z1dev / zkanji

Japanese language study suite and dictionary
GNU General Public License v3.0
61 stars 10 forks source link

BUG -- Minimize to tray: Does not properly restore #13

Open am2del opened 6 years ago

am2del commented 6 years ago

As known, no icon showing when minimizing to tray - but, upon clicking this no-icon no-description empty slot, it dissapears and is NOT restored. However, neither does it crash. It's still possible to bring it back up, but it's at the same time not present in an active-window list. It's sort-of restored to a "minimized-yet-semi-invisible"-mode instead of "restore window"-mode. Also, if trying to launch zkanji while still minimized at tray, it refuses to launch - would it be possible to trigger "restore window"-action instead of refusing completely upon this event?

Solution proposal: Currently none.

am2del commented 6 years ago

Need to add to this that "shade"-action also triggers "minimize-to-tray"-action, which it should NOT. If your distribution did not place button for "shade" per default, you can add it in WM-settings in order to test.

z1dev commented 6 years ago

I have added an image for the icon and also changed the order of some calls when restoring the program from the tray. I don't think it'll have any effect though. What does 'minimized-yet-semi-invisible" mean when you click on this icon?

am2del commented 6 years ago

Build (UTC): 2018-01-15 @ 15:06

I can confirm there is a visible icon now.

The fix you applied did make things better - now it restores (see notes) to minimized-state when clicking the tray. While the desired result would be restored as un-minimized. However, is still triggering "minimize-to-tray" - but in a way which causes graphical glitches, leaving part of the window drawn on screen. So in this aspect it's worse than before the fix.

Before the fix, clicking either "minimize" or "shade" (see descriptions) would trigger the "minimize-to-tray" without graphical glitches, and - after clicking the non-icon in the tray - it didn't reappear in the activity field (the field to which applications normally go when minimized). While in this state, using the launcher would result in failing to start as it's allready running. Bringing it back up required a work-around, hence calling it "semi" - as it's was actually there, but at the same time invisible to the user.

Descriptions: @ Shade: Sort-of roll up the window to the extent where only the frame is shown while all content is hidden. It's a feature for saving space on screen, and most practical when combined with "Force Above", "Force Below" & "Sticky". A great feature for those who has a lot of things up at once, i.e. reference documents etc. Although this feature is available in just about any WM (with possible exception for Gnome3 environment), it's not allways activated by factory default. In either case, it can be enabled/disabled in the WM-settings. @ Minimize: Same on all graphical systems I believe - hides application and it's frame at the activity bar.

Notes: It now restores, but - with a few seconds delay. By "a few seconds", I refer to up to roughly 3 seconds - on a quad-core @ 4.4GHz per core. The DE and system in general is optimized for speed/responsiveness.

z1dev commented 6 years ago

I have made changes to how the windows are restored again, but this kind of patching isn't a great way to fix things. It would be best if you could debug the program and see what's happening.

Restoring zkanji when it is started a second time is the planned behavior. The previous versions did that, but those were Windows only. I'll need to figure out how to communicate between programs with Qt, to make this cross platform.

I'll check what to do with the shade button. I have no experience using it even on Linux.

am2del commented 6 years ago

I'll take a look at this after the radical data & SVG's.

am2del commented 6 years ago

I got a few behaviour-questions in regards to this "Minimize to tray" feature in-before I run debugging and start messing with things.

As for SHADE, I forgot to mentionen that SHADE bahaves the way it should until "Minimize to tray" is ENABLED. Once ENABLED, it miss-behaves.

Also, is it design that the CLOSE-button calls EXIT even when "Minimize to tray" is ENABLED?

In my experience, on Linux when "Minimize to tray" is ENABLED: --> CLOSE-button usually behaves as close-to-tray, --> MINIMIZE-button still minimize normally, --> SHADE-button still shade normally, --> Menu:File -> QUIT will call EXIT the normal way, --> Tray icon is shown as long as the application is running as long as "Minimize to tray" stays ENABLED, --> Finally, clicking the ICON @ tray usually minimize/restore application.

