Skip to content
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

Dash to dock broken, unable to rearrange icons #2010

Closed
coreybruce opened this issue May 16, 2023 · 27 comments · Fixed by #2021
Closed

Dash to dock broken, unable to rearrange icons #2010

coreybruce opened this issue May 16, 2023 · 27 comments · Fixed by #2021

Comments

@coreybruce
Copy link

Hey there I wanted to report a issue with dash to dock, I am unable to rearrange the icons using dash to dock and the only way I was able to make it work was to set it to panel mode and also resizing icons doesn't not work unless it's set to panel mode. and have no idea why it's happening

I tried

dconf reset -f /org/gnome/shell/extensions/dash-to-dock/

But it is still broken.

Screencast.from.2023-05-17.02-58-17.webm

I am using Manjaro Gnome using the latest version 81 and tested both the extension package from Manjaros repo and from Gnome extensions and have the same issue.

@doppelhelix
Copy link

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock"
That does the trick for me.

@Fascomino
Copy link

When I moved the Show Applications icon to the end everything worked as intended. This error was introduced with the last change to put the button at the edge when in panel mode.

@ionutbortis
Copy link

Same here. No rearranging and the new opened apps that were not previously pinned to dash as favorites are not displayed properly.
dash to dock 81 issues.webm

@coreybruce
Copy link
Author

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

Hmm yeah that also does it but what is causing this issue I wonder?

@coreybruce
Copy link
Author

This is only happening on one machine, my laptop for example isn't sufferering from this same issue.

@ionutbortis
Copy link

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

Hmm yeah that also does it but what is causing this issue I wonder?

There are some recent changes that affect the dock behavior. I downgraded to version 80 and changed the version from the local metadata.json file to 81 in order to avoid future update to the problematic version.

@coreybruce
Copy link
Author

coreybruce commented May 18, 2023

If anyone is using a Arch based system like me which uses Manjaro I have the backup package of the 80-1 package from Manjaro, I know this isn't recommended or trust worthy but I have the sig file to verify it that is if anyone wants it :)

@ionutbortis
Copy link

You can also downgrade manually:

wget https://extensions.gnome.org/extension-data/dash-to-dockmicxgx.gmail.com.v80.shell-extension.zip

gnome-extensions install --force dash-to-dockmicxgx.gmail.com.v80.shell-extension.zip

nano ~/.local/share/gnome-shell/extensions/dash-to-dock\@micxgx.gmail.com/metadata.json
# Change version to 81 then CTRL+S and CTRL+X. Relogin and you should have version 80 running as 81.

rm dash-to-dockmicxgx.gmail.com.v80.shell-extension.zip

@FlyingPaperPlane
Copy link

FlyingPaperPlane commented May 19, 2023

@ionutbortis
thanks to your guide i could manage to downgrade my dock.
had an additional issue where the icons performed resize animations randomly, looked to me as if they would be dancing. now it's quite again :-)

i assume the next update will skip & overwrite version 81 and fix the issues

@ionutbortis
Copy link

ionutbortis commented May 19, 2023

@FlyingPaperPlane Yeah, I hope these issues will get fixed in the 82 version release 🙏

If not, we can redo the above downgrade process, manually change version to 82 and so on 😅

@vikingredwolf
Copy link

Update: I noticed you can't rearrange icons when the apps icon is on the left, but works perfectly when it's on the right side. Isn't that odd?

@fraz0815
Copy link

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

Thanks, confirming the workaround on manjaro gnome 44.1 testing.

@jcsekinger
Copy link

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

and re-enable ;)

@coreybruce
Copy link
Author

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

and re-enable ;)

Sadly that doesn't work, if you re-enable it than it will go back to the same issue.

@jcsekinger
Copy link

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

and re-enable ;)

Sadly that doesn't work, if you re-enable it than it will go back to the same issue.

yes, it does not really solve the pb, it is juste a workaround: disable > move the icon > re-enable it — and the icon is now at the correct place, that’s all you have to do it every time you have to move an icon.

@coreybruce
Copy link
Author

Same Problem here. the workaround is to disable "Move the applications button at the beginning of the dock" That does the trick for me.

and re-enable ;)

Sadly that doesn't work, if you re-enable it than it will go back to the same issue.

yes, it does not really solve the pb, it is juste a workaround: disable > move the icon > re-enable it — and the icon is now at the correct place, that’s all you have to do it every time you have to move an icon.

