Feature request: Multiple instances

[noppa]

First of all, thanks for Clapper! VLC and MPV both did not like it at all when I moved to Gnome 40+Wayland+Nvidia combo, but Clapper has been rock solid and fast.

When I open a video file in Clapper and there already is a video playing, the new video replaces the previously opened video. If possible, it would be nice if there was an option to make it so that opening a new video launches a new instance instead, and allows you to watch multiple videos at the same time. This would be similar to VLC's "Allow only one instance" option.

Playing multiple videos at the same times is sometimes useful when the content doesn't require 100% attention to it, like a lecture video or something, and you want to do a bit of multitasking.

[Rafostar]

It would certainly be nice usability wise, but due to single threaded nature of GTK and OpenGL, rendering two different windows from single process at once would be bad performance wise unfortunately. I will put this on hold until we either have some method of rendering that doesn't hinder performance much or GTK4 obtains parallel rendering ability (there was some progress on that).

[folknor]

One of my personality subtraits is known as being a "prospector", which means I don't focus on one thing for extended periods. During the day I might want to have 3 videos open, though just one playing at a time - for example one with a TV series, one with a movie/doc/standup, and one with a concert, and whenever I want a break from what I'm doing I'll hit play on the one I most want to continue watching.

It might take me 4 days to watch a normal movie. I actually enjoy that more than watching a movie or a long TV episode in one sitting. Not just a bit more. A lot more.

