as much as i appreciate your desire to make your feature requests into bugs, that's not how it works ;)

Also something Kickoff/KDE3 did right. :-)

Implemented by revision 808087 in openSUSE Plasma branch (not performance optimized though :-).

Didn't really want to assign this to me (confused by different Bugzilla versions).

*** Bug 155516 has been marked as a duplicate of this bug. ***

Not a feature - indeed it's a bug (unless I really don't understand what one can consider a bug). In any case, I trust that it will be fixed!

Indeed, I filed a plasma bug report (that was taken to be of bad form) complaining about huge CPU use, where the problem was with processes left-over in the background and restarted in new sessions. So, in the interest in not giving KDE4 an undeserved bad name (bloat), the present report should be taken seriously.

I agree.  If the option to restore manually saved sessions exists, then there must be a means for saving the sessions.  Alas, there isn't.  Debating whether this is a feature request vs. bug, in this case, makes no sense to me.  This is clearly a bug.

Stephan, will you backport the Suse fix for this when trunk is 4.2? Thanks in advance!

> Debating whether this is a feature request vs. bug, in this case, makes no
> sense to me.

i completely agree! it's up to the developers who are using bugzilla to plan their development lives to decide which is which. thanks for respecting our attempting to schedule our lives around your issues.

As a workaround you can save your session by typing (in one line)
  dbus-send --dest=org.kde.ksmserver /KSMServer org.kde.KSMServerInterface.saveCurrentSession

Malte, does that work for you? For me KDE restarts with an empty session when I save with dbus and have System Settings restoring this dbus saved session.

You're right, it seems like session saving is broken in Beta2.  I'm pretty sure it worked in Beta1.

BTW:  I just added the apps I want via the Autostart KCM instead of saving a session.  That also has the advantages that you can autostart KDE3 apps (the session manager only remembers the apps base name, not the full path, so if you eg. had Kopete from KDE3 running, the KDE4 version will show up next time).

since the explicit-session-save functionality is already there and advertised, 
this is not just a bug, it is a debilitating one.  it tends to shake user's confidence and convince them that they don't understand how to use the system.

Added some votes for this. Ken Manheimer is asolutely right: you set the option to manually save the session, yet you cannot manually save the session anywhere. I was checking 2, 3 times as well before I concluded I'm not insane. :D

But please, don't just remove the option and then say "there, no more confusion" ;)

*** Bug 167046 has been marked as a duplicate of this bug. ***

Running openSUSE 11 KDE4 Factory (4.0.99...) there is now a Save Session option in the "Leave" kickoff menu tab. So for me, this one is solved.

i don't have this on my mandriva, so this doesn't seems to be on upstream KDE

Save Session still missing on kubuntu with kde 4.1 rc1 (4.0.98; from the http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu repository).  further, in the kde.org 4.1 feature plan:

  http://techbase.kde.org/Schedules/KDE4/4.1_Feature_Plan

i found no mention of desktop session save - not marked as DONE nor TODO nor IN PROGRESS - just not on the map.  nor in the 4.2_Feature_Plan!  maybe i missed it, but if not, this is not a good sign.

Shouldn't 4.1 release include a list of known issues? (such as this one?)

Gilboa: a listing of every feature requested but not implemented?

Aaron,

As other have already noted, the main problem is not the missing feature (save session) but actually the available feature (set session save mode to manual) that causes confusion.
Last night I literally spent hours, feeling like an idiot, trying to find the missing save session button.
Using Google didn't really help, as the first (?) hit was about OpenSUSE that already includes the missing UI.

... Only after an hour of so it has occurred to me to look for bug report in bugs.kde.org and I found this bug.

Release notes, wiki-page, doesn't matter - as long as Google search can find it.

- Gilboa

I added it to the TechBase (thanks Aaron for pointing me to the article):
  http://techbase.kde.org/Schedules/Is_KDE_4.1_for_you#Session_management

Thanks!

- Gilboa

> Gilboa: a listing of every feature requested but not implemented? 

every feature that's advertised or known to work and is not working, should be listed. This feature is clearly one of them.

Session mgmt, as we know it in kde3 or any other DE in the world, is clearly broken in kde4.1.

Adding votes to this one as well.  I wasted a lot of time looking for the save session feature.  Half-implemented, visible to the user, and impossible to use = bug.

