kdelibs/kdeui

[Matt Rogers]

On Thursday 03 March 2005 02:10 pm, Dominik Haumann wrote:
> On Thursday 03 March 2005 20:25, Matt Rogers wrote:
> > On Thursday 03 March 2005 12:47 pm, Dominik Haumann wrote:
> > > CVS commit by dhaumann:
> > >
> > > fix: keep the right size when redock undocked widgets.
> > > Tested with: mainly k3b and some other apps.
> > > Now I can drag/drop/undock/dock widgets and the size is always correct.
> > > PS: There is a huge bug with highResolution, which has effects here. I
> > >     have fixed that locally here as well. So very probably a patch
> > > follows
> > >
> > > :)
>
> Btw, does this fix bugs/misbehaviors for example for Quanta as well?
> Andras?
>
> > highResolution is a huge bug, and will be gone for KDE 4.0 :)
>
> yes, but the even cooler thing is: I have a real fix for it *now* - not for
> KDE 4.0 :)
>
> I try to explain the problems with high-resolution:
>
>
> 1st) kdockwidget.cpp gets the splitter position on many places by using
> splitter->separatorPos(). This returns the separator position. KDockWidget
> assumes it is a value between 0..100 (so a procentual value), but if you
> turn on high resolution this is a value between 0..10000. Now assume the
> value is 10000 (eg. in kdocksplitter 100%), now it may happen, that
> KDockWidget (the very code I just changed) calculates "100-splitPos", which
> results in a value of "-9900", totally borked.
>
> Solutions for this:
> 1) KDockWidget can always test for highResolution. This is ugly and the
> code for this sucks.
> 2) KDockSplitter should provide an extra function separatorPosInPercent(),
> which always returns a value of 0..100. This works perfectly as I've got it
> already implemented and tested. I will commit this probably later :)
>
> Small example: k3b uses high resolution. Try to move a dockwidget, you will
> see the size always changes, it is *never* correct, because of the above
> described bug.
>
>
> 2nd) again highResolution. I try to explain why highResolution exists at
> all.
> Assume we have not high resolution, so only a value of 0..100.
> IF splitterKeepSize is not set, the splitter position always is a
> procentual value, which is right. But if you resize the windows (or do
> similar stuff like this) the splitter value always gets rounded to an
> integer value. That is, why the splitter only moves by ~8-10 pixel if you
> move it (see for example kate). It feels like there is something like a
> grid to which the splitter "snaps".
> IF splitterKeepSize *is* set, there is a problem. The code still saves the
> splitter position in a procentual value, so if you resize a window, the
> splitter position must always be corrected, so that the dockwidget's size
> stays. Because of the "low splitter resolution" there are a lot of rounding
> bugs, -- in short: low resolution and keep size is ***totally unusable***.
>
> If high resolution is set, the rounding bugs are not that bad, but they are
> still there, so it is still *unusable*! believe me! :) But I think that is
> why high resolution exists.
> Now: One could think "why not use a double for the separator position"? -
> Yes! That is what I tried, but it is not possible, because it is not BC.
> I'd have to change so much code which results in changes in public API -
> forget it.
>
>
> For all this I have a fix (along with some other fixes) - and it works like
> this:
> I remove the highResolution stuff so the resolution will be always 100000.
> (Of course, the interface stays, this is BC, but the function
> setHighResolution just has no effect anymore). 100000 is big enough to fix
> all rounding bugs for a screen resolution up to 10000x10000 pixel, so the
> user won't have/see bugs.
>
> (side note: assume the screen resolution is 10000 (yes, I exaggerate
> intentionally), then 100000*10000 = 1.000.000.000. This still fits into an
> 4-byte-int, so there is not buffer overflow)
>
>
>
> I just subscribed to the list, so I cannot answer to other mails now.
> There is an attempt to rewrite the dockwidgets (adymo afaik). Keep in mind:
> KDE 3.5 will be already this year, there is not enough time to
> 1. rewrite it and even stay BC
> 2. fix all bugs after the rewrite is finished
> If the rewrite is not BC, then other apps will not profit.
> So in short: Is it really right to rewrite it? For KDE 4 maybe, but who
> knows what the Qt4-QDockWidgets bring?
>
>
> I'd rather encourage all of you to try fix bugs in the current dockwidget
> stuff. If we all try *together*, we might even be successful ;)
>

Yes, whatever we can do now for KDE 3.5 will definately benefit, i'm just 
marking down changes that will be good to make sure we keep in mind for KDE 
4.

From what I can tell, Qt4's QDockWindow class is too much like a detached 
QToolbar that can just dock back to the main window. I've only taken a small 
look at it, so i'm still not really sure what kind of potential it has for 
KDE 4, and with the way the trolls have been changing things around lately, i 
haven't bothered looking again.

btw, will these changes close any bugs? :)

Matt