GUI with KDE

[David_Olofson]

David Olofson wrote:

Absolutely - but note that I’d of course ditch my custom version and
upgrade to SDL 1.3 as soon as that’s usable. (That’s one of the
strongest arguments against doing this hack - it’s just temporary
anyway, and won’t provide anything that SDL 1.3 is supposed to
have, AFAIK.)

Did you mean ‘that SDL 1.3 is not supposed to have’?

Yep.

The discussion
here makes it sound like nobody really knows what features SDL 1.3
will have and when it will be available.

That’s about it.

Is there another discussion
forum dealing with these questions?

Not that I know of. Is there?

However, there
is a lot of independently useful code and functionality in both
GTK, Qt and software being written to those APIs. So I would add
that extra ‘cruft’ is the price one pays for not reinventing
multiple wheels.

Of course, but I’d draw the line where writing a “wrapper” is more
complicated than reimplementing what you need in a way that fits your
design. It’s still possible to “rip” algorithms here and there, of
course - one of the best things with Free/Open Source.

Not sure what the “wrapper” part refers to here. I’m not talking
about anything that fits my definition of a wrapper.

Well, say it was possible to create child windows in the form of SDL
sub-surfaces, with “advanced clipping”. If you wanted to throw in a
window manager, you could implement it as a “wrapper” for the functions
you’d normally use to deal with the management of child windows, and pass
all relevant events through a function of the window manager, so it can
manage focus, window movement, resizing etc.

The real way, however, would be to allow the window manager to hook into
SDL, so that applications don’t have to explicitly “run” the window
manager - it would automatically add contexts for window borders, render
them, intercept mouse clicks on them and so on. Applications would just
have to be aware that it’s possible that punping the event loop may
result in windows being moved or resized, and that some events may be
translated into WM events.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 11 October 2001 18:51, Josh Stern wrote:

[David_Olofson]

David Olofson wrote:

There may or may not be other issues, but to me the
issues that the MacOS (X) backend(s) would have to be
rewritten/modified, and possibly others, too, means it is a
problematic feat. Not that I say this could not happen (and it
definitly must happen for SDL 1.3/TNG), but it ain’t easy.

In short, the problem is that many targets have basically the same
problem as SDL (no explicit context argument to calls), or use
designs that require all contexts to share one or more objects…?

I suspect that isn’t what Max meant, as it would seem to imply,
for instance, the impossibility of writing any MacX application with
more than one OpenGL window.

I don’t view things like that as SDL issues. If a target can’t handle
multiple OpenGL contexts, what should SDL do about it? Nothing. Just
refuse to open another contexs of that type. The same limits apply to any
application running on that platform.

But I would like to know what the real issue is here.

Well, if it’s an internal SDL design issue, I’m interested. (Although I
might well realize it’s not worth the effort trying to fix it under any
circumstances.)

If it’s the usual problem of some things not being possible on some
platforms, there’s nothing much to do about it anyway. So why worry about
SDL not being able to “fix” it?

Or should SDL drop every feature that isn’t fully supported on all
targets?

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 11 October 2001 18:57, Josh Stern wrote:

On Thursday 11 October 2001 17:44, Max Horn wrote:

[Max_Horn]

At 19:35 Uhr +0200 11.10.2001, David Olofson wrote:

David Olofson wrote:

There may or may not be other issues, but to me the
issues that the MacOS (X) backend(s) would have to be
rewritten/modified, and possibly others, too, means it is a
problematic feat. Not that I say this could not happen (and it
definitly must happen for SDL 1.3/TNG), but it ain’t easy.

In short, the problem is that many targets have basically the same
problem as SDL (no explicit context argument to calls), or use
designs that require all contexts to share one or more objects…?

I suspect that isn’t what Max meant, as it would seem to imply,
for instance, the impossibility of writing any MacX application with
more than one OpenGL window.

I don’t view things like that as SDL issues. If a target can’t handle
multiple OpenGL contexts, what should SDL do about it? Nothing. Just
refuse to open another contexs of that type. The same limits apply to any
application running on that platform.

I think we have a misunderstanding here, David. The limitation in
this case is not in OS X; it is in the OS X backend. And the reason
this limitation exists is due to the way backends have to interface
with SDL. The OS X backend could be rewritten to deal with multiple
windows of course, even with multiple pseudo-drivers, but the current
version doesn’t do it, i mean, why should it?

