GNUstep Icons UI Guidelines

[Quentin Mathé]

Hi,

Just a quick note to tell you I have finally moved GNUstep Icon UI
Guidelines written by Nicolas Roard and me on GNUstep.org as Alex Perez
requested it previously in February.

GNUstep.org web site doesn't reflect the web site cvs state… it should
be synchronised in two hours.

Main link :
http://www.gnustep.org/resources/documentation/Developer/UserExperience

For source DocBook :
http://www.gnustep.org/resources/documentation/Developer/
UserExperience/gnustep-icons-hig.docbook

For DSSSL stylesheet :
http://www.gnustep.org/resources/documentation/Developer/
UserExperience/gnustep-docbook.dsl

http://www.gnustep.org/resources/docs-web.html <-- linked here (I added
a link to OpenStep HIG PDF too)

Quentin.

--
Quentin Mathé
***@club-internet.fr

[Alex Perez]

Post by Quentin Mathé
Hi,
Just a quick note to tell you I have finally moved GNUstep Icon UI
Guidelines written by Nicolas Roard and me on GNUstep.org as Alex Perez
requested it previously in February.

Cool, thanks a lot!

Post by Quentin Mathé
GNUstep.org web site doesn't reflect the web site cvs state… it should
be synchronised in two hours.

actually, gnustep.org syncs at the bottom of every hour :)

Post by Quentin Mathé
http://www.gnustep.org/resources/documentation/Developer/UserExperience
http://www.gnustep.org/resources/documentation/Developer/
UserExperience/gnustep-icons-hig.docbook
http://www.gnustep.org/resources/documentation/Developer/
UserExperience/gnustep-docbook.dsl
http://www.gnustep.org/resources/docs-web.html <-- linked here (I added
a link to OpenStep HIG PDF too)

Thanks again, Quentin!

Alex Perez

[M. Uli Kusterer]

Post by Quentin Mathé
Just a quick note to tell you I have finally
moved GNUstep Icon UI Guidelines written by
Nicolas Roard and me on GNUstep.org as Alex
Perez requested it previously in February.

Great! That'll make it a lot easier to find
them, thanks! And thanks for the great work
writing this.

One suggestion: The link says "GNUstep User
Interface Guidelines", but then leads directly to
the Icon UI Guidelines. It may be a good idea to
either rename the link, or alternately to insert
an intermediate page that contains a link to the
Icon Guidelines plus another link for the actual
UI guidelines (which would probably be a link to
the OpenStep guidelines for now, or just a link
marked as "not yet available" or whatever.

Anyway, good work, guys!

[Quentin Mathé]

One suggestion: The link says "GNUstep User Interface Guidelines",
but then leads directly to the Icon UI Guidelines. It may be a good
idea to either rename the link, or alternately to insert an
intermediate page that contains a link to the Icon Guidelines plus
another link for the actual UI guidelines (which would probably be a
link to the OpenStep guidelines for now, or just a link marked as "not
yet available" or whatever.

I would like to add a GNUstep User Interface Guidelines intermediate
page where we could put links to various UI Guidelines topics/chapters
: well only one currently this Icons Guidelines chapter.
The link to OpenStep Guidelines document can be moved on this page
probably.

Now we just need someone really knowledgeable on docbook/dsssl/css
topic to become compliant with GNUstep.org look (by leveraging
GNUstep.org css)… Anybody here to work on this ? :-)

Anyway, good work, guys!

Thanks :-)

Quentin.

--
Quentin Mathé
***@club-internet.fr

[M. Uli Kusterer]

Post by Quentin Mathé
Just a quick note to tell you I have finally
moved GNUstep Icon UI Guidelines written by
Nicolas Roard and me on GNUstep.org as Alex
Perez requested it previously in February.

Quentin,

I just got an idea regarding hit-testing:

While it's a good idea to have icons accept
clicks on their full rect, so an icon with a hole
in the middle (like a CD) is easier to hit, this
could be a problem with icons that are very close
together, any maybe even partially overlap.

So, what about having "primary" and "secondary"
hits. I.e. it'd be considered a secondary hit if
a click only lies within an icon's rect, and
primary if it actually lies on a pixel of the
icon. During hit-testing, it would pick primary
hits in preference to secondary hits. That way,
if two icons are hit at the same time, the one
that actually draws on top would be considered
clicked.

You wouldn't really need a function for
detecting secondary hits in IconKit, but you'd
definitely need one for primary hits, and the
Interface Guidelines and method comments would
have to say that this method is only needed for
disambiguation when a rect-test for an icon
results in several hits.

Essentially, only people writing an app that has
freely positionable icons (like a file manager)
would need this latter hit-testing function. All
others would just test against the drawing rect.

Of course, to avoid that people accidentally use
the wrong method, you might have one that simply
returns YES for all points inside the icon's
rect, and another that does a pixel-test for
disambiguation, and name them accordingly.

[Banlu Kemiyatorn]

On Sat, 19 Mar 2005 00:00:09 +0100, M. Uli Kusterer

Post by M. Uli Kusterer
While it's a good idea to have icons accept
clicks on their full rect, so an icon with a hole
in the middle (like a CD) is easier to hit, this
could be a problem with icons that are very close
together, any maybe even partially overlap.
So, what about having "primary" and "secondary"
hits. I.e. it'd be considered a secondary hit if
a click only lies within an icon's rect, and
primary if it actually lies on a pixel of the
icon. During hit-testing, it would pick primary
hits in preference to secondary hits. That way,
if two icons are hit at the same time, the one
that actually draws on top would be considered
clicked.
You wouldn't really need a function for
detecting secondary hits in IconKit, but you'd
definitely need one for primary hits, and the
Interface Guidelines and method comments would
have to say that this method is only needed for
disambiguation when a rect-test for an icon
results in several hits.
Essentially, only people writing an app that has
freely positionable icons (like a file manager)
would need this latter hit-testing function. All
others would just test against the drawing rect.
Of course, to avoid that people accidentally use
the wrong method, you might have one that simply
returns YES for all points inside the icon's
rect, and another that does a pixel-test for
disambiguation, and name them accordingly.

Since each icon will be a bundle, I think it's better
to have a seperate layer to define hitTest: area
with one bit mask. With another policy that will
be used when there's no hit test bit mask available, is by
checking if any bitmap value is in a WxW matrix that
is centered to the hit point or not. Can we implement
this through NSAccessibility -accessibilityHitTest:
some how? May be GSIconCell?