ISSUE(s) & NOTE(s) -- WM-related, Resolution/Positioning/etc

This is a continuation of things mentioned in other posts previously, see issues: #13 & #14

The other issues seem to be mainly a problem because there is no real standard on Linux, how the WM should handle some situations. [...]

As I generally do CLI, it's not my field of expertise. But there IS A STANDARD, see EWMH-link below. Compiz and others should follow the standard - Compiz 0.8 was declared "completed" about 10 years ago and is in maintenance mode for kernel/X-updates and such. Anyhow, for what I know of the inner works, X-server is supposed to pass signals to the WM and applications seldom send the signals straight to the WM. There is a tool-set called "xdotool" which can be a great source for learning about passing signals to the WM's through X the "Linux way". I believe Wayland-server use same approach for WM's, handling the task of passing signals - but I hardly used Wayland personally as it doesn't offer as good driver-support for hardware yet. Project site: http://www.semicomplete.com/projects/xdotool Source: http://github.com/jordansissel/xdotool EWMH specification: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html

@ Multi-monitor setups: When you save positions, close application/windows - then disconnect/disable a monitor so it's no longer part of the full resolution - when you re-open the application (or window) with saved position it's out-of-bounds. Some form of cross-check resolution <--> position would be required to mend this. Esp. affected are laptop users who got a dock at home or office - but also flip-screen users as applications which save positions can be out-of-bounds as soon as the flip is performed (as flip causes changes in resolution, e.g. 1920x1200 <--> 1200x1920). Users who got multiple flippable monitors, or multiple monitors which are statically fixed in a mix of some horizontal and some vertical, can suffer from some parts of the full resolution being out-of-bounds.

Example: 1 vertical monitor (1920x1200) & 1 horizontal monitor (1200x1920) gives a total resolution of 3120x1920 where 720x1200 cannot be accessed. Those 720x1200 can be distributed across 1 or 2 rectangles of ?x1200 depending on alignment. Example above, if flippable, allow for any of following total resolutions: 3840x1200, 3120x1920, 2400x1920, 1920x2400, 1920x3120, 1200x3840 Also refer to the ASCII-example below.

Dual-/Tripple-monitor are the most common. Quad or more is rare as only more expensive, and CAD, GPU's support it - and in-expensive cards which are only for simple use like information displays like at some stores.

There can be further dis-alignment, causing additional rectangles which are out-of-bounds - but usually display-settings (regardless of OS) will attempt to minimize this in order for the cursor and applications to flow without unnecessary gaps. Ofcourse monitors can be overlapping, mirrored or used as duplicates... but those will still stay within bounds of above mentioned in this section. Personally I've used multi-monitor setup since late 90's... it has so many benefits I've grown to despise single-monitor setups. Remember I had Windows 98SE and an ATI Rage dual-head card with amazing 2MB dedicated VRAM. Gosh, these days it's an enthusiast card I guess?

To be honest, most offices I've seen in this country has multi-monitor setups for their employees due to the benefits. While rare for Mac/OSX (though mainly design offices uses Mac, thus I don't have much contact with those and may be mistaken), Windows and Linux workstations and laptop/dock-setups are very common with multi-monitor. Flip-capabilities is more or less standard on smaller laptops and full-system tablet/laptop-fusions. (Those which usually come pre-installed with either Ubuntu/GNOME3 or Windows 10. Andriod/iOS/Chromium/etc. are to be counted as limited systems.)

zKanji's primary target group is probably NOT at office, but well - some people use same laptop in private life as well or got their office at home and so on, hence mentioned.

If you use a VM like Oracle's VirtualBox, you can test out fake multi-monitor - although, depending on virtual OS you may have to shutdown the VM to change available "monitors" and KDE/Plasma require restart of SDDM to fully recognize all changes in monitor setup for some stupid reason (other DE's does not have this requirement). It's a matter of available RAM and VRAM too if you can do this or not. Maybe some some hardware may not support it, I believe..?

You probably guessed or already know - but here's an ASCII representation of gaps for illustrative purpose, based on two 90-degree flippable monitors where resolution X != Y:

              X
 ____________________________
