feat: Align left sidebar with vertical stylus palette by baetjer · Pull Request #1496 · OpenBoard-org/OpenBoard

baetjer · 2026-05-28T18:14:34Z

Add an optional left offset for the for the left dock palette
Position the sidebar tab next to the vertical stylus palette
Update the offset when the stylus palette changes orientation or visibility
Keep the existing behavior unchanged for horizontal stylus palette

Closes #1483
References: #1483

Signed-off-by: claas998, baetjer, SofianElmotiem

- Add an optional left offset for the for the left dock palette - Position the sidebar tab next to the vertical stylus palette - Update the offset when the stylus palette changes orientation or visibility - Keep the existing behavior unchanged for horizontal stylus palette

- Remove the gap variable - Return button size to the original size (42)

abdna94

Looks like a great feature! Just a tiny typo in the PR description's first bullet point, "the" is repeated twice. Other than that, the commits and description look really clean!?

Vekhir · 2026-05-30T09:57:12Z

I don't feel like this is the right solution. For me, the left dock should close with the board frame, and the stylus palette (that's free to move anyway) should adjust to the dock and be kept "inside" the board.
The presented solution leads to visual noise with empty space above and below the vertical stylus palette, and the closed dock having a floating handle in the middle of nowhere.

Thus, the stylus bar should adjust to the dock, not the other way around.

On the commits, the Signed-off-by should be on the individual commits for easy reference later on.
Since the second commit only fixes things introduced by the first one, it makes sense to combine them into a single commit. During rebase, there is the option f (fixup) to do just that.

Last note, though it doesn't matter much since the comment got removed; comments should be in English.

Vekhir · 2026-05-30T12:01:41Z

@abdna94 You can ping your teammates, or ask them yourself. I don't think actively waiting will achieve much.

Nevertheless, I'm interested in the considerations and the reasoning behind the decision. I like to add them into my commit messages, so others can follow my thought process. Oftentimes, this is also useful for later, when issues occur or better solutions might arrive.
It's easy to see what the code does, not so much why it's done this way. Hence the commit messages.

Even if sometimes, especially for graphical changes, it requires running the code to get a good understanding of its behaviour.

claas998 · 2026-06-02T07:32:33Z

@Vekhir Thanks for the detailed feedback!

My initial reasoning for this approach was based on the wording of #1483. I understood the requested behavior as keeping the stylus palette in its current left-side position and opening the sidebar next to it, so that the stylus palette no longer overlaps the sidebar.

I agree with you, that keeping the dock/sidebar layout as the stable element and moving or offsetting the vertical stylus palette when the left sidebar is opened seems like the better solution.

Before reworking the implementation, I just want to clarify which behavior would be preferred: should the vertical stylus palette be moved/offset when the left sidebar is opened, or would the alternative mentioned in the issue (automatically hiding the stylus palette while the sidebar is open) be the better approach?

Vekhir · 2026-06-02T07:49:21Z

should the vertical stylus palette be moved/offset when the left sidebar is opened

This is the preferred behaviour for me. It keeps the full functionality available. It's also consistent with how the stylus palette behaves with respect to the toolbar when the latter is moved to the bottom.

If desired, the stylus palette can always be manually hidden.

Revert the previous approach that offset the left sidebar based on the stylus palette position. The sidebar should remain anchored to the window edge, because it behaves like a fixed panel and should not be moved by a floating palette. Instead, offset the vertical stylus palette based on the left sidebar tab an opened sidebar geometry. This keeps the sidebar open button accessible while the sidebar is collapsed, and moves the stylus palette beside the opened sidebar when the sidebar is expanded. Horizontal stylus palette behavior remains unchanged. This reverts commit 98419fa. Signed-off-by: claas998

Vekhir

Looks good! A few minor questions arose, the general behaviour is what I expected.

Vekhir · 2026-06-03T21:32:19Z

+    int offset = mLeftPalette->x() + mLeftPalette->width();
+
+    const QRect tabRect = mLeftPalette->getTabPaletteRect();
+
+    if(!tabRect.isNull())
+        offset = qMax(offset, tabRect.x() + tabRect.width());


Doesn't mLeftPalette->x() and mLeftPalette->width() include tabRect?
I'd have thought qMax(offset, tabRect.x() + tabRect.width()) == offset

Vekhir · 2026-06-03T21:37:32Z