But I would like to know what the real issue is here.

Well, if it’s an internal SDL design issue, I’m interested. (Although I
might well realize it’s not worth the effort trying to fix it under any
circumstances.)

FYI: SDL polls for system events and translates them to SDL events.
In the case of the OS X target, all events are taken, then we check
if the events pertain to the SDL window, and if yes, hand them to
SDL, otherwise call the default handle. The problem is that if you
wanted to open multiple SDL windows, only the first one would be
served.

There is really no easy way around it with the current SDL
architecture. But again, not because OS X is faulty, but because the
SDL<->backend interface is limited, and this influences the way
backends are written.

If it’s the usual problem of some things not being possible on some
platforms, there’s nothing much to do about it anyway. So why worry about
SDL not being able to “fix” it?

Or should SDL drop every feature that isn’t fully supported on all
targets?

I never ever said this. I just countered your statment that backends
won’t have to be changed, and that one could open multiple contexts.
Not so!

Fork is not a good solution either, for various reasons:

1. It is not really portable
2. Communications between program parts is harder
3. On OS X, (without having actually tried this), this fork must be
   done very early in the programm, in fact, it must be done on the
   level of SDLMain. And if you do it, then each of your app instances
   would have its own menu bar and its own entry in the task list. Not
   good.

Max>On Thursday 11 October 2001 18:57, Josh Stern wrote:

On Thursday 11 October 2001 17:44, Max Horn wrote:
–

---

Max Horn
Software Developer

email: mailto:Max_Horn
phone: (+49) 6151-494890

[Josh_Stern]

Max Horn wrote:

Or should SDL drop every feature that isn’t fully supported on all
targets?

I never ever said this. I just countered your statment that backends
won’t have to be changed, and that one could open multiple contexts.
Not so!

I’m not sure what David said, but it was apparent in my mind that
the backend for every target would have to be changed slightly
to accomodate the proposals we discussed. Your description
of the OS X backed doesn’t make it sound like the kind and
magnitude of the change is significantly different than it would
be for other targets with multiple desktop windows.

Fork is not a good solution either, for various reasons:

1. It is not really portable
2. Communications between program parts is harder
3. On OS X, (without having actually tried this), this fork must be
   done very early in the programm, in fact, it must be done on the
   level of SDLMain. And if you do it, then each of your app instances
   would have its own menu bar and its own entry in the task list. Not
   good.

Also loss of efficiency. X11 has very good reasons for use of
a separate process - network transparency and robustness (
window system doesn’t go down if a client dies), but the
design decision was still criticized for loss of effiency
(this was eventually 95% overcome with first shared memory
between client and server on the same machine and second
special OS mods called DRI on Linux and something else on
SGI). Given how much work was done to get the efficiency
back, people would frown on the use of an additional process
just because a library made funny decisions about what goes
in global variables - or because people want to use the library
for other than its intended purpose, take your pick.

-= Josh

[Josh_Stern]

David Olofson wrote:

Well, say it was possible to create child windows in the form of SDL
sub-surfaces, with “advanced clipping”. If you wanted to throw in a
window manager, you could implement it as a “wrapper” for the functions
you’d normally use to deal with the management of child windows, and pass
all relevant events through a function of the window manager, so it can
manage focus, window movement, resizing etc.

The real way, however, would be to allow the window manager to hook into
SDL, so that applications don’t have to explicitly “run” the window
manager - it would automatically add contexts for window borders, render
them, intercept mouse clicks on them and so on. Applications would just
have to be aware that it’s possible that punping the event loop may
result in windows being moved or resized, and that some events may be
translated into WM events.

Take a look at Qt-X11 and Qt-embedded; they share 95% of their
code, by the part they don’t share is quite differemt; much more so
than Qt-X11 and Qt-Win32. This is because Qt-embedded provides an
entire windowing system in the frame buffer, like what you describe.
That is sometimes desireable for clients without their own windowing
system - though it implies some loss of efficiency there - but it’s never
desirable for targets that already have a window system.

What I have a need for is would be satisfied for the clients that
have a window system by an SDL-like library that
interacts with the window system for top level windows and
manages ‘sub-windows’ of a top level window internally in the
same process. The library would translate real window system
events to events in the intra-process window hierarchy as needed.

-= Josh

[David_Olofson]

At 19:35 Uhr +0200 11.10.2001, David Olofson wrote:

