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

Re: Don't set stacking order against unvisible windows

by Mike Hearn

However, I think it unbreaks InstallShield, which is a fantastically common application. It might be a case of a "lesser of two evils" decision. On Tue, 2003-07-01 at 00:01, Alexandre Julliard wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Changelog: > > dlls/x11drv/window.c: X11DRV_sync_whole_window_position > > Don't specify a stacking order agains unvisible windows > > This will break other things. The right fix is to make the desktop > option work correctly across processes. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

July 1, 2003

Re: wine/dlls/quartz quartz_private.h main.c filte ...

by Robert Shearman

> I updated from cvs an get an error I apologise for this. I will fix this when I next get access to my computer (it will be a fair few hours), unless someone beats me to it. It is a case of putting the following defines before strmif.h is included: #define NONAMELESSUNION #define NONAMELESSSTRUCT Rob

July 1, 2003

Re: wine/dlls/quartz quartz_private.h main.c filte ...

by Marcelo Duarte

I updated from cvs an get an error: gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o filtermapper.o filtermapper.c filtermapper.c: In function `FM2_WriteFilterData': filtermapper.c:365: structure has no member named `u' filtermapper.c:370: structure has no member named `u' filtermapper.c:373: structure has no member named `u' filtermapper.c:375: structure has no member named `u' filtermapper.c:376: structure has no member named `u' filtermapper.c:379: structure has no member named `u' filtermapper.c:382: structure has no member named `u' filtermapper.c: In function `FM2_ReadFilterData': filtermapper.c:513: structure has no member named `u' filtermapper.c:515: structure has no member named `u' filtermapper.c: In function `FM2_DeleteRegFilter': filtermapper.c:602: structure has no member named `u' filtermapper.c:605: structure has no member named `u' filtermapper.c:606: structure has no member named `u' filtermapper.c:608: structure has no member named `u' filtermapper.c:610: structure has no member named `u' filtermapper.c:611: structure has no member named `u' filtermapper.c:613: structure has no member named `u' filtermapper.c: In function `FilterMapper2_EnumMatchingFilters': filtermapper.c:910: structure has no member named `u' filtermapper.c:912: structure has no member named `u' make[2]: ** [filtermapper.o] Erro 1 make[2]: Leaving directory `/home/mduarte/wine/dlls/quartz' make[1]: ** [quartz] Erro 2 make[1]: Leaving directory `/home/mduarte/wine/dlls' make: ** [dlls] Erro 2 Em Ter 01 Jul 2003 01:29, Alexandre Julliard escreveu: > ChangeSet ID: 8645 > CVSROOT: /home/winehq/opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/06/30 23:29:48 > > Modified files: > dlls/quartz : quartz_private.h main.c filtergraph.c > Makefile.in > Added files: > dlls/quartz : filtermapper.c enummoniker.c > > Log message: > Robert Shearman <R.J.Shearman(a)warwick.ac.uk> > Implemented IFilterMapper2. > > Patch: > http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8645 > > Old revision New revision Changes Path > 1.7 1.8 +3 -11 wine/dlls/quartz/quartz_private.h > 1.24 1.25 +2 -0 wine/dlls/quartz/main.c > 1.2 1.3 +12 -0 wine/dlls/quartz/filtergraph.c > 1.26 1.27 +3 -1 wine/dlls/quartz/Makefile.in > Added 1.1 +0 -0 wine/dlls/quartz/filtermapper.c > Added 1.1 +0 -0 wine/dlls/quartz/enummoniker.c -- Marcelo Duarte

July 1, 2003

Deficient implementation of SetFileTime or with stub GetSetFileTimestamp

by Marcelo Duarte

Hi, Installing a system of the company in the Wine, I found a probable error, that is the following one: when the archives go being unpacked, them they are created in the directory with the current date and would have to be created with the same date of the compact file (as it is made in windows). Thus, in the next step, an update is made verifying the dates it of the files. However, in the Wine, it gives wrong for cause of this difference in the dates. I believe that I can myself make a patch, however as I still do not have experience in debugging Wine, he would like a suggestion of as to find the problem, because I do not know if the bug is in lzexpand (LZCopy) or in SetupApi (perhaps because of stub GetSetFileTimestamp) or because in SetFileTime "const FILETIME * lpCreationTime" simply is ignored, and in server, the function "static int set_file_time(obj_handle_t handle, time_t access_time, time_t write_time) " must not have more one parameter? Manually I make the system to install and run, however I want it running like in Windows. Thanks in advance. -- Marcelo Duarte

July 1, 2003

Re: Various problems- it just gets worse!

by Shachar Shemesh

Duane Clark wrote: > Shachar Shemesh wrote: > >> Duane Clark wrote: >> >> >>> I do understand the aversion to scripts, but the wineinstall one is >>> fairly mild. I've been using Wine for more than 3 years and have >>> even done some development on it (I wish I had more time for that... >>> sigh). Still, if I want to test with a clean install, I delete or >>> move the old windows and .wine directories and just use wineinstall >>> to create fresh versions. Because, well, it just works so well and >>> is a lot easier than doing the configuration by hand. >> >> >> >> My beef with wineinstall is that there is no way to isolate the >> configuration creation part from the install part. I think we should >> have a script that does only the configuration, fake root and >> registry creation. This way, the script can be bundled with the >> package and placed on the destination machine. such a script should >> be runnable without the sources dir (maybe by specifying the location >> of the template registry and such via command line, maybe created by >> ./configure). >> >> This way, the order CAN be "./configure, make depend, make, make >> install, createconf" for normal install. Packagers can then do >> "./configure --templatedir=/usr/share/wine --prefix=/usr (etc) && >> make depend && make && TMPDIR=/tmp/winerpmroot make install", and run >> "createconf" from the "postinstall" section of the RPM sort of thing. >> >> Opinions? > > > It sounds like you are looking for something useful for binary > distributions. I think that wineinstall would normally only be used by > someone who is downloading and installing their first source > distribution. Not entirely true either. I often find myself seeking to restore the config. Also, what about someone who downloaded the sources and installed wine system wide, and then wants to enable wine for a second user? > So I think wineinstall is appropriate for that. > > For binary distributions, I think a GUI tool is more appropriate. And > there exists a tool, winesetuptk, for that purpose. It is a long time > since I tried that tool, but as I recall, it was fairly easy to use. > I disagree, even had I been looking for something useful for a binary distribution. A GUI tool would be the worst solution possible. winesetuptk is excellent for an end user trying to tweak his own configuration. Something that runs while rpm -i (or dpkg -i) cannot depend on GUI, for it would prevent it from running while installing the system. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

July 1, 2003

Re: XEMBED System tray support

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > + /* now set sync the X11 window rects to the win32 window rects, > + so the shell tray code can properly align the icon */ > + > + > + XTranslateCoordinates(display, data->whole_window, root_window, > + 0, 0, &x, &y, &child); > + XGetWindowAttributes(display, data->whole_window, &attrs); > + > + wine_tsx11_unlock(); > + > + r.left = x; > + r.top = y; > + r.right = r.left + attrs.width; > + r.bottom = r.top + attrs.height; > + > + WIN_SetRectangles(hwnd, &r, &r); This completely bypasses the normal window size handling, I don't think that's a good idea. Positions changes should be handled by the standard ConfigureNotify processing. -- Alexandre Julliard julliard(a)winehq.com

July 1, 2003