SDL 1.3 and Menus

SDL Development
1

I know that this could be considered out of scope, and maybe it’s
something already in, but it would be nice to see relatively simple
menu support in SDL windows. It could obviously be tied into the
event system easily and the menus would probably be programmatically
created.

The reason I’m asking is a lot of games can have a windowed mode and/
or editors and other utility programs that could be better served with
more cross platform code.

There’s the 1 menu vs many OS problem, though.

[>] Brian

2

There is a lot of history behind the decision to add multiple window
support to SDL. One of the serious objections to doing it at all is
that supporting multiple windows seems to be a slippery slope leading
to supplying an entire GUI. So, it was decided to provide the minimum
needed to create a GUI without actually adding a GUI to SDL. So, in
SDL you have the ability to create multiple overlapping windows. You
can use those windows any way you like, including using them for
menus. But, SDL does not, and is not likely to ever, provide a menu
system in the core of SDL.

Feel free to write any sort of menu code you like and to share it as
you like, but do not expect to see menu support built into SDL.On Wed, Dec 3, 2008 at 7:30 PM, Brian Barnes wrote:

I know that this could be considered out of scope, and maybe it’s something
already in, but it would be nice to see relatively simple menu support in
SDL windows. It could obviously be tied into the event system easily and
the menus would probably be programmatically created.

The reason I’m asking is a lot of games can have a windowed mode and/or
editors and other utility programs that could be better served with more
cross platform code.

There’s the 1 menu vs many OS problem, though.

Note to everyone… before jumping in and starting a long debate on
this subject please go back and read the archives on this subject. I
first got into the discussion in 2002, and I’m sure it was going long
before I got in to it. So, please educate yourselves on what has
already been said before joining the discussion.

Bob Pendleton

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

±-------------------------------------+

3

There is a lot of history behind the decision to add multiple window
support to SDL. One of the serious objections to doing it at all is
that supporting multiple windows seems to be a slippery slope leading
to supplying an entire GUI. So, it was decided to provide the minimum
needed to create a GUI without actually adding a GUI to SDL. So, in
SDL you have the ability to create multiple overlapping windows. You
can use those windows any way you like, including using them for
menus. But, SDL does not, and is not likely to ever, provide a menu
system in the core of SDL.

Feel free to write any sort of menu code you like and to share it as
you like, but do not expect to see menu support built into SDL.

I understand, I assumed the slippery slope would be a problem (which
is why I suggested, as I thought multiple windows had already put us
down the slope.) Writing this code is not all that hard, but I’d
assume if I wrote OS X and win32 code (and stubs for other things) it
wouldn’t be accepted into the trunk as it’s a philosophical reason,
correct? If I decide to do it, I’d just write it outside (as I
wouldn’t have to deal with re-merging any SDL code), but if there was
a possibility, I might think about contributing the code.

[>] BrianOn Dec 8, 2008, at 4:39 PM, sdl-request at lists.libsdl.org wrote:

4

There is a lot of history behind the decision to add multiple window
support to SDL. One of the serious objections to doing it at all is
that supporting multiple windows seems to be a slippery slope leading
to supplying an entire GUI. So, it was decided to provide the minimum
needed to create a GUI without actually adding a GUI to SDL. So, in
SDL you have the ability to create multiple overlapping windows. You
can use those windows any way you like, including using them for
menus. But, SDL does not, and is not likely to ever, provide a menu
system in the core of SDL.

Feel free to write any sort of menu code you like and to share it as
you like, but do not expect to see menu support built into SDL.

I understand, I assumed the slippery slope would be a problem (which is why
I suggested, as I thought multiple windows had already put us down the
slope.) Writing this code is not all that hard, but I’d assume if I wrote
OS X and win32 code (and stubs for other things) it wouldn’t be accepted
into the trunk as it’s a philosophical reason, correct?

I do not decide what goes in the trunk and what doesn’t. Sam does.
OTOH, a nice menu system written entirely in SDL 1.3 would be a very
nice thing to have as an add on library.

Bob Pendleton

If I decide to doOn Mon, Dec 8, 2008 at 6:11 PM, Brian Barnes wrote:

