April 2003 - Wine-Devel - list.winehq.org

Re: Fix loading icon from resource

by BiGgUn

Hi Did you successfully load the splashscreen of emule ? I got a strange biased image instead of a clean one :-\ Stephan

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Patrik Stridvall

> > Once you have a skinning API, you just implement a 'gnome > compat' and 'kde > > compat' skin (or even just an automagical one that does > both) the thing would > > "just work", right? Why, it shouldn't take more than a > couple of hours ;) > > (WARNING: that last part was a joke, if you set your watch > by this you very > > well may miss work for several years). > > I don't think we could do KDE skins, as (surprise) they depend on Qt > which is GPLd. Well, I can't see why Trolltech (the owners of Qt) would object. Presumably the main reason that you would want a Qt skin for Windows application running under Wine is that you run several other Unix applications using Qt... So I can't see why they wouldn't give us special permission if we for some reason would need it... The alternative a GTK skinned only Wine would not benefit them at all, quite the opposite.

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> If you ask me, we should look to implement the (undocumented?) XP skinning > API's -- with a deliberite sprinkling of internal extensions to clean up some > of the messy parts if they are too slow for "built in" wine skins. I think they are fairly well documented from looking at them a few months ago. > It's probably not /that/ difficult to figure out, especially if one is armed > with something like WindowBlinds to hack on. After all, they figured it out > at StarDock, (although they might have the "top secret" special sauce from MS > for all I know...) and some of it is probably out there on the net. WindowBlinds uses extensive hooking from what I recall - it made Windows (98) rather unstable. XP theming is different, it's actually built into the common controls library. > Once you have a skinning API, you just implement a 'gnome compat' and 'kde > compat' skin (or even just an automagical one that does both) the thing would > "just work", right? Why, it shouldn't take more than a couple of hours ;) > (WARNING: that last part was a joke, if you set your watch by this you very > well may miss work for several years). I don't think we could do KDE skins, as (surprise) they depend on Qt which is GPLd. Most projects out there (mozilla, openoffice) use GTK theming engines. > Might be harder than some other approach to this problem, but IMO it would be > a waste to expend labor building "skins" into wine using some other > architecture which might be non-orthagonal to that used by MS operating > systems. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Gregory M. Turner

On Tuesday 29 April 2003 01:46 am, Gregory M. Turner wrote: > architecture which might be non-orthagonal to that used by MS operating hrmph, s/non-//r. I will shut up and try to do some real wine work soon, I promise ;) -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Gregory M. Turner

On Monday 28 April 2003 01:07 am, Dimitrie O. Paun wrote: > On April 27, 2003 05:32 pm, Francois Gouget wrote: > > So the situation will remain the same: we will haev KDE applications and > > WIDE applications and they will not be interoperable. I.e. it won't be > > possible to insert an Excel spreadsheet in a KWord document. > > No, it will be better: you will be able to have deep integration between > Win32 apps and Gnome apps, no small feat. > > > Does that include interoperability with OLE/COM/DCOM or just the look > > and feel integration? > > Well, the OLE/COM/DCOM bit is the interesting one, the look and feel > is simple and has other solutions, as we discussed. > > > I believe where we differ is on the method: > > * I think we should work on Wine to make that possible (though > > there may be some work to do in Gnome and KDE). a few issues are being conflated here perhaps: 1) what browser? 2) how can we get wine apps to have a consistient look-and-feel on gnome and kde (and other) desktops? 3) (the original thread I believe?) what are the prospects of using wine as a window manager? The third may be beyond my ability to answer, but 1) and 2) seem easy to me... As for the browser issue, it's been discussed on the list ad infinitum and the consensus was that we should lean towards konq integration. OTOH, if someone had a well-done, LGPL, working base of completely original code, or magical code to get mozilla or opera or lynx or what-have-you to do everything wine needs -- I would be surprised if it wouldn't find its way into wine (or at least into my tree at home !!! ;)) So he who codes first wins the debate, as usual ;) There is no reason, I think, that we theoretically couldn't accomidate different browsers via run-time configs -- some people really, really need/want their favorite browser -- the debate is therefore unwinnable, we need them all :P As for the look-and-feel thing, I have stronger opinions, so I will try to say less -- I imagine that I will fail ;) First, I should note that there do exist some efforts to do this already in wine, like "icon tray" support, cut-and-paste, etc... so it's not like there's no precedent for what you propose, Dimi... (except maybe the WM thing I guess). If you ask me, we should look to implement the (undocumented?) XP skinning API's -- with a deliberite sprinkling of internal extensions to clean up some of the messy parts if they are too slow for "built in" wine skins. It's probably not /that/ difficult to figure out, especially if one is armed with something like WindowBlinds to hack on. After all, they figured it out at StarDock, (although they might have the "top secret" special sauce from MS for all I know...) and some of it is probably out there on the net. Once you have a skinning API, you just implement a 'gnome compat' and 'kde compat' skin (or even just an automagical one that does both) the thing would "just work", right? Why, it shouldn't take more than a couple of hours ;) (WARNING: that last part was a joke, if you set your watch by this you very well may miss work for several years). Might be harder than some other approach to this problem, but IMO it would be a waste to expend labor building "skins" into wine using some other architecture which might be non-orthagonal to that used by MS operating systems. -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 28, 2003 12:29 pm, Steven Edwards wrote: > I think you are forgetting the one beast/API/toolkit to bind them all. > Mozilla. It is my hope that ReactOS will be able to use either khtml as > it is LGPL or use the Gecko. There's some confusion. I thought you guys are working on doing an Explorer-the-file-browser clone, not an IE clone. Yes, we already have khtml and gecko, it would be crazy/silly to start yet another one. -- Dimi.

April 29, 2003

Re: Excessive Swap with MSVC++ and Wine

by Alexandre Julliard

hatky <hatkyinc(a)yahoo.com> writes: > sounds like a memory leak in the code sould be > addressed to wine-devel(a)winehq.com and you should > probably open a bug on this ..... > > wine-devel, can someone comment/help on that? (I think > there wore more details on the original message) This may be fixed in current CVS, give it a try. -- Alexandre Julliard julliard(a)winehq.com

April 29, 2003

Re: FindWindow timeouts

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > After chatting to some people on IRC about windows message handling, I > remembered a bug I hit where a frozen window could kill everything > because FindWindow sends a message to every window with no timeout (to > get the window text). > > Is this right? Wouldn't it be better to make FindWindow more robust by > sending messages with a timeout so if one window in an app (or anothe > process) has frozen, it doesn't kill the caller? FindWindow doesn't send messages to other processes, exactly for that reason. It does send them to other threads inside the same process, so it can hang if a thread is not responding. That's the way it's supposed to work according to MSDN. -- Alexandre Julliard julliard(a)winehq.com

April 29, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Dan Kegel

That did it. And yes, the workaround was needed in EndPaint, too; I tried Mike's patch first, and added the EndPaint workaround myself before I noticed Dmitry's patch. The app isn't very functional, but at least it doesn't crash. I encourage anyone who is working on Visual Basic compatibility to give http://www.servicesoftware.com/sams/SAMSINDEX.exe a spin. (And look at all the pretty fixme's :-) Thanks, Dan Dmitry Timoshkov wrote: > "Dan Kegel" <dank(a)kegel.com> wrote: > > >>Backtrace: >>=>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) [painting.c:200] in user32.dll.so) (ebp=40892bc4) > > > Attached patch should help a bit. > > > > ------------------------------------------------------------------------ > > Protect BeginPaint and EndPaint from lps being NULL. > > --- cvs/hq/wine/dlls/user/painting.c Thu Jan 09 03:41:30 2003 > +++ painting.c Mon Apr 28 10:15:46 2003 > @@ -159,6 +159,8 @@ > HWND full_handle; > WND *wndPtr; > > + if (!lps) return 0; > + > if (!(full_handle = WIN_IsCurrentThread( hwnd ))) > { > if (IsWindow(hwnd)) > @@ -239,6 +241,8 @@ > */ > BOOL WINAPI EndPaint( HWND hwnd, const PAINTSTRUCT *lps ) > { > + if (!lps) return FALSE; > + > ReleaseDC( hwnd, lps->hdc ); > ShowCaret( hwnd ); > return TRUE; -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

April 29, 2003

Re: Winword, StorageImpl_Commit, Crossover and Wine

by Mike McCormack

Hi Uwe, I have implemented WriteFmtUserTypeStg and ReadFmtUserTypeStg in Crossover's Wine... I'm trying to gradually ween us off native DLLs. Alexandre should start merging shortly... Mike Uwe Bonnes wrote: > Hallo, > > running MS Word 2000 with builtin dlls doesn't allow to write files, because > of at least StorageImpl_Commit and WriteFmtUserTypeStg still stubs? Does > Crosover Office still require the native OLE dlls or has it some > implementation? > > Bye

April 29, 2003