[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Apr 2015 16:27:47 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Improving Johnny
Hi Mathieu,
Planning is a hard task even for us. Though we may guide you on
exact points. So write your plans as you see them now and share
sooner, so we will discuss them.
2 weeks for 1.4 -- 2.0 is too short. 2.0 #1: "first stable release"
includes building and testing packages for various OSes (Shinnok -
right?), it will take a full week at quite high speed.
Put more time on all things because
- you will have problems with john (everyone has)
- most tasks need time to investigate and choose right solution
- you'll need time to learn and understand various aspects of john
- you'll need time to write mails and discuss your problems with us
- most probably you will implement and redesign some things several
times, you'll need space for improvements
- we don't really know your coding skills
Every task has pitfalls. Most tasks do not have obvious solutions.
Don't be scared to put more time on tasks than "needed", you'll need
even more. We expect high quality of code and SOLUTIONS.
Please choose speed that you will be able to maintain during the whole
period of time. It should not be boring but don't stress yourself too
much because 3 months is quite long. Don't worry too much and don't
expect too much from yourself. While gsoc can motivate you quite much,
gsoc is not a magical thing that make you write code fast and right
from the first try. Also put some time for learning.
Is it more convenient for you to iterate over one feature till it is
done? Or is it more convenient for you to implement several features
and only then improve them? Like
1. implement feature 1
2. improve feature 1
3. improve feature 1
4. consider feature 1 as done
5-8. the same with feature 2
9-12. the same with feature 3
or
1-3. implement features 1, 2, 3
4-6. improve features 1, 2, 3
7-9. improve features 1, 2, 3
10-13. consider features 1, 2, 3 as done
?
You saw that the things are not very predictable: dynamic language
choosing brings a problem with width of the left panel, and there is a
possility that the solution will be a replacement of qlistwidget for
the left panel with a toolbar that it is far more harder to implement
than you can predict at the very beginning. That way, a trivial
cosmetic change brings big redesign. And there will be bigger
problems. We expect you to solve such tasks, not to do only trivial
changes. Your work should be deep, remember that writing the timeline.
Do you have a list of things you'd like to learn during the summer?
Did you work on some projects that were 2-4 months long? What
technical and personal problems did you face? (You may give answer for
these questions in personal mail with CC to Shinnok and Solar
Designer.)
It may be helpful to select some set of tasks that you're sure to
implement during the summer. We may need that to judge you during
midterm and final evaluations if something goes wrong.
And I'd like to see your answer to my question about temp <<
QString(...) to have more ideas about your abilities.
Thanks!
Regards,
Aleksey Cherepanov
On Sat, Apr 18, 2015 at 11:33:52AM +0300, Shinnok wrote:
> Hey Mathieu,
>
> I can't really do that estimation for you, what I can estimate is my efforts which aren't that useful for you. I suggest you try and evaluate yourself and the tasks at hand so that you can come up with estimates that pertain to you. This way you learn what each task implies more deeply, learn a bit more about Johnny and JtR as you try to figure out what each task is about and also get to evaluate yourself more.
> Don't overthink it though, come up with a plan and we can revise it afterwards. I suggest you focus on this and your finals in the next week so that you don't feel overloaded.
>
> Shinnok
>
> > On Apr 18, 2015, at 2:54 AM, Mathieu Laprise <mathlaprise@...il.com> wrote:
> >
> > Shinnok,
> > How much time would you estimate doing the first tasks that you mentionned to me : version 1.4, 1.5, 1.6 ? As you told me, I'm trying to make my timeline and separate 1.4 to 2.0 versions into 2 weeks sprint.
> >
> > On Fri, Apr 17, 2015 at 5:05 PM, Aleksey Cherepanov <lyosha@...nwall.com <mailto:lyosha@...nwall.com>> wrote:
> > On Fri, Apr 17, 2015 at 10:31:25PM +0300, Shinnok wrote:
> > >
> > > > On Apr 16, 2015, at 4:16 PM, Mathieu Laprise <mathlaprise@...il.com <mailto:mathlaprise@...il.com> <mailto:mathlaprise@...il.com <mailto:mathlaprise@...il.com>>> wrote:
> > > >
> > > > Hey guys,
> > > > I continue working on what we said yesterday. Here is just a quick update saying why I didn't finished yet.
> > > > There is probably a problem in the layout logic somewhere in the MainWindow designer file. In 2012, Aleksey found a workaround by specifying a maximum size and a magic numbe for the left menu bar :
> > > > // TODO: Magic number. It seems to be wrong approach.
> > > > m_ui->listWidgetTabs->setMaximumWidth(m_ui->listWidgetTabs->sizeHintForColumn(0) + 4);
> > > >
> > > > This workaround works most of the time but when you change the text dynamically in the MainWindow class by choosing french in the setting's list. I apply a translator, call the QT built-in method retranslateUi and everything layout correctly except the listWidgetTabs. As you can see on the screenshot http://i.imgur.com/8yZ0vkb.jpg <http://i.imgur.com/8yZ0vkb.jpg> <http://i.imgur.com/8yZ0vkb.jpg <http://i.imgur.com/8yZ0vkb.jpg>> , the listWidgetTabs object don't resize correctly when we add a bigger text than it previously contained(french word "Mot de passe" is bigger than "Password"). The rest of the screen looks great with translation because the layouts do their jobs and there are no hardcoded values.
> > > >
> > > > I tried to force relayout by calling update, updateGeometry, repaint and doing similar to what Aleksey did. However, it doesn't work. It only works when you read the settings and translate the application in main.cpp, before MainWindow is created. (http://i.imgur.com/YTvljPh.png <http://i.imgur.com/YTvljPh.png> <http://i.imgur.com/YTvljPh.png <http://i.imgur.com/YTvljPh.png>>)
> > > >
> > > > So we have two solutions:
> > > >
> > > > 1- Remove the work around with a magic number and find a real fix. What makes it harder is that all UI code for all screens is in the same file(mainwindow.ui) so I'll have to proceed with care while making changes to layouts.
> > > >
> > > > 2- On first startup, the application will choose system language(ex: french). If the user go in the settings to choose english, he has to restart the application for the changes to take effects. For all further startups, the language will be english.
> > > >
> > >
> > >
> > > This is a limitation of QListWidget that warrants a workaround. The proper fix for this with Qt >= 5.2.0 is to set QListWidget::SizeAdjustPolicy to QAbstractScrollArea::AdjustToContents. This is what you end up with:
> > >
> > > https://www.dropbox.com/s/je1fhj0cqx4y5ax/Screen%20Shot%202015-04-17%20at%2010.14.27%20PM.png?dl=0 <https://www.dropbox.com/s/je1fhj0cqx4y5ax/Screen%20Shot%202015-04-17%20at%2010.14.27%20PM.png?dl=0> <https://www.dropbox.com/s/je1fhj0cqx4y5ax/Screen%20Shot%202015-04-17%20at%2010.14.27%20PM.png?dl=0 <https://www.dropbox.com/s/je1fhj0cqx4y5ax/Screen%20Shot%202015-04-17%20at%2010.14.27%20PM.png?dl=0>>
> > >
> > > 1. Automatic adjust to contents on the fly.
> > > 2. Things that are really way to big will get elided. (thankfully there's eliding already in ListWidget)
> > > 3. All else on defaults(Layouts to preferred, no max-mins, no resize, ..).
> > >
> > > In my example I removed the setMaximumWidth call in MainWindow. As a general rule of thumb in UI design, we should never use a max constraint anywhere unless that's really the last resort. I'll look for the best approach to #ifdef for Qt <= 5.2.
> > >
> > > I should have some time tomorrow to deal with the repo issue, so that we can proceed to commiting the various changes we're talking about.
> > >
> > > PS: We might have to #ifdef the Qt 4 support back in like Mathieu did(Kali, KDE4 compat., etc..), shouldn't be that hard since there are just a couple of changes for 5. Though at some point I'd really like to get rid of it.
> >
> > http://stackoverflow.com/questions/6337589/qlistwidget-adjust-size-to-content <http://stackoverflow.com/questions/6337589/qlistwidget-adjust-size-to-content>
> >
> > The solution is to subclass QListWidget overriding sizeHint to return
> > sizeHintForColumn(0) as width. Though for me, it is needed to add 4
> > pixels, hence the hardcoded value (though it is not need in default
> > desktop environment). So I propose to move
> >
> > m_ui->listWidgetTabs->setMaximumWidth(m_ui->listWidgetTabs->sizeHintForColumn(0));
> >
> > into sizeHint of a subclass of QListWidget.
> >
> >
> > Old mail about width
> > http://openwall.com/lists/john-dev/2012/08/20/1 <http://openwall.com/lists/john-dev/2012/08/20/1>
> > > > - Fedora gives "..." in "Passwords" label
> > > > always under gnome3 fallback mode(?)
> > >
> > > I've seen it on other distros as well (openSUSE, Ubuntu), when testing
> > > older versions of Johnny - talking to my X server over SSH port
> > > forwarding. I think it's not dependent on what distro Johnny runs on,
> > > but rather what distro (fonts) the X server runs on. Yet you need to
> > > fix it in Johnny somehow.
> >
> >
> > Old mail about problems with small window height
> > http://openwall.com/lists/john-dev/2012/08/19/10 <http://openwall.com/lists/john-dev/2012/08/19/10>
> > small height causes scrollbar to appear in list widget, the width of
> > the widget is not adjusted so items are shrunk and labels are reduced.
> >
> >
> > Thanks!
> >
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