I got surprised the bahavour of CLOSE-button didn't change with this setting. Back in the days, while i still used Windows (up to XP SP1) - I recall applications behaving as described above, with exception for SHADE which never existed in Windows.

Reference cross-platform applications today with "minimize to tray" which do behave as described: Clementine, Deluge, VLC etc.

z1dev commented 6 years ago

The shade should do what it was made for, to follow the system standards. Unfortunately Qt doesn't seem to support it. It allows controlling whether the shade button appears, but I can't differentiate between minimize and shade. When I get notified that some state changed happened to the window, it always gives me WindowMinimized on shade too. There might be ways around this, but searches online didn't give me anything.

"Minimize to Tray" wasn't a standard way to hide windows in the early-middle days of the tray on Windows and I had many programs that do exactly what zkanji does. (Like winamp for example. Too bad that one died.) If a program minimizes to the tray when I close it, I'll kill it with fire, because personally I hate that behavior. This makes closing programs much more complicated than this simple act should be. It could be an option in the settings though, or make it the default on Linux maybe, which would also "fix" the shade problem.

am2del commented 6 years ago

It could be an option in the settings though, or make it the default on Linux maybe, which would also "fix" the shade problem.

I think it should be default behaviour on Linux due to SHADE, however - please do make it a setting if it's not too much work. In the feature, parhaps having a contex-menu @ tray for easy access to EXIT without the need of un-minimize first. Could also put those small search-things in that menu - in case user don't want to use, or simply forget, hotkeys.

z1dev commented 6 years ago

The original program should now restore from tray when you try to start it a second time. Linux seems to refuse to activate a window if it's already shown, but (at least in KDE) it now flashes the taskbar button if you start it separately again.

I will try to add the "fix" for the shade now. Is restoring from the tray with mouse click still doesn't work correctly? It seems "floating" the popup dictionary will make it simply disappear which must be fixed too.

am2del commented 6 years ago

The only issue with KWin, which I am aware of, is with a SHADED application - it will restore/re-activate it as SHADED, and UNSHADE must be done manually.

The original program should now restore from tray when you try to start it a second time. Linux seems to refuse to activate a window if it's already shown, but (at least in KDE) it now flashes the taskbar button if you start it separately again.

Build (UTC): 2018-02-02 18:22 It restores to MINIMIZED when started a second time, same when clicking icon in tray. Isn't it possible to send a RESTORE to WM upon this action? The previous DELAY-issue is well... it's not perfect, it's 1~2sec. At least better than earlier. Is it reasonable to make the icon at tray permanent while "minimize to tray" is enabled, never allowing to enter standard MINIMIZED state? Probably easier for users who use this feature to keep track of the application.

It seems "floating" the popup dictionary will make it simply disappear which must be fixed too.

Okay, now I'm gonna be annoying - please forgive me. And I know I - and some acquaintices - belong to a rare category in this aspect, but I'd still like to enlighten you on this. Please bear with me.