+    if(!mLeftPalette->isVisible())
+        return 0;


Does this actually trigger when the left dock is closed? It seems that even if closed, the palette size is taken into account, creating an unnecessary gap.

Vekhir · 2026-06-03T21:42:42Z

+        connect(mLeftPalette, SIGNAL(pageSelectionChangedRequired()),
+                this, SLOT(updateStylusPalettePosition()));


This is a nice idea.
To expand on that, maybe a separate signal could be used instead of pageSelectionChangedRequired that could be fired during UBTabDockPalette::mouseMoveEvent to provide a smoother change and adapt the stylus palette immediately. At the moment, it only updates at the end, when the mouse is released.

Vekhir · 2026-06-03T21:46:38Z


    if(UBSettings::settings()->appToolBarOrientationVertical->get().toBool()){
-        int posX = border();
+        int posX = qMax(border(), verticalLeftOffset);


I think adding them instead of using qMax is better, as that would create a slight separation to the left dock palette. When the palette is at the bottom, it also has that separation for easier distinction.

qqqqqqqqq9 · 2026-06-13T15:47:29Z

Hi,

this is mostly what I had in mind, thanks!
There just one small glitch. The stylus leftaligns to the right of the handle instead of the left border of the window. Or is this intended?
Thanks.
P.S. This should be adopted for the right pane, too?

Base the vertical stylus palette offset only on the expanded left sidebar width instead of the sidebar tab. This removes the extra gap while the sidebar is collapsed, but still keeps the stylus palette next to the sidebar when it is expanded. Add a dedicated dock geometry signal so the stylus palette updates continously while the sidebar is resized. Signed-off-by: claas998

claas998 · 2026-06-18T16:04:03Z

Thanks for the review comments.

I adjusted the offset calculation so the stylus palette is now only shifted based on the actual expanded left sidebar width, not the sidebar tab/handle. This removes the extra gap when the sidebar is collapsed and also avoids aligning the stylus palette to the handle instead of the sidebar itself.

I also changed the positioning to keep a small border between the expanded sidebar and the stylus palette, and added a dedicated dock geometry signal so the stylus palette updates continuously while the sidebar is resized, instead of relying on the page selection signal.

I did not extend this to the right pane for now, since this PR is focused on the left sidebar / vertical stylus palette behavior. I think that would be better handled separately if needed.

claas998 added 2 commits May 25, 2026 16:44

Align left sidebar with vertical stylus palette

0e2c00d

- Remove the gap variable - Return button size to the original size (42)

abdna94 reviewed May 30, 2026

View reviewed changes

Vekhir suggested changes Jun 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat: Align left sidebar with vertical stylus palette#1496

feat: Align left sidebar with vertical stylus palette#1496
baetjer wants to merge 4 commits into
OpenBoard-org:devfrom
claas998:feat-stylus-bar-should-not-obscure-the-sidebars

baetjer commented May 28, 2026

Uh oh!

abdna94 left a comment

Uh oh!

Vekhir commented May 30, 2026

Uh oh!

Vekhir commented May 30, 2026

Uh oh!

claas998 commented Jun 2, 2026

Uh oh!

Vekhir commented Jun 2, 2026

Uh oh!

Vekhir left a comment

Uh oh!

Vekhir Jun 3, 2026

Uh oh!

Vekhir Jun 3, 2026

Uh oh!

Vekhir Jun 3, 2026

Uh oh!

Vekhir Jun 3, 2026

Uh oh!

qqqqqqqqq9 commented Jun 13, 2026

Uh oh!

claas998 commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

		connect(mLeftPalette, SIGNAL(pageSelectionChangedRequired()),
		this, SLOT(updateStylusPalettePosition()));

Uh oh!

Conversation

baetjer commented May 28, 2026

Uh oh!

abdna94 left a comment

Choose a reason for hiding this comment

Uh oh!

Vekhir commented May 30, 2026

Uh oh!

Vekhir commented May 30, 2026

Uh oh!

claas998 commented Jun 2, 2026

Uh oh!

Vekhir commented Jun 2, 2026

Uh oh!

Vekhir left a comment

Choose a reason for hiding this comment

Uh oh!

Vekhir Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

Vekhir Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

Vekhir Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

Vekhir Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

qqqqqqqqq9 commented Jun 13, 2026

Uh oh!

claas998 commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants