As the movie shows: dragging a pane on the right, that has been closed, in order to reopen it, is much easier than performing the same operation on a closed pane on the left.
https://github.com/user-attachments/assets/a4a85ec5-91e3-4f1b-870c-8fb16cc35...
Please could Geany enhance the **show message window** action to open such a closed left pane at 1/3 width, without having to drag it, to overcome this problem?
The video does not work so can't see what is your problem.
On my Linux Mint it is the same easy capability to grasp the pane handle to resize panes from zero width on both left and right panes.
Without being able to see your problem as the video does not work, its likely that your theme is part of the problem. Try changing the GTK theme to allow more pane handle width to make it easier to grasp.
Here there is nothing unusual and difficult, and so it is unlikely that anything is needed to be done with Geany.
This is pretty much a duplicate of https://github.com/geany/geany/issues/1753 and https://github.com/geany/geany/issues/3329.
From #3329:
Not Mac specific, the problem is that the default GTK theme makes the size of window pane handles extremely small, especially on high resolution screens. It would be a good exercise for your mentees to Google which GTK CSS setting controls that and set it in Geany.css.
The thing is that at least on macOS, once you start nearing the edge of the window with the mouse cursor, it becomes a window-resize cursor and resizes the whole editor window and you cannot grab the sidebar edge (it would have to be extremely wide, say 6px to be able to grab it).
I have a WIP patch I'll post maybe later today that at least allows users to get out of this situation without having to edit the Geany config file.
As both those previous issues have pointed out, it depends on themes.
Some themes are sized for HD screen resolutions, and then the handle size is fine for users to find, but if the resolution is QHD or UHD or finer then the handle may be far too small for users to easily find and use it.
It seems to be dependent on the way the theme is set. Some work perfectly well for me, both on an ancient HD laptop screen and a QHD screen. Perhaps these themes set the handle size as something that is not dependent on the resolution, or perhaps they load an image in the handle, but whatever that makes the themes pane handles usable on either system.
Perhaps if people have themes that are set badly they need to set the pane separator, but AFAIK there is no way Geany can include a setting for "crap"[^1] themes without interfering with "good" themes. AFAIK the only thing might be to include a commented out CSS entry in `geany.css` that users could uncomment if their theme is "crap".
@techee if Mac has a poor theme perhaps you could patch it for that only of course.
[^1]: technical term :grin:
As both those previous issues have pointed out, it depends on themes.
It's only you who blames themes but it's Geany that does a completely crappy thing here.
macOS applications have 0px window border size (the content of windows goes completely to the edge of the window) and when you drag the separator to the edge, you'll get a window resize cursor at the edge and you won't be able to drag the separator. Yes, one could make the separator crazy big like 8px so it's sufficiently far from the edge and draggable but I'd claim _that_ would be a bad theme wasting too much space just because Geany doesn't handle the situation right.
What Geany should do is: 1. When you drag e.g. the sidebar separator to the edge, Geany should un-toggle "Show sidebar" because technically it becomes invisible. This should probably happen at say 20px from the edge. So dragging the separator close enough to the edge becomes another way to hide sidebar. 2. When showing sidebar, Geany should set the position of the separator to at least those 20px so it becomes draggable again.
This is by the way how other macOS applications work (maybe even done automatically by the framework).
I have (2) more or less done, what's missing is (1).
What the [explitive] is wrong with you???
CSS!!! Try:
```css paned > separator { min-width: 20px; } ```
No code is needed.
No, sorry @elextr - one inch thick separator just isn't a good GUI and users shouldn't be required to make their theme shitty in order to workaround a problem in Geany itself. Things should work reasonably well regardless of what theme they use even if they use a "crappy" theme that uses thin separators which are considered "bad" by you.
When showing sidebar, Geany should set the position of the separator to at least those 20px so it becomes draggable again.
Well make up your mind, you said something about 20px, so I used that ;-). Clearly you need a sensible handle width, a few px.
IIUC because you have a fault on Mac that it removes the handle when you move the sidebar to zero and have to add code to get around your strange zero width handle, keep it as a patch on your Mac repository, as I have said, there is no need on Linux for it.
To be clear __on Linux the handle works__, the window pane handle can never be zero and can be caught and moved by the resize cursor. The handle is never reduced below the number set by CSS unless the sidebar is hidden by `View->Show sidebar` untick and then the handle is hidden with the sidebar (and both reshown when `View->Show Sidebar` is ticked). The pane handle is __NOT__ the sidebar hide function. No special Geany code is needed in Geany.
For users who have difficulty selecting the handle it can be made wider with one line of CSS, no code is needed on Geany. A commented out CSS can be added to `geany.css` ready for use where the user has problems with their theme.
Well make up your mind, you said something about 20px, so I used that ;-). Clearly you need a sensible handle width, a few px.
Please read in what context I said those 20px before saying the "make up your mind" crap - it was about the patch I created (#4023), at the end I made the snapping distance 10px only.
IIUC because you have a fault on Mac that it removes the handle when you move the sidebar to zero and have to add code to get around your strange zero width handle, keep it as a patch on your Mac repository, as I have said, there is no need on Linux for it.
I'm pretty sure there is such a need on Linux too and, no, it's not the way you say - you misunderstand the problem completely. The handle **is present** and doesn't have 0 size - it's just so close to the edge of the window that you can't grab it because at its position you get the window resizing cursor.
In the following let's assume that the first `|` is the left edge of the window and the second `|` is the draggable separator: ``` v v || || || ``` The distance between the two `v`s is the place where you get window resizing cursor - since the area includes the separator, you have no way to grab it. So the ability to resize the sidebar depends on: 1. The size of the separator 2. The distance between the first `|` and the second `v` (on my linux machine with Xfce it's about 2px, on macOS I'd say it's about 4px). I'm not sure what controls this, if it's some WM settings on linux or some theming thing. In any case I can imagine it can vary and some users may like the distance bigger so they can resize windows more easily. 3. The size of the window border itself (the first `|`). If windows have bigger borders, you probably won't run into the issue because it will make the distance of the second `|` further to the right. On Xfce I get the window border size about 3px; on macOS it's either 0px or 0.5px (I can't really tell - it's possibly just some shadow behind the window). I use the identical theme for the linux VM and Geany theme I use for the macOS version so this is definitely not controlled by the GTK theme - probably a WM theme.
So for **identical** GTK theme, I get 2 different behavior because of (2) and (3) above and in one case it is possible to drag the separator, in the other it is not possible. And no, there's nothing "crappy" or "buggy" on borderless windows and window resizing cursor "deeper" in the application window.
By the way, just test how VSCode behaves if you think I'm doing something idiotic. Other applications tend to restrict how much you can drag sidebars but I don't think it's a good match for Geany.
No special Geany code is needed in Geany.
Please, next time at least try to understand the problem first before making such claims.
Just to repeat, I do __NOT SEE A PROBLEM__. Even when the sidebar is set to zero width and the cursor is then moved off the window, moving the cursor back switches to window resizing cursor then to the pane handle cursor then to line number margin cursor. There is a reasonable period as pane handle cursor to drag it back again, there is no problem with either of my Linux Mint systems on either low resolution old laptop or newish 27" QHD.
Your better explanation (thanks) of what you see describes your problem more clearly, but again I do not see the problem you see.
The thing that needs to be explained is why is it bad for you, but not for me, and then what possible solution there is in LM themes, or maybe its something set in Cinnamon and XFCE is different or its something else. But whatever, we should know why the behaviour is different between systems before jumping into any solution is decided (geany.css or code or whatever?).
By the way, just test how VSCode behaves if you think I'm doing something idiotic.
I originally deliberately didn't murky the problem with Vscode, it is different, but will explain.
1. it has a fixed left narrow sidebar with icons for selecting which of several sidebar contents is shown (and unhides the sidebar if an icon is selected). It is not resizable or removable (at least as I can find) so confusion with window resize is not a problem. 2. the actual sidebar contents is resizable, but it can only be dragged to a minimum (dunno where its defined but its about 15 characters) 3. but if the handle is continually dragged passed the minimum and close to the left edge it will activate the "hide sidebar" action instead of the "resize" action. There will be no handle. When the "unhide sidebar" is actioned it will come back to the original size not the minimum value.
So its all different and probably not helpful here.
Please, next time at least try to understand the problem first before making such claims.
We neither of us understand why it works in some places and not others, claims that "only code is needed" is as bad as "just CSS" and we need to understand it first.
Hmmm, noticed on another app and went back to Geany. The behaviour here on my system seems to be slightly different to yours but I have found it hard to describe, if you don't understand it ask!!
The Geany sidebar is minimised but not hidden so there is still a handle.
The sequence of icons that the user sees as the mouse controlled position is moved from left to the right is:
1. the desktop cursor icon thats default on desktop 2. the window left edge resize cursor icon 3. the pane handle resize cursor icon 4. the line number margin cursor icon
The mouse moves a position it controls smoothly from left to right through a sequence of areas that selects the cursor icon[^1]: ``` 1 desktop | 2 outside window | 3 pane handle | 4 line number margin ``` Area 1 is outside area 2 and the window. Area 2 is outside the window like a frame outside the window, it seems approximately the window resize icon width Area 3 is the handle width inside the window edge, set by theme or `geany.css` Area 4 is the line number margin as wide and set by code as line numbers change size.
But how the cursor icon varies in relation to the mouse position:
1. desktop cursor icon is right of the mouse position, if the mouse position is in area 1 2. window resize cursor icon is right of the mouse position ,if the mouse position is in area 2 3. handle resize cursor icon is equal left and right of the mouse position, if the mouse position is in area 3 4. the line number cursor icon is left of the mouse position, if the mouse position is in area 4
The point is that the cursor icon is visible and usable for the width of each area as the mouse position is in that area, it doesn't matter if the icons happen to be left, right or spread both sides of the position.
The widths of 1, 2, 4 are set by various things, but 3 as noted, the width of the handle is either the default theme settings or the CSS in `geany.css`, and the cursor will have that width available for the mouse position to move its cursor, and in that range be available to click and move the the sidebar width. It is irrespective of how the cursor icons move relative to the mouse position and might confuse users, it is how the mouse position moves that controls the cursor selected.
I am not sure what you are seeing on your XFCE or Mac, it sounds like its different, if the mouse position width allowed for each icon is different to some setting or something. But that is specific behaviour that those particular desktop systems have and it is different to the behaviour of Cinnamon which simply follows the settings and needs no fix.
So now the discussion we need to consider is how problems with Mac and XFCE can be approached without affecting Cinnamon that has no problem and does not need any fix. As I said Mac is easy, you can apply any patch to it by itself, but if XFCE does something weird and Cinnamon works sensibly then code in Geany is going to be hard to accept for XFCE and not accepted for Cinnamon.
So more experimentation and discussion is needed with each having a different distro to try.
And of course what all the other desktops do might be something else making it even more complex.
[^1]: I tried to take pictures showing this stuff, but I couldn't get cursor icons to show right, so lots of words, sorry
> I originally deliberately didn't murky the problem with Vscode, it is different, but will explain.
> 1. it has a fixed left narrow sidebar with icons for selecting which of several sidebar contents is shown (and unhides the sidebar if an icon is selected). It is not resizable or removable (at least as I can find) so confusion with window resize is not a problem.
Yes, that's true and this would help us because then the handle would be far enough from the window edge and would be draggable but we don't have it in Geany.
> 2. the actual sidebar contents is resizable, but it can only be dragged to a minimum (dunno where its defined but its about 15 characters) > 3. but if the handle cursor is continually dragged passed the minimum and close to the left edge it will activate the "hide sidebar" action instead of the "resize" action. There will be no handle. When the "unhide sidebar" is actioned it will come back to the original size not the minimum value.
This is pretty much the behavior I implemented in #4023. For (2) i used 10px as the minimum.
> We neither of us understand why it works in some places and not others, claims that "only code is needed" is as bad as "just CSS" and we need to understand it first.
I think I understand very well why it doesn't work and tried it to describe but maybe not clearly enough. On macOS you always get window resize cursor in a certain range around the window edge - this is marked by the red lines below:
<img width="624" alt="Screenshot 2024-11-01 at 17 14 57" src="https://github.com/user-attachments/assets/127fbdfc-4500-45fd-a5a8-fa0b7baf2...;
So whenever you are within this area with the mouse pointer, you will resize the whole window (I think the application doesn't receive the corresponding event at all in this case, it's processed by macOS window manager). You can notice the separator handle is present in the screenshot but because of the fact that window borders are near zero on macOS, it's very close to the edge and within the "red" area and therefore undraggable.
I can imagine you could get the same on linux with some window managers and window manager themes (this is not about GTK themes).
@elextr Just to describe what @philiprbrenan showed in the screencast - he uses KDE, has the message window on the right and it seems there's only 1px tolerance where he can drag the message window from the right edge <img width="282" alt="Screenshot 2024-11-01 at 17 41 39" src="https://github.com/user-attachments/assets/4371c7d6-6f0f-45e3-b117-b1ebe6814...;
because 1px to the right he gets the window resize handle <img width="282" alt="Screenshot 2024-11-01 at 17 42 03" src="https://github.com/user-attachments/assets/78d674a8-c025-4790-b756-91574dab3...;
and 1px to the left the mouse event is grabbed by the scrollbar <img width="302" alt="Screenshot 2024-11-01 at 17 41 12" src="https://github.com/user-attachments/assets/4d1af14d-749d-475e-b640-0d670e823...;
Now we can start blaming the theme and say he should use 10px separators but I think 1px separators are just fine (and I'd call this a "good theme" not wasting too much space) and I think Geany should behave better in such situations.
> This is pretty much the behavior I implemented in https://github.com/geany/geany/pull/4023. For (2) i used 10px as the minimum.
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.
To be clear, the Vscode behaviour is not like your #4023 as I best understand:
1. #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 2. #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 3. 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
Perhaps you could make #4023 closer to Vscode as you suggested, it not do resize if it hides, that would be useful for the user instead of trying to get a width again after its unhidden.
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.
Or even better throw away the labelled tabs and add a icon selector ... oh ok too far maybe ;-)
> I can imagine you could get the same on linux with some window managers and window manager themes (this is not about GTK themes).
Thats the point I realised on Cinnamon and described on my post that I hope you understand, you have the handle cursor icon for the width the mouse position is within the red lines, no matter what is covered by other cursor icons when the mouse position is outside the handle width. Don't get confused between the mouse position and the icon position, the mouse position should not jump but icons may appear to jump.
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.
Since Cinnamon is originally a fork of Gnome I would guess Gnome behaves the same, but it needs checking. Other desktops needs analysis too (nah, I don't have any other than Cinnamon).
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.
But it still is the position that Cinnamon does not need any special behaviour.
I don't think I understand all details of your argumentation and especially not why it got that heated :(.
To me it seems, what the OP described is a valid scenario and it doesn't matter who is to blame as it just might happen to users (including me). So #4023 is a good countermeasure to just help users to get the panes back easily, even if it is not Geany's fault.
As I said in #4023, the sizes after the panes have been restored are not perfect on my system but they probably never will be perfect on all systems as it is certainly influcened by GTK themes and maybe DPIs and whatever else. So I think it is fine to restore it so somewhat sane sizes and so give the user the possibility to adjust to her needs.
Thanks @techee!
> why it got that heated :(.
It wasn't meant to be heated, just badly misunderstood behaviour by different systems, and neither of us having the same system ;-), and Cinnamon and XFCE behave different so we have misunderstandings, so we had to get ourselves having a suitable understanding. Cinnamon just needs wider CSS entry so users can resize the sidebar, but I still don't know why XFCE doesn't?
> So https://github.com/geany/geany/pull/4023 is a good countermeasure to just help users to get the panes back easily, even if it is not Geany's fault.
As I said above "Perhaps you could make https://github.com/geany/geany/pull/4023 closer to Vscode as you suggested, it not do resize if it hides, that would be useful for the user instead of trying to get a width again after its unhidden."
Just the first solution in a PR doesn't have to be the best one until we finish discussions.
> As I said above "Perhaps you could make #4023 closer to Vscode as you suggested, it not do resize if it hides, that would be useful for the user instead of trying to get a width again after its unhidden." > > Just the first solution in a PR doesn't have to be the best one until we finish discussions.
Sure. On the other hand, it might not be worth it to spend much time in finding the perfect solution for an edge case when we already have a quite good solution. It can be optimised later anyway or we spend our limited time on other open topics. After all, I'd leave this decision to @techee.
> we already have a quite good solution.
Maybe its not evident due to all the discussion, but to be clear, to me it isn't a good solution at all.
> 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.
> 1. https://github.com/geany/geany/pull/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.
> 2. https://github.com/geany/geany/pull/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).
> 3. 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 https://github.com/geany/geany/pull/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 https://github.com/geany/geany/pull/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 https://github.com/geany/geany/pull/4023 at all. After you do, please suggest what should be changed.
> > we already have a quite good solution. > > Maybe its not evident due to all the discussion, but to be clear, to me it isn't a good solution at all.
Still after @techee's explanation above? I'm not convinced that insisting on mimicking the VSCode behavior might lead to delay this issue for some years although we already have a working solution. Yes, not the one you prefer but as said before, this is rather an edge case and putting so much efforts on it with all our limited spare time might not be worth it.
github-comments@lists.geany.org