New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic Transparency #513

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@franglais125
Contributor

franglais125 commented Jun 1, 2017

Here is a proposal to imitate the work done upstream on the top bar. The idea is that the dash blends in more uniformly, by behaving according to the top bar's new transparency when 'free-floating'.

Default behavior
As of Gnome 3.26, the top bar will be only 20% opaque by default. Hence, as a proof-of-concept, I have modified the default behavior for the dash. I have lowered the default opacity from 80% to 20% (as upstream), and the transparency logic is now a bit different. So far we assumed that the dash was opaque, unless the opacity setting was used.

I have now inverted this logic: the dash is 20% opaque, unless the user decides to set the opacity (permanently) to something else.

Option
I did it this way for simplicity, but we can of course change how this is done. The setting could be a combo-box with a few options like "Default, Automatic, Permanent" or something like that.

Regarding the code
I tried to keep the _updateSolidStyle() function as close as possible to upstream, so that it's easier to update if something changes. There are of course some differences stemming from the dash's complexity:

  • The dash is not only on the primary monitor
  • The dash has a border (that can have a different opacity)
  • The dash can have a custom color

Also, I tried to limit the number of operations on this function, as it gets called very often, hence having an impact on CPU time and responsiveness.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Jun 6, 2017

Contributor

@micheleg did you get a chance to try this?

I'm travelling at the moment, but I can look at this again later this week.

Contributor

franglais125 commented Jun 6, 2017

@micheleg did you get a chance to try this?

I'm travelling at the moment, but I can look at this again later this week.

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Jun 6, 2017

Owner

Haven't tried it yet. I have been trying Gnome 3.25.x and I have to say I don't seem to particularly enjoy that feature on the panel, however I think it makes sense to try to be consistent. I'll try to have a look at it. Before this I'd like to try to merge the previews on click branch

Owner

micheleg commented Jun 6, 2017

Haven't tried it yet. I have been trying Gnome 3.25.x and I have to say I don't seem to particularly enjoy that feature on the panel, however I think it makes sense to try to be consistent. I'll try to have a look at it. Before this I'd like to try to merge the previews on click branch

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Jun 6, 2017

Contributor

Sounds good. Let me know if there is any remaing to-do on the previews PR.

Contributor

franglais125 commented Jun 6, 2017

Sounds good. Let me know if there is any remaing to-do on the previews PR.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Jun 14, 2017

Contributor

Branch updated. It now includes a checkbutton, and the dynamic transparency uses the alpha value selected by the user. Very similar to #62 .

screenshot from 2017-06-14 12-13-52

Contributor

franglais125 commented Jun 14, 2017

Branch updated. It now includes a checkbutton, and the dynamic transparency uses the alpha value selected by the user. Very similar to #62 .

screenshot from 2017-06-14 12-13-52

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 6, 2017

Collaborator

I did test your branch and quickly gloss over your changes. They look good to me, but I'm not that familiar with the code itself :)

However, I have a suggestion: with this dynamic transparency, it removes any possiblity to have the launcher (especially in intellihide mode) not fully opaque once a window touches it.
Can't it be better to have 2 transparency values? Like, one when no window touches the dock, and another one when a window touches the dock (as you can modify in the upstream css). Or maybe compute one value from the other, what do you think?

Collaborator

didrocks commented Sep 6, 2017

I did test your branch and quickly gloss over your changes. They look good to me, but I'm not that familiar with the code itself :)

However, I have a suggestion: with this dynamic transparency, it removes any possiblity to have the launcher (especially in intellihide mode) not fully opaque once a window touches it.
Can't it be better to have 2 transparency values? Like, one when no window touches the dock, and another one when a window touches the dock (as you can modify in the upstream css). Or maybe compute one value from the other, what do you think?

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 6, 2017

Collaborator

The second idea (I'm happy to contribute btw, as I think we'll need to cherry-pick this soon as well for ubuntu-dock) is to only apply this settings in non intellihide mode.
Intellihide would just set the launcher with the selected transparency level, as by definition, no window can really "touch" it and it will then only appear above, or being far from any window.

Collaborator

didrocks commented Sep 6, 2017

The second idea (I'm happy to contribute btw, as I think we'll need to cherry-pick this soon as well for ubuntu-dock) is to only apply this settings in non intellihide mode.
Intellihide would just set the launcher with the selected transparency level, as by definition, no window can really "touch" it and it will then only appear above, or being far from any window.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 6, 2017

Contributor

@didrocks thanks a lot for the feedback! I keep forgetting to test intellihide when I submit PRs, as it's not something I use regularly...

Before trying to implement one of your ideas, let me try to see if I can fix the issue at its root: reacting to intellihide animations in the first place.

I included a commit to address this, I'm not claiming it is fixed, but it is perhaps better. What do you think? [ce76087].

Contributor

franglais125 commented Sep 6, 2017

@didrocks thanks a lot for the feedback! I keep forgetting to test intellihide when I submit PRs, as it's not something I use regularly...

Before trying to implement one of your ideas, let me try to see if I can fix the issue at its root: reacting to intellihide animations in the first place.

I included a commit to address this, I'm not claiming it is fixed, but it is perhaps better. What do you think? [ce76087].

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 6, 2017

Contributor

@didrocks Sorry for the change, I actually found away of doing this that is cleaner and more self-contained. Take a look here [792340a].

Is this good enough?

Contributor

franglais125 commented Sep 6, 2017

@didrocks Sorry for the change, I actually found away of doing this that is cleaner and more self-contained. Take a look here [792340a].

Is this good enough?

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 7, 2017

Owner

I'm still a bit confused by how this should behave. I'm personally distracted by having the top panel and the dash background changing transparency, expecially independently, while moving windows around....