On Dec 8, 2008, at 4:39 PM, sdl-request at lists.libsdl.org wrote:
it, I’d just write it outside (as I wouldn’t have to deal with re-merging
any SDL code), but if there was a possibility, I might think about
contributing the code.

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

±-------------------------------------+

5

If SDL 1.3 were to include a menu API, a “pure SDL” implementation
would have to be available to drive the menus when the user is
running on a platform that does not provide the menu for you. So I’d
say that’s the first step.On Tue, Dec 9, 2008 at 11:28 AM, Bob Pendleton wrote:

OTOH, a nice menu system written entirely in SDL 1.3 would be a very
nice thing to have as an add on library.

–
http://codebad.com/

6

If SDL 1.3 were to include a menu API, a “pure SDL” implementation
would have to be available to drive the menus when the user is
running on a platform that does not provide the menu for you. So I’d
say that’s the first step.

And what about systems that do have one? How well do SDL-controlled
blitting surfaces work with menu rectangles drawn over the top of them
by a window manager? I’ve seen things like that leave "dirty rectangles"
over DirectX windows that don’t get updated for a noticeable fraction of
a second after the menu’s gone, or sometimes even longer.>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] SDL 1.3 and Menus

7

If SDL 1.3 were to include a menu API, a “pure SDL” implementation
would have to be available to drive the menus when the user is
running on a platform that does not provide the menu for you. So I’d
say that’s the first step.

And what about systems that do have one? How well do SDL-controlled
blitting surfaces work with menu rectangles drawn over the top of them
by a window manager? I’ve seen things like that leave "dirty rectangles"
over DirectX windows that don’t get updated for a noticeable fraction of
a second after the menu’s gone, or sometimes even longer.

It would be interesting to know what exactly causes those rectangles
to appear. But I wasn’t at all suggesting that SDL would provide menus
that can “pop out” of the SDL window. I was only arguing that while it
might be in the spirit of SDL to provide a menu API, it strikes me as
being outside the scope of SDL to start provide its own menu
implementation. Thus if one wanted to add a menu API to SDL, they
would be forced to choose between disabling menu support when the user
is not using one of a few specific windowing environments, and having
to provide SDL with a menu implementation of its own.On Tue, Dec 9, 2008 at 1:07 PM, Mason Wheeler wrote:

From: Donny Viszneki <@Donny_Viszneki>
Subject: Re: [SDL] SDL 1.3 and Menus

–
http://codebad.com/

8

Hi all,

This is only to bring my personal opinion about the idea of Menus in SDL.
Since the beginning it is clear that it is a “Simple” direct media layer. To my mind, it means both simplicity of usage, the API is quite straightforward (I don’t want to revive past discussions about changes on the SDL API), and a limited function set. The philosophy is more to bring about a stable core, and create add on libraries appart.
Indeed, it’d be quite annoying to impose, for instance, a specific widget system on SDL.
Also, if I take the case of SDL_image, maybe the most used SDL “add-on”, although it is a very quality library, if one wants to read only bitmaps so why imposing all the decoding functions in the core of SDL ?
So, to conclude, there’re libraries having a “all in one” philosophy like Allegro, with a built-in GUI system, and a lot of built-in stuff. I’m not condemning this choice, just highlighting the fact that, until now (I dont know what’s planned for the next major), it is not the philosophy of SDL to be a “all in one” library.

I’m interested in other’s opinion about that. I hope I’m not out of topic ! :smiley:

Regards,
Julien.

9

SDL. Since the beginning it is clear that it is a “Simple” direct
media layer. To my mind, it means both simplicity of usage, the API
[…]
with a built-in GUI system, and a lot of built-in stuff. I’m not
condemning this choice, just highlighting the fact that, until now (I
dont know what’s planned for the next major), it is not the
philosophy of SDL to be a “all in one” library.

I agree. SDL is wonderful when you need to draw all your stuff in a
single window. The interface is really simple and straightforward. I
personally believe that SDL is just where it should be. It does not
impose any GUI model on you but provides the right amount of
abstraction so that you can think in graphics primitives that are
common to every graphics intensive application.

