New App info UI

[Digitalone1]

Given the issues related to the current layout, I made a new one for testing.

@wwmm What do you think? Any hint?

The space should be more optimized with this layout and scrolling doesn't change the app volume (#1211).

@wwmm I take this opportunity to ask another thing. I didn't notice before, but getting rid of GTKMM the locale format is not applied anymore. I see you use ftm library now. Is it intended to not have the locale or you forgot to implement it? Ftm has L key to format to locale.

[wwmm]

What do you think? Any hint?

I think it is fine. I did not see anyway to deal with the scrolling problem without putting the volume slider in the vertical orientation. Something that could also be considered is using a GtkScaleButton. I do not have a reason to keep the volume scale visible all the time. So if you feel it is better with the GtkScaleButton go ahead.

I take this opportunity to ask another thing. I didn't notice before, but getting rid of GTKMM the locale format is not applied anymore. I see you use ftm library now. Is it intended to not have the locale or you forgot to implement it? Ftm has L key to format to locale.

I probably forgot to check this. In the beginning of the port I did not put units in the widgets labels and probably the locale was fine. And as I usually test with English I did not notice the problem.

[jannuary]

Bit of a sketch from me:

I think the sliders are somewhat neccessary to be accessible, but I otherwise tried to simplify the layout and enforce a better visual hierarchy: auxillary info is inline with the player's title, and exclude/block/disable/etc would be in the popover next to the mute button.

[Digitalone1]

I think it is fine. I did not see anyway to deal with the scrolling problem without putting the volume slider in the vertical orientation. Something that could also be considered is using a GtkScaleButton. I do not have a reason to keep the volume scale visible all the time. So if you feel it is better with the GtkScaleButton go ahead.

I think the volume scale button is only good if the volume level is still visible, because if the user has to click a button to see the level, I think it's a regression. Seeing the level and clicking the button to show the slider and change the volume, it's good instead.

I think the sliders are somewhat neccessary to be accessible, but I otherwise tried to simplify the layout and enforce a better visual hierarchy: auxillary info is inline with the player's title, and exclude/block/disable/etc would be in the popover next to the mute button.

Thanks @jannuary. Horizontal volume slider is still a problem because it prevents the correct scrolling. Moreover that layout misses the enable and blocklist commands. Where would you add them? If you want, make another sketch with those commands.

Inline info is a good idea, but arranging the labels horizontally could be tough given the default padding of the GTK4 labels and I don't know how to deal with the separators in the middle. With the default GTK padding, the space between the labels could be very big and not pleasant to see. We could also make a single label and construct a concatenated string. I have to think about that. Anyway binding the label with the parameter is more straightforward from a developer point of view.

Update: No, as I think about it, inline layout seems definitely not good because the information is not contextualized. With the grid we specify the state, the format, the latency, the frequency, etc, while in the inline layout a user could not know what F32LE and 48K means...

[jannuary]

Moreover that layout misses the enable and blocklist commands. Where would you add them?

Given they kinda do similar things as is, they're in a menu near the mute button.

On the label side, it's intended to be a single label with · as a separator. I agree that the labels appear somewhat out of context, although, aside from the format, I don't think this is a large issue.

Not sure what would be a good solution to the sliders though - I think for a mixer-ish UI it's probably best to have large (and as such, fine) sliders and ideally we would just disable the scroll gesture, though no idea how that could be done :/

[wwmm]

Moreover that layout misses the enable and blocklist commands

Unless I misunderstood the sketchy the enable button would be the "dashed square". I am not sure we can make a checkbox that looks like that.

I also think that the triangle would be a menu button tied to a menu where things like the blocklist button could be. This is something that could be done. I do not think the blocklist button needs to be visible all the time. So it is fine to move it to a menu.

[jannuary]

Unless I misunderstood the sketchy the enable button would be the "dashed square".

Oops, yeah, that's supposed to be a symbolic icon of the player ‎😅️

[wwmm]

Oops, yeah, that's supposed to be a symbolic icon of the player

Oh! 😄

[wwmm]

Update: No, as I think about it, inline layout seems definitely not good because the information is not contextualized. With the grid we specify the state, the format, the latency, the frequency, etc, while in the inline layout a user could not know what F32LE and 48K means...

