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

Re: Right-To-Left (RTL) languages and Wine

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > Ok, thanks for that explanation. Do you know if dialog resources also > inherit WS_EX_LAYOUTRTL? A quick test suggests that they don't. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2010

Re: Right-To-Left (RTL) languages and Wine

by Paul Vriens

On 07/30/2010 10:02 AM, Alexandre Julliard wrote: > Paul Vriens<paul.vriens.wine(a)gmail.com> writes: > >> On 07/29/2010 08:13 PM, Alexandre Julliard wrote: >>> That depends on the situation. In some cases it can be set globally >>> through the version resources, in other cases it will have to be set on >>> an individual resource basis, or specified directly in the code. >> >> When you say 'globally' do you mean everything running under (one) >> wineserver? > > No, I mean globally for a process, this is always per-process. If you > put the magic string in the version resources the whole process is RTL, > making all the windows automatically WS_EX_LAYOUTRTL and mirroring all > the UI. That's the correct approach for Wine builtin apps, once > WS_EX_LAYOUTRTL works properly. > Ok, thanks for that explanation. Do you know if dialog resources also inherit WS_EX_LAYOUTRTL? After reading http://msdn.microsoft.com/en-us/goglobal/bb688119.aspx ("Activating Mirroring for Dialog Resources") it's not very clear to me (my thought is that it doesn't inherit). -- Cheers, Paul.

July 30, 2010

Re: [3/5] WineD3D: Get rid of some C99 code

by Henri Verbeet

Please use http://www.winehq.org/pipermail/wine-patches/2010-July/091554.html instead. Also, the module name is wined3d.

July 30, 2010

Re: Right-To-Left (RTL) languages and Wine

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > On 07/29/2010 08:13 PM, Alexandre Julliard wrote: >> That depends on the situation. In some cases it can be set globally >> through the version resources, in other cases it will have to be set on >> an individual resource basis, or specified directly in the code. > > When you say 'globally' do you mean everything running under (one) > wineserver? No, I mean globally for a process, this is always per-process. If you put the magic string in the version resources the whole process is RTL, making all the windows automatically WS_EX_LAYOUTRTL and mirroring all the UI. That's the correct approach for Wine builtin apps, once WS_EX_LAYOUTRTL works properly. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2010

Re: explorer: implement X session management

by Paul Chitescu

On Friday 30 July 2010 06:53:54 am Paul "TBBle" Hampson wrote: > On 30 July 2010 01:30, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > >> Changelog: > >> * explorer: implement X session management > > > Explorer should not have X11 as a dependency. This should be implemented > > inside of winex11.drv. > > A (previously-discussed years ago) model for DirectInput/RawInput > handling would have given explorer.exe an X11 dependency since there > needs to be a single process for a given wine server that handles > direct (XI2-style) input. > > I assume session shutdown notification works the same way, but haven't > read the above patch very hard... > > Unless you're suggesting implementing it inside winex11.drv and having > explorer then provide winex11.drv a non-X11-specific callback for when > a session termination message arrives, to be turned into the > Win32-equivalent message. (Which seems less correct to me, but not > unreasonable) > > [Apologies for the duplicate, I forget that Gmail is "Reply" by default] > > -- > Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com Please note that there can be more than one explorer per running wineserver instance, it is one per desktop. Virtual desktops and remote connections make the problem more complex. These should really be separate sessions (but wine doesn't handle yet logon sessions and stations).

July 30, 2010

Re: explorer: implement X session management

by Damjan Jovanovic

On Fri, Jul 30, 2010 at 5:53 AM, Paul "TBBle" Hampson <Paul.Hampson(a)pobox.com> wrote: > On 30 July 2010 01:30, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: >> Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > >>> Changelog: >>> * explorer: implement X session management > >> Explorer should not have X11 as a dependency. This should be implemented >> inside of winex11.drv. > > A (previously-discussed years ago) model for DirectInput/RawInput > handling would have given explorer.exe an X11 dependency since there > needs to be a single process for a given wine server that handles > direct (XI2-style) input. > > I assume session shutdown notification works the same way, but haven't > read the above patch very hard... > > Unless you're suggesting implementing it inside winex11.drv and having > explorer then provide winex11.drv a non-X11-specific callback for when > a session termination message arrives, to be turned into the > Win32-equivalent message. (Which seems less correct to me, but not > unreasonable) > > [Apologies for the duplicate, I forget that Gmail is "Reply" by default] > > -- > Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com > Well the other option, which I am working on, is for each Wine process to host all the session management code inside a winex11.drv thread only - and send WM_[QUERY]ENDSESSION messages to its own in-process windows. This strikes me as a better idea than using a single Wine-global explorer thread - each process can individually name itself to the session manager, so the user knows exactly what's blocking shutdown. Damjan Jovanovic

July 30, 2010

Re: wiki slightly broken still?

by Francois Gouget

On Thu, 29 Jul 2010, Dimi Paun wrote: > On Thu, 2010-07-29 at 18:17 +0200, Michael Stefaniuc wrote: > > Yes, the LocalBadContent page got pretty long; I'm fairly sure it's > > the spam checking that takes so long. > > I tried to empty it, and it does seem to help. However, it's not > the only cause of the problem, it's still not fast even with an > empty LocalBadContent. I have a theory: did the script move the remaining files to another directory? If not it may be that there's a fragmentation problem at the directory level; i.e. the directory structure was grown to accomodate 32k entries, not there's only 5k entries but they are spread over the old 32k entries leading to inefficient lookups? If so something like this should fix it: mkdir newdir mv olddir/* newdir # hope there's no dot file rmdir olddir mv newdir olddir -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A polar bear is a cartesian bear after a coordinate transform.

July 30, 2010

Re: Right-To-Left (RTL) languages and Wine

by Paul Vriens

On 07/29/2010 08:13 PM, Alexandre Julliard wrote: > Paul Vriens<paul.vriens.wine(a)gmail.com> writes: > >> I've been in talks with a Hebrew translator for some time now and I'd >> like to have Wine being able to start doing more RTL stuff. >> >> I'm looking for example at http://bugs.winehq.org/show_bug.cgi?id=1158 >> >> If I run an English winmine.exe on an Arabic box (thanks to the >> testbot) the main window will shows as normal LTR window layout with >> the menu's left justified as well. >> >> So eventhough the locale is set to Arabic it doesn't turn 'everything' >> into RTL. >> >> If we don't change the resource files for the RTL languages, that same >> logic will give us LTR Wine applications or am I wrong here? > > That depends on the situation. In some cases it can be set globally > through the version resources, in other cases it will have to be set on > an individual resource basis, or specified directly in the code. When you say 'globally' do you mean everything running under (one) wineserver? As said, I guess our Wine programs should be RTL if a user is running with the appropriate locale. Other programs should run RTL or LTR depending how they are coded. > > I don't think we are quite ready to enable RTL globally though, it's > still pretty broken. I'm currently trying to improve it. Great, I saw the commits before I saw this email. Thanks. -- Cheers, Paul.

July 30, 2010

Re: [2/4] tools: enable .lnk thumbnailing in Gnome

by Nicholas van Oudtshoorn

On 07/28/2010 08:54 AM, Scott Ritchie wrote: > On 07/26/2010 03:57 AM, Alexandre Julliard wrote: >> Damjan Jovanovic<damjan.jov(a)gmail.com> writes: >> >>> diff --git a/tools/Makefile.in b/tools/Makefile.in >>> index a9ec324..a0c9c99 100644 >>> --- a/tools/Makefile.in >>> +++ b/tools/Makefile.in >>> @@ -75,6 +75,8 @@ install install-lib:: wine.inf $(INSTALLDIRS) >>> $(INSTALL_DATA) $(SRCDIR)/l_intl.nls $(DESTDIR)$(datadir)/wine/l_intl.nls >>> $(INSTALL_DATA) $(SRCDIR)/wine.desktop $(DESTDIR)$(datadir)/applications/wine.desktop >>> -$(UPDATE_DESKTOP_DATABASE) >>> + gconftool --set -t string /desktop/gnome/thumbnailers/application(a)x-ms-shortcut/command "wine winemenubuilder -t %i %o" || true >>> + gconftool --set -t bool /desktop/gnome/thumbnailers/application(a)x-ms-shortcut/enable "true" || true >> >> There needs to be a better way of doing this. Probably filing a bug with >> freedesktop.org is in order. >> > > For sure. Thumbnailers are just shell scripts, but there is currently > no cross distro way to enable them. > > My current "solution" is to just do this at the packaging layer and > ignore KDE entirely until someone tells me the equivalent of installing > gconf schemas, but this is obviously not good. > > Thanks, > Scott Ritchie > > > Inspired by reading this in the newsgroup, I've thrown together a KDE plugin to do .lnk thumbnailing. I don't suppose the code belongs in the wine project (for a number of reasons, not least of which it's C++). If anyone's interested, though, it's available at http://code.google.com/p/kdewinelnkthumbnailer/ It'd be great if there was a cross-desktop way to do all of this... - Nicholas van Oudtshoorn (It's been a while since I've done any coding work, so it's probably not the most beautiful code! But it works!)

July 30, 2010

Re: [2/4] tools: enable .lnk thumbnailing in Gnome

by Nicholas van Oudtshoorn

On 07/28/2010 08:54 AM, Scott Ritchie wrote: > On 07/26/2010 03:57 AM, Alexandre Julliard wrote: >> Damjan Jovanovic<damjan.jov(a)gmail.com> writes: >> >>> diff --git a/tools/Makefile.in b/tools/Makefile.in >>> index a9ec324..a0c9c99 100644 >>> --- a/tools/Makefile.in >>> +++ b/tools/Makefile.in >>> @@ -75,6 +75,8 @@ install install-lib:: wine.inf $(INSTALLDIRS) >>> $(INSTALL_DATA) $(SRCDIR)/l_intl.nls $(DESTDIR)$(datadir)/wine/l_intl.nls >>> $(INSTALL_DATA) $(SRCDIR)/wine.desktop $(DESTDIR)$(datadir)/applications/wine.desktop >>> -$(UPDATE_DESKTOP_DATABASE) >>> + gconftool --set -t string /desktop/gnome/thumbnailers/application(a)x-ms-shortcut/command "wine winemenubuilder -t %i %o" || true >>> + gconftool --set -t bool /desktop/gnome/thumbnailers/application(a)x-ms-shortcut/enable "true" || true >> >> There needs to be a better way of doing this. Probably filing a bug with >> freedesktop.org is in order. >> > > For sure. Thumbnailers are just shell scripts, but there is currently > no cross distro way to enable them. > > My current "solution" is to just do this at the packaging layer and > ignore KDE entirely until someone tells me the equivalent of installing > gconf schemas, but this is obviously not good. > > Thanks, > Scott Ritchie > > > Inspired by reading this in the newsgroup, I've thrown together a KDE plugin to do .lnk thumbnailing. (KDE already has the ability to preview exe files using icotools, which I didn't realise!) I don't suppose the code belongs in the wine project (for a number of reasons, not least of which it's C++). If anyone's interested, though, it's available at http://code.google.com/p/kdewinelnkthumbnailer/ It'd be great if there was a cross-desktop way to do all of this... - Nicholas van Oudtshoorn (It's been a while since I've done any coding work, so it's probably not the most beautiful code! But it works!)

July 30, 2010