It's simply ridicolous marking this as a wishlist whereas it is clearly a last-minute-half-added feature, half-functional or better not functional, as are many features in KDE4 that are not going to be solved through the variuos versions.
Developers should not be able to decide if a missing feature is a wishlist or a bug: as this case suggest they will chose the "wishlist" just because they don't care about the feature. 
We users don't want to plan your developer life, if you prefer to work on some little shining feature rather than on the fundamentals of the system, it's all on you. We don't care. But please don't try to tease us marking this as a whishlist.

I agree with Fabio Puddu and other. This future is a bug, not a wishlist

I agree with Fabio Puddu and other. This is a bug, not a wishlist

Seems to me that, more often than not, these debates fall on deaf ears and that  developers are going to do what developers want to do.  As a long-time users and supporter of KDE, all I can say is that this approach is disappointing.  Case and point - users are quite clear in their votes and comments to this bug that they simply want this fixed.  Whether a feature or bug is somewhat irrelevant.  KDE developers - please listen to your users. :)

ok, i'm going to step in here for a moment because you are whipping each other up into a frenzy that's not going to do anyone any good. what i ask in return is that you all find a way to be calm and professional about it; the alternative is to be removed from the CC's on this bug report so that you aren't part of the conversation.

@Sunil: "Session mgmt, as we know it in kde3 or any other DE in the world, is clearly broken in kde4.1."

the "any other DE in the world" statement is demonstrably false. i invite you to go use gnome if you don't think so, where you will find the true meaning of "clearly broken session management". (they use autostart files to fake session management now)

the only thing missing in kde4 is a GUI that lets you save a session at a given point in time. this is a feature vanishingly few people use, so it has been prioritized behind the features that lots and lots of people use.

so let's please keep hyperbole out of this conversation, because it makes it nearly impossible to have a reasonable conversation about the topic.

@Fabbio: "Developers should not be able to decide if a missing feature is a wishlist or a bug: as this case suggest they will chose the "wishlist" just because they don't care about the feature.

 We users don't want to plan your developer life, "

first you say "developers should not be able to decide" and then you say you don't want to plan our life. 

please don't double talk at me. drop the rhetoric and let's discuss solution. ok?

"if you prefer to work on some little shining feature rather than on the fundamentals of the system, it's all on you."

that is an unfair characterization of the work we've been doing. it borders on insulting.

"We don't care. But please don't try to tease us marking this as a whishlist."

the point is not to tease anyone. the point is for us to be able to categorize things effectively so that we can prioritize things.

fixing bugs in features that are already exposed trump introducing yet more features. stabilize, extend, stabilize, extend, etc..

it has *nothing* to do with managing you as a user and everything with trying to allow the developers to work with effectiveness. while you comment on this report obviously unhappy about this, i have to deal with a few million other people and their needs as well. not an easy job, but we have tools to help make it as efficient as possible.

you're complaining about us using our tools as if it had anything to do with managing you and your expectations. it doesn't.

@Fred Wells: "Seems to me that, more often than not, these debates fall on deaf ears"

and yet time and again we prove that statement wrong through our actions. are you aware that we shelved 90%+ of our plans for plasma to concentrate 4.2 100% on these kinds of issues? the idea was to put a more 60-40 sort of balance in the development plan, weighted towards these kinds of issues.

you have, with this one statement of yours, made me regret terrifically ever bothering to make such an adjustment since obviously it doesn't actually matter to you.

on the other hand, the calmer side of me knows that all the users who did get their pet issues addressed in 4.2 feel otherwise.

why don't you go around to them and negotiate their feature off the table so we take care of yours? good luck and report back when you've accomplished that.

"and that developers are going to do what developers want to do."

