September 2004 - Wine-Devel

Re: Progress Bar: Fix Class Style & Repainting (resend2)

by Robert Shearman

Dimitrie O. Paun wrote: >On Tue, Sep 28, 2004 at 12:12:09PM -0700, Alexandre Julliard wrote: > > >>Robert Shearman <rob(a)codeweavers.com> writes: >> >> >> >>>Changelog: >>>- Fix class style to include the hbrBackground member. >>>- Fix repainting issues introduced by this change. >>>- Add WM_ERASEBKGND handler and remove background drawing code from >>>the WM_PAINT handler. >>> >>> >>Isn't that going to cause a lot of flicker? This was the reason for >>the existing code, because otherwise it looks really bad with apps >>that update the progress bar a lot. >> >> > >Indeed, IIRC I've tried to have as optimum background drawing code >as possible (in terms of overwriting areas, etc), as flicker in the >progress bar would look rather ugly. > > Yes, I saw the hack we have in the Crossover code and saw the discussion last year. This code still keeps code that doesn't unnecessarily redraw the background, but the whole client area needs to be painted each time (even if normally nothing is drawn in the rest of the area), because some InstallShields depend on this for correctly displaying the % in their progress bars. >We have to be careful with these sort of changes, in that there are >some controls that work real hard to avoid flicker as much as possible. >Yes, the code is bigger, more complicated, and maybe sometimes not >100% the way MS does it. But if it doesn't cause any problems, having >a good looking control is important IMO. > > Feel free to test the code and report any flicker. I'll fix the marquee case and then send you a test program if you like. Rob

Sept. 29, 2004

Re: Progress Bar: Fix Class Style & Repainting (resend2)

by Robert Shearman

Alexandre Julliard wrote: >Robert Shearman <rob(a)codeweavers.com> writes: > > > >>Changelog: >>- Fix class style to include the hbrBackground member. >>- Fix repainting issues introduced by this change. >>- Add WM_ERASEBKGND handler and remove background drawing code from >>the WM_PAINT handler. >> >> > >Isn't that going to cause a lot of flicker? > Not in the normal case. Flicker is caused when then background is drawn and then painted over by the foreground. I have kept the logic that only draws the background if the position of the progress bar has decreased. Admittedly, the invalidation in marquee mode will suffer from this problem, but I suppose that could be worked around with some careful RedrawWindow's. >This was the reason for >the existing code, because otherwise it looks really bad with apps >that update the progress bar a lot. > > The existing code is wrong. Apps that depend on WM_ERASEBKGND doing something currently look really bad, no matter how often they update the progress bar. It would be a shame to leave have this bug remain in an otherwise completed control. Rob

Sept. 29, 2004

Updated winecfg to do list

by Mike Hearn

OK, well assuming that Alexandre commits the last of my patches to winecfg at some point (I suspect there is a reason they aren't already ...), here is the updated todo list for winecfg based on my last email on the subject: http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I'm probably not going to do any more work on winecfg for a while. > You probably want to increase the size of the drive mappings list so it > fills the tab, currently there is just a lot of empty space at the top of > the pane now you removed the old stuff. If AJ commits the last two patches, this is done. In fact, the editing has been moved into the main tab, as there isn't much reason to have a separate window for this and it simplifies the UI and code somewhat. > Also we should kill the autodetect button. This is done by > wineprefixcreate these days, or should be. Getting there ... drive autodetection is implemented. The heuristics could perhaps be improved but they'll do for now. But, we need to call it from wineprefixcreate. This means adding code like so to main(): if (argv[0] is "--drive-detect") { gui_mode = FALSE; auto_detect_drives(); return apply_drive_changes(); } > - Drive editing seems broken. The list box only updates the second time I > hit edit. err:winecfg:applyDriveChanges unable to set volume label for > devicename of 'H:\', label of '' With my last two patches, this works for me. > - Browse in the "Add/Edit drive" dialog is a WRITEME Oh hum, good point. I suspect this still does nothing, I don't remember. We need to make sure / is mapped (there is a function to do this in drivedetect.c), trigger the shell directory select dialog, then if we had to map / automatically, unmap it again. Not too hard to implement. We can probably slide this for 0.9, it's not essential. > - Build system isn't right: I did a cvs update but the res files weren't > recreated properly. I had to do a make clean to get the gui updates. Probably my [ab]uses of make depend, can be ignored. > - "Add Application" has poor usability: we always use a file browser > dialog box even though the most common use case is just "foo.exe", ie > the user knows the name and doesn't care about the location. Worse we > start in the c:\windows\desktop folder for some reason, meaning users > might accidentally select a .lnk file! Well, we still use a file open dialog but at least it starts in c:\ now and is filtered on EXE files. If somebody wants to implement a natty dialog like the GNOME run window, go for it! This would be a nice usability improvement, especially if you implemented then used listview tile mode. > - The Add/Remove application buttons are *way* too big! Fixed > - Obviously, once audio autodetection has been moved into the drivers we > need to kill the audio tab. Still needs to be done. Not all that hard. > - Libraries tab just has generally poor usability, actually. The first > item in the radio group is "Builtin" meaning that's the one users are > most likely to select, it should be "builtin, native" followed by "native, > builtin" Lots of tweaks to this tab, I find it a lot more convenient to work with now. The main remaining problem is that enter always triggers OK in the applet itself, and when you're typing in a new DLL you want to add, you want enter to add it not close the window! Not sure how to fix this without messing up the property sheet API. > - We ask the user to understand a magic * symbol to set the default - what > is up with that? Fixed. > - There are no helpful default entries in the drop down box for setting a > DLL override, and when you add one the tree does not expand so to actually > *set* it you have to expand the tree then select the new override. It doesn't use a treeview anymore, but the combo box could definitely use some of the most common entries to give people a hint. > - We have way too many (eg, more than zero) tree controls in this app. Fixed. This simplifies the code enormously. I don't think there's really any problem with selecting the app you want to edit on the first tab and it means there aren't any wierd states anymore where you can have a selection in the treeview that doesn't actually mean anything. The titlebar now reflects the app you're editing. > - Drive mappings list is really unclear, there's no separation between the > "Drive X:" label and the unix path its mapped to. This is improved a bit now too but really I'd like to see us use the listview control with a header control here. So in summary the BIG things we need to do before we can consider winecfg good enough for 0.9 are: * Delete the audio tab and use autodetection at wine startup instead * Add a --drive-detect switch and use it from wineprefixcreate * Update the docs to reflect usage of the new tool (Brian is on this) After 0.9 we can look at more UI improvements, importing some artwork to make it prettier, maybe eliminating the property sheet as that's a big pain to work with (though, it may be also that our control is buggy :), and so on. Probably adding more prefs as well, for things like printing and fonts maybe. I'd like to see us get winecfg to some kind of finished, releasable 1.0 state before the end of the year though and then we can mark that task as done on the TODO list. thanks -mike

Sept. 29, 2004

Re: WINEDLLOVERRIDES for all dlls?

by Mike Hearn

> I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still > shows the downloaded native advapi32.dll being loaded. You need WINEDLLOVERRIDES="*advapi32=b" Yes I know that isn't what I said before. I suck :)

Sept. 29, 2004

Re: Upgrade management

by Mike Hearn

> I was always a fan of upgrades, but in the meantime I am more a follower of: > > > "If you upgrade to this new version, please re-setup your whole wine configuration > and merge over your data." > > This should only very seldom be the case anyway. > > This causes less work for us and less work for the user due to us breaking his update. It does rather discourage us from making improvements to the Wine configuration that could improve compatibility though, because everybody hates the hassle of upgrading and 99% of users will forget anyway. So, I think there's value in making it automatic. thanks -mike

Sept. 29, 2004

Re: WINEDLLOVERRIDES for all dlls?

by Steven Edwards

On Tue, 2004-09-28 at 23:09, James Hawkins wrote: > I'm working on getting ie6 sp1 to install without using any native > dlls. The install is fine until about 78% of the way through > installing the files, the installer loads a native advapi32 that it > downloaded to a temp directory and then the install seems to pause as > this message is continuously printed: > > fixme:thunk:CommonUnimpStub generic stub: ? > > I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still > shows the downloaded native advapi32.dll being loaded. Does > WINEDLLOVERRIDES only take dll's that are in the windows\system > directory into account? I have a feeling that the install would go > smoother if the builtin advapi32 was loaded instead of the native one. > I'm guessing that the installer is calling LoadLibary("path to native > advapi32")...that's just a guess though. What Windows version are you reporting? I sometimes test IE and it seems to be broken with win98 atm. Thanks Steven

Sept. 29, 2004

WINEDLLOVERRIDES for all dlls?

by James Hawkins

Hi, I'm working on getting ie6 sp1 to install without using any native dlls. The install is fine until about 78% of the way through installing the files, the installer loads a native advapi32 that it downloaded to a temp directory and then the install seems to pause as this message is continuously printed: fixme:thunk:CommonUnimpStub generic stub: ? I used WINEDLLOVERRIDES="advapi32=b" WINEDEBUG=+loaddll, and it still shows the downloaded native advapi32.dll being loaded. Does WINEDLLOVERRIDES only take dll's that are in the windows\system directory into account? I have a feeling that the install would go smoother if the builtin advapi32 was loaded instead of the native one. I'm guessing that the installer is calling LoadLibary("path to native advapi32")...that's just a guess though. -- James Hawkins

Sept. 29, 2004

Re: Progress Bar: Fix Class Style & Repainting (resend2)

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Isn't that going to cause a lot of flicker? This was the reason for > the existing code, because otherwise it looks really bad with apps > that update the progress bar a lot. The problem with Rob's patch is that it causes entire background of the progress bar to be repainted. Some time ago (3 years or like that) I wrote tests for progress bar and found that it invalidates background only when (oldPos < newPos) and it really has a separate WM_ERASEBKGND handler. Since then my code has been removed and rewritten (by you Alexandre) for no obvious reason IMO. -- Dmitry.

Sept. 29, 2004

Re: Problems installing IE6

by Joaquín Fernández

Stefan Leichter wrote: > > Hello, > > i have installed ie6 (SP1)some minutes ago on completely fresh wine enviroment > with installed dcom98 using cvs from 2 hours ago. I have a german version > from a cdrom. > > Here is what i did: > > 1. mv ~/.wine ~/.wine-old > 2. wine --version (create the new environment) > 3. create ~/.wine/config with: > -------------------------------------- > WINE REGISTRY Version 2 > > [DllOverrides] > "ole32" = "native" > -------------------------------------- > 4. wine dcom98.exe > 5. change ~/.wine/config to: > -------------------------------------- > WINE REGISTRY Version 2 > > [DllOverrides] > "advapi32" = "builtin" > "comctl32" = "builtin" > -------------------------------------- > 6. wine ie6setup.exe > > Install Mozilla ActiveX Control then and run wineboot. (i did not check this > two steps) > > Bye Stefan > > > Thanks a lot, Stefan, i was able to install IE6, but i don't understand. I made this steps before post in this list: 1) rm ~/.wine 2) wineprefixcreate 3) WINEDLLOVERRIDES="ole32=n" wine dcom98.exe 4) WINEDLLOVERRIDES="advapi32=b;comctl32=b" wine ie6setup.exe and never finish the installation. What's the difference????? i don't understand!!!!!!!! Regards Joaquín -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

Sept. 28, 2004

Re: Upgrade management

by Marcus Meissner

On Tue, Sep 28, 2004 at 12:46:12PM +0100, Mike Hearn wrote: > There are a bunch of different ways we may want to upgrade the users > configuration: I was always a fan of upgrades, but in the meantime I am more a follower of: "If you upgrade to this new version, please re-setup your whole wine configuration and merge over your data." This should only very seldom be the case anyway. This causes less work for us and less work for the user due to us breaking his update. Ciao, Marcus

Sept. 28, 2004