David Olofson wrote:

There may or may not be other issues, but to me the
issues that the MacOS (X) backend(s) would have to be
rewritten/modified, and possibly others, too, means it is a
problematic feat. Not that I say this could not happen (and it
definitly must happen for SDL 1.3/TNG), but it ain’t easy.

In short, the problem is that many targets have basically the
same problem as SDL (no explicit context argument to calls), or
use designs that require all contexts to share one or more
objects…?

I suspect that isn’t what Max meant, as it would seem to imply,
for instance, the impossibility of writing any MacX application
with more than one OpenGL window.

I don’t view things like that as SDL issues. If a target can’t handle
multiple OpenGL contexts, what should SDL do about it? Nothing. Just
refuse to open another contexs of that type. The same limits apply to
any application running on that platform.

I think we have a misunderstanding here, David. The limitation in
this case is not in OS X; it is in the OS X backend. And the reason
this limitation exists is due to the way backends have to interface
with SDL. The OS X backend could be rewritten to deal with multiple
windows of course, even with multiple pseudo-drivers, but the current
version doesn’t do it, i mean, why should it?

Ok; I somehow got the idea that Josh was thinking about OpenGL contexts
and that kind of things in general - which may be limited to a single
context per process in some implementations. (I’d be surprized if that’s
the case with an OS like Mac OS X, though…)

But I would like to know what the real issue is here.

Well, if it’s an internal SDL design issue, I’m interested. (Although
I might well realize it’s not worth the effort trying to fix it under
any circumstances.)

FYI: SDL polls for system events and translates them to SDL events.
In the case of the OS X target, all events are taken, then we check
if the events pertain to the SDL window, and if yes, hand them to
SDL, otherwise call the default handle. The problem is that if you
wanted to open multiple SDL windows, only the first one would be
served.