which for the last 5 months has been to step aside from our own plans (which, btw, are pretty critical for the future survival of KDE, though i don't expect people in general to understand why or how) and instead focus squarely on yesterday's users. that was what we wanted, that is what we did.

you're making up some false story here about how developers can never have the user's POV in mind or heart. what a sad tack to take.

" As a long-time users and supporter of KDE, all I can say is that this approach is disappointing."

you know what? i feel precisely the same way about your approach in this report.

"Case and point - users are quite clear in their votes and comments to this bug that they simply want this fixed. Whether a feature or bug is somewhat irrelevant."

let's pour some reality on this, shall we? there are hundreds of features users have asked for. some will never get implemented because they don't match the goals or design of things. of the remaining features, this being one of them, they get prioritized according to several metrics.

you're disappointed that your feature hasn't been prioritized higher. does that suck? sure. but life is full of choices and trying to pretend that we, as the workers bringing you this software, never have to make such choices is unrealistic.

we have put into place a huge number of features that users have been requesting, in some cases for years. many of these features were in kde3, many weren't.

"KDE developers - please listen to your users. :)"

a smiley at the end of your sentence doesn't undo any of the bad feelings you've engendered with your, and the rest of the recent commenters here, insulting tirade. i'm not going to hold it against you or this feature, but it's how i feel right now.

community? well, that's not visible here, is it?


so: what about this report indeed? when will we get a GUI for this? probably 4.3. certainly not sooner. in the meantime, may i suggest creating an icon that runs the d-bus command in ksmserver, as noted in the original report?

i'd also request that you put down your proverbial pitchforks and torches because all it does is reinforce the feeling that i don't really want to be working with, let alone for, you. i read every bug report and every comment on every bug report on the software i work on in KDE as they arrive. show some respect for that commitment and try not to drive good people away. a good rule of thumb is whether you'd say whatever you write to my face were we sitting across the table from each other, and i don't think that many of your comments here actually pass that test.

there are other ways of saying what you're thinking and feeling, and so i'm asking that you do just that.

i believe that (1) it is incorrect to call this issue a wishlist item, because that ignores some serious consequences of the problem, and (2) many of the protests here way overshoot, damning the developers and the development process counterproductively.  both of those are problems that hurt kde, and i'm hoping can be reduced.

re (1), while the simple implementation issue is lack of gui hookup of the sessions save feature, the apparent presence of the feature misleads those (apparently, few) people who *do* use it, leading to a lot of frustration for them.  there's no need for that.  if the issue were properly identified as a bug, then it would be more likely that either the presence of the misleading stuff or the absence of the apparently present save-session feature would be rectified.  i have been reluctant to recommend removing the misleading stuff, because it reveals that kde is actually missing gui-exposed session-save, which hurts kde's reputation.  but that's the truth of the matter, at this point, and not calling this a bug obscures that fact.  i know that less harm would be done by identifying that fact clearly than by obscuring it.

re (2), i don't believe that any developer intends ill, or is even negligent, in their concern for user features.  i think that accusations along those lines are equally as or more misguided than calling this issue a wishlist item, misinterpreting their efforts to great insult.  i hope i haven't contributed to that, and am sorry if i have.  i understand that the switch to kde 4 was an enormous effort, for the sake of enormous potential (and now actual!) improvement, and thank all involved.

this is a classic collision of user frustration versus developer issue assessment, where overshoot on the user's part can obscure the actual issue at hand.

i *do* think the harm in terms of confusion and shaken confidence for those that try to use the feature is being disregarded in calling this a wishlist item.  i believe that calling it a bug would give it proper prioritization attention - even if that leads to disabling the session-save gui exposure until the missing "save" functionality is gui-exposed, that would be a big improvement, avoiding the frustration and wasted time and presenting that actual reality of the situation.

if the information about the state of the system is clear and accurate, then the users and developers don't have to get paranoid about controlling one another to get results - choices and actions can be based on info about the system, rather than demands in one direction or the other.

@Ken: first, thanks for the very reasonable response. muchly appreciated.

"i do think the harm in terms of confusion and shaken confidence for those
that try to use the feature is being disregarded in calling this a wishlist
item."

it is not within my reach to fix incorrect assumptions. in this case the assumption that labeling it a "wishlist" item (which actually means "requesting a new feature", which this absolutely is for kickoff or the other launchers in plasma) means the developer are sweeping it under the rug.

that is a flawed assumption.

however, i'm also not going to break a working (for the developers) triaging system as a PR move (managing user expectation). this is a tool for me and my team to get work done, not do marketing or customer care.

"i believe that calling it a bug would give it proper prioritization
attention"

it's receiving exactly the prioritization we, the plasma team, can give it and are willing to give it. wishlist or bug doesn't change our priorities at all.

and yes, i resent the idea of trying to get me to change this to a bug report, when it isn't, as a means to try and subvert our priorities. those priorities are not something we randomly arrive at, but things that are the result of long hours spent with the reports here and subsequent meetings on irc and the mailing lists.

"if the information about the state of the system is clear and accurate"

what's ironic here is that the plasma team is probably one of the most, if not the most, active teams withing kde when it comes to applying process, which includes using the bug tracker system. we engage more than most other projects do and are completely honest about priorities and how we arrive at them.

this system is clear, it is accurate, it just isn't what some people either want or think it is (i think there's a mix of confusion and disappointment at play here). i can't please everyone all the time, but i can make sure that plasma develops properly and sanely.

