Hi everybody,
I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop.
None of these should be especially hard, and so would provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved.
As usual no guarantees these patches would be accepted, that's Alexandres call. But they probably would be, and you'll learn something while doing them! :)
Task 1: Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped. See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an explanation of how to do this.
I think it'd be ok to grab $HOME using the UNIX getenv() and then using the libwine APIs to map them to a Win32 path. If the mapping fails (ie $HOME is not accessible given the users dosdevices) then just fail with a WARN().
Task 2: This is similar to above but with some extra work. Map the contents of the ~/Desktop directory to the Windows virtual Desktop folder. In file pickers and Explorer, the filesystem root is represented by a magic Desktop folder. In real Windows this reflects the icons that are on the desktop and is mapped to a real directory at some arbitrary point in the filing system. On Linux we have no such virtual root, however it'd be nice if icons that appeared in the KDE/GNOME desktop were put in their proper place. That way users won't be confused by the file being on their desktop but unavailable from their Windows applications file picker.
This should not be too hard. The Desktop folder is implemented by a COM object in dlls/shell32/shfldr_desktop.c. You just need to read the $HOME/Desktop folder and put the items you find in there inside. Ignore .desktop files for now, they are a bit tricker to map and aren't especially useful for us anyway.
You also want to map CSIDL_DESKTOP in dlls/shell32/shellpath.c, _SHGetDefaultValue. See above.
Bonus points for fixing the desktop icon while you're at it (an arrow??!)
Task 3: The freedesktop.org icon theme specification shows us how to find icons for many different types of thing. Implement support for loading and using the following icons from the icon theme (it should be OK to use native libraries for this like GdkPixbuf, just fall back to the compiled in defaults if it's missing):
- folder - desktop - computer - unknown document
- any others??
Don't do file types, as native icon<->file type association is done by mime types not extensions, and it'd make our file dialogs even slower than they already are.
You may be tempted to use eg, libpng to implement this. Don't! Use GdkPixbuf instead, stock icons are allowed to be in many formats including SVG.
Task 4: Try updating the menu mapping code to support the new XDG menu specification. Don't bother trying to make this work everywhere, it's a total nightmare. Just try supporting the new standards. Be warned: not every desktop/distro supports this yet!
This one might be quite hard.
Task 5: Try improving the winebrowser script to take into account the users preferred applications. At the moment it just tries every browser it knows about in a hard coded order. Hint: in modern GNOME desktops you can use the "gnome-open" program to make this automatic. There is a KDE equivalent.
Task 6: Integrate Wine with XScreensaver, so installing Win32 screensavers makes them automatically appear in the list. You may need to write patches for xscreensaver to make this really slick.
Have fun!
thanks -mike
On Sat, 27 Nov 2004 21:14:33 +0000, Mike Hearn wrote:
You may be tempted to use eg, libpng to implement this. Don't! Use GdkPixbuf instead, stock icons are allowed to be in many formats including SVG.
Actually it's probably easier to use the new GTK+ APIs to implement this, that takes care of not only rendering the image to a raw bitmap you can then convert to an HICON, but it also implements the icon lookup algorithm for you. In future it'll probably also implement some fancy caching mechanism to reduce memory overhead. Might as well get these benefits easily!
thanks -mike
On Saturday 27 November 2004 22:14, Mike Hearn wrote:
Hint: in modern GNOME desktops you can use the "gnome-open" program to make this automatic. There is a KDE equivalent.
In kde the command is 'kfmclient openUrl <url>'.
Hi Mike, --- Mike Hearn mh@codeweavers.com wrote:
Task 1: Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped. See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an explanation of how to do this.
You left the most important thing off the list <g>. I would like to add support to use the draft FreeDesktop trashcan spec. I am working on this a little with one of the ReactOS guys but it will be a while before we have a patch ready.
Thanks Steven
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop.
None of these should be especially hard, and so would provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved.
Another suggestion, probably a bigger task: Look for common native applications and write entries for them into the registry. For example, I manually added an entry for KMail in \Machine\software\clients and now I can select Kmail as the default Mail application in the internet options control panel(Which is created when Internet Explorer is installed). My registry entries look like this:
[Software\Clients\Mail\Kmail] 1100110998 @="KMail"
[Software\Clients\Mail\Kmail\Protocols\MailTo] 1100110998 @="URL:MailTo Protocol" "EditFlags"=hex:02,00,00,00 "URL Protocol"=""
[Software\Clients\Mail\Kmail\Protocols\MailTo\DefaultIcon] 1100110998 @="C:\Program Files\Opera\opera.exe,1"
[Software\Clients\Mail\Kmail\Protocols\MailTo\shell\open\command] 1100110998 @=""Z:\usr\kde\3.3\bin\kmail" "%1""
With Z: mapped to /
I selected KMail as the default Mail application, and when I open an Mail Address in MSIE kmail pops up. The same happens when I enter a maito: address in Task Manager->New task.
Cheers, Stefan
On Sun, 28 Nov 2004 14:18:34 +0100, Stefan Dösinger wrote:
Another suggestion, probably a bigger task: Look for common native applications and write entries for them into the registry.
Yep! Here's another suggestion. Keep them coming guys! :)
- Implement a bridge between the Windows registry and the GNOME/KDE configuration systems. If you set the wallpaper in a Windows app it should reflect on your real desktop. This is useful for programs like the WebShots desktop.
Actually I already have the code for such a "wineshell" program in a local tree, for the system tray integration. I'll see if I can get it submitted soon. We could put all this integration stuff there once it's integrated into Wine.
thanks -mike
On Sun, 28 Nov 2004 15:56:37 +0000, Mike Hearn mh@codeweavers.com wrote:
On Sun, 28 Nov 2004 14:18:34 +0100, Stefan Dösinger wrote:
Another suggestion, probably a bigger task: Look for common native applications and write entries for them into the registry.
Yep! Here's another suggestion. Keep them coming guys! :)
Hi - probably my first comment after lurking here for a few weeks. Is there anything that a user type (I'm not a developer in any sense) can do in this area? I run Windows and have lots of apps I want to run under Wine. I've been entering info as I figue it out in the Wine bug database, but so far that isn't helping me get my programs running. I've wondered a number of times about installing Windows programs under Windows and extracting all of the changed registry entries and then reporting them somehow.
Is this possible?
I'm not sure the apps I want to run are the ones you all would all 'common', but they are common to follks doing audio work. (recording, writing, etc.) In the end would this be helpful?
Thanks, Mark
On Sun, 2004-11-28 at 08:35 -0800, Mark Knecht wrote:
Hi - probably my first comment after lurking here for a few weeks. Is there anything that a user type (I'm not a developer in any sense) can do in this area?
I'm afraid they nearly all involve patching Wine, so not with this set of suggestions no.
I run Windows and have lots of apps I want to run under Wine. I've been entering info as I figue it out in the Wine bug database, but so far that isn't helping me get my programs running.
Right. Unfortunately finding bugs isn't too hard, it's fixing them that's the hard part.
I've wondered a number of times about installing Windows programs under Windows and extracting all of the changed registry entries and then reporting them somehow.
Is this possible?
It is possible. It is unlikely to help in most cases.
I'm not sure the apps I want to run are the ones you all would all 'common', but they are common to follks doing audio work. (recording, writing, etc.) In the end would this be helpful?
Sure, if you figure out how to make apps work feel free to post information somewhere explaining how, or you could write a little script to automate it as has been done with IE.
thanks -mike
Task 4: Try updating the menu mapping code to support the new XDG menu specification. Don't bother trying to make this work everywhere, it's a total nightmare. Just try supporting the new standards. Be warned: not every desktop/distro supports this yet!
This one might be quite hard.
wineshelllink support update-menu which itself build xdg complient menu (via /etc/menu-methos/menu-xdg).
I know mandrake and debian distro use "menu", need confirmation for RH/Novell newest releases.
It would be more elegant to let menu manage gnome/kde/xgd/wmaker ... than reimplementing them in wineshellink . The strongest point is that menu build menu via methods which are tweakable by distro builder. Thus it will avoid to upgrade wineshellink whenever we want ot support gnustep xdg version 12 and the like .
Cheers Alban