Introduction and toolkit abstraction
jono at jonobacon.org
Wed Sep 1 03:09:20 EEST 2004
>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
File open dialog
File save dialog
Directory open dialog
Message boxes (Qt has different types, does GTK have similar types?)
Toolbar button config - this may not work as different toolbars work in
different ways - maybe a KDE toolbar setup window could add/remove GTK
Jono Bacon - http://www.jonobacon.org/
Writer / Journalist / Consultant / Developer
More information about the xdg