Hi Andrew, in the case of flatpaks, the command is somewhat more complex:
flatpak-runner options-for-flatpak-runner FLATPAK_ID options-for-running-command 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. In the case of SFOS, the architecture is as follows: Wayland-0 - Lipstick - Flatpak-Runner - Wayland-1 - Flatpacked app 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. 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) 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. 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. Cheers, Rinigus On Mon, Feb 10, 2020 at 2:36 PM Andrew Branson <andrew.bran...@jolla.com> wrote: > Hi Rinigus, > > I don't think the Wayland window className method is the right thing for > you - on further investigation this is used by aliendalvik because of > its unusual shared window handling. Your flatpak apps wouldn't do that > sort of thing, so we can handle this more simply. > > I did find where the support for X-Nemo-Single-Instance lives. It seems > to only interact with apps using the invoker: > > > https://git.sailfishos.org/mer-core/libcontentaction/blob/master/src/exec.cpp#L77 > > From the other TJC question about python3, it looks like this might > still be broken, but as you're not using the invoker I don't think it > would help you as it stands. More investigation is needed into why it's > not working, but I think that patch might be too simple. > > I think what's needed for flatpak and other launchers is some directive > to check the first argument as well as the binary. Will look into the > best way to do that. It'd be nice if it coped with apps that take > additional arguments too - no doubt there'll be a need to associate > flatpak apps with mimetypes. A good solution here could well obsolete > the broken single-instance completely - I'm not sure what use it has > otherwise. > > Cheers, > > Andrew > > On 07/02/2020 18:05, rinigus wrote: > > Hi, > > > > starting as a new thread with the specific subject. As discussed during > > the last meeting, would be great to get Flatpak app ID support by > > Lipstick. Idea is to ensure that a single app is started once. I will > > try to summarize below, please correct me if I am wrong. > > > > As an ID detected by Lipstick can be from desktop file indicated by > > X-Flatpak. > > > > As a helper, we can use flatpak-runner, as it is already. That would > > require flatpak-runner settings its Wayland className to the one > > corresponding to Flatpak ID. > > > > I don't know how to set Wayland className, please advise. Sounded like > > @abranson could help with Lipstick part, as for Wayland parts, I don't > > know who could help. > > > > BTW, if someone wishes to help with Flatpak support, please let me know. > > Right now, I am mainly working on the Angelfish browser to a add some > > missing functionality and polish it. Flatpak runner issues are at > > https://github.com/sailfishos-flatpak/flatpak-runner/issues . For > > example, selector (combobox), when opened on such pages as TMO, requires > > some composing. Looks I may have removed too much of the composing > > support from qxcompositor code in flatpak-runner... > > > > As a side note, its unclear why single instance support was dropped from > > Lipstick. Maybe there is some history behind. Otherwise, would be great > > to get it fixed (my personal opinion) > > > > Thank you very much for constructive discussion yesterday! > > > > Cheers, > > > > Rinigus > > > > _______________________________________________ > > SailfishOS.org Devel mailing list > > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org > > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