If I have undertood the issue and correctly interpreted @didrocks suggestion, I think that:

  • The two transparency status should probably be defined by css classes. The setting to enable/disable the dynamic transparency should be independent from the the opacity settings.
  • The opacity settngs should overwrite the opaque state (this is consistent with the origin of such settings, which was meant to ensure the dock is not transparent when using custom themes). For the transparent state I would use the top panel one in the default theme (or somethig fitting the defualt theme)
  • in intellihide mode the transparency could probably not be dynamic (constantly opaque). However, latest @franglais125 implementation seems to work quite well for me.
Owner

micheleg commented Sep 7, 2017

I'm still a bit confused by how this should behave. I'm personally distracted by having the top panel and the dash background changing transparency, expecially independently, while moving windows around....

If I have undertood the issue and correctly interpreted @didrocks suggestion, I think that:

  • The two transparency status should probably be defined by css classes. The setting to enable/disable the dynamic transparency should be independent from the the opacity settings.
  • The opacity settngs should overwrite the opaque state (this is consistent with the origin of such settings, which was meant to ensure the dock is not transparent when using custom themes). For the transparent state I would use the top panel one in the default theme (or somethig fitting the defualt theme)
  • in intellihide mode the transparency could probably not be dynamic (constantly opaque). However, latest @franglais125 implementation seems to work quite well for me.
@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 7, 2017

Contributor

in intellihide mode the transparency could probably not be dynamic (constantly opaque). However, latest @franglais125 implementation seems to work quite well for me.

I was thinking a bit about this too. The problem I saw with having the dock being opaque when in intellihide mode is from the user's perspective: if intellihide is on, toggling dyamic transparency in the GUI would have no effect, which would be weird/seen as a bug. Alternatively, this setting could be greyed out if intellihide is on, but then it is again weird to guess why it is like that. In the end, I was happy with the latest fix I included, as you said.

In any case, I'm waiting for @didrocks 's feedback again, as I'm not sure I fixed what he pointed out. I certainly don't intend to be dismissive of the suggestions.

Contributor

franglais125 commented Sep 7, 2017

in intellihide mode the transparency could probably not be dynamic (constantly opaque). However, latest @franglais125 implementation seems to work quite well for me.

I was thinking a bit about this too. The problem I saw with having the dock being opaque when in intellihide mode is from the user's perspective: if intellihide is on, toggling dyamic transparency in the GUI would have no effect, which would be weird/seen as a bug. Alternatively, this setting could be greyed out if intellihide is on, but then it is again weird to guess why it is like that. In the end, I was happy with the latest fix I included, as you said.

In any case, I'm waiting for @didrocks 's feedback again, as I'm not sure I fixed what he pointed out. I certainly don't intend to be dismissive of the suggestions.

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 7, 2017

Collaborator

Thanks to both of you! I tried latest branch and indeed, the Intellihide glitch is now fixed. I'm quite in favor for michele's suggestions, being:

  1. Fixed dock:
  • Toggle between min and max opacity values. Those values could be defined by css class when toggling dynamic transparency or adding a "min transparency" settings in the UI (widget is only active when dynamic transparency is set to true).
  • Opacity settings override the max opacity value set in css (or as told by Michele "opaque state"). Note that you can't use the top panel transparency value as it will be a non linear gradient (currently discussed on #gnome-design). I thus think that the css class approach for the min value is fine as told above (as I can understand you don't want to introduce yet another settings for this min opacity).
  1. Intellihide mode:
  • the dynamic transparency settings isn't active (and the widget can't be enabled/disabled) as it doesn't have any impact: only the "opaque" state (which can be slightly transparent, based on the existing opacity settings). Indeed, I see a lot of value of having a non fully opaque dock in intellihide mode, but I think it should always stay at the same opacity value.

Does it sum up and align with your understanding? I'm happy to give any help if needed :)

Collaborator

didrocks commented Sep 7, 2017

Thanks to both of you! I tried latest branch and indeed, the Intellihide glitch is now fixed. I'm quite in favor for michele's suggestions, being:

  1. Fixed dock:
  • Toggle between min and max opacity values. Those values could be defined by css class when toggling dynamic transparency or adding a "min transparency" settings in the UI (widget is only active when dynamic transparency is set to true).
  • Opacity settings override the max opacity value set in css (or as told by Michele "opaque state"). Note that you can't use the top panel transparency value as it will be a non linear gradient (currently discussed on #gnome-design). I thus think that the css class approach for the min value is fine as told above (as I can understand you don't want to introduce yet another settings for this min opacity).
  1. Intellihide mode:
  • the dynamic transparency settings isn't active (and the widget can't be enabled/disabled) as it doesn't have any impact: only the "opaque" state (which can be slightly transparent, based on the existing opacity settings). Indeed, I see a lot of value of having a non fully opaque dock in intellihide mode, but I think it should always stay at the same opacity value.

Does it sum up and align with your understanding? I'm happy to give any help if needed :)

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 7, 2017

Contributor
  1. Fixed dock: (This is w.r.t. css)
    To give some context: I initially tried to go the css route (as is done upstream for the top panel). However, I tried to keep in mind that:
  • There is a built-in theme (be it Adwaita, Ambiance, etc.)
  • The user can manually set the color of the dock in the GUI
  • The user can manually set an opacity value in the GUI

The first problem I found was that we need to adjust the property background-color, which unfortunately takes as input rgba, meaning that I need to specify both color and alpha.
Assuming we specify a css class for dynamic transparency, we would then be forcing the (r,g,b,a) combination we chose on all users, whatever theme/color they chose (i.e. dynamic transparency would be incompatible with any non-default theme).

