No thats not what Vscode does, it hides the sidebar but does not resize it, so when its unhidden it will be the original size.

I don't think it matters much what size it is - it should just be reasonable, draggable and visible, not forcing users to find the exact pixel like in the screencast or not being draggable at all like on macOS.

#4023 the resizing happens at any distance to miniscule (eg 10px) even if the value is unusable, Vscode has a usable minimum sidebar width (20 chars by my count) and cursor moved further left but the sidebar does not get smaller and then the cursor becomes the hiding action

I'm not sure if I understand what you mean exactly - I chose 10px (if you have some arguments for other value, let me know) because anything bigger is far enough from the border, visible, and draggable.

#4023 because the resizing is going to happen as well as the sidebar hiding, it will always be hidden at miniscule width, but Vscode does not resize the sidebar if you hide it with the cursor

Again, not sure what you mean exactly (have you tried the patch at all?). The sidebar/msgwindow will be restored at a reasonable value (as @eht16 suggested, it would be best to use the default size, right now it's slightly off).

when a sidebar is unhidden by the tick, it has a miniscule width, then the user has to resize, trying to get something like the original size, hmm that wide, no maybe a bit more, oh no too far back up a bit, oh maybe more etc, Vscode can unhide with both the icons, and the menu tick just like Geany's but the width is the original size the sidebar, so the user does not have to try and get back to the original size they used to like by guesswork

It resizes to the default value which may be slightly off regarding what the user wishes but compare it to the current situation when one has to play some mouse-pixel-precision games to be able to grab the separator and then resize it to the desired size.

And even better maybe a limited minimum useful sidebar width (with a setting in prefs). This makes it visible to the user that what they really wanted to do is hide the sidebar, not get confused with a handle as the OP described their users behaviour.

I personally prefer no configuration and freedom to resize the sidebar/msgwindow to whatever value unless it's too close to the edge.

Your "imagine" is unknown for any Linux desktop except XFCE, but you "imagine" it ;-), not analysis and describe the XFCE behaviour in detail yet, or at least maybe I missed /misunderstood it. For Cinnamon that I have detailed described, and which obeys handle width correctly as its set by theme or geany.css, it needs nothing. But we have no idea what other desktops do.

I'm sorry @elextr but I don't understand what you are trying to say. Yes, you said million times that it works on Cinnamon and works for you and I get it. But you refuse the fact that it doesn't work on macOS (so we have an idea what macOS desktop does) and with the OPs screencast it "works" but you have to hit the right pixel with the mouse which is not user friendly at all.

As for KDE users, thanks for the analysis of the OP. AFAICT we can't do anything specific for KDE, KDEs mapping of its theme to GTK theme is not understood. All we can do is have the commented entry in geany.css available to control the handle width and hope KDE doesn't override it.

And, again, why not something like #4023 which solves the problem for all the desktops?

I really don't get your argumentation and I'm not sure if I have the patience to repeat over and over the same so I'll rather concentrate on improving #4023 than this thread. The problem exists. This is not user friendly. On macOS you have to edit the config file to recover from the situation, there's no UI way. When resized to the edge, msgwindow and sidebar are invisible and it isn't clear to users what happened and how to restore them.

Maybe its not evident due to all the discussion, but to be clear, to me it isn't a good solution at all.

From what I understand, you haven't tried #4023 at all. After you do, please suggest what should be changed.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.