Hi, My situation is as follows. I have a network share with quite a bunch of folders. I want to put some "shortcuts" to that network drive in the places menu. Thus far that works just perfectly. However, i don't want to put it all under "places".. I rather create a new group: My network drive - Share 1 - Share 2 - Share 3 So i was wondering if such a feature would be allowed to be added? What i would do is add a right mouse button entry for the places panel. Right now you have "Add Entry" and i would like add a "Add Group". Cheers, Mark
> So i was wondering if such a feature would be allowed to be added? This isn't really up to Dolphin to decide. Note that the "Places" are provided by kdelibs and shared with the "Open/Save File" dialogs, among others.
We have about 60 bugs/wishes for the places panel in "kfile/kfileplaces". Should we report anyone of them for Dolphin separately? I hope that in the future, those panels share the same code again. Regarding this one, see bug 169751.
(In reply to comment #1) > > So i was wondering if such a feature would be allowed to be added? > > This isn't really up to Dolphin to decide. Note that the "Places" are > provided by kdelibs and shared with the "Open/Save File" dialogs, among > others. It shares 0,0 with KFilePlaces* classes. I checked the includes and the only thing it includes is KFile.. So how can i get this in kdelibs if kdelibs isn't even used? (In reply to comment #2) > We have about 60 bugs/wishes for the places panel in "kfile/kfileplaces". > Should we report anyone of them for Dolphin separately? I hope that in the > future, those panels share the same code again. > > Regarding this one, see bug 169751. Right.. Again Lets continue this discussion and get some code duplication OUT of dolphin instead of in it.. Could you sum up the differences between Dolphin's places implementation and the one in kdelibs? Since i don't know much about it from a technical point of view. Could the kdelibs version be used? If not, what needs to happen to make the kdelibs version fit for dolphin?
(In reply to comment #3) > It shares 0,0 with KFilePlaces* classes. I checked the includes and the only > thing it includes is KFile.. So how can i get this in kdelibs if kdelibs > isn't even used? They share the file where the 'Places' are stored. > > We have about 60 bugs/wishes for the places panel in "kfile/kfileplaces". > > Should we report anyone of them for Dolphin separately? I hope that in the > > future, those panels share the same code again. I hope so too, but then I would prefer that kdelibs/KDE frameworks 5.0 uses more code from Dolphin (which requires the resolution of a couple of issues, most notably the license), rather than the other way around because... > Lets continue this discussion and get some code duplication OUT of dolphin > instead of in it.. Could you sum up the differences between Dolphin's places > implementation and the one in kdelibs? Since i don't know much about it from > a technical point of view. The main difference is that they are based on different model/view implementations - Qt's itemviews (kdelibs) and the Itemviews-NG-based kitemviews (Dolphin). > Could the kdelibs version be used? That would essentially mean to throw away most of the work that Peter put into Dolphin between 4.8 and 4.9. This includes removing features like showing 'Places' and 'Devices' in separate groups and bringing back issues like the automatic resizing (yes, I know that some users liked it, but from my POV, it's a bug).
(In reply to comment #4) > (In reply to comment #3) > > It shares 0,0 with KFilePlaces* classes. I checked the includes and the only > > thing it includes is KFile.. So how can i get this in kdelibs if kdelibs > > isn't even used? > > They share the file where the 'Places' are stored. That's all they share. > > > > We have about 60 bugs/wishes for the places panel in "kfile/kfileplaces". > > > Should we report anyone of them for Dolphin separately? I hope that in the > > > future, those panels share the same code again. > > I hope so too, but then I would prefer that kdelibs/KDE frameworks 5.0 uses > more code from Dolphin (which requires the resolution of a couple of issues, > most notably the license), rather than the other way around because... You're serious.. a license issue _within_ kde? Dolphin and kdelibs are both.. KDE. How can there be a license issue? > > > Lets continue this discussion and get some code duplication OUT of dolphin > > instead of in it.. Could you sum up the differences between Dolphin's places > > implementation and the one in kdelibs? Since i don't know much about it from > > a technical point of view. > > The main difference is that they are based on different model/view > implementations - Qt's itemviews (kdelibs) and the Itemviews-NG-based > kitemviews (Dolphin). Actually, i completely miss a class in kdelibs that puts the bookmarks in a model.. (or i just keep missing it over and over again). So some "glue" code between KBoomarksManager and KFilePlacesModel probably has to be created to make this possible. > > > Could the kdelibs version be used? > > That would essentially mean to throw away most of the work that Peter put > into Dolphin between 4.8 and 4.9. This includes removing features like > showing 'Places' and 'Devices' in separate groups and bringing back issues > like the automatic resizing (yes, I know that some users liked it, but from > my POV, it's a bug). I for one am very glad that the darn automatic resizing is gone :) Now the places panel is actually usable for me. As for the separation between Places and Devices, that should probably be done through KBookmarkManager i guess. It should at least be possible. Even if that's done manually, that's still not a big issue (or a lot of code). So: Yes, you do want to have this feature, but only through kdelibs. For that to happen the current places code has to use KFilePlaces* from kdelibs Which is - not possible due to license issues (really..?) - not possible due to old bugs being reintroduced Thus - KFilePlaces* have to be adjusted to fulfill dolphins needs. Implementing it in kdelibs is not possible because those are features thus only for kde frameworks. Implementing this in dolphin is also a no-go because then dolphin and kdelibs grow apart even further. You know where this is going? Nowhere! Or do you see a solution out of this mess? I want to implement this feature, but i certainly don't want to wait for KF5 to be released since that can easily take well over 1 year or even 2 before that is getting it's first release. This isn't the first time i'm hitting a big snag like this when trying to implement something relatively simple. Others: - Tooltips (needs to go in KF5 or a separate library) - More then 2 shortcuts (needs to go into Qt itself and then it's also KF5 stuff) - and a few i can't even remember anymore.
One more note for auto risizing. It can be turned of! http://api.kde.org/4.9-api/kdelibs-apidocs/kfile/html/classKFilePlacesView.html#ae6a353d79ced51ac078c1d1820139c66 since KDE 4.1 ... I'm guessing Peter didn't know that at the time?
The more i'm diving into this the more i'm beginning to understand why the code is as it is. Since Peter decided to use the itemviews-ng code and heavily modify it, he seemingly also ended up writing his own places panel (all the other panels as well) which is QGraphicsWidget based. The KFilePlaces* stuff is QWidget based. Those don't map 1 on 1. KFilePlacesModel "might" be usable. KFilePlacesItem "might" also be usable, but note that it's a private header file! http://api.kde.org/4.9-api/kdelibs-apidocs/kfile/html/classKFilePlacesItem.html Right now it doesn't look like Peter "forked" KFilePlaces* and friends, but just took some of the usable stuff and combined it with a lot of itemviews-ng. Now that it's somewhat clear (both for me and apparently for you guys as well) why it's implemented as it is. I would like to ask it again: Would this feature be allowed when properly implemented with the knowledge that the full implementation is going to be in Dolphin? @Christoph Feck, yes. The way it is implemented in dolphin does mean that all the feature request you have for KFilePlaces* are likely also feature requests for dolphin due to the structural differences between the two. It might "look" the same, but it certainly isn't.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > It shares 0,0 with KFilePlaces* classes. I checked the includes and the only > > > thing it includes is KFile.. So how can i get this in kdelibs if kdelibs > > > isn't even used? > > > > They share the file where the 'Places' are stored. > > That's all they share. Yes. And if some parts of kdelibs use that very same file to access the 'Places', and they expect that items are not grouped, then Dolphin can obviously not change that file's format on its own. > > I hope so too, but then I would prefer that kdelibs/KDE frameworks 5.0 uses > > more code from Dolphin (which requires the resolution of a couple of issues, > > most notably the license), rather than the other way around because... > > You're serious.. a license issue _within_ kde? Dolphin and kdelibs are > both.. KDE. How can there be a license issue? Yes, I am serious. All code in kdelibs is required to be licensed under the LGPL or an even more permissive license. On the other hand, all code in Dolphin is GPL, which means that no code at all can be moved from Dolphin to kdelibs at the moment. But I will try to change that for the kitemviews/ and panels/places/ directories (Peter already agreed). My plan for KDE Frameworks would then be to write a new "Open/Save File..." dialog which is built around Dolphin's kitemviews and hope that people agree that it can replace the old, Qt itemviews-based implementation.
*** Bug 315129 has been marked as a duplicate of this bug. ***
The wish expressed in this bug will be more or less resolved by https://bugs.kde.org/show_bug.cgi?id=169751 *** This bug has been marked as a duplicate of bug 169751 ***