Re: joy.cpl icon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cool! Nice job. On 06/06/13 20:15, Austin English wrote: On Thu, Jun 6, 2013 at 2:15 AM, Joel Holdsworth j...@airwebreathe.org.uk wrote: For some reason, since I send in my icon for joy.cpl, it doesn't appear in the control panel - still only the wine glass fallback icon. Does anyone know why this is? I guess it will be a one line fix. Unfortunately I don't have time do this myself, but if someone has time, I think it would be worth resolving before the release. Best Regards Joel Holdsworth http://source.winehq.org/git/wine.git/commitdiff/6528aff97ba74fad20571acae33228a893bb4a7f -- -Austin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRsb0fAAoJEIsWlGmq62Igmv4H/j2xYSdeG1l7XnDT/a6C18bQ bBGxzziObaite5DL5N/Con6K8yfDvycNLmqS6Zn8Hq3MmyB/FE+xLC/JozHnDRr7 OA/mr89k9yldOGIH5pzgwU4cseOx8GSEg2dXxN1nDFT4tSvhJQSiinPnSeKR8/fY EeIl292c6a6SWLoXaAPMbOLK4/8wGQZBR3S8Ndr7LY+TrAvAQNU3+M9J2H/fXD4l lzEaydBSFbQHMg5JeKXgMnMFMsykZScnNO3cETgIQov5rvXs+JF+CooSZbC20311 OdZNXKZjGUOS+HaYTwpQqnKtBtVUXJtCJETLvnhGJ447qSkW6PszjUXOxvDAl9E= =MQh7 -END PGP SIGNATURE-
joy.cpl icon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For some reason, since I send in my icon for joy.cpl, it doesn't appear in the control panel - still only the wine glass fallback icon. Does anyone know why this is? I guess it will be a one line fix. Unfortunately I don't have time do this myself, but if someone has time, I think it would be worth resolving before the release. Best Regards Joel Holdsworth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRsFMgAAoJEIsWlGmq62Igf70H/jE97ibCOk2j2BMizaGkGzyW nAGQD0R9E3GXfdnGaUxzn21OPq3cu3/FapiTw1eN5Ns7Ec4b1cBLJ+ana1ElLIrO bz+yYGedqD0bYZq0D80MPE7t9S6jGy7939XGvkNLSMcZVOaBy8E2iroVnAILMNSB w1zbPhDXQGjHjRyBuYHZMhXTPhDz73s8+6JS7lZvCTaMmnF/dzZ6tW7DyTUIBdwx u3zUXn/j4nTNuNw3xGtK5wSYUZdNWxEx8RvQ1JrfuR9CWwLILTfFLB9d7OnSH/Rg 0sxBkjpSkOck25NN9gdQwdud0ERda1JurongrxUSHDXBBxghJ9BIk/gd+ZpP4cQ= =Hnk+ -END PGP SIGNATURE-
Re: msvcrt: remove hack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/05/13 12:56, Dmitry Timoshkov wrote: Christian Costa titan.co...@gmail.com wrote: and no modern gcc/other compiler that I can find cares. It was probably added because of a tool that warned of the unused parameter ... So it all goes in circles. ;) Ciao, Marcus So what about action = NULL instead? A checker tool should be instructed to ignore that kind of a warning instead. There are many legitimate cases when a function doesn't use all of its parameters, in that cases there is no need to take any special action to silence a warning IMHO. There is also __attribute__((unused_parameter)) but it's gcc specific. How is that better than 'unused = unused'? And it's even more typing... Just cast it to void: (void)unused_param; Thats the tidiest way IMHO. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRp0UeAAoJEIsWlGmq62Ig8mUH/06blo3lMqfU025dpA5NExVF mY/gTzccONBMP8uBxBey/qrwagG/zJI4Wq+nbDMRnoIEk9AayDqlL2KSVCcXQIH9 sTqQPLkpaYsfbvQixryWZ17W0y49Rmam3d9NzSlvVmjcKFcQuE8ke78wkIwMiOfN tJxKDwP4gETXH/867dWIVfdxB3LBGJpp2K02yspPW4lkTQ7u0WjKzElcm4icurQg W2vUVgvRJjcfPdiMpM2z99LJA83qnJifJ6Vf83qdqkf58oDqPVew59A9m8FFD4ev FGSq/o++UrJPvn27gOCmuIMC9L106FaABzP0euzuY8nlV5tlCyCBpw5nW3r4lVo= =8d7n -END PGP SIGNATURE-
Re: wineconsole screen scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/05/13 13:04, Hugh McMaster wrote: In my effort to improve wineconsole and its calculations of the largest possible window size, three scenarios come into play. 1. wineconsole with --backend=user (or more simply, 'wineconsole app.exe, in which case 'user' is the default). 2. wineconsole with --backend=curses. 3. wineconsole with --backend=curses, but no X server running. Detecting the screen resolution is a simple task with (1) and (2). SystemParametersInfo for (1) and wine's own XRandR for (2) can be used. My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before. The question is, should I worry about supporting such a scenario? wine works really well with windows-only embedded compilers. With wine as it is, you can just shove them in a Makefile like any other tool. Magic! This is an very useful use-case, and definitely important to preserve console support in X-less environments for this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRl6RFAAoJEHgUeO+Es/hFSPkH/06WW8fe/tBKPppBRiiwDO2/ LJRFV2glCyQzkmeN0BVR7vjHDndr002xLDJ+8wg4eKgFKxELfWf4r7fiyczkvCzF 05VXUt65m8ZqZuLMDujfUlkwY4bh4m8+E6e1MbtNFUWGTWyb3Hxtq6NF6ZHpTOs6 C/S4Ucv5kV9qA1gGh8JVjkDhmbueMRqFNUwZdwHAgY38Bm8Iv+UIQ0Chi6SBmR4R gbvxDrWUZvRsNdCWGSjU3gR61PR1/8s1JvfmSDC3ts6u829jOUmda43NXK097N/n Xfl1kcC92ePz1AnKV2e3eFMrbilcB/UXB4xqwa5ulBTaJN48+7QmomsIu0C3UBs= =uhWb -END PGP SIGNATURE-
Hi Res Icons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alexandre (+ Others), I notice you've been working on hi-res icons. I just have a couple of comments to chip in. So 2 years ago when I was doing the wine icon refresh, I decided not to try and tackle the problem of hi-res icons. Just getting the normal sized icons merged had proved to be a gargantuan task that took me over a year to complete - I didn't have the stomach to embark on another round of artwork. We also didn't support PNG icons in those days. As you can see in these hi-res icon patches, scaling icons is never as simple as people think. http://source.winehq.org/git/wine.git/blob/HEAD:/programs/iexplore/iexplore.svg As you can see here, scaling the iexplore icons really shows the limits of this artwork. The line caps are wrong in several places. The worst being in the highlight of the yellow swoosh at the bottom - you see the highlight doesn't line up with the border. A lot of things don't quite line up correctly. Moreover what were sharp single pixel lines in the 48x48 image have become fat strokes, which look rather play-schoolish to my eye. The solution is to have dedicated artwork specifically for these large sizes. This has been done in the Mango icon project: http://jimmac.musichall.cz/i.php?i=MIME2 http://jimmac.musichall.cz/i.php?i=git3 http://jimmac.musichall.cz/i.php?i=Tango-NG This is the work of Jakub Steiner and Lapo Calamandrei. They did a workshop on how to do this artwork here: https://www.youtube.com/watch?v=2T7833s2MJI Notice the fine detailing and beautiful shading. In the network filter they even used a paper texture for the card of the folder! These guys have done a fantastic job. So I wanted to sound out how much desire there is for this for Wine. I'm probably not going to be able to contribute this myself, due to time constraints. I wondered if there were any other developers cum artists interested in having a go. 2 years ago I asked Jakub if he would be interested in doing this, but he said he was quite busy. It might be worth reaching out to him or Lapo again, to see if they'd like to contribute. Also, I don't know how much this work is being driven by CodeWeavers Mac product, but another approach would be to for CodeWeavers to solicit contract work or a bounty for this. Jakub or Lapo might be more able to make time on those terms - but of course I don't know if that's a deal they or CodeWeavers would be interested in making. Another source of volunteers might be the tango-artists ML, but I don't know how many there are there. Finally, I've rebased my patch for the joy.cpl icon. It doesn't have a 256px icon though. Is this wanted? Best Regards Joel Holdsworth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRW/TtAAoJEIsWlGmq62IgaEcIAJYY9q/B3fA2AZQnR5M41qWn Q84e/5jrc1u2w1skmWAkCNdHNHu/R6AURklQ0Hysbnzxp+5GfftPHTKkRzA59cgs jVmkTSiqdVGGeGDRW2YWAcaFiH25xEOqSb9APzMLT4IRVypLbTwWYWhAsaZCa6+0 1USLRakqs5SF7+lCt5VcSHqiko/HPZZsTtNZYDy7cE4DPoNGbajPR9/0fEUfOEj+ b6xyu62tzPHfUcH4hj7YLa7ukJhq2Hh2ELA6gXnjr6yk+pZfx2uMTtfPZ4joWZzw 1DVcyoTkmeCOnasKJU2Obj7vdWgZxWG+WG4KTneH9a+rkSLo6T6Jojae+BXU4O8= =tNa1 -END PGP SIGNATURE-
re: Investigating iexplore/activex issues
On 26 July 2012 at 23:40 Dan Kegel d...@kegel.com wrote: I'm running into a similar problem, http://bugs.winehq.org/show_bug.cgi?id=23058 If you're using a different activex control, please file a new bug, with a way for others to reproduce the problem. Yes that does sound quite similar. I predict once page loading is fixed, this will be the main mode of failure. I'm not sure how easy it will be to find a public copy of the product, but I'll see if I can find one. Any chance you could add an HTML5 mode? http://praegnanz.de/html5video/ shows a bunch of HTML5 video player components, and lists which ones have Flash fallback for old browsers. You could turn it on if you detect a Linux client, and otherwise use the old activex solution. Yes, I would love for that to happen, and I've heard that there are plans in the pipeline. It's not so bad - there is a fallback on linux using a simple video object which works smoothly. Though that doesn't help for the annotations or the point-and-click ui for setting up the analytics, so to setup the more clever features of the device I have to go back to windows. Joel
Re: Investigating iexplore/activex issues
Hi Qian, That's the easiest solution I've heard so far. Unfortunately I ran straight into bug #25919 (http://bugs.winehq.org/show_bug.cgi?id=25918). Maybe I can find a work-about, unless you know the solution already? Joel On 27 July 2012 at 09:54 Qian Hong fract...@gmail.com wrote: On Fri, Jul 27, 2012 at 4:29 PM, Joel Holdsworth j...@airwebreathe.org.uk wrote: On 26 July 2012 at 23:40 Dan Kegel d...@kegel.com wrote: I'm running into a similar problem, http://bugs.winehq.org/show_bug.cgi?id=23058 If you're using a different activex control, please file a new bug, with a way for others to reproduce the problem. Yes that does sound quite similar. I predict once page loading is fixed, this will be the main mode of failure. I'm not sure how easy it will be to find a public copy of the product, but I'll see if I can find one. Any chance you could add an HTML5 mode? http://praegnanz.de/html5video/ shows a bunch of HTML5 video player components, and lists which ones have Flash fallback for old browsers. You could turn it on if you detect a Linux client, and otherwise use the old activex solution. Yes, I would love for that to happen, and I've heard that there are plans in the pipeline. It's not so bad - there is a fallback on linux using a simple video object which works smoothly. Though that doesn't help for the annotations or the point-and-click ui for setting up the analytics, so to setup the more clever features of the device I have to go back to windows. Joel Hi Joel, Would you like to try np-activex [1] ? np-activex is a npapi plugin for Chrome on Windows, at the same time, it is a ActiveX wrapper. With np-activex, users can load ActiveX control in Chrome for Win, without iexplore. Actually, with Wine's help, np-activex work on Linux as well, though you have to use Wine to run Chrome for Win on Linux. How ever, there are some bugs which will bring us to troubles: Bug 21232 - Chrome can't load any webpage unless --no-sandbox is used Bug 27248 - cannot unpack *.crx (extensions or themes) in Chrome unless --single-process is used Bug 27168 - chromium-based apps can't load https sites Unfortunately, to workaround all these bugs, we have to use special version of Chrome with special version of np-activex. I'm glad if this example is helpful for you: A guide to sign in China Merchants Bank (CMBChina) on Linux: Wine Chrome + ActiveX for Chrome + User Agent Switcher https://groups.google.com/forum/#!msg/non-ie-online-banking/EodETqFrcY0/ySq5PTXax_MJ There might be other bugs related to Chrome/ActiveX, some of them are covered in this list: http://code.google.com/p/online-banking-with-wine/wiki/buglist Let me know if I can help you further, also please let me know if you have good news ;-) Good luck. [1] http://code.google.com/p/np-activex/ -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Investigating iexplore/activex issues
Hi Jacek, thanks for that information. That really helpful. I might be able to find my way through to the solution. Joel On 27 July 2012 at 13:58 Jacek Caban ja...@codeweavers.com wrote: Hi Joel, On 07/26/12 20:32, Joel Holdsworth wrote: Hi All, I've recently begun working at VCA technology on an IP security camera system. I'm mostly doing embedded linux stuff, but bhe code I'm working with uses an ActiveX control to show the video and the overlaid annotations. I've doing quite a lot of experimentation trying to get the page work correctly on Wine. So far the results have been rather disappointing: wine git-head: wine builtin iexplore - page loads blank, though wireshark shows that html+js has been received. Various ole related fixmes. It's most likely a problem with supporting scripts on the used b the page. I'm fixing such problems, but the scope is so bit that it takes time. IE7 IE8 installed to seperate prefixes - IIRC page fails to load wine 1.4 wine builtin iexplore - page loads, but activex control fails to display. Soon after 1.4 release, Wine started handling scripts itself, instead of using Gecko for that. It causes a massive known regression, but it allows us having IE compatibility on scripting level, which was previously impossible. That's the most likely cause of changed behaviour. Does anyone have any suggestions for how I can better investigate these issues? It's a complex question (see bellow)... The best first step would be filling a bug and including jscript,mshtml traces. And what is the status of ActiveX in wine - is it likely to work at all? From my experience, there is a good chance that your ActiveX will work in our builtin IE. However: - it requires manual ActiveX installation. iexplore won't do that for you - the page must work good enough to get to the point of embedding the ActiveX (eg. if it's created by JavaScript code, that code must run up to the point) - ActiveX control may hit problems all across Wine. It's allowed to use any win32 API, so even if its embedding code is supported by our MSHTML, it may fail due to some random other API problem Jacek
Investigating iexplore/activex issues
Hi All, I've recently begun working at VCA technology on an IP security camera system. I'm mostly doing embedded linux stuff, but bhe code I'm working with uses an ActiveX control to show the video and the overlaid annotations. I've doing quite a lot of experimentation trying to get the page work correctly on Wine. So far the results have been rather disappointing: wine git-head: wine builtin iexplore - page loads blank, though wireshark shows that html+js has been received. Various ole related fixmes. IE7 IE8 installed to seperate prefixes - IIRC page fails to load wine 1.4 wine builtin iexplore - page loads, but activex control fails to display. Does anyone have any suggestions for how I can better investigate these issues? And what is the status of ActiveX in wine - is it likely to work at all? Thanks Joel
joy.cpl icon
Hi All, I've just submitted an icon for joy.cpl to wine-patches. Unfortunatly I've uncovered a problem with the buildimage script. When I first wrote the script, I used the rsvg command to convert svg to png. rsvg has been depreciated in favour of rsvg-convert, which has slightly different semantics: rsvg-convert in.svg out.png instead of rsvg in.svg out.png Moving over to rsvg-convert is trivial of course, except one question. Is it present on enough platforms? I'm using Ubunut 12.04. Is maintainer mode meant to work on Debian Squeeze? We could support both, but I'd rather not do that. Joel
Re: Are we missing the small folder_open icons?
Yes I agree, that FIXME looks strange. As you say, folder_icon.ico has all three icon sizes inside, so why is included in the resource three times? Does native have 3 icon resources? Is it ok to use the same multi-size icon 3 times? Joel On 20 April 2012 at 06:53 Francois Gouget fgou...@free.fr wrote: In dlls/shell32/shell32.rc I see the following fixme: /* FIXME: Following three resources are not yet added */ /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_SMALL ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_LARGE ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_SMALL_XP ICON folder_open.ico However folder_open.ico is generated from an SVG file and we seem to be having it in multiple sizes. Also this fixme has been there forever. So is there really still something to be fixed? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Lotto: A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U
Re: Regression testing breakthrough
Alternatively, have you considered doing a .tar.gz of every build snapshot, and placing that on a server somewhere? e.g. a folder full of36def4af0ca85a1d0e66b5207056775bcb3b09ff.tar.gz files? Then one could write a simple wine regression bisect tool that implements similar semantics to git bisect, but would essentially wrap wget. Then in your server you could have an index file which is a list of the sha commit ids. This would save the user having to clone a 26Gb repository when most of the commits will be irrelevant. Extra bonus points for doing a better job of compressing the small deltas between binaries*, rather than compressing full wine builds. Joel * Are binaries deterministic like this? or do they tend to be completely scrambled? On 18 October 2011 at 09:45 Damjan Jovanovic damjan@gmail.com wrote: Hi Since the beginning, I've had issues with regression testing. Despite the fact it's very useful, it takes forever, it's easy to make a mistake (especially during reverse regression testing), users find it too long and technical, and only a small minority of regressions are ever bisected. And several patches need backporting to allow older versions of Wine to compile and run on today's make, gcc, and libraries - this is the case even for the 1.0.x releases from less than 3 years ago! The problem is of course compilation. configure takes at least 40 seconds, without any way to speed it up on multi-core CPUs. make takes 5 minutes, and it's only taking longer as Wine gets bigger. Compilation is fundamentally complex and technical to users. But what if we had precompiled binaries, and regression testing consisted of just running different versions of Wine? Wine binaries take up about 122 MB and take over 5 minutes to compile. There's now 35770 commits between 36def4af0ca85a1d0e66b5207056775bcb3b09ff (Release 1.0) and origin. That's about 4.4 terrabytes of storage and over 4 months of compilation, if each of those versions had to be compiled and installed into its own prefix, way beyond what most users are willing or able to store or do. Most patches however end up affecting only a few binary files in the end, and compiling successive versions allows make to be very quick. So I've written a tool that compiles Wine and adds each commit's binaries into a Git repository. It knows how to compile old versions of Wine (currently as far back as 1.0). It knows that commits affecting only ANNOUNCE, .gitignore, and files in dll/ or programs/ ending with .c and such don't need to go through the endlessly slow configure, only make. It is stateless: if interrupted, it can resume from the last successful commit. It works around bugs in GNU make (you won't believe how many there are...). This tool compiled all 35000 or so commits from Wine 1.0 to around 4th October 2011 in only 7 days, generating a Git repository of Wine binaries that's only 26 gigabytes in size. Regression testing with binaries is a pleasure: it takes only a few seconds :-) on each bisection. I bisected a 16 step regression in just 20 minutes, and most of that time was spent running the application and dealing with 2 X-server crashes. I haven't figured out how to make the binaries available to users. Few users can clone a 26 gigabyte repository, and even fewer places can serve that much to multiple users. Maybe Git can compress it further? The other idea I had is that users should be able to regression test through a GUI tool. Maybe the GUI tool can just download and run the +/- 122 MB binary snapshots for specific commits, instead of having the entire binary repository locally? Any other ideas? Would you like to see this tool? Can I send an attachment with it? Thank you Damjan Jovanovic
Re: Compilation error with latest wine
+1 I have the same issue in Ubuntu 10.10 Joel
Re: Compilation error with latest wine
Hmm, Looks like it was caused by commit 9c4432f69d91007d02c52c50ba565ca795f44765, I think the CLSID isn't being included properly. Probably easy to fix. Joel
Git server down?
nmap source.winehq.org shows no git port. Any ideas?
WineSkin v0.01
Hi All, I just wanted to highlight my new project - WineSkin http://www.airwebreathe.org.uk/wineskin/ WineSkin is an attempt to create a set of scripts that auto-generate the necessary themes, visual styles and registry keys to visually integrate wine with the host desktop environment. At the moment I only support integrating 5 icons with the host, when the DE is Gnome. I'm hoping that the project will grow and eventually I'll be able to integrate with KDE and MacOS. For now I'm just focussing on trying to get any kind of good integration going. If anyone has any thoughts or comments, let me know; I'd love to hear them. All the best Joel
Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel
It says apply failure for 3/3, so that's probably why 2/3 wasn't committed also. Problem is that there are a lot of translation updates these days and some patches affect winecfg .rc files. I guess you should rebase on git head and resend patch. However, I see there is still one patch on the pipe that affects Es.rc from winecfg, so that might again cause some problems. Octavian Ok, I've rebased now, fixed up the problems, and resubmitted.
Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel
Does it fix a bug? If not, AJ may have placed it aside until after Wine 1.2 is released. Indeed. Adding new strings to translate will/should probably have to wait until after Wine 1.2, so we can get as many languages as possible at 100% when 1.2 is released. OTOH, if it new strings fix a problem, then go for it. The patch doesn't add any new strings - just modifies the dialog layout: http://www.airwebreathe.org.uk/space/new-about-screen.png . I'm trying to give the about panel a degree of graphical polish in time for the release.
Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel
On Wed, 2010-06-02 at 23:56 +0100, Joel Holdsworth wrote: Signed-off-by: Joel Holdsworth j...@airwebreathe.org.uk --- programs/winecfg/Bg.rc| 19 + programs/winecfg/Cs.rc| 19 + programs/winecfg/Da.rc| 19 + programs/winecfg/De.rc| 19 + programs/winecfg/En.rc| 19 + programs/winecfg/Es.rc| 19 + programs/winecfg/Fi.rc| 19 + programs/winecfg/Fr.rc| 19 + programs/winecfg/Hu.rc| 19 + programs/winecfg/It.rc| 19 + programs/winecfg/Ja.rc| 19 + programs/winecfg/Ko.rc| 19 + programs/winecfg/Lt.rc| 19 + programs/winecfg/Nl.rc| 19 + programs/winecfg/No.rc| 19 + programs/winecfg/Pl.rc| 19 + programs/winecfg/Pt.rc| 32 +++--- programs/winecfg/Ro.rc| 19 + programs/winecfg/Ru.rc| 19 + programs/winecfg/Si.rc| 19 + programs/winecfg/Sv.rc| 19 + programs/winecfg/Tr.rc| 19 + programs/winecfg/Zh.rc| 38 + programs/winecfg/about.c | 88 + programs/winecfg/idb_wine.bmp | Bin 14614 - 0 bytes programs/winecfg/resource.h |7 +++- programs/winecfg/winecfg.rc |4 +- 27 files changed, 342 insertions(+), 226 deletions(-) delete mode 100644 programs/winecfg/idb_wine.bmp Any thoughts about this patch? I guess there's a reason why 1/3 was merged but not 2/3 and 3/3. Anything I can fix?
Re: [PATCH 4/4] winecfg: Cosmetic improvements to the about panel
Are PNG icons supported? It didn't look like they were when I checked.
Also, sizes larger than 255px, are only partially supported in the
format. So any app, including wine would have legitimate reasons to
reject such a file.
On Tue, 2010-06-01 at 11:38 +0200, Alexandre Julliard wrote:
Joel Holdsworth j...@airwebreathe.org.uk writes:
+GpImage* LoadPNGResourceW(HINSTANCE hInst, LPCWSTR lpName)
+{
You should be able to use an icon for this, there shouldn't be any need
to involve gdiplus.
Re: [PATCH 4/4] winecfg: Cosmetic improvements to the about panel
On Tue, 2010-06-01 at 20:05 +0200, Alexandre Julliard wrote: Joel Holdsworth j...@airwebreathe.org.uk writes: Are PNG icons supported? It didn't look like they were when I checked. Also, sizes larger than 255px, are only partially supported in the format. So any app, including wine would have legitimate reasons to reject such a file. png icons are not supported but uncompressed ones should work fine. If it really doesn't work you can always use a bitmap. Are you sure? I really do think using PNGs is preferable. The PNG is 22.8kB, whereas a BMP would be 237.2kB - over 10x larger! If I use a BMP, it will make the winecfg executable bloat up 25%. By contrast importing GDI+ or WIC seems to me like a small price to pay.
Re: [PATCH 4/4] winecfg: Cosmetic improvements to the about panel
On Tue, 2010-06-01 at 22:39 +0200, Alexandre Julliard wrote: Joel Holdsworth j...@airwebreathe.org.uk writes: Are you sure? I really do think using PNGs is preferable. The PNG is 22.8kB, whereas a BMP would be 237.2kB - over 10x larger! If I use a BMP, it will make the winecfg executable bloat up 25%. By contrast importing GDI+ or WIC seems to me like a small price to pay. We can add support for PNG icons after 1.2. Adding more dependencies to winecfg is much more risky than a bloated icon. Ok, that's cool. I'll try and get that sorted within a couple of days. One other question; I got some feedback from Andre Herschel saying that the patch failed to apply to some of the language rc files. I suspected he ran into problems with varying character encodings. Did the patch [PATCH 4/4] winecfg: Cosmetic improvements to the about panel apply cleanly for you?
Re: Last Minute Submission: WinecfgAbout
Yeah the link control doesn't work. I think the problem is with shell32/shlexec.c. I get the attached output when I try with WINEDEBUG= +exec . For some reason it seems to be appending a backslash on the end of the URL. It looks like a very simple problem to fix. If you run wine winebrowser http://www.winehq.org; on the command line, you get native firefox. ...but then if you run wine winebrowser http://www.winehq.org\ \ - with an escaped backslash it works just as well; worth investigating. Even if we don't get it fixed in time, I think the link is worth having - even if just for purely aesthetic reasons. Joel trace:exec:ShellExecuteA (nil),open,http://www.winehq.org;,(null),(null),5 trace:exec:ShellExecuteExA 0x32d084 trace:exec:SHELL_execute mask=0x0400 hwnd=(nil) verb=Lopen file=Lhttp://www.winehq.org; parm=(null) dir=(null) show=0x0005 class=not used trace:exec:ShellExecute_FromContextMenu Lhttp://www.winehq.org; trace:exec:ShellExecute_GetClassKey ext = L.org trace:exec:SHELL_execute execute:Lhttp://www.winehq.org,L,L; trace:exec:SHELL_ExecuteW Execute Lhttp://www.winehq.org; from directory L trace:exec:SHELL_ExecuteW returning 2 trace:exec:SHELL_FindExecutable Lhttp://www.winehq.org; trace:exec:SHELL_FindExecutable Returning SE_ERR_FNF trace:exec:SHELL_execute_url Got URL: Lhttp://www.winehq.org; trace:exec:execute_from_key Lhttp\\shell\\open\\command Lhttp://www.winehq.org; (null) L L trace:exec:execute_from_key got cmd: LC:\\windows\\system32\ \winebrowser.exe -nohome trace:exec:SHELL_ArgifyW 0x328720, 1024, LC:\\windows\\system32\ \winebrowser.exe -nohome, Lhttp://www.winehq.org;, (nil), 0x32c004 trace:exec:SHELL_ArgifyW used 43 of 1024 space trace:exec:execute_from_key Got ddeexec Lhttp\\shell\\open\\ddeexec = L\%1\,,-1,0 trace:exec:dde_connect Launching LC:\\windows\\system32\ \winebrowser.exe -nohome trace:exec:SHELL_ExecuteW Execute LC:\\windows\\system32\ \winebrowser.exe -nohome from directory L trace:exec:SHELL_ExecuteW returning 33 trace:exec:SHELL_ArgifyW 0x329128, 256, L\%1\,,-1,0, Lhttp://www.winehq.org;, (nil), 0x32c004 trace:exec:SHELL_ArgifyW used 33 of 256 space trace:exec:dde_connect L\%1\,,-1,0 Lhttp://www.winehq.org; = L\http://www.winehq.org\,,-1,0; err:winebrowser:get_url_from_dde Unable to retrieve URL from string L\ err:winebrowser:wmain Usage: winebrowser URL trace:exec:SHELL_execute retval 33 On Sun, 2010-05-30 at 16:41 +0200, André Hentschel wrote: Am 29.05.2010 17:17, schrieb Joel Holdsworth: Hi All, I know it's late and we're in freeze mode now, but I wanted to offer some work I've been doing: http://www.airwebreathe.org.uk/space/new-about-screen.png Basically I've been giving the about page of winecfg a face lift. It seemed like a good idea to put some polish on it in time for the release. Is there any interest in pushing this? or is it too late? As Nikolay said, it is safe. The patches are all fairly straightforward. The only gotcha is that the modification to the page layout has to be carried across all languages without introducing any errors. I'm planning to do this with a simple script, but is there a simple way of switching between languages quickly? So I can check the layout doesn't get broken? Also, if I submit these patches - to be merged now or later, would it be better to submit all the resource language patches inidividually? or language by language? What do people think? First: Good idea and great job! It goes with the new Icons. Like Nikolay i am a bit scared of the link control. Maybe that should not be included in the first patch and you can send it later when it surely works. Against Nikolay's opinion i think you didnt changed the layout too much(compared one by one) so it is ok.
Last Minute Submission: WinecfgAbout
Hi All, I know it's late and we're in freeze mode now, but I wanted to offer some work I've been doing: http://www.airwebreathe.org.uk/space/new-about-screen.png Basically I've been giving the about page of winecfg a face lift. It seemed like a good idea to put some polish on it in time for the release. Is there any interest in pushing this? or is it too late? The patches are all fairly straightforward. The only gotcha is that the modification to the page layout has to be carried across all languages without introducing any errors. I'm planning to do this with a simple script, but is there a simple way of switching between languages quickly? So I can check the layout doesn't get broken? Also, if I submit these patches - to be merged now or later, would it be better to submit all the resource language patches inidividually? or language by language? What do people think? Joel
Re: [PATCH 09/16] Replaced mycomputer.ico with a Tango compliant icon
Hi Joel, I think this has been mentioned before, but the monitor icons (32-bit and 8-bit for size 32) show a wider lower half of the monitor compared to the upper half (I think the 32-bit size 22 as well). I've heard feedback about the screen colour before, which I've resolved. Never any queries about the shape of the screen. The reason it's slightly wider at the top to the bottom is that it is drawn in perspective, which is how the screen is drawn in the Tango base set. I believe only The 48px-32bit and 48px-8bit have this.
Re: new icons
On Fri, 2010-04-09 at 15:50 +0200, wy...@volny.cz wrote: Hi, this will be just a short note... I noticed some new icons and i like them! W. There's plenty more to come: http://www.airwebreathe.org.uk/wine-icon/ !
Icon Patches Feedback
Hi, Are there any thoughts about my latest round of icon patches? Thanks Joel
Re: [PATCH 02/48] Added new icon build rule
I'm certainly open to suggestions on how to reduce the work needed for the first step, but it needs to be a step in the right direction. Adding 500 files and reorganizing many directories is not a good intermediate measure. I definitely want your work committed too, in fact I included it in the requirements for the 1.2 release; but I'm not willing to make a mess of the source tree just to get this in sooner, as I'm sure you understand. Ok, thanks for letting me know. I'll investigate multipage SVG and see what I can come up with All the best Joel
Re: [PATCH 02/48] Added new icon build rule
Ok, I have good news and bad news. The good news is that multipage is standard now in SVG 1.2, and it is possible to embed a raster image in the SVG if you encode it in base64. Embedded images are partially supported in inkscape via python extensions. The bad news is that you can't set the canvas sizes of individual pages - only the orientation. Ideally we would set the bounding box of each page. One solution would be to set the canvas size to some arbitrary size, then tag the individual pages with custom attributes from some kind of wine namespace extension, that would tell the renderer what boundary box to draw with, and what bit depth to sample to. The alternative solution (which I favour) would be a one canvas workflow, which some Tango artists are using. This was the approach I took when I was making icons for Lumiera: http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob_plain;f=icons/svg/tool-arrow.svg;hb=HEAD In this solution you have a single page with multiple icon images present. You then place on top of these images magic invisible rectangles which have been tagged so that the renderer script knows to treat these as boundary boxes. For wine's purposes, you would then need embed to the canvas any raster images and tag these in a similar way which instructs the renderer to decode the base64 into a files. Multiple vector rendering would then combine together with multiple raster images unpacked, and these would be bundled into an ico. The great advantage is that inkscape supports this stuff today, so it's not so bad for artists. How does that sound? Joel
Re: [PATCH 02/48] Added new icon build rule
Alexandre Julliard julli...@winehq.org wrote: Joel Holdsworth j...@airwebreathe.org.uk writes: @@ -188,6 +188,11 @@ filter: dummy .man.in.man: LC_ALL=C sed -e 's,@bindir\@,$(bindir),g' -e 's,@dlldir\@,$(dlldir),g' -e 's,@PACKAGE_STRING\@,@PACKAGE_STRING@,g' $ $@ || ($(RM) $@ false) +# Rules for icons + +ifdef SVG_SRCS + +# Depreciated icon build rule .svg.ico: $(RSVG) -w 16 -h 16 -f png $ $*-16.png $(RSVG) -w 32 -h 32 -f png $ $*-32.png @@ -195,6 +200,17 @@ filter: dummy $(ICOTOOL) -c -o $@ $*-16.png $*-32.png $*-48.png $(RM) $*-16.png $*-32.png $*-48.png +else + +resources/%-32.png: resources/%.svg + $(RSVG) -f png $ $@ + +resources/%.ico : resources/%-*-4.png resources/%-*-8.png \ + resources/%-16-32.png resources/%-32-32.png resources/%-48-32.png + $(ICOTOOL) -c -o $@ $^ + +endif That's GNU make specific, you can't do that. Yes I wondered if that might be the case. Do you (or anyone) have any thoughts about how to approach this? The .svg.ico suffix rule that's present at the moment works if there's a 1:1 relationship; one svg results in one ico. My problem is that a 9:1 relationship is required. Do you have any suggestions about how to make a generic rule to do that? Does it require changes to makedep? Also please don't send such a huge patch series. The first step should be to get just one icon committed with the proper infrastructure. Then you can consider sending more of them, preferably one dll at a time.Sure - I can understand that. The reason I sent so many was that I wanted to show you that I don't plan to leave a depreciated SVG build rule lying around. I also wanted you to see and comment on my approach of creating resources subdirectories in these dlls like user32 has, and then putting the icon images in these. What do you think? Joel Holdsworth
Re: [PATCH 02/48] Added new icon build rule
I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories. I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls. The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more. Now the question is what to do about it? The two approaches I can see are to keep them independant and stored neatly, or to package them somehow. Keeping them independant is ideal from the artist's point of view because the SVGs and PNGs can be viewed and editied in their native format. I could package them together into an archive of some sort e.g. an icon.tar.gz file. That would make the build rules easier, but it would mean the individual images could not be individually versioned, and make them slightly harder to edit. An alternative we discused was to use a .ico rather than a .tar.gz as an image repository. However this has several problems: 1. Ugly blurring of the line between source binary and compiled binary: The build rule becomes 1x.ico + 4x.svg - .ico. Kinda circular. 2. .ico files are a real pain to work with from the artist's point of view. It's a very unusual image format. 3. It's so easy to screw up the icon's internal structure, or change the format of a sub-image without meaning to. Many image editor apps will not generate a byte for byte identical file in an open-edit-save process, and many image editors would subdly change the ico format, and git version history would not make that kind of change clear. 4. Even then you're still left with 4 images - 1x .ico and 3x .svg, so the problem is still pretty bad. I favour the individual images approach, or I could do a package approach if you like, but I can't see how a .ico package could work. Do you see my problem? Joel
Re: [PATCH 02/48] Added new icon build rule
On 22 March 2010 at 15:37 Alexandre Julliard julli...@winehq.org wrote: Joel Holdsworth j...@airwebreathe.org.uk writes: I still think that having to commit 10 source files per icon is not acceptable, even with subdirectories. I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls. The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more. As far as I understand it's possible to store everything in a single SVG file. I don't know if tools like inkscape can support this directly, but it's all XML so a simple perl wrapper should be able to do anything we need. It is possible with a multipage SVG (which Inkscape doesn't support yet, and can't be rendered RSVG) and embedded bitmaps for the hand tweaked images (which are at beta stage AFAIK). That's bad news, but these obstacles can be overcome by me spending a lot of my time (which these days is in really short supply) writing scripts in Perl, but that would require me to use Perl (which I don't know and would have to learn)*, and could take several more months. It would also require a dependancy on some kind of command line image handling tool like ImageMagick or Python image stuff (which I'm sure you won't like) because RSVG only renders to 32-bit, but we need to output to 4-bit and 8-bit without screwing up these palette (which may be very hard). The end result would be 1 file rather than 9, but in a format which is harder even than ico for artists to work with given the state of todays tools. * I do use python though - is there any in the project? Speaking personally: This project has already taken me over a year to get this far, and after all this painstaking work I'm really keen to get it out to the world, but I'm so short of time right now, and it feels like every time I try and submit, there are more of these never ending hoops to jump through. From my perspective I won't abandon this work that I've spent so much time on, but it's becoming this never ending nightmare of obstacles. I'm looking at the big picture and wondering; is turning a very minor mess of 9 files into 1 per icon really the best use of my time, when I could be productively contributing to areas of need within the FOSS world that will have a real effect on FOSS users. I want to keep pursuing this and I respect your opinion very much as the veteron maintainer of this project. Your uncompromising comittment to quality has resulted in an excellent and long standing project, it's just that I'm finding the lack of flexibility quite hard to cope with. Is there no way we could compromise on this? Joel
Tango Icon Questions
Ok, We seem to have two questions that need to be resolved before the tango icons can be merged. First: The SVGs. A little background on how I make the icon set: The icon set has been assembled from different sources of artwork. Some my own, some from other people, so there's a certain amount of variation in the formats that I've received. In every case, I have had to do a certain amount of work to produce the 9 or 10 sub-images of an ico. Rather like fonts, in icon art, the size of a pixel is significant relative to the size of graphical elements. This effect is particularly pronounced at the smaller sizes: 16x16 and 22x22. At smaller sizes, manual intervention in the vector artwork becomes increasingly necessary. Graphical elements have to be tweaked to align to pixel boundaries or resized, rearranged, or removed altogether. Low colour depths pose further problems. In 8-bit icons we only have 1-bit transparency. Drop shadows must be removed, and the icon must be adjusted in a raster editor to remove jagginess in the boundaries. These are exported as PNGs, and in some cases I kept the GIMP xcf.bz2s. 4-bit icons are still harder. Here the icon has to be so radically adjusted, that the original SVG really only forms a template for a piece of pixel art. I tend to do this work with the wine glass hidden in the SVG rendering, and then overlay a pre-rendered wine glass. Again, these are expored as PNGs, and in most cases I kept the GIMP xcf.bz2s. In an ideal world, we would have one SVG source file, which would be versioned in Git, which we would render to different sizes and depths as part of the build process. I hope you can see how this would be impractical because of the amount of manual raster work that has been needed. The only build scripts that I have are scripts that automatically compile my PNGs into ICOs, but this step wouldn't really help the project much, because the PNG is no less a binary blob than the ICO. To further compound the issue, I've found 2 bugs in icotool that cause it to create ICOs that are formatted incorrectly, and cause Wine to misbehave. For my ICO scripts I wrote a simple tool called fix-icon which tweaks the files, to correct the 2 types of problem. I've tried to contact the author of icotool about this, but as yet haven't got a response. So in conclusion, I think the best thing would be for me to tidy my icons project folder, and submit that to git or wine-pub-ftp. I think we need to accept that some images are PNG, some SVG and some XCF.BZ2, depending on the original source, and I don't think we can do automated render steps as part of the build. The other question is about attribution. By now, ALL the icons have had some input from me in one way or another; they're all a derivative work. I'm planning to just submit the icons in the current round, as shown on the website: http://www.airwebreathe.org.uk/wine-icon/ - no bitmaps this round, just shell32.dll, user32.dll, and Programs icons. The sources of these are: * Tango Base - Public Domain * Scott Ritchie - oic_winlogo.ico - the Wine Glass * Jakub Steiner - oic_bang.ico - GPLd, but I have an e-mail of him agreeing to relicense * Ulisse Perusin - winemine - GPLd, but have e-mail agreeing a relicense. * Joel Holdsworth - my original work - LGPLd. What would be the best way for us to attribute these? I guess we need to do things properly with regard to licensing, but I think the authors are all quite easy-going. Any thoughts Thanks Joel
Tango Icons Ready to Go
Hi All, I've spoken to the authors of the two icons that needed their licenses resolving. They've agreed to relicense them, so the Tango icons are ready to go. I've sent a pull request to wine-patches. Best Regards Joel Holdsworth
Re: Tango Icons (Almost) Ready to Go!!
On Thu, 2009-12-31 at 11:34 +0100, Alexandre Julliard wrote: Joel Holdsworth j...@airwebreathe.org.uk writes: My final question is about what to do with my source artwork. The artwork has been collected from a variety of sources. Some is SVGs, some gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the wine source repo, but does anyone have any bright ideas where these files *should* go? They'll need to be published in case the icons ever need to be changed in any way. Ideally they would all be SVG, we already have the infrastructure for that, and for regenerating the icons from it. Though I don't know how that would work for low bit depths, it probably needs some makefile work. Yes - I agree. However, I don't think it can work. It's really only the 32-bpp and 32x32 and 48x48 that can be generated from vector. The rest have all had at least some pixel work done. Some are completely done in raster. This is a reality of making icons; like hinting a font there's a lot of manual intervention at small sizes and low depths. That's one of the reasons it's taken so long to make the set. To make matters worse, a few of the icons were *acquired* as pngs or xcf.bz2s, which means I have no svg to begin with. It's all a very mixed bag. Complicating things further, I've found two bugs in icotool, which means that I have to run the compiled icons through my own icon tweaker program that fixes up the problems with the file (I've contacted the original author about the problem). For this reason I think the best thing would be for me to tidy up my project directory and upload it as a tarball somewhere. There's enough source material there so that someone could come and adjust the icons - even it's not as elegant as having it tied into the build process. Another question: When the time comes, what would be the best way to submit the icons? I have 36 patches each of which is going to be many kilobytes. Will the wine-patches mailing list take such large attachments? Would it be easier to send you a git pull request from my gitorious repo?
Re: Tango Icons (Almost) Ready to Go!!
On Thu, 2009-12-31 at 10:20 +0100, Warren Dumortier wrote: Thanks for all your work (is there some screenshot)? There's no doubt that the Tango icons are good, but would it be possible to easily make icon themes maybe, to have Oxygen icons for example? If i understand it's hardcoded, like on Windows, but making a theming feature is probably a lot of work right? There will be some theming work coming later when someone finishes implementing the uxtheme stuff. My icons are about getting a base theme that works well. The point of Tango is that it shouldn't look to badly out of place on Mac, KDE, Gnome or even Windows. That's a good starting point, which we can build upon if someone can implement a wine theme bridge.
Tango Icons (Almost) Ready to Go!!
Hi All, I'm pleased to announce that after a lot of work lately I've pretty much completed the graphics for the icons for shell32, user32 and the programs all sizes and screen depths: http://www.airwebreathe.org.uk/wine-icon/ There are a few minor things left to do: * comctl32: Finish and submit - only idb_std_small.bmp needs to be upgraded. Only idb_std_small.bmp is 32-bit in XP, and Vista * comdlg32: Convert bitmaps to 8-bit. Maybe rework comdlg32 so that the graphics are stored as a icons not bitmaps for so that different colour depths can be handled elegantly. What does windows do? * credui: Test on a low bit-depth platform, and submit. * cryptui: Redo emblems on certwarning.bmp, certerror.bmp, and convert bitmaps into icons for so that different colour depths can be handled elegantly. * winecfg: new transparent bitmap won't work without xrender on a 32-bpp screen. Think again. * wine: image lists still strip the alpha channel. talk to thunderbird about 32-bit DDBs * control, dxdiag, iexplore, winecfg: These programs currently do not have an icon, and although my patches add the icon to the src dir, further patches will be needed to add the icon to the progam's resources, and display them in the app windows. These things are all relatively minor, and I think at this stage it would be good to merge as soon as possible. The only major issue that remains is that there are 3 icons from Gnome that need to be relicensed as LGPL for our use. I've e-mailed the gnome artists mailing list, so hopefully we'll hear back from them soon. Once this is done I'm suggesting we merge the icons for shell32, user32 and the programs. If you're interested you can try them right now at the public-beta-2 branch of my gitorious repo: http://gitorious.org/wine-tango/wine-tango/commits/public-beta-2 My final question is about what to do with my source artwork. The artwork has been collected from a variety of sources. Some is SVGs, some gimp .xcf.bz2s, and some plain PNGs. I guess these shouldn't go into the wine source repo, but does anyone have any bright ideas where these files *should* go? They'll need to be published in case the icons ever need to be changed in any way. Any thoughts? Best Regards Joel
Wine Icons - final round
Hi All, I wanted to fill you in on the progress on the Tango icon set. You can see it here: http://www.airwebreathe.org.uk/wine-icon/ Please let me know what you think - or if you have any comments. After the last two rounds, I'm hoping that we should basically be at a stage where most people are happy. The main change since last time is that I've replaced the user32 icons with icons that are similar to the Windows 7/Vista standard - but Tango compliant. I was unable to clarify the license for the icon I was using for the ramdisk icon, so I redrew one of my own - a DIMM, which in the end is more suitable than the SOIC chip we had before. The other major change is that I've decided to hold off on cryptui.dll. I'm not happy with the artwork yet, and cryptui.dll needs to be modified so that it uses HICONs rather the HBITMAPs, which don't cope with different colour depths well. When everyone is happy, I really need to freeze the icons from further modifications, because I need to begin the laborious process of making 8 and 4-bit versions. If anyone would like to help with this I'd be happy to have some helpers. But for now let me know if you have any thoughts. Best Regards Joel Holdsworth
Re: [try 4] Add help message box to dxdiag implementation
I'm just wondering how easy would it be to do something simple with a proper dialog template. The reason I ask is that I've been working on an icon for dxdiag (http://www.airwebreathe.org.uk/wine-icon/), and it'd be nice if there was a dialog ready to receive it. It's no big deal though. What do you think? Joel
Re: Image List tests for comctl32 v6
It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests). Hope this helps. Ok... I've been looking at the child process code, and I think it's not necessary to do that (though you might be doing something more complex - I haven't looked at the patch in detail). The activation context method that's already present sets up a manifest-enabled state of affairs. The big gotcha is that you have to reload any function pointers that you might care to use... http://wine.pastebin.com/m11141e7a As you can see here my version of the test unloads comctl32, switches on the activation context, and then reloads comctl32, and then loads pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call these, you have a state of affairs that is pretty much identical to what you get with a manifest from the start.
Re: Image List tests for comctl32 v6
On Fri, 2009-10-02 at 02:40 +0400, Nikolay Sivov wrote: Joel Holdsworth wrote: Hi All, I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module. Does anyone have any thoughts about what might be going on here, and what I should do with my tests? Thanks Joel Hi, Joel. It works for precreated manifest as a separate file (not compiled in), isn't it? If so you could do a trick that I spotted here http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html for a first time - here another process is created after main test binary loaded, it's created for exactly the same binary but with a manifest created first (command line parameter passed to jump to V6 tests). Hope this helps. Yes that looks like what I need. Have you had any luck getting your patch merged? - I'd happily build on your work.
Image List tests for comctl32 v6
Hi All, I'm working on some tests to demonstrate some alpha-channel behaviour in comctl32 ImageLists. The problem is that this behaviour is only present in comctl32 v6, which of course you usually activate with an xml manifest. For the wine test suite we have a helper function, load_v6_module, that dynamically creates a manifest resource entry in the module, which seems to activate v6 behaviour. However, while this seems to activate v6 behaviour for controls, it seems not to for image lists - my tests work if I link a manifest into the test suite, but don't work via load_v6_module. Does anyone have any thoughts about what might be going on here, and what I should do with my tests? Thanks Joel
Re: Image List tests for comctl32 v6
Do you mean that the tests pass on Windows but not Wine when using load_v6_module, or that they don't pass on either platform? I used load_v6_module for some v6 imagelist tests (which may not yet be merged into Wine actually; I should probably check that and resubmit) and they worked fine. You may want to look at http://tinyurl.com/ybo28lt for instance. If the tests are working on Windows but not on Wine, the obvious reason for your tests failing would be that the required alpha channel support is not implemented. Cheers, It sounds like I need to investigate further, but no - I'm only talking about Windows. With crosstest, load_v6_module seems not to switch to v6 with regard to image lists.
Wine in Tango
Hi All, If anyone's interested I've published a working version of my Tango graphics for wine to Gitorious... http://gitorious.org/wine-tango/wine-tango clone: git clone git://gitorious.org/wine-tango/wine-tango.git branch: public-beta-1 This branch features Roderick Colenbrander's as-yet unmerged XRender patches, some patches from me for 32-bit support in the areas of icons, image lists and toolbars, and a partial set of patches to apply the tango graphics for shell32, user32 and comdlg32. Graphics for other apps/dlls are excluded, as well as the few tests I've produced. The work is most clear to see if you open a file dialog, or a message box. The full set of Tango graphics can be seen here: http://www.airwebreathe.org.uk/wine-icon/ . There are still a few graphical things to fix: dxdiag, certwatermark.bmp. Comments and criticisms are welcome! Best Regards Joel Holdsworth
Re: Finding IDB_VIEW_SMALL_COLOR
Great thanks! On Mon, 2009-09-07 at 00:42 +0400, Nikolay Sivov wrote: Joel Holdsworth wrote: Hi All, Does anyone know what DLL the image 32-bit version the standard image list IDB_VIEW_SMALL_COLOR is stored in in Windows? You can see some of it in this screenshot: http://www.airwebreathe.org.uk/IDB_VIEW_SMALL_COLOR.png. I might expect it to be in comctl32.dll with the other common image lists... but it's not - only the old 4-bit version of the image. Does anyone know where the 32-bit one is? Thanks Joel Could be comctl32 v6 (located in winsxs subdir).
Finding IDB_VIEW_SMALL_COLOR
Hi All, Does anyone know what DLL the image 32-bit version the standard image list IDB_VIEW_SMALL_COLOR is stored in in Windows? You can see some of it in this screenshot: http://www.airwebreathe.org.uk/IDB_VIEW_SMALL_COLOR.png. I might expect it to be in comctl32.dll with the other common image lists... but it's not - only the old 4-bit version of the image. Does anyone know where the 32-bit one is? Thanks Joel
Re: DxDiag Demo Patch
If you want, I can draw a Tango-style icon for it, as part of my work in progress wine icon refresh: http://www.airwebreathe.org.uk/wine-icon/
SVG Logo from the website
Quick question: Does anyone have an SVG of the wine logo as used on the wine website? I'd like to use it as part of my graphics refresh to improve idb_wine.bmp as shown here: http://www.airwebreathe.org.uk/wine-icon/
Re: SVG Logo from the website
On Sat, 2009-07-18 at 17:30 -0400, Steven Edwards wrote: I am curious though, the cryptui.dll cert icons don't strike me as right. I can't even tell what they are supposed to be. The icon is the standard certification icon taken from the Tango base set. From what I can see it represents a wax seal - the old way of certifying one's identity. In fact the original icon has the seal drawn in yellow on the left of the certificate, so the idea isn't too crazy. You could be right though. Maybe the metaphore isn't as clear as it could be - especially when the UI explicitly uses the word certificates. Drawing high quality icons takes me a long time, so I'm trying to avoid creating too much work for myself. On the other hand if people think it's wrong, then I don't mind working to get it right. It doesn't matter too much either way though, because cryptui is very obscure - so obscure that it's only after months of work on this project that I've been able to find a way to actually display the dialog for the first time! I had to write custom test software to do it! So whatever happens the impact on users will be quite low.
Alpha Roadblocks
Hi All, Some of you may have read some of my recent mails about my work to refresh the wine icons with Tango versions, as demonstrated in this screenshot: http://www.airwebreathe.org.uk/alpha-tango-icons.png Achieving this task isn't a simple icon replacement job, because of the inability of wine to handle the alpha channel correctly in two key areas: HICONS, and IImageLists. I've patched some of the problems, but others are roadblocked by shortcomings in x11.drv's BitBlt/StretchBlt which (usually) strip the alpha channel. This leaves me a bit stuck: AJ rightly won't accept any hacks or workabouts, which leaves me with the choice to give up (for the time being), or try and fix x11.drv myself. I'm pretty sure that fixing the blts would be a major job, but I thought I'd write and ask for some comments. Is it so hard as I think? Does anyone have any ideas what would be required? Thanks Joel
Re: user32/tests: Added tests for DrawIcon and DrawIconEx (try 6)
I don't think you need such a complex test, we don't really care about the exact reason why it's broken. Agreed. Fielding all the different deviations is getting quite convoluted. The modern/legacy stuff will need to remain because in some of these tests windows has made step changes - e.g. adding alpha support in 2000 and later. Also I think you should be using the relaxed color matching everywhere, even for the working cases. We may want to round things differently in Wine too, and there's no reason to require exact pixel values, testing a few high bits should be enough to determine that blending has taken place. I agree with you on this as well, exact pixel values are fragile, and 5-bit accuracy seems an acceptable margin of error. However, this still doesn't deal with the case in old windows, at 8-bit or less, the bitmap is rendered via the logical palette. In this case I found that even 2-bit accuracy sometimes wasn't sufficient - palette matching often caused channel variances of over 25%! Taking this into account would yield: ok ((result 0x00F8F8F8) == (modern_expected 0x00F8F8F8) || /* Windows 2000 and up */ broken((result 0x00F8F8F8) == (legacy_expected 0x00F8F8F8)) || /* Windows NT 4.0, 9X and below */ broken(GetDeviceCaps(hdc, BITSPIXEL) = 8), ... /* Windows NT 4.0, 9X and below at 8bpp or less*/ What do you think? Joel
Re: user32/tests: Added tests for DrawIcon and DrawIconEx (try 6)
cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIcon. Expected 3163 (modern), or 3868 (legacy). Got 20B8 from line 1109 cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1110 cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIcon. Expected 3163 (modern), or 3868 (legacy). Got 20B8 from line 1112 cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1113 cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 3163 (modern), or 3868 (legacy). Got 20B8 from line 1114 cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (legacy). Got 00FFE850 from line 1115 cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIconEx flags 0003. Expected 3163 (modern) or 3868 (legacy). Got 20B8 from line 1256 cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIconEx flags 0003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1257 cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIconEx flags 0003. Expected 3163 (modern) or 3868 (legacy). Got 20B8 from line 1259 cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIconEx flags 0003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1260 cursoricon.c:1171: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIconEx flags 0003. Expected 3163 (modern) or 3868 (legacy). Got 20B8 from line 1261 cursoricon.c:1171: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIconEx flags 0003. Expected 00FFCE9C (modern) or 00FFD0A0 (legacy). Got 00FFE850 from line 1262 I've tracked down the problems with an NT4 VM. The problem comes when screen depth is set to less than 32-bit. Even though I'm drawing from an icon made from 32-bit bitmaps, and making DrawIcon draw to a 32-bit DIB section, old versions of windows don't respect that, and will truncate the color data. In 16-bit only the top 5 bits of a color channels emerge ungarbled, and in 8-bit and less, the colors go via the palette (logical palette?), which knocks them completely off. The most obvious solution would be something like this as a color test: const int screen_bpp = GetDeviceCaps(hdc, BITSPIXEL); ok (result == modern_expected || /* Windows 2000 and up */ broken(result == legacy_expected) || /* Windows NT 4.0, 9X and below */ broken((result 0x00F8F8F8) == (legacy_expected 0x00F8F8F8) screen_bpp == 16) || broken(result != legacy_expected screen_bpp = 8), How acceptable would that be?
Re: [1/5] user32: Added tests for DrawIcon and DrawIconEx
GetVersion() is not a problem in itself but we make an effort to decide what to test based on behavior not version. If it absolutely can not be avoided (and you will see some examples in the code) GetVersion() is accepted. I think this is the case here. DrawIcon[Ex]'s behaviour has evolved over time, but we want Wine to support the modern behaviour not the 9X behaviour. You reference GdiAlphaBlend(). That's not part of user32. If you are sure Windows uses this for alpha blend support you can always check for the availability of the GdiAlphaBlend() function: Sorry - that was a mistake in my earlier e-mail. The version of Windows that introduced GdiAlphaBlend also introduced alpha-channel rendering in DrawIcon[Ex] as well (which must use GdiAlphaBlend internally). So in this case it would be better to check version numbers not check for the presence of GdiAlphaBlend, because that's not what I'm testing. This will give you a chance to decide not to run the tests on these platforms. I already ran you tests on NT4 and they pass. This doesn't mean that all tests run on NT4 as you sometimes return() without having done an ok() test or with a trace() or skip()/win_skip(), like here: +hicon = create_test_icon(hdc, 2, 1, bpp, 0, (UINT32*)color, sizeof(color)); +if (!hicon) return; Is there a reason this could fail? If not you should add an ok() test for hicon. If yes, you should use skip() or win_skip() to show these tests are skipped but with a correct/expected reason. There are more of these blind return's in your patch. Ok - yes these can be fixed. I did the blind thing because I've noticed other tests do that for the error condition, and I figured that my tests don't want to test CreateIcon et al; these are already tested. I'm only testing DrawIcon[Ex], but I suppose extra tests can't hurt.
Re: [1/5] user32: Added tests for DrawIcon and DrawIconEx
I've run your new tests on Win95, Win98 and NT4 (all VMware): Is there another way you can detect whether some XP (and up) tests can be run? We generally try not to use GetVersion() in our tests. It turns out that the reason for the Win95 errors is that it calculates true-colour - 16-bit dithers differently. These tests can be safely skipped, on these platforms. In addition to the errors Win95 has, the other Win98 failures seem to be the product of my interpretation GetVersion returns being wrong. Easily fixed. However, you're saying GetVersion is a problem. Why is that? And how else is one supposed to cope with GdiAlphaBlend not being present in pre-XP systems, as well as old-style dithering differences? Thanks Joel
Re: [1/5] user32: Added tests for DrawIcon and DrawIconEx
On Thu, 2009-06-04 at 08:43 +0200, Paul Vriens wrote: Joel Holdsworth wrote: Hi Joel, I've run your new tests on Win95, Win98 and NT4 (all VMware): Win95: == cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIcon. Expected 3163. Got 3868 from line 1130 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIcon. Expected 00FFCE9C. Got 00FFD0A0 from line 1131 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIcon. Expected 3163. Got 3868 from line 1133 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00FFCE9C. Got 00FFD0A0 from line 1134 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 3163. Got 3868 from line 1135 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00FFCE9C. Got 00FFD0A0 from line 1136 cursoricon.c:1028: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIconEx flags 0003. Expected 3163. Got 3868 from line 1262 cursoricon.c:1028: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIconEx flags 0003. Expected 00FFCE9C. Got 00FFD0A0 from line 1263 cursoricon.c:1028: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIconEx flags 0003. Expected 3163. Got 3868 from line 1265 cursoricon.c:1028: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIconEx flags 0003. Expected 00FFCE9C. Got 00FFD0A0 from line 1266 cursoricon.c:1028: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIconEx flags 0003. Expected 3163. Got 3868 from line 1267 cursoricon.c:1028: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIconEx flags 0003. Expected 00FFCE9C. Got 00FFD0A0 from line 1268 Win98: == cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with DrawIcon. Expected 3163. Got 3868 from line 1130 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with DrawIcon. Expected 00FFCE9C. Got 00FFD0A0 from line 1131 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color FFA0B0C0 with DrawIcon. Expected 3163. Got 3868 from line 1133 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00FFCE9C. Got 00FFD0A0 from line 1134 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 3163. Got 3868 from line 1135 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00FFCE9C. Got 00FFD0A0 from line 1136 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00C0B0A0. Got 003F4F5F from line 1081 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 00605850. Got 00C0B0A0 from line 1083 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00605850. Got 00C0B0A0 from line 1084 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 00DFD7CF. Got 00C0B0A0 from line 1085 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00DFD7CF. Got 003F4F5F from line 1086 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 01FF with DrawIcon. Expected 00010101. Got 00FF from line 1088 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 01FF with DrawIcon. Expected 00010101. Got 00FF from line 1089 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color FEFF with DrawIcon. Expected 00FEFEFE. Got 00FF from line 1090 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color FEFF with DrawIcon. Expected 00FEFEFE. Got 00FF from line 1091 cursoricon.c:1056: Test failed: Alpha blending. Expected 00FF with DrawIcon. Got 00C0B0A0 from line 1099 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color FFA0B0C0 with DrawIcon. Expected 00C0B0A0. Got 003F4F5F from line 1081 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 00605850. Got 00C0B0A0 from line 1083 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00605850. Got 00C0B0A0 from line 1084 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 80A0B0C0 with DrawIcon. Expected 00DFD7CF. Got 00C0B0A0 from line 1085 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 80A0B0C0 with DrawIcon. Expected 00DFD7CF. Got 003F4F5F from line 1086 cursoricon.c:1013: Test failed: Overlaying Mask 0 on Color 01FF with DrawIcon. Expected 00010101. Got 00FF from line 1088 cursoricon.c:1013: Test failed: Overlaying Mask 1 on Color 01FF with DrawIcon. Expected 00010101. Got 00FF from line 1089 cursoricon.c:1013
HICON Patches - Request for reviews
Hi All,
I've been working on alpha support in HICONs and HIMAGELISTs. This patch
set includes my earlier test patch (plus modifications as per the
comments), and fixes up DrawIcon, DrawIconEx and
CURSORICON_CreateIconFromBMI.
I've tested the test patch on 2k, XP, and Vista - but any other test
platforms would be welcome, and any comments on the other 4 patches
before I submit them.
Best Regards
Joel Holdsworth
From d22ba983b85028f667a7754858f35c7e219847e9 Mon Sep 17 00:00:00 2001
From: Joel Holdsworth j...@airwebreathe.org.uk
Date: Tue, 2 Jun 2009 21:13:47 +0100
Subject: [PATCH] Added tests for DrawIcon and DrawIconEx
---
dlls/user32/tests/cursoricon.c | 355
1 files changed, 355 insertions(+), 0 deletions(-)
diff --git a/dlls/user32/tests/cursoricon.c b/dlls/user32/tests/cursoricon.c
index 9475534..4caf442 100644
--- a/dlls/user32/tests/cursoricon.c
+++ b/dlls/user32/tests/cursoricon.c
@@ -956,6 +956,359 @@ static void test_CreateIconFromResource(void)
HeapFree(GetProcessHeap(), 0, hotspot);
}
+static HICON create_test_icon(HDC hdc, int width, int height, int bpp,
+ BOOL maskvalue, UINT32 *color, int colorSize)
+{
+ICONINFO iconInfo;
+BITMAPINFO bitmapInfo;
+UINT32 *buffer = NULL;
+UINT32 mask = maskvalue ? 0x : 0x;
+
+memset(bitmapInfo, 0, sizeof(bitmapInfo));
+bitmapInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
+bitmapInfo.bmiHeader.biWidth = width;
+bitmapInfo.bmiHeader.biHeight = height;
+bitmapInfo.bmiHeader.biPlanes = 1;
+bitmapInfo.bmiHeader.biBitCount = bpp;
+bitmapInfo.bmiHeader.biCompression = BI_RGB;
+bitmapInfo.bmiHeader.biSizeImage = colorSize;
+
+iconInfo.fIcon = TRUE;
+iconInfo.xHotspot = 0;
+iconInfo.yHotspot = 0;
+
+iconInfo.hbmMask = CreateBitmap( width, height, 1, 1, mask );
+if(!iconInfo.hbmMask) return NULL;
+
+iconInfo.hbmColor = CreateDIBSection(hdc, bitmapInfo, DIB_RGB_COLORS, (void**)buffer, NULL, 0);
+if(!iconInfo.hbmColor || !buffer)
+{
+DeleteObject(iconInfo.hbmMask);
+return NULL;
+}
+
+memcpy(buffer, color, colorSize);
+
+return CreateIconIndirect(iconInfo);
+}
+
+static void flood_background(HDC hdc, int width, int height, COLORREF color)
+{
+RECT rect = {0, 0, 1, 1};
+HBRUSH backgroundBrush = CreateSolidBrush(color);
+FillRect(hdc, rect, backgroundBrush);
+DeleteObject(backgroundBrush);
+}
+
+static void check_DrawIcon(HDC hdc, BOOL maskvalue, UINT32 color, int bpp,
+COLORREF background, COLORREF expected, int line)
+{
+COLORREF result;
+HICON hicon = create_test_icon(hdc, 1, 1, bpp, maskvalue, color, sizeof(color));
+if (!hicon) return;
+flood_background(hdc, 1, 1, background);
+DrawIcon(hdc, 0, 0, hicon);
+result = GetPixel(hdc, 0, 0);
+
+ok (result == expected,
+Overlaying Mask %d on Color %08X with DrawIcon. Expected %08X. Got %08X from line %d\n,
+maskvalue, (unsigned int)color, (unsigned int)expected, (unsigned int)result, line);
+}
+
+static void check_DrawIconEx(HDC hdc, BOOL maskvalue, UINT32 color, int bpp, UINT flags,
+ COLORREF background, COLORREF expected, int line)
+{
+COLORREF result;
+HICON hicon = create_test_icon(hdc, 1, 1, bpp, maskvalue, color, sizeof(color));
+if (!hicon) return;
+flood_background(hdc, 1, 1, background);
+DrawIconEx(hdc, 0, 0, hicon, 1, 1, 0, NULL, flags);
+result = GetPixel(hdc, 0, 0);
+
+ok (result == expected,
+Overlaying Mask %d on Color %08X with DrawIconEx flags %08X. Expected %08X. Got %08X from line %d\n,
+maskvalue, (unsigned int)color, flags, (unsigned int)expected, (unsigned int)result, line);
+}
+
+static void check_alpha_draw(HDC hdc, BOOL drawiconex, BOOL alpha, int bpp, int line)
+{
+HICON hicon;
+UINT32 mask;
+UINT32 color[2];
+COLORREF expected, result;
+
+mask = 0x;
+color[0] = 0x00A0B0C0;
+color[1] = alpha ? 0xFF00 : 0x;
+expected = alpha ? 0x00FF : 0x00C0B0A0;
+
+hicon = create_test_icon(hdc, 2, 1, bpp, 0, (UINT32*)color, sizeof(color));
+if (!hicon) return;
+
+flood_background(hdc, 1, 1, 0x00FF);
+
+if(drawiconex)
+DrawIconEx(hdc, 0, 0, hicon, 2, 1, 0, NULL, DI_NORMAL);
+else
+DrawIcon(hdc, 0, 0, hicon);
+
+result = GetPixel(hdc, 0, 0);
+ok (result == expected,
+%s. Expected %08X with %s. Got %08X from line %d\n,
+alpha ? Alpha blending : Not alpha blending,
+(unsigned int)expected, drawiconex ? DrawIconEx : DrawIcon,
+(unsigned int)result, line);
+}
+
+static void test_DrawIcon_true_color(HDC hdcDst)
+{
+DWORD dwVersion = GetVersion();
+DWORD dwMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion)));
+DWORD dwMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion)));
+
+/* Mask is only heeded if alpha
Icon Refresh News (and a question)
Hi All, I've been working away little by little at my icons work, and I'm beginning to make a little progress: http://www.airwebreathe.org.uk/alpha-tango-icons.png The screenshot montage shows my work on getting HICONs and HIMAGELISTs to support the alpha channel, combined with a refreshed icon set from Tango. Right now, a lot of the changes I've made are rather bodged, but I'm encouraged because at least here we see a proof of principle. To get this to work, I've basically had to go through fixing places where the alpha channel is incorrectly stripped or ignored. All of them are relatively easily fixed, except the ones in the stretch blt functions. StretchBlt, StretchDIBits et al. seem to have a fast path and a slow path. The fast path is active when no stretching or translation should occur. The slow path performs all other cases, but my tests show that only the fast path preserves the alpha channel. The reason must be that the stretch is performed in X - but this is a problem, because I don't know if it's possible for X to preserve alpha. Does anyone know? My demo has replaced the offending StretchBlts with BitBlts, which works fine, unless the icon has to be rescaled. Does anyone have any thoughts or comments? Thanks Joel
Re: Icon Refresh News (and a question)
Looks great, hope you get your code clean and soon can send patches. Why the buttons on the right top of the open-dialog are empty? Answer: Hack n' slash. I have no reproduction of the mechanism for checking which images *should* be alpha blended, and which should not - the code assumes all icons should, and so in the case of 16-bit icons the alpha channel is fixed at constant 0, and so will these icons are drawn with 0% opacity! This is one of many things that need to be finished in my work, but the proof-of-concept is there. Joel
Re: annoying pkg-config problem on 64 bit Ubuntu 8.10
On Thu, 2009-05-21 at 22:18 +0200, Tijnema wrote: Haven't checked Jaunty yet to see if it's still busted. We may need to postprocess pkg-config's output to add the missing 32 in some cases. Not sure if it's worth it. On Jaunty I get $ pkg-config --libs dbus-1 -L//lib -ldbus-1
Getting my test for DrawIcon and DrawIconEx included
Is there a reason why my patch (attached) hasn't been included yet? This
is my first patch, so maybe someone can help me get it in.
Joel
From e8398597bfe4772e065ebd98aa3f93a9f681a2fc Mon Sep 17 00:00:00 2001
From: Joel Holdsworth j...@airwebreathe.org.uk
Date: Sat, 2 May 2009 10:13:45 +0100
Subject: [PATCH] Added tests for DrawIcon and DrawIconEx
---
dlls/user32/tests/cursoricon.c | 209
1 files changed, 209 insertions(+), 0 deletions(-)
diff --git a/dlls/user32/tests/cursoricon.c b/dlls/user32/tests/cursoricon.c
index 9475534..de3c582 100644
--- a/dlls/user32/tests/cursoricon.c
+++ b/dlls/user32/tests/cursoricon.c
@@ -58,12 +58,54 @@ typedef struct
static char **test_argv;
static int test_argc;
+
+static HINSTANCE hinst;
+
static HWND child = 0;
static HWND parent = 0;
static HANDLE child_process;
#define PROC_INIT (WM_USER+1)
+static HWND create_a_window(void)
+{
+char className[] = icownd;
+char winName[] = Test DrawIcon;
+HWND hWnd;
+static int registered = 0;
+
+if (!registered)
+{
+WNDCLASSA cls;
+
+cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS;
+cls.lpfnWndProc = DefWindowProcA;
+cls.cbClsExtra= 0;
+cls.cbWndExtra= 0;
+cls.hInstance = 0;
+cls.hIcon = LoadIconA (0, IDI_APPLICATION);
+cls.hCursor = LoadCursorA (0, IDC_ARROW);
+cls.hbrBackground = GetStockObject (WHITE_BRUSH);
+cls.lpszMenuName = 0;
+cls.lpszClassName = className;
+
+RegisterClassA (cls);
+registered = 1;
+}
+
+/* Setup window */
+hWnd = CreateWindowA (className, winName,
+ WS_OVERLAPPEDWINDOW ,
+ CW_USEDEFAULT, CW_USEDEFAULT, 100, 100, 0,
+ 0, hinst, 0);
+
+ShowWindow (hWnd, SW_SHOW);
+
+Sleep(200);
+
+return hWnd;
+}
+
static LRESULT CALLBACK callback_child(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
BOOL ret;
@@ -956,6 +998,169 @@ static void test_CreateIconFromResource(void)
HeapFree(GetProcessHeap(), 0, hotspot);
}
+static void check_icon_draw(HWND hwnd, BOOL drawiconex, BOOL maskvalue,
+UINT32 color, int bpp, COLORREF background,
+COLORREF expected)
+{
+COLORREF result;
+HDC hdc = NULL;
+HICON hicon;
+RECT rect = {0, 0, 1, 1};
+HBRUSH backgroundBrush;
+UINT32 mask;
+
+if (!hwnd) return;
+
+mask = maskvalue ? 0x : 0x;
+hicon = CreateIcon(hinst, 1, 1, 1, bpp, mask, color);
+
+if (!hicon) return;
+
+hdc = GetDC(hwnd);
+
+backgroundBrush = CreateSolidBrush(background);
+FillRect(hdc, rect, backgroundBrush);
+DeleteObject(backgroundBrush);
+
+if(drawiconex)
+DrawIconEx(hdc, 0, 0, hicon, 1, 1, 0, NULL, DI_NORMAL);
+else
+DrawIcon(hdc, 0, 0, hicon);
+
+result = GetPixel(hdc, 0, 0);
+
+ReleaseDC(hwnd, hdc);
+
+ok (result == expected,
+Overlaying Mask %d on Color %08X. Expected %08X with %s. Got %08X\n,
+maskvalue, (unsigned int)color, (unsigned int)expected,
+drawiconex ? DrawIconEx : DrawIcon, (unsigned int)result);
+}
+
+static void check_alpha_draw(HWND hwnd, BOOL drawiconex, BOOL alpha, int bpp)
+{
+COLORREF result;
+HDC hdc = NULL;
+HICON hicon;
+RECT rect = {0, 0, 1, 1};
+HBRUSH backgroundBrush;
+UINT32 mask;
+UINT32 color[2];
+COLORREF expected;
+
+if (!hwnd) return;
+
+mask = 0x;
+color[0] = 0x00A0B0C0;
+color[1] = alpha ? 0xFF00 : 0x;
+expected = alpha ? 0x00FF : 0x00C0B0A0;
+
+hicon = CreateIcon(hinst, 2, 1, 1, bpp, mask, color);
+
+if (!hicon) return;
+
+hdc = GetDC(hwnd);
+
+backgroundBrush = CreateSolidBrush(0x00FF);
+FillRect(hdc, rect, backgroundBrush);
+DeleteObject(backgroundBrush);
+
+if(drawiconex)
+DrawIconEx(hdc, 0, 0, hicon, 2, 1, 0, NULL, DI_NORMAL);
+else
+DrawIcon(hdc, 0, 0, hicon);
+
+result = GetPixel(hdc, 0, 0);
+
+ReleaseDC(hwnd, hdc);
+
+ok (result == expected,
+%s. Expected %08X with %s. Got %08X\n,
+alpha ? Alpha blending : Not alpha blending,
+(unsigned int)expected, drawiconex ? DrawIconEx : DrawIcon,
+(unsigned int)result);
+}
+
+static void test_DrawIcon(BOOL drawiconex)
+{
+HWND hwnd = create_a_window();
+
+UINT display_bpp;
+HDC hdc;
+
+hdc = GetDC(0);
+display_bpp = GetDeviceCaps(hdc, BITSPIXEL);
+ReleaseDC(0, hdc);
+
+if(display_bpp == 16)
+{
+check_icon_draw(hwnd, drawiconex, FALSE, 0x00A0B0C0, 16, 0x00FF, 0x18B5);
+check_icon_draw(hwnd, drawiconex, TRUE, 0x00A0B0C0, 16, 0x00FF, 0x00FFE74A);
+
+check_icon_draw(hwnd, drawiconex, FALSE, 0xFFA0B0C0, 16, 0x00FF, 0x18B5);
+check_icon_draw(hwnd, drawiconex, TRUE, 0xFFA0B0C0, 16, 0x00FF, 0x00FFE74A
Re: Giving up for now
On Sun, 2009-05-03 at 16:05 +0200, Roderick Colenbrander wrote: We do support some alpha support using XRender, can't you use this too? I think that's the general method for using alpha at the moment on X. Yes and I'm using GdiAlphaBlend - for rendering, and I have fixes to use it. It's what you need to enable DrawIcon and DrawIconEx to draw properly. The reason is to do with the way *loading* works. Icons get loaded in arbitrary sizes and colour depths, but of course only compatible HBITMAPs can be displayed e.g. a 4-bit icon has to be upsampled to 32-bit before it can be displayed on my system. As a solution to both these problems CURSORICON_CreateIconFromBMI has an internal call to StretchDIBits, which applies both depth and size conversions. The problem is that this call seems to loose the alpha channel in doing so. I guess I should write a test to find out what StretchDIBits *should* do - whether we can use it, even theoretically. Once we get to the stage of returning a full formed HICON to the app, it's plain sailing. My DrawIcon patch can render alpha channel icons no problem, and hopefully a DrawIconEx patch will soon follow. The problem is that the only way to create one in wine right now is with CreateIcon! Joel
Question about my user32 tests patch
Hi All,
I just submitted my first ever patch to wine-patches (attached) - good
news. In retrospect I may have been a little premature. The patch adds
tests for user32:DrawIcon and user32:DrawIconEx including tests for icon
alpha blending which wine does not currently support.
It occured to me that my alpha tests will fail in versions of Windows
that don't support alpha blending - but the problem is I'm not sure at
what point alpha began to be supported. I only have a VM for XP - and I
think, but I don't know for sure, that alpha icons began to be supported
in 2000.
How do you deal with this problem, because presumably not every test
contributor has VMs ready to confirm the behaviour of 95, 98, ME, 2000,
XP and Vista. Do I submit the patch as-is, in the knowlege that it will
cause failures in old windows? Presumably not - so what do you suggest I
do?
I now have code to make DrawIcon pass the alpha tests, and I'm hoping to
have DrawIconEx ready in a few hours. With these done it should be
possible to in-cooperate my Tango patches, which should improve the
appearance of wine quite substantially.
Thanks
Joel
From e8398597bfe4772e065ebd98aa3f93a9f681a2fc Mon Sep 17 00:00:00 2001
From: Joel Holdsworth j...@airwebreathe.org.uk
Date: Sat, 2 May 2009 10:13:45 +0100
Subject: [PATCH] Added tests for DrawIcon and DrawIconEx
---
dlls/user32/tests/cursoricon.c | 209
1 files changed, 209 insertions(+), 0 deletions(-)
diff --git a/dlls/user32/tests/cursoricon.c b/dlls/user32/tests/cursoricon.c
index 9475534..de3c582 100644
--- a/dlls/user32/tests/cursoricon.c
+++ b/dlls/user32/tests/cursoricon.c
@@ -58,12 +58,54 @@ typedef struct
static char **test_argv;
static int test_argc;
+
+static HINSTANCE hinst;
+
static HWND child = 0;
static HWND parent = 0;
static HANDLE child_process;
#define PROC_INIT (WM_USER+1)
+static HWND create_a_window(void)
+{
+char className[] = icownd;
+char winName[] = Test DrawIcon;
+HWND hWnd;
+static int registered = 0;
+
+if (!registered)
+{
+WNDCLASSA cls;
+
+cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS;
+cls.lpfnWndProc = DefWindowProcA;
+cls.cbClsExtra= 0;
+cls.cbWndExtra= 0;
+cls.hInstance = 0;
+cls.hIcon = LoadIconA (0, IDI_APPLICATION);
+cls.hCursor = LoadCursorA (0, IDC_ARROW);
+cls.hbrBackground = GetStockObject (WHITE_BRUSH);
+cls.lpszMenuName = 0;
+cls.lpszClassName = className;
+
+RegisterClassA (cls);
+registered = 1;
+}
+
+/* Setup window */
+hWnd = CreateWindowA (className, winName,
+ WS_OVERLAPPEDWINDOW ,
+ CW_USEDEFAULT, CW_USEDEFAULT, 100, 100, 0,
+ 0, hinst, 0);
+
+ShowWindow (hWnd, SW_SHOW);
+
+Sleep(200);
+
+return hWnd;
+}
+
static LRESULT CALLBACK callback_child(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
BOOL ret;
@@ -956,6 +998,169 @@ static void test_CreateIconFromResource(void)
HeapFree(GetProcessHeap(), 0, hotspot);
}
+static void check_icon_draw(HWND hwnd, BOOL drawiconex, BOOL maskvalue,
+UINT32 color, int bpp, COLORREF background,
+COLORREF expected)
+{
+COLORREF result;
+HDC hdc = NULL;
+HICON hicon;
+RECT rect = {0, 0, 1, 1};
+HBRUSH backgroundBrush;
+UINT32 mask;
+
+if (!hwnd) return;
+
+mask = maskvalue ? 0x : 0x;
+hicon = CreateIcon(hinst, 1, 1, 1, bpp, mask, color);
+
+if (!hicon) return;
+
+hdc = GetDC(hwnd);
+
+backgroundBrush = CreateSolidBrush(background);
+FillRect(hdc, rect, backgroundBrush);
+DeleteObject(backgroundBrush);
+
+if(drawiconex)
+DrawIconEx(hdc, 0, 0, hicon, 1, 1, 0, NULL, DI_NORMAL);
+else
+DrawIcon(hdc, 0, 0, hicon);
+
+result = GetPixel(hdc, 0, 0);
+
+ReleaseDC(hwnd, hdc);
+
+ok (result == expected,
+Overlaying Mask %d on Color %08X. Expected %08X with %s. Got %08X\n,
+maskvalue, (unsigned int)color, (unsigned int)expected,
+drawiconex ? DrawIconEx : DrawIcon, (unsigned int)result);
+}
+
+static void check_alpha_draw(HWND hwnd, BOOL drawiconex, BOOL alpha, int bpp)
+{
+COLORREF result;
+HDC hdc = NULL;
+HICON hicon;
+RECT rect = {0, 0, 1, 1};
+HBRUSH backgroundBrush;
+UINT32 mask;
+UINT32 color[2];
+COLORREF expected;
+
+if (!hwnd) return;
+
+mask = 0x;
+color[0] = 0x00A0B0C0;
+color[1] = alpha ? 0xFF00 : 0x;
+expected = alpha ? 0x00FF : 0x00C0B0A0;
+
+hicon = CreateIcon(hinst, 2, 1, 1, bpp, mask, color);
+
+if (!hicon) return;
+
+hdc = GetDC(hwnd);
+
+backgroundBrush = CreateSolidBrush(0x00FF);
+FillRect(hdc, rect, backgroundBrush);
+DeleteObject(backgroundBrush);
+
+if(drawiconex)
+DrawIconEx(hdc, 0, 0, hicon, 2, 1, 0, NULL, DI_NORMAL
Re: Question about my user32 tests patch
On Sat, 2009-05-02 at 08:58 -0700, Juan Lang wrote: Hi Joel, How do you deal with this problem, because presumably not every test contributor has VMs ready to confirm the behaviour of 95, 98, ME, 2000, XP and Vista. Do I submit the patch as-is, in the knowlege that it will cause failures in old windows? Presumably not - so what do you suggest I do? That's what we generally end up doing. Watching test.winehq.org for test results once a patch gets committed, or waiting for an email from someone who watches the results, is a way to get feedback on test failures on other platforms. The alternative is to ask someone to test your tests on other platforms, by asking on wine-devel as you've done. Cheers, --Juan Ahh ok that's good news!
Giving up for now
Hi All, I've hit a bit of a wall with alpha blended icons. CreateIcon is working fine for icon creation, but ExtractIcon and LoadIconFromResource etc. are all proving more of a problem. All of these use various GDI DIB functions to coerce the icon bitmap to the correct colour depth and size. The problem is that preserving the alpha channel through these DIB functions seems to be impossible because they go via X11, so until the dib engine is merged (after hell freezes over) I'm not sure I can go much further. Joel
Re: Giving up for now
On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth j...@airwebreathe.org.uk wrote: Hi All, I've hit a bit of a wall with alpha blended icons. CreateIcon is working fine for icon creation, but ExtractIcon and LoadIconFromResource etc. are all proving more of a problem. All of these use various GDI DIB functions to coerce the icon bitmap to the correct colour depth and size. The problem is that preserving the alpha channel through these DIB functions seems to be impossible because they go via X11, so until the dib engine is merged (after hell freezes over) I'm not sure I can go much further. Joel If you say X11 might be problematic note that more and more display drivers are offering visuals with alpha, so 32-bit ones instead of 24-bit. You could force the selection of such a visual in winex11.drv for testing. Roderick Is that right? I simply assumed it would screw it up. If the problem can be solved with fixes to user32 or gdi32, then I can probably find the solution. If it involves work on winex11, then I'm not really the right guy for the job.
Re: Giving up for now
On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth j...@airwebreathe.org.uk wrote: On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth j...@airwebreathe.org.uk wrote: Hi All, I've hit a bit of a wall with alpha blended icons. CreateIcon is working fine for icon creation, but ExtractIcon and LoadIconFromResource etc. are all proving more of a problem. All of these use various GDI DIB functions to coerce the icon bitmap to the correct colour depth and size. The problem is that preserving the alpha channel through these DIB functions seems to be impossible because they go via X11, so until the dib engine is merged (after hell freezes over) I'm not sure I can go much further. Joel If you say X11 might be problematic note that more and more display drivers are offering visuals with alpha, so 32-bit ones instead of 24-bit. You could force the selection of such a visual in winex11.drv for testing. Roderick Is that right? I simply assumed it would screw it up. If the problem can be solved with fixes to user32 or gdi32, then I can probably find the solution. If it involves work on winex11, then I'm not really the right guy for the job. Why again did you need this specific alphablend method? The icon can't be converted to use some basic color keying for transparency or so? The reason is that the outlines will look aliased, and there will be no drop-shadows - without alpha the Tango icons won't look better than the current set. Also, I figured that icon rendering should be fixed for the sake of wine as a whole - which I think it should. It seems like a good little task for a wine beginner, and indeed I've made a lot of progress - I'm just a bit stuck. The culprit is a transfer through StretchDIBits in user32 which strips the alpha channel. I can't see a way round it - using StretchBlt doesn't help, and neither does GdiTransparentBlt. Another insentive: I suspect fixing this would also fix bug #201 which is now over 8 years old!
New Icons are very good, but not yet perfect
Hi All, Great stuff with the new Tango icons for Wine - they're a definite improvement. One observation: it looks like the icons that I have installed do not have versions that have been tuned for small size: 16x16 and especially 22x22. If I understand correctly, the scaled icons were drawn for 48x48, which means that when the icon is drawn at size 22x22 in my gnome menu, there will be line width of 0.46px which looks too faint next to the other icons which have been tuned for small sizes, and have 1px lines. Does anyone know anything about this? Thanks Joel Holdsworth
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
Making the icon(s) configurable would be a bonus. Yes I'm not this will be possible in the first instance, because icons have to be compiled into the DLL resources at compile time. In the long run, it might be possible for some of our dialogs to use theme icons instead, but we'll still need a no-theme fallback of some kind. Also, the end result will likely be a mixed because even if our dialogs use themes, app code will often still load icons by parsing DLL resources, which can't be dynamic. smime.p7s Description: S/MIME cryptographic signature
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
From: http://www.telegraphics.com.au/svn/icoformat/trunk/dist/README.html The ICO format has an inherent 1 bit transparency mask (0 = opaque, 1 = transparent), called the AND bitmap. which is the older format icon. and: In PNG (Vista) format icons, the alpha channel is simply stored as part of the PNG. There is no separate mask. http://www.rw-designer.com/windows-xp-icon http://www.rw-designer.com/vista-icon According to these, you can store the images as PNG in Vista instead of BMP+mask, allowing you to preserve the alpha channel. Vista also supports 256x256 icon images (according to the information above). http://www.axialis.com/tutorials/tutorial-vistaicons.html http://msdn.microsoft.com/en-us/library/aa511280.aspx Have some more information. From the MDSN article, it appears that toolbar images (and other images stored in image lists?) only support a 1-bit alpha mask. http://msdn.microsoft.com/en-us/magazine/cc546571.aspx Has information on the new format. Note that PNG can be used in place of DIB image data. It shouldn't be too difficult to use something like libpng to handle the images and produce a bitmap from it. This would need support on the resource compiler side as well. IIRC, Wine *does* support AlphaBlending, but it is very slow. - Reece AFAIK - Windows has supported icon transparency since XP - or even before. In the case of XP, transparency was supported simply through 32-bit bitmaps, which is what I've used in my patch. This works fine in XP, and you can see it in action, because many icons have subtle drop-shadows and the like. I believe in that case, the transparency mask would be unused, or maybe be set as a simple transparency = (alpha==0) value by the authoring app as an attempt at backward compatibility. 32-bit uncompressed (or RLE) works fine for small icons - even up to 48x48, but these days high resolution is becoming more and more common, and we're seeing icons containing images up to as large as 256x256px. But in 32-bit uncompressed that's a quater megabyte, which is enough to make most engineers wince, hence the introduction of PNG! smime.p7s Description: S/MIME cryptographic signature
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
I've just heard some good news on the Tango list. The Tango icons are now public domain, which makes using them a much easier proposition. I might see if I can improve the state of the shell32 icons at some stage. smime.p7s Description: S/MIME cryptographic signature
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
We do support transparency. Fancy alpha blending effects might not work but this should work I think. It might depend on the file type which was used and perhaps the setting of a color key in a palette (look for other wine apps which uses, some of them must be using transparency). Further apps like Office 2007 must also be using it and the app looks fine. Well as this screenshot shows, something is broken: http://www.airwebreathe.org.uk/no-alpha.png . It may be that key transparency is supported but full alpha transparency channels are not. Something is wrong here, because the icons show up perfectly fine in any app I care to open them with. smime.p7s Description: S/MIME cryptographic signature
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
I mentioned this issue before - and I agree. Personally I'm interested in good integration across the whole of Wine - this includes for example the icons which appear in the file dialogs. ReactOS have adopted Tango to great effect. The downside is that there's really no way of making Wine's icons theme responsive because they have to be compiled in to the various dlls as resources. Nonetheless, I would still be interested in participating in an effort to standardise Wine on Tango, because as a standard, Tango is meant to satisfy useful usability criterea. The outlines are designed so that contrast is retained on both light and dark backgrounds, and the style guidelines are an attempt to make the icons look good on Gnome, KDE, Xfce, MacOS (and Windows - though that doesn't apply to this project) all at the same time. Personally I'm not bothered by the shape of the Tango glass, but we could make it more slender easily enough. I'm sure people on the Tango project would be very excited to contribute patches if they thought they'd be well received - and I think they'd make a very good job of it. Joel On Thu, 2009-04-16 at 13:55 -0700, Scott Ritchie wrote: A user submitted a bug report to launchpad complaining that the Wine icon is not Tango compliant: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/358645 So, what is Tango Compliance? Well, the Tango icons all use a set of design standards, and you can find them here: http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines In short, it means the Wine icon looks very out of place when it is placed alongside all the other Tango-compliant icons on the system. If you click the Applications button on an Ubuntu system, for instance, you'll see 7 three dimensional, front perspective, on the table, lit from above, well-bordered and highlighted icons. At the bottom you see a two dimensional, heavily tilted underneath perspective, hovering in midair, lit from the lower right, thick-bordered Wine icon. In short, it's ugly, but our real goal here is usability. Making Wine blend in is part of that, however it's also important we deliver a consistent experience: as ugly as it is, I thought, that icon is our project's logo, so we should use the same image throughout. But then, I realized, we don't use the same logo consistently! If you go to winehq.org you'll see another logo, which fits in with the website theme very well but is nevertheless quite different from the Tango icons. From a user's perspective, changing the Wine icon on the system can present a very slight familiarity issue: you're jarred for a second while you realize that the old Wine icon is gone and the new icon (helpfully next to the familiar words Wine) is actually the same program. This is the main place where the user sees the Wine icon, as we don't yet display it on other areas where they may be interacting with Wine (eg, by placing a small Wine icon next to the program icon as in http://brainstorm.ubuntu.com/ideatorrent/idea/2141). Accordingly, a change here will be narrow, and if we make it now (before the icon needs to be used elsewhere) there is a minimal amount of familiarity loss. A new icon makes a program feel new, so the user will expect some change. Accordingly, I'd like to propose updating our icons when we move forward with the 1.2 release. This will coincide with the inclusion of several of the Wine integration projects I'll be including in the coming months, such that the user will see it all (with a new, consistant icon) in one big package in the October wave of distro releases like Ubuntu 9.10. So, what should that new icon be? Well, tango compliance is one major goal, as is recognizability as a Wine glass. Fortunately, someone has already made a Tango-compliant Wine logo here: http://lists.freedesktop.org/archives/tango-artists/attachments/20060331/63117187/wine.svg Now, if you're like me, the second you saw that you went Whoa, that doesn't look like the Wine icon! It looks completely different! The glass on the website, for instance, is much more narrow: http://winehq.org/images/winehq_logo_glass_sm.png Now, I'm not a drinker, but I do know that real wine people can be very, very picky about these kind of things. After giving the wikipedia article (http://en.wikipedia.org/wiki/Wine_glass) and a few other websites a full read, I can categorically state one thing: we're using the wrong glass for red wine. Now, whether the icon we use should be the right kind of glass or not is an aesthetic choice. Personally I'd use a red wine glass but one with a slightly narrower bowl than in the tango icon above (a Bordeaux glass rather than a Burgundy glass) http://www.the-gift-of-wine.com/Images/glass_bordeaux.jpg http://www.the-gift-of-wine.com/Images/glass_burgundy.jpg Anyway, I suspect most of you really really won't care, as long as it looks something
Re: Cool animated display of wine appdb stats
Has anyone else noticed http://commons.wikimedia.org/wiki/File:History_Of_WineAppDB.gif which is shown on the right side of http://en.wikipedia.org/wiki/Wine_(software) ? It's kind of cool. Hats off to http://en.wikipedia.org/wiki/User_talk:Estemi who put it together. - Dan Yes that is cool - though I think a plotted graph would be easier to read. On the other hand the animation does help get the feeling of growth across. smime.p7s Description: S/MIME cryptographic signature
Re: Wine64 : Trying to load PE image for unsupported architecture (I386)
On Wed, 2009-02-11 at 23:34 +0100, Alexandre Julliard wrote: Not really, you'll of course still need to build a full 32-bit version of Wine, the 64-bit Wine will never be able to run 32-bit apps. What needs to be improved is that the 64-bit loader should be able to forward automatically to the 32-bit one when encountering a 32-bit app. So there's no plans for implementing a clone of WoW64? smime.p7s Description: S/MIME cryptographic signature
Re: shell32: add explorer toolbar bitmaps
Nuvola is good, but I think Tango looks a lot nicer if it could be available, and I think it blends with different platforms better - it's designed specifically with that in mind. Nuvola looks very KDEish and very very blue; not as good as Tango IMHO. Does anyone know how gnome manages to handle the CC licensing issue? - given that gnome uses it everwhere? On Sat, 2009-01-03 at 16:02 -0800, Juan Lang wrote: Why not use icons from the tango project? There's also the nuvola icon theme, which, conveniently, is already LGPL: http://www.icon-king.com/projects/nuvola/ --Juan smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Wine Icons
On Wed, 2008-12-10 at 20:43 +, Hervÿe9 Chanal wrote: On Friday 14 November 2008 19:13:32 Juan Lang wrote: I find that a bit alarming. I'm sure he's working very hard, and doing good stuff, but I don't think Wine should be redrawing anything. Not when we have Tango around - it's designed to try create some consistency through standardisation. IMO standards are really good! - we use them if we possibly can. The trouble is that the Tango icon set doesn't cover all the icons Wine needs. There's no Tango icon for regedit, for instance. IIRC there's Tango icon sets for specific applications. If we're doing our own icons anyway, we could try to keep them coherent with the rest of the Tango look and get the icons upstream to Tango. This seems like the most reasonable approach. Of course the only things I usually paint are walls so I'd have no idea how easy it is to match the Tango specs when designing icons. Cheers, Kai First of all, sorry to not have answered before and for my poor English, but I was quite busy these past months and I didn't see all these messages since today. I realize that the two patch I sent an hour ago are not the best answer to all these issues (I think these two newer icons look nicer in the open dialog boxes anyway) and that all theses points have to be discussed. When remaking icons, I tried to add a bit of consistency while improving a bit the icons. Obviously, I missed something. Reading all theses remarks, I agree that a better way to handle these icons are to use the Tango ones when they are available. As it was stated, including them is not straightforward and I haven't the skill to work on including these libraries into the wine tree. I hope somebody will work on these issues. In the meanwhile, maybe I'll try to improve the others shell32 icons as the bin or the computer which I found awful in this size but I don't know if it's a good idea. Cheers, Hervé Hi Herve, Yes I agree it would be good for the icons to get some improvement. Some of the ones there currently are pretty poor. We really need to try and get as much consistency as we can. I really would encourage you to go for tango if you can. It's served ReactOS well. It might even be possible for me to help with making custom Tango icons. Here on the Lumiera project we've adopted a method for making icons called the one canvas work flow, which was inspired by these videos: http://blip.tv/file/1075329 and http://blip.tv/file/1077148 This allows you to use a single SVG canvas with icon drawings specialised for different sizes. A script is then executed as part of the build process to render the individual sizes into their appropriate PNGs. The Tango library is large, so there are many icons available already. You might find this helpful in seeing what's already there: http://people.freedesktop.org/~jimmac/icons/#tit Let me know if I can help at all. God bless Joel smime.p7s Description: S/MIME cryptographic signature
RFC: Wine Icons
Hi All, I notice that some of Wine's icons have been changed in recent releases. In principle I think updating the icons is a great idea, but right now I gotta say that icons in Wine are a real disaster. Take a look here: http://www.airwebreathe.org.uk/icons.png This is a screenshot of the shell folder select dialog. Out of those icons My Documents looks the least broken - with it's wannabe 98/ME/2000 styling. Desktop, /, My Computer and Trash look like they've been taken from large icons which have shrunk - badly, and with a broken alpha channel. And the new golden Folder icons look completely out of place - they bear no resemblance to anything else, they've been scaled down poorly, they don't look like Windows icons, and they don't fit in with the Gnome desktop (and I can't imagine they'd look good in KDE or on Mac either). I'd really like for Wine to start using icons from the Tango project, or similar. The purpose of Tango was to create a set of icons that are clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely that's exactly what we want? Note that ReactOS is using Tango, and it seems to be working out pretty well for them! Any comments on that? Best Regards Joel Holdsworth smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Wine Icons
Hi Juan, The problem that I see with the new SVG icon support is that we use icotool to create the small-size icons from the SVG when the SVG is available. This rarely works well. I think we need to maintain hand-drawn small-size icons, and optionally use SVG to generate larger-size (larger than 32x32) icons. You're absolutely right. I'm the GUI maintainer for Lumiera, and we're generating our icons from SVGs. Each icon has to be specially adopted for each of the standard small sizes. We've adopted the one canvas icon workflow that Tango artists seem to be working toward. This is a video demonstrating the technique: http://blip.tv/file/1075329 Basically it involves drawing a basic icon, then tweaking it so that it looks good for different sizes. The SVG file is then rigged by putting in invisible bounding boxes marked with XML metadata (this can all be done in inkscape). We then have a python script* that then walks through the SVG, rendering all bounding boxes that it finds marked with the metadata. Here's an example of one of our SVGs: http://www.lumiera.org/gitweb?p=lumiera/joel;a=blob_plain;f=icons/svg/tool-arrow.svg;h=3f0b72102bc3fe846eaedecb2d1ffabe82610aec;hb=master As you can see, the icon has been tweaked to look good at 48x48, 32x32, 22x22 (24x24 is also produced from this size), and 16x16. The One Canvas Workflow makes it very easy to make consistent changes instead of having to keep hundreds of different files in synch. You might try bugging Herve, as he's been redrawing all the icons. I find that a bit alarming. I'm sure he's working very hard, and doing good stuff, but I don't think Wine should be redrawing anything. Not when we have Tango around - it's designed to try create some consistency through standardisation. IMO standards are really good! - we use them if we possibly can. Joel * see here: http://www.lumiera.org/gitweb?p=lumiera/joel;a=blob;f=admin/render-icon.py;h=26bdb36535fb70464b1db5d217d007d571519db6;hb=master smime.p7s Description: S/MIME cryptographic signature
Wine Status Page
Hi All, Are there any plans to update the percentages on the Wine status page any time soon? I'm curious to know how much progress has been made in the past 10 months. Regards Joel Holdsworth