Specifically, I guess this is not a problem for "Ubuntu Dock", as I'm assuming it will be packaged with a specific theme anyway. But this wouldn't be the case for anyone installing d-t-d from e.g.o/git.

In any case, I'm not exactly experienced with css, so please let me know how to work around this. I feel like I'm missing something!

CSS reference: https://developer.gnome.org/gtk3/stable/chap-css-properties.html

  1. Intellihide mode: I'm fine with turning it off completely. As I don't use it often I don't know what feels more natural. I just thought it didn't look nice when in panel mode (à la Unity) when there are no windows, next to the transparent top panel.
Contributor

franglais125 commented Sep 7, 2017

  1. Fixed dock: (This is w.r.t. css)
    To give some context: I initially tried to go the css route (as is done upstream for the top panel). However, I tried to keep in mind that:
  • There is a built-in theme (be it Adwaita, Ambiance, etc.)
  • The user can manually set the color of the dock in the GUI
  • The user can manually set an opacity value in the GUI

The first problem I found was that we need to adjust the property background-color, which unfortunately takes as input rgba, meaning that I need to specify both color and alpha.
Assuming we specify a css class for dynamic transparency, we would then be forcing the (r,g,b,a) combination we chose on all users, whatever theme/color they chose (i.e. dynamic transparency would be incompatible with any non-default theme).

Specifically, I guess this is not a problem for "Ubuntu Dock", as I'm assuming it will be packaged with a specific theme anyway. But this wouldn't be the case for anyone installing d-t-d from e.g.o/git.

In any case, I'm not exactly experienced with css, so please let me know how to work around this. I feel like I'm missing something!

CSS reference: https://developer.gnome.org/gtk3/stable/chap-css-properties.html

  1. Intellihide mode: I'm fine with turning it off completely. As I don't use it often I don't know what feels more natural. I just thought it didn't look nice when in panel mode (à la Unity) when there are no windows, next to the transparent top panel.
@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 7, 2017

Collaborator

Those are valid points. I'll let Michele answer if the css or the extra settings path is the better with what he has in his mind. I'm starting to think (seeing how the code is structured) that another opacity settings for the start of the transparency transition makes sense.

On intellihide, indeed, it's true that it can look weird when no window touching it or the top panel. So, you may be right by keeping the min and max transparency to accomodate. However, I think that the "max" value (when hidden) shouldn't be opaque, but respecting the same opacity settings (which would be a little bit transparent in ubuntu dock when on top of a window pushing the dock away).

Collaborator

didrocks commented Sep 7, 2017

Those are valid points. I'll let Michele answer if the css or the extra settings path is the better with what he has in his mind. I'm starting to think (seeing how the code is structured) that another opacity settings for the start of the transparency transition makes sense.

On intellihide, indeed, it's true that it can look weird when no window touching it or the top panel. So, you may be right by keeping the min and max transparency to accomodate. However, I think that the "max" value (when hidden) shouldn't be opaque, but respecting the same opacity settings (which would be a little bit transparent in ubuntu dock when on top of a window pushing the dock away).

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 7, 2017

Owner

Quick comments:

The first problem I found was that we need to adjust the property background-color, which unfortunately takes as input rgba, meaning that I need to specify both color and alpha.

I didn't realise that. I don't think we can easily workaround it. I would still offer two css classes for our "embedded theme" and third parties themes (if they want to support dash-to-dock).

My idea is 1) we support the defualt theme and if possible adapt to other themes. 2) We provide great flexibility for to custom themes to define their own style. 3) The user can still manually tweak some parameter

I'm starting to think (seeing how the code is structured) that another opacity settings for the start of the transparency transition makes sense.

I still think all Ubuntu-dock needs should be satisfiable with changes at the theme level (with us adding the above mentioned css classes). On the dash-to-dock side, it's not too much of a deal to add another opacity slider if that is the most logical sulution.

For the intellihide case, I'm not sure what's the best visually speaking (I haven't used 3.26 enough to judge). Everything looks a bit unpleasnt to me with a dock touching the top panel (I remember the gradient mockups, but it seems to still be just transparent as of now). I'm even wondering if the Ubuntu folks have even considered disabling the dynamic transparency...

As we seems to have a working implementation, and if we a re going to add the second opacity settings, I would go for the current behaviour but with the opacity values corrected (no full opacity).

Owner

micheleg commented Sep 7, 2017

Quick comments:

The first problem I found was that we need to adjust the property background-color, which unfortunately takes as input rgba, meaning that I need to specify both color and alpha.

I didn't realise that. I don't think we can easily workaround it. I would still offer two css classes for our "embedded theme" and third parties themes (if they want to support dash-to-dock).

My idea is 1) we support the defualt theme and if possible adapt to other themes. 2) We provide great flexibility for to custom themes to define their own style. 3) The user can still manually tweak some parameter

I'm starting to think (seeing how the code is structured) that another opacity settings for the start of the transparency transition makes sense.

I still think all Ubuntu-dock needs should be satisfiable with changes at the theme level (with us adding the above mentioned css classes). On the dash-to-dock side, it's not too much of a deal to add another opacity slider if that is the most logical sulution.

