wine-devel April 2009

wine-devel@winehq.org

118 participants
279 discussions

Abiword unit / regression testing under Wine?
by Dan Kegel 20 Apr '09

20 Apr '09

It looks like you can build Abiword for Windows on Linux: http://abiword.com/mailinglists/abiword-dev/2008/Jan/0021.html Has anybody tried running the Abiword unit or regression tests on Wine? http://www.abisource.com/wiki/Unit_Test http://svn.abisource.com/abiword-testsuite/trunk/README - Dan

3 4

Re: sxs: Implement a stub CreateAssemblyCache to make Publish or Perish install.
by Kai Blin 20 Apr '09

20 Apr '09

On Sunday 19 April 2009 23:55:14 Kai Blin wrote: > As mentioned by the authors of Publish or Perish in their FAQ > (http://www.harzing.com/pop_faq.htm#Q309), Wine exporting sxs.dll and not > providing a real CreateAssemblyCache function trips up the installer. > This patch allows Publish or Perish to install without issues. > > Thanks to Donnie Berkholz for pointing me at this issue. > --- > dlls/sxs/sxs.c | 10 ++++++++++ > dlls/sxs/sxs.spec | 2 +- > 2 files changed, 11 insertions(+), 1 deletions(-) Of course the moment I sent this, I found the real implementation in fusion.dll. Sending a forward, feel free to ignore this patch. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

3 2

Re: [PATCH 1/2] Handle refcount of lights when interacting with viewport.
by Henri Verbeet 19 Apr '09

19 Apr '09

2009/4/19 Christian Costa <titan.costa(a)wanadoo.fr>: > @@ -760,6 +760,8 @@ IDirect3DViewportImpl_AddLight(IDirect3DViewport3 *iface, > lpDirect3DLightImpl->activate(lpDirect3DLightImpl); > } > > + IDirect3DLight_AddRef(lpDirect3DLight); > + > LeaveCriticalSection(&ddraw_cs); > return D3D_OK; > } > @@ -798,6 +800,7 @@ IDirect3DViewportImpl_DeleteLight(IDirect3DViewport3 *iface, > cur_light->active_viewport = NULL; > This->num_lights--; > This->map_lights &= ~(1<<lpDirect3DLightImpl->dwLightIndex); > + IDirect3DLight_Release(lpDirect3DLight); > LeaveCriticalSection(&ddraw_cs); > return D3D_OK; > } The patch looks ok in principle, but I think it's nicer to keep these close to the code that actually manipulates the list.

1 0

Re: wined3d: Fix prototype for EnumAdapterModes
by Stefan Dösinger 19 Apr '09

19 Apr '09

Am Freitag, 17. April 2009 03:10:26 schrieb Brad Martin: > --- > include/wine/wined3d.idl | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/wine/wined3d.idl b/include/wine/wined3d.idl > index b8691a7..6f86688 100644 > --- a/include/wine/wined3d.idl > +++ b/include/wine/wined3d.idl > @@ -2222,8 +2222,8 @@ interface IWineD3D : IWineD3DBase > ); > HRESULT EnumAdapterModes( > [in] UINT adapter_idx, > - [in] UINT mode_idx, > [in] WINED3DFORMAT format, > + [in] UINT mode_idx, > [out] WINED3DDISPLAYMODE *mode > ); > HRESULT GetAdapterDisplayMode( Are you sure you can do this without adjusting the implementation function in dlls/wined3d/directx.c and the callers in d3d9, d3d8 and ddraw? I don't have the code checked out currently, so I can't check. Maybe the calls and the implementation match and just the .idl prototype is different.

2 1

Re: gdi32: fetch child fonts by real parent font name
by Lei Zhang 19 Apr '09

19 Apr '09

On Tue, Apr 14, 2009 at 7:11 AM, Paul TBBle Hampson <Paul.Hampson(a)pobox.com> wrote: > This patch fixes bug 18044. > > Basically, the built-in FontLink functionality for subsituting > alternative fonts where a certain font is missing glyphs (used > by default for Tahoma and Microsoft Sans Serif under Windows) doesn't > work if the font is loaded via a FontSubstitution entry. > > The only place this is really likely to happen turns out to be using > MS Shell Dlg as a font name, which is generally discouraged for general > UI use (as far as I can tell, you're supposed to use a lookup function > which normally returns Tahoma or Microsoft Sans Serif directly) but > this happens to be the case for uTorrent 1.8 onwards. > -- > Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com This looks a lot like http://www.winehq.org/pipermail/wine-patches/2008-December/065543.html.

