GUI with KDE

SDL Development
1

Hello

For my SDL application I am interested in linking in a KDE GUI, I have
read that QT is available under GPL now so this should mean its
compatible with other non-unix platforms I think?

Could someone direct me to an SDL example with KDE gui, I have not been
able to find one so far.

Regards

JG

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
Email: jg at tk.hm.rd.sanyo.co.jp
Please use open standard file formats for attachments

2

Why not use Gtk, why do you think that Gtk is not comparable to KDE.
by the way check http://www.libsdl.org/libraries.html,
you will find a lot of gui that as good as KDE
whitout being difficult to learn nor beeing massive on the disc.

“J Grant” a ?crit dans le message news:
mailman.1002781384.7913.sdl at libsdl.org…> Hello

For my SDL application I am interested in linking in a KDE GUI, I have
read that QT is available under GPL now so this should mean its
compatible with other non-unix platforms I think?

Could someone direct me to an SDL example with KDE gui, I have not been
able to find one so far.

Regards

JG

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
Email: jg at tk.hm.rd.sanyo.co.jp
Please use open standard file formats for attachments

3

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.
Qt is available for X11, Win32, Mac OSX (in beta), and Linux embedded,
but only GPL/free software for X11 and Linux embedded. As I indicated
in the recent “Multiple Top Level Window” thread, I am interested in
the possibility of using SDL as the target OS dependency level for
creating a free cross platform version of Qt, which would be about
halfway to a cross platform KDE. In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

OTOH, creating a single SDL window within a Qt app is possible,
and apparently someone has created a Qt widget for this. However
I don’t have the link handy.On Thursday 11 October 2001 02:19, you wrote:

Why not use Gtk, why do you think that Gtk is not comparable to KDE.
by the way check http://www.libsdl.org/libraries.html,
you will find a lot of gui that as good as KDE
whitout being difficult to learn nor beeing massive on the disc.

“J Grant” a ?crit dans le message news:
mailman.1002781384.7913.sdl at libsdl.org…

Hello

For my SDL application I am interested in linking in a KDE GUI, I have
read that QT is available under GPL now so this should mean its
compatible with other non-unix platforms I think?

Could someone direct me to an SDL example with KDE gui, I have not been
able to find one so far.

Regards

JG

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
Email: jg at tk.hm.rd.sanyo.co.jp
Please use open standard file formats for attachments

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

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.

Just for completness, I do not want to prove a point or something,
just make sure the situation is stated accuratly :slight_smile:

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.
Something different are level editors etc. which don’t have to be as portable.

As I indicated

in the recent “Multiple Top Level Window” thread, I am interested in
the possibility of using SDL as the target OS dependency level for
creating a free cross platform version of Qt, which would be about
halfway to a cross platform KDE.

Not really. Even though we have QT on MacOS X (even before the OS X
port we had it using XFree86 on OS X), KDE is a complete different
thing - they are currently tied very closely to the ELF binary format
(and similiar ones), relaying on features in it that are just not
present on OS X (not because OS X’s linking scheme is worse, but
because it is very very different).

Until that is fixed, no KDE over here.

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

This is not something I would even attempt with SDL 1.2.x - it simply
was not made for this.

OTOH, creating a single SDL window within a Qt app is possible,
and apparently someone has created a Qt widget for this. However
I don’t have the link handy.

Max–

Max Horn
Software Developer

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

5

Not if you use SDL as your one and only displaytarget (in fullscreen).
All windows can be rendered into the SDL screen surface.

AlexAm Don, 2001-10-11 um 15.39 schrieb Josh Stern:

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.
Qt is available for X11, Win32, Mac OSX (in beta), and Linux embedded,
but only GPL/free software for X11 and Linux embedded. As I indicated
in the recent “Multiple Top Level Window” thread, I am interested in
the possibility of using SDL as the target OS dependency level for
creating a free cross platform version of Qt, which would be about
halfway to a cross platform KDE.

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

6

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.

Action games tend to consume all of the users attention; there is
less relevance to multiple windows a need to guard against loss
of pointer/keyboard focus, etc. Some kind of a thought/puzzle
game would be a different story, with different conclusions, I
think (aside: my ultimate purpose at the moment is cross-platform
multimedia with Java as the ‘glue’ language - the object
oriented Java bindings that the KDE project has created
for Qt are rather good - much better than Swing in many
ways, and also somewhat more natural than Qt in C++
due to QObject/moc stuff working out more transparently
in Java).

As I indicated

in the recent “Multiple Top Level Window” thread, I am interested in
the possibility of using SDL as the target OS dependency level for
creating a free cross platform version of Qt, which would be about
halfway to a cross platform KDE.