The model of providing basic functionality and leaving the more complex
stuff to additional libraries is also very nice. You need simple sound?
SDL gives you that and you can code a simple sound effect in half a
page of C code. If you need music and multiple effects, SDL_mixer is
your friend. Need scalable vector fonts? You can use SDL_ttf. And so on.

I think getting into the GUI business is a very big can full of really
agile worms. A good GUI should look and feel native in any platform,
preferably providing the same API regardless of the host system.
The only one I know of that is more or less along those lines is
wxWidgets (mind you, I’m no GUI expert).
Now the SDL API documentation is maybe 80 pages; you read about 30
before you can whack together your first ‘bouncy ball follows the
mouse’ program in a few hours. For wxWidgets you first buy the
(otherwise excellent) 700 page wxWorks book to get your gentle
introduction and it takes a couple of hundred pages before you even
contemplate of anything moving, let alone following the mouse. Then you
dive into the 2000+ pages API documentation for details. (By the way,
AFAIK wx now has and SDLFrame class, in one of your wx windows you can
have an SDL screen surface).

A GUI, by its nature, is all about lots of windows, widgets and all
that, concentrating on graphical representations of common interface
elements such as buttons, sliders, packing boxes and, well, menus,
with hierarchies, automatic sizing, placements and alike. SDL is a
DirectMedia Layer abstraction, the opposite approach. A GUI sits
between your program and the user - you don’t really care what
exactly the user sees (in case of wxWidgets it all depends on what
system it’s running on) as long as his actions are presented to you in a
consistent and sufficiently abstract level. With SDL you want to
control, down to the last pixel, what the user sees, want to know what
he does with mouse down to a fraction of a millimetre, want to know
the state of every single key on the keyboard. What you want to be
abstracted is the underlying hardware and its low level OS interface.
You don’t want to know if it’s a video chip or X server is reading your
video memory, but you want to deal with that video memory not as an
abstract canvas with a graphics context but as a bunch of bytes
representing pixels.

Sorry for being long-winded but I think SDL found the abstraction level
that was very useful for a whole class of applications (most prominently
games). It has its limitations but it is lightweight yet powerful, very
well supported on a lot of platforms, platform independent (since it
represents the concept of a single rectangular raster graphics surface,
common to every platform). It is not a GUI, it does not pretend that
it is and it indeed should not be. It would be a really sad thing if it
became a victim of feature creep, as so many FOSS projects did.

Create an SDL_GUI by all means, as a separate library. Make it so that
it looks like a Windows menu and widget system on Windows, OS X on a Mac
and GTK or QT or Motif on Linux, BSD et al. Would love it, really. But
please do not put it into the core SDL library. Let that be what it is,
a Simple DirectMedia Layer.

Zoltan

10

The idea to create a quite “standard” SDL GUI library is something that I am personnally looking for. Something with the same quality as SDL_image, SDL_ttf, SDL_mixer.
I hope some people will have the time, skills and interest in doing such a library.
This email to say that nobody is against a GUI lib, on the contrary. Don’t take the last emails as a negative judgement on the idea you proposed on this list, which is indeed a very good idea. Only the modalities are discussed.

Cheers
Julien

11

[…]
Don’t take the last
emails as a negative judgement on the idea you proposed on this list,
which is indeed a very good idea. Only the modalities are discussed.

Sorry if I sounded as opposing an SDL GUI package.

On the contrary, I’d love it. All I am saying that it should be a
separate library on top of the core SDL library and not part of the
basic SDL library itself.

Zoltan

12

Why does everything I post to any list always start a big discussion? :slight_smile:

I think you guys are mis-understanding my suggestion; if you look
through the code of SDL 1.3, there’s a number of items for window
attributes; for instance, can it minimize, what’s the minimize icon, can
it maximize, does it have X or Y. While I’m an OS X guy, I always
thought of menus as attributes of a window, therefore, it fits within
the general scheme of things. It’s another attribute, like setting a
icon for a window.

Therefore, what is actually being supported is just another attribute of
a window. While there are some systems that SDL will run on that don’t
support menus, there are also systems that won’t support multiple
windows … this is not a reason for exclusion – the targets you’ll see
the most – OS X, win32, and linux, will have that support.

