I did some testing myself, currently KDE4 updates a system for each change so it looks like a link, then after changes, the changes (it seems that way) are applied only to one item, but then it appears, that the source item is deleted, and you only see the icon of the source item but there is nothing there.

works fine here. drag n' drop an item from the kmenu to the folderview and it asks if the item should be copied or moved. So, someone already did implement it in trunk :)

p.s. the panel and desktop containments don't deal with files at all, only folderview and kmenu do.

Sebastian -- not to the folder, but _desktop_ or _panel_. Could you please check it (and reopen).

ad.ps) I d&d app, not a file. But now I also tried to d&d file to folder and to desktop. Again -- no questions, and I am afraid that silently the links were made.

Btw. another story -- should links be shown with some visual indicator (panel, desktop). It is hard to guess what I am looking at if all icons look the same.

well, please read my "p.s." note above. E.g. the desktop-containment is not a place any longer to store files cause for that we have the folderview which then can point to e.g. the ~/desktop directory which is then able to take files/directories and there you will be also able to copy/paste/delete/etc. files/directories.

and yes, you can actually just use those folderview as e.g. desktop-containment (well, at least it's planned afaik, not sure if it's already done yet) and then you are able to work with it like at KDE3 (aka using your destop as directory).

Sebastian, 
a) d&d is still possible
b) there is absolutely no indication that link will be done
c) ... the link was done

So how can user know she/he edits not a copy, but the object itself?

and about the design, how this can work with panel? The folderview is overkill. To put some two files on the desktop, I need to create two folderviews. Make two directories, put those files into those directories (distinct) configure folderviews, lock the widgets and still I won't see just icons but rather browsers with icons within.

d) this is not what would user like
e) how can this be done with target audience?


Whatever the design was, not it leads:
a) to complexity -- easy tasks require a lot of work
b) confusion -- because visual indication is not consistent at all

The panel is just like the desktop or the folderview a containment. Just like view the (like some users say) ugly default-theme shipped with 4.0 (and changed to a rather cool new theme in 4.1) this is just what kde ships per default. What your distributor or yourself or kde in the future does make out of it is written down somewhere else.

It will be btw even more interesting in the future if you are also able to drag n' drop content from the web to your desktop or panel or folderview or internetview(?) or your x-ray view (:-) or ...

btw, you don't need 2 folderviews (but you can have 2) since other classic desktops also have only one ;)

Sebastian, I am not against d&d, but d&d should show what will happen. Currently I can only guess -- that's bad. If the link will be made, show little arrow close to the icon, so user can be sure, it is a link.

When I edit properties, show I edit properties of linked object, not a copy.

In short: _inform_ user what is going on.

About FV -- I would like to add two icons, one in left, upper corner, and one in right, bottom corner, how can I do this with just one FV?
I am afraid the we had something very easy, well tested, and after all those years intuitive way of dealing with desktop. Now, KDE4 didn't improve it, KDE4 damaged it while redesigning. Some tasks now are impossible, some are harder (and there are some new ones, true).

> Currently I can only guess
> _inform_ user what is going on.

yes, good argument. Guess it's probably really a bit annoying if someone doesn't know about this. Yet the question is, if it will stay that way taken into account that e.g. the folderview is a brand new thing too (iirc those copy/link-menu is there since a few days only). Anyway, as far as I know it's planned to rework those "context-actions" (aka action-framework or however it was named).

> About FV

yes, it's rather new. Same goes btw for the possibility to don't auto-sort the items by there name. Well, step by step where also your other comment matches;

> Now, KDE4 didn't improve it

I guess you mean KDE 4.1? Well, it did compared to KDE 4.0 and I am sure 4.2 will compared to 4.1. That's the way development (and walking) works. You go step by step rather then being direct at the goal with one step.
If you refer to KDE3, then I would suggest to use KDE3 cause it imho reached it's goal already and is still one of the best desktops around (if not the best cause KDE 4.0 was imho not usuable for productive usage). You are for sure also able to mix them. E.g. run the KDE3-desktop under KDE4 or the other way around. E.g. I have plasma regular running within a KDE3-setup which works very well and at my KDE4-session I usually have also quit a lot of KDE3-apps running. There are really no limits there :-)

The first issue -- should I post a wish? ;-)

KDE4 improvement -- I was comparing it to KDE3. My point is -- easy tasks should be easy :-) It is not good if you say "ah, this is difficult for user to do, because the architecture is complex". And in KDE3 manipulating icons was breeze -- I d&d, it looked nice, I edited it (and only it). Now, it has some frame, it is not an object, so it gives me rather unsecure feeling if I don't break entire system.

The first issue -- I'll better wait, KDE4 currently is unpredictable. After d&d semi-copy is created, I can alter each copy individually but yet, each time whole system is updated. I get back to it when it will be closer to 4.1.

> should I post a wish? ;-)

uhm. see comment #8 "planned to rework" ... maybe we should create a "don't bother" assignment and assign some of the items there?! ;)
But let's look:

> because the architecture is complex

is it? Well, I suggest to look at something like http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/analog-clock/clock.cpp?view=markup and then you will probably note, that it is not. In fact it is now *VERY* easy to extend this KDE to your KDE.

As example your wish at bug #164453 is a good example. See, it is just not needed to implement it within plasma cause of exactly those architecture. You like it? Well, find someone who spends some hours to write a handy plugin that does exactly this. Yes, KDE4 is damn modular and you are able to replace, extend or remove parts very easy without the knowledge about all the internals. You don't like those desktop-containment but like to have e.g. one that displays a directory? no problem, use the folderview as desktop. You like to have a panel that does mac-os like display the applications menu? no problem since they are plugins and e.g. the current panel ( http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/containments/panel/panel.cpp?view=markup ) is with 500 lines of code rather small + it's easy to provide your own implementation that has feature xyz. So, rather then putting every single feature within one e.g. panel, you can have n different panels where each of them can come with another set of features. This doesn't only provide much more freedom at the end cause nobody needs to say "ok, we put that feature into the one panel to the other features" and doesn't only get right of those dialogs with 1001 checkboxes but it also keeps the sourcecode much more cleaner, smaller, better maintainable and therefore more bugfree and last but not least it allows *you* to choose what matches best to you and put the components (aka plugins) together to *your* KDE.

@Maciej:
'
"that icon represents the actual application entry." 
 
 And this is scary
'

look, i am NOT user tech support. i am going to talk in technical terms. and often those are SCARY sounding, from a user's POV.

but they aren't *actually* scary.

in fact, this is doing it the right way, almost exactly as we did it with kicker in fact only with fewer disk read/writes being necessary.

what you're running into are some issues with the properties dialog which aren't really very capable of handling what kicker used to on its own.

either i need to do some work on the properties dialog in kdelibs, or hold its hand a bit more in plasma.

but either way, the way this is working now is precisely how it should be working: it points to an entry in the system configuration cache that represents the .desktop file responsible for describing the installed application.

EOT.

In KDE3 changing icon didn't updated the whole system! In KDE4 it does, this is scary. And in effect is this only one icon is changed (like in KDE3) -- so why updating system?

But I'll wait till KDE4 will more mature, because now I cannot tell clearly is this a design or just bugs.