Re: Objective-C 2.0 and other new features in Leopard

[Dr Tomaž Slivnik]

> Tell me why GUI design would be more complex. Some more work can be  
> caused by color/tonality differences, but nothing we can't work out.

Well for one, if you're developing a new GUI control/element, what  
are you going to do? Will you now have to develop a different version  
for each theme in existence? What about updating it as themes are  
updated, or as new ones are introduced? Will developers end up  
supporting only certain themes? If so, the result will be a hodge  
podge of alien-looking GUI controls. So for one, themability makes  
innovation in the area of new GUI controls (well integrated with the  
rest of GUI) more difficult.

What about the relative sizes of GUI elements? Will they be the same  
in all themes? If yes, does that not constrain the themes you can  
develop unreasonably? If not, how will that affect developers?

The main, if not the only, real-life application to themability/ 
skinnability I've seen is music players. Any of the good ones allow  
their themes to change not just the relative sizes of GUI elements  
but also their relative positions. So to support themes well,  
applications, not just your application framework, will have to be  
themes-aware. Not to mention that I don't see how you handle the case  
of the general application at all.

Less importantly, what about colour schemes and style (e.g. line  
widths etc.) used within app. windows? In order for the look-and-feel  
to appear co-ordinated, these will have to be adjusted - in each  
application - to mesh well with each individual theme.

Etc.

Don't get me wrong - I've got nothing against themes; I like them in  
fact and think that a well designed GUI should be such that it can at  
any time be made themable. I.e. it should not be hard coded.

But I do not see how you plan to support themes (well) without  
significant associated costs. To me, the real question is not, does  
more configurability add more complexity or not; it is, do the  
perceived advantages outweigh the added complexity and cost?

Apple has decided not to support themes in OS X. It's not for lack of  
demand; the demand is there. There were even third party hacks around  
some years ago to allow you to do that. I think Apple even toyed with  
the idea at one point.

I believe a theming engine is a nice project for GnuStep. But is it  
justified to integrate it into the main distribution at this point in  
time and bear the costs this implies?

> Just accept for a fact that a vast majority of people dislike the  
> NeXT *look*, whatever the reason.

Hm. You could even be right, although I'm not sure you are right and  
I'm somewhat sceptical of you being to substantiate this assertion  
with evidence. How big is your sample size?

More importantly - crucially importantly - I don't think it  
matters ... the vast majority of people in this world like Windows.  
Or at least, say, and think, they like Windows. Moreover, if I want  
gummy and a Cocoa environment with the bestest and latest bloatware  
included, I can, and always will, buy Apple.

Would I be far wrong if I guessed that most people involved in  
GnuStep are old-time NeXTies who want to be able to continue using  
their favourite user environment in the 21st century, and continue to  
develop it in the same careful, considered, and well-designed way the  
original NextStep was developed?

GnuStep may need to ask itself the question - is its goal to pursue  
quality and satisfy this core group of users, and grow its user base  
organically, OR, to try to appeal to the masses, aim to become  
mainstream (an aim which, incidentally, I think is bound not to be  
achieved), and consequently have to make some compromises as a  
consequence (like Apple has done)?

Tomaž