So, basically, I’m not proposing anything approaching an in-window GUI,
I believe that’s outside the scope of “core” SDL, as most everybody
else. What I’m proposing is just another window attribute. The other
reason to put it in core is it would tie in nicely with the event system.

Something simple:

bool SDL_HasMenuSupport(void);
void SDL_ClearWindowMenus(SDL_WindowID windowID);
void SDL_AddWindowMenu(SDL_WindowID windowID,cosnt char *title,const
char *items); // where items = “item 1\nitem 2\tF5\nitem 3”

new cosntants

SDL_WINDOW_MENU // for window creation
SDL_EVENT_MENU_ITEM // for events

People would have to know their deployment well enough to understand the
menu differences between OS X and most other systems, i.e., it would
ignore the windowID and effect the menubar itself. This is up to the
programmer to care about the platforms he’d want to deploy to.

[>] Brian

13

Sorry for the misunderstanding, the idea is receivable, to my mind. Being a Mac OS X user, I cannot ignore that each mac application has a menu attached to it. I don’t see how it could fit in a windows system anyway …

Cheers
Julien

— En date de?: Mer 10.12.08, Brian Barnes a ?crit?:de: Brian Barnes
Objet: Re: [SDL] SDL 1.3 and Menus
?: sdl at lists.libsdl.org
Date: Mercredi 10 D?cembre 2008, 15h40

Why does everything I post to any list always start a big discussion? :slight_smile:

I think you guys are mis-understanding my suggestion; if you look through the
code of SDL 1.3, there’s a number of items for window attributes; for
instance, can it minimize, what’s the minimize icon, can it maximize, does
it have X or Y. While I’m an OS X guy, I always thought of menus as
attributes of a window, therefore, it fits within the general scheme of things.
It’s another attribute, like setting a icon for a window.

Therefore, what is actually being supported is just another attribute of a
window. While there are some systems that SDL will run on that don’t
support menus, there are also systems that won’t support multiple windows
… this is not a reason for exclusion – the targets you’ll see the most –
OS X, win32, and linux, will have that support.

So, basically, I’m not proposing anything approaching an in-window GUI, I
believe that’s outside the scope of “core” SDL, as most everybody
else. What I’m proposing is just another window attribute. The other
reason to put it in core is it would tie in nicely with the event system.

Something simple:

bool SDL_HasMenuSupport(void);
void SDL_ClearWindowMenus(SDL_WindowID windowID);
void SDL_AddWindowMenu(SDL_WindowID windowID,cosnt char *title,const char
*items); // where items = “item 1\nitem 2\tF5\nitem 3”

new cosntants

SDL_WINDOW_MENU // for window creation
SDL_EVENT_MENU_ITEM // for events

People would have to know their deployment well enough to understand the menu
differences between OS X and most other systems, i.e., it would ignore the
windowID and effect the menubar itself. This is up to the programmer to care
about the platforms he’d want to deploy to.

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

14

I think you are pretty of like mind to most people here with some twists here and some six of one and half of a dozen there. The libs at the SDL website are pretty good and at least one of the is made in part by Sam (SDL Sam). I’m happy to take what they did and change it to suit my app and make it my own. The libs cover so much on so many topics that I for one don’t even see the point of making the focus of SDL so broad as to include those things in SDL proper.

---- julien CLEMENT wrote:=============
Hi all,

This is only to bring my personal opinion about the idea of Menus in SDL.
Since the beginning it is clear that it is a “Simple” direct media layer. To my mind, it means both simplicity of usage, the API is quite straightforward (I don’t want to revive past discussions about changes on the SDL API), and a limited function set. The philosophy is more to bring about a stable core, and create add on libraries appart.
Indeed, it’d be quite annoying to impose, for instance, a specific widget system on SDL.
Also, if I take the case of SDL_image, maybe the most used SDL “add-on”, although it is a very quality library, if one wants to read only bitmaps so why imposing all the decoding functions in the core of SDL ?
So, to conclude, there’re libraries having a “all in one” philosophy like Allegro, with a built-in GUI system, and a lot of built-in stuff. I’m not condemning this choice, just highlighting the fact that, until now (I dont know what’s planned for the next major), it is not the philosophy of SDL to be a “all in one” library.