I partially agree. The latency without a label is not going to have a clear meaning for first time users. Same thing to the number of channels. But the state, frequency and format should be self explanatory without labels for the users that actually care about this kind of information.

I like how @jannuary proposal looks. But it would still have the "scroll problem". Unfortunately the volume scale would have to be put in the vertical. I could never found a way to disable its scroll event.

[wwmm]

Anyway binding the label with the parameter is more straightforward from a developer point of view.

I agree. The information we display there comes asynchronously from different signals. Putting all of them on the same label may be a little annoying...

[Digitalone1]

I'm against hiding commands in a menu. It's already being done in the header bar, we have space in the application tab, it's better to use it.

When I see the application list, I'd like to see every information without having to click to show things. If the volume button does not show the volume level, it's useless.

Hiding the blocklist command is useless too because I'd like to know which application is excluded. If I don't want to see an excluded app, I toggle the relative switch in the blocklist menu in the footer bar.

I partially agree. The latency without a label is not going to have a clear meaning for first time users. Same thing to the number of channels. But the state, frequency and format should be self explanatory without labels for the users that actually care about this kind of information.

I like how @jannuary proposal looks. But it would still have the "scroll problem". Unfortunately the volume scale would have to be put in the vertical. I could never found a way to disable its scroll event.

The problem is that if we show things horizontally, the vertical space is reduced. If it's reduced, the volume vertical scale is so little that's useless. We can't make it horizontally because of the scroll issue, so the last option would be putting an horizontal spinbutton somewhere for the volume.

Or maybe a volume button, but with a syncronized label to show the level. In this case I wonder if the scale will move the neighbor widgets or it will appear over them. Because if it will change the size, we can't do it vertical because the app row will change the height.

[wwmm]

What do you think? Any hint?

@Digitalone1 looking at your image again I think it would be nice to keep the mute button as a toggle as it is now. The functionality is obviously the same with a checkbutton. It just doesn't feel as interesting to the eyes.

I imagine you changed it to a checkbutton because with the slider in the vertical there won't be enough vertical space to do the same we do in the horizontal. Tough call indeed.

[Digitalone1]

Unfortunately the next week I don't have so much time to dedicate to EasyEffects.

Anyway I leave here some points to resume. Feel free to add suggestions if don't agree.

• No options/features in menus because it's not immediate at first sight, it's not the header bar, we have space to use.
• The volume level should be visible even if the scale is hidden.
• The scale, if always visible, should be vertical to solve the scroll issue.
• The mute command has to be a toggle button like it is currently.
• The blocklist command should be visible because if an app is not processed, should be immediately visible why it's not handled by our pipeline, otherwise could be confusing and clicking to show a menu is an extra operation I think useless since we have space to fit. Consider also that we can already hide blocklisted apps. So if others do not hide them, they want to see the blocklist state.
• Aside the states running, stopped, etc., which are self explanatory for the app, other parameters should have a label that contextualize their meaning (format, frequency, latency...).

[wwmm]

Aside the states running, stopped, etc., which are self explanatory for the app, other parameters should have a label that contextualize their meaning (format, frequency, latency...).

We can keep a label for them. My point was only t that hey are not super dependent on a label for first time users like in the latency case.

[Digitalone1]

@wwmm do you know if there's a way to limit the size of a widget? As I remember, there's no such thing in GTK4 so the widget occupy its size or it can be expanded to fit all the space. We can force a fixed size, so the horizontal slider covers only a part of the app row.

An hack we could apply is to use an horizontally expanded 3 column homogeneous grid, so the slider will fit only 1/3 of the row, and the rest can be used to show other widgets.

[wwmm]

do you know if there's a way to limit the size of a widget?

I did not look at this in gtk4. But I think labels should still accept a fixed amount of characters in their width. The question is how this approach will look in different screen sizes. So maybe your second idea is better.

An hack we could apply is to use an horizontally expanded 3 column homogeneous grid, so the slider will fit only 1/3 of the row, and the rest can be used to show other widgets.

Our bottom panel is implemented with a GtkCenterBox that does exactly that

easyeffects/data/ui/effects_box.ui

Line 22 in 6a64218

<object class="GtkCenterBox">

.

[Digitalone1]

@wwmm @jannuary what do you think?

I'd like to modify the slider value to show some space padding (like plugin in/output level sliders) and the % sign.

[wwmm]

what do you think?

