[Kde-pim] Akregator column widths
Jonathan Marten
jjm2 at keelhaul.demon.co.uk
Thu Jan 29 15:18:48 GMT 2009
Frank Osterfeld <frank.osterfeld at gmx.de> writes:
> On Wednesday 28 January 2009 17:55:48 Jonathan Marten wrote:
>> Some people have reported (bug 152702) that the problem with
>> remembering column widths and configuration is not fixed in 4.2
>> released today, and I've noticed the same with current trunk.
>
> So you say it still forgets its settings in trunk, for you? Does
> that only apply to the feed list or also the article list?
Both, although not the same problem. In the article list the last
(date) column would resize itself both on startup and if new articles
arrived when another tab was open. I suspect that the former is a Qt
problem that it is possible to work around in Akregator (doing the
'header()->resizeSection(header()->count()-1,1)' before a
restoreState()), while the latter is another Qt problem that the
isVisible -> isHidden patch fixes.
In the feed list the saved column state didn't appear on startup,
adding a restoreState() to loadHeaderSettings() fixed that. I can't
work out why this applies to the feed list but not the articles,
unless the caller uses setModel() differently - that previously was
the only place where the restoreState() got done. But see below.
> The line in subscriptionlistview.cpp, right? Shouldn't the header settings be
> applied correctly when the first model is set, in setModel() (the model() == 0,
> m != 0 case)? And why is this only necessary in subscriptionlistview but not
> in articlelistview?
It should work that way, but when I looked here after updating with
your 2 commits (and before applying the Qt workarounds) it didn't seem
to work. I've just built again without the restoreState() there and
it seems to work, so perhaps the other fixes have solved this one too.
I'll leave this line out in the commit.
> The whole resizing behavior in QHeaderView is weird. I think I am safe to say
> that, I have seen enough people struggling with it by now ;)
> lastSectionSize not initialized as in uninitialized variable? That'd be a
> clear bug to me.
Haven't been able to completely figure out how that variable is used,
but it is not initialised in the constructor which spells danger.
Looking at the value at runtime, it seems to have random values which
are no relation to the size/layout of the view.
>> (3) may also be a problem with Qt, but which it is not possible to
>> work around in Akregator. There is a simple patch, but I don't know
>> if there would be any point in trying to get this into Qt 4.4 since
>> 4.5 will be out soon (and KDE 4.3 will require Qt 4.5, is that
>> correct?). Qt 4.5 seems to be quite different in this code area, so
>> maybe the bug is already fixed.
>
> This bug affects both Qt 4.4 and 4.5 snapshot? I'd say lets try to get it to
> the trolls as quick as possible. 4.2.x will still be based on 4.4.
Haven't tried 4.5 yet.
I'll submit a Qt task for the isVisible -> isHidden fix, since that is
easily described and there is no workaround in Akregator. Not sure
about the other problem, since it is not so easy to pin down.
>> The patch also maintains separate article list column configurations
>> for the "feed" and the "group" mode, instead of simply removing/adding
>> the "Feed" column. Doing that resizes the following column ("Date")
>> to fit, where it would make more sense to resize the variable-length
>> "Title" column.
>
> Makes absolute sense.
Thanks for your comments... will fix the whitespace/indentation, and
will commit each fix/feature separately.
> If that turns out to be Qt bug, better mark it as workaround (possibly with
> affected versions, Qt task tracker number etc.) so we can clean it up later
> again.
Commented appropriately.
--
Jonathan Marten http://www.keelhaul.demon.co.uk
Twickenham, UK jjm2 at keelhaul.demon.co.uk
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list