On Thursday 14 June 2007 16:58:39 Boudewijn Rempt wrote:
> On Thursday 14 June 2007, Jonathan Riddell wrote:
> And after years of claiming that 
> having ordinary and advanced buttons wasn't a solution, that's just what
> system settings provides.
Kind of an off shoot, but this idea has been bouncing around in my head for a 
while.
Hidden options: As some of you may know I wrote the kcm tweaK which handles 
many of the hidden options of KDE. extremely simple app, in fact so simple 
that I wanna redo it when I go to port it to kde4 sometime probably much 
later (probably around 4.1.x)
The idea I had was implementing a sort of a plugin style where when a new 
hidden option is introduced they can install a xml file describing the config 
file, the option, type, text, description, etc. in which this would read and 
create a sort of a dynamic GUI sorta like a general area for those options 
that either can't get a GUI option due to string freezes or would just 
clutter up the interface. being it'd have to be independent of the string 
freezes this couldn't be in any kde module. But in a way I'd like to poll you 
all on something. These description files (KConfigXT? or something similar?) 
should they be independent of the modules as well (ie maintained by the tweak 
project) or something installed along with the kde modules that tweak would 
just read?
Being maintained in the module would introduce possible translation issues 
when they upgrade but at the same time there is a much higher possibility 
that these options would get added to the interface.(sorry I don't monitor 
for new hidden options I just read the wiki ever so often =) Also probably 
more important is, this would sync the options with the current installed 
version. no need to run version checks to enable/disable options.

By doing this I'm not suggesting this is the place to store those 'advanced' 
options. Just a place to throw options that can't get a GUI option (yet or at 
all)
Does this sound like a good idea? suggestions?

-- 
Stephen Leaf