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
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...
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
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
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 :|
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
Patchwatcher is almost recovered from its move
to the new machine. I expect to turn email
notifications back on tomorrow.
The old machine could only just barely keep up with
the patch flow. The new machine is two or so times
faster, so it's much, much better at catching up
when a patch flood hits it.
The new machine has a fairly modern nvidia card, so
more of the tests are actually run.
To-do list:
1. Figure out what card I need to buy to avoid these:
overlay.c:218: Tests skipped: Failed to initialize ddraw
overlay.c:89: Tests skipped: Failed to create an overlay - assuming
not supported
sysparams.c:2313: Tests skipped: Setting depth 24 failed(ret = -2)
visual.c:7453: Tests skipped: Card has unconditional pow2 support,
skipping conditional NP2 tests
visual.c:8456: Tests skipped: Only 1 simultaneous render target
supported, skipping MRT test
visual.c:8595: Tests skipped: D3DFMT_G16R16F textures not supported
visual.c:8595: Tests skipped: D3DFMT_G32R32F textures not supported
visual.c:9690: Tests skipped: Sanity check returned an incorrect
color(00552200), can't assure the correctness of the tests, skipping
2. Install corefonts to avoid these:
font.c:1163: Tests skipped: Arial is not installed
font.c:1473: Tests skipped: Arial is not installed
font.c:1653: Tests skipped: Arial Black is not installed
font.c:1653: Tests skipped: Symbol is not installed
3. Figure out what's causing these:
font.c:1879: Tests skipped: Font DejaVu Sans doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font Lohit Gujarati doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font Lohit Hindi doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font Lohit Punjabi doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font Lohit Tamil doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font Mallige doesn't contain 'x', skipping the test
font.c:1879: Tests skipped: Font OpenSymbol doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font Purisa doesn't contain 'x', skipping the test
font.c:1879: Tests skipped: Font UnBatang doesn't contain 'x', skipping the test
font.c:1879: Tests skipped: Font UnDotum doesn't contain 'x', skipping the test
font.c:1879: Tests skipped: Font Vemana2000 doesn't contain 'x',
skipping the test
font.c:1879: Tests skipped: Font utkal doesn't contain 'x', skipping the test
4. Get the mailing list parser to handle multiple overlapping patch series
so it doesn't get stuck when somebody sends a partial one.
5. Bring up my new refactored patchwatcher script.
6. Add multiple worker machines.
7. Bring up valgrind support.
8. Figure out why I have to blacklist the following tests:
comctl32:tooltips.c
ddraw:visual.c
dsound:ds3d.c
kernel32:thread.c
riched20:editor.c
user32:input.c
user32:msg.c
user32:win.c
wininet:http.c
9. Figure out why winmm_test.exe.so wave.c always hangs on my new test machine.
"If someone wants to write a pulseaudio driver, he should feel free to
do so, but he should be aware that just writing a simple 20 line
linear PCM out driver is not sufficient."
http://bugs.winehq.org/show_bug.cgi?id=10495
I have written a waveout/in driver for wine to use pulseaudio which is
in bugzilla. I would appreciate feedback on it, as I have received
little thus far. I would appreciate it also if people took care to
ensure that their instance of pulseaudio is properly setup before
trying.
Current problems include properly recovering from disconnects of both
audio streams and server connections. WaveIn is currently buggy and
usually has a larger latency. Multiple instances of one sink/source is
also currently a problem. Currently WaveIn / WaveOut wodMessage /
widMessage functions use "device IDs" which are basically array
indexes of an array of available "devices." Without instance
information it is hard to allow an application to open the same device
more than once.
Thanks
- Art
The Chinese resource files are already utf-8,
but I suspect lots of other files are in obscure character
sets, which complicates patch processing and display.
Just how silly would it be for us to bite the bullet
and set all source files to utf-8?
We'd need to recode a bunch of files once,
but after that, there'd be less confusion about
how to view and edit various resource files.
Not saying we should up and do it, just
throwing out an idea for discussion...
Juan wrote:
> Since Rob was noncommittal about whether -Werror was a good or a bad
> idea, I'll take a stance: I think it's a bad one. ...
> some warnings are just plain wrong. In some cases the "fix"
> to quiet the warning is uglier than the warning.
In those cases, we can disable the warning.
> Having a code base that has hundreds of warnings is also a problem,
> but we're fortunate enough not to be in that situation.
Are you sure about that? When I configure with -Wall -Werror,
I can't even configure properly; one gets the errors
configure: libxrandr development files not found, XRandr won't be supported.
configure: libxinerama development files not found, multi-monitor
setups won't be supported.
configure: WARNING: Old Mesa headers detected. Consider upgrading your
Mesa libraries.
OpenGL and Direct3D won't be supported.
And if one blows past those, "make depend" fails. In fact, everything
fails pretty spectacularly.
We should probably have a look at -Wall errors in more detail and breadth
before we assume that we're ok.
- Dan