Humm... I think I prefer the approach we currently use because the stream information is centered in the row. In the image above once the width is large there are many things packed together in the left when there is plenty of space in the middle.

If the idea is keeping the slider in the horizontal direction but smaller so that it is easier to scroll the list I think it will be better to keep our current approach but forcing the slider maximum width to be the same of the block with the stream information. In other words it would be better to just shrink it while keeping the current position instead of putting it to the right with a very smaller size.

[Digitalone1]

Humm... I think I prefer the approach we currently use because the stream information is centered in the row. In the image above once the width is large there are many things packed together in the left when there is plenty of space in the middle.

So the problem is only the empty space in the middle or also the things "packed"? Because if it's only the former, I can just center the whole block. Should be easy. I can make a test screenshot later.

If the idea is keeping the slider in the horizontal direction but smaller so that it is easier to scroll the list I think it will be better to keep our current approach but forcing the slider maximum width to be the same of the block with the stream information. In other words it would be better to just shrink it while keeping the current position instead of putting it to the right with a very smaller size.

The slider would take the majority of the screen size (in most of cases, except very large screen which are rare) even if it takes the same width of the stream info grid. If the target is to facilitate the scroll, the previous layout is better because it takes only the 25% of the horizontal width (with the hack of 4 homogeneous column grid with the first 3 spanned). It was taken in consideration to completely hide it behind a button which is not good in my opinion, shrinking it at 25% in the right side could be a good compromise. The user would have the 75% of the window to scroll, in most cases greater than the size of the layout with the slider restricted to the width of the stream info grid.

I was skeptical about the horizontal stream info, even because the example by jannuary was a single label. But having tested the layout shown before putting the labels in the same box, swapping the dim class on the data and setting a specific margin between different info feels much better. Do you prefer the grid?

[Digitalone1]

Or with the app icon aligned to the left:

Personally I prefer the latter.

[Digitalone1]

Comparison with wide and low width windows:

Slider is too tiny for my taste in low width, maybe better changing the grid to 3 homogeneous columns, so it takes 33% and 66% is still available for the scrolling.

@wwmm what do you think? I prefer this layout and the stream data in one only row feels better than the current grid. Can't do better than that. Let me know.

[jannuary]

I don't think squeezing the volume slider to the point where it's impossible tiny is a good solution to the problem, to be honest.

Otherwise, this is not bad - I like the player info, though I wouldn't necessarily put Enable/Exclude in spotlight.

[Digitalone1]

In this post I describe what personally is not good about the current layout.

• The enable switch is not intuitive at first sight. We do know what it does because we use the app by years, but could be confusing for the new user. I don't care about Gnome Circle, but they were right about that. We need something to tell the user what it does and the check button with the label is good in doing this.
• I don't like Add the blocklist label. I think we need something better to describe that the application should not be processed by EasyEffects even if the Process All option is enabled. I though Exclude, but maybe there's something better. I'm open to suggestions here.
• Even if we restrict the slider to the stream data width, on low width windows there's still no space to scroll, as shown above.

I don't think squeezing the volume slider to the point where it's impossible tiny is a good solution to the problem, to be honest.

@jannuary You're right, this is a limitation of GTK. If we could specify a fixed size would be better, but the only way to control it in our situation is to make a hack like the grid homogeneous column. Maybe could be better at 1/3 (33%) or 2/5 (40%) of the horizontal width (in the screenshots I posted was 25%).

Otherwise, this is not bad - I like the player info, though I wouldn't necessarily put Enable/Exclude in spotlight.

Where would you put them? I thought putting them in the same section was good because they control how EE handles the stream.

[Digitalone1]

This is the slider at 2/5 (40%).

The size above is the lowest before GTK don't shrink anymore and the horizontal scrolling is enabled (and the horizontal scroll does not work, this is another issue to resolve).

Anyway the slider seems to have a reasonable size and quite 60% of horizontal width remains to scroll.

[wwmm]

I don't like Add the blocklist label. I think we need something better to describe that the application should not be processed by EasyEffects even if the Process All option is enabled. I though Exclude, but maybe there's something better. I'm open to suggestions here.

I have no complaints about this change. The new label is shorter and gets the job done. This is good.

