Summary: | Some KXMLGui-using apps are opening maximized instead of windowed | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kconfig | Reporter: | agentxlax <agentxlax0> |
Component: | general | Assignee: | Matthew Dawson <matthew> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 0xCAP, bugseforuns, claudius.ellsel, doug, i, kdelibs-bugs, kfm-devel, nate, till2.schaefer |
Priority: | VHI | ||
Version: | 5.74.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=430521 | ||
Latest Commit: | https://invent.kde.org/frameworks/kconfig/commit/a62e53e1b1fdb363fefb74907dca339b238e99b9 | Version Fixed In: | 5.78 |
Sentry Crash Report: |
Description
agentxlax
2020-09-21 14:06:48 UTC
It is possible that a window rule has been set which forces these windows to be maximized? You can check in System Settings > Window Management > Window Rules. I've already looked in there my self and the person on the EOS forums already checked for Konsole on this machine. Thanks for the info. Am I clear that you are reporting this on behalf of your roommate? Are you going to be able to debug on that person's machine? Yes I'll be the one that handles this on his machine. Just let me know what you need. Ok. Not sure I can help any more though. Perhaps someone else can. A window may become maximized when it's mapped due to several reasons: (a) the initial window size is bigger than the screen size (b) the window asked the window manager to maximize it (c) a window rule sets the maximized state (d) a script sets the maximized state Does purging dolphin and konsole config files help to resolve the issue? The member on EOS fixed his by rolling back a week and doing the updates again and seems to be fine now. Now what is exactly involved with purging Dolphin? I don't want to lose his custom service menu items. Thanks Can confirm I'm encountering exactly the same issue on KDE neon User Edition 5.19, using Plasma DE and KWin WM. Even simply pointing out where/how Konsole and/or Dolphin store their startup size preferences would make for a great starting point. Sorry for the double comment, but I wanted to report that I currently solved the issue by removing a bunch of "suspicious" lines from my ~/.config/konsolerc file. The lines looked like the following: Window-Maximized 1016x1807=true Window-Maximized 614x1093=true Window-Maximized 647x1150=true Window-Maximized 864x1536=true Window-Maximized 904x1205=true Window-Maximized 909x1617=true (In reply to agentxlax from comment #7) > The member on EOS fixed his by rolling back a week and doing the updates > again and seems to be fine now. Now what is exactly involved with purging > Dolphin? I don't want to lose his custom service menu items. Thanks Sorry for not providing enough information how to do that. The config file for konsole and dolphin is ~/.config/konsolerc and ~/.config/dolphinrc, respectively. By purging, I meant saving a config file and then removing it in /.config. After you've finished testing, restore the config file. Okay, so it looks like konsole maximizes itself at startup. (In reply to 0xCAP from comment #9) > Sorry for the double comment, but I wanted to report that I currently solved > the issue by removing a bunch of "suspicious" lines from my > ~/.config/konsolerc file. > The lines looked like the following: > > Window-Maximized 1016x1807=true > Window-Maximized 614x1093=true > Window-Maximized 647x1150=true > Window-Maximized 864x1536=true > Window-Maximized 904x1205=true > Window-Maximized 909x1617=true Are you using Frameworks 5.74? I touched the code that does this recently, so it's possible I regressed something. :( In my case I'm just going to fresh install my roommate's OS and replace it with EbdeavourOS. Nice and minimal and gives me the chance of getting the OS on his M.2 versus the SATA SSD it's now on. I'm currently running EOS and for the most part I've loving it. I'm sure the Dolphin issue he's having is something he did and not his currently installed OS's fault. Can you tell me the version of Frameworks running on this person's machine? I just need to know if it's 5.74 or not. Yep, I'm on Frameworks 5.74. Then there's a chance I messed this up. Will investigate. *** Bug 427867 has been marked as a duplicate of this bug. *** I'm investigating and can't get this to happen. I have some questions: 1. Is it still happening with the latest Frameworks? 2. Does this happen with only Konsole, or also Dolphin? How about Kate? 3. Are you currently using a scale factor, or have you done so in the past or changed it recently? 4. Do you have multiple screens? 4a if so, do they have differing resolutions? yes he's still having the issue even with the current frameworks and it's dolphin that's doing it not konsole or kate. as foir your 3rd question i believe we had to scale down, but that's been awhile so i can't swear to it. lastly just the one monitor. Does the dolphinrc file still have multiple Window-Maximized [something]x[something else]=true entries in it? If so, can you attach the file and also mention the screen's resolution? *** Bug 430145 has been marked as a duplicate of this bug. *** Another duplicate, re-opening. Bug is somewhere around here: https://invent.kde.org/frameworks/kconfig/-/blob/master/src/gui/kwindowconfig.cpp#L50 Perhaps the problem is that these entries aren't being deleted when they should be. A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kconfig/-/merge_requests/36 Git commit a62e53e1b1fdb363fefb74907dca339b238e99b9 by Nate Graham. Committed on 09/12/2020 at 18:23. Pushed by ngraham into branch 'master'. Fix windows being inappropriately maximized on launch When a window is closed while maximized, we write a special string to the config file so that it gets restored in its maximized state. But we don't ever delete that thing when the window is un-maximized and closed again, causing the window to always be maximized when launched. FIXED-IN: 5.78 M +3 -0 src/gui/kwindowconfig.cpp https://invent.kde.org/frameworks/kconfig/commit/a62e53e1b1fdb363fefb74907dca339b238e99b9 Once you get this fix (in Frameworks 5.78), you may need to manually delete the spurious Window-Maximized entries from the app's rc file. But thereafter, they should not come back. I wonder whether https://bugzilla.opensuse.org/show_bug.cgi?id=1179294 is somehow related. Will try to have a look at the relevant config files the next time I run Tumbleweed. *** Bug 431267 has been marked as a duplicate of this bug. *** (In reply to Nate Graham from comment #26) > Once you get this fix (in Frameworks 5.78), you may need to manually delete > the spurious Window-Maximized entries from the app's rc file. But > thereafter, they should not come back. Is there a use case for multiple entries? Otherwise, cannot we just loop through all entries in order to fix already corrupted configs flying around? (In reply to 0xCAP from comment #9) > I currently solved > the issue by removing a bunch of "suspicious" lines from my > ~/.config/konsolerc file. > The lines looked like the following: > > Window-Maximized 1016x1807=true > ect ... This fixed my issue. I'd always had a window size defined (130 x 80) that was a good starting point. But like this gentleman, I had a window-maximized line that was totally out of place. Removed it, and expected behaviour was restored. Yeah there was a brief period of time during which those items were inappropriately written to people's config files. The bug causing this to happen has been fixed now, but it's possible that you would still be affected if it happened to you during that period of time. Removing them is a perfectly acceptable way to fix it for yourself. (In reply to Nate Graham from comment #31) > Yeah there was a brief period of time during which those items were > inappropriately written to people's config files. The bug causing this to > happen has been fixed now, but it's possible that you would still be > affected if it happened to you during that period of time. Removing them is > a perfectly acceptable way to fix it for yourself. Considering the time stamp of the participants, true. What flummoxed me was the location. The convention for the .config directory originally was in this format $XDG_CONFIG_HOME/subdir/filename, so I was looking for .config/kde/configuration file location. It never occurred to me they would be in the base of the .config file. The KDE configuration file location has shifted a time or two since it was originally released so I was actually poking around the ./local directory looking. The issue wasn't a major file to me and I knew I'd eventually get around to finding an answer. I do wish the files would eventually follow the convention, but innovation doesn't occur without breaking a rule or two and the growth of Linux, KDE and the other windowing systems is phenomenal. When I ran across it in 1995 you had to know the specific hardware configuration and chipset of the video card to get X to run and all the apps had to be built in order to run. It was a daunting experience but I knew OS/2 was in it's death spiral and I was desperate not to be forced into using any Microsoft products at home. I switched to Linux full time in 1997 and the change from the 1995 version was profound. The growth and maturity has continued to defy my expectations and I don't see that changing. I'm so glad you see it that way! :) |