Not really. Even though we have QT on MacOS X (even before the OS X
port we had it using XFree86 on OS X), KDE is a complete different
thing - they are currently tied very closely to the ELF binary format
(and similiar ones), relaying on features in it that are just not
present on OS X (not because OS X’s linking scheme is worse, but
because it is very very different).

Fair enough. What I really meant was something like halfway to
being able to build a cross platform app using important KDE
widgets like the html engine in Konqueror, etc.

Until that is fixed, no KDE over here.

Perhaps some sort of generic COM-ish dynamic linking model,
like the one used in Java JNI, could be substituted.

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

This is not something I would even attempt with SDL 1.2.x - it simply
was not made for this.

If you have any technical criticisms regarding the discussion by
David Olofson and myself I would appreciate it.

-= Josh

7

Alex wrote:> Am Don, 2001-10-11 um 15.39 schrieb Josh Stern:

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.
Qt is available for X11, Win32, Mac OSX (in beta), and Linux embedded,
but only GPL/free software for X11 and Linux embedded. As I indicated
in the recent “Multiple Top Level Window” thread, I am interested in
the possibility of using SDL as the target OS dependency level for
creating a free cross platform version of Qt, which would be about
halfway to a cross platform KDE.

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

Not if you use SDL as your one and only displaytarget (in fullscreen).
All windows can be rendered into the SDL screen surface.

Right, I’m aware of that. It could either be a single top level window
on a windowing desktop, or it could take over the entire windowing
system in the manner of Qt-embedded. But both those possibilities
are quite constraining from the standpoint of many desktop applications -
consider an email client, for example.

-= Josh

8

[…]

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

This is not something I would even attempt with SDL 1.2.x - it simply
was not made for this.

The only real issues I can see is that

1. the SDL API lacks "context" arguments. (You need explicit
   context switches as for OpenGL in similar situations.)

2. SDL is not thread safe. (Which is also the case with many
   OpenGL implementations, and many other libraries.)

Another issue might be that the ones who have wanted this feature so far
don’t want to/can’t hack it, while the ones that might do that kind of
stuff are convinced that SDL 1.2 can’t do multiple contexts, period.

However, note that the real issue here might well be that I need to
read the code more carefully. :wink:

//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 15:47, Max Horn wrote:

9

At 16:50 Uhr +0200 11.10.2001, David Olofson wrote:

[…]

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed in
the aforementioned thread and the Multiple SDL Contexts thread
today.

This is not something I would even attempt with SDL 1.2.x - it simply
was not made for this.

The only real issues I can see is that

  1. the SDL API lacks “context” arguments. (You need explicit
    context switches as for OpenGL in similar situations.)

  2. SDL is not thread safe. (Which is also the case with many
    OpenGL implementations, and many other libraries.)

Those two are not that simple issues. And I assume your definition of
"real issue" is “issue caused by fundamental things”. It does not
cover, however, real world issues like: no backend provides support
for multiple windows, so they need to be changed all.

Sure, it is possible, but what you end up with it not SDL anymore
but some new thing that is based on SDL.

So I would rather like to see this effort and energy spent on making
a proper new SDL verion (i.e. work on TNG / 1.3) than hacking away at
SDL 1.2 like this. Of course, if you feel like it, nobody will held
you back :slight_smile:

Another issue might be that the ones who have wanted this feature so far
don’t want to/can’t hack it, while the ones that might do that kind of
stuff are convinced that SDL 1.2 can’t do multiple contexts, period.

Well, the current SDL can’t do it. The APIs don’t support it. Period.

Of course, you could add new APIs (and even if you only “modify” old
APIs, the result is essentially a new API). Sure.

However, note that the real issue here might well be that I need to
read the code more carefully. :wink:

=)

Max>On Thursday 11 October 2001 15:47, Max Horn wrote:

Max Horn
Software Developer

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

10

[…]

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as discussed
in the aforementioned thread and the Multiple SDL Contexts thread
today.

Not if you use SDL as your one and only displaytarget (in
fullscreen). All windows can be rendered into the SDL screen surface.

Right, I’m aware of that. It could either be a single top level
window on a windowing desktop, or it could take over the entire
windowing system in the manner of Qt-embedded. But both those
possibilities are quite constraining from the standpoint of many
desktop applications - consider an email client, for example.

That would be a pretty flashy email client, to motivate the use of SDL,
right? :wink:

Seriously though, the reason why I would like to use SDL for a “GUI
toolkit” is that I don’t feel like reimplementing SDL. I need:

* Fast colorkey and alpha rendering.

* Support for accelerated OpenGL. (*NOT* a requirement
  that acelerated OpenGL is available!)

* Keyboard and mouse input with "full control".
  (Access to qualifiers and all that stuff.)

* Loading of various image formats.

* Fullscreen and windowed modes.

* Support for fullscreen-only targets.

* No cruft - I don't want to drag in GTK+, Qt or
  similar, as my toolkit is based on a completely
  different design idea. (As I've said before,
  it's *not* meant for normal applications.)

* Portability accross platforms and targets.

Now, tell me that SDL doesn’t fit the bill…

//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 16:39, Josh Stern wrote:

11

[…]

The only real issues I can see is that

  1. the SDL API lacks “context” arguments. (You need explicit
    context switches as for OpenGL in similar situations.)

  2. SDL is not thread safe. (Which is also the case with many
    OpenGL implementations, and many other libraries.)

Those two are not that simple issues. And I assume your definition of
"real issue" is “issue caused by fundamental things”. It does not
cover, however, real world issues like: no backend provides support
for multiple windows, so they need to be changed all.

The idea is to use “multiple backends”, rather than extending one or more
of them to support multiple windows. The advantage is that you may open
entirely independent contexts, using different backends. (Although that
would require some fiddling with system variables, as it is now. :slight_smile:

Sure, it is possible, but what you end up with it not SDL anymore
but some new thing that is based on SDL.

Well, I don’t think so, but even if that’s the case, I might well do it,
if I really need it before SDL 1.3 is usable. Even if I’d be sort of
wasting my time on a dead-end branch, it beats reimplementing SDL from
scratch, doesn’t it? heh

So I would rather like to see this effort and energy spent on making
a proper new SDL verion (i.e. work on TNG / 1.3) than hacking away at
SDL 1.2 like this.

Of course, that would be much more worthwhile - and unless I manage to
get up to the same speed with the toolkit as I did with Kobo Deluxe, I
probably won’t need it soon enougd to warrant “messing” with 1.2.

Of course, if you feel like it, nobody will held you back :slight_smile:

Yeah, I know; no one cares to keep me from wasting my time! :wink:

Another issue might be that the ones who have wanted this feature so
far don’t want to/can’t hack it, while the ones that might do that
kind of stuff are convinced that SDL 1.2 can’t do multiple contexts,
period.

Well, the current SDL can’t do it. The APIs don’t support it. Period.

Of course, you could add new APIs (and even if you only “modify” old
APIs, the result is essentially a new API). Sure.

Modifying stuff will just break things and cause confusion - the changes
would only be visible in the form of some entirely new calls.

However, note that the real issue here might well be that I need to
read the code more carefully. :wink:

=)

Hmm… You know something I won’t like, don’t you!? :wink:

//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 17:03, Max Horn wrote:

12

At 17:30 Uhr +0200 11.10.2001, David Olofson wrote:

[…]

The only real issues I can see is that

  1. the SDL API lacks “context” arguments. (You need explicit
    context switches as for OpenGL in similar situations.)

  2. SDL is not thread safe. (Which is also the case with many
    OpenGL implementations, and many other libraries.)

Those two are not that simple issues. And I assume your definition of
"real issue" is “issue caused by fundamental things”. It does not
cover, however, real world issues like: no backend provides support
for multiple windows, so they need to be changed all.

The idea is to use “multiple backends”, rather than extending one or more
of them to support multiple windows. The advantage is that you may open
entirely independent contexts, using different backends. (Although that
would require some fiddling with system variables, as it is now. :slight_smile:

I can’t speak for other backends, but for the OS X backend this won’t
work. I think the same holds true for the MacOS backend, though I am
not 100% sure there.

Sure, it is possible, but what you end up with it not SDL anymore
but some new thing that is based on SDL.

Well, I don’t think so, but even if that’s the case, I might well do it,
if I really need it before SDL 1.3 is usable. Even if I’d be sort of
wasting my time on a dead-end branch, it beats reimplementing SDL from
scratch, doesn’t it? heh

Sure.

[…]

Another issue might be that the ones who have wanted this feature so
far don’t want to/can’t hack it, while the ones that might do that
kind of stuff are convinced that SDL 1.2 can’t do multiple contexts,
period.

Well, the current SDL can’t do it. The APIs don’t support it. Period.

Of course, you could add new APIs (and even if you only “modify” old
APIs, the result is essentially a new API). Sure.

Modifying stuff will just break things and cause confusion - the changes
would only be visible in the form of some entirely new calls.

Yeah, I just tried to anticipate possible counter arguments :slight_smile: I
wouldn’t recommend (ab)using old APIs like that.

However, note that the real issue here might well be that I need to
read the code more carefully. :wink:

=)

Hmm… You know something I won’t like, don’t you!? :wink:

Nah, not really. 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.

Max>On Thursday 11 October 2001 17:03, Max Horn wrote:

Max Horn
Software Developer

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

13

David Olofson wrote:

Seriously though, the reason why I would like to use SDL for a “GUI
toolkit” is that I don’t feel like reimplementing SDL. I need:

  • Fast colorkey and alpha rendering.

  • Support for accelerated OpenGL. (NOT a requirement
    that acelerated OpenGL is available!)

  • Keyboard and mouse input with “full control”.
    (Access to qualifiers and all that stuff.)

  • Loading of various image formats.

  • Fullscreen and windowed modes.

  • Support for fullscreen-only targets.

  • No cruft - I don’t want to drag in GTK+, Qt or
    similar, as my toolkit is based on a completely
    different design idea. (As I’ve said before,
    it’s not meant for normal applications.)

  • Portability accross platforms and targets.

Now, tell me that SDL doesn’t fit the bill…

My list would be similar, emphasizing also the sound framework and especially
the fact that these portability aspects are being maintained to a large
extent by independent developers. Losing that would be one of the
major downsides to forking your own version. 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.

-= Josh

14

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as
discussed in the aforementioned thread and the Multiple SDL
Contexts thread today.

Not if you use SDL as your one and only displaytarget (in
fullscreen). All windows can be rendered into the SDL screen
surface.

SDLwm =)–
Trick

Linux User #229006 * http://counter.li.org

15

David Olofson wrote:

Seriously though, the reason why I would like to use SDL for a “GUI
toolkit” is that I don’t feel like reimplementing SDL. I need:

* Fast colorkey and alpha rendering.

* Support for accelerated OpenGL. (*NOT* a requirement
that acelerated OpenGL is available!)

* Keyboard and mouse input with "full control".
(Access to qualifiers and all that stuff.)

* Loading of various image formats.

* Fullscreen and windowed modes.

* Support for fullscreen-only targets.

* No cruft - I don't want to drag in GTK+, Qt or
similar, as my toolkit is based on a completely
different design idea. (As I've said before,
it's *not* meant for normal applications.)

* Portability accross platforms and targets.

Now, tell me that SDL doesn’t fit the bill…

My list would be similar, emphasizing also the sound framework and
especially the fact that these portability aspects are being maintained
to a large extent by independent developers. Losing that would be one
of the major downsides to forking your own version.

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.)

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. :slight_smile:

//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 17:54, Josh Stern wrote:

16

Yeah… Some time ago, I figured out a basic model for how to design a
"slot" API (or rather a small set of hooks) where you can connect your
favorite SDL WM, to interact with an application running on a multiple
context capable version of SDL.

If I get around to implementing a WM on top of SDL (related to this
toolkit I’m raving about), I’ll keep that design in mind, in case it will
make senes with SDL 1.3 in some way. (The point being that it would be
nice if SDL 1.3 provided the hooks required to “install” a custom WM,
rather than being forced to have the “WM” act as a toolkit, wrapping part
of the SDL API.)

//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 17:59, Trick wrote:

In order to do this, SDL itself would
need to be modified to support the multiple contexts, as
discussed in the aforementioned thread and the Multiple SDL
Contexts thread today.

Not if you use SDL as your one and only displaytarget (in
fullscreen). All windows can be rendered into the SDL screen
surface.

SDLwm =)

17

[…]

The idea is to use “multiple backends”, rather than extending one or
more of them to support multiple windows. The advantage is that you
may open entirely independent contexts, using different backends.
(Although that would require some fiddling with system variables, as
it is now. :slight_smile:

I can’t speak for other backends, but for the OS X backend this won’t
work. I think the same holds true for the MacOS backend, though I am
not 100% sure there.

There are objects involved, which cannot be used in more than one
instance per thread/process, or what…?

[…]

However, note that the real issue here might well be that I need
to read the code more carefully. :wink:

=)

Hmm… You know something I won’t like, don’t you!? :wink:

Nah, not really. 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…?

Well, that certainly complicates things a bit - at least if a multiple
context hack is to support more than a small subset of the targets. heh
So, the “real problem” turns out to be that multiple contexts has to be
implemented on the backend level for many targets.

(BTW, that means that my example of using two different backends at the
same time is actually the easy part.)

//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 17:44, Max Horn wrote:

18

David Olofson wrote:
Josh Stern wrote:

My list would be similar, emphasizing also the sound framework and
especially the fact that these portability aspects are being maintained
to a large extent by independent developers. Losing that would be one
of the major downsides to forking your own version.

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’? The discussion
here makes it sound like nobody really knows what features SDL 1.3
will have and when it will be available. Is there another discussion
forum dealing with these questions?

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. :slight_smile:

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

-= Josh

19

[…]

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,
^^^^
Uh, substitute for “isn’t”, and this might actually make sense. :slight_smile:

//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:34, David Olofson wrote:

20

David Olofson wrote:> On Thursday 11 October 2001 17:44, Max Horn 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. But I would like to know
what the real issue is here.

-= Josh