Rethink toolbar layout

[bertob]

Currently the app has three "toolbars":

• The headerbar, including the tool chooser (split out into a separate toolbar on small sizes)
• The active tool options
• The floating toolbar with zoom/undo/etc

The active tool options are the group with the most content, yet it's vertical, which is usually the shorter axis, leading to scrolling. The zoom/undo/etc buttons feel like they'd be more appropriately grouped with view options and save in the toolbar than the tool chooser, which is more directly linked to the canvas and tool options.

I'd try something like the following:

• Tool options as a horizontal bar at the bottom
• Zoom/undo/etc in the headerbar
• Tool chooser as a toolbar or floating buttons on the side
• This would also allow moving the save button to the right side, which would be more in line with other apps

[benjamin051000]

As a lefty, the floating undo/redo buttons do get in the way sometimes... It would be nice to be able to move them, either to another corner, or in the headerbar would be fine too. I do love the aesthetic of it right now so it's difficult to say what would be best.

[flxzt]

I am in the process of implementing tabs and took the opportunity to move some things around, based on your suggestions. What do you think @bertob ? Obviously needs more polishing but you get the idea.

I feel like the zoom / undo buttons in the headerbar are a bit too much, especially in the "fixed-size" layout where two additional buttons appear (for adding / resizing pages ). When removing the zoom-in / zoom-out buttons, it should be okay.

I now think that the bottom toolbar could work, in contrary to the concerns I previously expressed regarding UI where the writing hand lays. When it is in the center, it probably won't be in the way too much.

Edit: Another papercut I noticed when having the undo /redo buttons in the headerbar, is that when no undo is possible, and you still click, you end up maximizing the window. Not ideal

[philipwilk]

imo, the spanner section with the move tools feels a bit strange. Maybe the two move tools could merge into one icon, and then have a toggle between them under the tool options bar on the side.

[bertob]

This definitely looks like a step in the right direction, but the overall layout still feels a bit odd. I think part of it is the combination of floating and non-floating toolbars, as well as the non-symmetric layout. I'd try moving the top toolbar to the left, and making the one on the right float as well.

[flxzt]

Do you have a suggestion where to put the flap toggle button when it becomes floating?

Still not too enthusiastic about moving UI to the side where the writing hand / palm is..

@wiryfuture I don't understand, what do you mean by merge into one icon? They are two different tools, one is to move the canvas, and the other is moving the strokes and more miscellaneous tools likely will be added in the future

[bertob]

Do you have a suggestion where to put the flap toggle button when it becomes floating?

Would it be a problem if the toggle is in a floating toolbar? Otherwise I guess it could be in the headerbar, like in Builder.

[flxzt]

I'll try it. Could be confusing though, grouped with the per-pen options. It could simply have its own floating section

A different random thing: no expectations, but I would happily swap the "stroke color " / "fill color" icons out for better ones.

[bertob]

A different random thing: no expectations, but I would happily swap the "stroke color " / "fill color" icons out for better ones.

Happy to take a look once I'm able to build the project again. Maybe open a separate issue so it's easier to keept track of?

[flxzt]

Maybe open a separate issue so it's easier to keept track of?

Done.

Here is how it looks with a floating sidebar, with the flap toggle in the headerbar:

Not sure I like it though, with small window sizes the layout becomes awkward and since the sidebar always takes the size of the largest page, with many pens there is a lot of empty space which looks weird in combination when it floats. When your build works again, check out the overlay-sidebar branch to see yourself

[bertob]

I've played with the overlay sidebar branch a bit. It definitely feels like a step in the right direction, the three floating toolbars feel very natural for a drawing app, and the canvas looks much bigger. I think with some adjustments this layout can be super nice. Some notes:

• The toolbar mostly being empty in some cases is indeed a problem, but does it have to be the size of the largest page? Could it dynamically resize to take up only the space it needs? Alternatively we could maybe try centering the content when there's empty space, but not sure that'd work in all cases.
• I'm not too worried about very small window sizes, to support those properly we'd need a bit of a different layout optimized for that anyway (e.g. non-overlay toolbars, hiding some of the toolbar options in submenus to conserve space, etc.)
• All the toolbars should be the same distance from the canvas edge (I'd use the smaller distance from the bottom one for all of them).
• It's unclear to me why the side toolbar can be on both the left or right, I'd always keep it in the same place for a simpler and more predictable layout.
• The same goes for the files drawer. If it was always on the same side, the show/hide icon could be on that side of the headerbar.
• It's a bit weird to have a floating toolbar below the headerbar, I'd move that toolbar to the side instead, so that there's one toolbar on each side

[rapgenic]

Hi, first of all thank you for the great app, I've been using it heavily for the last few months and it's been incredibly useful.

I've been testing the beta release a bit, and I'm finding it a nice improvement, mainly in term of reachability of the controls, which require less hand travel.

I'd like to add some feedback on some of the suggestions by @bertob, which are quite important for me as a heavy user, in regards to the positioning of the side toolbars:

• having a toolbar on the side of my dominant hand would be for me very strange, because it would be reducing my writing space, and most of all I'd be constantly worried of changing some setting by mistake (plus I'd be covering the controls with the hand most of the time, as I tend to keep the hand quite still on the screen)
• given this premise, as a left handed person, it is also fundamental for me to be able to place the side toolbar (and files drawer) on the opposite side of what most people would do, so big plus for the possibility to choose left or right positioning.

