Messages window height 0 - irritating

[hartmut27]

Feature Request:

You can close Messages Window.
But on Linux you can set its height to 0 also
(dragging window top frame border with mouse down to lower bar of screen).

Then the Message window is active, but you can't see its contents.
e.g. when starting Find in Files, you get some search results, but you can't see and this is irritating.

[elextr]

What is the feature request? The above seems to be a series of statements of existing capability.

[hartmut27]

When the "message window resize / set height to 0" event occurs, ignore this event, instead hide message window. Later, when the user unhides the message window (e.g. showing Find in Files results) the message window reappears in its original dimension.

[codebrainz]

What if the user set it to 0 height on purpose to prevent it from popping up all the time? (I do this)

[hartmut27]

Which function does pop op the message window and you don't want this?
To prevent this I propose you write a separate feature request supressing this behavior. e.g. a new option "Popup Message Window automatically y/n".

[elextr]

@hartmut27 I don't understand why you want set height 0 to hide the window? If you want to hide it do that. Menu->View->Show message window unticked, and/or define a keybinding for it if you want to (I use Alt+m).

[hartmut27]

@elextr I don't "want" to set the height 0. the message window has no close button (no cross icon in the right upper corner, as notepad++ does for example). perhaps with an close window icon this request would me less imortant...
to use the menu option to close a window - this seems to be a bit over-complicated.
one way or another... a window with height 0 which formally is in visible state, and at the same time is not visible, does not make sense to me and confuses users in my eyes. this is the reason why I've issued this topic. notepad++ on windows has the same behaviour, i must confess.
but most apps I use day to day don't allow this ambivalent setting.

[elextr]

to use the menu option to close a window - this seems to be a bit over-complicated.

define a keybinding as I said.

As far as window size 0 or 1 or 2 etc Geany takes the approach for most things that if the user set it they meant to do it, and so it does what it is told and isn't too smart for its own good. Geany is an IDE after all, for programmers, who should be given at least a sliver of doubt that they intended it.

You will also notice that the message pane has no top bar, that would need to be added to put your button in, and an option to remove it for those who would prefer not to waste so much real estate for a button they don't use. But a well written pull request may be accepted.

[codebrainz]

It's fairly common to allow totally collapsing a paned/split view. GTK+ allows it by default (and so all GTK+ apps which haven't added special code to prevent it), and Qt even has friendlier behaviour where once you get close to fully collapsing it, it snaps shut, making it a little more obvious what the behaviour is. I don't think WinForms or Cocoa prevent users from fully collapsing split views either.

The only slightly odd/confusing part is that Geany doesn't re-expand it when it wants to show something in the collapsed side of the splitter, which for me is a plus, but probably not for everyone. I don't expect it would be highly controversial if someone wanted to make a patch to expand the message window when it needs attention (would be fairly easy to code), but then the question becomes how big to make it, since the previous size was zero, it would have to be some hardcoded size. It could use GEANY_MSGWIN_HEIGHT I suppose.

[hartmut27]

Thanks for your ideas.