For the intellihide case, I'm not sure what's the best visually speaking (I haven't used 3.26 enough to judge). Everything looks a bit unpleasnt to me with a dock touching the top panel (I remember the gradient mockups, but it seems to still be just transparent as of now). I'm even wondering if the Ubuntu folks have even considered disabling the dynamic transparency...

As we seems to have a working implementation, and if we a re going to add the second opacity settings, I would go for the current behaviour but with the opacity values corrected (no full opacity).

Show outdated Hide outdated docking.js
@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 8, 2017

Collaborator

I'm even wondering if the Ubuntu folks have even considered disabling the dynamic transparency...

We did, but for obvious reasons, we don't really want to deviate from upstream's design on that one. I think we can achieve something matching with a very transparent dock when no window is touching them.

As we seems to have a working implementation, and if we a re going to add the second opacity settings, I would go for the current behaviour but with the opacity values corrected (no full opacity).

Yeah, so basically: current behavior, 2 opacity settings (min/max), intellihide mode respecting as well those 2 opacity settings. That makes sense to me as well. Tell me if you need any help.

Collaborator

didrocks commented Sep 8, 2017

I'm even wondering if the Ubuntu folks have even considered disabling the dynamic transparency...

We did, but for obvious reasons, we don't really want to deviate from upstream's design on that one. I think we can achieve something matching with a very transparent dock when no window is touching them.

As we seems to have a working implementation, and if we a re going to add the second opacity settings, I would go for the current behaviour but with the opacity values corrected (no full opacity).

Yeah, so basically: current behavior, 2 opacity settings (min/max), intellihide mode respecting as well those 2 opacity settings. That makes sense to me as well. Tell me if you need any help.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 8, 2017

Contributor

Thank you both again for the feedback :)! I was taking some time before tackling the code, as I wanted to make sure I understood what we want.

I'll try to come up with a few patches in the next few days. Further feedback is of course appreciated!

Contributor

franglais125 commented Sep 8, 2017

Thank you both again for the feedback :)! I was taking some time before tackling the code, as I wanted to make sure I understood what we want.

I'll try to come up with a few patches in the next few days. Further feedback is of course appreciated!

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 8, 2017

Contributor

Introduced three commits:

  • [f6b0ea1] + [cc316a8] move the styling to stylesheet.css. I took the colors for background and border from the upstream default styles.
  • [90cba5e] set the maximum opacity to the user-selected value, and the minimum opacity to 0.2 (as the top panel).

If you look at the new style classes added, you'll see that the opaque one has a maximum of 0.8 (suggestions?). I put this value tentatively, but I want to point out that this is not used anyway, as the maximum is the one selected from the slider.

I still need to rework the GUI+settings to add the second slider.

To do:

  1. Add setting for minimum opacity
  2. Respect the min/max values set in stylesheet.css if they were not set by the user.
Contributor

franglais125 commented Sep 8, 2017

Introduced three commits:

  • [f6b0ea1] + [cc316a8] move the styling to stylesheet.css. I took the colors for background and border from the upstream default styles.
  • [90cba5e] set the maximum opacity to the user-selected value, and the minimum opacity to 0.2 (as the top panel).

If you look at the new style classes added, you'll see that the opaque one has a maximum of 0.8 (suggestions?). I put this value tentatively, but I want to point out that this is not used anyway, as the maximum is the one selected from the slider.

I still need to rework the GUI+settings to add the second slider.

To do:

  1. Add setting for minimum opacity
  2. Respect the min/max values set in stylesheet.css if they were not set by the user.
@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 8, 2017

Collaborator

One last thing while thinking about it and playing with it a little bit more: I think, for full height panel (like ubuntu-dock default and your special settings for it), I think it will make sense to just link the transparency detection with the top panel one. You can consider it as just one UI and not 2 independant part, which could look "flaky".

That could be one option (that I'll toggle in ubuntu dock IMHO), which is "link panel and dock opacity state" or something along those lines. Only the Shell (via the top panel transparency decision) would in that option decides if toggling something transparent or not.
Does it make sense? If you don't feel like doing it, I'm happy providing a PR for this.

Collaborator

didrocks commented Sep 8, 2017

One last thing while thinking about it and playing with it a little bit more: I think, for full height panel (like ubuntu-dock default and your special settings for it), I think it will make sense to just link the transparency detection with the top panel one. You can consider it as just one UI and not 2 independant part, which could look "flaky".

That could be one option (that I'll toggle in ubuntu dock IMHO), which is "link panel and dock opacity state" or something along those lines. Only the Shell (via the top panel transparency decision) would in that option decides if toggling something transparent or not.
Does it make sense? If you don't feel like doing it, I'm happy providing a PR for this.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 8, 2017

Contributor

I had the same idea actually, while I was setting the minimum to 20%, so yes, I'd find that to be the most consistent look ootb.

I will definitely keep it in mind! I'll try to see how I can implement the various elements (new slider, etc.), while not cluttering the GUI with too many options.

Contributor

franglais125 commented Sep 8, 2017

I had the same idea actually, while I was setting the minimum to 20%, so yes, I'd find that to be the most consistent look ootb.

I will definitely keep it in mind! I'll try to see how I can implement the various elements (new slider, etc.), while not cluttering the GUI with too many options.

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 8, 2017

Collaborator

Excellent! :)

Basically, I guess the idea is to check for this settings in _updateSolidStyle and check if the "solid" css class is set on the panel element via has_style_class_name. But then, there is the question of the race (which _updateSolidStyle() is called first.

So, the easiest and more robust IMHO is to unwire this function when using that settings and rely on, the "style-class" signal set by the panel clutter actor each time the class has changed.

Collaborator

didrocks commented Sep 8, 2017

Excellent! :)

Basically, I guess the idea is to check for this settings in _updateSolidStyle and check if the "solid" css class is set on the panel element via has_style_class_name. But then, there is the question of the race (which _updateSolidStyle() is called first.

So, the easiest and more robust IMHO is to unwire this function when using that settings and rely on, the "style-class" signal set by the panel clutter actor each time the class has changed.

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 8, 2017

Collaborator

FYI, Shell 3.25.92 disable this dynamic transparency for now: https://bugzilla.gnome.org/show_bug.cgi?id=787446.

There is thus a little bit of time to polish this PR and get the exact desired experience :)

Collaborator

didrocks commented Sep 8, 2017

FYI, Shell 3.25.92 disable this dynamic transparency for now: https://bugzilla.gnome.org/show_bug.cgi?id=787446.

There is thus a little bit of time to polish this PR and get the exact desired experience :)

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 8, 2017

Owner

It's still not clear what it's going to happen to the upstream transparency, I have the feeling that that patch is ready just in case that's the final decision.

If we want full syncronization, I think that the best route is to have a single '_updateSolidStyle' function handling both the panel and dock. As we can't easily disconnect the panel signals, we should replace Main.panel._updateSolidStyle with an extended one testing on both the dock and panel and then applying wathever logic we like. Connecting to the style-changed signal would work only one way (making the dock opaque when the panel is, but not the opposite)

@franglais125 : beside the UI and settings, is the logic functioning properly now?

Owner

micheleg commented Sep 8, 2017

It's still not clear what it's going to happen to the upstream transparency, I have the feeling that that patch is ready just in case that's the final decision.

If we want full syncronization, I think that the best route is to have a single '_updateSolidStyle' function handling both the panel and dock. As we can't easily disconnect the panel signals, we should replace Main.panel._updateSolidStyle with an extended one testing on both the dock and panel and then applying wathever logic we like. Connecting to the style-changed signal would work only one way (making the dock opaque when the panel is, but not the opposite)

@franglais125 : beside the UI and settings, is the logic functioning properly now?

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 8, 2017

Contributor

we should replace Main.panel._updateSolidStyle with an extended one

Good, this was one of the things I was considering, glad to know it would be an acceptable path to take. But I'd wait a bit more to see what happens in the end for 3.26. If they don't ship the feature, we can always reconsider this for 3.28, if it comes then.

@franglais125 : beside the UI and settings, is the logic functioning properly now?

The logic is functioning properly now, with one caveat: the minimum transparency is currently hard-coded to 0.2, it doesn't respect whatever is included in stylesheet.css. The thing is, I haven't found a reliable way of accessing this information from the stylesheet. Is there a proper way of doing it? A hacky workaround was to apply the transparent style to a dummy Stobject, to then retrieve the alpha value from it.

I would like to point out that the maximum transparency is set by the opacity slider. The rgba included in the opaque style is simply to follow the theme's color.

Contributor

franglais125 commented Sep 8, 2017

we should replace Main.panel._updateSolidStyle with an extended one

Good, this was one of the things I was considering, glad to know it would be an acceptable path to take. But I'd wait a bit more to see what happens in the end for 3.26. If they don't ship the feature, we can always reconsider this for 3.28, if it comes then.

@franglais125 : beside the UI and settings, is the logic functioning properly now?

The logic is functioning properly now, with one caveat: the minimum transparency is currently hard-coded to 0.2, it doesn't respect whatever is included in stylesheet.css. The thing is, I haven't found a reliable way of accessing this information from the stylesheet. Is there a proper way of doing it? A hacky workaround was to apply the transparent style to a dummy Stobject, to then retrieve the alpha value from it.

I would like to point out that the maximum transparency is set by the opacity slider. The rgba included in the opaque style is simply to follow the theme's color.

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 8, 2017

Owner

Good, this was one of the things I was considering, glad to know it would be an acceptable path to take.

Not too clean but not dirtier then many other parts of the extension :) There's no much choise if we want to change the panel opacity logic.

The thing is, I haven't found a reliable way of accessing this information from the stylesheet. Is there a proper way of doing it? A hacky workaround was to apply the transparent style to a dummy Stobject, to then retrieve the alpha value from it.

Can't think of a better way than what you are suggesting. I was a bit naive in thinking it would have been straightforward. If the issue is that we want to specify the opacity but not the color in the css, we could define a custom css property (something like -dashtodock-opacity). The we could apply the class to the dock directly and read the value. But I'm not sure if it works so easily like that, i never tried.

Owner

micheleg commented Sep 8, 2017

Good, this was one of the things I was considering, glad to know it would be an acceptable path to take.

Not too clean but not dirtier then many other parts of the extension :) There's no much choise if we want to change the panel opacity logic.

The thing is, I haven't found a reliable way of accessing this information from the stylesheet. Is there a proper way of doing it? A hacky workaround was to apply the transparent style to a dummy Stobject, to then retrieve the alpha value from it.

Can't think of a better way than what you are suggesting. I was a bit naive in thinking it would have been straightforward. If the issue is that we want to specify the opacity but not the color in the css, we could define a custom css property (something like -dashtodock-opacity). The we could apply the class to the dock directly and read the value. But I'm not sure if it works so easily like that, i never tried.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 12, 2017

Contributor

@didrocks It seems Shell 3.26 was tagged today with the top bar transparency enabled. Do you have any other info on this? Just to make sure it will stay like that for now.

Contributor

franglais125 commented Sep 12, 2017

@didrocks It seems Shell 3.26 was tagged today with the top bar transparency enabled. Do you have any other info on this? Just to make sure it will stay like that for now.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 12, 2017

Contributor

Following the limitations of the css approach that we discussed, here is a mock GUI configuration.

It will be easier for me to tackle the code once we agree on the better way to present the options (and what those options should be).

screenshot from 2017-09-12 14-32-16

  • Fixed: the dock has the same opacity all the time. In the GUI, the opacity slider is active, and the user can set the opacity to any value.
  • Adaptative: the dock and panel are 'locked', and share the same opaque/transparent state. The dock's maximum opacity is set via a css style. The slider and GtkButton are inactive.
  • Dynamic: the user can choose the min and max values for opacity, that is triggered according to the windows' positions. In the GUI, we set the GtkButton to active, and an advance menu presents slider for min and max.