which it is, if you track the delta between each released version.

i can also try to ensure that as many people get "what they want" as is possible and reasonable.

now, i do think that what is displayed here is users feeling they are entitled to a certain self-defined level of service that has no basis in reality combined with those same users not knowing how else to get closer to what they want ("disempowered", so to speak). so they engage in a very counterproductive means of interaction out of a "back against the wall" perception and nobody wins. worst of all, nobody has put their back against the wall, but they are putting me in a position where i have few choices beyond "give in to a worse process and watch things erode and fall apart" and "deal with it directly and correct the misconceptions"

now, i believe kde ought to have a place for those of you in the bug report to interact in a more appropriate forum about such things. we don't. none of the FOSS projects do to my knowledge, and the commercial entities that do charge insanely for access to that level of service. and i don't see any of these people stepping up to create such a place either. i have been writing a bit recently about supply chain issues, and this is part of it.

but that does not change the bald fact that bugs.kde.org is not the place for such interaction. nor will i not allow it to be abused as a place for it at the expense of my team's productivity, since that ultimately leads to being able to satisfy your needs, desires and even whims.

now, i've already outlined when this issue can be addressed, and included a work-around for it in the meantime.

i think that's pretty clear.

@Aaron
Ok let's discuss this solution as you say.
Here we have a publicized feature (launch saved session in system settings panel) that simply doesn't work, because there isn't a no-terminal way to save the session. Stop. For me that's simply a bug: that panel claims that you're able to do something that actually you're not. No more, no less. In my opinion you have two ways that you could use to solve this bug. The first one is by adding an easy way to save the session. Is this too much complicated and time expensive? There are other priorities? OK. No problem, I don't want to meddle into the order of your priorities.  Then solution number 2. You remove that panel from system settings in the next bugfix release, solving the bug, and *then and only then* you mark this as a whishlist. In that case it would be a correct definition. The feature is not present and there are some users that want that feature. It's very easy.
Marking this thread *now* as a wishlist, seems to me, simply irrespectful of the time we spend in reporting here what doesn't work.
When I say that developers should not be the ones who decide if a problem is a bug or a whishlist, I don't mean to set their priorities. I just mean that the definition is clearly inside the problem itself: something that doesn't work is a bug, something that is not present is a wishlist. And not recognizing this seems to me just a way to underestimate the total number of bugs of the system.

i think you say at the end that this is not the right place to discuss this, but you also say something along the way that mistakes what i was trying to convey.  i'd like to just briefly comment on that, and then i'll let the matter rest.

you say:

> it is not within my reach to fix incorrect assumptions. in this case the
> assumption that labeling it a "wishlist" item (which actually means "requesting
> a new feature", which this absolutely is for kickoff or the other launchers in
> plasma) means the developer are sweeping it under the rug.
>
> that is a flawed assumption.

i did not mean to suggest that anyone is trying to sweep anything under the rug.  i do not believe that to be the case.

what i think is behind the shrill and/or insistent voices, including mine, is a perception - rightly or wrongly - that a nuance of the problem is being missed in your assessment.  in particular, that the presence of gui for restoring a saved session (System Settings / Advanced / Session Manager / "Restore manually saved session") without gui to save the session - or any indication that there are no such gui provisions - is at fault.  while there are workarounds, they do not address specifically the plight of those who are mislead by the "restore" button to believe there is gui for saving.  that is the reason i've been arguing for identifying this as a bug (which i could see addressed, though not optimally, with a note by "Restore manually saved session" clarifying the absence of gui to do the save).

further, your impression that users are merely trying to control and dominate the prioritization for their pet problems may be mistaking frustration at feeling unheard.  even if that feeling is mistaken, it's often behind these kinds of tugs-of-war.  i believe you feel similarly unheard, and that frustration is behind your characterizing my and/or others persistence as attempts to subvert (ie, distort) priorities.  i don't want to subvert anything, and am willing to wait for a fix.  i just didn't believe that the misleading nature of the "restore manually saved" dealie was being recognized.