Hmm… It could me messy to change that in SDL, but other than that, it
sounds like a pretty normal situation. Anyway, how would only the first
window be served if there’s only one, global event queue? (That’s the
very reason why I thought about doing it that way.

[…]

If it’s the usual problem of some things not being possible on some
platforms, there’s nothing much to do about it anyway. So why worry
about SDL not being able to “fix” it?

Or should SDL drop every feature that isn’t fully supported on all
targets?

I never ever said this. I just countered your statment that backends
won’t have to be changed, and that one could open multiple contexts.
Not so!

Fork is not a good solution either, for various reasons:

1. It is not really portable
2. Communications between program parts is harder
3. On OS X, (without having actually tried this), this fork must be
   done very early in the programm, in fact, it must be done on the
   level of SDLMain. And if you do it, then each of your app instances
   would have its own menu bar and its own entry in the task list. Not
   good.

Yeah… And when thinking about it, who would ever get the idea to
fork() GUI applications, and then to expect that to result in anything
but full instances of the application!? (Only to illustrate how strange
the fork() hack really is.

Anyway, don’t worry; I started coding a 2D-on-OpenGL library using the
SDL API yesterday.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 11 October 2001 20:06, Max Horn wrote:

On Thursday 11 October 2001 18:57, Josh Stern wrote:

On Thursday 11 October 2001 17:44, Max Horn wrote:

[David_Olofson]

David Olofson wrote:

Well, say it was possible to create child windows in the form of SDL
sub-surfaces, with “advanced clipping”. If you wanted to throw in a
window manager, you could implement it as a “wrapper” for the
functions you’d normally use to deal with the management of child
windows, and pass all relevant events through a function of the
window manager, so it can manage focus, window movement, resizing
etc.

The real way, however, would be to allow the window manager to hook
into SDL, so that applications don’t have to explicitly “run” the
window manager - it would automatically add contexts for window
borders, render them, intercept mouse clicks on them and so on.
Applications would just have to be aware that it’s possible that
punping the event loop may result in windows being moved or resized,
and that some events may be translated into WM events.

Take a look at Qt-X11 and Qt-embedded; they share 95% of their
code, by the part they don’t share is quite differemt; much more so
than Qt-X11 and Qt-Win32. This is because Qt-embedded provides an
entire windowing system in the frame buffer, like what you describe.
That is sometimes desireable for clients without their own windowing
system - though it implies some loss of efficiency there - but it’s
never desirable for targets that already have a window system.

Actually, I’ve seen exactly this (WM in WM) in many multimedia
applications on Win32, and it can also be seen in various X applications.

(Which is not to say that I think it’s a good idea in general. On the
contrary, a non-standard WM inside another WM is confusing, and Win32
"MDI" style applications just waste screen space, especially on big
screens.)

What I have a need for is would be satisfied for the clients that
have a window system by an SDL-like library that
interacts with the window system for top level windows and
manages ‘sub-windows’ of a top level window internally in the
same process. The library would translate real window system
events to events in the intra-process window hierarchy as needed.

Yes, that was the idea here - the “SDL WM” is a different story.
(Although it may be somewhat related from the API perspective; the idea
that the SDL WM should look like any other WM to the application for
example.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 11 October 2001 21:28, Josh Stern wrote:

[Max_Horn]

At 17:39 Uhr +0200 12.10.2001, David Olofson wrote:
[…]

FYI: SDL polls for system events and translates them to SDL events.
In the case of the OS X target, all events are taken, then we check
if the events pertain to the SDL window, and if yes, hand them to
SDL, otherwise call the default handle. The problem is that if you
wanted to open multiple SDL windows, only the first one would be
served.

Hmm… It could me messy to change that in SDL, but other than that, it
sounds like a pretty normal situation. Anyway, how would only the first
window be served if there’s only one, global event queue? (That’s the
very reason why I thought about doing it that way.

Only the first window is served because the custom event queue we use
only knows about one window, and it intercepts all events for the
first window and handles them; the other window gets no events.
Worse, events into the second window are treated as if they occured
in the first window, which could result in extremly weird behaviour.

[…]

Yeah… And when thinking about it, who would ever get the idea to
fork() GUI applications, and then to expect that to result in anything
but full instances of the application!? (Only to illustrate how strange
the fork() hack really is.

Indeed!

Anyway, don’t worry; I started coding a 2D-on-OpenGL library using the
SDL API yesterday.

Good!

Max–

Max Horn
Software Developer

email: mailto:Max_Horn
phone: (+49) 6151-494890

[J_Grant]

Hello

Thank you for the information

I checked gtksdl,GUILib, libuta, paragui and some others

I am creating a 3D editing style application, so really i just wanted a
file->load etc with some menus and buttons

QT has OpenGL support acording to these 2 docs

http://www.trolltech.com/products/qt/whitepaper/whitepaper-6-3.html

http://www.trolltech.com/products/qt/whitepaper/whitepaper-6-2.html

But I could not find any examples, did not have much time to look.

Most of my code is in SDL, i suspect that if I change to ussing
QT/OpenGL I will not be able to use SDL due to input and mouse control
problems… ?

Ok, thanks in advace for any replys, the last topic was very useful.

Regards

JG

Josh Stern wrote:

Max Horn wrote:

At 8:39 Uhr -0500 11.10.2001, Josh Stern wrote:

Of course GPL license does not mean that something has been
ported to multiple platforms - the two having directly to do with
each other. So far as I know, Gtk is only available for X11 platform.

GTK os also available for Win32, and I think they have a BeOS port
(not sure though). I am one of those crazy guys who are interested in
(and a bit working on) a GTK/Quartz backend (for OS X) but there is
nothing there yet.

Ok, thanks for the update. Also, for completeness in answering the
original poster, he might want to look at WxWindows for cross platform
needs.

Qt is available for X11, Win32, Mac OSX (in beta), and Linux embedded,
but only GPL/free software for X11 and Linux embedded.

Alothough QT is available on these, and GTK on some others, I
wouldn’t use either fro a game. Of course, the original request
didn’t state for what purpose this was needed, I just speak in
general.

Hypermedia Research Centre
Sanyo R&D Headquarters, Tokyo
http://www.sanyo.co.jp/R_and_D/3dm/
Tel: +81 (0)3 5803 3566
Fax: +81 (0)3 5803 3640
E-post: jg at tk.hm.rd.sanyo.co.jp
Please use open standard file formats for attachments

[Scott_Jerry_Lawrence]

On a similar note, I’m working on some pure SDL gui widgets and controls
for my paint program (and a game) There are some screenshots on the web
page for i:

http://www.cis.rit.edu/~jerry/Software/4p

next on my implementation list for it is text input, multiline text box
widgets, along with a file requestor dialog box.

-j–
Scott “Jerry” Lawrence
@Scott_Jerry_Lawrence

For all of your Cheese Weasel needs… http://www.cheeseweasel.com