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

[Gregory John Casamento]

Chris,

To edit myself here a little bit...  I'm not disregarding Nicola's work on 
Renaissance.   I'm simply saying that the assumption that the concept of 
relative positioning doesn't fit into Gorm/IB is incorrect.

GJC
--
Gregory Casamento -- OLC, Inc 
# GNUstep Chief Maintainer

----- Original Message ----
From: Gregory John Casamento <greg_casamento@yahoo.com>
To: Christopher Armstrong <carmstrong@fastmail.com.au>; discuss-gnustep@gnu.org
Sent: Sunday, November 11, 2007 5:17:27 PM
Subject: Relative positioning (Re: Objective-C 2.0 and other new features in 
Leopard)

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





_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep