wine-devel

wine-devel@winehq.org

84471 discussions

Re: Where are we going on multiuser?
by Alexandre Julliard 24 Nov '01

24 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > What is our vision on support for multiple users on a single computer? > > I know that WINEPREFIX allows us to use something other than $HOME/.wine for > the base of everything but as far as I can see the whole design still > requires a different WINEPREFIX for each user. (e.g. the socket is in > wine-server-<hostname> and there is no apparent support for the system.reg, > user.reg and userdef.reg being in different places). You need one WINEPREFIX per user yes. You can use global registry files by creating symlinks to global files in the user WINEPREFIX. The usual way is to wrap your app in a shell script that will populate the user's WINEPREFIX if it doesn't exist yet. There are plans for splitting registry files into separate sections with some kind of include mechanism, but nothing implemented yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

Where are we going on multiuser?
by Bill Medland 23 Nov '01

23 Nov '01

What is our vision on support for multiple users on a single computer? I know that WINEPREFIX allows us to use something other than $HOME/.wine for the base of everything but as far as I can see the whole design still requires a different WINEPREFIX for each user. (e.g. the socket is in wine-server-<hostname> and there is no apparent support for the system.reg, user.reg and userdef.reg being in different places). Bill

1 0

Re: fix documentation compilation error
by Andreas Mohr 23 Nov '01

23 Nov '01

On Fri, Nov 23, 2001 at 01:35:14AM +0100, Michael Stefaniuc wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > Add missing </para> in documentation/packaging.sgml Ouch ! Hmm, better make an actual compile next time :-\ Sorry !! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

A window painting problem.
by Duane Clark 23 Nov '01

23 Nov '01

Howdy, Perhaps this is one of those things that is in work. But this patch causes one of the (sub)windows in the app Xilinx fpga_editor (commercial) to never get painted. The app has several windows within a window, including a scrolled window, which after the patch I can zoom in and out and move the scrollbars just fine. But the contents never get painted, no matter what I do, including hiding and reshowing, etc. All the other pieces and windows are painted fine. http://cvs.winehq.com/patch.py?id=1005773317852080273907632 Log message: Moved WIN_FindWinToRepaint functionality to the server. Duane

1 0

Re: Which is correct? listview or treeview?
by Gerard Patel 22 Nov '01

22 Nov '01

At 01:58 PM 21/11/2001 -0800, you wrote: >With regard to my problem that I was getting infinite redraws in my listview >following Alexandre's change to server/user/message.c: > >I eventually tracked it down to the fact our code used >SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be >demonstrated easily on e.g. the MFC RowList sample with a two-line change). >Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and >then RedrawWindow. >In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's >data. > >Which is (more) correct? I have seen the same problem with the plain listbox I have an app (Eudora) that is using WM_SETREDRAW on a listbox and found that it was not possible to reproduce the app's behaviour without doing directly a RedrawWindow. Andi commented it was ugly and unefficient (IIRC) and Alexandre Julliard ignored the patch anyway. So I intended at some point to look at Listview and Treeview (with the nasty intent to prove that I am right and they are wrong of course :-)) If you find that doing an explicit RedrawWindow is the right way (TM) I am all for it. OTOH, I have myself - at least ;-( - one regression pending for this patch. The attached hack (on dlls/x11drv/winpos.c) fixes it, maybe with a lot of luck it could fix your problem too ? I'm not too hopeful as it does not seem related but you never know. Gerard --- winpos.c.orig Tue Nov 13 23:02:20 2001 +++ winpos.c Thu Nov 22 00:24:35 2001 @@ -1464,6 +1464,14 @@ /*********************************************************************** * X11DRV_ConfigureNotify */ + +Bool predicate(Display *display, XEvent *event, char *arg) +{ + Window w = *((Window *) arg); + return ((event->type == ConfigureNotify) && + (event->xany.window == w)); +} + void X11DRV_ConfigureNotify( HWND hwnd, XConfigureEvent *event ) { HWND oldInsertAfter; @@ -1472,8 +1480,20 @@ RECT rect; WINDOWPOS winpos; int x = event->x, y = event->y; + XConfigureEvent ev; if (!(win = WIN_GetPtr( hwnd ))) return; + + while (XCheckIfEvent(event->display, (XEvent *)&ev, + predicate, (XPointer)&event->window)) + { + event->x = ev.x; + event->y = ev.y; + event->width = ev.width; + event->height = ev.height; + event->above = ev.above; + event->send_event = ev.send_event; + } data = win->pDriverData; /* Get geometry */

2 1

thanksgiving prayer
by lee 22 Nov '01

22 Nov '01

...wishing everyone a special thanksgiving filled with great joy, special friends and loved ones as we move forward to a brighter tomorrow, carrying with us the best of yesterday and the promise of today- lee

1 0

Crashing menus, event handling broken?
by Jukka Heinonen 22 Nov '01

22 Nov '01

While playing Civilization 2, I noticed that Wine crashes if I click menu bar twice while the game is thinking. The reason for this is that raw hardware messages get processed before menu event loop starts. Raw event processing turns raw events into cooked events and because menu event loop has not started yet, game window is not capturing events and thus clicks on menu bar are turned into nonclient messages. These cooked messages are put back into message queue. When menu event loop starts, it receives the second nonclient button press event and passes it to DispatchMessage. Default window procedure creates a new menu event loop and since the nonclient message was still in the event queue (it would have been removed if DispatchMessage had returned), we get a nice stack overflow. The real problem is not in menu event loop but in the fact that Wine event handling forgets that we can't determine whether a mouse event is nonclient event or not unless we have already called window procedure for all previous mouse events. This is because one of those calls might have for example captured mouse input after which we no longer report nonclient events. Since event handling is quite complicated and this flaw looks more like a design error than coding bug, I would like to get some discussion about what should be done to fix this problem. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: Packing in mmsystem16 and supporting broken GetWindowLong use cases
by Joshua Thielen 21 Nov '01

21 Nov '01

Jukka Heinonen wrote: >The second patch is because Wine mmsystem16 header does not use >correct packing which results into 48 byte structure taking >52 bytes and overwriting a pointer. This makes Civilization 2 >quite unhappy. Took almost a day to debug the game and >find out that the bugger who messes the pointer is really >waveOutGetDevCaps16... > Yessss! Thanks for finding this bug! It would have taken me ages to find it. Finale was choking awfully after calling midiInGetDevCaps. It would go into an endless loop, trashing my hard-drive and forcing me to do a hard reset on my box. Your patch fixes the problem. Cheers! Josh Thielen

1 0

Which is correct? listview or treeview?
by Bill Medland 21 Nov '01

21 Nov '01

With regard to my problem that I was getting infinite redraws in my listview following Alexandre's change to server/user/message.c: I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be demonstrated easily on e.g. the MFC RowList sample with a two-line change). Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the treeview's data. Which is (more) correct? (And how does calling RedrawWindow once result in the repeated repainting of the treeview anyway?) I'm prepared to do the fix if no-one else can but I must admit that I am not really up on the details of the invalidation/paint etc Bill

1 0

New level of Shlwapi (parts 1 & 2)
by Guy L. Albertelli 21 Nov '01

21 Nov '01

Most of the shlwapi upgrades have been driven by my desire to be able to run Outlook Express under Wine. (I know that there are other mail packages, but the rest of the home uses Windows - anyway it is a great test vehicle, uses everything ever implemented). The current status is as follows: With V4 or IE and OE - with builtin shlwapi,commctrl,comctl32 . IE displays page, can even do www.cnn.com, even runs javascript. + Certain menu popups either fail to display, or bomb. + Needs work in comctl32 rebar for extra space. . OE seems to basicly work. + Can display messages, change folders, and create messages. + Cannot invoke address book, but can request address list when creating new message. V5 of OE - requires native commctrl, comctl32: . With builtin comctl32 + OE fails to startup . With native commctrl, comctl32: + OE comes up but is mostly non-functional. Bombs on shutdown due to shlwapi.208 and shlwapi.210 V5 of IE - Does not start up yet. Requires native shlwapi . With native shlwapi, builtin comctl32 + IE has black toolbars with white lines. Menu line real small. . With native shlwapi and comctl32: + IE has black bitmaps for button bar. Mostly functional, however cannot access dropdown arrow for address bar. <sarcasm> I really appreciate the MS developer that decided to implement menus in OE5 with objects and put some of his "common" code in shlwapi. </sarcasm> Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel