July 2008 - Wine-Devel - list.winehq.org

Re: winecfg.cpl: Add new control panel applet for winecfg

by Rob Thornton

Owen Rudge wrote: > > As we said before, implementing a control panel applet doesn't mean > > you have to do anything to the current winecfg code. > > True, but would it really benefit to add an icon for each winecfg tab > (which I think is what you are suggesting, yes?) to the control panel, > compared to having one general icon for Wine configuration? > I don't think think making winecfg seem more like the Windows Control panel is really something wine should strive for. Wine may be a compatibility layer for Windows but I'm not sure it should mimic it. Rob Thornton

July 1, 2008

Re: winecfg.cpl: Add new control panel applet for winecfg

by Owen Rudge

> As we said before, implementing a control panel applet doesn't mean > you have to do anything to the current winecfg code. True, but would it really benefit to add an icon for each winecfg tab (which I think is what you are suggesting, yes?) to the control panel, compared to having one general icon for Wine configuration? -- Owen Rudge http://www.owenrudge.net/

July 1, 2008

Re: winecfg.cpl: Add new control panel applet for winecfg

by James Hawkins

On Tue, Jul 1, 2008 at 4:22 PM, Owen Rudge <owen(a)owenrudge.net> wrote: >> Isn't it more logical (and closer to native) to have a control panel >> applet for each category/tab already in winecfg instead of having one >> winecfg applet? Otherwise you're just moving winecfg to another >> place. > > Well, my plan, as mentioned before in another thread, is to split up winecfg > a bit, but there's only so much you can do this, due to the fact that most > of the tabs in winecfg can work on a global or application-specific basis. > As far as I can tell, the Desktop and Sound tabs are the only bits of > winecfg that are global-only and as such can be split from the rest in this > manner, and this is something I would be considering for a "next step" for > this applet. However, I figured a simple applet that showed some icons that > a) let us actually have something in the control panel and that would b) > provide a more user-friendly interface to these tools for users would be a > good start, rather than coming along straight away with a large patch that > hacks up winecfg! > As we said before, implementing a control panel applet doesn't mean you have to do anything to the current winecfg code. -- James Hawkins

July 1, 2008

start/stop logs by code... is it possible ?

by Massimo Del Fedele

I'd like to start some trace log entering a function and stopping it at exit, to isolate just the part I need. Is it possible to add some code inside the function body that do it ? I mean... void aWineFunction(...) { ....... STARTLOG ....... ....... STOPLOG ....... } The purpose is to isolate traces from code called by a single function. Max

July 1, 2008

Re: winecfg.cpl: Add new control panel applet for winecfg

by Owen Rudge

> Isn't it more logical (and closer to native) to have a control panel > applet for each category/tab already in winecfg instead of having one > winecfg applet? Otherwise you're just moving winecfg to another > place. Well, my plan, as mentioned before in another thread, is to split up winecfg a bit, but there's only so much you can do this, due to the fact that most of the tabs in winecfg can work on a global or application-specific basis. As far as I can tell, the Desktop and Sound tabs are the only bits of winecfg that are global-only and as such can be split from the rest in this manner, and this is something I would be considering for a "next step" for this applet. However, I figured a simple applet that showed some icons that a) let us actually have something in the control panel and that would b) provide a more user-friendly interface to these tools for users would be a good start, rather than coming along straight away with a large patch that hacks up winecfg! -- Owen Rudge http://www.owenrudge.net/

July 1, 2008

Thoughts on implementation of winhttp.dll

by Zac Brown

Hi, I've been looking at implementing winhttp.dll. Does anyone have thoughts on implementing parts of winhttp in terms of wininet? The primary issue that prevents entirely implementing winhttp in terms of wininet is that there is no direct Win32 API for fetching an SSL certificate in winhttp. To access these, I'd need access to functions defined in wininet/netconnection.c but aren't exported. My current two ideas are to either: 1) Copy the networking sublayer from wininet into winhttp and build on top of that to implement winhttp. Effectively reimplementing mostly from scratch. 2) Implement most winhttp things in terms of wininet and then copying over parts that I need from wininet's network sublayer, like fetching SSL certificates and so on. Thoughts on this are greatly appreciated, as I'd prefer to only have to write the library once. -Zac

July 1, 2008

Re: [4/5] WineD3D: Delay render target activation

by James Hawkins

On Tue, Jul 1, 2008 at 2:12 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > You forgot the patch. -- James Hawkins

July 1, 2008

Re: winecfg.cpl: Add new control panel applet for winecfg

by James Hawkins

On Tue, Jul 1, 2008 at 2:17 PM, Owen Rudge <owen(a)owenrudge.net> wrote: > This patch adds a new applet, winecfg.cpl, to Wine, based on a patch sent a > few months ago by Metody Stefanov (pure_evil @ mail.bg). The control panel > features three icons, for Wine Configuration, the Registry Editor, and the > Task Manager. > Isn't it more logical (and closer to native) to have a control panel applet for each category/tab already in winecfg instead of having one winecfg applet? Otherwise you're just moving winecfg to another place. -- James Hawkins

July 1, 2008

RE: [4/5] WineD3D: Delay render target activation

by Stefan Dösinger

This time with the patch > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Tuesday, July 01, 2008 2:13 PM > To: wine-patches(a)winehq.org > Subject: [4/5] WineD3D: Delay render target activation > >

July 1, 2008

re: gdi32: Implement automatic font substitution

by Dan Kegel

Liu Qishuai wrote: > This patch appends all fonts on child_list so that if a character is > not available in the font, other fonts will be automatically used. > This is how Windows does to get a CJK character when a latin font is specified. > > A lot of CJK-related bugs will be fixed after applying this patch. Excellent! In case AJ hesitates to apply this patch: Can you write a conformance test that verifies this behavior? Also, can you identify a bug in bugzilla this will fix? - Dan

July 1, 2008