Yeah I agree

@coreybruce
Copy link
Author

Any progress on fixing this issue?

3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue May 31, 2023
When using a floating show apps icon setup, it needs to be at the same
level of the dash box, but we can't use the same container because
upstream code only uses that for application icons, and this assumption
may break things such as DnD and potentially other things.

So move things in a new container.

Closes: micheleg#2010
@3v1n0
Copy link
Collaborator

3v1n0 commented May 31, 2023

#2021 should fix it, please test!

@3v1n0 3v1n0 closed this as completed May 31, 2023
@3v1n0 3v1n0 reopened this May 31, 2023
@jcsekinger
Copy link

how can I test that solution ? How do I « Use a different container to hold floating ShowAppsIcon»? This is not significant for me. Thank you !

@ionutbortis
Copy link

#2021 should fix it, please test!

Hi Marco,

Thanks for looking into this!

I tested the rearrange-fix-icons branch, we can now rearrange the icons, that's good.

But on my side, there's still a small issue:
When you open an app that is not already added to the favorites, it will be added at the end, with a separator. All newly opened apps after that one are opened to its left, not to its right, as it was functioning before.

Please see the attached screencast.
Screencast from 2023-05-31 15-23-40.webm

@3v1n0
Copy link
Collaborator

3v1n0 commented Jun 1, 2023

All newly opened apps after that one are opened to its left, not to its right, as it was functioning before.

I think this bug was also present before v80 and so it's another issue, but thanks for letting me know

3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Jun 2, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: micheleg#2010 (comment)
3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Jun 2, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: micheleg#2010 (comment)
3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Jun 2, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: micheleg#2010 (comment)

LP: #2017523
3v1n0 added a commit that referenced this issue Jun 2, 2023
When using a floating show apps icon setup, it needs to be at the same
level of the dash box, but we can't use the same container because
upstream code only uses that for application icons, and this assumption
may break things such as DnD and potentially other things.

So move things in a new container.

Closes: #2010
3v1n0 added a commit that referenced this issue Jun 2, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: #2010 (comment)

LP: #2017523
@Amzd
Copy link

Amzd commented Jun 2, 2023

Just tested after #2021 merge and I think this is related:

Last pinned item moves to the wrong side of the separator when a different item is unpinned.

Screencast.from.2023-06-02.04-07-10.webm

@3v1n0
Copy link
Collaborator

3v1n0 commented Jun 2, 2023

Thanks @Amzd, please test #2023

@Amzd
Copy link

Amzd commented Jun 2, 2023

unpin edge case is fixed 👍 seems to all work fine in #2023 with applications button on the left @3v1n0

@ionutbortis
Copy link

All newly opened apps after that one are opened to its left, not to its right, as it was functioning before.

I think this bug was also present before v80 and so it's another issue, but thanks for letting me know

You're right, that bug seems to be introduced in v80. Just tested v79 and the issue is not present there.

Also, #2023 fixes that issue, the newly opened apps that are not pinned to the dash are properly getting their order in the dash. Thanks!

3v1n0 added a commit that referenced this issue Jun 2, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: #2010 (comment)

LP: #2017523
3v1n0 added a commit that referenced this issue Jun 2, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: #2010 (comment)

LP: #2017523
hasecilu pushed a commit to hasecilu/dash-to-dock that referenced this issue Oct 10, 2023
When using a floating show apps icon setup, it needs to be at the same
level of the dash box, but we can't use the same container because
upstream code only uses that for application icons, and this assumption
may break things such as DnD and potentially other things.

So move things in a new container.

Closes: micheleg#2010
hasecilu pushed a commit to hasecilu/dash-to-dock that referenced this issue Oct 10, 2023
The separator may be wrongly computed as an extra icon item,
causing new items being positioned in the wrong place.

This is clearly visible when running a new application, that ends
up being added as the one before the last one, instead of as the
last one.

By temporary removing the separator element we avoid having to
consider the special case all the times when doing the icons
positioning math, instead we can just add it back once we're
done.

See: micheleg#2010 (comment)

LP: #2017523
@eboye
Copy link

eboye commented Nov 18, 2023

I stumbled upon this issue as I'm having the same behavior on Gnome 45.1 and D2D v89

Screencast.from.2023-11-18.22-11-35.webm

@vanvugt
Copy link
Collaborator

vanvugt commented Nov 21, 2023

This bug is closed, but you can continue the conversation in #2122

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.