<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Andrew,<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">in the case of flatpaks, the command is somewhat more complex:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">flatpak-runner options-for-flatpak-runner FLATPAK_ID options-for-running-command</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So, just checking the first argument maybe incorrect with the executable specified by FLATPAK_ID somewhere in the middle. Its the same syntax as expected by `flatpak run` command.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In the case of SFOS, the architecture is as follows:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Wayland-0 - Lipstick - Flatpak-Runner - Wayland-1 - Flatpacked app</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As you can see, Lipstick has no way of learning directly what's running in flatpak-runner as its using its own Wayland compositor. While designing for future, I don't know if its needed. However, it maybe handy to keep all regular desktop apps dialog boxes inside single flatpak-runner window. For know, its probably realistic to expect larger changes in Lipstick coming not immediately after Qt update, whenever that will come.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now, coming back to original issue. Somehow, Lipstick has to distinguish while launching and later following appearing windows flatpak-runner either running by itself or with some app embedded. When launching, its easy - Lipstick can follow desktop X-Flatpak for Flatpak ID. For catching correct window to stop showing minimized card with spinning disk, that's more difficult. I presume that SailfishApp::application or some similar object signals it to Lipstick. So, we will have to somehow implement that part as well. (Guessing here)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we wish to generalize it to any kind of launchers, then we need some mechanism to tell Lipstick some unique ID of the app and there should be a way for Lipstick to associate window with it. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As for mimetypes, don't know much how to do that. If used, as expected, with single instance application, it will require some forwarding of flatpak-runner part. Or just starting it as normal and letting the app to sort it out. Will require some thinking/working on it in future.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 10, 2020 at 2:36 PM Andrew Branson <<a href="mailto:andrew.branson@jolla.com">andrew.branson@jolla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rinigus,<br>
<br>
I don't think the Wayland window className method is the right thing for <br>
you - on further investigation this is used by aliendalvik because of <br>
its unusual shared window handling. Your flatpak apps wouldn't do that <br>
sort of thing, so we can handle this more simply.<br>
<br>
I did find where the support for X-Nemo-Single-Instance lives. It seems <br>
to only interact with apps using the invoker:<br>
<br>
<a href="https://git.sailfishos.org/mer-core/libcontentaction/blob/master/src/exec.cpp#L77" rel="noreferrer" target="_blank">https://git.sailfishos.org/mer-core/libcontentaction/blob/master/src/exec.cpp#L77</a><br>
<br>
 From the other TJC question about python3, it looks like this might <br>
still be broken, but as you're not using the invoker I don't think it <br>
would help you as it stands. More investigation is needed into why it's <br>
not working, but I think that patch might be too simple.<br>
<br>
I think what's needed for flatpak and other launchers is some directive <br>
to check the first argument as well as the binary. Will look into the <br>
best way to do that. It'd be nice if it coped with apps that take <br>
additional arguments too - no doubt there'll be a need to associate <br>
flatpak apps with mimetypes. A good solution here could well obsolete <br>
the broken single-instance completely - I'm not sure what use it has <br>
otherwise.<br>
<br>
Cheers,<br>
<br>
Andrew<br>
<br>
On 07/02/2020 18:05, rinigus wrote:<br>
> Hi,<br>
> <br>
> starting as a new thread with the specific subject. As discussed during <br>
> the last meeting, would be great to get Flatpak app ID support by <br>
> Lipstick. Idea is to ensure that a single app is started once. I will <br>
> try to summarize below, please correct me if I am wrong.<br>
> <br>
> As an ID detected by Lipstick can be from desktop file indicated by <br>
> X-Flatpak.<br>
> <br>
> As a helper, we can use flatpak-runner, as it is already. That would <br>
> require flatpak-runner settings its Wayland className to the one <br>
> corresponding to Flatpak ID.<br>
> <br>
> I don't know how to set Wayland className, please advise. Sounded like <br>
> @abranson could help with Lipstick part, as for Wayland parts, I don't <br>
> know who could help.<br>
> <br>
> BTW, if someone wishes to help with Flatpak support, please let me know. <br>
> Right now, I am mainly working on the Angelfish browser to a add some <br>
> missing functionality and polish it. Flatpak runner issues are at <br>
> <a href="https://github.com/sailfishos-flatpak/flatpak-runner/issues" rel="noreferrer" target="_blank">https://github.com/sailfishos-flatpak/flatpak-runner/issues</a> . For <br>
> example, selector (combobox), when opened on such pages as TMO, requires <br>
> some composing. Looks I may have removed too much of the composing <br>
> support from qxcompositor code in flatpak-runner...<br>
> <br>
> As a side note, its unclear why single instance support was dropped from <br>
> Lipstick. Maybe there is some history behind. Otherwise, would be great <br>
> to get it fixed (my personal opinion)<br>
> <br>
> Thank you very much for constructive discussion yesterday!<br>
> <br>
> Cheers,<br>
> <br>
> Rinigus<br>
> <br>
> _______________________________________________<br>
> SailfishOS.org Devel mailing list<br>
> To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a><br>
> <br>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfishos.org</a></blockquote></div>