Starting with runing jack causes to ask settings save on quit
Short time before I had qjackctl with enabled option to stop jack in application exit. Today I disabled this option, because need sometimes to restart qjackctl due to another clearly systray-related bug.
It is ok, if qjackctl quited first time after enabling this option. But if started during same jack run, following attempt to quit will cause it to behave as if there are unsaved settings. Problem doesn't appear if jack was not started when qjackctl started, but doesn't disappear if jack was stoped before to quit.
Turning mentioned option back on makes problem to disappear immediately (not only on next qjackctl run). It even doesn't appear if option is enabled, saved, and then immediately disabled, all during one qjackctl/jack run.
it all depends whether you're using JACK D-BUS ? right? then it's all expected behavior...
When starting qjackctl and at that moment the jack-server is already up and running, probably due to some other client demand (jackdbus does its thing), then all settings are there read from JACK D-Bus interface and NOT from any previous qjackctl saved settings. That's probably why it asks you to save the new settings on exit. Again, this is expected behavior.
Cheers
Here it is. I tried example on top of qsystray example from qt reference. Just removed everything irrelevant (though left icon hide/show option), added dialog context handler, showing same menu as assigned to systray, and additionally tested, how menu changes are handled by systray. Both xfce and mate panels are ok. I only need yet to get to other pc with xfce. qt-tray-menu-dynamic.zip
In my example is one menu object, assigned to systray. For window context menu same systray-dedicated menu object is exec'ed, no need to create new.
Edit: also I tested, how actions are added/removed from existing menu.
https://github.com/rncbc/qjackctl/commit/a2d0415 might have nailed it
please test && tell thanks a lot cheers
wrong issue, post above is related to #62
wrong issue, post above is related to #62
i know but it was just your previous comment here that sparked this move.
thanks again