[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: |
Gregory John Casamento |
Subject: |
Re: Relative positioning (Re: Objective-C 2.0 and other new features in Leopard) |
Date: |
Sun, 11 Nov 2007 14:34:42 -0800 (PST) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Relative positioning (Re: Objective-C 2.0 and other new features in Leopard),
Gregory John Casamento <=