This is what the "maximum" approach would be, i.e. basically all the options are exposed. I'm not advocating for this model, but this is at least a first sketch of how we could organize things.

Thoughts, suggestions? Options to be dropped?

Contributor

franglais125 commented Sep 12, 2017

Following the limitations of the css approach that we discussed, here is a mock GUI configuration.

It will be easier for me to tackle the code once we agree on the better way to present the options (and what those options should be).

screenshot from 2017-09-12 14-32-16

  • Fixed: the dock has the same opacity all the time. In the GUI, the opacity slider is active, and the user can set the opacity to any value.
  • Adaptative: the dock and panel are 'locked', and share the same opaque/transparent state. The dock's maximum opacity is set via a css style. The slider and GtkButton are inactive.
  • Dynamic: the user can choose the min and max values for opacity, that is triggered according to the windows' positions. In the GUI, we set the GtkButton to active, and an advance menu presents slider for min and max.

This is what the "maximum" approach would be, i.e. basically all the options are exposed. I'm not advocating for this model, but this is at least a first sketch of how we could organize things.

Thoughts, suggestions? Options to be dropped?

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 17, 2017

Owner

Since, I have reworked this in another branch (https://github.com/franglais125/dash-to-dock/tree/transparency_usePanelFunc), where I make use of the upstream function instead (for the 'adaptive' mode) of copying it.

At the moment it doesn't seem to make a big difference as the copied code is quite simple. Generally speaking yes, I prefer this second approach, as we don't need to track minor changes upstream, also helping maintaining mutlti-version support. That said, this feature will be surely reworked upstream in the next cycle, and we will have to readapt it again in any case. We can think about it later maybe.

Owner

micheleg commented Sep 17, 2017

Since, I have reworked this in another branch (https://github.com/franglais125/dash-to-dock/tree/transparency_usePanelFunc), where I make use of the upstream function instead (for the 'adaptive' mode) of copying it.

At the moment it doesn't seem to make a big difference as the copied code is quite simple. Generally speaking yes, I prefer this second approach, as we don't need to track minor changes upstream, also helping maintaining mutlti-version support. That said, this feature will be surely reworked upstream in the next cycle, and we will have to readapt it again in any case. We can think about it later maybe.

Show outdated Hide outdated theming.js
@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 17, 2017

Owner

@franglais125 Something to bear in mind. I'd like to keep the master branch compatible with recent older GNOME Shell versions. At the moment we support down to 3.18, but I think it is reasonable to drop the oldest versions. Hoerver, it is quite important for me to keep the same codebase for the version I run daily on my systems, that is 3.22. I think that this should also include most stable versions of major distributions, so we don't need to backports minor bugfixes.

This include dealing with the shell code and js syntax. For this branch we need to decide what to do in 3.24 and before. I'm fine in just disabling it for the moment. I was concern about the arrow functions syntax but they seem to work in 3.22 too.

Owner

micheleg commented Sep 17, 2017

@franglais125 Something to bear in mind. I'd like to keep the master branch compatible with recent older GNOME Shell versions. At the moment we support down to 3.18, but I think it is reasonable to drop the oldest versions. Hoerver, it is quite important for me to keep the same codebase for the version I run daily on my systems, that is 3.22. I think that this should also include most stable versions of major distributions, so we don't need to backports minor bugfixes.

This include dealing with the shell code and js syntax. For this branch we need to decide what to do in 3.24 and before. I'm fine in just disabling it for the moment. I was concern about the arrow functions syntax but they seem to work in 3.22 too.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 17, 2017

Contributor

@micheleg Good point. I run Debian 9 too, so whenever I test some new code, the first thing I use is 3.22. This at least ensures we are compatible with Gnome = 3.22. I never test something older though... Perhaps I should, every once in a while.

As for this branch, while it is compatible with Gnome <= 3.24, what happens is that adaptive will just work as dynamic (I need to add more descriptions to the GUI to warn people). Is this acceptable?

(This is why I test for !Panel._updateSolidStyle before enabling the 'adaptive' part.)

If you are ok with this, to-do (feel free to extend it, also @didrocks if you have further comments!):

  1. Address new comments
  2. Add more descriptions to the new options in the GUI
Contributor

franglais125 commented Sep 17, 2017

@micheleg Good point. I run Debian 9 too, so whenever I test some new code, the first thing I use is 3.22. This at least ensures we are compatible with Gnome = 3.22. I never test something older though... Perhaps I should, every once in a while.

As for this branch, while it is compatible with Gnome <= 3.24, what happens is that adaptive will just work as dynamic (I need to add more descriptions to the GUI to warn people). Is this acceptable?

(This is why I test for !Panel._updateSolidStyle before enabling the 'adaptive' part.)

If you are ok with this, to-do (feel free to extend it, also @didrocks if you have further comments!):

  1. Address new comments
  2. Add more descriptions to the new options in the GUI
@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 17, 2017

Owner

Great! For now not crashing or thowing errors in 3.22+ is ok for me, which I plan on support from now on. Let's finalise the bahaviour for 3.26 (which is also what ubuntu dock will support), and than before releasing a new version of dash-to-dock we can clean up the settings, in case hiding the unnecessary ones.

Owner

micheleg commented Sep 17, 2017

Great! For now not crashing or thowing errors in 3.22+ is ok for me, which I plan on support from now on. Let's finalise the bahaviour for 3.26 (which is also what ubuntu dock will support), and than before releasing a new version of dash-to-dock we can clean up the settings, in case hiding the unnecessary ones.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 18, 2017

Contributor

@micheleg I hope I addresses all/most of your comments. In the case of an eventual merge, the new commits can certainly be squashed where appropriate. Let me know if you want me to do this, just o save you some time. I didn't do so to make clear what the new changes are.

Contributor

franglais125 commented Sep 18, 2017

@micheleg I hope I addresses all/most of your comments. In the case of an eventual merge, the new commits can certainly be squashed where appropriate. Let me know if you want me to do this, just o save you some time. I didn't do so to make clear what the new changes are.

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 18, 2017

Collaborator

Thanks for working on this over this week-end! (And late, from what I see). I'm going to give another round of testing of the new code. The one from Friday was working very well with 3.26, I didn't notice any issue. I'll try to the updated code today.

I guess it's going to be too late for uploading today, I'm trying to aim for tomorrow/wednesday thus (which should be ok given the amount of testing). How should we proceed? I see you are ok maybe to merge this and refine later for earlier G-S release.

Note that I will only cherry-pick the commits + some other fixes from master for 17.10: I can't introduce the Unity backlight supports as we are past Feature Freeze (this is why I didn't rebase the branch recenly) and will get the FF exception for this dynamic opacity only. I'll wait for next cycle thus to do a full rebase, so if you prefer me to cherry-pick directly from this PR branch and not merge it directly, it's fine as well.

Collaborator

didrocks commented Sep 18, 2017

Thanks for working on this over this week-end! (And late, from what I see). I'm going to give another round of testing of the new code. The one from Friday was working very well with 3.26, I didn't notice any issue. I'll try to the updated code today.

I guess it's going to be too late for uploading today, I'm trying to aim for tomorrow/wednesday thus (which should be ok given the amount of testing). How should we proceed? I see you are ok maybe to merge this and refine later for earlier G-S release.

Note that I will only cherry-pick the commits + some other fixes from master for 17.10: I can't introduce the Unity backlight supports as we are past Feature Freeze (this is why I didn't rebase the branch recenly) and will get the FF exception for this dynamic opacity only. I'll wait for next cycle thus to do a full rebase, so if you prefer me to cherry-pick directly from this PR branch and not merge it directly, it's fine as well.

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 18, 2017

