User:Mark Gaiser/KDirchainRebuild

From KDE TechBase
Revision as of 12:49, 22 April 2014 by Mark Gaiser (talk | contribs) (Created page with "= Introduction = This all started a few years ago when i was profiling Dolphin. I wasn't happy with it's general performance and was even less happy when it came to massive fo...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

This all started a few years ago when i was profiling Dolphin. I wasn't happy with it's general performance and was even less happy when it came to massive folders. Added to that was the - back then - brand new stuff called "QML". So i wanted to create a file browser that is fast, memory efficient and with a GUI done in QML so that i could add those nifty animations. So i set out to restructure all of the directory handling from KIO from as low UDSEntry till the user facing models. I named that "KDirchainRebuild" since it was rebuilding the chain of events when you open a directory.

That's how it all started a few years ago. Fast forward to today and you see an entirely different landscape. Dolphin is now very fast even on large folders. I didn't make any patches for it, but my initial research in why it was performing poorly was apparently a spark for the Dolphin devs to take a good close look at it and improve it greatly. The biggest thing i did here was investigating how entries where being batched in KIO. That is improved to do real batching which in turn allows an application to show data more quickly to the user. A big thank you here for David Faure since the new batching triggered another weird socket issue that he solved.

So is there still a reason to even consider this "KDirchainRebuild" over the existing classes? Well, yes. The new classes are aimed at simplicity, small memory footprint and being as fast as possible (which sometimes conflicts with simplicity), and - via models - being usable in QML.

Why new classes instead of improving the existing ones?

Initially the idea was to take the current classes, remove all function content and re-implement them in my view. Later i abandoned that idea because there seemed to be quite a few functions that i wanted to handle in a different way along with removing methods altogether. I wasn't really interested in marking a dozen functions as "deprecated". Specially not as long as this project was highly experimental and just for my own pet project. So the choice was easiest to just go for my own class names without the burden of having to re-implement the existing classes.