Wine Traffic #261 For 11�Feb�2005

By Brian Vincent

Table Of Contents

Introduction

This is the 261st issue of the Wine Weekly News publication. Its main goal is to float. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 114 posts in 477K.

There were 49 different contributors. 23 posted more than once. 25 posted last week too.

The top posters of the week were:

1. Wintab Status

10�Feb�2005 (1 post) Archive Link: "The status of the wintab dll"

Topics: Status Updates

People: Robert North,�,�Unknown

Robert North posted a bunch of patches a few weeks ago to improve Wine's tablet support. This week he wrote to give and update about what works, what doesn't, and what areas people could work on:

I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches.

Applications: Current status

To Do

  1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this)
  2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done.
  3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen)
  4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows.
  5. Tests
    --My current philosophy on tests is... Use Photoshop & Painter, any formal tests can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict.

Long term to do (Anyone interested?)

There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;)

  1. Improve configuration of wintab.
    Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file.
  2. Handle Z-Order of context properly. This entails
    • sharing Z-Order between apps.
    • Working out exactly what role windows have in determining tablet context z-orders.
    • Allow tablet contexts that don't cover the whole screen/tablet.
    • Handle inter-application clipping of tablet contexts
    • Allow all application's windows to receive tablet events when tablet context is on top
  3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse)
  4. Unicodify
  5. Implement various wintab extensions.
  6. Implement wintab manager functions.
  7. Tests.

Unknowns

  1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop?
  2. How Painter detects the eraser. Have 3 possibilities
    1. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!)
    2. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only).
    3. I've missed something
  3. Requirements of other applications

2. Configuring TrueType Fonts

7�Feb�2005 (3 posts) Archive Link: "Question about TrueType rendering"

Topics: Fonts

People: Eric Frias,�Huw Davies,�

Eric Frias wanted to know exactly how Freetype and Wine interact to use TrueType Fonts:

I'm trying to get winelib working on a platform whose X server doesn't have native support for TrueType fonts. I've configured wine with freetype, but it never seems to display the TrueType fonts. I don't have xfsft or xfstt installed.

Should I expect this to work? I don't understand whether Wine uses the freetype library to render TrueType fonts, or if it just uses it for some other purpose (like getting metrics) and still depends on the font server to render the fonts.

I see messages like this when wine starts, so it looks like wine is finding my fonts, but when I Call CreateFont("Arial"), it never maps to a TrueType font:

Is it still necessary to run xfsft to use these fonts, or should wine be able to use them on its own?

Huw Davies explained what the trace message meant and what was going on:

If you've got this, then it means Wine is happily using FreeType. In this case Wine will (by default) render the fonts itself and display them via the X RENDER extension. This means that it'll not use X11 font mechanisms at all. If Wine can't use the RENDER extension then it will fallback to using X requests such as XPutImage which again won't use the X11 font mechanism.

In fact Wine will only use X11 fonts if either:

3. Recycle Bin Needs Implementing

9�Feb�2005 (3 posts) Archive Link: "Re: [Discuss] Recycle Bin problem with Preclick image editing software"

Topics: Integration

People: Mike Hearn,�David Lee Lambert,�

Mike Hearn forwarded an email to wine-devel about an application that needed some special functionality to be implemented:

Context is: app has a "send to recycle bin" option to delete photos. Doesn't work. Native shell32/shfolder fixes it. If anybody is up for what is probably an easy task, figure out why and fix it so c:\Recycled is used.

For bonus points we should bridge it to KDE/GNOME so if an app recycles something it appears in your actual trash can

David Lee Lambert looked into it and reported some more details:

comment in dlls/shell32/shlfileop.c says: "unimplemented and break if any other flag set: FOF_ALLOWUNDO, FOF_WANTMAPPINGHANDLE". FOF_ALLOWUNDO = 0x40 is the flag that says to use the Recycle Bin, if available. Note that Windows itself doesn't use the recycle bin on network drives or removable disks.

Probably some extra logic could be added around line 1085 to issue a 'rename' (or MoveFileEx) call in either of the following situations:

  1. The file is under the user's home directory; move it to ~/Desktop/Trash or ~/.gnome-desktop/Trash
  2. The file is on a VFAT partition; move it to $(MOUNT_POINT)/Recycled

However, the app in question is probably upset about something else, and there are still some stub functions in that file, so I doubt that a "correct Recycle Bin" is first-priority for the Wine team.

4. Bi-arch Support on AMD64

7�Feb�2005�-�8�Feb�2005 (4 posts) Archive Link: "Re: bi-arch on an amd64"

Topics: Ports

People: Alex Woods,�

Alex Woods described the steps he needed to perform in order to get a bi-arch build of Wine on an AMD64:

It turns out, it's actually a problem with kernel 2.6.10 that I was encountering, and the multilib build is a success. With kernel 2.6.9 wine runs perfectly.

To round things up, here are the steps I took to achieve this:

  1. Apply patch below (will be submitting to wine-patches)
  2. Move your /usr/include out of the way and replace with one from an ix86 box (might not be necessary if your distro has multilib includes)
  3. autoconf
  4. ./configure --x-libraries=<path_to_your_multilib_x_libs>
  5. make depend && make
  6. make install
  7. Don't forget to put your /usr/include back ;)

I suppose I should see what's up with kernel 2.6.10 now.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.