Re: [kde] Bizarre window snap at screen borders
On 10/23/2013 09:23 PM, Wes Hardin wrote: > It is an intended behavior. It was introduced (with many bugs) in 4.11 and > refined gradually over the past two releases. I understand the developer's > reasoning, but it has no benefit in my (and apparently others') workflow. I > have had lengthy dicussions with the KDE developers about at least making it > optional. They have refused. Unbelievable. I do not mind crazy defaults as far as I can revert to what I consider saner, but this one is not even configurable. Inconsistent and ugly. -- Roberto Ragusamail at robertoragusa.it ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
Roberto Ragusa posted on Thu, 24 Oct 2013 10:53:04 +0200 as excerpted: > On 10/23/2013 09:23 PM, Wes Hardin wrote: >> It is an intended behavior. It was introduced (with many bugs) in 4.11 >> and refined gradually over the past two releases. I understand the >> developer's reasoning, but it has no benefit in my (and apparently >> others') workflow. I have had lengthy dicussions with the KDE >> developers about at least making it optional. They have refused. > > Unbelievable. > I do not mind crazy defaults as far as I can revert to what I consider > saner, but this one is not even configurable. > Inconsistent and ugly. FWIW, I believe it /was/ configurable at one point. I remember an option in kde settings... something about "maximized windows can be resized", with a checkbox, IIRC. And I set that and all was fine... until a kde update apparently removed that functionality and dragging the edge of a maximized window "broke". I thought the setting had just got reset and spent quite some time turning kde settings upside down and inside out, attempting to shake out that configuration option again, but I finally decided the option must have been removed. This thread now confirms it. Note that I run either latest series live-branch (currently 4.11-branch), or during the betas when lastest stable is basically done but they've not branched off the new branch yet, master/HEAD (well, thru early 4.11, now the various kde projects are splitting off a 4.x branch and master is qt5 based kde5/frameworks, but I'll be sticking with the 4.x branch for awhile I think). And I update every week or so, thus far more often than the monthly releases (semi-monthly during the beta/rc pre-releases). So I can't easily say what specific version the config option appeared in, and where it disappeared, without spending some time looking that all up. It may have actually been the betas that had the config option, with it being removed by 4.11.0 release, I'm not sure. But the config options was there for awhile as I remember it. And I too find the now hard-coded behavior annoying. Tho as I believe I said in an earlier reply, now that I figured out what happened, it's reasonably easy to use the modifierkey-mousebutton drag method, to click /inside/ a window and resize it. /That/ still works for these windows, fortunately! And it's not even much more trouble. But it *DOES* require breaking the old edge-drag habit and training myself in with the new modifier-key-drag habit, and that's certainly annoying! Without that workaround, there's a fair chance I'd be motivated enough to trace down the commit that killed that functionality and revert it, setting up a patch to be (scripted-auto-)applied when I rebuild kwin or whatever. Since I'm on gentoo and already building from source using ebuild scripts, that's a simple matter of dropping the patch in the appropriate dir so it's automatically applied when I rebuild the package. However, given that I have the modifier-drag workaround, my frustration hasn't risen to the level of triggering the search for that individual commit. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
Am Donnerstag, 24. Oktober 2013, 09:27:08 schrieb Duncan: > Roberto Ragusa posted on Thu, 24 Oct 2013 10:53:04 +0200 as excerpted: > > On 10/23/2013 09:23 PM, Wes Hardin wrote: > >> It is an intended behavior. It was introduced (with many bugs) in 4.11… > > Unbelievable. > > I do not mind crazy defaults as far as I can revert to what I consider > > saner, but this one is not even configurable. > > Inconsistent and ugly. > > FWIW, I believe it /was/ configurable at one point. I remember an option > in kde settings... something about "maximized windows can be resized", > with a checkbox, IIRC. And I set that and all was fine... until a kde > update apparently removed that functionality and dragging the edge of a > maximized window "broke". I thought the setting had just got reset and > spent quite some time turning kde settings upside down and inside out, > attempting to shake out that configuration option again, but I finally > decided the option must have been removed. This thread now confirms it. See how tastes differ. *I* found this a bad idea and it was among the things I always disable right after installation, because I wanted the window's [X] to be in the corner where it belongs so I can quickly reach it by mouse. It's the same reason for which I can't understand why people use top panels. But that's the user world -- to each his own, and the dev's can't accommodate everyone. The fact that they don't include (or, as you say, even remove) the option is sadly another story. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. Es gibt bessere zündende Ideen als die Bombe. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
On 10/24/2013 04:27 AM, Duncan wrote: > Roberto Ragusa posted on Thu, 24 Oct 2013 10:53:04 +0200 as excerpted: > >> On 10/23/2013 09:23 PM, Wes Hardin wrote: >>> It is an intended behavior. It was introduced (with many bugs) in 4.11 >>> and refined gradually over the past two releases. I understand the >>> developer's reasoning, but it has no benefit in my (and apparently >>> others') workflow. I have had lengthy dicussions with the KDE >>> developers about at least making it optional. They have refused. >> >> Unbelievable. >> I do not mind crazy defaults as far as I can revert to what I consider >> saner, but this one is not even configurable. >> Inconsistent and ugly. > > FWIW, I believe it /was/ configurable at one point. I remember an option > in kde settings... something about "maximized windows can be resized", > with a checkbox, IIRC. And I set that and all was fine... until a kde > update apparently removed that functionality and dragging the edge of a > maximized window "broke". I thought the setting had just got reset and > spent quite some time turning kde settings upside down and inside out, > attempting to shake out that configuration option again, but I finally > decided the option must have been removed. This thread now confirms it. That is a separate issue that I don't know about. My maximized windows don't have a border to grab and drag, which I thought was a selectable option but I can't seem to find it now. I remember seeing the "maximized windows can be resized" option at one point too, but if maximized windows don't even have the option of having a border now then that option wouldn't make much sense. The issue here is related to snapping, packing, or creating new windows at the edge of the desktop. The KDE devs have determined that in every case, for every user, the border is useless at the edge of the desktop and thus windows should snap to the edge of the client rather than the decoration. For maximized windows (which don't have a border) I expect client content to end at the edge of the screen, but I have many, many more non-maximized terminals where the border provides the valuable visual feedback about the end of content. With the border off-screen, I just have a black box with text and no indicator of whether the content is going off-screen. Did I accidentally move part of the window off screen? Other users have various other uses for the border. While I recognize that some users may like the "feature", there are many who have voiced their dislike of the feature. I'm not advocating that my way be the only way, I've only asked for an option to toggle it. /* wes */ ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
Am 24.10.2013 10:53, schrieb Roberto Ragusa: > On 10/23/2013 09:23 PM, Wes Hardin wrote: >> It is an intended behavior. It was introduced (with many bugs) in 4.11 and >> refined gradually over the past two releases. I understand the developer's >> reasoning, but it has no benefit in my (and apparently others') workflow. I >> have had lengthy dicussions with the KDE developers about at least making it >> optional. They have refused. > > Unbelievable. > I do not mind crazy defaults as far as I can revert to what I consider saner, > but > this one is not even configurable. > Inconsistent and ugly. > Hm, but this is configurable. right click on the frame, select additional Action (weitere Actionen in german) and there you can select the settings for window management. In this dialogue you can select the moving part and on the right side you can set border snap to 0 (no border znapping). regards Martin ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
Wes Hardin posted on Thu, 24 Oct 2013 10:54:42 -0500 as excerpted: > That is a separate issue that I don't know about. My maximized windows > don't have a border to grab and drag, which I thought was a selectable > option but I can't seem to find it now. I remember seeing the > "maximized windows can be resized" option at one point too, but if > maximized windows don't even have the option of having a border now then > that option wouldn't make much sense. > > The issue here is related to snapping, packing, or creating new windows > at the edge of the desktop. The KDE devs have determined that in every > case, for every user, the border is useless at the edge of the desktop > and thus windows should snap to the edge of the client rather than the > decoration. > > For maximized windows (which don't have a border) I expect client > content to end at the edge of the screen, but I have many, many more > non-maximized terminals where the border provides the valuable visual > feedback about the end of content. > With the border off-screen, I just have a black box with text and no > indicator > of whether the content is going off-screen. Did I accidentally move > part of the window off screen? Other users have various other uses for > the border. > > While I recognize that some users may like the "feature", there are many > who have voiced their dislike of the feature. I'm not advocating that > my way be the only way, I've only asked for an option to toggle it. It may be a (sort-of) separate issue conceptually, but AFAIK the same patch (or series of patches) removed the edge of screen border for both cases. As for maximized windows, my expectation was apparently different than yours -- I maintain a conceptual difference between a maximized window, which should still have a border at the screen edge, and a full-screen window, which shouldn't. As for use-case, here's one: I have a kwin rule for pelapeli (kde's jigsaw puzzle "game") set, which forces the window to cover my two main monitors, with the titlebar just at the bottom of the third/top monitor (configured logically stacked on the other two so moving the mouse up moves into it, but it's physically off to the side, due to physical space constraints as the two big monitors are actually 42-inch TVs covering an entire wall at the foot of my bed, without room for the third except off to the side). Covering the two 42-inch big monitors makes the for a puzzle window about the same size as the puzzle table my family used to use when I was a kid... there's room to spread out the puzzle pieces. But, I have the rule set to force the size and location of the window such that the borders remain onscreen, despite the multi-monitor "maximized" window. Among other reasons this allows me to easily close the window with just the mouse (which is used when working on the puzzle, the keyboard being set off to the side and temporarily forgotten about as it's not useful for doing the puzzle), since I can get to the border and activate the window context menu with the window close option, from there. That way I don't have to go reaching for the keyboard to close the window from there, or crane my neck and squint at the smaller monitor off to the size, to maneuver the mouse to the close button in the titlebar found there -- hitting the "infinite edge" and activating the window's context menu to close the window is far easier in this case, and it won't work if the window border is off the edge of the screen. Which brings up a point. It's still possible to use window rules to force the borders to be where people want them, IF AND ONLY IF it's reasonable to force the window location and possibly size (depending on the screen border involved). However, since that /does/ end up forcing the location and possibly size of the window as well, which works for the use case I mention above, but not for others, it's not suitable when window location flexibility is desired. For instance my normal konsole window layout is two side-by-side, and I can't force the location as it would force them to be on top of each other instead of side-by-side. Unfortunately, that means kde's new default "border offscreen" behavior comes into play, and the external borders of the konsole windows disappear, leaving only the internal borders where the two butt up to each other, thus visually unbalancing them since the border on one side is there but the border on the other isn't. What's worse, since the border that's missing is the screen-edge border, it effectively kills the "infinite edge" advantage I mentioned above -- the ability to mouse to the edge and have the mouse "magically" stop at just the right spot to activate the window context menu to close or otherwise manipulate that window. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard St
Re: [kde] Bizarre window snap at screen borders
Frank Steinmetzger posted on Thu, 24 Oct 2013 13:34:58 +0200 as excerpted: > See how tastes differ. *I* found this a bad idea and it was among the > things I always disable right after installation, because I wanted the > window's [X] to be in the corner where it belongs so I can quickly reach > it by mouse. It's the same reason for which I can't understand why > people use top panels. But that's the user world -- to each his own, and > the dev's can't accommodate everyone. The fact that they don't include > (or, as you say, even remove) the option is sadly another story. Just noting the multi-monitor case, with monitors logically stacked and kwin set to maximize to a single monitor. That's actually the case here, with the further condition that altho three monitors are logically stacked, only the bottom two are actually physically stacked due to space constraints (they're actually 42-inch TVs that stack to cover an entire wall, with the third logically stacked on top to preserve the logical rectangular desktop, but physically off to the side where I have room for it). In that case, a top panel covering essentially all of the top monitor, my "system status dashboard", graphing user/system/nice/wait CPU usage separately for six cores, app/buffer/cache memory, various system temps, voltage and power usage, and fan speeds, network usage, and listing top applications by memory and cpu usage, etc, along with last 20 or so syslog entries, all in a custom superkaramba theme, makes sense, particularly since that monitor is physically separated from the others even if it's logically stacked on top of them. In any multi-monitor situation, unless the app's at the correct location on the correct monitor, that X button you mentioned isn't going to be in the "infinite corner" in any case. Since in my layout my working monitors are the two (logically) lower ones, I /never/ have windows in that "magic" location anyway, so having the status superkaramba theme occupying that space isn't a big deal. ... Thus demonstrating your point about "the user world -- to each his own" rather forcefully indeed. Absolutely, the devs can't accommodate everyone by default, but I long ago stopped expecting defaults that matched my usage. Instead, I don't care much about the defaults; I just want to have the configurability to sanely setup a configuration I'm comfortable with. And kde is renowned for that sort of flexible configurability, a big part of why I use it, for much the same "big part of" reason that I use both Gentoo and Linux in general -- the configurability. Too bad in this case kde had it, but removed it! =:^( -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
Martin (KDE) posted on Thu, 24 Oct 2013 18:46:16 +0200 as excerpted: > Am 24.10.2013 10:53, schrieb Roberto Ragusa: >> On 10/23/2013 09:23 PM, Wes Hardin wrote: >>> It is an intended behavior. It was introduced (with many bugs) in >>> 4.11 and refined gradually over the past two releases. I understand >>> the developer's reasoning, but it has no benefit in my (and apparently >>> others') workflow. I have had lengthy dicussions with the KDE >>> developers about at least making it optional. They have refused. >> >> Unbelievable. >> I do not mind crazy defaults as far as I can revert to what I consider >> saner, but this one is not even configurable. >> Inconsistent and ugly. >> >> > Hm, but this is configurable. right click on the frame, select > additional Action (weitere Actionen in german) and there you can select > the settings for window management. In this dialogue you can select the > moving part and on the right side you can set border snap to 0 (no > border znapping). Except... I /want/ border snap. I just want it to snap so the decoration is shown too. Setting that to zero does indeed let me position the window to show the decoration (thanks for pointing that out, I generally understood it but as a result hadn't actually tried it to see what the interaction was with the new change in behavior), but then I lose the snap-to-border effect that's the main thing the option configures, and that I want to keep. I (and I guess the other users in-thread) just need it to snap to the border but still show the decoration when it does so, and that now appears to be impossible. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
On Thu, Oct 24, 2013 at 05:37:41PM +, Duncan wrote: > Frank Steinmetzger posted on Thu, 24 Oct 2013 13:34:58 +0200 as excerpted: > > > See how tastes differ. *I* found this a bad idea and it was among the > > things I always disable right after installation, because I wanted the > > window's [X] to be in the corner where it belongs so I can quickly reach > > it by mouse. It's the same reason for which I can't understand why > > people use top panels. But that's the user world -- to each his own, and > > the dev's can't accommodate everyone. The fact that they don't include > > (or, as you say, even remove) the option is sadly another story. > > Just noting the multi-monitor case, with monitors logically stacked and > kwin set to maximize to a single monitor. That's actually the case here, > with the further condition that altho three monitors are logically > stacked, only the bottom two are actually physically stacked due to space > constraints (they're actually 42-inch TVs that stack to cover an entire > wall, with the third logically stacked on top to preserve the logical > rectangular desktop, but physically off to the side where I have room for > it). > > In that case, a top panel covering essentially all of the top monitor, > my "system status dashboard", graphing user/system/nice/wait CPU usage > separately for six cores, app/buffer/cache memory, various system temps, > voltage and power usage, and fan speeds, network usage, and listing top > applications by memory and cpu usage, etc, along with last 20 or so syslog > entries, all in a custom superkaramba theme, makes sense, particularly > since that monitor is physically separated from the others even if it's > logically stacked on top of them. you godda admit, that’s an “exotic” setup. Anyways, I was more referring to the “typical“ single-monitor, single-desktop use case. Not having seriously worked with a multimonitor setup yet, I excluded that from my thought process. :o) Think for example *cough* Apple laptops or, heck, Gnome (not just 3 but also the default config in 2 and also in xfce4). > ... [...] Instead, I don't care much about the defaults; I just want > to have the configurability to sanely setup a configuration I'm > comfortable with. > > And kde is renowned for that sort of flexible configurability, a big part > of why I use it, for much the same "big part of" reason that I use both > Gentoo and Linux in general -- the configurability. Too bad in this case > kde had it, but removed it! =:^( Indeed. PS.: If you use KWin's align window function (which I set to Meta + left/right, inspired by Windows) to put a window either on one half or quarter of a screen, then the borders are not chopped. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. “I’m working on than.” -- Stephen Hawking (When visiting the set of the Starship Enterprise’s engine room) signature.asc Description: Digital signature ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Bizarre window snap at screen borders
On 10/24/2013 10:07 PM, Frank Steinmetzger wrote: > On Thu, Oct 24, 2013 at 05:37:41PM +, Duncan wrote: >> Frank Steinmetzger posted on Thu, 24 Oct 2013 13:34:58 +0200 as excerpted: >> >>> See how tastes differ. *I* found this a bad idea and it was among the >>> things I always disable right after installation, because I wanted the >>> window's [X] to be in the corner where it belongs so I can quickly reach >>> it by mouse. It's the same reason for which I can't understand why >>> people use top panels. But that's the user world -- to each his own, and >>> the dev's can't accommodate everyone. The fact that they don't include >>> (or, as you say, even remove) the option is sadly another story. >> >> Just noting the multi-monitor case, with monitors logically stacked and >> kwin set to maximize to a single monitor. That's actually the case here, >> with the further condition that altho three monitors are logically >> stacked, only the bottom two are actually physically stacked due to space >> constraints (they're actually 42-inch TVs that stack to cover an entire >> wall, with the third logically stacked on top to preserve the logical >> rectangular desktop, but physically off to the side where I have room for >> it). >> >> In that case, a top panel covering essentially all of the top monitor, >> my "system status dashboard", graphing user/system/nice/wait CPU usage >> separately for six cores, app/buffer/cache memory, various system temps, >> voltage and power usage, and fan speeds, network usage, and listing top >> applications by memory and cpu usage, etc, along with last 20 or so syslog >> entries, all in a custom superkaramba theme, makes sense, particularly >> since that monitor is physically separated from the others even if it's >> logically stacked on top of them. > > you godda admit, that’s an “exotic” setup. Anyways, I was more referring > to the “typical“ single-monitor, single-desktop use case. Not having > seriously worked with a multimonitor setup yet, I excluded that from my > thought process. :o) Think for example *cough* Apple laptops or, heck, > Gnome (not just 3 but also the default config in 2 and also in xfce4). > >> ... [...] Instead, I don't care much about the defaults; I just want >> to have the configurability to sanely setup a configuration I'm >> comfortable with. >> >> And kde is renowned for that sort of flexible configurability, a big part >> of why I use it, for much the same "big part of" reason that I use both >> Gentoo and Linux in general -- the configurability. Too bad in this case >> kde had it, but removed it! =:^( > > Indeed. > > > PS.: If you use KWin's align window function (which I set to Meta + > left/right, inspired by Windows) to put a window either on one half or > quarter of a screen, then the borders are not chopped. > I don't remember what version of kde that started this problem. Please remind me so I can (hopefully) prevent it from being upgraded. --doug -- Blessed are the peacemakers..for they shall be shot at from both sides. --A.M.Greeley ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
