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

List:       kde-devel
Subject:    Re: UI Inconsistency OK APPLY buttons
From:       Marcos Dione <mdione () grulic ! org ! ar>
Date:       2003-04-02 4:31:28
[Download RAW message or body]

On Mon, Mar 31, 2003 at 09:09:25PM +0300, Andras Mantia wrote:
> Just for the note: and Cancel cancels the changes also in case when Apply was 
> pressed before. So in any case after you pressed Cancel the state of your 
> application/dekstop/whatever should be the same as before the dialog 
> appeared.

    Suppose this other situation: you have an applet that fiddles with the
screensaver's (ss from now on) settings. Enabled, disabled, run, etc. This
applet also reflects those settings with some icons. What happens? If the user
changes the setting from the control center, the applet does not realizes of
that [1] and shows a status that is wrong.

[1] Unless the applet 'pings' for changes in the conf. One way I used was
polling w/ KConfig. This has the drawback of reading constantly from the fs, and
setting the last access time in the file, so if the updates are too often, you
have an active fs. This may prevent your system to sleep. And if it's not too
often, you get a status taht is wrong again. Another way would be to accomplish
in a 'good' way would be to use fam.

    But I think a better solution would be something that has the status of the
configuration of any app *that wishes this kind of conf handling*. This
something would have the ability to hold temporal configs, emit signals when
conf changes, save them (even with different backends, may be) and any other
things you may wish.

    I think this thing would solve both problems. May be I should explain more
the idea, but I haven't time to sepnd it thinking on this. Maybe someday. But
remember the free soft way: release early, release often. Comments?

-- 
La gelatina hecha con vodka pega mas que 'La Gotita'
            --oyente anonimo del programa de radio "Dos tipos audaces"
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]