Version: (using KDE 4.0.82) I remove label, but the icon is gone D&D konq. app from Kmenu to desktop. Edit its properties. Go to application -> name. Delete it. Confirm. Effect: you deleted name, but the name is kept, you didn't touch icon, but icon is gone.
confirmed with current trunk.
Maciej: this report feels a *lot* like someone going through things and trying everything possible to discover flaws. if this is what you are doing, i'm on the fence as to its usefulness. you are using up a huge amount of our time with this huge volume of bug reports. if you are honestly running into these issues, great. if you are going around doing things like "clear every text field, press Ok, see the results, report bug if it fails in some way ..." then i'm going to ask this of you: please try and keep a record somewhere (perhaps on a page in http://techbase.kde.org/Projects/Plasma/) of these edge cases you run into that aren't exactly life threatening or even the sort of things that people will run into very often if ever under normal usage. these reports are useful in that they show actual flaws that should be fixed, but they are unuseful in that they are sucking up way too much of my (and i assume other's) time triaging them. if you're going to keep up this bug reporting volume, i ask you help us in triaging them rather that using bugs.kde.org as a dumping ground. thank you.
Short story: I use KDE3.5.9 but since KDE4.1 will be available soon, I run it (KDE4) using KDE4Daily and I step by step try to "simulate" fraction of my daily work. So I won't be surprised... If it is more useful for you that I stop till KDE4.1 release, no problem (I just have one issue in mind :-) ). Or I can only focus on issues present in both KDE3.5.9 and in KDE4.
Maciej: I guess the prob is more that you are to successful at discovering problems *g* ... so, it would help us if you prioritize your reports a bit (not stopping them!). So, if it's a minor issue then it's really not that important and we would very likely ignore it anyway cause there are more important things but if it's a bigger issue (specially crashes but imho also this case since it renders the desktop-file invalid which is somewhat a kind of data-lose) then it's *very* great to know about them asap :)
ups, it's NOT datalose since it's only a visual thing and after a restart the label+icon are displayed correct (guess I did test the wrong thing there before, hmmm...). So, it's imho a minor-issue.
I could add keywords in summaries like (minor), (data)? Btw. is the problem (me) applies to whole KDE4 or just plasma (so I can still post reports for other apps freely?). Ad.#5) with KDE4 older version than today the icon was not restored after restart
heh, well, you are free to do whatever you like to do. We just ask you do help us a bit by putting some kind of priority on your reports. See for example bug #164507 which even ends with a question. Now someone would need to spend some time at answering rather then actually solving other issues. Aaron did so and as a result another report got opened... :-/ really, things don't got done faster cause there are more reports but it just takes additional time to handle them and yes, we handle all reports or at least try to do so (and may it only to read the report, reply and close it while providing a reason why we closed it). So, it would be great if you could ask yourself on reporting something if it may a minor issue or if it may even only something that was done for a reason (like not copying the desktop-files around everywhere) and if not sure, then it's a good indicator that the report may not worth the time you and we have to spend with it :) re "keywords"; each report has a priority-field but we don't use it so much as it seems. re "with KDE4 older version than today"; so, it's fixed already, right?
Priorities: I'll try that. Keywords: as a reporter, I cannot use priority fields. No, it is not fixed, I just said the "workaround" didn't work previously.
ah, I didn't know that reports are not able to define the priority. Well, makes sense they are not if I re-think :-)
The name thing is easily solvable. After you update "m_text" do m_icon->setText(m_text) About the icon issue. When you drag an icon to the Desktop, it shows the global .desktop file (installed at /usr/share/applications/foobar.desktop). When you change some data about it, and as you can't write the global file, a local copy is done and modified. However, it seems the new local .desktop file is mostly empty, and one of the lost values was "icon" so it will show the "unknown" icon. (This is a KPropertiesDialog I guess)
I commited the patch to update the IconApplet text; and I sent a review request to fix the icon issue: http://reviewboard.kde.org/r/1390/
*** Bug 208727 has been marked as a duplicate of this bug. ***
This is fixed in KDE SC 4.4. Confirmed here using: Qt: 4.6.0 (kde-qt master commit cd8595efe9aace2afdaa5db37af7cfe82b87e4aa Date: Wed Nov 18 01:33:21 2009 +0100) KDE Development Platform: 4.3.81 (KDE 4.3.81 (KDE 4.4 >= 20091204)) kdelibs svn rev. 1060674 / kdebase svn rev. 1060675 on ArchLinux i686 - Kernel 2.6.31.6