Add proper design for drop down list

[ochi12]

Above is the current design. This is also found in app-center and I think the design is weird. First of all having flat look on item hover instead of a rounded corner padded style is already fine but the top space above the first item throws me off. I think it should look like this:

The design for the auto complete list is actually proper

I don't know if why even a single widget (drop down list) has a lot of fragmentation in its design.

Affected designs:

• Drop down list for Popup menu button
• Drop down list for Split Button

[ochi12]

@Feichtmeier Would it make sense to establish a centralized design discussion space, for example a dedicated design repository similar to GNOME’s design repo, where we can document, review, and standardize the UI guidelines for our widgets?

Having a shared place for design decisions would let us consistently define and reference things like:

• Standard padding values
• Border radius rules
• Spacing between a pressed widget and its popup menu
• Menu-item padding and layout conventions
• Button design patterns
• Other shared style and interaction guidelines

One idea is to group similar components under a common design primitive. For example, any widget that behaves like a button (standard buttons, tabs, split buttons, popup menu buttons) could be represented in a single button_primitive.png asset. That file would document the canonical padding, radii, font styles, and interaction spacing for all button-like widgets.

This kind of centralized documentation would also make it easier to identify inconsistencies and guide future refactoring, especially for widgets that might otherwise be overlooked.

I think this approach would be very beneficial for the design clarity and long-term maintainability of yaru.dart.

Referencing above, I don't know yet if popup menus for auto complete, split buttons, and popup menu buttons uses a centralized popup menu source widget. This small things are actually very noticeable and doesn't emit a proper yaru vibe

this issue #1047 is actually good example too, we could reference this to the example I mentioned the 'button_primitives.png'. An issue create is great but it would be better if we could also document it.

I would like to also amp this issue by taking app center as part of it. I was scrolling for apps when I saw the categories section and Immediately noticed that the buttons have no left padding.

Again, we could reference button_primitives.png to ensure that we stay consistent with the design

[juanruitina]

Given that we are looking at consistency, option 2 would be probably best to keep it aligned with GNOME.

On guidelines, YES, it would be great to have design guidelines. I'm personally missing clearer guidance on what each component is ideally used for, and how. We could use the repo wiki for this.

[Feichtmeier]

Given that we are looking at consistency, option 2 would be probably best to keep it aligned with GNOME.

On guidelines, YES, it would be great to have design guidelines. I'm personally missing clearer guidance on what each component is be ideally used for, and how. We could use the repo wiki for this.

We could just default to adwaita if we all agree on this. This would also mean to make all those containers with borders rather be based on cards (elevation) than borders, this is what adwaita (gnome) does

Edit: and sadly I have def. no time to create a full docu on the looks
on the other hand we spent quite some time on the example live demo, which is basically a list of our widgets and an example in the FAP
https://ubuntu.github.io/yaru.dart/

[ochi12]

We could just default to adwaita if we all agree on this. This would also mean to make all those containers with borders rather be based on cards (elevation) than borders, this is what adwaita (gnome) does

That is what I have been thinking for a long time, I don't know if I'm correct but yaru.dart is designed primarily for ubuntu desktop right? Since adwaita is the native look for most gnome apps in gnome desktop, I think it is actually better to just follow the look of yaru + adwaita since we are now diverging to heaving modifications (meaning we don't even have plans on making gtk and gnome shell look like yaru.dart anyways)

[Feichtmeier]

We could just default to adwaita if we all agree on this. This would also mean to make all those containers with borders rather be based on cards (elevation) than borders, this is what adwaita (gnome) does

That is what I have been thinking for a long time, I don't know if I'm correct but yaru.dart is designed primarily for ubuntu desktop right? Since adwaita is the native look for most gnome apps in gnome desktop, I think it is actually better to just follow the look of yaru + adwaita since we are now diverging to heaving modifications (meaning we don't even have plans on making gtk and gnome shell look like yaru.dart anyways)

I personally care more about the maintainability
At the start we decided to create a theme for material widgets so people can build ubuntu-ish apps fast
Re-creating all widgets is a lot of work (and the quality needs to be high and include accessability etc) so we decdided to go with the themed material most of the time. Exceptions are the progress indicator and the switch (and maybe some more)

I would say, if it is easily done via the theme (which it is most of the time) let's just recreate adwaita
but if it means we would need to recreate a widget to copy the pixel perfect look of adwaita, I would strongly say let's not do this, except canonical dedicates some developers to it, because I can not do this, and most likely @Jupi007 also not (time wise). THis lib needs to be solid in the first place IMO and maintained well. 100% pixel perfect adwaita copy is a second prio

[ochi12]

I don't know if theming in flutter has the same workflow as theming in native android. I had a lot of fun building the widgets of my controller app when I was in 3rd year. If I were to start yaru.dart my self I would definitely go with theming. We don't need to necessarily copy all the adwaita widgets but instead make what available material widget look like adwaita.