ui-standards.rc tweaks to Settings menu

[Frans Englich]

On Wednesday 27 October 2004 15:52, Aaron J. Seigo wrote:
> On Wednesday 27 October 2004 05:12, Tobias Koenig wrote:
> > Hmm, I don't know whether it was already discussed on kde-usability, but
> > wouldn't this option make more sense in the 'View' menu?
>
> it might, yes. however, we have apps that use noMerge for the settings menu
> that put Fullscreen the settings menu. so, ironically, it's not as simple
> as changing it in ui-standards.rc. i'd rather see us be consistently
> imperfect that inconsistently perfect ;-)
>
> for KDE4 i hope we can go through the ui-standards.rc thoroughly, including
> documenting how it works[1] and finding common cases where noMerge occurs
> in applications with the goal of making those noMerges less necessary
> (increasing our ability to make policy changes with less effort)
>
> Tobias, David: thanks for reviewing, i'll commit later today when i get
> into the office =)
>
>
> [1] this is off-topic for this thread, but i'm increasingly concerned about
> knowledge transfer from the original authors/designers of technology in
> kdelibs to our present and future maintainers and application developers.
> writing ui.rc files is still something of a grey art and not
> comprehensively documented anywhere that i know of.

In the thread[1] on kde-guidelines about integrate developer.kde.org and the 
various upcoming guidelines, we discussed this topic. Specifically, I wrote:

<quote>
It is hard for developers and 3rd parties to use the KDE technologies since 
the notes are hidden in informal READMEs and text files in the CVS 
repository. It's unacceptable that building upon the KDE technologies requires 
checking out our inhouse development modules.

Combined with the content of developer.kde.org is loosely organized, 
scattered and vague -- but good things once one have found it -- I have in 
plans to organize what we have, into a KDE Development book. Specifically, a 
reference book which covers KDE technologies such as KConfigXT, autostart, 
DCOP, and so forth, at a high level, roughly as replacement for 
developer.kde.org(docbook). This needs KDE in order to have a 3rd party 
appeal.
</quote>

(it probably sounds a bit scary when taken out of context)

So, a solution to that, in several senses big problem, is coming.


Cheers,

		Frans

1.
http://mail.kde.org/pipermail/kde-guidelines/2004-September/000025.html