2 1

XI2 DirectInput mouse implementation RFC
by Paul TBBle Hampson 19 Apr '09

19 Apr '09

I've thrown together a rather-rough-but-working-in-a-limited-sense implementation of XInput2-based DirectInput. It's got a fair few problems, I'm mainly interested in feedback on the approach, although obviously any code or style criticisms are welcome. Current limitations: * Doesn't check for XInput2.h, so won't build without it. * Doesn't send mouse-ups. XI2 bug. * Doesn't send events after mouse-down until after mouse-up on a window. I'm pretty sure this is an XI2 bug, but it might be a design feature. * Doesn't support exclusive mode. XI2 bug (grabs not yet implemented) * Mouse buttons aren't remapped nicely downwards. Need to look harder at this, my mouse reports buttons 1, 2, 3, 4, 5, 8 and 9 under X. 4 and 5 are scroll, 6 and 7 might be horizontal scroll in which case if this is always the case we can just remap downwards. * Only supports the Mouse. Adding keyboard support should be really trivial compared to actually getting the framework right. If this format is fine, then the first patch is basically ready to go, the latter two patches may need to be re-split or merged more sensibly. I've also attached a couple of fixes for the XI2 stuff if anyone wants to try it. One only affects 64-bit builds, and one fixes XCB locking assertions which you could probably otherwise ignore. So they're both kinda option in the Wine context. And one more patch, against the xinput utility from whot's git tree, to fix a compile failure. 0001-Unlock-display-after-XIQueryVersion.patch > libXi 0001-Clear-definitions-of-X-types-defined-to-wire-types.patch > x11proto-input 0001-Ensure-we-have-a-definition-of-BYTE.patch > xinput -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com Shorter .sig for a more eco-friendly paperless office.

1 0

Re: [PATCH 2/4] gdi32: fetch child fonts by real parent font name
by James McKenzie 19 Apr '09

19 Apr '09

Paul TBBle Hampson wrote: > This patch fixes bug 18044. > > Basically, the built-in FontLink functionality for subsituting > alternative fonts where a certain font is missing glyphs (used > by default for Tahoma and Microsoft Sans Serif under Windows) doesn't > work if the font is loaded via a FontSubstitution entry. > > The only place this is really likely to happen turns out to be using > MS Shell Dlg as a font name, which is generally discouraged for general > UI use (as far as I can tell, you're supposed to use a lookup function > which normally returns Tahoma or Microsoft Sans Serif directly) but > this happens to be the case for uTorrent 1.8 onwards. > > Paul: Where is the patch? I could not find it. James McKenzie

2 1

Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
by Scott Ritchie 18 Apr '09

18 Apr '09

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/63… 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 like a wine glass and has the words Wine next to it. But I did want to start a discussion, especially because this represents our projects logo and is, to a real extent, more than just an icon. Meanwhile, I'll try drumming up some artists to see if I can get a few different Tango-compliant icons for us to chose from. Thanks, Scott Ritchie

10 16

Article on wine development strategy
by Dan Kegel 18 Apr '09

18 Apr '09

http://yokozar.org/blog/archives/48 is a fun little look at using simulation to see how various strategies might affect Wine development. The one that worked out best was to pick some random user who's almost happy, fix the last few bugs that are keeping his apps from working, and then once he's happy, move on to the next such user. - Dan

6 9

re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
by Dan Kegel 17 Apr '09

17 Apr '09

The Ubuntu Studio logos look fine. I'd be happy with adopting them if they really make Wine fit in better with modern desktops. No need to wait for 1.2, just check 'em in now, 1.2 will be along soon enough.

9 13

← Newer
1
...
11
12
13
14
15
16
17
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2009