An advantage of designing for customization
Bryce Harrington writes about a simplified version of Inkscape. Sounds great, and it reminded me of Thomas Zander’s post about a simplified KWord interface for kids. The thing that struck me though is the implementation. From Bryce’s post:
“So, I think we could quite easily support an ‘inklite’ version of inkscape, built from the same codebase. Implementation-wise, it’d be easiest to do it as just two different executables via a #define INKLITE type thing; a lot of the menu code and stuff uses structs and static strings that can’t be modified at runtime. This is analogous to what we already do for inkview.”
#ifdefs to change some toolbars and menus around sounded a little strange to me, considering KDE menus and toolbars can be changed around through the user interface and through XML. Indeed from Thomas’s post:
“The simple-text plugin, like all other plugins can be enabled/disabled (or simply not be installed) for people that want a certain look. This makes it possible for one application to be used by all users in the market. The more the user needs, the more plugins he enables. Or in the case of our educational setting we disable most plugins and hide the default dockers.”
So, letting the interface be simplified with user controls compared to using #ifdefs… kudos to KOffice and KDE developers on creating flexible libraries.
Note: I hope this doesn’t get interpreted as a flame, I really like inkscape, this just pointed out to me what a great job KDE devs have done.
P.S. It’s a relief to use wordpress on >350MHz.