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

Add the applications menu to the dock #337

Open
danirabbit opened this issue Dec 11, 2024 · 14 comments
Open

Add the applications menu to the dock #337

danirabbit opened this issue Dec 11, 2024 · 14 comments
Labels
Needs Design Waiting for input from the UX team Priority: Wishlist A feature request or enhancement

Comments

@danirabbit
Copy link
Member

Problem

Currently we have app launching split between two different processes on different sides of the screen. This requires those processes to communicate for things like pinning. Means duplicate code for any launcher features and they might get out of sync (like badges, context menus, drag behavior, rearranging, etc). Has complications with dragging launchers from the menu to the dock. Etc

Proposal

Move the applications menu into the dock so we can recycle launcher code and make sure launchers behave the same in the dock and in the applications menu, maybe finally have re-arranging in the applications menu, at least make sure we have drag n drop easily between the applications menu and the dock without dragging across the whole screen

Prior Art (Optional)

iPad OS:
IMG_6615

GNOME Shell:
IMG_6616

ChromeOS
IMG_6617

@danirabbit
Copy link
Member Author

I’ve been chewing on this for a while and the more I think about it the more into it I am. Especially thinking about implications for the panel as well. Without the applications menu it could go back to more of our original design of having it be just kind of floating, ephemeral in the corner, window dodging, putting confirmations in the panel like the sound prototype I did so it just pops in to give feedback. Maybe Dynamic Island vibes?

@danirabbit danirabbit transferred this issue from elementary/.github Dec 11, 2024
@danirabbit danirabbit added Needs Design Waiting for input from the UX team Priority: Wishlist A feature request or enhancement labels Dec 11, 2024
@patx
Copy link

patx commented Dec 12, 2024

