Proposal: Enhanced file system navigation for KDE application under Windows

[BRM]

----- Original Message ----

> From: Romain Pokrzywka <romain.pokrzywka at kdab.com>
> 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 (qt5-feedback at qt.nokia.com - 
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