Hi All,
From time to time the discussion comes up about having some sort of
Window manager or explorer replacement for when running in Desktop mode. I don't know if a Win9x style desktop is really what we need for running in Desktop mode and after giving it a bit of thought, perhaps enhancing the program manager would be a better fit for us. Like perhaps if you start in Desktop mode then explorer would auto-magically start the program manager for you. I was also thinking that rather than using Windows 3.1 style group menus, we teach Program manager how to read shortcuts and directories in the start menu to use those as programs and program groups. Winefile could also use some loving as well and maybe we could come up with a better way to tie it in to the Program Manager. It seems to me that enhancing both of these programs should take a few months or work and fill out a SoC project nicely. Thoughts?
From time to time the discussion comes up about having some sort of Window manager or explorer replacement for when running in Desktop mode.
Personally, I think enhancing explorer to have its own GUI (rather than launching winefile) would be an interesting project. If nothing else, having a graphical way to explore the shell namespace might be handy for debugging shell issues. From there to an explorer for desktop mode might not be such a big leap.
--Juan
Hasn't someone else somewhere in the world already written an explorer replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel.
-Brian
On Fri, Mar 28, 2008 at 2:18 PM, Juan Lang juan.lang@gmail.com wrote:
From time to time the discussion comes up about having some sort of Window manager or explorer replacement for when running in Desktop mode.
Personally, I think enhancing explorer to have its own GUI (rather than launching winefile) would be an interesting project. If nothing else, having a graphical way to explore the shell namespace might be handy for debugging shell issues. From there to an explorer for desktop mode might not be such a big leap.
--Juan
Hasn't someone else somewhere in the world already written an explorer replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel.
There's the ReactOS one, but it's written in C++. I don't know of any ANSI C ones, but maybe I haven't looked hard enough. --Juan
On Fri, Mar 28, 2008 at 3:40 PM, Juan Lang juan.lang@gmail.com wrote:
Hasn't someone else somewhere in the world already written an explorer replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel.
There's the ReactOS one, but it's written in C++. I don't know of any ANSI C ones, but maybe I haven't looked hard enough. --Juan
http://www.google.com/search?q=windows+explorer+replacement&ie=utf-8&...
List of windows explorer replacements: http://gladiator-antivirus.com/forum/index.php?showtopic=50712&pid=16709...
Here's direct links to a few I found: http://www.xyplorer.com/index.htm http://mustangpeak.net/ http://www.download32.com/directory-opus-i30453.html http://www.explorerxp.com/ http://www.discount-softwares.com/soft/Utility/File_Disk_Management/9079_uni...
There's even an open source one (in visual basic though, bleh) http://sourceforge.net/projects/pc-viewer
http://www.google.com/search?q=windows+explorer+replacement&ie=utf-8&...
Um.. yeah, I've heard of google, thanks. How many are written in ANSI C?
Find me one of those, and I'll retract my suggestion as a SoC project. My suggestion is moot unless someone actually applies to do that though. --Juan
Austin English wrote:
On Fri, Mar 28, 2008 at 3:40 PM, Juan Lang juan.lang@gmail.com wrote:
Hasn't someone else somewhere in the world already written an explorer
replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel.
There's the ReactOS one, but it's written in C++. I don't know of any ANSI C ones, but maybe I haven't looked hard enough. --Juan
http://www.google.com/search?q=windows+explorer+replacement&ie=utf-8&...
List of windows explorer replacements: http://gladiator-antivirus.com/forum/index.php?showtopic=50712&pid=16709...
Here's direct links to a few I found: http://www.xyplorer.com/index.htm http://mustangpeak.net/ http://www.download32.com/directory-opus-i30453.html http://www.explorerxp.com/ http://www.discount-softwares.com/soft/Utility/File_Disk_Management/9079_uni...
There's even an open source one (in visual basic though, bleh) http://sourceforge.net/projects/pc-viewer
It has been asked if any of these are written in ANSI C, how about converting the last one into ANSI C? That would definitely be a mind expanding project, IMHO. I've done language conversion in the past, and would do so now, if I had the available resource, time. Would that be a good GSOC project?
James McKenzie
On Sun, Mar 30, 2008 at 12:11 AM, James McKenzie jjmckenzie51@sprintpcs.com wrote:
It has been asked if any of these are written in ANSI C, how about converting the last one into ANSI C? That would definitely be a mind expanding project, IMHO. I've done language conversion in the past, and would do so now, if I had the available resource, time. Would that be a good GSOC project?
The real problem is most of the work needs to be done in shell32 not explorer. If you look at Thomas Widenmullers explorer-new verses the old ReactOS explorer (which is still default) you'll see that most of windows explorer actually lives there and not enough of the shell namespace and friends is actually implemented. Thats partly another reason I suggested using Program Manager and Winefile. For examples see below. I know linking to ReactOS code is normally not acceptable policy here but both the author of explorer Martin Fuchs and explorer-new Thomas Widenmuller, have contributed quite a bit to Wine in the past and besides, its obvious there is no way in hell they are derived from Windows.
http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/explorer/ http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/explorer-new/
Explorer-new is written in C but it neither works on ReactOS or Wine at this time. I don't think basing our explorer off of a third party shell replacement that duplicated functionality that needs to be reimplemented in shell32 is a good idea.
Hey Juan!
On Fri, Mar 28, 2008 at 4:18 PM, Juan Lang juan.lang@gmail.com wrote:
Personally, I think enhancing explorer to have its own GUI (rather than launching winefile) would be an interesting project. If nothing else, having a graphical way to explore the shell namespace might be handy for debugging shell issues. From there to an explorer for desktop mode might not be such a big leap.
Enhancing our explorer to be a full explorer replacement would be cool with me too, there were just a few reasons I suggested using Program Manager and Winefile rather than trying to extend explorer for the UI
1. Its kind of massive and I don't think we need all of that for desktop mode. I view desktop mode as kind of a corner case that only should be used like 5% of the time. 2. We have winefile and the Program Manager already and both are in really bad shape. They have for the most part bit-rotted in the tree for as long as I can remember. It would be nice to see them polished for Wine 1.0 3. This is just my taste but I don't really like having a Window style explorer bar running in a window. It would make Wine feel more like a VM like environment to me. Maybe we want that for Desktop mode to further try to discourage users from running it, like case 1.
I'd like to see when Desktop mode is invoked, a working Program Manager launch that already has program groups for all of the installed Shortcuts plus existing Winelib applications we ship in the tree. Perhaps even a My Computer group minimized with support for the Shell Namespace builtin and or support for launching winefile with shellnamespace support. I know its a bit of a departure from the normal Windows UI and some may even say using the Program Manager like that is a throwback to Windows 3.1 but it just seems like it would flow better from a UI perspective. Plus it would leverage the code we already have in tree.
All of that being said I don't know if I could mentor such a project anyway, just throwing out ideas. As with everything it really comes down to what Julliard wants.
-
Austin English -
Brian Vincent -
James McKenzie -
Juan Lang -
Steven Edwards