I’m interested in other’s opinion about that. I hope I’m not out of topic ! :smiley:

Regards,
Julien.

15

;

I think you are pretty of like mind to most people here with some twists
here and some six of one and half of a dozen there. The libs at the SDL
website are pretty good and at least one of the is made in part by Sam (SDL
Sam). I’m happy to take what they did and change it to suit my app and make
it my own. The libs cover so much on so many topics that I for one don’t
even see the point of making the focus of SDL so broad as to include those
things in SDL proper.

I’d love to get my hands on the SDL_Sam lib - where can I download it? :wink:

---- julien CLEMENT wrote:

=============
Hi all,

This is only to bring my personal opinion about the idea of Menus in SDL.
Since the beginning it is clear that it is a “Simple” direct media layer.
To my mind, it means both simplicity of usage, the API is quite
straightforward (I don’t want to revive past discussions about changes on
the SDL API), and a limited function set. The philosophy is more to bring
about a stable core, and create add on libraries appart.
Indeed, it’d be quite annoying to impose, for instance, a specific widget
system on SDL.
Also, if I take the case of SDL_image, maybe the most used SDL “add-on”,
although it is a very quality library, if one wants to read only bitmaps
so why imposing all the decoding functions in the core of SDL ?
So, to conclude, there’re libraries having a “all in one” philosophy like
Allegro, with a built-in GUI system, and a lot of built-in stuff. I’m not
condemning this choice, just highlighting the fact that, until now (I dont
know what’s planned for the next major), it is not the philosophy of SDL
to be a “all in one” library.

I’m interested in other’s opinion about that. I hope I’m not out of topic
! :smiley:

Regards,
Julien.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

----- Original Message -----
From: necronology@cox.net (necron)
To: "A list for developers using the SDL library. (includes SDL-announce)"
Sent: Wednesday, December 10, 2008 3:27 PM
Subject: Re: [SDL] SDL 1.3 and Menus

16

Sounds exciting. It must make MMORPGs really easy.

Jonny DOn Wed, Dec 10, 2008 at 7:57 PM, David Olsen wrote:

----- Original Message ----- From:
To: “A list for developers using the SDL library. (includes SDL-announce)”
;
Sent: Wednesday, December 10, 2008 3:27 PM
Subject: Re: [SDL] SDL 1.3 and Menus

I think you are pretty of like mind to most people here with some twists

here and some six of one and half of a dozen there. The libs at the SDL
website are pretty good and at least one of the is made in part by Sam (SDL
Sam). I’m happy to take what they did and change it to suit my app and make
it my own. The libs cover so much on so many topics that I for one don’t
even see the point of making the focus of SDL so broad as to include those
things in SDL proper.

I’d love to get my hands on the SDL_Sam lib - where can I download it? :wink:

---- julien CLEMENT wrote:

=============
Hi all,

This is only to bring my personal opinion about the idea of Menus in SDL.
Since the beginning it is clear that it is a “Simple” direct media layer.
To my mind, it means both simplicity of usage, the API is quite
straightforward (I don’t want to revive past discussions about changes on
the SDL API), and a limited function set. The philosophy is more to bring
about a stable core, and create add on libraries appart.
Indeed, it’d be quite annoying to impose, for instance, a specific widget
system on SDL.
Also, if I take the case of SDL_image, maybe the most used SDL “add-on”,
although it is a very quality library, if one wants to read only bitmaps so
why imposing all the decoding functions in the core of SDL ?
So, to conclude, there’re libraries having a “all in one” philosophy like
Allegro, with a built-in GUI system, and a lot of built-in stuff. I’m not
condemning this choice, just highlighting the fact that, until now (I dont
know what’s planned for the next major), it is not the philosophy of SDL to
be a “all in one” library.

I’m interested in other’s opinion about that. I hope I’m not out of topic
! :smiley:

Regards,
Julien.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

17

Helz Yeah. SDL makes any app easy compared to not having it. Don’t forget to check out the libs and books listed at the SDL website too.

---- Jonathan Dearborn wrote:=============
Sounds exciting. It must make MMORPGs really easy.

