Hello,
Since my first proposal got no response at all, I thought I'd offer another possible project I'm interested in. I looked a little into the "Implement the Explorer" project idea listed on the Summer of Code page on the wine wiki. I have a few questions as to what parts need to be implemented. Clearly, as stated by the description on the Summer of Code page, we have winefile, which does some of the things expected of explorer, but how far is winefile from a correct explorer implementation? Also would implementing Shell Extensions be a good Summer of Code project? In particular, I think it would be nice to have things like TortiseSVN working in wine.
Thanks -- Jay Yang
Hi Jay,
On Thu, Mar 24, 2011 at 05:16, Jay Yang jkelleyy@gmail.com wrote:
Hello,
Since my first proposal got no response at all, I thought I'd offer another possible project I'm interested in. I looked a little into the "Implement the Explorer" project idea listed on the Summer of Code page on the wine wiki. I have a few questions as to what parts need to be implemented. Clearly, as stated by the description on the Summer of Code page, we have winefile, which does some of the things expected of explorer, but how far is winefile from a correct explorer implementation? Also would implementing Shell Extensions be a good Summer of Code project? In particular, I think it would be nice to have things like TortiseSVN working in wine.
I think winefile is pretty much a dead end as far as "correct" Explorer implementations go. Assuming that we want something as close to the native architecture as possible, the main functionality of the windows explorer lies in libraries ( shell32.dll, explorerframe.dll, ..), used through COM. I did some work in this area last year, which resulted in an implementation of the ExplorerBrowser control (see the documentation for IExplorerBrowser on msdn [1]). I also just now quickly fixed up the proof-of-concept "explorer" I hacked up last year so that it at least compiles on my system (see [2]). It's not beautiful (neither the code nor the interface), but it might give you an idea of what the current state of affairs are. It runs on at least wine and Windows 7, and should also run on Vista.
The code for creating new explorer windows should probably reside in explorerframe.dll, somewhat analogous to how this works for the Internet Explorer and shdocvw.dll.
As for TortoiseSVN I don't dare speak for what others might find useful or how far we are from having that working, but in general there's no lack of things in the shell subsystem that could use some attention. Having explorer implemented and somewhat working would undoubtedly also lead to more of these shortcomings surfacing and hopefully getting some attention.
[1] http://msdn.microsoft.com/en-us/library/bb761909%28v=vs.85%29.aspx [2] http://inget.dyndns.org:9999/wine_explorer/
-- David
On Thu, Mar 24, 2011 at 9:51 AM, David Hedberg david.hedberg@gmail.com wrote:
Hi Jay,
On Thu, Mar 24, 2011 at 05:16, Jay Yang jkelleyy@gmail.com wrote: As for TortoiseSVN I don't dare speak for what others might find useful or how far we are from having that working, but in general
Pretty much a drop in linux replacement for tortoise is RabbitVCS: http://www.rabbitvcs.org/
Hi David,
Thank you for your reply, I was quite busy yesterday so I didn't get around to responding. Thank you for helping clarify the situation with the explorer.
On 03/24/2011 10:51 AM, David Hedberg wrote:
I also just now quickly fixed up the proof-of-concept "explorer" I hacked up last year so that it at least compiles on my system (see [2]). It's not beautiful (neither the code nor the interface), but it might give you an idea of what the current state of affairs are. It runs on at least wine and Windows 7, and should also run on Vista.
Yep, I got it to work after some fiddling with include paths, thanks.
The code for creating new explorer windows should probably reside in explorerframe.dll, somewhat analogous to how this works for the Internet Explorer and shdocvw.dll.
So would implementing explorerframe.dll be a good summer project or is it too large or too small? I haven't been able to find any good documentation on what exactly is implemented by explorerframe.dll, is there any?
Thanks -- Jay Yang
Hi Jay,
On Fri, Mar 25, 2011 at 21:51, Jay Yang jkelleyy@gmail.com wrote:
The code for creating new explorer windows should probably reside in explorerframe.dll, somewhat analogous to how this works for the Internet Explorer and shdocvw.dll.
So would implementing explorerframe.dll be a good summer project or is it too large or too small? I haven't been able to find any good documentation on what exactly is implemented by explorerframe.dll, is there any?
Yeah, lack of documentation might be a problem here. I haven't dug very deep into these parts. In fact it might be the case that it would not be worth the time to attempt to implement this exactly like in Windows at the moment, given both the lack of documentation and - presumably - a lack of applications relying on it.
The obvious parts missing is code for the creation of a frame with navigation controls and an embedded ExplorerBrowser, and then some changes to our explorer to use this code instead of spawning winefile.
As you have probably seen though, neither the wine Explorer Browser control nor the things it relies on are quite full featured, so there's no real lack of things one could work on if the above were to be insufficient for an entire project. Many of the new interfaces introduced in Vista+ are also poorly (or not at all) supported. There's also the issue of supporting shell extensions like you mentioned. I guess it boils down to what you want to accomplish and how much time you think that will take you. :-)
Disclaimer: While I am trying to give a picture of where we're currently at, I might not have much of any actual say in wine's gsoc administration.
-- David
-
David Hedberg -
Jay Yang -
John Klehm