September 2003 - Wine-Devel

Re: PATCH: stop crashes in desktop mode

by Alex Pasadyn

Mike Hearn wrote: > On Tue, 2003-09-30 at 21:57, Dimitrie O. Paun wrote: > >>In fact, what kind of problems >>do we have with InstallShield? > > > It attempts to do window management across two different desktop windows > causing an X11 ConfigureWindow error. We can't run it outside of desktop > mode because the big blue window becomes unmanaged and you can't switch > to the main installer window. So what about the patch I submitted that started this discussion? It certainly prevents the ConfigureWindow call from crashing Wine (at least for the cases I tried). I realize it's not addressing the root problem, but I think it's at least a better situation than crashing. Longer term, I think the ideal solution is to get all the priority and input focus issues worked out so all the windows could just get managed by the window manager. (That's what it's there for!) I would like to help with this, but I need to better understand what the issues are. There are certainly native X applications that create oddly shaped windows without WM decorations that don't confuse the window manager at all. Are Wine apps needing to do something that's not supported or is it just a matter of fixing Wine? Then, at that point, what would be really slick is if the Wine desktop could be a separate process that you run when you want to confine a specific app (and all its subprocesses) to a smaller space (e.g. winedesktop -size 800x600 -- myapp.exe). -ajp

Sept. 30, 2003

Re: Updated winetests.exe

by Dimitrie O. Paun

On Tue, 30 Sep 2003, Ferenc Wagner wrote: > I thought the build tag (which can be any one-line string) > was enough. Why do we need anything else? That works nicely IF Jakob builds the tests only on official releases (which should happen anyway). I guess we can hope not to do some silly things. In fact, the build script can be smart enough to notice if we're not using an offcial release, and provide a different build tag. Anyway, it's cool. > > -- you have to be able to deal (how?) with tests results > > that arrive before the master file. > > This is impossible, I would reject them. It's not really impossible (the way email gets delivered), but I guess should be rare enough that rejecting is OK. > > -- a simple to generate format would be: [...] > > > > KEY:<the uuid> > > *** <dll> (section repeated for each DLL) > > * <dlls/<dll>/tests/file.c>:<CVS version> (multiple times, for each file) > > <any errors/warnings generated during compilation, verbatim> > > > > <output of 'wine dlls/<dll>/tests/<dll>_test.exe.so> > > In general, this sounds almost OK, although I do not see why > it would be simple to generate. It can't be that hard: we mainly have to for dll in $DLLS echo "*** $dll" ver=`cvs status $file | grep Working | awk '{print $3}'` for file in dlls/$dll/tests echo " * $file $ver" echo "MinGW:" compile_file_with_MinGW echo "MSVC:" compile_file_with_MSVC done wine dlls/$dll/tests/$dll_test.exe.so done > We should accomodate both > MSVC and MinGW, right? Their outputs are different. Sure, we can do that, we just need a line that have a tag like so <build_system>: separating the output of various build systems. > And some asterisks might be useful to separate the compiler and > test output. We don't need any, the output looks like this: [dimi(a)dimi wine.build]$ wine dlls/kernel/tests/kernel32_test.exe.so Usage: dlls/kernel/tests/kernel32_test.exe.so test_name Valid test names: alloc atom ... In fact, it's probably better to include this first, instead of the '*** <dll>' line, it tells us even more info... > But I think it is rather hard (Jakob?) and not sure whether > it is worth the effort. Apart from the compiler output > everything can be generated from the build tree (and I have > the shell script for that), and since the build procedure is > not automated, Jakob could simply copy some relevant output > into dsound.dll.txt, possibly add some comments, tar it up > with the master file and send it to WinHQ. Come one, it's not that big a deal. Besides, we really need to automate the build procedure, I don't think manual stuff will cut it. Also, I don't like the tar idea, I'd like to be able to see the reports in the emails, rather than save a file, extract, etc. Plain text works best here. We do spend a bit more time now working out the nits, but I hope that at the end of the day, we can simply "fire and forget", with virtually no manual intervention required. In fact, the build procedure should be included in our makefiles, and we can invoke it automatically on a new Wine release through the make_release script... -- Dimi.

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Uwe Bonnes

>>>>> "Dimitrie" == Dimitrie O Paun <dimi(a)intelliware.ca> writes: Dimitrie> On 30 Sep 2003, Mike Hearn wrote: >> future they too could be managed but with the appropriate hints to >> switch off window decorations, appearing in the window list etc. Dimitrie> It certainly be nice to defer the window management to ... the Dimitrie> window manager :) Maybe we can start with a list of hints that Dimitrie> we need in order to do that. Once we have the list, we can Dimitrie> approach the freedesktop.org people for integration in the Dimitrie> standard. Would that also solve our InstallShield problems? In Dimitrie> fact, what kind of problems do we have with InstallShield? >> Another alternative would be to merge in Keith Packards pseudo-root >> extension: Dimitrie> Any idea why he did not get it integrated? There have been problems in the Xfree86 board, and to my knowledge Keith is no longer member of that board. It probably was not his decision to leave the board... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Mike Hearn

On Tue, 2003-09-30 at 21:57, Dimitrie O. Paun wrote: > In fact, what kind of problems > do we have with InstallShield? It attempts to do window management across two different desktop windows causing an X11 ConfigureWindow error. We can't run it outside of desktop mode because the big blue window becomes unmanaged and you can't switch to the main installer window. > > Another alternative would be to merge in Keith Packards pseudo-root > > extension: > > Any idea why he did not get it integrated? So much to do, so little time to do it.....

Sept. 30, 2003

Re: uxtheme.dll

by Jimmy O'Regan

Roderick Colenbrander wrote: >The "old" dll that MS ships with WindowsXP is comctl32.dll version 5.x which >is the same as on other Windows versions. > >Version 6 is the new version. One of the biggest changes is that this updated >dll handles both the user and common controls. Further all controls now >include some area in which can be drawn for theming. > >For more info check out: >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html… > >Roderick Colenbrander > > Another difference is that the new version comes as an assembly; multiple versions of the dll can live side by side.

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > I suppose the problem then is that we can't figure out how a fullscreen > install window is different to a menu or tooltip window. Perhaps in > future they too could be managed but with the appropriate hints to > switch off window decorations, appearing in the window list etc. Well yes that's the plan, the problem is that it requires being able to switch a window to managed on the fly, and that's a bit tricky to do right. I'm planning to work on that once I'm done with the $%#@$ dll separation and glibc stuff. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Dimitrie O. Paun

On 30 Sep 2003, Mike Hearn wrote: > future they too could be managed but with the appropriate hints to > switch off window decorations, appearing in the window list etc. It certainly be nice to defer the window management to ... the window manager :) Maybe we can start with a list of hints that we need in order to do that. Once we have the list, we can approach the freedesktop.org people for integration in the standard. Would that also solve our InstallShield problems? In fact, what kind of problems do we have with InstallShield? > Another alternative would be to merge in Keith Packards pseudo-root > extension: Any idea why he did not get it integrated? -- Dimi.

Sept. 30, 2003

Re: "Start menu" (continued ...)

by Jakob Eriksson

On Tue, Sep 30, 2003 at 10:02:40PM +0200, Robert van Herk wrote: > Would such a system be appreciated by the you people? Or do you think I > should wait untill a better standarization is available? Or do you think > creating a Windows deamon and a Linux client is too much overkill for > such a feature? _Waiting_ for standards could mean waiting forever. Creating something on the other may very well be creating a _de_facto_ standard. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Mike Hearn

On Tue, 2003-09-30 at 18:13, Alexandre Julliard wrote: > I don't think that's a problem. If you want desktop mode you can > install Xnest. Another alternative would be to merge in Keith Packards pseudo-root extension: http://keithp.com/~keithp/talks/proot.tar.gz Unfortunately it's not currently in XFree but apparently would be easy to merge in. At some point if a Wine hacker feels like branching out ... :)

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Mike Hearn

On Tue, 2003-09-30 at 21:13, Alexandre Julliard wrote: > For windows that need to be managed yes. Even in managed mode there > are some windows that are never managed, like menus, tooltips, etc. > That's what is_window_managed is for. I suppose the problem then is that we can't figure out how a fullscreen install window is different to a menu or tooltip window. Perhaps in future they too could be managed but with the appropriate hints to switch off window decorations, appearing in the window list etc.

Sept. 30, 2003