Re: [GSoC] My proposal for GSoC 2013
Hello again! Thank You all for the feedback! There's a bit more info at http://wiki.winehq.org/FAQ#head-dba86ae589dca54a116a3fc21f6237af45e8119c. That's odd - I could've sworn this was an environment variable which had the same limitations as using winecfg! My memory must be playing tricks on me... And yes, now that I tested it again, I see it really does the job. Except for not working with steam games, but that is steam's fault, not Wine's. Though you did start early, so you have plenty of time to find other ideas Indeed... But now that I have to think of something else - what general areas in Wine are most welcome for GSoC ideas? I Looked over the GSoC Wine's wiki page, but I do not know how much I can trust it. That is because after GSoC 2012, it was only edited once. And the edit comment says: remove some stuff that's done (still quite a bit of cleanup left).. Thank You for Your time! Gediminas Jakutis -- LDK Varčiai www.varciai.lt
Re: [PATCH 4/5] winemac: Implement rudimentary support for system tray icons as Mac status items.
On Mar 18, 2013, at 3:22 PM, Ken Thomases k...@codeweavers.com wrote: On Mar 18, 2013, at 4:04 PM, Charles Davis wrote: On Mar 18, 2013, at 2:23 PM, Ken Thomases wrote: On Mar 18, 2013, at 2:15 PM, Ken Thomases wrote: On Mar 18, 2013, at 3:03 PM, C.W. Betts wrote: On Mar 17, 2013, at 9:40 PM, Ken Thomases k...@codeweavers.com wrote: Doesn't support right-clicks, mouse moves, or notification balloons. Notification balloons can probably be done using either Notification Center or Growl Yeah, I was thinking that the notification center is the right way to go. Josh reminds me that only code-signed apps can use the Notification Center, so that may not be very useful. *sigh* So what? [...] Though I wonder if it's a good idea to ask users to create a self-signed certificate just so Wine can use the Notification Center... You answered your own question. ;) At this point, though, I'm wondering if it wouldn't just be easier to have Explorer draw the balloons itself à la Windows XP. Probably. I also considered using an NSPopover anchored to the status item. Again, that's 10.7+ functionality. We could implement it and do compile- and runtime checks to make sure that the functions aren't called in unsupported OS X versions. However, this would probably add fragmentation, and I doubt Alexandre would be happy with this.
Re: gdi32: Copy gamma ramp validation from winex11 to make it driver independent
André Hentschel n...@dawncrow.de wrote: - this was done for the mac driver - i tried to follow the file-style, except of the original variable naming The ERRs should be downgraded to WARNs or even TRACEs, there is no point to loudly complain on application input. -- Dmitry.
Re: Parameterizing the places Wine suggests people report bugs
On Mon, Mar 18, 2013 at 5:18 PM, Josh DuBois dubo...@codeweavers.com wrote: Hi all, There are a couple of places wine suggests that people report bugs to wine-devel. The crash reporting dialog in winedbg suggests this, and a couple of places in code refer to wine-devel@winehq.org in error messages. I assume you meant http://bugs.winehq.org for the winedbg dialog, since that's what I get/the po files refer to: Report-Msgid-Bugs-To: http://bugs.winehq.org\n; The configure script has a PACKAGE_BUGREPORT macro which could be used to allow someone building wine to redirect those errors somewhere else. At least for wine's crash dialog, an alternate approach for a repackager to redirect bug reports would be to read the url / email address for where to send bugs from the registry. Would Wine accept a patch for making winedbg read the 'destination' for bug reports from the registry or some other runtime variable? Or would the project prefer to have all the bug reports routed directly to winehq, so that a repackager who wants to re-route bugs would have to build that facility on its own? I can't speak for Alexandre, of course, but speaking with my bugzilla hat on, if a packager wants to override that, I don't see the harm. I'd rather see wine bugs reported upstream (i.e., http://bugs.winehq.org), but if the packager wants to override that, I assume they have a good reason (building wine with custom/hacky patches, changing default registry settings, etc.). How many packagers will actually use that feature though, and how many users would notice the difference, is the ultimate question, of course :). -- -Austin