|     W1xH1     |  |    V    |
| ------------- |  |    E    |
|               |W2|    R    |
|               |x |    T    |
|   HORIZONTAL  |Y |    I    |  Y
|               |  |    C    |
| ------------- |  |    A    |
|____ W1xH2_____|__|____L____|

X = The total combined X resolution.
Y = The total combined Y resolution.
W1 = Horizontal Screen X
H1 & H2 can have values down to 0, but sum of H1+H2 comply to:
H1+H2 = Vertical Screen Y - Horizontal Screen Y
W2 = Fake EMPTY space in-between monitors, this can have values down to 0 and up to the GPU's maximum allowed total resolution minus X.

Above ASCII only represents dual monitors located as LEFT & RIGHT while user may have TOP & BOTTOM or other settings with even more monitors. If all monitors are at same individual resolution and aligned in a row, there won't be no invisible space(s) like W1xH1. But regardless, the X and Y will still - even for a single monitor setup - represent the COMBINED RESOLUTION which should be available for disposal thus a basic guideline should be to enforce keeping application within these bounds. Would surprise me a lot if there's no available feature for requesting system resolution information.

Area W1xH1, W1xH2 and W2xY can be a pain identifying, so I say - don't bother. Let the WM handle those and if the WM can't then too bad, replace a WM which can or live with it. As for the W2xY, usually the DISPLAY MANAGER will try to keep such gaps non-existent - but they can occur on user request.

What's important is, at application START - and possibly RESTORE - make an addition like: (illustrative)

FUNCTION OUT_OF_BOUNDS(*) {
    IF (WINDOW_POSITION_X > X || WINDOW_POSITION_Y > Y) {
        WINDOW_POSITION_X=NONE ;
        WINDOW_POSITION_Y=NONE ;
    }
}
WINDOW_POSITION = EVAL OUT_OF_BOUNDS(WINDOW_POSITION) ;
SET WINDOW_POSITION ;

...in order to relocate window or set NONExNONE as WINDOW_POSITION. Most applications do something like this on STARTUP, some on RESTORE too.

