Launchpad has imported 43 comments from the remote bug at https://bugs.kde.org/show_bug.cgi?id=15329.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2000-11-14T13:42:45+00:00 Kidcat7 wrote: (*** This bug was imported into bugs.kde.org ***) Package: kwin Version: 2.0 Severity: wishlist Installed from: Mandrake 7.2 RPM I think that the placement policy should have en aditional feature called 'Remember'. M$-winslows has this feature and it is awfully nice... Especially when running at high resolutions it is nice that everything pops up in the same size on the same place. I know that other WM's has this feature so it should not be hard to implement ;) (submitted via bugs.kde.org) Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/0 ------------------------------------------------------------------------ On 2002-09-26T19:44:57+00:00 L-lunak-5 wrote: *** Bug 27969 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/1 ------------------------------------------------------------------------ On 2002-10-01T12:18:19+00:00 L-lunak-5 wrote: *** Bug 18578 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/2 ------------------------------------------------------------------------ On 2002-10-02T17:37:51+00:00 L-lunak-5 wrote: See also bug #39946. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/3 ------------------------------------------------------------------------ On 2002-10-19T22:18:47+00:00 hbush wrote: > Especially when running at high resolutions it is nice that everything pops up in the same size on the same place. Very strongly supported. There should be some way to define strict, unchangeable by application itself position and size of initial window. All child windows (optionally) should have the same size. Cascading windows should use the same initial position incremented by some defineable steps (default values depending of screen resolution). This feature will be valuable specially with business people. Take a look on business people desktops: most of them want their mail app, text editor, browser etc. exactly on positions they like, not everywhere decided by some optimization algorithm. I know :-) I want myself all things on my 1600*1200 desktop to be on their defined positions, because I am used to that order and do not want to distract my attention seeking where the hell KMail opened this time and why it is so small this morning - I need to resize it and bring back to its right place anyway. Annoying. So to say we need hammer and nails to fix at least main KDE apps in places they should be forever. Title option Save Settings _doesnt_ do this, BTW. It too often forgets about place and size. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/4 ------------------------------------------------------------------------ On 2002-12-19T19:54:32+00:00 L-lunak-5 wrote: *** Bug 28224 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/5 ------------------------------------------------------------------------ On 2003-05-22T15:45:16+00:00 L-lunak-5 wrote: *** Bug 58771 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/6 ------------------------------------------------------------------------ On 2003-10-27T13:04:04+00:00 Sébastien Laoût wrote: - I agree : having theire windows alwayse at the same position is needed. - And have a maximized flag is also good (especialy with the new interactive changing desktop resolution, or orientation... or simply by changing the kicker size). - It's already doable but few programs, as OpenOffice, overwrite this behavor and I doesn't like : his window isn't maximized and it still few pixels ! - And also, at the moment, we must explicitly specifie which windows will keep theire geometry. But I want save geometrie of ALL windows : please add a mode to ALWAYSE remember windows properties by default. What KWin III will change ? Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/7 ------------------------------------------------------------------------ On 2004-04-09T23:21:22+00:00 L-lunak-5 wrote: *** Bug 79300 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/8 ------------------------------------------------------------------------ On 2004-05-13T11:27:43+00:00 L-lunak-5 wrote: *** Bug 81463 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/9 ------------------------------------------------------------------------ On 2004-05-17T20:11:09+00:00 Y-coolo wrote: Replaced kidc...@hotmail.com with abrah...@acm.org due to bounces by reporter Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/10 ------------------------------------------------------------------------ On 2005-01-25T12:52:22+00:00 L-lunak-5 wrote: *** Bug 85715 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/11 ------------------------------------------------------------------------ On 2005-01-25T12:52:29+00:00 L-lunak-5 wrote: *** Bug 97718 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/12 ------------------------------------------------------------------------ On 2005-01-25T12:53:42+00:00 L-lunak-5 wrote: NOTE TO SELF: Check all duplicates, especially the last two. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/335761/comments/13 ------------------------------------------------------------------------ On 2005-02-09T12:53:52+00:00 hbush wrote: Quoted from Jarne Cook, in description of Bug 97718: "I see kwin now has the extreme advanced window settings dialog. In there I can set each app to have it's size/pos remembered. This is a nice feature but it's is very inconvenient. To have to right click for every application is just overboard." Agree. Not only one need to set each app to have it's size/pos remembered but in fact it's necessary for every _window_. For exampe, I need to set RClick -> Advanced -> Store window settings for EACH WINDOW I use with Mozilla (and there usually are lot's of Mozilla windows on my desktop, and I don't like tabs, thank you). If I have used previously e.g. not more than 6 Mozilla windows and decide to open the seventh one, it will pop up in some hard to predict weird position and I will have to adjust it and set "Store window settings" for it individually. Well, this is better than not to have any position/size remembering at all (like it used to be some time ago), but nevertheless "overboard". In my humble opinion it would be much better if option "Remember" will refer to whole application and it's windows, by default according window placement policy. For example, if I have set Placement as "Cascade" and set "Remember" with main application window, then additional windows should come up cascaded (if not set specifically with "Remember"). Harry, using KDE 3.2.3 coming with Mandrake 10.1 x86-64 Commercial. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/335761/comments/14 ------------------------------------------------------------------------ On 2006-06-23T20:16:13+00:00 sulla wrote: I strongly support this wish! It drives me nuts to have a "economic" placement, because for ME economic means a window pops up, where I last closed it. This makes it "economic" for me to find the window. "economic" is great, if you like it. Also, you can use an "economic" placement, if a window is opened for the first time. "random" position is some odd feature. Who actually uses it? PLEASE add a policy "remember". And make it remember different functions of konquerer (one placement and size for file browsing, one other for internet browsing...) Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/15 ------------------------------------------------------------------------ On 2006-07-11T17:32:09+00:00 Stefan-borggraefe wrote: *** Bug 121736 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/16 ------------------------------------------------------------------------ On 2006-07-11T18:02:32+00:00 Kyromaster wrote: Many apps already have the functionality to remember the window state, and some have the ability to remember the window position and size (like kdetv). Perhaps a general framework for remembering those settings would be useful. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/17 ------------------------------------------------------------------------ On 2006-11-02T02:55:48+00:00 Kde-8 wrote: > I want to save the geometry of ALL windows: please add a option to ALWAYS > remember windows properties by default. ACK! I use Linux/KDE (2048x768) inside vmWare on a dual-screen host (2560x1024). So X & kdm don´t know about two screens and just realize the wide resolution. So windows open often in the middle of both screens or with 70% of the desktop-width what results in ultra-wide widgets. What would happen with a 4000px wide (virtual) desktop? The windows would spawn overweening wide - so they need to know their 'common size' (something between minimal size to show their content and size of one display) - or at least remember the users demand last time. The 'smart' windowplacement of KDE 3.5 sometimes opens windows (preferred texteditors) with a size of about 50x50px in a far away corner, if the desktop is cluttered with windows. But two minutes ago I maximized the last application entity vertically and want the current the same. The functionality of the already available window-specific behavior configuration is great for special demands, so keep it, but it´s not good as missing-default workaround. (The names of the tabs (at least the german) for this configuration do not really reveal which window-identification is mandatory for a rule. The workflow steps don´t really open up.) I just wanted to annotate that application-specific transparency-rules also fit this topic, but it´s already there! :) Thank you, team!! Beside the option 'remember application size and position when reopen' the smart placement (and sizing) would be much smarter if it could be defined that kde lives inside a dual-, tripple-, n-monitor configuration. Depending on this, another 'smart' placement-strategy would work: where to place new windows on screen: left screen, center, right screen, top, bottom, or the screen where mousepointer is on. I have to note, that I haven´t tryed xinerama already. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/18 ------------------------------------------------------------------------ On 2006-11-06T12:54:22+00:00 L-lunak-5 wrote: If the host system is dual-head and the client system inside VMWare doesn't know about this, then I'd consider this to be a VMWare problem. You can use http://ktown.kde.org/~seli/fakexinerama/ to force a specific Xinerama setup. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/335761/comments/19 ------------------------------------------------------------------------ On 2008-12-05T02:26:54+00:00 usr wrote: KDE must remember positions and size for all apps, for better desktop experience. It's very annoying to have to resize the applications each time they boot. Yes, it can be done by hand with KWin, but this is something that KWin should know do by himself (like MS Windows, for example). Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/20 ------------------------------------------------------------------------ On 2009-01-11T11:30:47+00:00 kioftes wrote: It is indeed something that should be fixed. Some apps (ex. adept) open in a ridiculously small window. It is very annoying and still there on kde 4.1.85 Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/21 ------------------------------------------------------------------------ On 2009-05-03T04:48:56+00:00 Z-lucas wrote: *** Bug 191375 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/23 ------------------------------------------------------------------------ On 2010-12-07T08:15:14+00:00 Nemeskey-david wrote: Jesus, opened 10 years ago, 322 votes, and the bug is still here?! Please, implement this feature. It is more relevant than ever with KDE4 and the plasma widgets. My notebook has an extra-wide screen, so I prefer to place a few plasmoids on the right hand side of the screen, and I don't want any windows to cover them. Unfortunately the "smart" (more like "dumb as hell") placement puts every window there (since there is already a window in the top left corner). Firefox remembers its position, but the KDE apps don't. (On a side note, you could also modify how the "smart" placement works -- or just rename it to "corners".) Remembering the size would also be nice, I hate how Adept always opens in such a small window. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/26 ------------------------------------------------------------------------ On 2012-01-04T04:46:29+00:00 Gökdeniz Karadağ wrote: Searching for a solution for making window positions permanent, I found lots of instructions on "window rules". Some months, and some researchers later I find this bug and see it is open from 2000. - Is there an official choice/policy on NOT doing a "remember all window positions"? If so, these bugs should be closed as WONTFIS - Is there an implementation difficulty? If so, it would be very nice to hear this from developers. - Is the only thing that we lack is manpower and developer interest ? The issue can be proposed in Summer of code, or a call-to-arms can be published on developer blogs to implement this highly wanted feature. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/27 ------------------------------------------------------------------------ On 2012-01-04T15:04:25+00:00 Thomas-luebking wrote: First off: it's Martins decision. I'll just share my personal opinion on this. There seem three requests here a) make kwin store all window positions b) make kwin store all window dimensions c) make kwin shrink it's placement area Dealing (c) first - this feature does actually exist. It's called "struts". They can set by *any* client (including the desktop) and usually are by docks. They will also have the in the apparent context "nice" side-effect to constrain the maximization area. To make that very clear (while I think I have on some plasma-desktop bug): IT IS NOT REQUIRED TO HAVE AN ACTUAL DOCK TO ADD A STRUT¹ The solution in the named usecase (which makes me wanna bash "Why do ppl. want to add important stuff to their desktop where it's covered by some windows anyway. What's the whole point of SuperKaramba") would be to have plasma-desktop to optionally add some virtual struts (== dead area from the screen edges) for it's plasmoids. As a result 1) new windows would not be placed in that area 2) maximizing a window would not make it cover that area 3) moving a window across that are will require a "free" move (alt+lmb or specially featured by the decoration) resize but is still possible ---- Now regarding (a), that is to re/store all window positions: "Client job. Period." 1) 100% exact identification of a window is not possible for the WM as it is for the Clients 2) Braindead implementation approach. The WM would have to keep a (fast growing) list of all windows to check _everytime_ a window is mapped. Taking every client window you once opened, every dialog and the fact that window properties (including even the classname by every frickin' minor version - ask firefox...) change "under the hood" ie. without any chance for the WM to know that this window will never show up again but is replaced by some other" or that we'd have to invoke the title for precise identification means that we're very soon talking about megabyte dimensions for that list. Meaning you can forget about the CPU cache. (That translates: "dog slow") On the other hand, the client only needs to store only two numbers and in the beginning tell the WM "please place me here, thank you". -> task for kdelibs/kmainwindow, but: 3) Very debatable functionality. The exact position is stored alongside and thus across sessions. Makes sense because it means you get the desktop you left. Placing a window at the exact same position it had last time while the desktop may have completely changed in the meantime (you plasmoid setup, other windows, ...) doesn't sound "smart" at all but more like intrusive (the window might be placed right under the pointer leaving a click at an unintended target; it might cover other windows while there would have been plenty of space where it would not) --- b) Shares points (1) and (2) with (a) but in general makes a lot of sense, why this is the default behavior of kdelibs/kmainwindow and even per screen size. (That is, when you closed a window @ 1774x1216 while your netbook was attached to your cinema display, it will still open at 1024x600, as it closed last time on the netbook display) KWin provides the rules as workarounds for legacy or broken or whatever clients which do not provide this functionality, but for Implementing this as a general feature, see (a.2) ===> My personal conclusion: * Clearly "WONTFIX" -at least not implemented in the WM-for (a) * WORKSFORME for (b) * (c) is misassigned. I admit to have no plasmoids on my desktop so i cannot judge on whether this makes sense, but it can and must be done by the client interested in restricting the placement area (plasma-desktop in the apparent case) [1] Implementation detail: Ok, kwin does a sanity check whether the requesting client is a dock. It's however ok to have an 1x1 offscreen dummy dock and make it add random struts. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/28 ------------------------------------------------------------------------ On 2012-01-18T05:08:00+00:00 Hormel wrote: Re. post #25 An interesting take on things (works for me) but doesn't solve the problem. Fact is that each app used here at present is not saving it's window size+position in a reproducible way. Main windows, sub menus, dialogues, are all affected here in v 4.6.5 it's a ridiculous situation in 2012! Having pinhead sized "windows"...pop up for an application start-up. Most especially perhaps when M$ has got this right from year 1998 at least. Yeah, a rant, but I'd fix it if I could and not take an arrogant stance (Martin) that helps nobody. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/29 ------------------------------------------------------------------------ On 2012-01-18T05:28:31+00:00 Mgraesslin wrote: > Main windows, sub menus, dialogues, are all affected here in v 4.6.5 it's a > ridiculous situation in 2012! Having pinhead sized "windows"...pop up for an > application start-up. it might be possible to use the JavaScript bindings for it. Just use a huge map with the positions of your windows and listen to Client added. It can fix your problem, but is nothing to go into the window manager itself. > > Most especially perhaps when M$ has got this right from year 1998 at least. There is nothing wrong with using Microsoft Windows if it suits your needs better. Unfortunately it doesn't make any sense to point out that Windows supports this as that doesn't fix problems. Mircosoft is in the lucky situation of controling the complete Windowing System. We rely on what X provides. > Yeah, a rant, but I'd fix it if I could and not take an arrogant stance > (Martin) that helps nobody. Calling people arrogant in a bug report makes it very likely that they will start implementing your desired features. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/30 ------------------------------------------------------------------------ On 2012-01-18T05:55:18+00:00 Thomas-luebking wrote: Not sure, but since Martin hasn't commented on this at all so far, I must assume that you accuse me of an "arrogant stance"? Fact #1 Microsoft has actually nothing. There's nothing such as a WM on Windows but applications handle their window management pretty much themselves. For at least the dimensions that means they (those which actually do, what's NO WAY the general case) store them in their registry group and restore them on re-launch... Fact #2 ... what is -as mentioned- pretty much the same as (nearly) all KDE applications do. If they do not for you (you didn't specify what applications pop up "pinhead sized") that is clearly a bug, but likely a local one (sorry) like insufficient access permissions an (ivalid, would be bug - yes) major strutting. You should name those clients and then start to investigate why they do as you observe, for this is NOT the behaviour on any system i've ever been in touch with why the "works for me" statement is not arrogant but simply reality. Fact #3 I not a single client tries to always restore it's former *position* (what is especially defined by the ICCCM spec and generally honored by kwin, except for explicit rule overrides) that means that either *all* application delevopers, DE engineers and HIG experts are arrogant or stupid - or no one is. I'll happily read your paper to lay out why this would be a generally resonable behaviour. Fact #4 I have no idea what you take as "sub menus" but ("popup-")menus a) are not handled by the window manager at all b) (dynamically) calculate their dimensions to fit the content c) are (dynamically) placed (by the application) related towards their parenting items d) are neither resizable nor movable by users at all. esp. if (b) should NOT hold for you, that would mean that for some reason every application on your destop thinks that you've an unreasonably tiny workspace (but it would also mean that you couldn't "maximize" them any bigger) Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/31 ------------------------------------------------------------------------ On 2012-01-18T05:57:41+00:00 Hormel wrote: Thanks for the response and I owe you an apology, therefore I apologize. I had just read something from you in another medium and it was rather blunt but I realize now that English may not be your first language. also I'd just resized a Firefox window for the umpteenth time. As a strong advocate of Linux, KDE, FSF etc. and an 'assistant' to more than a few senior citizens it really irks when stuff like this "window forgetting" happens. Try as I might I cannot honestly defend a criticism that follows these or similar events. No Microsoft products in use here as they don't suit me. :) Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/32 ------------------------------------------------------------------------ On 2012-01-18T06:38:51+00:00 Hormel wrote: (In reply to comment #28) > Not sure, but since Martin hasn't commented on this at all so far, I must > assume that you accuse me of an "arrogant stance"? Sorry for the misunderstanding, it was a blunt statement made on the subject (attributed to Martin) that upset a few people. > Fact #1 Thanks > Fact #2 > ... what is -as mentioned- pretty much the same as (nearly) all KDE > applications do. If they do not for you (you didn't specify what applications > pop up "pinhead sized") that is clearly a bug, but likely a local one (sorry) > like insufficient access permissions an (ivalid, would be bug - yes) major > strutting. You should name those clients and then start to investigate why > they > do as you observe, for this is NOT the behaviour on any system i've ever been > in touch with why the "works for me" statement is not arrogant but simply > reality. Ok thanks, in short almost any GUI type that I've used appears to do this. A clue for me might be that KDE 3.5, 4.5, held the settings and 4.6.5 doesn't. > Fact #3 > I not a single client tries to always restore it's former *position* (what is > especially defined by the ICCCM spec and generally honored by kwin, except for > explicit rule overrides) that means that either *all* application delevopers, > DE engineers and HIG experts are arrogant or stupid - or no one is. > I'll happily read your paper to lay out why this would be a generally > >resonable behaviour. Fair enough, I don't expect to be writing that paper any time soon. > Fact #4 > I have no idea what you take as "sub menus" but ("popup-")menus > a) are not handled by the window manager at all Not clearly stated by me, sorry, "popping-up" could have been said as 'appearing' and refers to any of the windows listed in the "Advanced> Special Window Settings> Window Extra area. > b) (dynamically) calculate their dimensions to fit the content > c) are (dynamically) placed (by the application) related towards their > parenting items > d) are neither resizable nor movable by users at all. > > esp. if (b) should NOT hold for you, that would mean that for some reason > every > application on your destop thinks that you've an unreasonably tiny workspace > (but it would also mean that you couldn't "maximize" them any bigger) Of course what you say makes good sense and I don't know why the effect is experienced but as far as I can tell permissions are fine and as previously mentioned this behavior was almost totally absent in earlier KDE incarnations. It is certainly very bothersome though in my 4.6.5 version. Re. Workspace, my idea of clutter might not accord with another person's and I might be content to have windows layer upon layer in a single desktop and switch between them. < (just for illustration, I don't do this) That's okay for me in that instance but unless I'm missing the point does the allocation strategy say in effect, "sorry but this next window is going to be pinhead sized because we have no space available?" The odd behavior is there in any case even with a single application on an otherwise sparsely populated screen. Just a single instance of Dolphin for example. Opens perfectly first time around, a re-size operation is done and then when opened again as a single app it's squashed up into 'pos 0,0' and so tiny as to be almost unrecognizable. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/33 ------------------------------------------------------------------------ On 2012-01-18T07:15:12+00:00 Mgraesslin wrote: > (In reply to comment #28) >> Not sure, but since Martin hasn't commented on this at all so far, I >> must >> assume that you accuse me of an "arrogant stance"? > > Sorry for the misunderstanding, it was a blunt statement made on the > subject > (attributed to Martin) that upset a few people. Now I am surprised that you attribute statements to developers who have not yet commented on the bug. But anyway I would like to know to which statement you refer which upset a few people. I am not a native speaker so I need to know which statements were bad phrased to not repeat the mistakes. Feel free to send the reply privately to keep this bugtracker clean. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/34 ------------------------------------------------------------------------ On 2012-01-18T07:37:09+00:00 Hormel wrote: > Now I am surprised that you attribute statements to developers who have > not yet commented on the bug. But anyway I would like to know to which > statement you refer which upset a few people. I am not a native speaker > so I need to know which statements were bad phrased to not repeat the > mistakes. Feel free to send the reply privately to keep this bugtracker > clean. OK I'll send you the information privately. Thank you for all that you do development-wise, and I will not add any more noise to bugtracker. I can see that a few other writers have stated the "pos,size" difficulty in a more lucid way and it's clearly a problem that could do with a better answer than the one we currently have. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/35 ------------------------------------------------------------------------ On 2012-01-18T16:24:13+00:00 Thomas-luebking wrote: (In reply to comment #30) > Sorry for the misunderstanding, it was a blunt statement made on the subject > (attributed to Martin) that upset a few people. Ok, I guess you just got why ppl. often write: DO NOT CROSSPOST! ;-) > Ok thanks, in short almost any GUI type that I've used appears to do this. A > clue for me might be that KDE 3.5, 4.5, held the settings and 4.6.5 doesn't. If it covers Dolphin, Kwrite, Firefox, Gimp and LibreOffice there's indeed a general (window- or filesystem) issue because they would all work differently in this regard. -> Did you add any rules to kwin ("kcmshell4 kwinrules", It's general access to "Special Window Settings" management) ==> (esp. if one of them is a "blind" rule matching all windows) please attach your ~/.kde/share/config/kwinrulesrc (the rules are very powerful and *do* allow you to shoot yourself and break your desktop) -> Do you use multiple (plasma-desktop) activities? (their introduction broke nearly all "remember" rules - see bug #264981 > That's okay for me in that instance but unless I'm missing the point does the > allocation strategy say in effect, "sorry but this next window is going to be > pinhead sized because we have no space available?" NO! The WM ensures reasonable bounds (ie. not bigger than the workspace and not smaller than the titlebar requires) but that's it. If the windows are *all* very small that is either a) because they set this size b) because a KWin rule explicitly forces them to this size c) because the workspace is (virtually) restricted to this size (that's why i asked for maximization behavior) > The odd behavior is [...] Opens perfectly first time around, a re-size > operation is > done and then when opened again as a single app it's squashed up into 'pos > 0,0' -> Sounds like conflicting remember rules are set up. Please attach kwinrulesrc as well as the dolphirc (you can strip the latter one from stuff like last path and whatever private information might be stored there - only the mainwindow sections and everything that starts by width/height is relevant) Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/36 ------------------------------------------------------------------------ On 2012-01-19T20:25:45+00:00 Hormel wrote: Thomas Lübking wrote: > https://bugs.kde.org/show_bug.cgi?id=15329 > > If it covers Dolphin, Kwrite, Firefox, Gimp and LibreOffice there's indeed a > general (window- or filesystem) issue because they would all work differently > in this regard. <snipped> Thanks indeed for the pointers and info! I'll make some time to get on to this as soon as I can. Regards Mac Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/37 ------------------------------------------------------------------------ On 2012-03-10T15:23:03+00:00 Mgraesslin wrote: I am setting this feature request to WONTFIX as it is not possible to implement such a remember policy with our currently used windowing system. Recognizing a window is a non trivial issue. This might become solvable with Wayland but in general remembering cannot be implemented by a window manager or a windowing system, but has to be requested by the clients. Given that the feature request has been opened more than 10 years ago I consider it as the most honest thing we can do to finally close the request instead of keeping it open in the hope that someday the technical requirements will be available. I want to thank everybody who commented on this report in order to make KDE suit his needs better. This is of course highly appreciated. I am sorry that we have to close this request and cannot present an implementation. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/38 ------------------------------------------------------------------------ On 2012-03-14T22:38:57+00:00 Thomas-luebking wrote: *** Bug 192060 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/39 ------------------------------------------------------------------------ On 2019-08-28T15:26:48+00:00 Nate-b wrote: *** Bug 380799 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/40 ------------------------------------------------------------------------ On 2019-08-28T15:26:56+00:00 Nate-b wrote: *** Bug 384091 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/41 ------------------------------------------------------------------------ On 2019-08-28T15:31:09+00:00 Nate-b wrote: *** Bug 409349 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/42 ------------------------------------------------------------------------ On 2019-08-28T15:31:10+00:00 Nate-b wrote: *** Bug 409338 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/43 ------------------------------------------------------------------------ On 2019-08-28T15:34:59+00:00 Nate-b wrote: Re-opening because a similar bug I filed remained open (Bug 79300). Based on the list of duplicates and votes, It's clear that this is a very highly desired feature by our users and I think we ought to put some effort into trying to make it happen. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/44 ------------------------------------------------------------------------ On 2019-08-28T20:11:17+00:00 Mgraesslin wrote: Sorry, but this is not possible to implement for a window manager. We lack information to identify that a window is the same as previous window. Please see Thomas's comments on that. As Thomas states this is clearly a client job and we can only do something in frameworks for KDE applications. On Wayland we lack the same information and I don't see a possibility to add a spec adding the required functionality as it requires each and every application to change. Even Qt API doesn't provide anything to specify the required functionality. Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase- workspace/+bug/335761/comments/45 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/335761 Title: Placement policy 'Remember' by default for all windows To manage notifications about this bug go to: https://bugs.launchpad.net/kubuntu-default-settings/+bug/335761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
