Edward Cullen 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 strongly disagree. It is *missing* the big picture that brings up
exactly the kind of misconception that you have.
I see I’m not going to win any argument here. All I’m asking for is a conduit into how OSes handle menus now, which is usually attached to windows or the top of the screen. This is what 99% of people think of when they think of menus. You guys can come up with as many big picture ideas as you want, and they might all be valid, but they aren’t exactly what users of OS X and Windows expect.
>
> 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.
This is because of the corruption of the word window. Originally, a
'window' was simply a self-contained drawing region. Both X11 and
Windows draw everything into a window; a menu *is* a window in and of
itself. You may argue that this is an implementation detail, but
step-back: think about this: "How do I define a system that can allow
arbitrary composition with any number of base elements?"
If you think about it long enough, you will end up with what is, in
X11 and Windows parlance, a window.
CWnd::SetMenu. Windows obviously understands the concept of menus being part of a window. It might be implemented (as you noted) as a separate window, but it’s what the end user sees that matters.
The problem is to make this concept work, you have to IGNORE OS X, which is what you do below by saying it lacks flexibility. Maybe it does, but if SDL is supposed to be cross platform, then this is something you can’t ignore.
> 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 :)
>
> 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 :)
What if I wan't to have my own menu system with funky graphics or
chunky text or pictures for say, children, or I dunno... a game? Why
should I be forced to conform to a general-case structure that simply
doesn't suit my needs?
As far as I can tell, OS X doesn't allow arbitrary window composition.
That REALLY sucks; it massively reduces flexibility to define your own
solutions. This is the price you pay for a Macs 'ease of use'. It
would seem that the problem you have is actually that you're
developing on a Mac; if you were developing under X11 or even, heaven
forbid, Windows, you would know that you can create an application
window, then create an SDL surface as a child to that window.
Finally, it is interesting that you make the assertion that 'most'
people will want a menu for their SDL apps. Call me old fashioned, but
'most' SDL apps are games, and most games seem to run full-screen
and/or have simple menus (i.e. a simple up/down, start, options, quit
type menu). Therefore, 'most' SDL apps don't want/need OS-style menus.
I would argue that, actually, *yours* is the corner case!
Again, you can’t ignore OSes that you think “don’t do it right.” SDL would, be definition, have to handle that kind of stuff. And, I’m not asking for regular menus in game, that would be silly. If you have funky menus, then do it like you do it now. What I’m thinking is for these uses:
-
simple cross-platform utility apps for games
-
if you game goes into windowed mode for some reason, use the menus to launch debug information or additional things
P.S. Try ParaGUI.
I have my own GUI routines, that’s not what I’m looking for. I’m not
looking for a IN GAME GUI, not at all. I’m looking for an easy way to
make cross-platform utility apps for my application, with minimal GUI.
i.e., very non-game type apps. I think you guys are assuming I’m trying
to make in-game GUIs easy, that’s not the case. Having a menu in a SDL
app is probably something that would only happen at certain times, in
certain apps.
Again, I’m not going to win this one 
[>] Brian