----- Original Message ---- > From: Romain Pokrzywka <[email protected]> > On Thursday 26 May 2011 14:12:38 Fabian Aichele wrote: > > I've experimented with a very basic implementation of an alternate Qt file > > system engine under Windows that uses the file system access routines of > > the Windows Shell instead of the "ordinary" file system manipulation > > routines that are tailored to deal with "classic" files and folders > > residing on physical media on the local machine. > > > > Essentially, this would enable applications using Qt to navigate the > > complete content of the Explorer namespace, including "virtual folders" > > like the system control panel, but also remote network shares, or basically > > anything that uses ITEMIDLIST data structures to interact with Windows > > Explorer. > > > > As of now, I've mastered the most basic task of actually navigating a > > folder/container hierarchy starting from a given point within the Explorer > > namespace, so I've verified combining Qt's file engine interface and the > > Explorer namespace is possible. > > > > I'd like to ask for some feedback if this is a priority at all for KDE on > > Windows (personally I definitely think it is, and should be), and if > > there's interest in such a piece of software: How closely should I stick to > > the layout that Windows Explorer itself imposes on the file system > > hierarchy? Should I simply replicate it, or has anyone suggestions that I > > haven't come up with yet? > > This can indeed be a nice feature to improve KDE support on windows, good > work >! > > I'm not really familiar about 'Explorer style navigation', but I assumed > that >this basically what you see when you open > > a file explorer. > My main question is: what type of limitations are you talking about when you >write "How closely should I stick to the > > layout that Windows Explorer itself imposes on the file system hierarchy? ". >Is it really different from the "C: > \foo\bar" hierarchy we normally use ? > > Also, does that mean you can get access to things like Libraries on Windows >Vista/7 ? That would indeed be a cool thing > > to have. > > Now regarding your implementation and where things should go, I'm a bit >undecided. On one hand, since this seems to be > > an internal modification of Qt (ie. QFileEngine), I could see it being > merged >upstream into Qt directly, as it is not > > really related to KDE in particular. I'm not sure either if it's even > possible >to have it outside the Qt code (unless > > QFileEngine supports plugins, but it doesn't afaik). However I might just > have >misunderstood the implementation details, > > so don't hesitate to tell me if this isn't correct. > > Then, as far as the browsing is concerned, QDesktopServices has the >storageLocation() method which maps well known > > places to paths. I haven't given it much thoughts yet, but maybe there's >something do be done there too, for example > > adding new standard places. However if those can't be mapped to a real path > on >disk (like libraries), then this wouldn't > > be very helpful. > > All in all, I like the idea, I'm just not sure of how it is implemented and >thus what can be done with it. Maybe you > > could show us an example ? >
I quite agree. I would suggest that this may be a nice thing to add to Qt5, which is doable. I'm going to be putting together a branch to add service/daemon support natively into Qt5 - as opposed to having to install QtService component. So, please join the qt5-feedback list ([email protected] - http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback) and see what people think. There may be a nice place to integrate it into already. My one question is though - how would this work if Plasma were to replace Explorer.exe as the desktop shell? From my understanding that removes a lot of the interfaces provided by MS. $0.02. Ben _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