I love this idea. I currently have my desktop set up this way. I've disabled
wingpanel and only use the dock. I had to make a small python app to add to my dock to show a applications menu button (which launches ulauncher), battery/date&time info, and logout/reboot/poweroff. My setup works great for me but is VERY crudely done. It would be amazing to see this done properly by you guys using a ephemeral type top panel, sligshot in the dock, and then a great dock (maybe user preference on dock location (bottom or side?). I was skeptical of the new dock in eOS 8 at first but once using it I am very impressed.

Screenshot from 2024-12-11 21 29 55

Screenshot from 2024-12-11 21 31 33

@teamcons
Copy link

This sounds like a complete, breaking change in a long established, recognized DE design, for no other reasons than a technical solution, making the DE lose more identity in the process since everyone else do that but better and since years.
i dont even see the point...

Id rather see both (and appcenter) pulling the informations from a same place. or just "ln appthingy.vala" or something

@jeremypw
Copy link

If anything I'd move the Dock into the App Menu or wingpanel as the dock is always popping up when or where I don't want it (and there is no "Always hide the dock" option)! I don't like things appearing "out of nowhere" anyway. Having the dock always visible has its own disadvantages. The Applications wingpanel item could be made a larger target and activate on hover. The first page would be something equivalent to the dock. I accept that for most losing the dock is probably a step too far though!

@teamcons
Copy link

teamcons commented Dec 12, 2024

If anything I'd move the Dock into the App Menu or wingpanel as the dock is always popping up when or where I don't want it (and there is no "Always hide the dock" option)! I don't like things appearing "out of nowhere" anyway. Having the dock always visible has its own disadvantages. The Applications wingpanel item could be made a larger target and activate on hover. The first page would be something equivalent to the dock. I accept that for most losing the dock is probably a step too far though!

Honestly i can get more behind this idea. Focusing too much into a small rectangle that either reserves a whole horizontal zone of the screen or plays hide and seek, feels silly, when there is a bar above whose whole deal is to control computer status, installed apps, and various informations

We could even go a step further, and allow the "Integrated" Wingpanel to either draw icons on it, or display a detached rectangle at bottom - So that wingpanel "is" the whole interface, theres no desync or duplication, and people are happy

It would even make sense for this idea: elementary/quick-settings#37 since Wingpanel would have everything app related

@patx
Copy link

patx commented Dec 12, 2024

If anything I'd move the Dock into the App Menu or wingpanel as the dock is always popping up when or where I don't want it (and there is no "Always hide the dock" option)! I don't like things appearing "out of nowhere" anyway. Having the dock always visible has its own disadvantages. The Applications wingpanel item could be made a larger target and activate on hover. The first page would be something equivalent to the dock. I accept that for most losing the dock is probably a step too far though!

This is pretty much what GNOME has done no?

Just me, but I use the dock a lot more then the top panel in elementary, to the point where I don't need the top panel. Either way, I like the idea of consolidating these two elements as you suggested.

@jeremypw
Copy link

Yeah, I don't think the Dock should go away but it is pretty broken atm with (count them) 5 different hide options, which is not very elementary. There only needs to be three - Always, Smart and Never. This in combination with a default "Favorites" page in the Applications menu would meet most needs. DRYing the associated code should be independent from the UI.

@teamcons
Copy link

Yeah, I don't think the Dock should go away but it is pretty broken atm with (count them) 5 different hide options, which is not very elementary. There only needs to be three - Always, Smart and Never. This in combination with a default "Favorites" page in the Applications menu would meet most needs. DRYing the associated code should be independent from the UI.

Honestly "Favorites" is already redundant with a dock. You get two custom sets of apps, in two different places, + the list of installed apps which share the same place as one of the former

I love the dock but it's just a rectangle with items one can reorder. It may as well just pull info from some other process

@alainm23
Copy link

The idea is not clear to me. Is it about moving the applications menu to the dock? If so, what would happen to the applications menu? Would it be removed?

@danirabbit
Copy link
Member Author

danirabbit commented Dec 12, 2024

@alainm23 Yes this is about moving the applications menu from the panel to the dock. It would no longer be in the panel if this was implemented.

@jeremypw our survey results showed:

  • Almost 90% of people use a dock to launch apps and of those about 90% use it daily
  • Over a third of people use the applications menu either infrequently or never to launch apps
  • A significant number of people use the dock to switch between open apps

So I don't think the data supports merging the dock's functionality into the applications menu, personally

I do agree that there's kind of a lot of hide modes for the dock but that seems off topic for this post imo. "When not being used" is the most aggressive hiding option where the dock only shows if you reveal it. So if you're getting accidental reveals, that's also a separate issue

@leolost2605
Copy link
Member

I like the idea of moving the app drawer to the dock but I definitely don't think merging dock and panel into one would be good. I also think system search should stay in wingpanel?
Regarding the actual implementation of the app drawer in the dock, I've started some prototyping with the drawer sliding up from the middle of the dock. Because one thing that really bothers me about the current wingpanel application menu is the generic popup animation. Any opinions here?

@teamcons
Copy link

teamcons commented Dec 12, 2024

So I don't think the data supports merging the dock's functionality into the applications menu, personally

agree. For the appmenu. Not wingpanel, which was also suggested
In the menu itself, intuitively, it adds needing one more click. The whole point of the dock is to spare a click and a menu
However, consolidating in the wingpanel wouldnt be against it. The data points are about having apps in a quick access way.

another issue with the app menu in the dock, is that in the current behaviour, user can just throw the mouse to the edge
in the dock, position of the launcher on the screen depends on how many apps there are. So it requires active looking for and pointing to an icon after showing up the dock instead of a movement

@danirabbit
Copy link
Member Author

danirabbit commented Dec 12, 2024

@leolost2605 I definitely think there’s room for exploring animation here. Gnome shell and iPad iOS both have this kind of animation of launchers flying out of the dock

ScreenRecording_12-12-2024.14-35-43_1.webm

@jeremypw
Copy link

OK, I was playing devil's advocate to a degree. I just feel that the issue of quick access to favorites must have a better solution than a "now you see me now you don't" rectangle fixed at the bottom of the screen. The fact that 90% of respondents use it is not surprising if there is no usable alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Waiting for input from the UX team Priority: Wishlist A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

6 participants