The enable switch is not intuitive at first sight. We do know what it does because we use the app by years, but could be confusing for the new user. I don't care about Gnome Circle, but they were right about that. We need something to tell the user what it does and the check button with the label is good in doing this.

While I agree with the "not intuitive" part in my opinion the checkbuttons do not feel a superior solution from a visual point of view. Specially when the pack of labels with stream information is super close to them. I wonder how it would look with a GtkToggleButton instead. It is not the end of the world to remove the GtkSwitch. But it made the enable button "special". Now it visually has the same importance of the exclude button what again, in my opinion, is weird. But it is not the end of the world...

What I really do not like is this new volume scale position. Honestly between this and having it hidden in a menu I prefer the menu. Let me take a look again at the "scroll situation". I've got close to a solution in the last attempt. We just have to find a way to make gtk to completely ignore the GtkScale when it comes to scroll events and sending them to the parent widget.

[Digitalone1]

What I really do not like is this new volume scale position. Honestly between this and having it hidden in a menu I prefer the menu. Let me take a look again at the "scroll situation". I've got close to a solution in the last attempt. We just have to find a away to make gtk to completely ignore the GtkScale when it comes to scroll events and sending them to the parent widget.

Okay, let me know. If that scroll issue couldn't be solved, I could test with the GTK volume button and adding a label to show the volume level.

[wwmm]

I wonder if we shouldn't consider using a GtkSpinButton to handle the volume instead of the GtkScale. The scale is more elegant in this task but as it is inside a list its scroll conflicts with the list scroll. Maybe this is a sign we should stop fighting against the toolkit and using another widget. Specially if we are going to change buttons and their positions along the way anyway. Maybe with the new approach a spinbutton will look good in this task.

[Digitalone1]

No problem. The next week I will do other attempts with:

• Enable GtkToggleButton
• Exclude GtkCheckButton
• Volume GtkSpinButton

For stream info data, I will try both grid and horizontal labels.

[Digitalone1]

@wwmm @jannuary What do you think? Do not pay attention to wrong dimmed long description, it's a known gtk4 bug, already reported.

To me it's OK.

[wwmm]

Now that I can see the togglebutton and the checkbutton side by side I have the feeling that the togglebutton may be too heavy on the eyes in this location. Or at least it seems so with the dark theme. So it is probably better to keep both as a checkbutton.

While I agree that labels for the information fields will help new users now that they are all on the same line somehow it feels we have too much labels there. Maybe it is because I do not use dark themes. But I still think that visually this line would look better only with the values instead of having words like format or rate together.

I think I need to some time to meditate on this... I will pin this issue so it gets more visibility and maybe more ideas. Although we would be fixing the issues that were pointed by some people I still have the feeling that visually we will be giving one step back.

[Digitalone1]

Maybe a speaker icon for output streams and a microphone for input streams.

Before the release I'd like also to see a message when the list is empty to inform the user EasyEffects is not managing any stream.

Gnome File is doing this for empty folders:

I don't know which would be the correct sentence. Maybe Empty List: No streams handled by EasyEffects

@wwmm any thought?

[Digitalone1]

I wonder also if Enable could be better than Activate. @wwmm why did you choose Activate?

[wwmm]

why did you choose Activate?

No special reason. It seemed better at the time but after some time using it there is no difference to me. Both names are fine.

Maybe a speaker icon for output streams and a microphone for input streams.

As we already use these icons a lot I think it is better to use an icon that gives the "media idea". I do not think that we have to use different icons for each pipeline. If we can it is better. But it is not a problem to have the same generic media icon on both sides.

I don't know which would be the correct sentence. Maybe Empty List: No streams handled by EasyEffects

I also do not have a good sentence in my head right now. Let's start with the one you thought. This is the kind of thing that can be easily changed in the future.

[Digitalone1]

Searching in Adwaita icon folder I see

• applications-multimedia-symbolic
• multimedia-player-symbolic

which could be two good candidates.

[wwmm]

At least to me applications-multimedia-symbolic is the better option. The other makes me think about a smartphone.

[Digitalone1]

I can't look at the code right now, but I'd like to get an hint on how this could be done in the future.

I was thinking about adding a vertically expanded row with the empty state text. That row would be shown when the app list count is 0, otherwise it's hidden. Is it doable or we have to look at another hack?

I don't even know if there's a special class to show the text in a bigger size, similarly how Gnome File is doing.

[wwmm]

