April 2011 - Wine-Devel - list.winehq.org

Re: RFC: Standardising the Help menus

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > * Putting the program name in the menu name also feels redundant to me. > Does one really expect Regedit to give you the help for Notepad? > Similarly one would expect an 'About' menu to be about the current > program, although in Wine's case it's more a generic About dialog. I agree that the program name is not needed for something like 'Contents'. However, 'About' all by itself doesn't feel right. 'About <program>' is IMO preferable for grammatical reasons, even if it's a little extra work for translators. -- Alexandre Julliard julliard(a)winehq.org

April 1, 2011

Re: RFC: Standardising the Help menus

by Jerome Leclanche

On Fri, Apr 1, 2011 at 4:02 PM, Francois Gouget <fgouget(a)free.fr> wrote: > > I am in the process of reviewing Wine's resource files and more > specifically the menus of its applications, and even more specifically > the Help menu for now. > > Currently they are a bit inconsistent and I propose to standardise them > by following the GNOME interface guidelines. That is use the following > structure: > > Help > Contents F1 > About > > So here is the data I gathered on this eminently critical issue ;-) > > ... Great summary. Inconsistent menus always bothered me in wine; had filed bugs 18973 and 19347 for similar issues a while back. I'm really happy about the recent cleanup of all the unimplemented menu items, they were truly annoying. My first instinct would have been to support the Windows guidelines, but seeing as MS themselves do not respect them, there isn't much point to that. The KDE guidelines are very specific to KDE. The "What's this" is a Qt feature which, for some reason, is being enforced on all KDE apps (despite being completely unused, and usually unimplemented). It's safe to say that overall, the KDE guidelines are pointless to follow for Wine. As for OO/Firefox, they tend to be Windows GUI designs ported to GTK rather than the opposite, so it makes sense they would follow Windows guidelines. Fully agreed on supporting the HIG on that one. > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Stolen from an Internet user: > "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !" > > > -- Jerome Leclanche

April 1, 2011

RFC: Standardising the Help menus

by Francois Gouget

I am in the process of reviewing Wine's resource files and more specifically the menus of its applications, and even more specifically the Help menu for now. Currently they are a bit inconsistent and I propose to standardise them by following the GNOME interface guidelines. That is use the following structure: Help Contents F1 About So here is the data I gathered on this eminently critical issue ;-) Windows User Experience Interaction Guidelines ---------------------------------------------- * The section about standard menus say we should use: http://msdn.microsoft.com/en-us/library/aa511502.aspx Help <program name> help F1 <separator> About <program name> * All applications seem to conform to the specification for the 'About' menu (except Sound Recorder which uses 'About' and Disk Management which incorrectly adds an ellipsis). * But for the 'Help' menu there is a lot of inconsistency. In Windows 7 I got: 'View Help': Notepad, Solitaire, Mine Sweeper, Calculator, FreeCell, Internet Backgammon, Spider Solitaire '<program name> Help': Internet Explorer 8 '<program name> Help Topics': Task Manager 'Help Topics': Regedit, Task Scheduler, Disk Management 'Help': Sound Recorder 'Contents': msinfo32 'None' (replaced by a toolbar icon): Explorer, Paint, XPS Viewer, Windows Media Player, Backup and Restore, Sync Center * From the point above I conclude that following the Microsoft Guidelines will not particularly help consistency with other Windows applications, nor help meet the users expectations. * Putting the program name in the menu name means we will have as many strings to translate as there are programs. This is more work for translators and can yield inconsistencies from one program to the next. * Putting the program name in the menu name also feels redundant to me. Does one really expect Regedit to give you the help for Notepad? Similarly one would expect an 'About' menu to be about the current program, although in Wine's case it's more a generic About dialog. Unix Interface Guidelines ------------------------- * The GNOME Human Interface Guidelines specify: http://library.gnome.org/devel/hig-book/2.32/hig-book.html#menu-standard-he… Help Contents F1 About * This allows sharing of the translations across programs. * It would make Wine's applications consistent with the system ones... as long as one uses Gnome. * Because unfortunately this is a case where the KDE User Interface Guidelines differ: http://developer.kde.org/documentation/standards/kde/style/menus/help.html Help <program name> Handbook... F1 What's This? Shift+F1 <separator> About <program name>... About KDE... * Using ellipses as specified for these menus makes absolutely no sense and is inconsistent with their own guidelines regarding them. Fortunately this seems to be a bug in the specification and the applications don't uses ellipses (feel free to report this bug). * Both GNOME and KDE applications follow their guidelines pretty well. (except Gnome's Network Tools app which uses 'Help Ctrl+H' instead of 'Contents F1', maybe another bug to report) * However other applications, specifically FireFox and OpenOffice seem to follow the Windows guidelines. VMware Workstation follows them for the About menu, but follows GNOME's guidelines for the 'Contents' help menu. * So given that we cannot be consistent with all Unix applications I propose to pick the scheme that requires the less work for us, which is GNOME's scheme. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

