Version: 1.9.2 (using KDE 3.96.00 (KDE 4.0 Beta4), compiled sources) Compiler: gcc OS: Linux (x86_64) release 2.6.22-10-generic There seems to be no way that I can tell konsole to use a specific size for all newly started konsoles. I'm using xinerama with 2 screens, where the second is taller then the first. It seems I keep on adjusting the size of newly created konsoles because simply starting one on my smaller screen alters the configuration so the next one I start on my taller screen has to be manually resized to be bigger again. Please allow me to 'save' my setup and never auto-save it without the user actively pressing an Ok button (in a dialog for example).
As an added note; it seems that the directory I'm in is also 'inherited' from the last active one. So if I "cd /" and then create a new shell the new one doesn't start in my homedir, as I expect, it starts in the root dir. This breaks scripts I have; and basically falls under the same rule I wrote in my initial submission that settings should never be autosaved without the user actively ok-ing to that.
> Please allow me to 'save' my setup and never auto-save it > without the user actively pressing an Ok button (in a dialog for example). Konsole uses the geometry saving feature of the KMainWindow class, it doesn't do the geometry management itself. Perhaps the solution here is for KMainWindow to record window geometry on a per-screen basis? > As an added note; it seems that the directory I'm in is > also 'inherited' from the last active one. Yes. There was an RFE bug report with lots of votes which asked for this feature. The exception is that if you start a new session from a specific profile (using the File menu, shortcuts can be assigned from the 'Manage Profiles' dialog) then the initial working directory associated with that profile will be used.
On Friday 16. November 2007 17:06:02 Robert Knight wrote: > > Please allow me to 'save' my setup and never auto-save it > > without the user actively pressing an Ok button (in a dialog for > > example). > > Konsole uses the geometry saving feature of the KMainWindow class, it > doesn't do the geometry management itself. Perhaps the solution here is > for KMainWindow to record window geometry on a per-screen basis? Or, like the kde3 version, not save it unless I ask for saving it? :) > > As an added note; it seems that the directory I'm in is > > also 'inherited' from the last active one. > > Yes. There was an RFE bug report with lots of votes which asked for this > feature. The exception is that if you start a new session from a specific > profile (using the File menu, shortcuts can be assigned from the 'Manage > Profiles' dialog) then the initial working directory associated with that > profile will be used. Yeah, when that gets finished so I can actually set the keyboard shortcuts I guess it will get better. Maybe it would be good to set one profile as a 'default' so using the 'new tab' feature would use that one.
> Or, like the kde3 version, not save it unless I ask for saving it? :) I have had several requests over IRC and at Akademy for Konsole to automatically remember its window size between sessions, and also several bug reports from users complaining that they were unable to figure out how to save changes to the default setup in KDE 3. Making the window size management automatic was intended to make this easier for users and behave like other KDE applications (which also use KMainWindow internally). Presumably this problem affects other KDE applications as well, although Konsole gets used more than they do. Perhaps I should mail to kde-core-devel? > Yeah, when that gets finished so I can actually set the keyboard > shortcuts I guess it will get better. You can do that now. Settings -> Manage Profiles. Click the Shortcut column for the profile that you want to assign a shortcut to and enter the shortcut. There are a couple of known bugs at the moment. The shortcut entering is done using a line-edit rather than the KDE shortcut sequence dialog and the change will not take effect until a new Konsole window is created. > Maybe it would be good to set one profile as a 'default' so using the 'new > tab' feature would use that one. You can do that as well. Settings -> Manage Profiles. Click the profile you want as the default and click "Set as Default". At the moment the "New Tab" action will always duplicate the active session's working directory. It might be useful to have an option for new instances not to inherit the working directory of the previous session. Given the feature/string freeze I'm not sure that I could do this for KDE 4.0 though.
> > Or, like the kde3 version, not save it unless I ask for saving it? :) > > I have had several requests over IRC and at Akademy for Konsole to > automatically remember its window size between sessions, Did you get feedback from people that requested it and actually used it? It sounds great in principle, but it really is horrible and makes me feel like I'm walking on my toes. Every time I resize the window, or worse, when kwin or some konsole app resizes it for me, I have to manually undo that resize some point in the future. It feels like working in an app that has no undo, I have to really think about every action I do since I can get hurt later on. Usecase; I start a konsole and go to my music dir; I then start ogg123 and play some music. I want to make the konsole some 4 lines tall as that is enough to see the current song name, and make it pretty wide to fit all the titles. But doing so will make the next konsole I start loose my preferred size for programming in vim which I spent quite a lot of time making since it makes two konsoles fit perfectly side by side on one monitor. I suggest to use profiles for this instead. > and also > several bug reports from users complaining that they were unable to > figure out how to save changes to the default setup in KDE 3. That makes sense; the only place was the context menu and there was no way to save it from the dialog. If you combine *all* settings in one dialog you win immensely in the findability department. Your solution to make it happen automatically seems to be a bit extreme and ignores valid usecases. I suggest to use profiles for this instead. > Making the window size management automatic was intended to make this > easier for users and behave like other KDE applications (which also use > KMainWindow internally). The big difference between konsole and most other applications is that a konsole is just a front end to any number of other applications. So, whereas using kopete will make you perform the same task every time you use the same window this is not true for konsole. And because konsole can't distinguish between all the different apps a user wants to run in a konsole it should not assume things like that the next time its being used the same size is going to be useful. I suggest to use profiles for this instead. > Presumably this problem affects other KDE applications as well, > although Konsole gets used more than they do. Perhaps I should mail to > kde-core-devel? Sounds more like a usability thing to me... > > Yeah, when that gets finished so I can actually set the keyboard > > shortcuts I guess it will get better. > > You can do that now. Settings -> Manage Profiles. Click the Shortcut > column for the profile that you want to assign a shortcut to and enter > the shortcut. I tried that; I typed "Ctrl+Shift+N", but also "Ctrl-F". Didn't do anything... > > Maybe it would be good to set one profile as a 'default' so using the > > 'new tab' feature would use that one. > > You can do that as well. Settings -> Manage Profiles. Click the > profile you want as the default and click "Set as Default". Also doesn't seem to work; I only have one profile and the 'set as default' is ghosted out. But when I use the 'new tab' menu option it doesn't use this profile. I suggest to make the size a part of the profile so editing the profile and pressing 'ok' there will save the size. Optionally you can add a checkbox for each profile stating the size should always be saved for that specific profile.
> Also doesn't seem to work; I only have one profile and the 'set as > default' is ghosted out. That is because that one profile is the default already. If you create a new profile and select it then it will allow you to set it as the default. If you right-click in an existing terminal session and select "Edit Current Profile" and look at the title of the dialog that pops up, which will give you the name of the profile being used for that session.
> Did you get feedback from people that requested it and actually used it? Everybody who uses Konsole (under KDE 4) will use this feature and I know that is quite a few people. I haven't had any comments or bug reports about it since I originally implemented it - save this one of course. > which I spent quite a lot of time making since it > makes two konsoles fit perfectly side by side on one monitor. In the use case you describe the real problem (as far as I see) is at the window management level because there isn't an easy way to lay a group of windows out in a particular order - each window has to be resized and moved individually (in KWin at least). This is something which I personally would find useful for many other use cases that don't involve the terminal. > Optionally you can add a > checkbox for each profile stating the size should always be saved for > that specific profile. I could do that. Perhaps a checkbox labelled "Remember window size on exit" in the 'Window Options' section of the profile edit dialog. Remembering window size on a per-profile basis is something that could also be done. There is a "--profile" argument which specifies the profile to use in the new Konsole window. For example, if you created two profiles "Vim" and "Music", then: Executing "konsole --profile Music" would not affect the saved geometry for Konsole instances started with "konsole --profile Vim". > I tried that; I typed "Ctrl+Shift+N", but also "Ctrl-F". Didn't do > anything... As I mentioned, there is a bug which will mean that the shortcuts are not created until a new Konsole window is opened. There are also some unenforced rules about combinations of modifier keys that can be used (because most single-modifier shortcuts are reserved for use by terminal programs). Both Ctrl+Shift+[Letter] and Ctrl+Alt+[Letter] should work.
I would really like to be able to have the saved geometry be per-profile. For example, I have certain Konsole profiles that I always use for IRC where I maximize the window. IWBNI the profile could remember that it is always maximized so I could not have to maximize the windows every time I start it up.
> As I mentioned, there is a bug which will mean that the shortcuts are not created until a new Konsole window is opened That incidentally has now been fixed.
Rename the report to make clear that this it the only issue left.
I have been using kde4 for a few weeks. konsole is the application i use the most. It seems every time i start konsole it opens up in a different size, which is very frustrating. I agree fully with the comment that konsole is a gateway to other applications and konsole has a million uses. I use konsole for tons of different tasks. I like the idea of saving a konsole size per profile. That way you can have konsole remember the start up size if the user wants, but also allow other users to specify a starting size for new konsole. I know it's difficult to please everyone, but a start up size in the default profile will please both groups of people. I firmly believe that konsole should start up in a consistent state. As a user, consistency is important.
I found this bug report while looking to file my own. I agree with the comments which state that auto-saving sizes should not be enabled by default. I found this very confusing. On one desktop I like to have on terminal at 80 chars wide, and as tall as the screen allows, wither two other beside the tall one at the standard height. Being as I opened 3 terminals first, then resized one to be taller, every terminal I open now is full height. This is very annoying...
Just after writing this, I tried closing all my terminals, launching one, resizing it, closing it and launching another one. I resized the one to 80x24, but after closing it, the second one I launched came up at 80x7..... resizing that one to 80x24, closing and reopenning, it insists on being 80x7...
Another vote NOT to have auto-saving of konsole sizes. It should be set and saved per-profile and only altered when the user specifically resets it. Auto-saving, without the ability to disable it, takes away the users ability to control this. At the moment I still waste time resizing windows because of this 'feature', but it is now getting to *really* annoy me. John.
I also found this bug report while looking to file my own. I would prefer the old way in KDE 3 - "save current window as default". Maybe there could also be an option - "Save geometry on exit", but I would not be one to use that. I find it extremely annoying that it remembers the window size. In fact, it is so annoying that I started using Konsole from KDE 3 instead because I decided that the KDE 4 version of konsole is almost unusable because of this. I've seen the same bug (feature?) in Dolphin. That is also very annoying. I'll file a report on that as well.
I was looking to file a related report. However, in my case, konsole never remembers it's window size, no matter what I do. A new konsole is always the same size (a size that is too high and not wide enough). When I resize it, it's no way to save the size manually, and apparently it's either not saved on exit or not restored on startup.
I agree with the apparent consensus on this - konsole startup size should configurable. Seems a simple option to toggle on/off auto-size option might work.
Hate to add another "me too" but this is a huge usability problem for me. I open literally hundreds of konsoles per day (some are very short lived and some last for weeks), and I want /every/ /single/ /one/ of them to open with the same size - some I resize to be huge and others small, but I certainly don't want those choices to impact what the /next/ konsole I bring up looks like. Please revert to KDE 3.5 behavior. Please also see bug 181129 which could probably be merged with this one.
Same here. Konsole must not mess with the window size; there are too many console applications which depend on 80 chars per line. Suggested fix: Expand the prefs to say: o Remember last size o Fixed size: XX x XX characters / pixels o Open maximized [] Same size for all profiles
Another "me too" comment. I use most konsoles with the standard 80x24 size. However, in some circumstances, I make some of them bigger (for instance while browsing log files with extra-long lines). That doesn't mean that from then on I want *all* my konsoles to be huge. Now, I constantly am resizing my konsoles to make them small (normal-sized) again. Why can't we get back the previous KDE 3.5 behavior? The thing I really liked in KDE 3.5 was the Settings->Size menu, which proposed not one, but _several_ standard size (40x15 (Small), 80x24 (Vt100), 80x25 (IBM PC), 80x40 (xterm), ..). Really handy for the odd curses-based app that works on 80x25, and _only_ on 80x25 (there's an SNMP client that behaves like that). For me this is one of the issues that has kept me with KDE 3.5 (...and Kubuntu 8.04). KDE 4.x was plagued with lots of these, and distributions (Kubuntu 8.10, Fedora 9) jumped onto the KDE4 bandwagon _way_ too early, giving it a bad rap. As a Beta, KDE 4.0 and KDE 4.1 were fine, but not for day-to-day work. Too many missing features (that were present in 3.5) and glitches to be bundled as the default in a distribution. KDE 4.2 is mostly usable, but this one issue is still present in 4.2 and is a show stopper.
> KDE 4.2 is mostly usable, but this one issue is still present > in 4.2 and is a show stopper. Firstly - I don't mind making it possible for Konsole not to remember the window size or to use a specified fixed size for new windows. It just needs someone to write the code, However, when I came to overhaul Konsole I had a long list of priorities and this wasn't at the top. I felt, and I still do think, that remembering the last used window size is the best behavior for the majority of users (who only have one or two Konsole windows open in a session) - so that got implemented first. That's all there is to it. As far as this being a 'show stopper' goes - I think it is daft if you're being made to choose between two complete desktops based on one feature of one program. Konsole from KDE 3 works under KDE 4 and it really ought to be possible to have both installed at the same time so you can run Konsole/KDE 3 under KDE 4.2. I understand that distributions have a trade-off to make and any effort they invest in keeping KDE 3 apps running is time they could be spending on KDE 4 but I still find it daft that packaging systems make it such a pain to have many versions of the same software installed at once. The other approach, of never removing any feature or option from an application hurts new users at the expense of keeping a (relatively small) number of existing ones happy.
> Firstly - I don't mind making it possible for Konsole not to remember the > window size or to use a specified fixed size for new windows. It just needs > someone to write the code, Ok, so basically, if I understand correctly, this broke due to some underlying libraries changes with KDE, and you just didn't get around to fixing it yet? > However, when I came to overhaul Konsole I had a long list of priorities and > this wasn't at the top. I felt, and I still do think, that remembering the > last used window size is the best behavior for the majority of users (who only > have one or two Konsole windows open in a session) - so that got implemented > first. That's all there is to it. So, if I understand this paragraph correctly, it was _not_ an accident or lack-of-time to adapt to new libraries, but rather a _deliberate_ decision. So, which is it? Or was it a deliberate decision at some point, and then you ran out of time to revert it back? > As far as this being a 'show stopper' goes - I think it is daft if you're > being made to choose between two complete desktops based on one feature of one > program. The thing is, in KDE 4.0 and KDE 4.1, there were loads of other similar issues in other parts of KDE (not possible to add icons to kpanel/plasma, kalendar focus bugs, not possible to define alternate menues, ...). Each one of them taken on its own might not be enough to justify holding back on the switch, but all taken together certainly were/are. On the plus side, most other outstanding issues have been fixed. > Konsole from KDE 3 works under KDE 4 and it really ought to be > possible to have both installed at the same time so you can run Konsole/KDE 3 > under KDE 4.2. It ought to be possible, but in practice, it isn't, unfortunately. On Fedora 10, I get: ./konsole: error while loading shared libraries: libkdeprint.so.4: cannot open shared object file: No such file or directory > I understand that distributions have a trade-off to make and > any effort they invest in keeping KDE 3 apps running is time they could be > spending on KDE 4 but I still find it daft that packaging systems make it such > a pain to have many versions of the same software installed at once. So now, instead they spend so much more time on supporting entire "old" distributions, because people fear to "up"grade. Case in point, Kubuntu committed on keeping 8.04 supported until October 2009, so during this time, they cannot really brush off people who find a problem in a (non KDE) related package that has been fixed in 8.10 or 9.04 . If they had stuck to KDE 3.5 until 4 was really ready, people would have moved along easier, saving them time on supporting obsolete non-KDE related package. > The other approach, of never removing any feature or option from an > application hurts new users at the expense of keeping a (relatively small) > number of This is daft. But fortunately the authors of the other parts of KDE don't seem to agree with you on this. Indeed they are adding back the dropped functionalities, one-by-one. KDE 4.2 is almost there. Among those features that I need, the only missing ones are konsole sizes, virtual desktop labels and alternative menu buttons. The many other issues, (such as icons in the panel, windowlist button, kalendar focus, various display problems...) have fortunately been fixed in 4.2
> So, which is it? Or was it a deliberate decision at some point, > and then you ran out of time to revert it back? Neither. I want the default behavior to be that Konsole, like most other applications, remembers the last used window size. This was a deliberate decision. However, I don't mind having an option to always use a fixed size or remember the last size per-profile since I do see the need for it. I haven't got around to it yet though.
So, there seems to be a consensus here to at least have an *option* to set a default terminal size. Whoohoo... When might we expect to see this?? :) One thing to consider when prioritizing this against other requests is that many of us consider this single missing feature to be one of the most annoying and debilitating of the new KDE4 Konsole. Another thing to ponder is, who the larger konsole user community really is. I would argue it's NOT the typical one-or-two terminal user; rather it's the developer or the system/web administrator, etc. Also, the implied notion by some that all KDE apps should have the same base window behavior is IMO flat out ridiculous. For Konsole to arbitrarily decide on behalf of the user that the size of the last active terminal is the desired size for the next terminal is nonsense, even though this may make perfect sense for something like a Web Browser.
> many of us consider this single missing feature to be one > of the most annoying and debilitating of the new KDE4 Konsole. 'Many' is not a number I can use. I do however consider quantifiable things like the number of votes on a bug report, the number of users CCed to a bug report, the number of duplicate reports and feedback from people who do user support for KDE. > I would argue it's NOT the typical one-or-two terminal user; > rather it's the developer or the system/web administrator, etc. There is no need to speculate, I did a large survey a couple of years ago. You can find a summary of the results at http://websvn.kde.org/trunk/KDE/kdebase/apps/konsole/developer-doc/research/konsole-survey-findings?revision=662161&view=markup
(In reply to comment #23) > > However, I don't mind having an option to always use a fixed size or > remember the last size per-profile since I do see the need for it. I haven't > got around to it yet though. > Sounds good to me.
> I felt, and I still do think, that remembering the > last used window size is the best behavior for the majority of users (who > only have one or two Konsole windows open in a session) - so that got > implemented first. My reasons for being on this bug is that this doesn't work in 80% of my cases: 1. I resize the plasma panel. This sometimes resizes all Konsole windows (makes them take 100% of the width, jump to my second monitor or change the height/position). This issue is tracked by another bug but it makes konsole brittle. 2. I open a new konsole, make it big (so I can see more). When I close this window, I must remember to shrink if before closing or else the next window will be small again. 3. I want to make the console *exactly* 80x25. If I simply resize the window, it doesn't snap to multiples of the font size so all my windows have a slightly different size. Note: This is *my* workflow. If you don't like it, don't use it but it makes using konsole a pain for *me*. And just as you won't change your workflow to please me, I won't change my workflow to please konsole. :)
> Note: This is *my* workflow. If you don't like it, don't use it but it > makes using konsole a pain for *me*. And just as you won't change > your workflow to please me, I won't change my workflow to please konsole. :) Good grief. I have stated a couple of times above that I don't mind having an option for new windows to take on a specified fixed size and I understand why some users want this. There's nothing more to say except to get a patch written.
Created attachment 31667 [details] Adds Save geometry on exit to profile page Here is a very, very quick patch which adds 'Save geometry on exit' to the profile General tab. I'll test it more on the weekend. If anyone can try it, let me know what you think. I'm not positive I like this approach or perhaps there is something better.
Three comments: 1. You replaced ' >' with '>' in the UI XML which makes it hard to see what you actually changed. I suggest to fix the XML formatting in a separate step. 2. The toolTip text is wrong (cut&paste error) 3. What happens if I deselect this field? What size is used when I never save the geometry? Please see comment #19 for a more complete solution.
The functionality I was aiming for in my initial report was that I could save an exact size in any profile. In the profile dialog this would probably mean we have these controls; [X] Remember size [Use Current Size] The checkbox is disabled by default (to match the current behavior) The button is only enabled when the checkbox is enabled and when you press the button it copies the size of the active konsole window to this profile. After pressing 'Ok' in the dialog the next time a session of this type is opened the window is resized to the requested window size.
> Here is a very, very quick patch which adds >'Save geometry on exit' to the profile General tab. <PlainEnglishPolice> I prefer the phrase "window size and position". </PlainEnglishPolice>
Created attachment 31687 [details] Adds 'Save window size and position' to profile Change the profile text and clean up the .ui patch. Konsole will use the default size if there is no size in the config/profile. I do think having 'Save current window size now' and perhaps the suggestion in comment #19 would be a good idea. However, this requires allowing profiles to save their window settings and this is not coded yet. This patch could be at least a first step.
*** Bug 186605 has been marked as a duplicate of this bug. ***
*** Bug 193502 has been marked as a duplicate of this bug. ***
When will this finally be fixed in mainline code? It used to work correctly in KDE 3, so the code to do it should still be out there somewhere. Would it be possible for you to back out that change from CVS? Also, the menu "sizes" in KDE3's konsole, which allowed to quickly pick from a list of several usual sizes was great. We want to have our konsoles open with sane sizes again!
> When will this finally be fixed in mainline code? I don't know is the short answer. Unfortunately one of the drawbacks of volunteer projects is that the developers are sometimes otherwise occupied - having said that, Kurt you're welcome to commit the proposed patch once trunk is unfrozen. > It used to work correctly in KDE 3, so the code to do it should > still be out there somewhere. > Would it be possible for you to back out that change from CVS? The core terminal emulation was ported from KDE 3 but that is all that remains in KDE 4 - everything else is new code.
> Unfortunately one of the drawbacks of > volunteer projects is that the developers are sometimes otherwise occupied To clarify - you don't have to have any previous experience or a KDE svn account to post patches. Anyone is welcome to do that.
I understand that you may not currently have time for working on konsole. I also maintain a couple of packages (udpcast, mtools, ...), and occasionally I have to freeze development on these for longer amounts of time due to other activities (family, job, LUG, ...). However, usually I am careful not to release versions that remove features that were previously taken for granted before going into a longer phase of inactivity. A little bit like (on the job) not doing a deployment on a Friday :-) I think that is where many people on this bug have an issue with. You have the time to break it, but when people wanted it fixed again, suddenly it is "tough luck, that's the drawback of volunteer projects". Is it really not possible to at least roll back the change? KDE3 had a great way of handling sizes: 1. Konsole had a standard size (for example 80x24) which it didn't change on a whim. 2. It had a menu with a list of other common sizes which made it really convenient to pick from, without much of fiddling 3. You could still resize the window with the mouse, without any ill effect on points 1 or 2 Many of us here on the list would be glad if we could get the old behavior back.
I have a question, which rose from this feature/bug: In every other aspect, and for all other applications, kwin has features to implement window/application-specific options such as size, position, fullscreen. I am talking about ALT+F3 -> Advanced -> Special Application Settings. This works fine for every other application. You can force a size, or apply initially a position. Applying a position initially for konsole even works great, but if you apply a size on konsole, it is "ignored" or "overwritten" by the size that was autosaved by konsole. This is clearly not the wanted behavior for anyone using the "special window/application settings" feature of kwin, regardless of the konsole autosave size feature.
(In reply to comment #40) > Applying a position initially for konsole even works great, but if you apply a > size on konsole, it is "ignored" or "overwritten" by the size that was > autosaved by konsole. Edit: It seems that no application honor the "apply initially" setting for size, as they did in kde3. They do honor the size setting when set to "force", but that is not desirable. kwin bug ?
(In reply to comment #41) > It seems that no application honor the "apply initially" setting for > size, as they did in kde3. They do honor the size setting when set to > "force", but that is not desirable. kwin bug ? Don't know. It's working here (4.2.2), even for konsole. That's the workaround I'm using.
(In reply to comment #42) > (In reply to comment #41) > > > It seems that no application honor the "apply initially" setting for > > size, as they did in kde3. They do honor the size setting when set to > > "force", but that is not desirable. kwin bug ? > > Don't know. It's working here (4.2.2), even for konsole. That's the workaround > I'm using. You are correct, I was mislead because it does not work if you maximize the window before closing it. It will remember the maximized state instead. That can be worked around though, since you can also set it to not maximize in the kwin application specific settings.
Tried it here (konsole 4.2.2 on Kubuntu 9.0.4): it allows me to set it (Size, Apply Initially, 665,457), but when I then click OK, and re-enter the Window "Special Applications Settings" dialog, it is again unselected. If I try the same with non-KDE applications (such as firefox), it stays selected. But interestingly enough, it still seems to work, which is good. Just be careful that you don't resize the konsole window which you used for activating this setting. Better close it immediately. From then on, you can resize your other konsole windows without them interfering with the default size.
*** Bug 196397 has been marked as a duplicate of this bug. ***
Given that resizing windows every time you create one is a Big Nuisance, I'd like to advocate that it is a DESIGN BUG. This isn't just a minor nuisance when you spend your whole day futzing with these things. It is also a regression over 3.5. It is a bug. Thank you.
RE: comment #21 ``However, when I came to overhaul Konsole I had a long list of priorities and this wasn't at the top. I felt, and I still do think, that remembering the last used window size is the best behavior for the majority of users (who only have one or two Konsole windows open in a session) - so that got implemented first. That's all there is to it.'' I am willing to take a guess that people who open and close various Konsole sessions all day long were not consulted. This is a behavioral regression. Also in comment #21 is a good clue for the fix: ``Konsole from KDE 3 works under KDE 4 and it really ought to be possible to have both installed at the same time so you can run Konsole/KDE 3 under KDE 4.2.'' Cool. How about shipping Konsole3.5 with KDE 4? I consider the issue a "show stopper", too, were I able to "stop the show." I'm not particularly excited about finding a copy of KDE 3.5's Konsole, ensuring that it was linked against the current libc and installing it properly. We have a serious (not enhancement) issue here that can be resolved by just adding the 3.5 Konsole to the distribution. Below are my initial comments from the duplicate bug I filed: * It used to be the case that geometry was a settable attribute when saving settings. It is a horrible regression that this capability has been disabled. * It should be possible to make an X setting in .Xdefaults: xterm*geometry: 81x105 Doesn't work. * it should be possible to set the geometry in a command line option in the property settings of the Konsole desktop file. Nope, doesn't work either. RE: comment #25: ``'Many' is not a number I can use. I do however consider quantifiable things like the number of votes on a bug report,'' Remember that the people who comment here are a *VERY* rarified group of people who are mostly developer types and sufficiently irritated by the behavior to chase down how to comment about it to the developer in charge. Please consider the votes and comments to be an extremely tiny fraction of the universe of people quite irritated by this. I also looked at your survey. Perhaps I missed it, but it doesn't look like you asked folks about resizing of the Konsole sessions. I think you have your answer for that one now, though.
Well I also suffered from this bug, and agree that this is a regression from the 3.5 version. That being said, my own workaround is to use wmctrl: adding wmctrl -i -r $WINDOWID -e 0,-1,-1,746,434 to my .cshrc gives me a nice 90x21 konsole on startup...
$ type wmctrl bash: type: wmctrl: not found Well, I'm glad you have a solution. It's pretty geeky anyway. I'd sure appreciate a Konsole35. Mr. Robert Knight *please* add this to the KDE 4 distribution. Thank you.
IMO this autosaving of geometries should be removed from KMainWindow altogether! This is simply annoying! No matter if it's about Konsole, Konqueror (a popup and you get postcard sized windows from now on...), Dolphin or what ever app. I also can't follow the argument that it should be easier for new users. There are regular cases where a window needs to be resized from it's default size (which doesn't exist) to accomplish just a single operation, and afterwards you want the default again, but you get tiny, huge or what ever sized windows instead. So working around it in Konsole (please do!) is an option, but no general solution for the problem.
I agree that the automatic resizing is annoying (and a showstopper for me using KDE4, I always want my terminals to start as 80x25). However, in the mean time, the workaround via setting the size initially in kwin does exactly what I want.
To expand on Neil's comment, I found this web-page very useful in figuring out how to actually set the default window size: http://maketecheasier.com/set-special-window-settings-with-kwin/2009/08/03
I agree with comment #50: autosaving the window size is annoying not only in Konsole but in Dolphin as well. I find myself resizing things far more often than I did in Gnome.
Generally I tend to agree that "autosaving window size" is just in the way. Using kwin to set a default window size, as described in the link from Comment #52, does not actually work here (KDE 4.3.0 - "release 158") neither with Konsole nor with Dolphin. Using wmctrl as described in Comment #48 does work with .bashrc and Konsole - but; Using the exact dimensions from Comment #48 (746,434) results in a 90x25 Konsole here. Presumably this is because I use a different font, and/or other window decorations. But it shows that setting the window *size* does not translate directly to some specific lines x chars. While I do use the wmctrl workaround, it's also clearly just that; a workaround. Basically what's needed is the same set of 'preset' geometries as found in Konsole of KDE 3.x - where choosing, say, 80x40 would resize the window to whatever dimensions needed for that. In general I need Konsoles of 80x40 or 80x25 Manually adjusting the size with the mouse is just not feasible in day to day operations, and having to know that "with a screen of 1280x1024, and this particular font, then I need to set the konsole to 666,677 to get 80x40" is just... ridiculous I don't care about the outside dimensions of my Konsoles. What I care about is the lines x chars, and I would love to see a reimplementation of the 'presets' from 3.x
Yet another reason for including Konsole3.5 with KDE 4: Some people (at least me :) use KDE 4 at home (because KDE 3.5 is no longer available) but I have an old distribution at work. (I am not an admin there and could not upgrade the distro even if I wanted to.) Consequence: As everybody knows, nearly every every pull down menu item has found new and much better places in the menu hierarchy and there are not redundant entries in the old places. This means that little things like clearing the history (oops, I mean "clearing the scrollback") have new and much better places that I have to fiddle around to find all the time. For God's sake, *PLEASE* bring back Konsole3.5.
So, where is this protracted debate leading? Is the debate about whether or not Konsole should adopt the standard KDE4 window size management paradigm? The overwhelming consensus here seems to be to restore KDE3 window size functionality to the KDE4 Konsole. Can we expect to see this in a future update? Or, is there still some resistance from the developers on this? If so, what are the stumbling blocks?
> So, where is this protracted debate leading? I am happy for the original request - storing the window size per-profile and not auto-saving the window size on exit to be implemented. I believe the default behavior should stay as it currently is - with Konsole remembering the last used window size on exit. We just need to sort out the best way to do this in the UI. My suggestion would be to add a three-way radio button in the Edit Profile dialog: Window size: [X] Remember the last used window size for this profile [ ] Use a fixed size. [Select Size Button] [ ] rows by [ ] columns [ Use Current Window Size ] Where the user can enter a specific number of rows and columns or pre-fill them by clicking the [Use Current Window Size] button. The other use case mentioned above was changing the size of an existing window to some pre-set. I'm not sure where best to put this without causing confusion between settings which are used for new windows or tabs (currently accessed via Settings -> Edit Current Profile) and settings which are temporary and only take effect in the current tab (such as the Scrollback dialog accessed via Scrollback -> Scrollback Options)
@Fred > So, where is this protracted debate leading? Is the debate about > whether or not Konsole should adopt the standard KDE4 > window size management paradigm? There is no debate really. The short version (which you can read in earlier comments) is that I introduced automatic window size saving into Konsole about 2 years ago following bug reports and people asking me for it at Akademy. Based on the data I have, most users use lots of tabs and a small number of windows so this works well for them. Clearly it does not work for everyone. I said I was okay with adding an option to turn this off and to be able to specify pre-set sizes (in rows and columns) for new windows. Two years later it has not been implemented yet and we have not got a complete patch to solve the problem, though Kurt Hindenburg kindly made a start. For that I apologise.
> I believe the default behavior should stay as it currently is > - with Konsole remembering the last used window size on exit. I believe that the Konsole3.5 should be the default and that it doesn't matter hardly a bit which way you go. What does matter is having readily navigable ways of getting to where most of the posters here want to go: bringing up a Konsole session in a consistently sized window. i.e. not adapting as standard the random size selected by some pop up invocation. Part of my and earlier folks' frustration is that it was more than a little non- obvious that the geometry settings that one found under "settings" migrated to a title bar menu of advanced/special-window-settings/ geometry. A different menu collection with completely different names. How is one supposed to follow that? Once one does learn that "little trick", then this problem degrades to less-than-blocker. The only remaining big irritant is that I use BASH in emacs mode. That mode has used Ctl-B for over 20 years. It has been hijacked for use as "add a bookmark". You wouldn't believe how immense my book mark collection is. I did find settings/configure-shortcuts. As you know, that is a session-only setting, so I have to set it every single time. Even worse than resizing.
> How is one supposed to follow that? The title bar menu is something is something which comes from KDE's window management and is the same in KDE 3 and 4. It is available in every application and not specific to Konsole. It just so happens that it can be used to fulfill the same need. > That mode has used Ctl-B for over 20 years. It has been hijacked > for use as "add a bookmark". This is fixed in the current version of Konsole to use Ctrl+Shift+B instead - definitely in 4.3 and possibly in an earlier version. Configure Shortcuts changes should be permanent but I believe there was a bug which affected only the 'Add Bookmark' action.
Robert, thanks for not letting all this chatter draw the attention away from the actual issue. I think your solution is convenient and solves the problem in a sensible way.
Is there any sign of this bug being fixed?
I think for now, you're supposed to work around it by using a window-specific setting (systemsettings) to apply your custom geometry.
(In reply to comment #63) > I think for now, you're supposed to work around it by using a window-specific > setting (systemsettings) to apply your custom geometry. Unfortunately, that doesn't help if you had konsole maximized before, as konsole will also restore its maximization state :(
You can apply window specific settings to disable the maximized state too.
pinging this bug. This is the single most annoying aspect of KDE 4. Here we are at KDE 4.5 and it is still not fixed. I don't think saving window *position* is appropriate for konsole to do itself, but saving window *dimensions* (size) is appropriate - if that is what the user has requested. gnome-terminal, xterm, rxvt, and every single other terminal I've used don't do this, and the "workaround" is a hack at best. Please add a preference that disables auto-saving. I find the current behavior remarkably counter-intuitive.
It would appear that bug 181129 is very similar, *and* it includes a very recent patch (from Gentoo).
(In reply to comment #67) > ....bug 181129 is very similar, ...[and fixed] That raises an interesting question: That bug was resolved in a year and a half. This one is *three* years old. How is it that saving sizes on a per-profile basis is easier than saying, "STOP SAVING RESIZED SIZES!!!"?
The design in Konsole is to use a mainWindow; which looks suspicious since that behavioral model is different from what I expect for something like Konsole. But its a design that was followed and not easy to refector out. So I don't expect this bug to be fixed until Konsole gets a new and active maintainer. In all honesty I have to say I don't care for this bug anymore because KWin now has the ability to quickly position + size windows the way I want them by dragging them to an edge. I would remove myself from CC except that I'm not on CC list, but I'm the reporter :P
I might be wrong, but although kde is supposed to be OS independent, it is mostly used in linux, that is, under (some variant of) X. The X api states: "Although the layout of windows on a display is controlled by the window manager ... most X programs accept a command line argument of the form -geometry WIDTHxHEIGHT+XOFF+YOFF ... for specifying a preferred size and location for this application's main window." As per `konsole --help-kde` for instance, kde indeed has a --geometry option. Unfortunately, that option is apparently ignored by most kde applications. This is odd: if a user bothers to set that option, it's because he wants it to be used, I am right?
> This is odd: if a user bothers to set that option, > it's because he wants it to be used, I am right? From the user's point of view, that is correct. The --geometry option is provided by the KDE libraries whether the application pays attention to it or not though. The general principle in Konsole is that command-line options take precedence over defaults and options from config files so a patch to make it work is welcome.
Incidentally, Thomas, I did not quite follow your comments about 'mainWindow' but the feature outlined in the original report does not require major refactoring to implement. A patch to implement the --geometry option mentioned in the previous comment would be one way to solve that.
Just a thought, since --geometry is provided by general KDE libraries, should it not be kwin's job to enforce it if the particular application chooses to ignore it?
(In reply to comment #73) > Just a thought, since --geometry is provided by general KDE libraries, should > it not be kwin's job to enforce it if the particular application chooses to > ignore it? No, for two reasons: - Where should kwin get the command line parameters of other processes from? - What if you're using another WM (such as compiz)?
He meant probably "enforced by the KDE libraries" rather than kwin.
Yes, I mean the kde libraries. Seing this bug is close to 3 years old, this is the only hope of seing this fixed in a reasonable time, as it seems konsole is not actively maintained anymore, or is it?
I've been trying the work-around by using the window specific rules setting. I must say that it's not easy to get it to work. Right now I have three separate settings for Konsole, and they still don't catch every window... It's very annoying to have to fiddle for days to get this to work, as it was a very easy setting in KDE 3. I have three "Settings for Konsole". I have no idea what the difference is between the three, but they were all created by selecting "Detect window properties" every time a new konsole window didn't behave. I've selected "use window class (whole application)" on all of them, as well as "Apply Initially" on size (in the geometry tab). As I said, this still doesn't catch all konsole windows.. Every now and then a new window opens with the last used size. Very annoying. :-<
Konsole under KDE 4.6.3 has an option that seems to provide the sticky console geometry size that so many of us prefer. It's in the General tab of configuration profile dialog. It has the rather odd label "Save window size and position on exit." (Exit from what? The configuration dialog or the Konsole window?) Unchecking this box allows me to open fresh 80x25 Konsoles from within an open Konsole of any geometry. Love it!
Cool. Why did it take *FOUR* years for this?
Can the 80x25 be configured? I can't test it myself. I downgraded my Kubuntu from the latest, since my GUI was freezing all the time (Compiz w/ patched Emerald decorator). With 1650x1080 or higher resolutions so common on desktops, I would hardly call such a small window a fix.
The option is in Kubuntu 11.04 with KDE 4.6.2 (Konsole 2.6.2). Yes, the size can be configured. Changing the default size afterwards is cumbersome, though, if logical, involving starting a session, resizing, setting the option, quitting, starting a new session and unsetting the option again. I think this is from the patch submitted by Kurt V. Hindenburg in February 2009. I'm unable to find out when the change was merged. It seems there's another change on the way besides. Look at the entry (by Kurt Hindenburg) on 2011-03-12 in https://projects.kde.org/projects/kde/kdebase/konsole/activity?authenticity_token=dLDx6r5EGOwFGc%2F9EgWZE%2FMJJVQN6t%2FAiRjHJJ7JT9I%3D&from=2011-03-30 This has the description "Revision 0dc1f3b0: Apply local patch which creates an 'Configure Konsole' menu and dialog." Looking at the diff for EditProfileDialog.ui, the string "Set the window size and position for this profile when exiting" is removed. I haven't investigated further. This change appears between the Konsole version updates for 2.6.2 and 2.6.3 (2011-03-01 and 2011-04-09). Reading the slightly more detailed description I have a bad feeling about this change... "Some profile options don't actually belong to profiles. They should be in the main Konsole settings. This is the first step is trying to seperate the options. I only did 1 option for this patch. At some time it may be possible to put the profile dialog inside this main settings dialog." Kurt, please could you comment?
*** Bug 255571 has been marked as a duplicate of this bug. ***
*** Bug 216820 has been marked as a duplicate of this bug. ***
Status update : I have recently added two profile options in the development branch for defining the preferred terminal size. No GUI control is added because those options currently do not always work as expected. To use it, build the latest code from https://projects.kde.org/projects/kde/kde-baseapps/konsole/repository and manully put following lines under the [General] group in your profiles( ~/.kde4/share/apps/konsole/*.profile) TerminalColumns=80(or whatever) TerminalRows=24(or whatever) Then, remove lines like "Height 800=801" and "Width 1280=1281" in ~/.kde4/share/config/konsolerc. Now, start konsole and it should open at the size specified in the default profile. And here is the catch: If konsolerc contains previously saved geometry information like "Height 800=801", those profile options does work. So if you want to use those options, make sure the "save window size and position on exit" option is disabled in each profile. If you want to control the terminal size from command line, you can do it like this: "konsole -p 'TerminalColumns=80;TermisizeColumns=24' ". No dedicated command line options are added. As you can see, this is far from a satisfactory solution. But it should be something useful for those who want/need to control the terminal size in a explicit way.
(In reply to comment #84) > I have recently added two profile options in the development branch for > defining the preferred terminal size. Thank you Jekyll Wu! I tried it and it works for me.
as the original reporter, the feature in kwin to manage the konsole window size makes this one obsolete and frankly, its a fringe feature request anyway. Lets move on :)
Thomas, this bug has over 500 votes, so it is a bit selfish to simply close it just because you are no longer interested in it.
(In reply to comment #86) > as the original reporter, the feature in kwin to manage the konsole window > size makes this one obsolete and frankly, its a fringe feature request > anyway. > Lets move on :) (In reply to comment #86) > as the original reporter, the feature in kwin to manage the konsole window > size makes this one obsolete and frankly, its a fringe feature request > anyway. > Lets move on :) Well, the kwin rule is just a workaround and doesn't solve all problems . There is good need behind the requested feature(s) in this report, although I don't need it(them) myself. So I will just reopen this report before all voters and subscribers start asking "Why close it? ". Thomas, although you are the original reporter, it is not good idea for you to close such a popular report. Just leave that work and the blame to the developers :)
I don't get it, may be I'm just confused. Here the "Save window size and position at exit" does not do what I expect (when I start a new konsole it should have the size of the last one I closed, which is not for me in 4.9.3), so what is that supposed to do? I tried to set TerminalColumns=170 and TerminalRows=50 in the profile file and it does what I want.... may I ask why there is not a GUI option for this, or why the "Save window size and position at exit" has not been replaced with this (since they conflicts if I understand well).
I'd just like to add my support for this to be a proper configuration option. I just want my terminals to be the 80x25 size, and this feature (TerminalColumns, TerminalRows) is undiscoverable right now.
KDE 4.13 code freezes are coming up in next few weeks - if anyone is compiling from source please test https://git.reviewboard.kde.org/r/115628/ Please comment about the GUI options, etc... It has the basic code to allow profile col/row settings. Konsole Settings->Configure Konsole->General->Use current window size on next startup 1. Enabled - ignores all profile size settings - uses previous window size 2. Disabled - profile size settings are used - set via Edit Current Profile 1st tab Only new windows will use "new" col/row/size settings. There are likely situations that are not covered. There is also an issue where the rows is sometimes -1 the expected.
Git commit 931d64df81dd07548a2abecfde65780036ff1fa1 by Kurt Hindenburg. Committed on 15/02/2014 at 15:49. Pushed by hindenburg into branch 'master'. Allow konsole to store terminal size in the profile. This removes the profile setting to 'Save window size upon exit'. Now it is in the Konsole settings; each profile can now set desired column and row size. Konsole Settings->Configure Konsole->General->Use current window size on next startup: Enabled - ignores all profile size settings - uses previous window size Disabled - profile size settings are used - set via Edit Current Profile 1st tab Only new windows will use "new" col/row/size settings. REVIEW: 115628 FIXED-IN: 2.13 M +15 -5 src/EditProfileDialog.cpp M +2 -1 src/EditProfileDialog.h M +113 -24 src/EditProfileDialog.ui M +18 -9 src/MainWindow.cpp M +0 -2 src/MainWindow.h M +0 -2 src/Profile.cpp M +10 -9 src/Profile.h M +0 -2 src/ViewManager.cpp M +0 -1 src/ViewManager.h M +0 -1 src/settings/GeneralSettings.cpp M +6 -3 src/settings/GeneralSettings.ui M +1 -1 src/settings/konsole.kcfg http://commits.kde.org/konsole/931d64df81dd07548a2abecfde65780036ff1fa1
Much appreciated, thank you for this work
Git commit 522e4a57ba6a1eede1142eefd6917314f6f8cd3d by Kurt Hindenburg. Committed on 15/02/2014 at 15:49. Pushed by hindenburg into branch 'frameworks'. Allow konsole to store terminal size in the profile. This removes the profile setting to 'Save window size upon exit'. Now it is in the Konsole settings; each profile can now set desired column and row size. Konsole Settings->Configure Konsole->General->Use current window size on next startup: Enabled - ignores all profile size settings - uses previous window size Disabled - profile size settings are used - set via Edit Current Profile 1st tab Only new windows will use "new" col/row/size settings. REVIEW: 115628 FIXED-IN: 2.13 (cherry picked from commit 931d64df81dd07548a2abecfde65780036ff1fa1) M +15 -5 src/EditProfileDialog.cpp M +2 -1 src/EditProfileDialog.h M +113 -24 src/EditProfileDialog.ui M +18 -9 src/MainWindow.cpp M +0 -2 src/MainWindow.h M +0 -2 src/Profile.cpp M +10 -9 src/Profile.h M +0 -2 src/ViewManager.cpp M +0 -1 src/ViewManager.h M +0 -1 src/settings/GeneralSettings.cpp M +6 -3 src/settings/GeneralSettings.ui M +1 -1 src/settings/konsole.kcfg http://commits.kde.org/konsole/522e4a57ba6a1eede1142eefd6917314f6f8cd3d