I was thinking about adding a vertically expanded row with the empty state text.

I think there is a container that can have only one child visible at a time. With it we could select what is visible depending on whether there is app or not. It does not have to be something that expands. I will try to remember this container name.

[wwmm]

Maybe this one https://docs.gtk.org/gtk4/class.BinLayout.html. But it may be a good idea to see how nautilus is implementing this.

[wwmm]

This is the nautilus commit that added the Folder is Empty https://gitlab.gnome.org/GNOME/nautilus/-/commit/69b5caad316bd39d4f13010e1dcfe7296f69ff68. They seem to be adding an overlay.

[wwmm]

The overlay approach is easy to implement but for some reason I do not understand it goes over widgets that are outside its parent container

Somehow this does not happen on Nautilus... I wonder why...

[wwmm]

There is a way to avoid the problem

I had to set gtk_overlay_set_clip_overlay(self->overlay, GTK_WIDGET(self->overlay_empty_list), 1). But it does not seem nautilus needed to do this...

[wwmm]

@Digitalone1 the message we talked about before seems too long

[wwmm]

As the code is working I have updated the master branch with a shorter temporary message until we have a better idea

[Digitalone1]

It does not have to be the same size as Nautilus. Try to reduce the scale. I suggest to apply also the wrap property

<property name="wrap-mode">word-char</property>

You could also add the default app icon when there's no icon available.

[wwmm]

I suggest to apply also the wrap property

I wasn't thinking about the wrapping. It feels like it is too much text to read in a situation where the message should be more direct.

Try to reduce the scale.

In nautilus they use <class name="large-title" />. I will try to see if there is something smaller.

[Digitalone1]

At this point let's also add a No Effects Applied when the plugin stack is empty (but in the plugin view, not in the plugin stack itself).

[wwmm]

The class title-3 combined with dim-label and the icon pixel_size set to 64 instead of 128 seem more reasonable

At this point let's also add a No Effects Applied when the plugin stack is empty (but in the plugin view, not in the plugin stack itself).

Ok. If we are lucky the same approach can be used there too.

You could also add the default app icon when there's no icon available.

I will try to remember to do this too. But I am not sure if there will be time for this today.

[Digitalone1]

Maybe it's also better to change the Effect icon in emblem-music-symbolic

And use this icon for the empty state in Effects tab.

[wwmm]

Maybe it's also better to change the Effect icon in emblem-music-symbolic emblem-music-symbolic

New version

but in the plugin view, not in the plugin stack itself

I wonder if space is not going to be a problem. In the stack location there is plenty. But not so much in the plugins list panel.

[Digitalone1]

@wwmm I was talking about the Effect button icon, not the empty state icon in the app list (which I think the previous was better).

I wonder if space is not going to be a problem. In the stack location there is plenty. But not so much in the plugins list panel.

I was talking about the parent widget where the plugin commands are shown, not the plugin list side panel.

[wwmm]

I was talking about the Effect button icon, not the empty state icon in the app list (which I think the previous was better).
I was talking about the parent widget where the plugin commands are shown, not the plugin list side panel.

Oh... That is why we should not write code minutes before going to lunch 😄

As the plugins controls are inside a GtkStack I thought you were suggestting to put the message over the listview at the left side.

New version

[jannuary]

Let's not reinvent the wheel here: Adw.StatusPage

[wwmm]

Thanks @jannuary! As I was reading the nautilus code I just did the same thing. I did not even consider the possibility Adwaida could have a class for this

[Digitalone1]

So what remains for a new release? Only the StatusPage for Effects tab and the default icon for application with no icon?

[wwmm]

So what remains for a new release? Only the StatusPage for Effects tab and the default icon for application with no icon?

I think it would be good to have these 2 in the next minor release.

[Digitalone1]

I noticed a weird thing about the selectable property with app name and description.

I launch the application and change the tab, then return to the applications list and the app name is selected even if I didn't select it with the cursor.

I didn't expect this behavior, it occurs frequently, but only one time after I open the window. Might be a GTK issue, anyway we could consider to remove the selectable property even if I thought It was useful for the user to copy the app name...

[wwmm]

the app name is selected even if I didn't select it with the cursor.

Strange. It did not happen here. But as we do not need these labels to be selectable I think we could just disable this property.

[wwmm]

I think we can close this.