Jonny D

On Wed, Dec 10, 2008 at 7:57 PM, David Olsen wrote:

----- Original Message ----- From: <@necron>
To: “A list for developers using the SDL library. (includes SDL-announce)”
;
Sent: Wednesday, December 10, 2008 3:27 PM
Subject: Re: [SDL] SDL 1.3 and Menus

I think you are pretty of like mind to most people here with some twists

here and some six of one and half of a dozen there. The libs at the SDL
website are pretty good and at least one of the is made in part by Sam (SDL
Sam). I’m happy to take what they did and change it to suit my app and make
it my own. The libs cover so much on so many topics that I for one don’t
even see the point of making the focus of SDL so broad as to include those
things in SDL proper.

I’d love to get my hands on the SDL_Sam lib - where can I download it? :wink:

---- julien CLEMENT wrote:

=============
Hi all,

This is only to bring my personal opinion about the idea of Menus in SDL.
Since the beginning it is clear that it is a “Simple” direct media layer.
To my mind, it means both simplicity of usage, the API is quite
straightforward (I don’t want to revive past discussions about changes on
the SDL API), and a limited function set. The philosophy is more to bring
about a stable core, and create add on libraries appart.
Indeed, it’d be quite annoying to impose, for instance, a specific widget
system on SDL.
Also, if I take the case of SDL_image, maybe the most used SDL “add-on”,
although it is a very quality library, if one wants to read only bitmaps so
why imposing all the decoding functions in the core of SDL ?
So, to conclude, there’re libraries having a “all in one” philosophy like
Allegro, with a built-in GUI system, and a lot of built-in stuff. I’m not
condemning this choice, just highlighting the fact that, until now (I dont
know what’s planned for the next major), it is not the philosophy of SDL to
be a “all in one” library.

I’m interested in other’s opinion about that. I hope I’m not out of topic
! :smiley:

Regards,
Julien.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

18

Why does everything I post to any list always start a big discussion? :slight_smile:

I think you guys are mis-understanding my suggestion; if you look through
the code of SDL 1.3, there’s a number of items for window attributes; for
instance, can it minimize, what’s the minimize icon, can it maximize, does
it have X or Y. While I’m an OS X guy, I always thought of menus as
attributes of a window, therefore, it fits within the general scheme of
things. It’s another attribute, like setting a icon for a window.

Start with a false premise end with a false conclusion :slight_smile:

Menus are most definitely not an attribute of a window. That is an
assumption that was made by just about everyone 20+ years ago and it
turned out to be wrong. Menus are their own thing. They are windows in
their own right. When you start looking at any kind of interesting GUI
you start finding that menus need to be able to be aggregated, moved
around, they may need to be ripped (by the user) from one window to
another, they may need to float of to the side or be docked in their
own containing windows. You might not even know what windows will be
available in a window until you have queried the objects withing the
window. Hey, that big blue dragon has his own menu, but only when it
is on the screen and the contents of the menu change depending on how
long it has been since he ate a virgin…

Menus an attribute of windows? No…

Bob PendletonOn Wed, Dec 10, 2008 at 8:40 AM, Brian Barnes wrote:

Therefore, what is actually being supported is just another attribute of a
window. While there are some systems that SDL will run on that don’t
support menus, there are also systems that won’t support multiple windows
… this is not a reason for exclusion – the targets you’ll see the most –
OS X, win32, and linux, will have that support.

So, basically, I’m not proposing anything approaching an in-window GUI, I
believe that’s outside the scope of “core” SDL, as most everybody else.
What I’m proposing is just another window attribute. The other reason to
put it in core is it would tie in nicely with the event system.

Something simple:

bool SDL_HasMenuSupport(void);
void SDL_ClearWindowMenus(SDL_WindowID windowID);
void SDL_AddWindowMenu(SDL_WindowID windowID,cosnt char *title,const char
*items); // where items = “item 1\nitem 2\tF5\nitem 3”

new cosntants

SDL_WINDOW_MENU // for window creation
SDL_EVENT_MENU_ITEM // for events

People would have to know their deployment well enough to understand the
menu differences between OS X and most other systems, i.e., it would ignore
the windowID and effect the menubar itself. This is up to the programmer to
care about the platforms he’d want to deploy to.

