[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Relative positioning (Re: Objective-C 2.0 and other new features in

From: Christopher Armstrong
Subject: Re: Relative positioning (Re: Objective-C 2.0 and other new features in Leopard)
Date: Mon, 12 Nov 2007 09:39:16 +1100
User-agent: Thunderbird (Windows/20070728)


By no means whatsoever did I intend to imply that I support integrating relative positioning directly into GNUstep. I used Renaissance as an example of an add-on framework that people can use to support relative positioning in their applications. I agree with your point completely.

I did mean to imply though that most GNUstep applications are designed with fixed positioned elements - it would be up to the developer to convert them to a relative-positioned system, and theme developers would need to make sure they don't break things for existing applications (e.g. button borders that are too thick).


Gregory John Casamento wrote:

"Yes, because GNUstep has fixed positioning and sizing for its GUI elements, the themes that can be developed should be constrained. Developers of themes are unfortunately tasked with testing their theme against as many applications as possible, but in some instances there will be a mismatch. The Renaissance framework (which uses relative sizing) may solve some of these issues. A good example of applications which must run in an environment that supports multiple themes is Windows (2000, XP, and Vista all have different themes which are drawn by the same API)." Please read my previous reply.
I would much rather this functionality be implemented as a framework with a 
palette available for use in Gorm, if we're going to have relative positioning. 
  There's nothing in the way Gorm or IB are built that rules out relatively 
positioned elements.   They are, in fact, built with no assumptions regarding 
the position of elements.  The only parts of them which do assume anything are 
the inspectors.  It's possible to have inspectors and editors which can deal 
with relative position added to the application via the palette.

Later, GJC

Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer

----- Original Message ----
From: Christopher Armstrong <address@hidden>
To: address@hidden
Sent: Sunday, November 11, 2007 4:59:51 PM
Subject: Re: Objective-C 2.0 and other new features in Leopard


I've looked at implementing theming under GNUstep before. I started writing patches to allow individual controls to be themed, and in parallel, writing a theme engine that integrates directly with the uxtheme API on Windows, for a native Windows XP/Vista look and feel. I haven't got very far with this because of time constraints (full-time

Most of your questions are legitimate concerns. However, with an area like theming, like many engineering problems, you do have to be intensely pragmatic about what you create, what features it will have, its limitations, etc. This does not mean that you shouldn't attempt to support them at all. My (subjective) experience suggests that we can support theming without putting an unreasonable burden on the developer or the theme maintainer.
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.
This is a valid point, but the problem is far better than you think. Most controls are composite of a relatively small set of elements, those elements being things like a background (solid shade, blended gradient, image, etc), a button (of which there may be different button border styles and maybe different icons for radio, checkbox buttons, etc), a selected/unselected state (often this is just a highlight).

Controls like NSTableView would use a combination of simple elements (such as buttons) to draw the outside parts, and most likely, draw their grid in the same way under every theme (i.e. you wouldn't theme the grid lines).

There are some controls that don't quite fit this model, and will require parts of them to be themed (menus are a good example, whereby you don't use a button for every menu item). This is unavoidable, and we should do the best we can to allow them to be consistently themed. If new GUI controls are added, we need to be proactive in making sure that themes are updated to support them.
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.
Yes, because GNUstep has fixed positioning and sizing for its GUI elements, the themes that can be developed should be constrained. Developers of themes are unfortunately tasked with testing their theme against as many applications as possible, but in some instances there will be a mismatch. The Renaissance framework (which uses relative sizing) may solve some of these issues. A good example of applications which must run in an environment that supports multiple themes is Windows (2000, XP, and Vista all have different themes which are drawn by the same API).

Conversely, there is some expectation that developers will need to test
their applications against good, well-accepted themes. This highlights the importance of providing a nice, standard theme that developers can test against. Also, when developing for platforms like Windows, developers will need to maintain a separate set of nibs, as they will need to modify them to satisfy Windows's user interface guidelines e.g. an obvious one that comes to mind is putting the "OK" button on the left, something Apple regularly forgets to do with its Windows ports of its applications. Another is that menu items will need to be iconed and renamed to the standard Windows icons and names. A developer will still need to "port" their application to different platform, it really isn't just "compile everywhere".

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.
There is a little bit of debate about this. One school of thinking
would suggest that themes dictate the colour, thickness, etc. of elements (this is what I believe) because then the theme covers everything. Another would suggest that the theme be much more flexible and allow its colours to be changed; the disadvantage here is that themes would need to be created very specifically, often by hand in code, instead of being able to use a graphics editor as you can with Camaelon.

Also, it is important to separate look and feel from themeing. In GNUstep, the path (I think) that has been taken is that the "feel" is dictated by GNUstep, and this covers the layout of GUI elements (e.g. menus vertically/horizontally stacked, scrollbars on the left/right, scrollbar button positions, etc.) as well as the behaviour of applications. The theme dictates the "look" or "eye-candy" aspects: it should be able to work with an OpenStep, Mac, Windows feel but still be able to dictate the look. The boundaries between look and feel can be difficult to define but it is something where you need to make a decision on. I think the aim here is to leave as little uncertainty as possible and make things as simple as possible for the theme developer.


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?
Aesthetics are a very subjective thing, as you could probably tell by the amount of debate that appears on this list about the default NeXT theme. I think the flexibility is a worthwhile cost in most people's minds (your "perceived advantage"). It is expected that you can theme most applications/environments these days. It isn't configurability per se, it is being able to change the look of the application. These things combine to affect "perceived quality" e.g. a user may think: "if my application looks and feels like Windows Vista, but I know it isn't, but I still think it is a good application because it seems to integrate with my environment".
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?

Apple have tried to reduce the amount of different user interface looks
they present to developers to present to users in Leopard. The key reason is that they have a much greater imperative to maintain a consistent look and feel, which is part of their branding and marketing of MacOS X as a consistent, integrated environment that doesn't get in your way and lets you get your work done, but also doesn't look so bad as well. It makes things considerably easier in terms of maintenance.

We, on the other hand, should at least strive to support theming as it gives us a certain amount of flexibility in how we can present our applications. We also need to make sure that our code is portable (that is a key objective, I believe, of this project), and the look is part of this well. Apple don't want to run Cocoa on other platforms, so they don't need to support theming so that it looks like other platforms (anyone want a Mac that looks like Motif? Windows XP? anyone ;-)

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)?
I for one, don't like the default NeXT look. That is motive enough for me to try and change it. Unlike users, we have the skills to modify the code to change its look and feel as we please (time permitting). Users will simply move on if they don't like the look, and find something else that works (maybe not as well) and just use that, because they like the way its looks. We have established that we prefer users over the look and feel, so that we should probably try and get even just a few more users, even if this is a somewhat elusive goal for this project.

We are not trying to continue some legacy that NeXT left the market. OpenStep and NeXT are dead. We should try and move on and pursue our own goals, instead of trying to remain loyal to a company that has gone before us. For goodness sake, the old NeXT look is just a theme - we should be able to change it as we please. We can write an add-on for it later :-)


Discuss-gnustep mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]