Version: (using KDE Devel) Installed from: Compiled sources METACONTACTS: If I begin to drag a metacontact, I am shown a little metacontact icon following my mouse cursor (GOOD), and my cursor is replaced with an invalid cursor, letting me know that I can't drop it right there (on the metacontact I'm dragging) (GOOD). If I then move over some other metacontacts, the cursor remains invalid (GOOD). When I move over a group, the cursor becomes valid, indicating that I can drop it there (GOOD). Now when I move the cursor over some other metacontacts, or back over the same ones, the cursor stays valid (BAD!!!). If I'm dragging in an upwards directions, SOMETIMES the group name will get a box drawn around it as I drag over it, indicating that I can drop there (BUGGY). If I'm dragging in a downwards direction, a box is never drawn (BAD). CONTACTS: If I start to drag a contact, I see the invalid cursor (GOOD). Once I move off of that specific contact, I never see the invalid cursor again (BAD). Box drawing is iffy, just like for metacontact dragging (BUGGY).
Only the rectangle around the group actually seems to show where the dropped metacontact will be moved to. Allowing a drop on metacontacts in another group is just to ease the move action (think about moving a file in a filemanager, usually you can drop files everywhere if you want to move them into another folder, i.e. you can even drop them on the files _inside_ the folder). Btw, I cannot reproduce the box drawing buggieness on my KDE 3.2.2 laptop-install. Which KDE version are you using?
HEAD from last night, qt-copy + patches. Dropping a file on a file in a folder should try to open the first file USING the second file...which works sometimes (i.e. if you drop a text file onto an editor binary file). Otherwise no... But nonetheless when you return to the original group's metacontacts it does not return no invalid, and I'd greatly prefer that you had to specifically drop it on a group rather than users within that group in this context.
> Dropping a file on a file in a folder should try to open the first file > USING the second file...which works sometimes (i.e. if you drop a text file > onto an editor binary file). Binaries are an exception in that logic, I don't think this applies here (I'd say contacts are like normal files, not like binary files). > But nonetheless when you return to the original group's metacontacts it does > not return no invalid, Yep you are right, the rectangle stays on the last group I moved my mouse over (the one before I moved back onto the original group) but if you drop it onto the original group nothing happens. > and I'd greatly prefer that you had to specifically drop it on a group > rather than users within that group in this context. That's harder to use if you have lots of users online. You will have to scroll the top of the group then. Just dropping it "somewhere" in that group would be easier IMO. Anyway, I don't think that point is the most important one of this bugreport, the rectangle and allow/deny cursor problems are the ones that really need fixing :)
After having used Kopete for years, today I have learned that you can merge contacts into metacontacts by dragging the protocol icon. In Bug 78012 I submitted a wish for automatic merging of contacts into metacontacts, because I knew of no other method than via the RMB menu's. I know some Kopete users who don't know how to use metacontacts, so I submitted the wish in order to allow those users to keep their contact lists clean without having to know the difference between a contact and a metacontact. Now that I found out that you can simply drag contacts into metacontacts, this usability problem is solved. There is one problem though: Users (at least the users I know, including me) never discover the possibility to drag those little protocol icons. The most intuitive thing to try is to drag the metacontact and drop it on top of another metacontact, but that does not work. This action is currently reserved for moving metacontacts to another group. Here is a suggestion to allow merging of contacts into metacontacts by using drag and drop on the metacontacts (not the contacts), while also allowing to move metacontacts between groups in the usual way. Here is what I would like to propose: * Dragging a metacontact from one group to another moves the metacontact from one group to another. * Dragging a metacontact within it's own group will merge the metacontact with the metacontact that it is dropped on. Currently, moving a metacontact within it's own group is not allowed. To prevent the dragging of metacontacts to lead to unexpected results, the user should get live feedback on it's dragging such that he will be able to predict exacly what will happen when he drops the metacontact. I would like to propose the following feedback: * When the user drags metacontacts within the same group: While the metacontact is dragged, the contact list changes in real time to reflect the changes that would be applied when the user would drop the metacontact at that position of the mouse: The metacontact should be temporarily inserted at the mouse position. * When the user drags metacontacts between groups: While the metacontact is dragged, the contact list changes in real time to reflect the changes that would be applied when the user would drop the metacontact at that position of the mouse: The protocol icon(s) of the contact(s) inside the metacontact that is dragged will be temporarily added to the protocol icons of the metacontact below the mousepointer. How about this?
I think a better idea just occurred to me...Dik, let me know what you think of this... I would rather not see the inconsistency between what happens based on which group you happen to drop it in (though your real-time feedback option is good), but there may be another way to have the best of both worlds: When you drop a metacontact onto another metacontact, a popup would appear, and ask you whether you want to move that metacontact into the group you dropped it in, or whether you would like to combine the two metacontacts. There would be a "[ ] Remember my choice" checkbox that you could optionally tick before selecting, so those of us who don't like being bothered with the question over and over again could do away with it, and have it just the way we want.
I think that every problems reported in the original report is is a Q/KListview problem.
Olivier, then why does i.e. listview in KMail work perfectly?
Dik, could you please post your thoughts on Comment #5?
My thoughts om Comment #5: > I would rather not see the inconsistency between what happens based on which group you happen to drop it in (though your real-time feedback option is good), but there may be another way to have the best of both worlds: Inconsistency is in general a bad thing, agreed. It leads to usability problems in most cases. However, I don't think that this case will cause usability problems because of the live feedback. Of course, I may be wrong. > When you drop a metacontact onto another metacontact, a popup would appear, and ask you whether you want to move that metacontact into the group you dropped it in, or whether you would like to combine the two metacontacts. > so those of us who don't like being bothered with the question over and over again could do away with it That would be me.. :) Personally, I'm not a real popup lover. I just want to drag it and drop it, no questions asked. So, I guess I will have to make Kopete remember to do one of both tasks, denying myself the choice at each drag action. So, for me personally, this solution would not change much about the problem, except for that I can choose to merge on drop in stead of move. Maybe I should post both solutions on the Usability list and see what feedback I get?
On Friday 16 July 2004 08:13, Dik Takken wrote: > Maybe I should post both solutions on the Usability list and see what > feedback I get? Sounds like a plan. Be sure to reference this bug and let me know what happens :) I'm not on the usability list presently.
You can find the KDE Usability discussion about this bug here: http://lists.kde.org/?t=109005598700001&r=1&w=2
I hate when we expose two different problems in the same report. the original report is about the fact the cursor is not invalid when it should: this is not a Kopete issue, but a K/QListView problem. I opened the Bug 85700 for it.
(CnP from my kde-usablity post. may as well spam it here too ;) a popup menu would be more consistent with other areas of KMail (e.g. analogous to Copy/Move when DnD'ing files or emails in konqi or kmail). the entries would be: Add %1 to %2 group Add %1 to %3 contact that's a bandaid, however. the REAL problem is that those protocol icons are a mystery to users. what do they mean? what happens when you click on them? if a user has 2 MSN accounts, which butterfly icon is which? a more radical approach would solve this, namely change the layout of the tree to be: Group Metacontact Account 1 Account 2 then dragging would be obvious: dragging INTO a metacontact would add the account(s) to that metacontact. you could even use a nice little "drop line indicator" ala keditbookmarks and kmenuedit. now, before someone says "OMG, that would make my list SO big, and i don't want to have to expand Metacontacts to send messages" i would suggest that the account icons would remain visible as they are right now on metacontacts UNTIL the metacontact is expanded showing the sub accounts. clicking on the metacontact itself would launch a chat window using the same "which is the best account to use" heuristics currently used. one could even show which account that is with a special marking in the expanded metacontact view. default to expanded metacontacts. perhaps provide an easy way to collapse (and expand?) all metacontacts. i'll bet that users would find this mechanism a LOT more obvious. i know from observing kopete users that many/most never figure out those protocol icons. once shown how they work they are pretty blown away =)