I believe Compiz 0.8 is the one and only WM - counting Windows and other systems too - which actually is designed to help users counter these issues, but it can only handle like... TRUE STANDARD TYPE(s) of windows, e.g. not dialogs such as "Kanji Information Dialog"-widget etc. INVISIBLE space can actually be visually accessed too if desired, but space which is OUT_OF_BOUNDS cannot. (Using the custom script feature it's probably possible to extend to, theoretically, cover anything - but requires deeper user knowledge.)

To get ACTIVE_MONITOR, I believe you need to request POINTER_POSITION - or request ACTIVE_OUTPUT from WM. Normally, I believe, WM will handle this better per default if you do NOT send WINDOW_POSITION information. For sub-windows sending RELATIVE_POSITION.

Thank you for explaining about the monitors and resolutions. I hope I'm not annoying but I still have some questions.

When you turn off a monitor, does it show up in the available desktop space right away?
Let's say you told zkanji to save its original size and position. When you start it, should it go to the monitor with the mouse, the one with the current active window, or get restored on the original position? (Assuming it's turned on.)
Clicking the tray icon, should the program restore on the monitor where the icon was clicked? (Qt might do this already for me because I just tell it to restore the windows.)
Should flipping the monitor (thus changing resolution) force the program to move, if it ends up being outside of the current monitor? (I'm not sure if I can detect this with Qt.)

As I generally do CLI, it's not my field of expertise. But there IS A STANDARD, see EWMH-link below.

I phrased my original statement wrong about non-existing standards. Linux has a standard, but many sizing and positioning issues I have with Linux are due to the standard being badly specified. The Qt docs have many mentions of this (which is funny because Qt itself has gaping holes in its documentation and misbehaves a lot.) One example is: http://doc.qt.io/qt-5/application-windows.html#x11-peculiarities

It says:

[...] X11 is policy-free (others call it flexible). [...] Basic rule: There's always one user who uses a window manager that breaks your assumption, and who will complain to you. All Qt can do is to send certain hints to the window manager. The window manager, a separate process, may either obey, ignore or misunderstand them. Due to the partially unclear Inter-Client Communication Conventions Manual (ICCCM), window placement is handled quite differently in existing window managers. [...] X11 provides no standard or easy way to get the frame geometry once the window is decorated.

I could quote the whole text though. This is just one example, but throughout the development of zkanji I see these everywhere.

To get ACTIVE_MONITOR, I believe you need to ...

Qt can handle this I think. You can ask for available "screens" relative to position or window.

Switching a monitor OFF does NOT affect calculations as the cord is still connected - need to disconnect the cord if it's to re-calculate available space. KDE/Plasma has a bug/issue where it doesn't update resolution of screens which are (re-)attached during on-going session unless restarting SDDM, e.g. disconnecting a 1920x1080 monitor and attaching a 1280x800 will still make KDE/Plasma report 1920x1080 as available (and the other way around) - unless they fixed this very recently of-course. (Removing laptop from dock gives same behaviour as disconnecting a cord from GPU, some docks even got a different GPU which is much better than the built-in one.)
On saved size and position, only verify OUT_OF_BOUNDS and MAX_X & MAX_Y so it cannot exceed or get outside of current resolution in any way. Also see: @ RESTORE_WINDOW
Clicking icon at tray should have two options: --> Restore to SAVED_POSITION, or --> Restore to ACTIVE_MONITOR. Also see: @ RESTORE_WINDOW
Upon flipping and change in resolution, handle it upon RESTORE_WINDOW-action - unless, of-course, you can make a passive LISTENER. Also see: @ RESTORE_WINDOW

@ RESTORE_WINDOW _(Also @ CREATE_WINDOW.)_ SAVED_POSITION must perform the OUT_OF_BOUNDS-check, while ACTIVE_MONITOR attempts to restore position to the best extent possible. (See if position can be somewhat scaled/relative to SAVED upon this?) OUT_OF_BOUNDS-function attempts to keep X and Y, resetting only if OUT_OF_BOUNDS - optionally scaling X & Y. Scaling of X & Y would be a bit of extra work, but could be nice touch to stay as close as possible to original position.

Basicly, see what's within the scope of capabilities - then concider the time-effort delta. These things could be done way further down the road if too time consuming.

A v0.0.4-alpha-release should probably be concidered first as it currently is fairly stable and its been a long time since last one.

It's still not clear for me whether active monitor means the monitor with the mouse or the monitor showing the active window. Asking the WM would be an option of course but I rather not go for platform specific solutions. It would be a nightmare to maintain and I would have to write code each time a new platform is tested.

For now I'll just make sure nothing is out of bounds when shown first, and that tool windows like the kanji information and handwriting recognizer will be always shown relative to the main window. As for the popup dictionary and popup kanji search, I'll show them on the screen with the mouse.

It seems easy enough to detect resolution changes and when a screen is disconnected according to the Qt docs, but knowing Qt, it won't work adequately out of the box. I might try to do something with this too but I can't promise anything.

A v0.0.4-alpha-release should probably be concidered first as it currently is fairly stable and its been a long time since last one.

I would like the next release to fix most problems, and the current behavior with multiple monitors would appear as a bug for the users. It'll be just the fast solution I mentioned above, but please note if you find windows still not working comfortably after the release.

This issue is almost solved, at least on my virtual Linux with virtual displays, to be at least working more or less. There is one thing I don't know how should work though.

If you move windows that have free positioning, like the kanji information, I'll show them at the same position where they were hidden last, unless the monitor was disconnected. Some people might expect them to be moved to the monitor the main window currently is, others might like it the current way, because they have a dedicated monitor for such stuff. Do you think there might be a compromise in this regard or I must make an option for this in the settings?

Another question related to this is whether I should change the add-to-group dialogs' behavior. They are free positioning too, but this might be counter intuitive for dialogs like those. I need some input in this because I'm not accustomed to using multiple displays.

Sorry for the delay. Been changes in working conditions, will know more tomorrow (hopefully) how things turns out, schedules etc... Anyhow.

ACTIVE_MONITOR = Where the mouse is. (Or at least should be.)

Build (UTC): 2018-02-26 @ 11:04

Still enforcing RESTORE_FROM_TRAY to PRIMARY / LEFT_MOST monitor, instead of to ACTIVE_MONITOR (the monitor with the pointer). Opening a minor request in relation to this. Is this related to the "Window position and state -> Save and restore windows"? Setting it to "Don't save state" doesn't help and disabling it doesn't change whereto it restores, however - it does enforce default layout upon next start... Possible to make the "Save and restore tool windows" independent of "Save and restore windows"?

NOTE: PRIMARY isn't neccessarily specified as some use fused monitors, where X or Wayland will treat all as a single monitor. Windows has third-party tools which does this, such as you find among - for example - nVidia's bloatware.

Like, re-work it to: (Attempted to make an easy tree-structure.)

@ Settings -> Interface
| -->   Window position and state:                              <--  LABEL
|   | -->   Save and restore main window:  [COMBOBOX]   <--  NEW OPTION(s), EDIT TEXT
|   |   | -->   Save and restore state and position
|   |   | -->   Save and restore state only
|   |   | -->   Save and restore position only
|   |   | -->   Always start maximized
|   |   | -->   Always start minimized
|   |    `-->   Don't save state nor position
|   | -->   Multi-monitor mode             [CHECKBOX]   <--  NEW OPTION(s)
|   |    `-->   Prefer:                    [COMBOBOX]   <--  NEW OPTION(s)
|   |       | -->   System default behaviour
|   |       | -->   Active monitor
|   |        `-->   Last position
|    `-->   Save and restore tool windows  [CHECKBOX]   <--  MAKE INDEPENDENT
|       | -->   Save docked position       [CHECKBOX]   <--  NEW OPTION(s)
|       | -->   Save floating position     [CHECKBOX]   <--  NEW OPTION(s)
|        `-->   Restore to:                [COMBOBOX]   <--  NEW OPTION(s)
|           | -->   System default behaviour
|           | -->   Last position
|            `-->   Relative position
| -->   Save last kanji/radical filters and restore them on startup   [CHECKBOX]   <--  EDIT TEXT LATER.
 `-->   Minimize and close:                        [COMBOBOX]
    | -->   Quit on close, move to tray on minimize
     `-->   Move to tray on close, default minimize

Save and restore main window: DEFAULT: As is now. A few more options, and affects only the main window. (The current behaviour affects docked/floating as well which makes it quite annoying as disabling saving position kills all docked/floating as well.)

Multi-monitor mode: DEFAULT: DISABLED A checkbox which enables anything related to multi-monitor behaviour. If you planned the code you can place a single check which just SKIP these behaviours IF DISABLED. (Saving performance for all who doesn't use multi-monitor setups.) After, or below, there's a preference COMBOBOX to select desired behaviour. Like "Active monitor" prefer to place on monitor with pointer, while "Last position" prefer as close to last position as possible - just preventing OUT_OF_BOUNDS. System default means let system handle it, regardless if it can or not.

Save and restore tool windows: DEFAULT: As is now. This affects tool windows specifically, and isn't DISABLED the way it is as of current. It affects dialogs, sub-windows, docked windows etc. "Save position" being separate for docked and floating respectively, while "Restore to" COMBOBOX only affects floating type.

Save last kanji/radical filters and restore them on startup: Add radical here later, or for later, as similar filters will be present in the radical browser... Just need to find some spare time.

Opening a minor BUG/ISSUE for the filters.

If you move windows that have free positioning, like the kanji information, I'll show them at the same position where they were hidden last, unless the monitor was disconnected. Some people might expect them to be moved to the monitor the main window currently is, others might like it the current way, because they have a dedicated monitor for such stuff. Do you think there might be a compromise in this regard or I must make an option for this in the settings?

For a "professional" feel to it there should be an option, however - default should be favouring single-monitor users, e.g. the current behaviour. See "Multi-monitor mode" above and the settings proposal.

Another question related to this is whether I should change the add-to-group dialogs' behavior. They are free positioning too, but this might be counter intuitive for dialogs like those. I need some input in this because I'm not accustomed to using multiple displays.

I vote for applying the above suggested behaviour options to all sub-windows. See "Save and restore tool windows" above and the settings proposal. However, the group-dialogs are fetchable through WM-options - at least in Linux, and given the users know such exists - so it's not that big of a deal in my oppinion.

Something which feels a bit counter-intuitive, though - is the "Add to group..."-thingy. When you got a group-view already open and docked, zKanji will still open a NEW_WINDOW for this. I believe this is intended design, but - may I ask you to concider integrating the behaviour if view is already open?

Also opening a minor request for groups-view.

Nice work on the pop-up dictionaries, seems to work fine. Comfortably popping up as they should on ACTIVE_MONITOR.

I was writing tons here before accidentally closing the window... Trying again.

Your idea looks complete and customization friendly, but it also is very complex that would take a fair time to code. I would rather simplify what I currently have and not make it more complex. If there is an expected behavior in general for systems, I will rather do that and only give some options that make things acceptable.

You seem to define tool window as any window that's not the main window. For me, tool window is only the kanji information and handwriting recognizer. The windows you can dock with the search and group widgets are dock windows and should behave differently from the rest. Everything else are dialog windows, whether modal (blocking) or nonmodal (not blocking.) The popup dictionary and popup kanji search windows, or popup windows as a group are clear I guess.

Here is a fast summary of what I wrote before it got lost: dialog windows would always appear on active monitor, no exceptions. Their size could be saved, but I'm not sure about their position. Is screen center not the standard? Or is it above the active window? I prefer screen center myself, so I would go with that without providing an option for their position.

Dock windows when docked, are part of the main window. While floating, maybe it'd be best not to restore them at all, but in case they are actually restored, is there a standard for dock window placement? Maybe on same monitor as the main window even if they were moved? How do other programs handle this? I checked Inkscape which has almost no options for window positioning. It only allows saving the main document's "geometry" and that's it. Although Inkscape looks like a very low quality program on Windows.

I saw you had an option in some of the combo boxes for "system default behavior." Unfortunately we are working with Qt here, and it can mysteriously place windows in default positions, or just put them at the top left corner of the screen, and this behavior feels very random. Currently I have to move everything forcefully either to the center of the screen or to their saved position, so providing this option would be very buggy or take a long time to figure out.

You didn't list the "system default behavior" for the minimize combobox though. On Windows since 7, using the tray for programs is becoming less and less preferable, to the extent that I don't move anything to tray now, unless they are really nothing more just background processes. Likewise zkanji sits on the taskbar like any other program.

Still enforcing RESTORE_FROM_TRAY to PRIMARY / LEFT_MOST monitor, instead of to ACTIVE_MONITOR (the monitor with the pointer).

This worked well for me, I might have reintroduced the wrong behavior as a bug. I'll fix it if it shows up here.

The main window of the program should restore to the active screen from tray now. It's not perfect, because only the main window is moved, but it'll stay this way until we figure out how the other windows should behave.

Your idea looks complete and customization friendly, but it also is very complex that would take a fair time to code. I would rather simplify what I currently have and not make it more complex. If there is an expected behavior in general for systems, I will rather do that and only give some options that make things acceptable.

If a complete re-work will take a lot of time, it can be skipped or post-poned - no worries - but below mentioned minor change should (in my oppinion) still be done as it feels quite annoying as it is.

The main window of the program should restore to the active screen from tray now. It's not perfect, because only the main window is moved, but it'll stay this way until we figure out how the other windows should behave.

Tool windows which are docked should be saved at their docked position/size per default and restored along with the main window as a base feature. Or make a minor addition:

| -->   Window position and state:                              <--  LABEL
|   | -->   Save and restore windows:           [CHECKBOX]
|   |   | -->   Main window:                    [COMBOBOX]
|   |    `-->   Save and restore tool windows   [CHECKBOX]
|    `-->   Save docked windows:                [CHECKBOX]      <--  ADD THIS?
...

Do NOTE it's "docked" and not "dock", which refer to windows which has been docked in the main window - NOT the ones in floating state. It should be independent so that the user can choose to NOT save position of the main window.

[...] dialog windows would always appear on active monitor, no exceptions. Their size could be saved, but I'm not sure about their position. Is screen center not the standard? Or is it above the active window? I prefer screen center myself, so I would go with that without providing an option for their position.

Saving size but not position of dialog windows sounds like a good idea. While some user out there may get upset, it will ensure no user ends up with windows off-screen - which I believe should be priority. Centre of screen, or maybe even better - relative centre, e.g. at centre of the main window.

I saw you had an option in some of the combo boxes for "system default behavior." Unfortunately we are working with Qt here [...]

Usually the WM provide a setting which controls this behaviour when no detail is sent to WM overriding this. Windows (correct me if I'm misstaken) doesn't have a WM-settings thingy where users can control the behaviour (some shortcuts/visuals aside). While in Linux, advanced WM's like Compiz and KWin allow user to take control of placement priority in these cases - although, depending on distribution, these behaviours are not always set per default.

You didn't list the [...]

Well, I'm not perfect - and I believe noone is - but thanks for correcting me. And please do be critical to suggestions and such, usually the best results comes after discussing various points of view.

I will test things out during the weekend, hopefully already on Saturday. The changes in working hours may take a heavy toll on me though. Away from home up to like 12~13hours a day, and every second week (ISO-week odd numbers) will have short weekend and many late hours from now on.

If a complete re-work will take a lot of time, it can be skipped or post-poned - no worries - but below mentioned minor change should (in my oppinion) still be done as it feels quite annoying as it is.

What behavior would you personally need to make it not annoying? I think deciding this should be a first step before changing anything. I would rather make things work first, and if someone requests something new then decide whether to add it as an option or not.

Tool windows which are docked should be saved at their docked position/size per default and restored along with the main window as a base feature.

This is the current behavior, unless you uncheck saving position and state. Maybe I shouldn't even give the user the option to be able to not save this? Although it's extra work to remove it now.

I insist on not calling them tool windows, because tool window is a standard term for windows that float above the main window that either contain tools that influence the main window or give information. On the other hand the dockable windows can do everything you can do on the main window too. They are just a side-effect of the design, to allow docking parts of the interface on the main window any way you like. If it was up to me, they would have been equal windows to the main window, but neither Windows nor KDE is happy with that. They need one main window that's the parent of everything else.

Windows (correct me if I'm misstaken) doesn't have a WM-settings thingy where users can control the behaviour (some shortcuts/visuals aside).

You are mostly correct. Windows doesn't have settings for default window positioning, but it does have default position for new windows. It places each new window a bit down and to the right relative to the previous, then starts over when this reaches the edge of the screen. It completely lacks standards for dialog windows though, apart from guidelines on the MS developer sites. What is worse, it is inconsistent itself. The default open/save file dialogs on my system remember their last size and position, but it wasn't like this in all previous versions of the OS, and I haven't tested with all possible dialogs the OS provides.

It's Linux (or rather KDE) that forces me to place all windows at a predefined position, because it always placed some windows at the top left corner of the main screen, while it worked well with others. It's a mistake on my part for sure, but I couldn't figure it out, that's why I went with what we have right now. I'm still pointing fingers at Qt because the documentation is missing important information, and Qt function calls always have unforeseeable consequences. I imagine it saying: "You want to know the exact size of the window before it opens? Too bad, I will give you the wrong information AND break the future behavior of this." The reason I just want it to work in an acceptable way and be done with it is my annoyance with Qt to be honest, but I should stop ranting now.

Build (UTC): 2018-03-03 @ 10:59

Almost all good now, it's just the startup which cannot be controlled to appear on ACTIVE_MONITOR - even when "Save and restore windows" is unchecked... while unchecked, DOCKED_DIALOGUE go poof which is annoying.

What behavior would you personally need to make it not annoying? I think deciding this should be a first step before changing anything.

Either making already DOCKED_DIALOGUE stay per DEFAULT, or adding an option to save only DOCKED_DIALOGUE. Currently one need to save POSITION as well - OR the DOCKED_DIALOGUE go poof - which isn't desired behaviour for, I believe, anyone who use multi-monitor setup. If making DOCKED_DIALOGUE go poof is desired on startup, a RESTORE_DEFAULTS flag could be available - or a button/menu-option to restore default interface.

If having it as option, it's preferred to be independent of the SAVE_POSITION & SAVE_STATE - as many will not want to save these. Or, optionally - in the current COMBOBOX, add an option like "Only save docked windows" for those who doesn't want POSITION nor STATE to be saved thus allowing the choice to uncheck the whole thing having it startup as "new" every time. (Which may be desired if used on a portable memory stick, never knowing the resolution nor amount of screens available on the next device?)

Single-monitor users will probably not mind either way as it doesn't really affect them much, where as the multi-monitor users will almost allways prefer if applications ends up on the ACTIVE_MONITOR, e.g. the screen with the cursor. Upon RESTORE_FROM_TRAY, it works this way already - restoring to ACTIVE_MONITOR - it's just application startup which is being a bother.

It's Linux (or rather KDE) that forces me to place all windows at a predefined position, because it always placed some windows at the top left corner of the main screen, while it worked well with others. It's a mistake on my part for sure, but I couldn't figure it out, that's why I went with what we have right now.

Usually, the DEFAULT in Linux WM's for window placement is often so-called "smart placement" - it aim's to cover as little as possible of other open windows, if no windows are open it attempts to make the best of available space (what that means differ between WM's). Any sophisticated WM's offer options such as "prefer corners", "prefer centre", "tile" etc. "Smart" also attempts to prefer ACTIVE_MONITOR, e.g. the one with the cursor. And, of-course, there are exceptions as Linux allow the freedom to. But as a rule of thumb, it goes like this.

I'm trying to advance in this issue for days but I'm currently stuck. I found no way in Qt to get the program start on the "active monitor." I could make the program appear on the monitor with the mouse cursor on, but the active monitor depends on WM settings and there is no way of getting the correct one with Qt. I'm on the verge of giving up and just make the window always start on the first monitor, unless you change the settings to always start at the position the program was closed on.

After a very long struggle with this I decided to completely redo the program logic. No other programs I checked give the user any kind of customization regarding starting positions, so zkanji should still be more customizable.

I plan the following:

The visible dockable windows will always be saved and shown, just like the docked widgets on the main window.
The size of all windows will always be saved and restored if possible.
The kanji information window will not be shown on startup, nor any other window.
There will be one checkbox to remember last window positions. If not checked, I'll not touch the position of the windows on startup. I hope this will do the right thing on most systems, but it's greatly dependent on Qt. When checked, the main window and docked windows will show up exactly where they were last shown (unless they fall outside every monitor.)
If a window would be outside of monitors, I'll ignore its saved position and let the system do its thing.
The handwriting recognizer window is an exception. It will have its own checkbox, because some users wanted it to always show up at the old position.
I'm torn on this, but for now the kanji information window will not save its position at all. When closed, the next time it might show up at an entirely different place.
Most dialog windows will stay non-modal like now, but I won't force their position, only their size. This is important because this way you can do stuff by drag-dropping if needed.

The so-called "smart" placement on KDE and other WMs is slightly bothering me because they tend to show stuff at window corners, which feels very awkward to me. This is what must have caused many of my dialog windows to show up in the corner on KDE after all. The WM might handle any non-modal window as a generic window and screw things up. If this feels wrong to you, I might add an option, or rather force these windows to always be shown at the middle of their parent, but I won't be doing it for now.

I'll start these changes right away, but if there was any existing logic that would be erased, I'll try to keep them only commented out in the code.

EDIT: I forgot to mention, but the option to keep the minimized/maximized state of the main window will stay as is. In case someone doesn't check the save window positions option, this option will be disabled for now.

Small update to previous comment: If I go with the default Qt behavior on Windows, the kanji information window (and generally all child windows) would appear at the middle of the main window every time, which is annoying. I added an option to keep the system default (on KDE this means random positions,) or save the last position and show it there always (this only fails if the monitor it was on previously is disconnected. In that case the default position is used,) or show the window near the cursor. Since KDE, and possibly other WMs, behave too randomly for me when it comes to showing windows above the main window (sometimes centered, sometimes seemingly random, sometimes screen corner - that's "smart" positioning,) I'm thinking of forcing them at some position like window center or monitor center, but for now I'll just go with system default and see how Qt handles this for non-modal dialog windows.

Latest update should fix most issues, forcing all dialog windows to appear right in the middle of their parent window. I hope this gets rid of this issue for good. I'll close this in a few days. In case there are problems with specific things related to window positioning, please open an issue for each of them separately.

It's been a lot more than a few days, so I'm closing this issue. Please tell me in case it's not fixed or there are other issues.

z1dev / zkanji

ISSUE(s) & NOTE(s) -- WM-related, Resolution/Positioning/etc #15