Introduction and toolkit abstraction

[Jono Bacon]

Hi Jeremy,

>I'd like that idea too. It sure would make it easier for developers to
>later choose to support a different toolkit.
>
>I'd like to have a BSD-licensed toolkit that is as good as GTK or Qt, but
>a major obstable is having to recode applications to use it. So it would
>be nice to have your common interface.
>  
>
I think the ideal solution would minimise how much code needs to be 
changed in software. Each hacker who wants to make their tool compliant 
should only really need to change the bits of code where Qt/GTK specific 
parts are used, such as opening dialogs. These specific bits would need 
to be replaced with code that uses the abstracted library.

>One problem is uncommon features. What would you do about them?
>  
>
I think we would need to determine how much scope is common and 
uncommon. From my initial thoughts, I think there would be raltively few 
areas that are uncommon. In any case, if one widget set has an uncommon 
feature (such as a special dialog or picker), there is no 
standardisation to aim for - only one desktop has support for the 
feature. If we are standardising on themes it should not make much 
difference. Even if we manage to just get file open/save dialog boxes 
working, I think this will make software appear easier and more uniformed.

As an initial guess of common graphical attributes across toolkits, here 
are some:

 File open dialog
 File save dialog
 Directory open dialog
 Message boxes (Qt has different types, does GTK have similar types?)
 Colour picker
 Toolbar button config - this may not work as different toolbars work in 
different ways - maybe a KDE toolbar setup window could add/remove GTK 
buttons?

Cheers,

    Jono

-- 
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer