World Wine News

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

• In Painter 5
  • Cursor pressure works. (Therefore is usable by most)
  • Cursor orientation is a little odd: The orientation maths needs to be re-done.
  • No eraser. Haven't yet cracked what enables the eraser.
  • Doesn't work in desktop mode: Need to map to desktop coordinates.
  • Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-)
  • Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions.
• In Photoshop 6
  • Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode.
  • Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs.

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

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:

trace:font:ReadFontDir Found "arial.ttf" in "/devel/syncad/.SynaptiCAD/mnt/c/windows/Fonts" trace:font:AddFontFileToList Loading font file "/devel/syncad/.SynaptiCAD/mnt/c/windows/Fonts/arial.ttf" index 0
trace:font:AddFontFileToList fsCsb = 400001ff ffff0000/00007a87 80000000 00000008 00000000
trace:font:AddFontFileToList Added font L"Arial" L"Regular"

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

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:

a. You tell Wine to do so in the config file
b. Wine can't find any TrueType fonts
or
c. Wine can't find, or wasn't compiled with, a working version of FreeType.

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

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.

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.