Perfecting JUCE for POSIX :)


#1

Hi Julian!

  1. String::toUpperCase() and String::toLowerCase() functions do not work properly under Linux. The non-English strings (the Cyrillic ones in this case) are not cased at all. Maybe you should consider another way to work with Unicode strings under Linux? ICU, for instance, is the best Unicode implementation ever created and it’s the standard library provided in many popular Linux distributions today. Well, anyway it’s up to you, of course.

  2. This is the good multi-platform library worth to look at: http://www.appinf.com/poco/info/index.html (sure, if you have enough free time for this).

  3. The JUCE framework is not compatible with Compiz window manager running under XGL. The strange juce-window behaviors are noticed… The details I’ll tell later (I’m still investigating that).

  4. I cry :cry:. JUCE is unable to detect properly my display colour depth (or detects it but does not believe it). I assure you that I have a display set to 24bit colour depth and the GNOME and the KDE window managers support transparency for sure. But JUCE refuses to draw shadows and transparent PNGs onto the OS windows (although, I assure you that many other programs do that perfectly).

  5. Sound problems are still active. The ALSA driver is the perfect way to produce sounds out of your application. But to play more sound streams simultaneously you have to use “dmix” ALSA plug-in to mix them like DirectSound does it. Maybe I’m wrong but I’ve noticed that some programs (with source code) can share the access to ALSA driver without “dmix” plug-in.

  6. I suggest to add some utility functions to prevent screen saver from running (suspend it, to prevent interfering in application’s activity). The same want to suggest as to DPMI API.

(to be continued…)


#2

[quote=“Ptomaine”]Hi Julian!

  1. The JUCE framework is not compatible with Compiz window manager running under XGL. The strange juce-window behaviors are noticed… The details I’ll tell later (I’m still investigating that).
    [/quote]

Is it the same problem as the one in the link below?
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=1168

I’m pretty sure the “default” device points to “dmix” in newer alsa…? Anyway, if you are serious about audio, you may want to use jack, not alsa.


#3

Not that kind.

Probably you’re right. But JUCE does not use the “default” device directly. So, JUCE has to be aware of the “dmix” directly too.

Agreed, but the JACK driver is much more problematic then the ALSA driver to setup properly.


#4

check out the thread on jack… we have provided 2 different solutions to jack implementation, even if none of them is integrated with the AudioDevices of juce. but they work !


#5

Agreed, but the JACK driver is much more problematic then the ALSA driver to setup properly.[/quote]

Well, I’m not quite sure what you mean, but the JACK API is really simple and high level (quite similar to the JUCE sound API), while the alsa API is really complicated and low level.


#6