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

List:       koffice-devel
Subject:    Re: Making koApplication inherits KUniqueApplication
From:       Thomas Zander <zander () kde ! org>
Date:       2005-11-04 12:05:53
Message-ID: 200511041305.54538.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 04 November 2005 12:58, Clarence Dang wrote:
> On Wednesday 26 October 2005 21:43, Thomas Zander wrote:
> > On Wednesday 26 October 2005 13:03, Clarence Dang wrote:
> > > > ps. the usability aspect of KConfig changes has been solved many
> > > > years ago already in the original styleguide.
> > >
> > > Have you ever seen the recent file list in KOffice staying in sync
> > > between windows?   It only works if those windows are in the same
> > > process.   So depending on how I invoke KWord (running another
> > > instance or clicking File / New), I get different behaviour.   That
> > > is not desirable.
> >
> > Sure, I agree that that does not work as needed, but there is
> > absolutely no need to go and kill a huge gain we have in sharing
> > processes because you have no idea how to fix a little sideeffect.
>
> Again, you still haven't solved the problem of a modal dialog blocking
> unrelated open documents.

The KWin window hierarchy certainly does allow this nicely.  Nobody 
bothered to actually find out how to do so yet, I assume..

> > In the above mentioned styleguide it says that a config is
> > application wide and is effective as soon as OK is clicked.
>
> My point entirely.  Almost no application I've seen does this correctly
> (not limited to recent files list - lots of settings).

Might that be because they all share the same configure framework ? :)
The applications I wrote for a former client (based on Java) certainly 
does this just fine, which is why I know its entirely possible if you 
only look for the right problems before stating a solution.

> > Directing your question back to kconfig being flaky;
> > A much easier way to fix this is to mark a config as dirty whenever
> > another process overwrites the config file and reparse/merge when its
> > needed afterwards.
>
> Keeping files in sync is going to be fun.

Its incredibly easy if you use the scheme I described in my previous email 
(and go on describing below).  Again; I already did this in practice 
ones, so this is not just a figment of my imagination.

> A while ago, Michael 
> Goffioul said that he used a DCOP signalling mechanism in KPrinter to
> get around this. 

Thats not a solution, thats a workaround to a lack of a proper config 
layer.

> Alternatively, I guess the config could be pulled out 
> into a server rather than being per application.

Being per process, you mean?
Having a server is not needed; as long as the configuration layer knows 
what the orig value was so it has a clear and simple way of doing a 
'diff' internally as well as a secondary level diff with the file system 
version.

> I'm just tossing around ideas here.

Sure, which part of my solution did I not explain very well yet?

-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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