[>] Brian

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–

±-------------------------------------+

19

Bob Pendleton wrote:

Start with a false premise end with a false conclusion :-)

Actually, no. The problem is that you are thinking code wise, not user-wise, and that is the biggest (IMHO) problem with open source software. You’re also having a problem with variations on the 90/10 rules, getting caught in minutia and missing the big picture.

Menus are most definitely *not* an attribute of a window. That is an
assumption that was made by just about everyone 20+ years ago and it
turned out to be wrong. Menus are their own thing. They are windows in
their own right. When you start looking at any kind of interesting GUI
you start finding that menus need to be able to be aggregated, moved
around, they may need to be ripped (by the user) from one window to
another, they may need to float of to the side or be docked in their
own containing windows. You might not even know what windows will be
available in a window until you have queried the objects withing the
window. Hey, that big blue dragon has his *own* menu, but only when it
is on the screen and the contents of the menu change depending on how
long it has been since he ate a virgin....

Menus an attribute of windows? No......

Open up any of your programs – 99% of the users will have their menus
either docked always at the top (OS X) or always at the top of a window
(unless it’s the new fangled toolbar menus, which are just fancy
menus.) To them – and to most users – menus are parts of a window.

It’s you guys baby, I’d be more than happy to submit OS X and Windows
code when I got around to trying it, and you guys decisions. But I
think pulling out an example that, if even a real program, would be less
than 1% of the usage of this doesn’t really make a case :slight_smile:

If you need something so special, then it’s a edge case and you’ll have
to handle it yourself. If you want the old regular menus, then that
would be something the core could provide, though I doubt I’m getting
this :slight_smile:

[>] Brian

20

Brian Barnes wrote:

Bob Pendleton wrote:

Start with a false premise end with a false conclusion :-)

Actually, no. The problem is that you are thinking code wise, not
user-wise, and that is the biggest (IMHO) problem with open source
software. You’re also having a problem with variations on the 90/10
rules, getting caught in minutia and missing the big picture.

I think I disagree. Most programs I see are written by thinking
code-wise and not user-wise. Once I had to write the user interface for
a digital audio editing hardware (not a PC, an app. oriented spec HW
with its own limited size LCD and custom keys and things). I wrote it
thinking code-wise, with cascading menus and all that, neat,
hierarchical and pretty elegant, from a programming point of view.

The customer (professional audio engineers in the movie industry) said
it was a piece or crap. Then during long negotiations they tought me
a few basic rules:

  • Modal interface elements are to be used under only extremely special
    circumstances. Otherwise every (G)UI item should be subservient to
    you and if in the middle of a dialog it occurs to you that you want to
    go to do something else and come back later, you should be able to.

  • No matter how unintuitive (to you) and bizzar or perverse is to do an
    operation at a given state of the system, if it is at all possible,
    you must allow it. This including jumping from a menu/system state
    to a completely unrelated menu/state, with as few interactions as
    possible.

  • Undo should be implemented lisp-continuation like, if you go to state
    A then jump to B then C, come back to B then A then over to D you
    still should be able to get C back.

At the end they were happy with it but it required me to forget about
the conventional menu hierarchy. It is not menus and submenus, it is a
huge graph of possible states and possible actions and at any state you
present the user all transition possibilities, groupped by some way
that may group the same actions completely differently depending on
where you are. A helluva lot more coding than a hierarchical menu
system, but loads more user satisfaction too.

Most programs are not written like that (including, sadly, most of my
own). We, and the users, are trained to use the usual menu structures,
got used to modal dialogs, accept that your application is often a tree
and to go from A to B you may have to go up and then descend again and
so on. Apple is much better than the rest, but it’s still the same.

So I think Bob is right, menus should be independent interface elements
presenting choice tothe user, not part of an application window.
However, I find it rather unlikely that the mentality of the entire SW
and GUI industry would change. The audio guys could spit on my code
because they paid for it and they had the power as well as the egos to
demand to get what they wanted. Most users get what they are given,
take it or live it.

It is more of a phylosophical issue than practical, I think.

Zoltan