Version: (using Devel) Installed from: Compiled sources There exist no GUI to add additional panels or to remove a panel (including the last one).
do you really think filing a bug report against every possible missing feature you can imagine is a good use of your time, my time or anyone's time? i could spend the next month doing this all over kde. but as a developer, i sort of realize that's not a particularly useful way to spend my time or waste the time of others in triaging. seriously, please try taking this to the devel list, work on the roadmap page so we can merge these in, but don't make me work longer with b.k.o than necessary. it's the LEAST efficient way to do this.
Maybe if both of you were a bit more verbose on the roadmap regarding the features you are going to implement, it would help to not have duplicates in bko. "Panel config" does not really say much on which features are going to be implemented without filing wishes. "Bring back missing Kickoff/KDE3 functionality to Kickoff/KDE4 implementation" does not say anything to users that did not use kickoff in kde3 either.
> "Panel config" does not really say much on which features are going to be > implemented without filing wishes. there's this conception floating about that you need to know what "panel config" means or, perhaps, that i don't know what it means (otherwise why would you need to tell me?). honestly, unless you're going to be coding it ... you don't need to know what's up. if someone out there thinks i don't know what panel configuration options everyone is used to, wants or expects then perhaps they've missed the last few years where i maintained kicker. hell, one of my first major patches to kde was a redesign of the kicker configuration dialog. now i've been considering (and not in a vacuum) what we need to bring to the desktop for a couple of years and it's a hell of a lot better than what 99% of the wishlist entries that have been filed here have so far been asking for. i'd like to get on with it rather than deal with endless requests for duplicating the past. we'll duplicate what makes sense, and we happen to know the difference. if you and i sat down and talked about what's really needed for panel configuration, as the example de jour here, you might just be surprised how wrong we had it in kde3 and how much better it can be. left/right/center? what a joke. so unless you personally plan on writing code for this, these wishlist entries for the bleeding obvious only take up my time, your time and/or whoever triages the BR's time. i don't need nor want wishlists saying "implement this thing we used to have". if you have an idea for something *new* or some other way of utilizing what we have, then please communicate that in the form of a wishlist or an email to panel-devel. p.s. have a look at the version number of plasma. have a chuckle then come back. ;)
> now i've been considering (and not in a vacuum) what we need to bring to > the desktop for a couple of years and it's a hell of a lot better than what > 99% of the wishlist entries that have been filed here have so far been > asking for. i'd like to get on with it rather than deal with endless > requests for duplicating the past. we'll duplicate what makes sense, and we > happen to know the difference. If you do not write it down, i.e. make it transparent, you cannot expect others to read your mind. Hence they either have to just wait and see or file their wishes, because you cannot read their mind either. If you do not complain that people should have told you (discussed it) before, if they only complain after you have already finished your work on panel config, fair enough. Discussing on the ml is not possible if one does not know what you are going to implement and has to assume what is obvious to you or not, what you are going to reject from kde3 and so on. I think it is better to state what one is going to do, get feedback and then implement it, to save your time, because changing it afterwards takes more time than writing "the obvious" down beforehand. Apart from that and since you also mentioned that there are a lot of useless bug reports and wishes, including those duplicating what is obvious to you anyway: If the roadmap would state what you are going to implement and what not, including reasons, you would have saved yourself a lot of time and could just point to the roadmap. Since not everything from kde3 is going to be ported, it is currently a valid question, if a user asks: panel config, does that include xy? I'm not going to bother you with any more discussion about this since I think that this is primarily a communication problem and iterating all over it again and again does not gain anything. If you don't want to spend time on laying out the details I could write down a list of kde3-features for the panel in the roadmap and you simply add comments to those you do not consider worth porting.
> have to just wait and see good idea. > because you cannot read their mind either there is no need to. > Discussing on the ml unless you're going to be involved in the implementation, there is no need to do this either. > changing it afterwards don't worry, it won't be. > If the roadmap would state what you are going to implement and what > not, including reasons, you would have saved yourself a lot of time and could > just point to the roadmap. i *wish*. most people don't read those documents, many who do don't care and file away anyways and honestly: i could sit and write books of material but that doesn't get code written. just back off and let me work. > it is currently a valid question, if a user asks: panel config, does > that include xy no, it isn't a valid question. it's a question that may occur to you, but it's not a valid question for me. to me it's irrelevant. my point in being here is not to molly coddle you into feeling good and nice. somewhere along the line people got this impression that it's my job to do something along the lines of customer support and cooing in a soothing voice. every minute i spend doing that is five i don't spend coding. i'm trying to tell you how i work best, and you seem intent on finding a way around that. good job on helping me slow down. > I could write down a > list of kde3-features for the panel in the roadmap and you simply add > comments to those you do not consider worth porting. the roadmap page is for people putting down what they are actually implementing. please don't abuse it for something else like a "wishlist area somewhere else after we were asked not to do it on b.k.o." moreover, i don't need such a list, it's not going to get you anything sooner (or later) and i really don't get everyone's obsession with having to pester about whether Foo or Bar are going to be there today or tomorrow. when it comes to panel config, write code or back off. if you're looking to write code, i'm happy to discuss. but i'm not going to waste my time (which is really the time you have to wait before the features land) if you aren't. if you wonder why i'm replying to this, it's because i'm going to bookmark this BR and start offering it as my reply to people who come to me with the same questions in the future. it'll save me from having to manually re-iterate it over and over.
A simple GUI implementation versus trunk: http://mattr.info/r/290/
The simple GUI to add (and remove) standard panel has been committed.