April 1, 2011

Re: [3/3] wined3d: Get rid of context_validate.

by Alexandre Julliard

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > It should not be needed anymore, now the wined3d context is implicitly > validated on GL context activation. The check itself wasn't reliable > because of some threading issues and it also brought a small performance hit. It crashes here (nvidia driver 256.53): ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so visual.c && touch visual.ok visual.c:949: Tests skipped: D3DFMT_P8 textures not supported wine: Unhandled page fault on read access to 0x00000004 at address 0x564def4d (thread 0044), starting debugger... Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x564def4d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:564def4d ESP:0032f110 EBP:7e27f248 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:682e96c0 ECX:00000000 EDX:00000000 ESI:56d8f000 EDI:00000000 Stack dump: 0x0032f110: 56d8f000 00000000 00000004 02000007 0x0032f120: 556be000 02000007 7df05fa0 5572fc1e 0x0032f130: 7e27f270 556be000 56d8f000 02000007 0x0032f140: 00000000 00000014 00000000 7e0db298 0x0032f150: 02000007 02000007 7df05fa0 56d8f000 0x0032f160: 7e27f270 7e0db1a0 7e27f248 5572fdbf Backtrace: =>0 0x564def4d in libnvidia-glcore.so.256.53 (+0xd38f4d) (0x7e27f248) 1 0x00000000 (0x7e106410) 0x564def4d: testl $0xe000000,0x4(%edi) -- Alexandre Julliard julliard(a)winehq.org

April 1, 2011

Re: About Wine/Gecko/MSHTML

by Jacek Caban

Hi Artem, On 3/31/11 9:13 PM, Artem S. Tashkinov wrote: > Hi, > > I have no idea to what extent and how Mozilla's Gecko library is being used in Wine (all I know is that it's used in Wine's MSHTML component), but recently a Mozilla developer made a very unsettling announcement: groups dot google dot com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion > > I wonder if this announcement has any adverse effects on Wine's future. We don't use any of mentioned APIs that are about to be removed. We use Gecko more internal APIs. They are unfrozen for a while now and it's not really a news that Mozilla developers don't care much about embedders when making product direction decisions. It's definitely not a good for us, but it's nothing new, so I wouldn't worry too much (at lest not yet). Cheers, Jacek

April 1, 2011

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista

by Dmitry Timoshkov

Austin Lund <austin.lund(a)gmail.com> wrote: > --- a/dlls/user32/tests/msg.c > +++ b/dlls/user32/tests/msg.c > @@ -12681,6 +12681,7 @@ static const struct message WmSetParentSeq_2[] = { > { WM_WINDOWPOSCHANGING, sent|wparam, SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE }, > { EVENT_OBJECT_HIDE, winevent_hook|wparam|lparam, 0, 0 }, > { WM_WINDOWPOSCHANGED, sent|wparam, SWP_HIDEWINDOW|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, > + { HCBT_SETFOCUS, hook|optional }, > { WM_NCACTIVATE, sent|wparam, 0 }, > { WM_ACTIVATE, sent|wparam, 0 }, > { WM_ACTIVATEAPP, sent|wparam, 0 }, This does look correct. It's pretty strange that other Windows versions don't send HCBT_SETFOCUS notification before WM_KILLFOCUS (which is right after WM_ACTIVATEAPP in the message sequence). -- Dmitry.

April 1, 2011

Re: Why do the wintab32 tests load the dll at runtime?

by John Klehm

On Thu, Mar 31, 2011 at 5:27 AM, Francois Gouget <fgouget(a)free.fr> wrote: > > The subject says it all. > Why do the wintab32 tests load the dll at runtime instead of simply > linking with wintab32.dll? > It was to make it easier when the dll wasn't around. I pretty sure wintab32 is not included by default with XP. I've only looked briefly but it seems to be MIA from Windows 7 as well (atleast in the windows direcotry its' not to be found with a search). I think it's possible that there might be a default driver included with Vista or Windows 7 given the amount of built in tablet stuff in those versions of windows I might just have missed it. --John

April 1, 2011

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=10257 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

April 1, 2011