[LAU] question about qjackctl explicitly setting the wm class name

[Tim E. Real]

On November 30, 2012 04:17:29 PM Rui Nuno Capela wrote:
> On 11/30/2012 03:22 PM, Ivica Ico Bukvic wrote:
> > All,
> > 
> > This one is a bit convoluted so please stick with me while I try to
> > explain.
> > 
> > The problem manifests itself on Ubuntu using Unity (I know, I know, some
> > will claim they don't care about it and I fully appreciate that, but I
> > am not entirely sure this is about Unity).
> > 
> > As I've learned by working on pd-l2ork, it appears that Unity assigns
> > windows under the appropriate icon based on window class name (at least
> > that is how tcl/tk calls it). If no class name is specified, Unity gives
> > window class name based on the name of the shortcut that started the app
> > (.desktop file) and herein lies the problem.
> > 
> > While typically .desktop files will have the same name as the app, and
> > starting them as such will not  be a problem, I have a a shell script
> > built for L2Ork participants that appears as a desktop shortcut.
> > Double-clicking on the shortcut starts the bash script that detects
> > whether qjackctl is already running and if not starts it, then it starts
> > pd-l2ork and uses optional argument to open the right piece. Since I
> > made pd-l2ork explicitly set its own window class using the following
> > command:
> > 
> > toplevel $window -class <name>
> > 
> > all pd-l2ork windows appear under the icon that I pinned on the Unity
> > launcher. The important thing is this was not the case until I
> > explicitly set the window class name. Before I did this, it would appear
> > under the name of the .desktop file name since Unity did not find any
> > other explicit information on the program, resulting in a new question
> > mark icon that appears on the launcher and program window(s) being
> > pegged under this new icon. On the other hand, since qjackctl does not
> > explicitly set its window class name, it continues to (mis)behave like
> > pd-l2ork used to prior to explicitly setting its window class names.
> > Namely, when I click on the shortcut in Unity launcher/menu, its newly
> > spawned window is pegged under qjackctl icon (as it should). However,
> > when I run qjackctl through the script, it is pegged under the new
> > question marked icon bearing the name of the .desktop shortcut.
> > 
> > So, here's the question that's been bugging me: is there a way to
> > explicitly set the window class name in qt as is the case with tcl/tk
> > (FWIW, I would be seriously surprised if one couldn't since I consider
> > qt far superior to tcl/tk) and if so, would it be possible to add this
> > to the future releases of qjackctl?
> 
> had you tried
>    qjackctl -name <name>
> ?
> 
> > Another completely unrelated qjackctl wishlist question is would it be
> > possible to disable popping up message window and the pop-up error
> > window in the event the qjackctl does not connect successfully connect
> > to jackd via a preferences option as it can be quite annoying for new
> > users to click through those two windows every time attempted start of
> > jackd fails...
> 
> two windows? that's unity snafu's most certainly o.O there should be
> only one, either a bubble window (if the systray icon is enabled) *or* a
> plain standard message-box window.

Hi Rui. I believe he's referring to the two error dialog users must
 click through when Jack can't be started.
The first dialog gives the root of the error, such as:

"D-BUS: JACK server could not be started.
 Sorry"

When the user clicks Cancel on that dialog, a second dialog pops up 
 with the more general operation failure:

"Could not connect to JACK server as client.
- Overall operation failed.
- Unable to connect to server.
Please check the messages window for more info."

Can it be fixed to just show one error dialog and be done with it?
Sometimes it can be confusing, also due to the slight delay in them
 popping up, and the appearance of the messages window as well.

Tim.

> 
> > Many thanks!
> 
> i don't use unity and don't plan to use ever. so both support
> question(s) remain
> 
> 
> cheers