[philipwilk]

This new layout does not work at all when in portrait mode, (from the beta I have tried) as everything is now on opposite sides of the screen. On my 12.3" laptop, this is incredibly uncomfortable to use. Maybe if you could move the tools bar next to the colours bar? I also find it uncomfortable in landscape because it's quite far on that as well.

[flxzt]

I think with some adjustments this layout can be super nice

I think so too!

but does it have to be the size of the largest page

The current stack implementation does that unfortunately, I am not sure if this can be altered without manually reimplementing it. the vhomogeneous property can toggle this, but then the transitions look odd. Also not a good look when centering the contents vertically. But with the recently added stroke-width palette it isn't that much of an issue anymore, see:

I'm not too worried about very small window sizes

You're probably right. Also I recently saw the AdwAdaptiveState PR in the libadwaita repo, that looks really nice and could be used to create a second mobile friendly overlay for smaller sizes when it is merged.

All the toolbars should be the same distance from the canvas edge

unfortunately the scrollbars are in the way, and I don't want to hide them entirely. The margin values could be dependent whether they are enabled though

It's unclear to me why the side toolbar can be on both the left or right

As I already previously and @rapgenic mentioned, I want to keep the side where the writing hand lays clear of UI, the sidebar setting for left- and right handed writers is pretty important to me (I am a lefty too)

@wiryfuture has a good point, I didn't think of tablet users in portrait mode when placing the tool switcher on the bottom. I tried having both on top in a flexbox like fashion, but I had trouble with alignment when using GtkFlowBox. It doesn't seem capable of centering both toolbars when they are in the same row equivalent to flexbox' justify-content, or at least I couldn't get it to do that.

I think overlay-sidebar is still an improvement, so I am planning to merge it eventually.

[philipwilk]

I think with some adjustments this layout can be super nice

I think so too!

but does it have to be the size of the largest page

The current stack switcher implementation does that unfortunately, I am not sure if this can be altered without manually reimplementing it. Centering the contents vertically also looks a bit weird. But with the recently added stroke-width palette it isn't that much of an issue anymore, see:

I'm not too worried about very small window sizes

You're probably right. I also recently saw the AdwAdaptiveState PR in the libadwaita repo, that looks really nice and could be used to create a second mobile friendly overlay for smaller sizes when it is merged.

All the toolbars should be the same distance from the canvas edge

unfortunately the scrollbars are in the way, and I don't want to hide them entirely. The margin values could be dependent whether they are enabled though

It's unclear to me why the side toolbar can be on both the left or right

As I already previously and @rapgenic mentioned, I want to keep the side where the writing hand lays clear of UI, the sidebar setting for left- and right handed writers is pretty important to me (I am a lefty too)

@wiryfuture has a good point, I didn't think of tablet users in portrait modes when placing the tool switcher on the bottom. I tried having both on top in a flexbox like fashion, but I had trouble with alignment when using GtkFlowBox. It doesn't seem capable of centering both toolbars when they are in the same row equivalent to flexbox' justify-content, or at least I couldn't get it to do that.

I think overlay-sidebar is still an improvement, so I am planning to merge it eventually.

Have you tried something similar to the css grid display attribute for aligning the menu bar? It would allow you to use relative, automatically scaled distances for the edge padding, then you could have the items in one flexbox with some padding inbetween them, and the whole group of them would be automatically pushed into the center by having them in the centre grid row using a width like fit-content or auto.

[flxzt]

@wiryfuture I don't think css layout is supported in gtk, it only has limited support for styling: https://docs.gtk.org/gtk4/css-properties.html . You still need to do the layout with Gtk's widgets

[PJansky]

I've given my feedback in #516 which was correctly closed as duplicate, but for completeness I 'm posting it here again.
My Feedback from #516

I don't think the new 3 panel design is ideal from a UX perspective and this is reflected by other note-taking apps like Notability, Goodnotes or OneNote not having anything similar. Most other note-taking apps I've looked at have one toolbar at the top. This gives the user a good mental model of "If I want to change something, I look to the top of the window". With the new Rnote design, the user has to think about which tools/settings are where. stroke color -> top; stoke width -> left; shaper -> bottom; fill color of shape -> top. I understand what you tried to do with having the top panel staying constant and having the left panel change based on the tool selected in the bottom panel, but I don't think this really works. In addition the bottom toolbar is often covered by your hand while note-taking. I personally think a more minimalistic top toolbar approach like the one found in GoodNotes would be better suited for Rnote. It looks to me like a good middle ground in between the feature richness of OneNote and still keeping a more simple design like Notability.

