Chris,
"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 <carmstrong@fastmail.com.au>
To: discuss-gnustep@gnu.org
Sent: Sunday, November 11, 2007 4:59:51 PM
Subject: Re: Objective-C 2.0 and other new features in Leopard
Hi
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
uni).
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.
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?
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 :-)
Regards
Chris
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep