9 Dec
2002
9 Dec
'02
3:15 p.m.
The world and his dog seems to be releasing macos/windows audio s/w that
looks like 19" rack units.
Anyone know enough about X to know if its possible to make X apps open
thier main window inside a standard sized cabinet (ala Reason).
I'm assuming it would be ok to require the app to be a certian size and
have explicit support, but I guess it couldn't put any restrictions on
toolkit.
Other than looking cool, it would actually be a useful way to keep window
clutter down. Not that we have any 19" lookalike apps yet, but I guess we
will do at some point.
- Steve
9 Dec
9 Dec
3:59 p.m.
The world and his dog seems to be releasing
macos/windows audio s/w that
looks like 19" rack units.
Anyone know enough about X to know if its possible to make X apps open
thier main window inside a standard sized cabinet (ala Reason).
not exactly. you can pass them the ID of an X Window to draw
into. they can look it up and then use it. it won't be a top-level
window, which will create some restrictions on what they can do, and
so they have to expect this to be the case.
the program that created the toplevel window can prevent it from being
resized, i think. but every time a new app starts, the original
program will need to create a new X window for the, otherwise the
situation ends up like macos<=9, where every app can draw onto every
other app's stuff. ick.
I'm assuming it would be ok to require the app to
be a certian size and
have explicit support, but I guess it couldn't put any restrictions on
toolkit.
it suffers from several the usual incompatible toolkit problems, but
not quite as many. as long as the toolkit allows you to add a foreign
window, it could be made to work.
Other than looking cool, it would actually be a useful
way to keep window
clutter down. Not that we have any 19" lookalike apps yet, but I guess we
will do at some point.
you wish.
:))
--p
ps. just how big is a 19" lookalike going to be?
4:16 p.m.
On Mon, 9 Dec 2002, Paul Davis wrote:
not exactly. you can pass them the ID of an X Window
to draw
into. they can look it up and then use it. it won't be a top-level
window, which will create some restrictions on what they can do, and
so they have to expect this to be the case.
Wouldn't it work much like a window manager? Don't they run pretty
similarly like normal X11 programs. That's how they're able to write
window managers that use GTK+ for their widgets.
Taybin
--
http://www.piratesvsninjas.com
4:33 p.m.
On Mon, 9 Dec 2002, Paul Davis wrote:
yes, but that works in reverse: the app creates a new X window, the WM
is notified of its creation, and acts accordingly. in the case steve
was proposing, the "WM" creates the window, the app draws into it.
--p
not exactly. you can pass them the ID of an X
Window to draw
into. they can look it up and then use it. it won't be a top-level
window, which will create some restrictions on what they can do, and
so they have to expect this to be the case.
Wouldn't it work much like a window manager? Don't they run pretty
similarly like normal X11 programs. That's how they're able to write
window managers that use GTK+ for their widgets.
5:41 p.m.
On Mon, Dec 09, 2002 at 03:00:19 -0500, Paul Davis wrote:
Actually I have a clutch of small jack things that could be cleaned up and
19"-ised. I'm sure there will be more in the future.
not exactly. you can pass them the ID of an X Window
to draw
into. they can look it up and then use it. it won't be a top-level
window, which will create some restrictions on what they can do, and
so they have to expect this to be the case.
Right, well I wasn't thinking it would work with existing apps. More of a
target for new things that are bigger than plugins, but not really complex
(like meterbridge).
it suffers from several the usual incompatible toolkit
problems, but
not quite as many. as long as the toolkit allows you to add a foreign
window, it could be made to work.
Any idea how many do?
Other than
looking cool, it would actually be a useful way to keep window
clutter down. Not that we have any 19" lookalike apps yet, but I guess we
will do at some point.
you wish. ps. just how big is a 19" lookalike going to be?
Yeah, well. thats something of a religous issue. 1 pixel per mm ;)
A quick servey of windows 19" alike samplers, compressors and synths looks
like they tend to be in the 500 pixel region. To some extent it doesn't
matter it reduces the variables for simple UIs and that can be a good
thing.
A lot of people would probably arugue that it should be a screen
dimension *shrug*. At this point I only care if it's even possible.
- Steve
6:01 p.m.
On Monday 09 December 2002 21.00, Paul Davis wrote:
ps. just how big is a 19" lookalike going to be?
Well... While XMMs looks very tiny in 2048x1536 even on a 22" screen,
all text is still completely readable. (Yes, this monitor produces a
pretty sharp image.)
19":1U ratio is 1:9.82.
XMMS is 275 x 116 pixels, which means it's pretty close to a "2U
half-rack" unit. (Ever seen one of those?)
I think XMMS is a bit on the small side - but OTOH, you would
probably not want to make these things too wide. Can we assume that
most users have at least 800x600 screens, and that 640x480 can be
considered an absolute minimum display resolution?
If so I would suggest 624 x 64 for a 1U 19" window. The ratio is
1:9.75; just half a pixel away from 19":1U on the height. 624 gives
you some room for window borders even in 640x480, and height
shouldn't be an issue as long as units stay below 7U. 64 is also a
nice figure for 1U, IMHO. :-)
Hmm... Looking at that and thinking about an exact replica of my
JV-1080 implemented in that size, the display would be just fine -
but the text under the buttons would be *really* small.
Then again, we'd probably have to use 1248x128 instead, if we were to
make *exact* copies of existing rack devices. One can use acronyms or
icons, and optional hint flashes or something to give the full names
+ brief explanations.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
6:11 p.m.
On Monday 09 December 2002 20.10, Steve Harris wrote:
Other than looking cool, it would actually be a useful
way to keep
window clutter down.
Yes, that's probably the main reason why they started doing this.
Doesn't everyone just *hate* these little windows of all sizes and
aspect ratios popping upp all over the screen? At least, they were
getting on *my* nerves when I used Cakewalk + plugins...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
6:37 p.m.
On Mon, Dec 09, 2002 at 03:00:19PM -0500, Paul Davis wrote:
it suffers from several the usual incompatible toolkit
problems, but
not quite as many. as long as the toolkit allows you to add a foreign
window, it could be made to work.
Seeing as this has come up again, I asked on the #gtk+ channel on
irc.gnome.org the other day about why you can't use gtk+ and qt (for
example) in the same app, and whether or not it's likely to change.
They had this to say:
<owen> node: Well, really depends on the other toolkit....
<owen> node: And whether you want to share the Display connection or not.
<owen> node: GTK+ is perfectly happy to let another toolkit share its main loop
<owen> node: Metacity is an example of how you can leach of GDK's display
connection, but sharing a single display is inherently going
to be hard
Has anybody actually tried to get gtk+ and qt working in the same
application?
Bob
7:02 p.m.
On Mon, Dec 09, 2002 at 10:56:08 +0100, David Olofson wrote:
On Monday 09 December 2002 21.00, Paul Davis wrote:
Yes, this is one of my reasons for thinking that specifying it in pixels is
OK. I have a 1600x1200 15" display and I can use xmms on it fine.
ps. just how big is a 19" lookalike going to
be?
Well... While XMMs looks very tiny in 2048x1536 even on a 22" screen,
all text is still completely readable. (Yes, this monitor produces a
pretty sharp image.) If so I would suggest 624 x 64 for a 1U 19"
window. The ratio is
1:9.75; just half a pixel away from 19":1U on the height. 624 gives
you some room for window borders even in 640x480, and height
shouldn't be an issue as long as units stay below 7U. 64 is also a
nice figure for 1U, IMHO. :-)
Those sound like nice numbers, I'd have though 800x600 was a reasonable
minimum screen size. Go on then, whose running at 640x480 ;)
Hmm... Looking at that and thinking about an exact
replica of my
JV-1080 implemented in that size, the display would be just fine -
but the text under the buttons would be *really* small.
The Windows UIs I've seen have not been copies of modern equipment, they've
been simplified, or copies of older equipment that had larger legends and less
busy interfaces anyway.
The only things in my rack that wouldn't work at this res are the reverb
(it has tiny program numbers on a rotary encoder - but you wouldn't
represent it that way, you could have another number display), and the
mixer, which is like 12U.
A lot of modern rack equipment has been trying to cram loads of UI into a
small space, I dont think theres any point copying that, just simple,
intuative or familar interfaces.
I'd expect most computer UIs to be 2U.
- Steve
7:04 p.m.
On Mon, Dec 09, 2002 at 11:06:53 +0100, David Olofson wrote:
On Monday 09 December 2002 20.10, Steve Harris wrote:
Well, AFAICT in windows they dont group (mount? ;) them, there just all the
right dimensions and have little rack ears draw on the end. Cute, but not
useful.
Reason arranges its internal parts into a rack, but doesnt accept extenal
programs into it AFAIK.
- Steve
Other than looking cool, it would actually be a
useful way to keep
window clutter down.
Yes, that's probably the main reason why they started doing this.
Doesn't everyone just *hate* these little windows of all sizes and
aspect ratios popping upp all over the screen? At least, they were
getting on *my* nerves when I used Cakewalk + plugins...
7:06 p.m.
On Mon, Dec 09, 2002 at 03:35:10 -0500, Paul Davis wrote:
yes, but that works in reverse: the app creates a new
X window, the WM
is notified of its creation, and acts accordingly. in the case steve
was proposing, the "WM" creates the window, the app draws into it.
Well, I dont really care how it works I was just thinking of app swollowing
in docks. The only important thing is that windows from different apps
should be groupable, and that its not a grotesque hack.
- Steve
11:51 p.m.
On Mon, Dec 09, 2002 at 03:00:19PM -0500, Paul Davis
wrote:
its been done.
it was ugly as sin. they did it by writing some new KDE objects to
handle the GTK+ side of things. then they wrote a "white paper" about
it that was enough to put any right-thinking programmer off the whole
idea. it might be *slightly* easier by using GTK+ as the "primary"
event loop, but not much.
but since we want to, as owen said, "leach off a single XDisplay",
this will always be hard. the way i described this over on the VST
plugins list recently was somewhat like this: each toolkit has its own
event loop that gets events from the X server. but it has no idea what
to do with events that are for windows that the toolkit did not
create. what you'd like is some kind of "master event loop" that
allowed to register a event handler for a given toolkit along with a X
Window ID; when events arrive for that window, they are dispatched to
the correct handler. however, this totally messes up the fact that
most toolkits expect to be able to schedule time-based events from
their event loops and also to be able to integrate poll/select-driven
I/O on generic file descriptors (and other kinds of "events") into
their event loops. so yeah, its basically really hard. i could write
this, but it would take me a 3-4 weeks to make it work with even just
GTK and Qt, let alone all the other toolkits.
worse, all nobody needs it except us wierdos who want to load .so's
that create their own GUIs. the regular world doesn't need this in any
way.
--p
it suffers from several the usual incompatible
toolkit problems, but
not quite as many. as long as the toolkit allows you to add a foreign
window, it could be made to work.
Seeing as this has come up again, I asked on the #gtk+ channel on
irc.gnome.org the other day about why you can't use gtk+ and qt (for
example) in the same app, and whether or not it's likely to change.
They had this to say:
<owen> node: Well, really depends on the other toolkit....
<owen> node: And whether you want to share the Display connection or not.
<owen> node: GTK+ is perfectly happy to let another toolkit share its main loo
p
<owen> node: Metacity is an example of how you can leach of GDK's display
connection, but sharing a single display is inherently going
to be hard
Has anybody actually tried to get gtk+ and qt working in the same
application? 
10 Dec
10 Dec
1:40 a.m.
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
This is a strong counterexample to the oft-repeated maxim that "choice is
the strength of OSS."
But I guess the fact that 10 random linux audio applications are written to 10
different APIs that can't interoperate is another.
In my opinion, this is why the deskop projects (KDE and Gnome) are so
important. They give consistency of behavior and interoperability between
applications.
KDE and Gnome are both targetted toward layperson desktop use, especially
office and productivity. They also ensure a higher degree of visual
consistency than audio apps really require. I can see why authors of audio
apps would resist embracing either one of these and the policy they impose.
But perhaps it would be beneficial to create a loose "Linux Audio Desktop"
platform. Include in it:
* the audio API applications should use, namely JACK
* the plugin API applications should use, namely LADSPA
* provisions for session management, once they become mature
* suggested toolkit, for situations where it will matter (such as the
context outlined above)
There may be other things. The statement would mostly be "the more closely
you follow these guidelines, the better your application will interoperate
with existing Linux audio applications."
Think about the difference between writing a game for Win32 vs. Linux. With
Win32 you keep your Direct* reference handy and away you go; it's an entire
platform. With Linux you have to make umpteen decisions about what system to
use for graphics, sound, networking, timers, etc. People often make
less-than-optimal decisions due simply to lack of knowledge. What the
"Linux Audio Desktop" could offer is a resource of "best practice"
advice
on what decisions to make when writing audio applications.
I've felt the mission lately to do whatever I can to help unify divergent
efforts in the OSS community. I think the best way to do this is to give
application authors compelling reasons to make choices that will make their
software more useful, and help out with changes where possible.
Thoughts?
Josh (urgh, back to studying for finals, looking forward to Christmas and
having oodles of time to work out of the OSS project queue I've built up
over the semester...)
Has anybody
actually tried to get gtk+ and qt working in the same
application?
its been done.
it was ugly as sin. 
18 Dec
18 Dec
2:20 p.m.
On Monday 09 December 2002 20:10, Steve Harris wrote:
The world and his dog seems to be releasing
macos/windows audio s/w that
looks like 19" rack units.
Anyone know enough about X to know if its possible to make X apps open
thier main window inside a standard sized cabinet (ala Reason).
I'm assuming it would be ok to require the app to be a certian size and
have explicit support, but I guess it couldn't put any restrictions on
toolkit.
Other than looking cool, it would actually be a useful way to keep window
clutter down. Not that we have any 19" lookalike apps yet, but I guess we
will do at some point.
- Steve
Why not add another option to the window manager instead?
(much like "Always on top")
"Add to window group" -> "Audio rack"
Let the window manager keep them with a common width
and split height. Resize and Move all windows together.
- Possible?
/RogerL
--
Roger Larsson
Skellefteå
Sweden
5:33 p.m.
On Wed, 18 Dec 2002, Roger Larsson wrote:
Why not add another option to the window manager
instead?
(much like "Always on top")
"Add to window group" -> "Audio rack"
Let the window manager keep them with a common width
and split height. Resize and Move all windows together.
- Possible?
I think the main problem with that is modifing all the window managers to
do it. To do that, you'd have to get it into the window manager spec,
which I imagine would be difficult.
Taybin
--
http://www.piratesvsninjas.com
30 Jan
30 Jan
4:43 a.m.
[Bringing an old thread up again...]
On Monday 09 December 2002 22.56, David Olofson wrote:
[...]
If so I would suggest 624 x 64 for a 1U 19"
window. The ratio is
1:9.75; just half a pixel away from 19":1U on the height. 624 gives
you some room for window borders even in 640x480, and height
shouldn't be an issue as long as units stay below 7U. 64 is also a
nice figure for 1U, IMHO. :-)
There were no complaints about using 624 x 64 as the 1U of 19" for
virtual rack devices, IIRC. Still sounds nice to me, although, for
various reasons, I'd also like to support "half rack" format; ie 312
pixels corresponding to 9½" units.
Sounds ok?
Anyway, the reason I'm asking is that I'm getting closer and closer to
a point where I'll need a highly portable "media player" that can
host (for starters) Audiality, to play Audiality specific songs. I'd
also like to use the same framework for testing, debugging and
editing tools for Audiality, and perhaps other things in the future.
Obvious features to add at an early stage is LADSPA hosting and
running as a JACK client.
Requirements:
* Must run on Linux, Mac OS X and Windows at the very least.
* Should support full-screen modes.
* Concistent look'n'feel across platforms.
* Should be fast and responsive.
* "Chrome" support; ie per-plugin VST style skins.
* A minimum of dependencies, for easy porting and building.
* Preferably pure C, to avoid C++ binary compatibility issues.
I'd really rather not hack specific player plugins (XMMS, WinAmp and
whatnot) for each platform if I can help it. I'd much rather not
spend much time hacking stuff that won't even compile on Linux...
As it looks now, I'll use SDL for graphics and portable audio output.
(Audiality already supports SDL audio, and compiles with that only if
there's no OSS.) SDL 1.2 can't handle multiple windows, but I don't
really want that anyway, not even in windowed mode. It's going to be
entirely rack style, though I'll probably support multiple columns.
SDL *can* handle fullscreen, it's highly portable, and it's great for
fast low level graphics.
The GUI toolkit will be a *very* basic pixmap based one, with an
asynchronous, two-way event based API that does not assume the
rendering layer is in the same thread or even process as the client.
This won't really matter initially, but the idea is that
out-of-process clients should be able to run GUI panels in the rack
and that kind of stuff.
I'll probably add a binding that allows the abuse of Audiality's EEL
scripting language for creating GUIs. That way, you can implement
"engines" in EEL, so you can construct "real" GUIs without adding
compiled code anywhere. (EEL code will run wherever Audiality runs -
or you won't get any waveforms rendered.)
Obviously, I've looked for something I could use or hack, but it seems
like every damn media player is either a huge, non-portable monolith
or a half-finished beginner's project - or both. Of course, there
appears to be no such thing as a remotely portable media player
plugin API.
I've been thinking about building one on top of LADSPA, but it seems
to be the wrong kind of design for the job entirely. This needs more
thinking, though. (Obviously, I should check out the WinAmp and XMMS
plugin APIs to get an idea of the feature set, so I don't have to
figure it all out through experimentation.)
Did I miss something? (Useful cross-platform player plugin APIs, for
example...)
Is there interest in something like this, or maybe better ideas that
would solve my problems as well? A suitable player plugin API I could
use, or at least start with?
Finally, note that I'm still talking about a "quick hack", rather than
The Final Media Player. It's probably going to be lots of copy/paste
from various SDL stuff I've written, and pretty messy for starters.
I'm just trying to start with a basic idea that isn't *totally*
bogus, in case it actually becomes half as useful as it seems to me
on a good day.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
8:17 a.m.
On Thu, Jan 30, 2003 at 09:35:57 +0100, David Olofson wrote:
Yeah, good idea.
I did actually play with this stuff a little, one possible way forward is
using Xnest*, but I found it a bit tricky to get stated (its not well
documented). In theory you would write a simple window manager, get it
running on the Xnest server and the set the DISPLAY var to the Xnest
server when starting your app. The simple window manager could then stick
it in the right place and all would be happyness and joy.
Except that I could not get the Xnest server to autorise any clients ;)
- Steve
* Xnest is an X Windows client (window) and virtual X Server that appears
as a server to apps, so you can run any X apps and they will appear in the
window which can have its own window manager etc. It comes with XFree86 by
default.
If so I would
suggest 624 x 64 for a 1U 19" window. The ratio is
1:9.75; just half a pixel away from 19":1U on the height. 624 gives
you some room for window borders even in 640x480, and height
shouldn't be an issue as long as units stay below 7U. 64 is also a
nice figure for 1U, IMHO. :-)
There were no complaints about using 624 x 64 as the 1U of 19" for
virtual rack devices, IIRC. Still sounds nice to me, although, for
various reasons, I'd also like to support "half rack" format; ie 312
pixels corresponding to 9?" units.
8:31 a.m.
On Thursday 30 January 2003 13.10, Steve Harris wrote:
On Thu, Jan 30, 2003 at 09:35:57 +0100, David Olofson
wrote:
Yeah, good idea.
I did actually play with this stuff a little, one possible way
forward is using Xnest*, but I found it a bit tricky to get stated
(its not well documented). In theory you would write a simple
window manager, get it running on the Xnest server and the set the
DISPLAY var to the Xnest server when starting your app. The simple
window manager could then stick it in the right place and all would
be happyness and joy.
Well, I was thinking in terms of doing that on the rendering API level
- although that obviously means that you'll either have to use my low
level, chrome oriented pixmap toolkit directly, or port some more
traditional toolkit (like FLTK) to render on top of it. Communication
with the server would be through lock-free FIFOs in shared memory,
Un*x pipes, messages or whatever, depending on platform.
Not exactly the smoothest way to do it, though it seems to be pretty
much the only way to do what I want. I don't want to drag in toolkits
that I'm basically just going to (ab)use as rendering layers anyway,
especially since virtually none of them will run on more than 2 or 3
platforms, and even fewer support fullscreen/"raw" targets like
fbdev, DirectFB, DirectX or svgalib.
Anyway, as to X, how about doing something like what XMMS does? Don't
know exactly how it's done, but it looks like they're just dragging
the other windows along when the main window is moved. Doesn't track
totally glitch free, but it sort of works...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
If so I
would suggest 624 x 64 for a 1U 19" window. The ratio
is 1:9.75; just half a pixel away from 19":1U on the height.
624 gives you some room for window borders even in 640x480, and
height shouldn't be an issue as long as units stay below 7U. 64
is also a nice figure for 1U, IMHO. :-)
There were no complaints about using 624 x 64 as the 1U of 19"
for virtual rack devices, IIRC. Still sounds nice to me,
although, for various reasons, I'd also like to support "half
rack" format; ie 312 pixels corresponding to 9?" units.
10:01 a.m.
On Thu, Jan 30, 2003 at 01:24:02 +0100, David Olofson wrote:
Anyway, as to X, how about doing something like what
XMMS does? Don't
know exactly how it's done, but it looks like they're just dragging
the other windows along when the main window is moved. Doesn't track
totally glitch free, but it sort of works...
From some similar experience I think thats just an
artifact of the fact
they they have frameless, shaped windows.
I think having all the apps diplays under the control of a hosting app is
a better idea.
- Steve
10:48 a.m.
On Thursday 30 January 2003 14.54, Steve Harris wrote:
On Thu, Jan 30, 2003 at 01:24:02 +0100, David Olofson
wrote:
Yes, but how? Somehow giving each app something that's compatible
enough with an X window to handle a standard toolkit is the obvious
way, but it might be more complicated than it sounds... (And it won't
help the portability issue much, unless it's actually an X protocol
implementation - but that's probably a minor issue for most people.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
Anyway, as to X, how about doing something like
what XMMS does?
Don't know exactly how it's done, but it looks like they're just
dragging the other windows along when the main window is moved.
Doesn't track totally glitch free, but it sort of works...
From some similar experience I think thats just an artifact of the
fact they they have frameless, shaped windows.
I think having all the apps diplays under the control of a hosting
app is a better idea. 
11:50 a.m.
On Thu, Jan 30, 2003 at 03:41:05PM +0100, David Olofson wrote:
On Thursday 30 January 2003 14.54, Steve Harris
wrote:
tell app its windowname and swallow that...
if app wnats to open another window then it has to tell
the host app via IPC of its new window ID and then the host will
swallow it.
gnome-toolbar can swallow every app... kde toolbar too...
so host could be written with qt or gtk dont know about
fltk, wx etc...
On Thu, Jan 30, 2003 at 01:24:02 +0100, David
Olofson wrote:
Yes, but how? Somehow giving each app something that's compatible
enough with an X window to handle a standard toolkit is the obvious
way, but it might be more complicated than it sounds... (And it won't
help the portability issue much, unless it's actually an X protocol
implementation - but that's probably a minor issue for most people.) Anyway, as to X, how about doing something like
what XMMS does?
Don't know exactly how it's done, but it looks like they're just
dragging the other windows along when the main window is moved.
Doesn't track totally glitch free, but it sort of works...
From some similar experience I think thats just an artifact of the
fact they they have frameless, shaped windows.
I think having all the apps diplays under the control of a hosting
app is a better idea.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
12:11 p.m.
On Thu, Jan 30, 2003 at 03:41:05 +0100, David Olofson wrote:
Thats why I suggested Xnest. It is a genuine X implemntation, and it lets
you run a private window manager to control the rack.
- Steve
I think having
all the apps diplays under the control of a hosting
app is a better idea.
Yes, but how? Somehow giving each app something that's compatible
enough with an X window to handle a standard toolkit is the obvious
way, but it might be more complicated than it sounds... (And it won't
help the portability issue much, unless it's actually an X protocol
implementation - but that's probably a minor issue for most people.)
12:23 p.m.
Yes, but how?
Somehow giving each app something that's compatible
enough with an X window to handle a standard toolkit is the obvious
way, but it might be more complicated than it sounds... (And it won't
help the portability issue much, unless it's actually an X protocol
implementation - but that's probably a minor issue for most people.)
Thats why I suggested Xnest. It is a genuine X implemntation, and it lets
you run a private window manager to control the rack.
1:19 p.m.
On Thu, Jan 30, 2003 at 11:31:12 +0100, torbenh(a)gmx.de wrote:
tell app its windowname and swallow that...
if app wnats to open another window then it has to tell
the host app via IPC of its new window ID and then the host will
swallow it.
gnome-toolbar can swallow every app... kde toolbar too...
so host could be written with qt or gtk dont know about
fltk, wx etc...
Yes, but hat is done with a window manger hack, normal X apps can't do
that.
- Steve
1:22 p.m.
On Thu, Jan 30, 2003 at 11:19:57 -0500, Paul Davis wrote:
...
Thats why I
suggested Xnest. It is a genuine X implemntation, and it lets
you run a private window manager to control the rack.
yes, i love it. note that it requires a newer version of XFree86
(3.3.2 doesn't have it). the big problem is that writing even a simple WM is
not
trivial. still, i would guess that taking twm and hacking it to
enforce window sizes and position can't be that hard.
Damn. I was hoping it wasn't going to be too hard. I guess it involves
dealing with Xlib directly, and that instantly makes it hard.
On the up side it doesn't require anything like mouse controlled movement
of windows as thier placed automatically. You wouldn't need any window
furniture either.
- Steve
31 Jan
31 Jan
3:38 a.m.
On Thursday 30 January 2003 18.12, Steve Harris wrote:
On Thu, Jan 30, 2003 at 11:31:12 +0100, torbenh(a)gmx.de
wrote:
Are you sure this is the case? There are numerous applications that support
swallowing. Some of them are quite small.
Right now I can't think of one though, I'll do some checking.
We talked about this some years ago I remember doing some checking back then,
the ones that I have seen are derived from WindowMakers dockapps.
These apps export small bitmaps as windows, I think the approach is valid for
us to.
/Robert
tell app its windowname and swallow that...
if app wnats to open another window then it has to tell
the host app via IPC of its new window ID and then the host will
swallow it.
gnome-toolbar can swallow every app... kde toolbar too...
so host could be written with qt or gtk dont know about
fltk, wx etc...
Yes, but hat is done with a window manger hack, normal X apps can't do
that. 
4:47 a.m.
On Fri, Jan 31, 2003 at 08:31:44AM +0100, Robert Jonsson wrote:
On Thursday 30 January 2003 18.12, Steve Harris
wrote:
http://www.freedesktop.org/standards/xembed/html/
if i understand correctly, hack seems like too strong a word. the
embedder reparents the out-of-process window and sets the
SubstructureRedirectMask so it can intercept events etc. it's fairly
simple (even with all the bells and whistles they use in their spec),
and in general it isn't an abuse of the X architecture. see also 'man
XReparentWindow' and for example 'man XConfigureEvent' to see how the
substructure redirect is handled.
the only thing that really needs to be agreed upon after that is how
to get the window id of the window to be swallowed.
rob
----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async(a)cc.gatech.edu
On Thu, Jan 30, 2003 at 11:31:12 +0100,
torbenh(a)gmx.de wrote:
[...] tell app its windowname and swallow that...
if app wnats to open another window then it has to tell
the host app via IPC of its new window ID and then the host will
swallow it.
gnome-toolbar can swallow every app... kde toolbar too...
so host could be written with qt or gtk dont know about
fltk, wx etc...
Yes, but hat is done with a window manger hack, normal X apps can't do
that.
5:10 a.m.
On Fri, Jan 31, 2003 at 03:40:49 -0500, rm wrote:
On Fri, Jan 31, 2003 at 08:31:44AM +0100, Robert
Jonsson wrote:
This came up recently, IIRC its appropriate, but not implemented yet.
- Steve
On Thursday 30 January 2003 18.12, Steve Harris
wrote:
http://www.freedesktop.org/standards/xembed/html/ On Thu, Jan 30, 2003 at 11:31:12 +0100,
torbenh(a)gmx.de wrote:
[...] tell app its windowname and swallow that...
if app wnats to open another window then it has to tell
the host app via IPC of its new window ID and then the host will
swallow it.
gnome-toolbar can swallow every app... kde toolbar too...
so host could be written with qt or gtk dont know about
fltk, wx etc...
Yes, but hat is done with a window manger hack, normal X apps can't do
that.
5:14 a.m.
On Fri, Jan 31, 2003 at 08:31:44 +0100, Robert Jonsson wrote:
OK, well, more precicely, the ones I looked at (FVWM and Gnome-whatsit IIRC)
used window manager hacks.
Yes, but hat
is done with a window manger hack, normal X apps can't do
that.
Are you sure this is the case? There are numerous applications that support
swallowing. Some of them are quite small.
Right now I can't think of one though, I'll do some checking. We talked about this some years ago I remember doing
some checking back then,
the ones that I have seen are derived from WindowMakers dockapps.
These apps export small bitmaps as windows, I think the approach is valid for
us to.
Not really, as the bitmap will be ~600 pixels wide and is likely to
contain constantly moving meters, I can image that being quite a load.
Xnest seems like a better option really. It just needs somone who
understands X better than me to look at it.
- Steve
5:16 a.m.
On Thu, Jan 30, 2003 at 11:19:57 -0500, Paul Davis wrote:
yes, i love it. note that it requires a newer version of XFree86
(3.3.2 doesn't have it).
I think it does, its been around for a while, but maybe it wasn't
installed by default, RedHat 5 had Xnest 3.3 RPMs.
- Steve
Yes, but how? Somehow giving each app something
that's compatible
enough with an X window to handle a standard toolkit is the obvious
way, but it might be more complicated than it sounds... (And it won't
help the portability issue much, unless it's actually an X protocol
implementation - but that's probably a minor issue for most people.)
Thats why I suggested Xnest. It is a genuine X implemntation, and it lets
you run a private window manager to control the rack.
5:25 a.m.
On Fri, Jan 31, 2003 at 09:03:22AM +0000, Steve Harris wrote:
On Fri, Jan 31, 2003 at 03:40:49 -0500, rm wrote:
This came up recently, IIRC its appropriate, but not implemented yet.
nothing really needs to be implemented (as i understand it); you just
reparent the window and forward xevents.
rob
----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async(a)cc.gatech.edu
5:35 a.m.
Robert Melby wrote:
if i understand correctly, hack seems like too strong
a word. the
embedder reparents the out-of-process window and sets the
SubstructureRedirectMask so it can intercept events etc. it's fairly
simple (even with all the bells and whistles they use in their spec),
and in general it isn't an abuse of the X architecture. see also 'man
XReparentWindow' and for example 'man XConfigureEvent' to see how the
substructure redirect is handled.
the only thing that really needs to be agreed upon after that is how
to get the window id of the window to be swallowed.
I was just trying this out (on Solaris ...) when this message came in.
It works, and it's simple (if you have the habit of working with X
directly).
--
Fons Adriaensen
ALCATEL SPACE
6:15 a.m.
On Fri, Jan 31, 2003 at 10:28:44 +0100, Fons Adriaensen wrote:
Robert Melby wrote:
OK, so how much work is needed to make a generic library or similar that
can handle this for client windows? I'm assuming the 'rack' would launch
the apps, so it can take care of communicating its ID to the clients.
- Steve
if i understand correctly, hack seems like too
strong a word. the
embedder reparents the out-of-process window and sets the
SubstructureRedirectMask so it can intercept events etc. it's fairly
simple (even with all the bells and whistles they use in their spec),
and in general it isn't an abuse of the X architecture. see also 'man
XReparentWindow' and for example 'man XConfigureEvent' to see how the
substructure redirect is handled.
the only thing that really needs to be agreed upon after that is how
to get the window id of the window to be swallowed.
I was just trying this out (on Solaris ...) when this message came in.
It works, and it's simple (if you have the habit of working with X
directly).
6:36 a.m.
Steve Harris wrote:
On Fri, Jan 31, 2003 at 08:31:44 +0100, Robert Jonsson
wrote:
OK, well, more precicely, the ones I looked at (FVWM and Gnome-whatsit IIRC)
used window manager hacks.
Reading up on it somewhat I see no reason for using even OpenGL inside a
swallowed application... They are after all just windows. Maybe my
note about bitmaps was just confusing things. They are as accelerated as
anything else.
Here is an example I found with a quick search, I have no idea how the
code looks.
http://www.informatik.uni-oldenburg.de/~bigboss/kappdock/index.html
Yes, but
hat is done with a window manger hack, normal X apps can't do
that.
Are you sure this is the case? There are numerous applications that support
swallowing. Some of them are quite small.
Right now I can't think of one though, I'll do some checking. We talked about this some years ago I remember
doing some checking back then,
the ones that I have seen are derived from WindowMakers dockapps.
These apps export small bitmaps as windows, I think the approach is valid for
us to.
Not really, as the bitmap will be ~600 pixels wide and is likely to
contain constantly moving meters, I can image that being quite a load.
Xnest seems like a better option really. It just needs somone who
understands X better than me to look at it.
I'm definately not convinced, running Xnest seems to me like a huge
waste of resources. I mean Xnest is a complete Xserver isn't it?
/Robert
8:34 a.m.
On Fri, Jan 31, 2003 at 11:29:08 +0100, Robert Jonsson wrote:
Well, in practice it just punts the X stuff to the real server, the binary
is about 3meg.
- Steve
Xnest seems
like a better option really. It just needs somone who
understands X better than me to look at it.
I'm definately not convinced, running Xnest seems to me like a huge
waste of resources. I mean Xnest is a complete Xserver isn't it?
12:18 p.m.
On Fri, Jan 31, 2003 at 09:07:18AM +0000, Steve Harris wrote:
No Xnest please...
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Fri, Jan 31, 2003 at 08:31:44 +0100, Robert Jonsson
wrote:
OK, well, more precicely, the ones I looked at (FVWM and Gnome-whatsit IIRC)
used window manager hacks.
here is some excerpt from gtksocket.h: from gtk-1.2.x
------------------snip---------------------------
struct _GtkSocketClass
{
GtkContainerClass parent_class;
};
GtkWidget* gtk_socket_new (void);
guint gtk_socket_get_type (void );
void gtk_socket_steal (GtkSocket *socket,
guint32 wid);
------------------snap---------------------------
this is a normal gtkwidget ... call gtk_socket_steal( sock, wid )
and you are done...
if this is a hack i dont see it and dont care.
i will try it out soon...
when i write the jack application component for gAlan...
Yes, but
hat is done with a window manger hack, normal X apps can't do
that.
Are you sure this is the case? There are numerous applications that support
swallowing. Some of them are quite small.
Right now I can't think of one though, I'll do some checking. We talked about this some years ago I remember
doing some checking back then,
the ones that I have seen are derived from WindowMakers dockapps.
These apps export small bitmaps as windows, I think the approach is valid for
us to.
Not really, as the bitmap will be ~600 pixels wide and is likely to
contain constantly moving meters, I can image that being quite a load.
Xnest seems like a better option really. It just needs somone who
understands X better than me to look at it.
12:29 p.m.
On Friday 31 January 2003 08.31, Robert Jonsson wrote:
[...]
We talked about this some years ago I remember doing
some checking
back then, the ones that I have seen are derived from WindowMakers
dockapps. These apps export small bitmaps as windows, I think the
approach is valid for us to.
X bitmaps, or something toolkit specific?
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
7763
days inactive
7816
days old
linux-audio-dev@lists.linuxaudio.org
36 comments
11 participants
participants (11)
-
Bob Ham -
David Olofson -
Fons Adriaensen -
Joshua Haberman -
Paul Davis -
rm -
Robert Jonsson -
Roger Larsson -
Steve Harris -
Taybin Rutkin -
torbenh＠gmx.de