I tried (again, I've tried before as well) switching from celluloid to clapper today, and this prevents me from doing that. I don't care about the performance. Presumably whatever performance I got from having 3x celluloid windows open will be the same as 3x clapper windows?

[Rafostar]

I don't care about the performance. Presumably whatever performance I got from having 3x celluloid windows open will be the same as 3x clapper windows?

Remember that we use entirely different backend (GStreamer) and our way of integrating video within GTK4 nowadays is also much different. Hard to compare the two. Might be better, might be worse. Will also vary with HW most likely. And as I mentioned before:

I will put this on hold until we either have some method of rendering that doesn't hinder performance much or GTK4 obtains parallel rendering ability (there was some progress on that).

The first part is half-done since Clapper 0.5.0 version, we can still improve performance further with VAAPI in (I hope) not too distant future. In the meantime GTK4 devs should be able to further polish and improve their stuff (like frame clock, add parallel rendering, etc.).

I.e: I consider this a nice/useful feature, but there is still some other work both here and in GTK that should happen first, so the performance does not take a too big hit with multiple windows.

[josch]

It would certainly be nice usability wise, but due to single threaded nature of GTK and OpenGL, rendering two different windows from single process at once would be bad performance wise unfortunately.

Is there a reason against spawning an entirely new process with its own window?

Similar to @folknor my scenario where I need this is: I'm watching something, then somebody sends me a link via chat or email or my daughter wants to watch a video with me. Right now I have to pause my old video, write down the timestamp somewhere, then start the new video and then (after finishing watching the new video) open the old video again (sometimes i forget writing down the link to the old video so i have to search for that as well) and jump to the timestamp i noted down. Then I (again) have to select the audio and subtitle track I already set the first time I started watching the video. I don't need to have multiple videos playing at the same time, so I don't think performance is of any concern here, no?

I just need a more convenient way to pause one video, play another video, then resume the first.

[Rafostar]

Is there a reason against spawning an entirely new process with its own window?

It does not seem to be a supported mechanic under GApplication or at least I haven't found any way to do that.

I don't need to have multiple videos playing at the same time (...) I just need a more convenient way to pause one video, play another video, then resume the first.

Then perhaps this issue/feature request is more for you: #60

[josch]

Is there a reason against spawning an entirely new process with its own window?

It does not seem to be a supported mechanic under GApplication or at least I haven't found any way to do that.

If anybody else is oblivious about how gio Applications work (just as I was before reading the docs): if you start an application with the same id as an already running application, then instead of opening a new window and running a new instance, the already running instance is contacted via dbus and will carry out the operation given on the command line, while the new process will quit and put you back on the terminal. One way to prevent a gio application to behave like that is to pass no id when initializing it like this:

--- a/src/app.js
+++ b/src/app.js
@@ -16,7 +16,7 @@ class ClapperApp extends Gtk.Application
     _init()
     {
         super._init({
-            application_id: Misc.appId,
+            application_id: null,
             flags: Gio.ApplicationFlags.HANDLES_OPEN,
         });
 

With that patch, every time I start a new clapper instance, a new window is opened instead of the contents of the old one being replaced. But this is not a real solution, just an attempt at explaining (also for future me) why clapper currently behaves as it does.

I don't need to have multiple videos playing at the same time (...) I just need a more convenient way to pause one video, play another video, then resume the first.

Then perhaps this issue/feature request is more for you: #60

I wonder how such a feature would work with videos that clapper played via gtuber instead of a local file...

[Rafostar]

If anybody else is oblivious about how gio Applications work (just as I was before reading the docs): if you start an application with the same id as an already running application, then instead of opening a new window and running a new instance, the already running instance is contacted via dbus and will carry out the operation given on the command line, while the new process will quit and put you back on the terminal.

This is something I knew, since I handle that DBUS signal by opening another video and bringing window to front. I did not expect that null would work through. Although this seems pretty hacky and is against how Flatpak app is supposed to be written, where this talking to the container over DBUS is crucial for the container. Nice discovery through.

As stated some time ago, I do plan to have an option to have multiple windows, but its not ready yet as there are some other things that I am (unfortunately slowly) taking care of before adding this functionality.

I wonder how such a feature would work with videos that clapper played via gtuber instead of a local file...

Ideally, someone could make a fully fledged GTK4 youtube client that let's you browse videos, comment on them, have login and all other features, while utilizing Clapper + gtuber as a video playback backend (a complete browser replacement). This way I could still work on backend here and have someone else working on a frontend. Finding anyone volunteering for it will be hard through and I alone am simply unable to do everything (still have live and work).

[sp1ritCS]

If anybody else is oblivious about how gio Applications work (just as I was before reading the docs): if you start an application with the same id as an already running application, then instead of opening a new window and running a new instance, the already running instance is contacted via dbus and will carry out the operation given on the command line, while the new process will quit and put you back on the terminal.

This is something I knew, since I handle that DBUS signal by opening another video and bringing window to front. I did not expect that null would work through. Although this seems pretty hacky and is against how Flatpak app is supposed to be written, where this talking to the container over DBUS is crucial for the container. Nice discovery through.

The G_APPLICATION_NON_UNIQUE flag passed to g(tk)_application_new is the proper way to do this 😉

[josch]

Hah, nice find, thank you! I'm now running clapper with this patch:

--- a/src/app.js
+++ b/src/app.js
@@ -17,7 +17,7 @@ class ClapperApp extends Gtk.Application
     {
         super._init({
             application_id: Misc.appId,
-            flags: Gio.ApplicationFlags.HANDLES_OPEN,
+            flags: Gio.ApplicationFlags.HANDLES_OPEN | Gio.ApplicationFlags.NON_UNIQUE,
         });
 
         this.doneFirstActivate = false;

Could this be made configurable? Do you see a downside of passing the NON_UNIQUE flag?

[sp1ritCS]

Could this be made configurable? Do you see a downside of passing the NON_UNIQUE flag?

well it doesn't own an instance on the bus anymore (duh). The flatpak might break (it might also not, you never really know) since it relies somewhat heavily on dbus. Also anything else that needs the bus will probably fail, so MPRIS will not work for all but the oldest instance, also the dconf backend of gsettings might fail?

[josch]

Since I neither need flatpak nor mpris support, I opened PR #325. If desired, this allows the user to start clapper with NON_UNIQUE while also warning that this is required for flatkpak and mpris.

[sp1ritCS]

@josch having this exposed over a GSettings toggle seems slighty dangerous, since GSettings might rely (depending on the used backend) on dbus. Maybe a command line toggle or env var could work too?