2337 allow resize the drop down terminal

[anhtumai]

Please follow these steps before submitting a new Pull Request to Guake:

• rebase on latest HEAD:

  $ git pull --rebase upstream master

• hack your change

• to execute the code styling, checks and unit tests:

  $ make style check reno-lint test

• describe your change in a slug file for automatic release note
  generation, using:

  $ make reno SLUG=<short_name_of_my_feature>

  and edit the created file in releasenotes/notes/.
  You can see how reno works using pipenv run reno --help.

  Please use a generic slug (eg, for translation update,
  use translation, for bugfix use bugfix,...)

• create new commit message

  $ <hack the code>
  $ git commit --all

• If your change is related to a GitHub issue, you can add a reference
  using #123 where 123 is the ID of the issue.
  You can use closes #123 to have GitHub automatically close the issue
  when your contribution get merged

• Semantic commit is supported (and recommended). Add one of the following
  line in your commit messages:

  # For a bug fix, uses:
  sem-ver: bugfix
  
  # For a new feature, uses:
  sem-ver: feature
  
  # Please do not use the 'breaking change' syntax (`sem-ver: api-break`),
  # it is reserved for really big reworks
  

[anhtumai]

Allow resizing the drop-down terminal by dragging its bottom edge

closes #2337

Summary

Similar to Windows Terminal, this lets you resize Guake's drop-down window by dragging its bottom edge — handy for temporarily expanding the terminal to read long command output without leaving the drop-down view.

• Enable decorated on the main window (guake.glade) so the window manager provides a native border, which makes it grabbable/draggable on the bottom edge.

• Debounce configure-event on the main window (300ms) to detect when a drag-resize has settled, and record the resulting height/width as percentages of the monitor workarea (Guake.on_window_configure / on_resize_debounced in guake_app.py).

• Store that as an in-memory SettingsOverride (guake/utils.py) that RectCalculator.set_final_window_rect prefers over the persisted window-height/window-width gsettings values, without writing them back to gsettings — so the size holds for the rest of the session (surviving hide/show via F12) without permanently changing your configured default.

• If you explicitly change height/width/alignment via Preferences, accel_increase_height/decrease_height, or dconf, the override is dropped (GSettingHandler.size_changed/alignment_changed in gsettings.py) so the persisted setting takes priority again, as expected.

Notes

• The Fluxbox show() workaround previously re-triggered the window-height changed signal to force a re-apply; that would now also clear the override, so it was changed to call RectCalculator.set_final_window_rect directly instead, preserving the original Fluxbox fix without disturbing the in-session override.

• Also bumped the black/flake8/pylint pre-commit hook revisions, which were badly out of date and crashing under modern Python (old black referenced ast.Str, removed in Python 3.12+).

Testing

• make style check test
• Manually: drag the bottom edge to resize, hide/show (F12) and confirm the size sticks; then change the height via Preferences and confirm that takes over cleanly.

[anhtumai]

Demo of my PR:

Screencast.From.2026-08-03.17-31-56.mp4

[Davidy22]

I notice from both my testing and your video that this change introduces an unnecessary titlebar. That's going to have to get cleaned up before I merge this.

[anhtumai]

Thank you for your respone. I will look at it tonight or this weekend

[anhtumai]

@Davidy22 I have fixed the code.
Here is the new demo , when I have removed the title bar. You can check in guake.glade that the code is same as before, except for glade version changed

Screencast.From.2026-08-15.20-49-42.mp4

[anhtumai]

About the title bar, actually I prefer to keep it, because it has options to: Move to monitor (Up/Down/Left/Right). So we can move the Guake terminal to other places, not stuck in one place. What do you think about this @Davidy22 ?

If you agree, I will keep the titlebar, since it improves user experience a lot

Another solution is to make another issue to fix: Move Guake terminal to wherever cursor last clicks, but it will be much harder to do than just enabling the titlebar by setting: decorated=True

[anhtumai]

About the title bar, actually I prefer to keep it, because it has options to: Move to monitor (Up/Down/Left/Right). So we can move the Guake terminal to other places, not stuck in one place. What do you think about this @Davidy22 ?

If you agree, I will keep the titlebar, since it improves user experience a lot

Another solution is to make another issue to fix: Move Guake terminal to wherever cursor last clicks, but it will be much harder to do than just enabling the titlebar by setting: decorated=True

@Davidy22 sorry for direct ping. But can you give your feedback here?

[Davidy22]

Adding a title bar changes the program quite substantially, is out of scope for this PR, and jars with how it's supposed to be a panel that pulls down from the top.

Flagged things I noticed, also the temporary override mechanism's a point of discussion. Size changes not being reflected in the preferences menu is going to be a bit unintuitive. Also need to consider what merits usage of the temporary settings, why would dragging the window edge count for a temporary change, but CTRL+up/down doesn't?

I would lean heavy towards cutting the temporary settings mechanism and just having the window edge dragging alter the general window size setting. If you want to make a case for doing it this way, at the very least the window size keyboard shortcuts fulfil a very similar role to this and should also use the same mechanism.

[Davidy22]

Don't put issue numbers in comments, just describe what the code does.

[Davidy22]

Similar deal

[Davidy22]

This is a convention change to go with the glade version bump I presume?

[Davidy22]

Don't change our linter versions. Out of scope, do this in another PR.

[anhtumai]

Adding a title bar changes the program quite substantially, is out of scope for this PR, and jars with how it's supposed to be a panel that pulls down from the top.

Flagged things I noticed, also the temporary override mechanism's a point of discussion. Size changes not being reflected in the preferences menu is going to be a bit unintuitive. Also need to consider what merits usage of the temporary settings, why would dragging the window edge count for a temporary change, but CTRL+up/down doesn't?

I would lean heavy towards cutting the temporary settings mechanism and just having the window edge dragging alter the general window size setting. If you want to make a case for doing it this way, at the very least the window size keyboard shortcuts fulfil a very similar role to this and should also use the same mechanism.

Thank you . I will modify the logic to align with existing implementation