Collaborator

Ok, just gave it an advanced round of testing and didn't spot anything weird or incoherent in the dock behavior. Even with intellihide, it's nice to see the transition starting when you push it on side (as it will reappear with max opacity)!

A little gotcha, which doesn't really concern the ubuntu dock case: when you change the advanced settings for min and max opacity in the adaptative or dynamic case like the switch on/off the customize switch or play with the switchers:

  1. if you change the max opacity and you are not in the max opacity case with a window next to it, you won't see the change (same with the min opacity in case you have a window next to the launcher).
  2. everytime you change a value, a transition is triggered from opaque switcher to max or min opacity (even if you just play with the switch).

Excellent work :)

Collaborator

didrocks commented Sep 18, 2017

Ok, just gave it an advanced round of testing and didn't spot anything weird or incoherent in the dock behavior. Even with intellihide, it's nice to see the transition starting when you push it on side (as it will reappear with max opacity)!

A little gotcha, which doesn't really concern the ubuntu dock case: when you change the advanced settings for min and max opacity in the adaptative or dynamic case like the switch on/off the customize switch or play with the switchers:

  1. if you change the max opacity and you are not in the max opacity case with a window next to it, you won't see the change (same with the min opacity in case you have a window next to the launcher).
  2. everytime you change a value, a transition is triggered from opaque switcher to max or min opacity (even if you just play with the switch).

Excellent work :)

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 18, 2017

Contributor

@didrocks Thanks a lot for the testing!

  1. if you change the max opacity and you are not in the max opacity case with a window next to it, you won't see the change (same with the min opacity in case you have a window next to the launcher).
  2. everytime you change a value, a transition is triggered from opaque switcher to max or min opacity (even if you just play with the switch).

I'll try to see if I can work around these two annoyances. Lower priority though!

@micheleg I checked the compatibility of arrow functions. They were apparently introduced in libmozjs = 24, which was included as far back as Jessie. I tested the new code on 3.18 and it worked fine. I actually thought 3.18 was old, but as an example Ubuntu 16.04 is using it. Anyway, I'll try to be more careful with coding style and JS functionality!

Contributor

franglais125 commented Sep 18, 2017

@didrocks Thanks a lot for the testing!

  1. if you change the max opacity and you are not in the max opacity case with a window next to it, you won't see the change (same with the min opacity in case you have a window next to the launcher).
  2. everytime you change a value, a transition is triggered from opaque switcher to max or min opacity (even if you just play with the switch).

I'll try to see if I can work around these two annoyances. Lower priority though!

@micheleg I checked the compatibility of arrow functions. They were apparently introduced in libmozjs = 24, which was included as far back as Jessie. I tested the new code on 3.18 and it worked fine. I actually thought 3.18 was old, but as an example Ubuntu 16.04 is using it. Anyway, I'll try to be more careful with coding style and JS functionality!

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 18, 2017

Owner

Good! Let me see see If I can clean up the branch and merge it in master.

Owner

micheleg commented Sep 18, 2017

Good! Let me see see If I can clean up the branch and merge it in master.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 18, 2017

Contributor

@micheleg thanks! Let me know if you need some help.

Contributor

franglais125 commented Sep 18, 2017

@micheleg thanks! Let me know if you need some help.

Show outdated Hide outdated theming.js
Show outdated Hide outdated stylesheet.css
Show outdated Hide outdated theming.js
@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 19, 2017

Owner

