Beside taking care to keep Dolphin simple and efficient for users, it is also very important for me to do the same for the code: It should be simple and easy to maintain for developers.
Sometimes this works quite well, but it also happens that parts of the code need to be refactored. It is quite common in commercial companies that developers don't get the chance to refactor the code: The user does not recognize it in the first sight and there is definitely a risk of having regressions.
I'm convinced that in the long-term keeping the code base clean pays off and results in less bugs and easier maintenance. Although some features like improved searching or version control support have been added for Dolphin in KDE SC 4.4, I also did some internal cleanups.
For KDE SC 4.5 I want to completely concentrate on fine-tuning the code base of Dolphin, so that some long standing bugs can be fixed in a clean manner:
Information Panel
I totally underestimated the complexity of the Information Panel before KDE SC 4.0 had been released and was never happy with the code-base. I tried to fix things from release to release (which can also be seen visually when looking at the screenshots from the Dolphin-News). Now with KDE SC 4.4 the code-base is a lot better, although there is still some work until it can be moved to kdelibs to get shared with other applications (I blogged about it already in Information Panel and Tooltips). One issue that needs definitely to be solved for KDE SC 4.5 is a non-blocking fallback solution for showing meta information even when Nepomuk and Strigi indexing are turned off (bug 193592). Also fixing the missing meta information in the properties dialog (bug 190588) is a must.Column View
The column view has been added shortly before the feature freeze for KDE SC 4.0. I fell into the trap to assume that showing several columns cannot be much more difficult in comparison to the other views. The result was that the column view added a lot of complexity to the code and fixing column view related bugs was tricky. I cleaned up the code base for KDE SC 4.4 and am quite happy now: A lot of interfaces and workarounds could be removed, less code is needed and fixing column view bugs is straight forward. The beta releases and release candidates popped up some regressions, but they could be fixed quite fast.Location bar ("breadcrumb")
Long before KDE SC 4.0 had been released, the location bar was only meant as prototype. It happened too fast, that we moved it to kdelibs to make it available for the file dialog... It was my fault not taking care to cleanup up the public interface of this widget before KDE SC 4.0 (honestly speaking: There really where more serious problems to solve to that time ;-)). I could not manage to do a cleanup for KDE SC 4.4, but a refactored version is already available on trunk. There are two nice "side effects" of this cleanup:- Dolphin can now easily remember the expansion state of detail-view trees when going back in history (I've to thank Frank Reininghaus a lot for his contributions in this area).
- The Dolphin code could be simplified, as it is very easy now to remember history states.
my_document.tx
t
instead of
my_document.
txt
The searching for Dolphin has already improved in KDE SC 4.4, but still needs a lot of work...
Things like these are what I'd like to fix in Dolphin for KDE SC 4.5, so please don't expect huge, new features :-)
BTW: I'm very happy to announce that on February the 1st I'll start working fulltime at Openismus. Most probably I'll get the chance to work with Qt for Maemo 6 (Harmattan).
16 comments:
Nice. Seriously, really nice. Thanks for the hard work. (: Waiting for the KDE SC 4.5 version.
please, add the bread crumb like navigation for bookmarks like the amarok sidebar for 'Places'
"For KDE SC 4.5 I want to completely concentrate on fine-tuning the code base of Dolphin, so that some long standing bugs can be fixed in a clean manner"
YOU ARE GOD!!!!
I wish more developers had this attitude.
Have you thought about some kind of cache/preloading of Dolphin? It is sometimes slow to open itself.
Except that "error", I think Dolphin is perfect. Thank you!
First of all, thank you very much for your work and for this news. Taking this concious decision to keep the quality as high as possible is sure to be praised.
I wanted to ask you about something which I'm not sure if it's related to Dolphin so please, excuse me if I'm wrong. It's about context menu extensions.
I've installed KDiff 3 and Kdesvn. Both programs install some kind of context menu extension. And this is where inconsistencies across KDE SC start:
- In Dolphin only Kdesvn context menu entries are shown but KDiff 3 are not.
- In Konqueror entries for both programs are shown.
- In KFind, which can be launched from Dolphin, you get entries for BOTH programs when clicking on search results.
- In Plasma's Folder View both programs also get their context menu entries.
- In File Dialogs no special entries are shown (as expected, I guess).
- The new version control support icons and context menu entries are only show in Dolphin and Konqueror but NOT in Folder View, KFind results or File Dialogs. (In contrast, with TortoiseSVN running on Windows, you get its special icons everywhere).
I more or less guess the technical reasons for this behaviour but, in my opinion, this results in inconsistencies from the point of view of the user. I think files should be presented and handled the same across all KDE software (and of course, if this could be done using the same infrastructure, the better).
Anyway, as I said, I don't know if this is Dolphin's responsibility or not.
So, thank you again for your work. I'm already looking forward to KDE SC 4.5. :-)
It would be nice to see in Dolphin "open konsole in this folder" feature of Konqueror.
you can just press F4 to get console in the current dolphin directory
what would be nice is to be able to open pdf and other okular supported docs similar way as the Information panel.
so that one could use the dolhin file browsing of docs on folders and then open them inline should that it would not always open individual okular window.
that should work better on small resolution screens as well (or on future things like ereaders, tablets, CTIs, pads...).
of course that kind of file browser could be implemented on the okular as well, but I think it would make the dolhin pretty nice "document browser" via a pretty small okular-part thingie.
just try to browse doc folder with 100+ docs with either dolhin and okular or okular alone and you can feel the pain. :-)
Is the information panel going to be moved to kdelibs for 4.5? I was hoping to use it for the file name conflict dialog. It is in pretty bad shape right now when it comes to displaying file information in a useful and consistent manner IMO, and I think using the information panel for it would be an efficient way to fix that.
@Peter: can you please reply my email about the file properties? Thanks.
@Pino: When replying to your kde-email address, I get a failure notice with the information that your private email address rejected my e-mail... (SPF Failed - not authorized) How should we proceed?
@Todd: Yes, it is planned that the Information Panel widget gets moved into kdelibs for KDE SC 4.5
@gskbyte: No, I've not considered preloading yet. How long does it take on your system until Dolphin has been started?
@Naproxeno: I'll try to fix such inconsistencies, thanks for the pointers.
@ above anonymous: Why not use konqueror for that, that's what konqueror does better IMHO.
@Raúl: yep, did use the konqueror for exactly that in kde3 era, since moved to the kde4 era the konqueror is not fitting well with my other stuff, so only have the Arora (sure rekonq has the WbKit as well, but that doesn't have the konqueror's file manager stuff in it) as the main browser and of course FF for compatibility emergencies.
the gwenview of course has pretty nice way of browsing on it that would work well for such library browsing, but of course as the codebase is so much different that it would make either dolphin or okular look way too different that idea is out of window.
anywho, was just an 2 cents idea. :-) both okular and dolphin already rule as apps, kudos for all the devs.
Nice to see the code being simplified. As you said, your approach may create regressions, and I thing it did. When I check the property of a file since a few days (trunk), dolphin enter in infinite loop, get a bad memory leak and I have to to be fast at killall -9 before my computer go out of memory.
I have the information pane turned off (no qdockwidget at all, in fact). I also get random freeze with strigi/nepomuk turned off. It's all new bugs, so I just say them like that, no bug report, just a comment in a blog post.
While I am in the "pet my bug" mode, .directory with dolphin info about how to display the current folder does not work with a cifs share mounted by fstab with user uid forced. Directories are just not written to the share. If all that was done using nepomuk, it would not happen. I may submit a GSOC proposal about some of these nepomukitification details.
Make sure you have the Amarok devs sync with your breadcrumb implementation. Their breadcrumb widget reacts to clicks in a different way which creates inconsistency across KDE, for example, clicking on a top-level icon creates a drop-down in Dolphin but immediately navigates to the top in Amarok. Which one is better? I don't know. Perhaps let one of the usability folks run a study.
Post a Comment