search

JeysonFlores / vault

Save your code for later.
GNU General Public License v3.0
0 stars 0 forks source link

UI Design #1

Open JeysonFlores opened 2 years ago

JeysonFlores commented 2 years ago

Problem

The UI design has to look good and modern without loosing simplicity.

Prior Art

This is the design Cassidy did for the codestash project: image

Proposals

I'd suggest drop the thick headerbar and move the buttons to the bottom of the notes' list. The Search field is something I don't really know what would be a good place for it.

JeysonFlores commented 2 years ago

There has been an idea in my mind since a few hours ago, what about doing a cards-style list for the notes? Something like this: image (of course without that side panel and stuff)

Suzie97 commented 2 years ago

I'd suggest drop the thick headerbar and move the buttons to the bottom of the notes' list. The Search field is something I don't really know what would be a good place for it.

I did this quick mockup.

Artboard

It's basically the same layout as CodeStash and SourceNote, but changed a little to match the newer elementary OS style, particularly the Tasks app. I think this style is tried and tested and it would be safe to go with this.

The advantages of this note according to my analysis are:

Disadvantages:

Suzie97 commented 2 years ago

There has been an idea in my mind since a few hours ago, what about doing a cards-style list for the notes?

This is an interesting idea.

Advantages:

JeysonFlores commented 2 years ago

It's basically the same layout as CodeStash and SourceNote, but changed a little to match the newer elementary OS style, particularly the Tasks app

Yep, it's pretty close of what I thought originally, however one problem this generates is the fact that (in Gtk3) would make use of LibHandy's Window which is a library and a class that is not available in the C++ bindings. This would lead to 2 possible solutions:

JeysonFlores commented 2 years ago

While hovering the cursor over a card, if a preview is displayed which even more content than what is shown by the card, it would improve the navigation experience.

Actually I didn't think about this, I'll make a mockup to see how would it be.

Suzie97 commented 2 years ago

Yep, it's pretty close of what I thought originally, however one problem this generates is the fact that (in Gtk3) would make use of LibHandy's Window which is a library and a class that is not available in the C++ bindings.

Why is Handy needed? Rounded corners in the window? If that is the only case, I think adding the rounded style class to the window should work. If there are any other reasons please let me know.

JeysonFlores commented 2 years ago

Why is Handy needed?

Headerbars are mandatory(and undivisible) in vanilla Gtk3, even if you let it empty and flat that side panel going from top to bottom it's not possible (as long as I know). Edit: If I'm not wrong, there's a trick to (kind of) achieve it. It consists to overlay a container over the headerbar. I've only seen that once in a really old elementary app, and the result was kinda buggy and ugly.

Rounded corners is not the only usage of Hdy.Window, that widget it's a clear and empty space to start building your apps without pre-defined layout designs. That's why the Hdy.Headerbar can be placed anywhere, to let the app developer put the Window's controls wherever he/she wants or needs. See: https://blogs.gnome.org/alexm/2020/04/12/on-windows-and-titlebars/

Suzie97 commented 2 years ago

Why is Handy needed?

Headerbars are mandatory(and undivisible) in vanilla Gtk3, even if you let it empty and flat that side panel going from top to bottom it's not possible (as long as I know).

Edit: If I'm not wrong, there's a trick to (kind of) achieve it. It consists to overlay a container over the headerbar. I've only seen that once in a really old elementary app, and the result was kinda buggy and ugly.

Rounded corners is not the only usage of Hdy.Window, that widget it's a clear and empty space to start building your apps without pre-defined layout designs. That's why the Hdy.Headerbar can be placed anywhere, to let the app developer put the Window's controls wherever he/she wants or needs. See: https://blogs.gnome.org/alexm/2020/04/12/on-windows-and-titlebars/

Planner had the same sidebar layout before handy was around, I had managed to implement a sidebar using planner's source. You can check out the old source code for planner and see how it's done.

JeysonFlores commented 2 years ago

mmm you're right, I'm having trouble compiling from source an old version of Planner but it seems Alan put a Gtk.Paned inside a a Gtk.HeaderBar. I'll open a design branch to work on the mockup

JeysonFlores commented 2 years ago

Replicating the code of the first release of Planner 2.0 this is what I get: image It gives a hint of what should it be but it is not what we're looking for.

It seems Alan achieved this using hundreds of CSS code, I'm trying to modify it but I can only make it worse D: You can try it on the desing-mockup branch

JeysonFlores commented 2 years ago

I tried other alternatives like setting the decorated property of the Window to "false" but the result is even worse.