@didrocks: I have prepared a slightly cleaned-up branch in the development branch (https://github.com/micheleg/dash-to-dock/commits/development). It is substantially the same of this PR, beside very minor cosmetic changes and history cleanup. This is what I'm going to be merge in master, although I still want to improve the behaviour on dash-to-dock side. I think the best strategy for you is to cherry pick from there.

Owner

micheleg commented Sep 19, 2017

@didrocks: I have prepared a slightly cleaned-up branch in the development branch (https://github.com/micheleg/dash-to-dock/commits/development). It is substantially the same of this PR, beside very minor cosmetic changes and history cleanup. This is what I'm going to be merge in master, although I still want to improve the behaviour on dash-to-dock side. I think the best strategy for you is to cherry pick from there.

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Sep 19, 2017

Collaborator

Here we go! I just based the ubuntu-dock branch, cherry-picking the needed commits. Thanks a lot @micheleg and @franglais125 for working on this. After the currrent finale round of testing, everything looks good to me.
I'm waiting for our Feature Freeze exception to be acked and will upload that to ubuntu itself.

I'm planning as well blogging about your excellent work there :) Do not hesitate if you need anything!

Collaborator

didrocks commented Sep 19, 2017

Here we go! I just based the ubuntu-dock branch, cherry-picking the needed commits. Thanks a lot @micheleg and @franglais125 for working on this. After the currrent finale round of testing, everything looks good to me.
I'm waiting for our Feature Freeze exception to be acked and will upload that to ubuntu itself.

I'm planning as well blogging about your excellent work there :) Do not hesitate if you need anything!

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 19, 2017

Contributor

@didrocks thanks a lot for the feedback and ideas! Good luck with the FF exception!

Contributor

franglais125 commented Sep 19, 2017

@didrocks thanks a lot for the feedback and ideas! Good luck with the FF exception!

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 21, 2017

Owner

So I've merged this in master as of [225b51d].

Owner

micheleg commented Sep 21, 2017

So I've merged this in master as of [225b51d].

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 21, 2017

Contributor

@micheleg Thanks a lot! Let me know if you find remaining issues or things to polish. One quickly comes to mind: hide the "Adaptive" option on Gnome < 3.26, or at least offer an explanation on the UI.

Contributor

franglais125 commented Sep 21, 2017

@micheleg Thanks a lot! Let me know if you find remaining issues or things to polish. One quickly comes to mind: hide the "Adaptive" option on Gnome < 3.26, or at least offer an explanation on the UI.

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Sep 21, 2017

Owner

That's exactly what is missing on our side, before reconsidering our default behaviour. I would possibly hide the adaptive case. For adding explanationas, I don't know where to put it. An idea would be to update the "subtitle" of the option, the one that now "Tune the dash backgrond opacity".

Owner

micheleg commented Sep 21, 2017

That's exactly what is missing on our side, before reconsidering our default behaviour. I would possibly hide the adaptive case. For adding explanationas, I don't know where to put it. An idea would be to update the "subtitle" of the option, the one that now "Tune the dash backgrond opacity".

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Sep 21, 2017

Contributor

@micheleg I added two commits to see how this would work. In general, I'm not really satisfied with the result. I needed to work around a few things which I didn't expect:

  • [c2b7b24] I needed to add a compare function. I'd have liked to simply check for Main._panel._updateSolidStyle, but importing imports.ui.main introduces a bug we have hit before (missing Meta library, etc.).
  • [93826df] Changing the label can change the space it takes up in the GUI, hence I manually set the height request. Also, the description itself might need some work.
Contributor

franglais125 commented Sep 21, 2017

@micheleg I added two commits to see how this would work. In general, I'm not really satisfied with the result. I needed to work around a few things which I didn't expect:

  • [c2b7b24] I needed to add a compare function. I'd have liked to simply check for Main._panel._updateSolidStyle, but importing imports.ui.main introduces a bug we have hit before (missing Meta library, etc.).
  • [93826df] Changing the label can change the space it takes up in the GUI, hence I manually set the height request. Also, the description itself might need some work.
docking.js: Use 'var' instead of 'const' for dock State.
This variable is accessed from theming.js.
@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Oct 8, 2017

Contributor

Added one commit to remove JS warning.

Contributor

franglais125 commented Oct 8, 2017

Added one commit to remove JS warning.

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Dec 23, 2017

Owner

Last mentioned commit was merged as ae7b86e.

Owner

micheleg commented Dec 23, 2017

Last mentioned commit was merged as ae7b86e.

@franglais125

This comment has been minimized.

Show comment
Hide comment
@franglais125

franglais125 Jan 6, 2018

Contributor

Finally closing this PR. Thanks everyone for the effort!

Contributor

franglais125 commented Jan 6, 2018

Finally closing this PR. Thanks everyone for the effort!

@didrocks

This comment has been minimized.

Show comment
Hide comment
@didrocks

didrocks Jan 8, 2018

Collaborator

Thanks again for your work! :)

Collaborator

didrocks commented Jan 8, 2018

Thanks again for your work! :)

@joca-bt

This comment has been minimized.

Show comment
Hide comment
@joca-bt

joca-bt Jan 28, 2018

Hi all, sorry to barge in. I can't find the options mocked here in the version available at https://extensions.gnome.org/extension/307/dash-to-dock/. How can I get the adaptative behaviour? (Got version 61 today.)

joca-bt commented Jan 28, 2018

Hi all, sorry to barge in. I can't find the options mocked here in the version available at https://extensions.gnome.org/extension/307/dash-to-dock/. How can I get the adaptative behaviour? (Got version 61 today.)

@micheleg

This comment has been minimized.

Show comment
Hide comment
@micheleg

micheleg Jan 28, 2018

Owner

v62 is still awaiting review (#679). You have to manually install the latest release if you want access to those features.

Owner

micheleg commented Jan 28, 2018

v62 is still awaiting review (#679). You have to manually install the latest release if you want access to those features.

@franglais125 franglais125 deleted the franglais125:transparency branch Mar 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment