Re: winemac: Null-terminate an snprintf-ed key name buffer in case of short buffer.
On Wed, Mar 27, 2013 at 7:22 PM, Ken Thomases k...@codeweavers.com wrote: --- This has probably been discussed before, but shouldn't snprintfW be safe against this kind of thing, the way POSIX snprintf is? Regards, -- Per Johansson
Re: [7/10] winemenubuilder: Create a basic Info.plist.
On Tue, Mar 19, 2013 at 5:57 AM, Ken Thomases k...@codeweavers.com wrote: On Mar 17, 2013, at 12:18 PM, Per Johansson wrote: +namestr = CFStringCreateWithCString(NULL, link_name, CFStringGetSystemEncoding()); You should use CFStringCreateWithFileSystemRepresentation() to create CFStrings from POSIX path strings. Fixed. Thanks, -- Per Johansson
Re: [0/10] Launcher app bundles on OS X
On Mon, Mar 18, 2013 at 9:13 PM, C.W. Betts computer...@hotmail.com wrote: A quick glance at the source revealed that you removed static from some functions. Why? If a function isn't being called outside a source file, it's better to have it be static. This includes functions referenced in structs (but not the structs themselves). Hi, I believe I only removed static where it was needed. Utility functions are kept in winemenubuilder.c, and some of them are referenced from xdg.c and/or appbundler.c. Thus static was removed from those. Regards, -- Per Johansson
Re: [1/3] Make mac driver the default on OS X
On Thu, Mar 7, 2013 at 3:03 PM, Charles Davis cdavi...@gmail.com wrote:
More items can be added to the menus easily enough. However, I'm loathe to
assign the usual keyboard shortcuts. The problem is that the Command key is
used to generate Alt keystrokes and it's relatively likely that a Windows
program will want to receive Alt-H for its menus.
Why aren't we using Option as Alt? Nearly every Mac keyboard labels it as
Alt these days. Is typing characters like 'ü' and 'ø' and '∆' really that
important? :)
Yes, they are. But even more importantly, most of us Europeans also
need it to type [, ], {, }, ~, |, etc. Even @ is option-2 for me.
Regards,
--
Per Johansson
Re: Making wine default to the Mac Driver on OS X
On Mon, Mar 4, 2013 at 8:36 PM, Alexandre Julliard julli...@winehq.org wrote: Ken Thomases k...@codeweavers.com writes: If the concern is what you get when you're ssh'd into a remote system, then it's probably possible for the Mac driver to detect when it doesn't have GUI console access and fail. Then, Wine could fall back to X11. If that can be made to work, it would certainly be a nice solution. The current session type can be queried by the command launchctl managername It'll say Aqua for GUI console and either Background or StandardIO for ssh. It seems to be using a private API to fetch this though: http://www.opensource.apple.com/source/launchd/launchd-442.26.2/support/launchctl.c Regards, -- Per Johansson
Re: Making wine default to the Mac Driver on OS X
On Sat, Mar 2, 2013 at 7:20 PM, Josh DuBois dubo...@codeweavers.com wrote: With Friday's release, I am interested in making the Mac Driver wine's default on OS X. My own immediate motivation is largely so we at CodeWeavers can start testing it as a default internally (which obviously we can do on our own, regardless, if needed), but I figured I'd ask the wider community to see whether it's time in winehq also. Is it really ready yet? As far as I can tell, the OpenGL fixes are not yet committed. My question is how it should be configured from a user perspective. Right now one can set a registry key in HKCU/Software/Wine/Drivers/Graphics with a comma-separated list specifying the driver load order, and the first one successfully loaded will be used. Absent the key, there is a hardcoded load order in user32/driver.c. Right now that is just x11. Discussing with Alexandre the other day I believe his thought is to make the hardcoded default x11,mac in all cases (including Linux). I believe (and I don't mean to put words in his mouth) that his thought is that a user should never have to edit the registry to switch between drivers. The thought would be that in order to switch between drivers, a user must instead create an environment in which all drivers which are ahead of the desired driver in the hardcoded load order will fail to load. I think that in the specific case of x11,mac on an OS X box, the thought was to unset DISPLAY if you want to run with the Mac Driver on, forcing X11 to fail and therefore getting the fallback. I don't think this is a good idea. Consider this case: User is happily using wine with mac driver. User installs XQuartz for reasons unrelated to wine. Suddenly wine is using X11 driver instead of mac driver. User is now unhappy (maybe). I propose an environment variable, WINEDRIVERLOADORDER. I would think we would first use the registry value, then the value of WINEDRIVERLOADORDER, then the hardcoded fallback. I would also propose making the hardcoded fallback differ on OS X and linux, so that a user who does nothing on OS X can have the Mac Driver, but someone who wants X11 can set WINEDRIVERLOADORDER and switch to that without editing the registry. Is that an acceptable approach? I agree that the default on mac should be mac,x11, but I don't really see the reason an override can't be set in registry. Is it just because registry is considered too complicated to modify? I'd suggest making a setting in winecfg in that case. Virtual desktop is already there and has a similarly large impact. Environment variables feel a bit too volatile to be depended upon. Launching from terminal or through desktop very well might have different variables set. If global configuration is needed, it should be through a configuration file, IMO. wine.inf could handle it, except it's overwritten when upgrading. Regards, -- Per Johansson
Re: Compiling Wine on Mac OS X 10.8.2?
On Sun, Feb 3, 2013 at 4:59 PM, Jeremiah Flerchinger jeremiah.flerchin...@gmail.com wrote: Is anyone compiling Wine from the git repository for OS X version 10.8.2? At first I thought I broke my toolchain and could no longer compile Wine at all, but this is not the case. I can still compile old releases, but can no longer compile from git. I'm just curious if anyone else has tried... Hi, the default gcc binary hasn't been able to correctly compile wine since 10.7 was released (since it was then switched to llvm-gcc). clang should be able to compile latest master (since http://source.winehq.org/git/wine.git/commit/c14bdaf1ddb7d0e5587f63f1216b61c9ecb7a8c3). The only other option I'm aware of is gcc-apple-4.2 from macports. Regards, -- Per Johansson
Re: [PATCH 3/6] loader: On Mac, embed Info.plist in (__TEXT, __info_plist) section.
On Mon, Jan 7, 2013 at 4:48 AM, Charles Davis cdavi...@gmail.com wrote: With this, you won't be able to launch Wine from the Finder or with open(1) prior to 10.6. I don't see how you'd do use open or the Finder to launch wine, could you explain more detailed? If you're talking about --args (which I just learnt about), that was also added in 10.6. Regards, -- Per Johansson
Re: [PATCH] winebuild: Use Clang to assemble if its integrated assembler is being used.
On Wed, Jan 2, 2013 at 5:05 PM, André Hentschel n...@dawncrow.de wrote: Not sure if you can do it like that, as i understand it winebuild should always be able to crosscompile something, these ifdefs would destroy that feature. I suppose the correct way is to always use clang without target_alias prefix, but with the proper arch parameter. A combination of this patch and mine for llvm-mc. Either -arch or -Xassembler -triple -Xassembler target_alias Regards, -- Per Johansson
Re: winebuild: Add configure option to use llvm-mc as assembler.
On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis cdavi...@gmail.com wrote: The right thing IMO is to test if we're compiling with Clang. If we are, then we should test if Clang is using its integrated assembler; if it is, then we should invoke Clang instead of the system assembler to assemble. This way, the user doesn't have to pass yet another option to configure in case he's using Clang. I have a patch to hack-fix winebuild to invoke Clang if we're being compiled by Clang; I can fix it to test for Clang and Clang's integrated assembler in configure and send it to the list--something I really should've done a while ago. Sure, sounds like a better plan. I tried briefly to use clang, but there were a lot of undefined symbol errors I wasn't sure how to fix. Tell me if you want some help with the patch. Regards, -- Per Johansson
Re: winebuild: Add configure option to use llvm-mc as assembler.
On Tue, Jan 1, 2013 at 7:11 PM, Per Johansson p...@morth.org wrote: On Tue, Jan 1, 2013 at 6:00 PM, Charles Davis cdavi...@gmail.com wrote: The right thing IMO is to test if we're compiling with Clang. If we are, then we should test if Clang is using its integrated assembler; if it is, then we should invoke Clang instead of the system assembler to assemble. This way, the user doesn't have to pass yet another option to configure in case he's using Clang. I have a patch to hack-fix winebuild to invoke Clang if we're being compiled by Clang; I can fix it to test for Clang and Clang's integrated assembler in configure and send it to the list--something I really should've done a while ago. Sure, sounds like a better plan. I tried briefly to use clang, but there were a lot of undefined symbol errors I wasn't sure how to fix. Tell me if you want some help with the patch. Btw, I should probably add that there's currently no way to build unpatched wine on 10.8 (and probably 10.7), as gcc-apple-4.2 get a conflict about cpu_type_t and pure gcc is not up to date with the latest Objective-C syntax in the system headers. Being able to build with clang would help a lot. Regards, -- Per Johansson
Fwd: [PATCH 3/8] winemac: Implement GetDeviceCaps().
Forgot to include list somehow... On Mon, Dec 17, 2012 at 9:16 PM, Alexandre Julliard julli...@winehq.org wrote: My main reason for using it is to test the Mac builds before pushing commits, so not being able to build the Mac driver on it is a serious problem (and no, it can't be upgraded apparently). I'll let you guys decide on 10.5 or 10.6, but I'd like to note that all intel Mac should be able to run 10.6, as per Apple's website http://support.apple.com/kb/SP575. Regards, -- Per Johansson
Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk madewokh...@gmail.com wrote: I agree that scaling to 32x32 would probably work out better. Personally, I probably would've chosen 128x128, since that would involve no loss of information or distortion (but maybe we don't like the increased file size?). It's however much more common that a 32x32 icon is already present. In fact, checking my own set of wine generated icons, they all already contain a 32x32 icon. Actually, most contain a 48x48 icon as well. I must admit I'm also no expert at image scaling, but presumably scaling twice is much worse than scaling once, right? In that case I'd say we only want to store a 64 - 48 scaled icon only if there's no 128, 256 or 512 size icon available, as those would only be scaled once to produce the final image. I'm not so sure it's a good idea to scale upwards, it's better to let the OS scale down an even larger size in that case, if one is available. It's quite uncommon to have larger icons though, at least in my set. I guess it also depends on what size the OS uses to display the icon. If it will usually be a particular size, we should probably take that into account, though I don't know how much we can really do about it. I don't think it's possible to say that it has a usual display size. Default in the Finder seem to be 64x64, but has probably changed over time. Other applications, e.g. launchpad, has larger ones and the dock is dynamic based on the number of items it contains. Regards, -- Per Johansson
Fwd: [1/3] scrrun: Implement IDictionary_Add and Count (try 2)
On Fri, Oct 12, 2012 at 8:48 AM, Alistair Leslie-Hughes leslie_alist...@hotmail.com wrote: I will have a look at some sort of hash table. I'd use wine existing tree implementation, unless there's some specific reason to use a hash table. Hash tables are good in theory but with in practice trees are just as effective in my experience (especially AVL trees). Regards, -- Per Johansson
Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)
Hi, I should probably add a note that when I wrote this I had some doubts it it belongs in start.exe, and I still somewhat do. The alternative would be to write a new program. The advantage to that is: 1. start.exe is left more similar to it's windows counterpart. 2. This other program could handle multiple files sent in the same AppleEvent, which is possible. 3. The same program could also act as a proxy for a dock icon, handling clicks and activating windows (this is a later project). I'd imagine it'd be called winehostproxy or somesuch and handle several types of interaction with the host (is that what we call it btw?). If you think that's more appropriate I can work on that instead of adding this to start. Regards, -- Per Johansson 2012/9/23 Per Johansson pe...@morth.org 0006-start-Support-getting-the-file-to-open-by-AppleEvent.patch Description: Binary data
Re: [5/6] start: Support getting the file to open by AppleEvent. (resend)
On Tue, Sep 25, 2012 at 10:57 AM, Francois Gouget fgou...@free.fr wrote: On Tue, 25 Sep 2012, Per Johansson wrote: Hi, I should probably add a note that when I wrote this I had some doubts it it belongs in start.exe, and I still somewhat do. The alternative would be to write a new program. The advantage to that is: Start.exe already has a /unix option so adding a /AppleEvent one may make sense. I have two questions though (I apologize if careful reading the patch would answer them). How would this new /AppleEvent option be used? It will be used in file type association scripts created by winemenubuilder (patch 6/6). You won't invoke it manually since it only makes sense if there's an AppleEvent waiting to be delivered. The AppleEvent is sent to an application by OS X when you open a document. Is AppleEvent how they call DDE on Mac OS Xg? Pretty much, details differ but it serves the same function. AppleEvents have existed since 1991 and are pretty much unchanged since then at the API level. Mac OS prefers a single instance of each application and the events are therefore sent by the OS instead of a new instance of the application. This patch only checks for an event at launch, but since it usually immediately exits it's then ready to relaunch and check for another event. Regards, -- Per Johansson
Re: [3/8] winemenubuilder/tests: Added tests for XDG files
19 sep 2012 kl. 23:52 skrev Marvin test...@testbot.winehq.org: Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21661 Hi all, Failure is: xdg.o: In function `func_xdg': /var/lib/winetestbot/build-mingw32/programs/winemenubuilder/tests/../../../../wine-git/programs/winemenubuilder/tests/xdg.c:423: undefined reference to `_setenv' /var/lib/winetestbot/build-mingw32/programs/winemenubuilder/tests/../../../../wine-git/programs/winemenubuilder/tests/xdg.c:424: undefined reference to `_setenv' collect2: ld returned 1 exit status I could use some help resolving that. I tried using SetEnvironmentVariableA already, but then it doesn't work, the changed variable is not found by winemenubuilder. Should I perhaps change winemenubuilder to use GetEnvironmentVariableA instead of getenv, will that work with the normal Unix environment? Regards, -- Per Johansson
Re: [PATCH 3/3] winemenubuilder: Implement OS X application bundles.
24 jul 2012 kl. 17:40 skrev Per Johansson: 0003-winemenubuilder-Implement-OS-X-application-bundles.txt Just noticed I managed to intruduce a typo when removing associations support (the associations init function shouldn't be NULL). Please disregard this for now. Regards, -- Per Johansson
Re: start: Support getting the file to open by AppleEvent.
24 jul 2012 kl. 17:49 skrev Per Johansson: I've also managed to write a function which fetches the AppleEvent using Objective-C, which can be seen here: https://github.com/morth/molae/blob/master/molae.m. I suppose if there's no way to get this file into wine I could make it into a library and check for it in configure. Would that be the most proper approach? Sorry, I googled some and brought myself up to date with the Obj-C discussions in 2009 and 2010. I knew Obj-C is not allowed but I hadn't realized it was such an heated debate. At the risk of bringing it up even more, I don't necessarily think a QuartDriver is necessary, or at least not a primary goal. I would like to see some better integration with the OS X desktop though. The good news is I think I might've found a path through the CoreServices (C API) code which will also fetch the initial AppleEvent. Still investigating... Regards, -- Per Johansson
Re: windowscodecs: Do not assume that vtable is the first element of the object, avoid not necessary casts. Resend.
25 jul 2012 kl. 04:45 skrev Dmitry Timoshkov: I don't have a Mac here, what's the failure there? For the latest one (88611): ccache gcc-apple-4.2 -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DENTRY_PREFIX=WIC_ -DPROXY_DELEGATION -DWINE_REGISTER_DLL -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -I/opt/local/include/freetype2 -I/opt/local/include-g -O2 -o icnsformat.o icnsformat.c icnsformat.c: In function 'IcnsEncoder_CreateNewFrame': icnsformat.c:686: error: 'IcnsEncoder' has no member named 'encoder' icnsformat.c:686: error: 'IcnsEncoder' has no member named 'encoder' Regards, -- Per Johansson
Re: start: Support getting the file to open by AppleEvent.
19 jul 2012 kl. 20:00 skrev Per Johansson: 19 jul 2012 kl. 18:11 skrev Alexandre Julliard julli...@winehq.org: You really don't want to do that. Alright, but like I said earlier there's really no other good way to support associations without using Objective-C. I'll send a new version without associations support in a few days. I've sent in a new series without associations support, so this one can be discarded (noticed it's still in new status). I've also managed to write a function which fetches the AppleEvent using Objective-C, which can be seen here: https://github.com/morth/molae/blob/master/molae.m. I suppose if there's no way to get this file into wine I could make it into a library and check for it in configure. Would that be the most proper approach? Regrads, -- Per Johansson
Re: start: Support getting the file to open by AppleEvent.
19 jul 2012 kl. 18:11 skrev Alexandre Julliard julli...@winehq.org: Per Johansson pe...@morth.org writes: Uses a private API. You really don't want to do that. Alright, but like I said earlier there's really no other good way to support associations without using Objective-C. I'll send a new version without associations support in a few days.
App bundle patches for OS X
Hi, I think I've reached a committable stage for the application bundle code I took over from Steven Edwards last summer. But there are some controversial parts so I figured I'd ask the list first. The patch extracts all XDG specific parts of winemenubuilder into a separate file, and there is also a new file for app bundles. Which one is used is controlled by a dispatch table and is choosable in the registry. The new code reacts to the same events but instead of a .desktop file an app bundle is created, start menu is replicated at ~/Applications/Wine/. Associations are handled by modifying start.exe to make it able to receive the file to open using AppleEvent, and an app bundle execing start.exe is put in ~/Library/Wine/Associations/. The actual file name contains the associated extension but the display name is modified to be the application that will be launched. It should work out of the box, after you've installed this patch and run winemenubuilder -a you should be able to right click a text file and choose Open with notepad (there's a cache involved as well so you might also need to remove the wine fileassociations key in the registry). Commits can be found at https://github.com/morth/wine/commits/appbundle-proper (original commits are on the master branch). The major controversity is in the start.exe code (commit https://github.com/morth/wine/commit/ec68ac2b2abc0a1d4559eb5490b1f12b21000e59). It uses a private API to access the AppleEvent containing the file to open. I choose this way because: 1. The only official way to access this information is by using Objective-C, building a proper Mac application. 2. Another option was to use the deprecated Carbon, but would also take a lot of code to finish. IMO neither of the two are good options, which leaves either doing it this way or to ask Apple to open up the API. Unfortunately I don't think Apple will respond quickly to such a request. Now that 10.8 is close (maybe even GMed) it's very unlikely to happen before 10.9, and perhaps not even then without backing from a major developer (I suppose the wine project might count as a such). I've made sure to check with configure if the functions exist before calling, but it is of course not safe in case they change the signature. OTOH, I don't think that is overly likely to happen. Another thing to note is that the app bundle script will copy some environment variables when created (commit https://github.com/morth/wine/commit/58773927eb7da431ba47923d66768cd129e4daffgenerate_bundle_script function). The ones copied are: PATH, DYLD_FALLBACK_LIBRARY_PATH and WINEPREFIX. DYLD_FALLBACK_LIBRARY_PATH is needed or wine won't work much at all. PATH is copied because the default one is only /bin and /usr/bin, and on OS X wine is rarely in one of those locations but rather installed with MacPorts of fink or similar, which use non-default paths. Anyway, if I don't hear anything from the list I'll likely send in the commits. I suppose that will be a second chance to review them. Once again I'd like to mention that Steven Edwards did a major part of this code, thanks goes to him and also to the wine project as a whole, I really enjoy using it. Finally, I only work on this code once every few months or so, so if it's deemed that there's too many problems, anyone should feel free to pick up this code and make it done (it'd be nice if you notified me though). Regards, -- Per Johansson
Re: WineHQ database compromise
On Tue, Oct 11, 2011 at 9:13 PM, Jeremy White jwh...@codeweavers.comwrote: Hi, I am sad to say that there was a compromise of the WineHQ database system. snip Hi, one question. I'm not worried about my current account, but I had an old email with an old password recorded in my keychain store. I tried that email at appdb.winehq.org but it said user does not exist. Can I assume it was completely deleted? Regards, -- Per Johansson
Re: IPv6 issue on TestBot?
22 sep 2011 kl. 12:14 skrev Michael Stefaniuc: Wow! /66? And that works? While the standard allows for that you should use /64 which everybody and his dog read it as that is the only thing that needs to work and the only thing that get tested. IPv6 brings back the class-full thinking which everybody has to painfully unlearn once IPv6 catches on... Safe prefix length (especially if involving client devices) are: /64 - LAN /126 and /127 - point to point /128 - host routes RFC3513 is quite more strict than should: All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. (2001:: has the binary prefix 001). So this might very well be the problem. I've heard the reason for 64 bits is that it's what currently fits in most computer registers, but I don't know if it's true. Regards, -- Pelle Johansson
Re: Tests failing on OSX
22 sep 2011 kl. 11:49 skrev Francois Gouget: On Wed, 21 Sep 2011, Charles Davis wrote: [...] I also wondered if Xquartz brings it's own X11 headers and libraries. I haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin. Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively. That does not sound right. I have installed XQuartz 2.6.1 on my Leopard machine and I have no /opt/X11 directory. In fact I don't really know where XQuartz installed itself. I suspect it overwrote the files in /usr/X11. The Leopard releases go into /usr/X11 (can't remember the exact reason). Starting with Snow Leopard they go into /opt/X11. If you installed it using macports it probably goes into /opt/local. Try sudo port contents xorg-server in that case. Regards, -- Pelle Johansson
Re: configure.ac: add -Werror to default compiler options
(resent with correct from-address, please ignore the previous one) 1 sep 2011 kl. 03:27 skrev Dan Kegel: At which point it would probably be a fine idea to add -Werror by default; buildbot will help keep everyone in sync, even if they're using a compiler that doesn't catch as many warnings as the one buildbot uses. We use -Werror at my company, but I think you should really think twice before enabling it for a distributed package. New compiler versions add new warnings. Usually correctly so, but there's no way to know what warnings will be produced by what compiler, and keeping up with new compilers requires a bit of effort. We make sure to always test new compilers separately before upgrading on the developing machines. I think most users will probably just see that the package fails to build, and assume it's broken. Ps. I know there's also a few warnings while building on OS X. I don't have access to it now, or I'd send the list. -- Per Johansson
Re: configure.ac: add -Werror to default compiler options
1 sep 2011 kl. 03:27 skrev Dan Kegel: At which point it would probably be a fine idea to add -Werror by default; buildbot will help keep everyone in sync, even if they're using a compiler that doesn't catch as many warnings as the one buildbot uses. We use -Werror at my company, but I think you should really think twice before enabling it for a distributed package. New compiler versions add new warnings. Usually correctly so, but there's no way to know what warnings will be produced by what compiler, and keeping up with new compilers requires a bit of effort. We make sure to always test new compilers separately before upgrading on the developing machines. I think most users will probably just see that the package fails to build, and assume it's broken. Ps. I know there's also a few warnings while building on OS X. I don't have access to it now, or I'd send the list. -- Pelle Johansson
Re: Tasks request
25 aug 2011 kl. 14:12 skrev Frédéric Delanoy: On Thu, Aug 25, 2011 at 03:31, Nowres Rafid nowres.ra...@gmail.com wrote: Hello, I want to help the wine project, any one can tell me what tasks I can start with.Thanks Nowres rafid There are many things that can be done to help Wine: bug hunting, fixes, triage (http://bugs.winehq.org/), test applications for regressions(http://appdb.winehq.org/), translations (http://wiki.winehq.org/Translating, http://source.winehq.org/transl/), etc. For coding tasks, http://wiki.winehq.org/SummerOfCode might also be of use. -- Per Johansson
Re: winemenubuilder: appbundle patch 20110618
Hi Steven, list, I tried both AppleScript and shell script versions and AppleScript doesn't really add anything, so it's probably better to go with shell script and generate the bundle manually. I'll see if I can help smoothing it out. -- Pelle Johansson 17 aug 2011 kl. 00.06 skrev Steven Edwards: You might be interested in this. It allows icons and localized resources. I've just not gotten around to doing all the polish. -- Forwarded message -- From: Steven Edwards winehac...@gmail.com Date: Sat, Jun 18, 2011 at 5:43 AM Subject: winemenubuilder: appbundle patch 20110618 To: Wine Developers List wine-de...@winehq.com Hi, I've finally gotten back around to hacking the *.app bundle support in winemenubuilder and come close to having something that mostly works. There are still things that need to be cleaned up and further abstracted, and a bit more logic to work out. I wanted to go ahead and send this out in case anyone else wants to play around with it, or if for some reason I am unable to finish hackin on it. Some notes: - The first icon/bundle always seems to get the wrong icon, and uses the default wine icon. I need to take some time to understand the code a bit better and see why this is. - Bundles are created in $HOME/Applications/wine and icon's are generated using the icns code. Support for building bundles for shortcuts on $HOME/Desktop has not been hacked on yet. - There are still plenty of bugs to resolve such as making sure we are actually using the correct icon, and properly setting various values in the app *.plist. There are a couple of alternative ideas I looked in to, such as doing some sort of spawn/fork to invoke /usr/libexec/PlistBuddy rather than using the CoreFoundation API, but I worry about creating race conditions and other performance problems when installing software that creates many icons, such as Microsoft Office. - I've tried to make this un-invasive to the existing xdg code path (as one can run a FreeDesktop on Darwin/OS X) but have not had a chance to actually test supporting both menu systems at the same time. I welcome your feedback. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo appbundles_20110617.diff
OSA-applets on OS X
Hi, my first post to the list, be gentle. :) I'd like some help to fix up the attached patch for submission. It's a change to winemenubuilder such that it will create an OSA applet instead of a .desktop file, when generating a file on the desktop (and only on the desktop). Obviously that's only useful on OS X, which has AppleScript. The main thing left to do is that I'd like to have to hard coded default determined by configure instead, with an option to set it. I didn't find any other code in configure.ac doing such a thing though, so I'm unsure how and if it should be done. I'm also unsure if it's ok to use posix_spawnp. I chose that function because as far as I can tell spawnvp does not allow me to send data to stdin, and popen requires the argument to be escaped, which seems unnecessary. You'll also notice that I include a few environment variables in the applet. That's because by default applications launched on OS X will only have /bin:/usr/bin as path and only look for libraries in /usr/lib. That's not typical locations for wine on OS X and if the paths are not set the applet is unlikely to find the wine binaries. The final point which should be considered is the copying of the icon file from /tmp to the location inside the applet. A more proper way is perhaps to generate the icon file in the correct place in the first place, but doing that requires rather large changes to the code, and this way was much more simple. Any feedback is appreciated, -- Per Johansson Ps. If someone tries to apply it you'll probably get a conflict around line 3065 since the patch currently assumes that my other patch[1] to winemenubuilder is already applied. [1] http://www.winehq.org/pipermail/wine-patches/2011-August/105396.html osa.diff Description: Binary data
