An option to allow for negative window coordinates
Subtitle Editor derived from 6.0c, but with VLC and Hunspell checker
Brought to you by:
kameleon
Menu
▾
▴
1 Attachments
#18 An option to allow for negative window coordinates
From the attachment, you can see my usual workspace. Notice the lack of the window header (or whatever that is called in English).
In the past version (from 2019) this location is saved and restored upon relaunching the application.Thus the application appears not to have a window header each time when launched.
The current version stores it as well (I think, as I don't have it stored, as recently I have tested another bug (the one with the keyboard layout switching nightmare) and I didn't bother to "remove" the header by moving it offscreen), but makes it a zero when launching the window if it is negative.
Due to the nonideal ergonomy of the current application (which shall hopefully be sorted out a bit after the next version launches... the one that enables resizing the editing textbox, etc.) I need as much space as possible, but manually moving the window header offscreen each time I launch the application is quite a bother. :P
I do understand why this change was made in the first place - to disallow for badly defined situations, like the window header being entirely offscreen and thus unavailable at all. But from the many years of me using this software, I never had issue with the old behaviour - and thus I would like a choice.
Preferred solution: a checkbox in the settings called "allow loading windows into negative stored coordinates", which would be unticked by default. If an user ticks that, he should be skilled enough to zero out the coordinates in case of something going wrong (the only other option for the user to tick that would be that is going through the settings ticking stuff randomly, which we cannot account for, nor should we).
Bad solution: Another solution would be to allow the minus coordinates to go upwards for the height of the window header minus 1 pixel, but that solution would be deeply flawed - Windows is notorious for having different window header heights each version (further affected by gui used (WinForms versus WPF, etc.), by themes and such,...) AND not always reporting the window header height correctly. So that is a solution that should be avoided.
I just checked and couldn't find an option to remove window decorations / the window header. If that option was available, it would render my workaround irrelevant. Of course, it might not be possible, as I know nothing about Delphi-based apps.
I propose a third solution: give the user the possibility to change the vertical position beyond the top of the screen with the mouse wheel while pressing shift and escape simultanously.
I would not choose for an extra checkbox anyway: the user interface is already complex enough (not even mentioning the translations that will be needed).
If you agree it will be implemented in v6.2.6.
What?
I can put the header above the screen boundaries already. (unless you have a staging build that modified that)
That is not the problem. I sense a misunderstanding here.
My problem is that it isn't LOADED (I think it gets stored) and the header won't be where it was on load.
Last edit: Templayer 2023-10-26
How can you do that? Putting the header above the screen top? I tought that windows did not allow that.
Anyway: negative values will be loaded back and used as such.
By disabling Snap.
I hate snapping to screen borders.
Being able to push individual windows out of the way by putting them to the side or downwards, or gaining additional workspace by "removing" the window header by moving it upwards is quite a boon to that.
And, of course, there is still the matter of me using Win7.
I'm in control of my computer. Not microsoft. I can do whatever the fuck I want. :P
Linux Mint with Cinnamon is much better for that, though.
Yeah, I remember seeing negative values in the configuration file. They are currently being zeroed, I assume. It will be nice not having to move that header each time I launch the application, as it is a little bit time-consuming and bothersome. :)
Tried the first build-labelled version (6.2.6_100) and maybe it doesn't have that implemented - after reopening the app, the negative coordinate is not restored. Which means I cannot store the window header being outside of the window (with the exception of its one pixel so I can drag it back to boundaries if needed).
Single-monitor setup.
Indeed Testversion 100 does not have that feature yet. I will post an upated version tomorrow.
Last edit: Kameleon_ 2023-10-29
👍
Here is the version that should be OK.
Also this has been built in as a test (only for the main window tough for the moment):
Last edit: Kameleon_ 2023-10-29
I tested putting the header out of screen boundaries and now I am able to launch the application without a window header.
Yaay!
Haven't tested the shift+esc feature, as I do not need that. :P
Perhaps other users could need it (the ones with snapping to screen border set to on)?
They might. I don't. :p
Worst case scenario somebody will make you a ticket if that breaks... at least you will know somebody is actively trying to use your new short-cut feature. :^)
Well, it is only in the test version now. I can keep it out for the new release.
I decided to implement your "preferred" solution anyway in the final v6.2.6.
That would be prudent.
My line of thinking was: "but if somebody wanted it to work as it did..."
Then that would be an impasse.
And let's not do it like Microsoft does, i.e. forcing their stuff and not giving people options.
Your setting is nowhere as big to be considered too big. I use PotPlayer because it has numerous settings - try looking at the settings there to have an idea of how much is a lot of settings. And yet, I still like that (personally). But that amount might be too much for some people. :P