binded_output_name doesn't work correctly with counter_multi example

[MalpenZibo]

Settings binded_output_name in the counter_multi example doesn't produce any change.

The interface is rendered in all available monitors every time.

[Decodetalkers]

Yes, that is just designed for single layershell

[MalpenZibo]

And is not possible to have this feature also for multi-layer applications?

I created a fork with a "very horrible" workaround that seems to work. I notice that right now in the case of multiwindow application the surface is created inside a for on every possible monitor

for (_, output_display) in displays.iter() {
                let wl_surface = wmcompositer.create_surface(&qh, ()); // and create a surface. if two or more,
                let layer_shell = globals
                    .bind::<ZwlrLayerShellV1, _, _>(&qh, 3..=4, ())
                    .unwrap();

Changing this part is possible to use the specified binded_output_name.

Would be very nice to have an enum like:

enum Output {
  Active, // create the surface on the "active" monitor (the one where I launch the application)
  All, // create the surface on every possible monitor
  Target(String) // create the surface on the specified monitor

[Decodetalkers]

And is not possible to have this feature also for multi layer application?

This feature is used to make the single layershell to show on the target screen, the multi layer application was designed to always shown on multiple screens.. but it is easy to make it work. I think it is easy. What is your use case?

[Decodetalkers]

https://github.com/waycrate/exwlshelleventloop/blob/master/layershellev%2Fsrc%2Flib.rs#L1935-L1935

https://github.com/waycrate/exwlshelleventloop/blob/master/layershellev%2Fsrc%2Flib.rs#L1662-L1665

Related logic is these two parts.. you can change these logic to is_single or the target screen is some

[Decodetalkers]

And is not possible to have this feature also for multi-layer applications?

I created a fork with a "very horrible" workaround that seems to work. I notice that right now in the case of multiwindow application the surface is created inside a for on every possible monitor

for (_, output_display) in displays.iter() {
                let wl_surface = wmcompositer.create_surface(&qh, ()); // and create a surface. if two or more,
                let layer_shell = globals
                    .bind::<ZwlrLayerShellV1, _, _>(&qh, 3..=4, ())
                    .unwrap();

Changing this part is possible to use the specified binded_output_name.

Would be very nice to have an enum like:

enum Output {
  Active, // create the surface on the "active" monitor (the one where I launch the application)
  All, // create the surface on every possible monitor
  Target(String) // create the surface on the specified monitor

This feature is good, you can make a pr for me. I will accept it. Sorry I cannot make this feature because these days my second screen is broken.. Now I only have one screen.. sorry

[MalpenZibo]

I had to create a status bar that should be able to open other layer on the same monitor.

Would be nice to have the ability to spawn the status bar on every monitor or on a specific monitor.

[Decodetalkers]

#74

Can you test this pr? Maybe it can fix your problem

[MalpenZibo]

I will test it as soon as I can! Thank you soon much!

[MalpenZibo]

It works!
In my opinion, I will have extended the functionality to the single-layer application (right now I can set the "monitor_all_screen" to true in the "counter" example but nothing happens).

Also, I prefer to use the StartMode enum directly in the settings. Right now I can set both monitor_all_screen and binded_output_name but binded_output_name has the priority.

Having in the settings something like:

enum Output { // to replace StartMode
  Active, // binded_output_name: None, monitor_all_screen: false
  All, // binded_output_name: None, monitor_all_screen: true
  Target(String) // binded_output_name: Some, monitor_all_screen: false
}

seems cleaner for me.

But maybe you don't want to break the current lib API 😅

I notice some lag when I try to open a new window using monitor_all_screen but probably is was there also before these changes

[Decodetalkers]

It works! In my opinion, I will have extended the functionality to the single-layer application (right now I can set the "monitor_all_screen" to true in the "counter" example but nothing happens).

Also, I prefer to use the StartMode enum directly in the settings. Right now I can set both monitor_all_screen and binded_output_name but binded_output_name has the priority.

Having in the settings something like:

enum Output { // to replace StartMode
  Active, // binded_output_name: None, monitor_all_screen: false
  All, // binded_output_name: None, monitor_all_screen: true
  Target(String) // binded_output_name: Some, monitor_all_screen: false
}

seems cleaner for me.

But maybe you don't want to break the current lib API 😅

I notice some lag when I try to open a new window using monitor_all_screen but probably is was there also before these changes

I think your is better.. but then there will be a useless setting for single-layer application..

[MalpenZibo]

Well, the single-layer application doesn't have support to spawn multiple layers, so the view function, for example, doesn't have the id as a second parameter. But maybe someone wants to have the same layer rendered on multiple monitors even without the possibility to open a new layer.

[Decodetalkers]

Well, the single-layer application doesn't have support to spawn multiple layers, so the view function, for example, doesn't have the id as a second parameter. But maybe someone wants to have the same layer rendered on multiple monitors even without the possibility to open a new layer.

ok, I have made some adjustment now, you can take a look

[MalpenZibo]

Very nice!
As I said before I would leave the possibility for a single-layer application to render in every monitor but I notice that there's an assert to prevent that configuration. Anyway is up to you the choice 😄. My use case is for a multilayer application so I'm good

Thank you so much

[Decodetalkers]

Ok, I will merge it, but I need help in another pr, about the scale.. I cannot solve that problem