[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdelibs/kutils
From:       Derek Kite <dkite () shaw ! ca>
Date:       2004-12-10 4:45:00
Message-ID: 200412092045.01708.dkite () shaw ! ca
[Download RAW message or body]

The flicker goes away if the window is resized big enough to not need the 
scrollbars.

Derek

On December 9, 2004 04:25 pm, Frans Englich wrote:
> (sorry for being slow)
>
> On Wednesday 08 December 2004 01:03, Aaron Seigo wrote:
> > On December 7, 2004 16:44, Aaron J. Seigo wrote:
> > > CVS commit by aseigo:
> > >
> > > don't give me seizures and don't lock up kicker
>
> Do you literally get lock-ups, it freezes?
>
> > with masterflash style
> >
> > > dance moves
> > > BUG:94619
>
> This is weird, I've never encountered this and can't reproduce(haven't
> checked out your change yet). Judging from the BRs, the flickering is there
> even if the user doesn't resize/move etc. Did this happen to any other KCM,
> other than kcmkicker? (I'll also ask the bug reporters)
>
> Combined with that I can't reproduce it on my setup, that the two BRs were
> on Kicker, and that one comment says "On devianart I saw blinking editboxes
> also. ", it perhaps suggests that the problem lies elsewhere? Do you know
> more exactly what caused the flickering? I have no idea what could case
> this, and how your changes fixes it(feel free to explain).
>
> > i should probably note right here that this _should_ be a temporary fix.
> > i just couldn't wait for the author to fix it properly at this point as
> > it was holding me up. this patch fixes things up, but basically makes the
> > scrollview thing useless as it'll never get used due to the call of
> > setMinimumSize. i tried a call to just setSize but it gets resized later
> > so .... bleh.
> >
> > so this is basically a return to the no-scrolling days
>
> Right.
>
> > but at least it
> > works.
> >  and i don't believe that simply squishing all kcms down to 640x480
> > out of some pedantism over the UI guidelines is acceptable since it takes
> > an interface that is too big for a small section of our users (800x600
> > resolution) and makes it suck for everyone.
>
> I'm not sure if we're compromising in the right direction, although I think
> it's this it boils down to; a policy decision.
>
> There's reasons to why the feature was added; the primary one was to make
> dialogs _usable_ on 800x600 setups. Simply, some dialogs expands outside
> the screen, making the buttons unreachable(!). I don't see how a dialog
> which the user has to resize is /more/ important than that. In other words,
> there's other scenarios than Kicker, and what we want is a result which not
> necessarily is optimal for only Kicker, but gives the best overall result.
>
> Regarding the HIG rule, I'm not the one to judge it or say when it can be
> ignored -- I haven't made it up. Neither am I to tell what users KDE have
> or how important they are. As a side note, it's interesting to paraphrase
> the xml/text configuration discussion; for the power users, a small
> percentage of our users, it is unthinkable to have an editing on the level
> of the everyday of web designers(xml).
>
> I won't debate the HIG clause, but I can tell why I think it's important.
>
> It's _not_ only about making dialogs usable on certain screens; it's also
> about making the window paradigm better for /all/ users. When windows are
> "small" the user has flexibility with arranging the windows and it hence
> becomes more practical to use multiple windows. For example, guess if using
> multiple windows is cumbersome when dialogs are as big as main windows.
>
> Dialogs are not designed for being large -- then should they show up in the
> taskbar among other things -- but is a subset of the main window, which the
> user can see in the background and percepts the context off(this is
> emphasized by slightly transparent dialogs, for example). Keeping dialogs
> small/smaller is about making windows practical.
>
> Open source/KDE expands in developing countries and that means cheap/old
> hardware -- making sure it's attractive for them can be seen as
> economically of interest(world domination) as well as from a  humane
> perspective.
>
> In other words, I don't think it can be classified as HIG pedantism. What
> you did, was to point out a part of the HIG and say that that one is
> actually wrong, and motivated it with a sentence or two.
>
> But debating the HIG clause is not of interest -- what's relevant is what's
> the /most/ important: that users doesn't have to resize windows, or that
> dialogs are _unusable_ for users(AFAICT). I would redesign the dialogs, and
> even reach a better overall result.
>
> What do you think?
>
> Fuck, I need more time.
>
>
> Cheers,
>
> 		Frans
[prev in list] [next in list] [prev in thread] [next in thread]