I noted this too, the popup can be moved, but only using special WM-shortcut which allows moving windows without frame/decorations - and this popup will allways end up on DEFAULT PRIMARY MONITOR. As a multi-screen user - with all 90-degree flippable monitors (usually with some as horizontal and some as vertical) - I really do not like this behaviour at all. It should follow WM-rules and end up on the monitor with the pointer (active monitor). Starting zKanji makes it restore to last position, even when Settings -> Interface -> Window position and state -> Main window is set to Don't save position. This type of behaviour is extra annoying when having some monitors switched OFF and/or after FLIPPING them - needing to turn ON monitor(s) which are OFF and/or flip back (multi-)monitors to grab and move zKanji to a position which is within bounds of the "new" resolution. The "Kanji Information Dialog" got the same issue in this aspect, the positioning should be remembered as relative to the main window and never allow position out-of-bounds. Flipping screens changes DE-resolution, however - a connected monitor which is OFF does not. This behaviour is also annoying for those who got laptop and "extra"-monitor only when docked. As long as WM is allowed full control, multiple flippable screens - nor different screen settings for docked laptops - has never been an issue. Not sure about all WM's, but god bless Compiz 0.8 which features a "move window to..."-option which includes 9 screen positions at each monitor, 9 positions at full DE-resolution as well as straight to POINTER-position (the 9 positions are like what you're used to upon moving a window to a screen edge/corner + full screen, but this work for both individual as well as cross multi-monitor) - the one detail is that this doesn't affect the type which "Kanji Information Dialog" is of, thus only affect windows like: View -> New Window KWin and some others offers a context menu option called "Move" (at the active applications bar) which at least allows bringing applications back from non-existant areas as built-in work-around for these issues. But just like Compiz - the type which "Kanji Information Dialog" is of is unaffected by this feature. I also want to point out that if unchecking Save and restore windows, it won't restore tool-windows... which is a reason "Don't save position"-option should be functional.

Question: Is any of this (or things in #14) - in any way - related to the"Hide popup when-option @ Settings -> Interface -> Popup windows.

Also, keep this in mind and see last section(s) of todays post @ #14 - it relates to this.

z1dev commented 6 years ago

The only issue with KWin, which I am aware of, is with a SHADED application - it will restore/re-activate it as SHADED, and UNSHADE must be done manually.

Qt misses the functionality to do anything with shaded windows whatsoever. I would have to use Linux specific commands, but I'm not an expert on Linux GUI development, so I'll need help with this.

It restores to MINIMIZED when started a second time, same when clicking icon in tray. Isn't it possible to send a RESTORE to WM upon this action?

It's what I tell it to do and it works fine on KDE for me. And also...

The previous DELAY-issue is well... it's not perfect, it's 1~2sec. At least better than earlier.

This looks like an issue with Qt and/or the WM. (i.e. message from Qt is sent to WM that ignores it for seconds because it should be notified differently)

Is it reasonable to make the icon at tray permanent while "minimize to tray" is enabled, never allowing to enter standard MINIMIZED state?

I will look into it, but it might break the current functionality by having a permanent icon, so this can have some negative consequences. Skipping the state of being minimized is what is supposed to happen already. Maybe your WM doesn't allow this to happen?

[...] this popup will allways end up on DEFAULT PRIMARY MONITOR. [...] It should follow WM-rules and end up on the monitor with the pointer (active monitor).

I have no experience with multiple monitors. I welcome any clues on how it should work.

This type of behaviour is extra annoying when [...]

While I do understand your frustration, you also have to understand that zkanji is in mid-development, so most of the issues with it are due to it being an unfinished program. All the colorization issues, bad font sizes, some functionality being broken or settings not doing what they are supposed to is due to this. When you arrived I was about to start going over everything, fixing such bugs and making an initial release on Windows (because I did almost all my development there.)

Is any of this (or things in #14) - in any way - related to the"Hide popup when-option @ Settings -> Interface -> Popup windows.

I doubt it, but zkanji is complex enough now that things can break each other even if they seem unrelated. For now the answer is still "no" though.

z1dev commented 6 years ago

By the way could you please open new issues when they come up and not write everything here? Even if it's easier and faster to mention them all at once, having to scan through every existing open issue all the time is time consuming.

z1dev commented 6 years ago

Starting zKanji makes it restore to last position, even when Settings -> Interface -> Window position and state -> Main window is set to Don't save position.

I was going to see what's wrong with this, but it seems to me it's just a misleading phrasing of the option. The main window position refers to whether it's minimized or maximized on startup, nothing more. If you need the option to stop moving the main window to the monitor it was on before, uncheck the Save and restore windows box. This will prevent saving window sizes and positions altogether.

After reading your description my understanding is that windows should save their sizes and positions, but restore them always on the monitor with the mouse, relative to each other. In that case you might need entirely different options for this. Do you have any hints what is it you need?

Rotating/flipping your monitors that thus change resolution is a rather rare use case. Please explain how other apps behave so zkanji can do something similar.

am2del commented 6 years ago

Maybe your WM doesn't allow this to happen?

Given it happens with three of the most commonly used WM's, I suppose it's not a WM issue. It also occurred in pure KDE/Plasma... Would also like to add that the BUILD from which a screenshot was posted some days ago (the KDE-screenshot), the user sent me another screenshot where it shows that NO ICON is shown while minimized to tray. As I don't got physical access to the computer more than once in a while when it's brought here it's a little tricky to check, and VNC and such got limitations. On my setup icon is shown as it should with builds made before and after the KDE one... so may be a build-issue. I will update you on this when I can. I attach the screenshot. screenshot_20180204_003146 Build (UTC): 2018-02-01 @ 20:31 Screenshot is taken a few days later.

@ Resolution/positioning/WM I will open a new thread and reference to this thread.

am2del commented 6 years ago

[...] most of the issues with it are due to it being an unfinished program [...]

First off, in-before anything:

You're doing a great job - hats off for you!

I don't bring things up as negative criticism - I have absolutely no ill intentions - but in order to enlighten you in regards to various aspects worth a thought, and things which are good if kept in mind during further development. Whatever suggestions, request or work I help with - I will leave final decision to you. Also, I'm not expecting "finished"-state of any sort for an ALPHA. (Seriously, what ALPHA is NOT buggy and NOT subject for being re-written?)

Although I've been aware all this time, since it's stated in the README, I'm actually impressed to the point where it's hard to believe you're just a single programmer doing this.

I wish I could spend a lot more time helping you, but unfortunately I can only offer what time I can spare. To the extent possible - and within the limitations of my capabilities - I offer to lend a hand. As you probably noticed, things I do may take a while to complete due to lack of time to spare and my level of thoroughness... Anyhow, I am a self-taught programmer/tech - without any official degree what-so-ever. Primarily CLI-oriented in terms of programming, however - fairly accustomed to large-scale information handling and parsing. I had a few jobs within the IT-field, but gotten those through proving myself on-site... which is very tough given how many got a degree these days. Native English-speaker is something they desire in non-English countries though. Another thing I can do is discuss with people whom I have recommended zKanji to and gather some user-feedback, although from a very limited user base - it may be useful.

z1dev commented 6 years ago

Maybe your WM doesn't allow this to happen?

Given it happens with three of the most commonly used WM's, I suppose it's not a WM issue.

If you know Qt programs minimizing to tray correctly which are open source, I could check what they do. I thought of this before, but after reading your WM-related positioning issue post, I'm sure that the only way I could safely make zkanji behave well on all those WMs you and the others tried would be to do extensive testing on them myself, and that's not going to happen any time soon because of time issues.

[...] another screenshot where it shows that NO ICON is shown

I have zero influence over this, I just tell Qt what to do. Few reasons I can think of:

I don't bring things up as negative criticism - I have absolutely no ill intentions - but in order to enlighten you in regards to various aspects worth a thought, and things which are good if kept in mind during further development.

I reacted that way because you showed clear frustration over the multiple monitor behavior. I have frustrating experience with many programs as well so I understand this. I didn't mean to sound defensive, nor blame you for anything. You help a great deal letting me know of all these issues, because otherwise I'd be in the dark and would probably never find out about them.

am2del commented 6 years ago

@ No ICON shown at tray: I suspect currupt build being the fault as this wasn't the only suspicious issue - there were several other things I became aware of this past week. Missing packages or currupt source at build-time, can't tell at the moment. Gonna perform some testing as soon as I get my hands on that laptop.

I reacted that way because you showed clear frustration over the multiple monitor behavior. I have frustrating experience with many programs as well so I understand this. I didn't mean to sound defensive, nor blame you for anything. You help a great deal letting me know of all these issues, because otherwise I'd be in the dark and would probably never find out about them.

I should probably point out the use of CAPITAL-letters is to emphase important key(s) in the text for ease of detection when wanting to find something on-the-fly, they are not used for any form of aggression - just a bad habit of mine from too much CLI...

z1dev commented 6 years ago

How is the state of this issue currently? Does the program restore or are there still visual bugs?