wine-devel November 2008

110 participants
239 discussions

by Aric Stewart

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

7 years, 11 months

What happened to the Fedora packages?

by Neal Gompa

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

9 years, 9 months

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?

by Detlef Riekenberg

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

10 years, 7 months

re: Wine t-shirts?

by Dan Kegel

Maarten wrote: > Why don't we have wine t-shirts any more? I dunno, where were they before? I just looked, couldn't find any on cafepress.com. I'd like to bring back the Codeweavers drunken penguin t-shirts, perhaps with a slightly more generic Wine design. Coincidentally, I found some site on the net had taken the logo from that shirt and erased the Crossover logo from the wine bottle; here's a cleaned-up copy: http://kegel.com/wine/wine-penguin-corkscrew.png

14 years, 8 months

winequartz.drv Mac OS X UI discontinued?

by Adam Strzelecki

Hi, I know that CodeWeavers supports quite nicely Mac builds of Wine, and CrossOver for Mac, yet all of them are X11. There was also once Darwine - an effort to provide Carbon Wine UI driver and Mac optimizations & L&F. Pretty many of those were merged back to Wine, but not winequartz.drv. Do you guys think about reviving winequartz.drv? This would greatly improve Wine on Mac as we could have native Mac fonts handling that's faster than FreeType, Dock icons for Wine applications, and few others. There's still old copy of the it hanging around, but it is abandoned, and no longer compiles with Wine. Or I think it would be cool to write new winecocoa.drv or sthing like that, as Apple officially states that Carbon is deprecated. While it is not well documented, it is pretty easy with Cocoa to make console non-bundled process to be UI foreground process and handle events and Dock: (This code is copyrighted by myself ;P) > int main(int argc, const char * argv[]) { > ProcessSerialNumber psn = {0, kCurrentProcess}; > OSStatus returnCode = TransformProcessType(&psn, > kProcessTransformToForegroundApplication); > SetFrontProcess(&psn); > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > [NSApplication sharedApplication]; > > NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"]; > [NSApp setApplicationIconImage:icon]; > > [NSApp finishLaunching]; > > NSWindow *window = [[NSWindow alloc] > initWithContentRect:NSMakeRect(0, 0, 100, 100) > styleMask:NSTitledWindowMask| > NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask > backing:NSBackingStoreBuffered defer:NO]; > [window center]; > [window setTitle:@"Test"]; > > NSButton *button = [[NSButton alloc] > initWithFrame:NSMakeRect(10, 10, 80, 80)]; > [button setTitle:@"What?"]; > [button setBezelStyle:1]; > [[window contentView] addSubview:button]; > [button release]; > > [window makeKeyAndOrderFront:NSApp]; > > while(1) { > NSEvent *event = [NSApp > nextEventMatchingMask:NSAnyEventMask > untilDate > :[NSDate distantFuture] > inMode:NSDefaultRunLoopMode > dequeue:YES > ]; > if(event) [NSApp sendEvent:event]; > } > [pool release]; > return 0; > } BTW. I heard that someone previously working for Wine project is now in Apple, it is true? Regards, -- Adam Strzelecki |: nanoant.com :|

14 years, 10 months

Wine desktop integration: current directory of app launched with doubleclick?

by Dan Kegel

I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files. My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing. ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work. If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME. I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@" That worked better; it let ViewSel.exe launch the DICOM viewer. So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan

15 years, 3 months

Re: [5/9] Add support of WDM drivers for USB devices.

by Alexandre Julliard

Alexander Morozov <amorozov(a)etersoft.ru> writes: > From ed6e12ca39e194829ad8d6be4fbd91d9f276d435 Mon Sep 17 00:00:00 2001 > From: Alexander Morozov <amorozov(a)etersoft.ru> > Date: Fri, 3 Oct 2008 17:57:00 +0400 > Subject: [PATCH] Add support of WDM drivers for USB devices. > > --- > configure.ac | 14 ++ > dlls/wineusbhub/Makefile.in | 15 ++ > dlls/wineusbhub/wineusbhub.c | 291 +++++++++++++++++++++++++++++++++++++++ > dlls/wineusbhub/wineusbhub.spec | 7 + > programs/winedevice/Makefile.in | 2 +- > programs/winedevice/device.c | 79 +++++++++++- > programs/wineusb/Makefile.in | 15 ++ > programs/wineusb/main.c | 224 ++++++++++++++++++++++++++++++ > server/device.c | 111 +++++++++++++++ > server/protocol.def | 16 ++ > tools/wine.inf.in | 10 ++ > 11 files changed, 782 insertions(+), 2 deletions(-) Your design needs a lot more thought. You can't add all these Wine-specific modules, or make winedevice special-case usb devices, or poll the server for the add_device request like you do. All this needs to be properly integrated in the existing infrastructure. -- Alexandre Julliard julliard(a)winehq.org

15 years, 3 months

re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Dan Kegel

FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.

15 years, 4 months

Valgrind warning in wined3d/swapchain.c in IWineD3DSwapChainImpl_Destroy

by Dan Kegel

Hi Stefan, you seem to have been in this code recently, could you have a look? This is a somewhat flaky error that happens about 80% of the time under heavy load on my quad core box. (This is valgrind's xml output format, it's pretty fluffy, sorry.) Thanks, Dan <error> <kind>UninitCondition</kind> <what>Conditional jump or move depends on uninitialised value(s)</what> <stack> <frame> <obj>dlls/wined3d/wined3d.dll.so</obj> <fn>IWineD3DSwapChainImpl_Destroy</fn> <dir>dlls/wined3d</dir> <file>swapchain.c</file> <line>75</line> </frame> <frame> <obj>dlls/d3d9/d3d9.dll.so</obj> <fn>IDirect3DSwapChain9Impl_Release</fn> <dir>dlls/d3d9</dir> <file>swapchain.c</file> <line>66</line> </frame> <frame> <obj>dlls/d3d9/d3d9.dll.so</obj> <fn>D3D9CB_DestroySwapChain</fn> <dir>dlls/d3d9</dir> <file>directx.c</file> <line>427</line> </frame> <frame> <obj>dlls/wined3d/wined3d.dll.so</obj> <fn>IWineD3DDeviceImpl_Uninit3D</fn> <dir>dlls/wined3d</dir> <file>device.c</file> <line>2426</line> </frame> <frame> <obj>dlls/d3d9/d3d9.dll.so</obj> <fn>IDirect3DDevice9Impl_Release</fn> <dir>dlls/d3d9</dir> <file>device.c</file> <line>98</line> </frame> <frame> <obj>dlls/d3d9/tests/d3d9_test.exe.so</obj> <fn>func_visual</fn> <dir>dlls/d3d9/tests</dir> <file>visual.c</file> <line>9960</line> </frame> <frame> <obj>dlls/d3d9/tests/d3d9_test.exe.so</obj> <fn>run_test</fn> <dir>dlls/d3d9/tests/../../../include/wine</dir> <file>test.h</file> <line>452</line> </frame> <frame> <obj>dlls/d3d9/tests/d3d9_test.exe.so</obj> <fn>main</fn> <dir>dlls/d3d9/tests/../../../include/wine</dir> <file>test.h</file> <line>502</line> </frame> </stack> </error>

15 years, 4 months

RFC: Proposed new web site design

by Jeremy White

At Wineconf, we made the decision to change the entry page to the Wine web site. The hope was to simplify and stream line it, and to put in place the infrastructure to start moving more content to the Wiki. Jeremy Newman and Jon Parshall have put a lot of time and energy into a proposed new design, following what we took away from the meetings at Wineconf. A mock up of that design is up now here: http://wine.codeweavers.com/winehq_new/ ...and the theming intended for all 'child' pages of the web site, starting with the Wiki: http://wine.codeweavers.com/winehq_new/wiki.html Beyond the normal controversy that any new design sparks there is one major potential controversial change. That is, I am asking for prime placement on the download page on behalf of CodeWeavers instead of the (stale and ugly, sorry) banner ads we used in the past. You can see our current concept around that positioning here: http://wine.codeweavers.com/winehq_new/download.html I hope that the general community sees that as a reasonable exchange for all of the work we put into Wine and hosting the Wine server, and a vast improvement over the banner ads. At any rate, comments and feedback are welcome. And in a vain attempt to prevent all the flames from scorching Jon and Jeremy, I'd like to officially state how much I appreciate their efforts. Cheers, Jeremy

15 years, 4 months

Jump to page:

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 November 2008