i also don't want to abuse bugs.kde.org, and didn't realize i was doing so until you mentioned it.  (have you all considered launchpad?  it comes with more facilities, and i believe is available for such projects as kde.)  anyway, i hope i haven't completely used up any welcome, and i'll let the matter drop.

ken

I totally agree with the previous two comments.  As you can see from my comment a few months back, the current state of implementation wasted my time.

It's a bug one way or the other:  Either remove the option to restore a manually saved session, or add an option to manually save a session.  The current, broken, state causes serious confusion for anyone coming from KDE 3.5.  Despite what others have said, I don't think that's a huge minority; everyone I know used it.

It's also not (always) been a case of doing something without the GUI.  The last time I tried (months back) to save a session manually under Kubuntu it didn't work even from the command line.  So, the "restore" option in the GUI was completely unusable.

Wow, what an emotional dialog we've managed to stir.  Thus, I fully retract my obviously unqualified statement that "... developers are going to do what developers want to do."  Or at least its negative implications.  Although, don't we all?  I clearly can't know the prioritization methods used by individual developers.  Perhaps what's really needed is a better mechanism to report on those priorities.  In a vacuum, many of us devoted users tend toward the negative.  I did and I sincerely apologize.  

WRT the feature v. bug debate here, I think I can safely speak for many of us users who assume (maybe falsely) that feature requests naturally take a lower priority to bugs.  Hence the active concern.  Bottom line is that users want this fixed, irrespective of its classification, which was my earlier point.  Simple acknowledgement of the users' wishes here could go a long way. 

In the end I would hope we could direct our time and energies away from this emotionally charged and somewhat fruitless debate and towards the task of correcting this bug (and others).

Finally, let me (re)state clearly that I'm a VERY long time and devoted KDE user and that I fully hope to continue as one.  I can't think of a better way of showing my deep gratitude and appreciation for all of the KDE development community.  :)

I must admit that the turn of events is very disconcerting on both ends.
@bug reporters:
We (as users) seem to forget that in the end, the OSS movement began when one developer decided to scratch its own personal itch.
I'm more-or-less amazed that this bug report doesn't include a -single- patch to disable the semi-implemented feature until the developers find the time to implement the missing UI.
If Aaron would have rejected the patch, then, and only then some of the rough comments made in this bug report would have been warranted.

Aaron, and the rest of the KDE development team don't owe us anything. End of discussion, Period.
Want something fixed - fix it yourself.

@aaron:
Please don't take it as a personal insult (It's not intended as one), but I don't understand you either.
This the third bug report in which I'm seeing the KDE plasma team getting into heated emotional exchanges with users about bug report - most of them simple, easy to solve bugs. A classical bike-shed colour problem.
True, you don't owe us (as users anything), but in the end, it all depends on what are your end goals:
If your are scratching your own personal itch, then feel free to ignore me.
If, on the other hand, you are interested in keeping KDE alive and attracting -testers- (as we all know most users won't bother to report a bug, they'll just switch to a previous version and/or to another DE), then you going at it the wrong way. Yes, you have more important things to do; yes, users and testers can be annoying at times, but without them, KDE 4.x will become the next E17 release. Technologically interesting, but nothing more.

... Though, as I said, you don't really owe us anything, so feel free to ignore me.

- Gilboa

Can we move this conversation to the mailing list or private mail please (Everyone's address is right there...), I'm CC'ed to this bug so I know when there's code changes relating to it, not for arguing. Due to all this spam I've lost time that I could be spending actually doing something useful. The next comment on this bug report under this one must be either a patch file or a SVN hook reply.

Thanks.

re-reported as http://bugs.kde.org/show_bug.cgi?id=176769 

if you wish to be notified of its status, add yourself to the CC list.
if you repeat the performance of this report, 176769 will be closed and i won't be opening a new one for it.

So why do we debate over something that was implemented more then a month ago? ;) 


http://websvn.kde.org/?view=rev&revision=870950
http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/kickoff/core/leavemodel.cpp?annotate=870950&pathrev=870950#l122

I hope everybody, both users, developers and me, the original reporter
 can draw the conclusion now, that the way this was handled was not good at all.