Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Apr 2015 14:37:23 +0300
From: Aleksey Cherepanov <>
Subject: Re: Improving Johnny

Hi Shinnok,

On Sat, Apr 18, 2015 at 11:42:39AM +0300, Shinnok wrote:
> > On Apr 18, 2015, at 12:05 AM, Aleksey Cherepanov <> wrote:
> > 
> > On Fri, Apr 17, 2015 at 10:31:25PM +0300, Shinnok wrote:
> >> 
> >>> On Apr 16, 2015, at 4:16 PM, Mathieu Laprise < <>> 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 <> , 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. ( <>)
> >>> 
> >>> 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:
> >> 
> >> <>
> >> 
> >> 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.
> > 
> >
> > 
> > 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.
> > 
> Why not setMinimumWidth() instead of Max? To me it would seem like a
> much more "scalable" and future-proof approach.

Because default width is higher than needed. If you make it smaller by
default and then set minimum width, then it may work.

> On a different note, if this QListWidget is giving us so much
> headache, my rationale tells me that we shouldn't really be using
> that just for displaying 5 icon buttons. Maybe rebase it on another
> kind of widget?

I remember that QListWidget was a pain due to other reasons too. I
think I was concerned that it was possible to drag items from it. But
I tried it now and the dragging works in a sane way. Either I fixed
that or something was changed in my environment and/or in qt.

Left panel may be done as a toolbar.

Also you may look how left panel is done in the VLC media player.

I hope you have a tactical to-do list or just a list of problems (not
in form of timeline) to put such problems on that list. Hm, you can
use Openwall's wiki and/or bug tracker on github.


Aleksey Cherepanov

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.