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

List:       kde-usability
Subject:    "UNIfication"
From:       David Laban <alsuren () gmail ! com>
Date:       2005-05-28 0:58:36
Message-ID: 200505280203.00241.alsuren () gmail ! com
[Download RAW message or body]

I had a long email planned but after some thought, I realised that it boiled 
down to this (at 2:00 am):

If I wanted to change the position of "configure" etc. so it fitted in with 
the Gnome standards, could I do it without a re-compile?

Basically, I would like to propose a system for generating menus and button 
layouts for yes/no/cancel in which all the work is done by a different 
process (similar to how Kparts works, but for menus). This way, we make it 
easier for programmers to follow interface guidelines because their program 
basically says "create a yes/no/cancel button array" and then when the other 
process returns the answer, your program does the appropriate thing. This 
also means that if there are KDE and Gnome users on the same PC, the Gnome 
user could use a different interface program, which puts the 
"settings/configure" under "tools/options". This way, you can have all your 
programs (GTK and Qt) following the KDE and Gnome HIGs and you don't need to 
recompile every time you want to change DEs

The title of UNIfication was a take on "UNIX" because UNIX has lots of 
programs which you can pipe into and out of. The idea is that *everything* to 
do with creating a frontend could be piped out into a different program, 
leaving the user's processes to do less and less. The situation described is 
comparable to the choice between piping through grep or less in order to get 
an output. Each program takes the same input but each displays a different 
output
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]