I still think a more traditional "top toolbar only" approach would be more familiar and easier to use. Seemingly I'm alone with this criticism so do with this feedback what you will and keep on making this great app better.

[jaklt]

@PJansky no, you're not alone in this :-)

I'm trying to get used to the new layout but I still preferred the previous one. But I do love the option to have tabs, so I understand that something had to be done.

My main issue is that the tools and their settings are now in three different places and I constantly have to think if something is on the top/bottom/right... Also, I find having floating elements distracting and the fact that it's three of them doesn't seem like a good use of space.

[benjamin051000]

@jaklt I agree. Perhaps once I learn the new layout and get more comfortable with it over time, it'll be better, but at least right off the bat it's less intuitive because I find myself searching for the button I need more often than I'd like.

[flxzt]

I am hoping the now merged libadwaita breakpoints will make different layouts for different sizes possible

[vBazilevich]

Hello! Could you please return the add page button to its previous location? Currently it's in the page settings menu and it isn't as convenient as it was before. Especially, when you record or share your screen.

[Fedefilice]

Hello, i think too that a toolbar simplification is needed. I believe that a "top toolbar" like suggested by Pjansky could be a good thing, but another option I tought is this one i draw which is similar to the existing one but more cleaner and simpler to use.

Moreover i believe it would be more functional if you could move it on one, predefined spot, of the four corner of the screen.

[mahdihasan2006]

@Fedefilice I also thought very similar to you. Here is my thought:

Sample menu:

Notes

1. Click to open the options First click to select a tool, then click on selected tool to open it's options menu. Click outside the menu to make it disappear. May be ignoring the first pen stroke will prevent unwanted points.

2. A large option menu with most options in an organized way.

3. The menu will be movable to left, right, up and down of the screen.

[jrr96]

Hi! Thank you for the amazing tool. It feels amazingly snappy and I really appreciate that you open sourced it. I do however, struggle a lot with its UI. Below I am writing some ideas on how I would go about it...

Menu consolidation

As it stands there are two sets of buttons on the top ribbon and three toolbars. This is just way too much in too many places to pay attention to. I would consolidate all the buttons on the top leaving to the left only minimize, maximize window and close application buttons.

Regarding buttons themselves, I like the new tab and hide toolbars button. I find the displacement effect when opening the sidebar extremely distracting, probably due to how wide it is. I believe a floating window might work better.

Finally, there is a button that moves from the top right to the top left when opening the side bar?? The button which has three lines as an icon. I also find this behavior really confusing.

Toolbar layout

I would like to see a differentiation between quick access tools (predefined by the user) and the full menu. When taking notes I am most of the times just using a 2 to 5 tools and being able to quickly switch between them without having to configure them from scratch is great. Furthermore, it prevents me from accidentally using a different format.

That being said I also think that a color and width selector should also be part of this quick access toolbar since this two elements impact almost every other tool. I myself would also like to see a zoom selector where I can preset different levels but I am not sure how other users would feel about it.

I think the concepts app is probably best in class when it comes to a quick access toolbar.

Tool interaction

I would add a current tool icon. When the user selects one of their preset tools, the current tool copies the settings of the preset tools that the user selected. If the user selects any other tool from the extended menu, the current tool will take the default properties of that selected tool. Finally, when the user selects a color or a width from the quick access toolbar, this settings are modified in the current tool.

I believe this set up combines the quick workflow of having your main tools quickly accessible without impeding using the full range that rnote offers AND still being very user friendly and understandable.

[mahdi4260-1]

Currently, the top bar, the color selection bar and the bottom toolbar takes good amount of space, specially in small screens.

I think the 2nd design will give users more space for their work.

• A set of tools in the top bar.
• Clicking the tool again will show some kind of sub-menu for extra options for each tool.

[mityax]

I just found this discussion and, while I don't want to hijack it, I think it's worth mentioning that another approach to giving the users more space for their work would be automatically hiding/unhiding the floating toolbars, like I suggested in issue https://github.com/flxzt/rnote/issues/1288.

The idea would basically be that, if the user has enabled the "hide toolbars" button, each toolbar is temporarily shown when the user hovers close to the according canvas edge with their pen and is hidden again afterwards. That way, the toolbars remain relatively easily accessible (as they are) and there's no need to introduce further double clicks/nested menus.

Of course this is not mutually exclusive with toolbar redesign – I just wanted to point to this idea here since I feel like it's related and might be of interest.