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
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
P.S. I won't be available from the 15th for about a week or so.
So, if you have any questions, I'm afraid you might have to be patient.
Hope this is of interest to someone
-Rob.
******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
i. Windows can detect an eraser, and sends specific messages.
(I'm sure I've seen this, but can't work out where!)
ii. Only works if tablet and cursors are named correctly.
(Probably linked to wacom tablets only).
iii. I've missed something
3. Requirements of other applications
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s
/ZKMUGwQOuw/SIIbOkIUbd0=
=R4M7
-----END PGP SIGNATURE-----
Hi,
Now that we're facing Direct3D 9 feature completion soon - VTF support coming
in from Henri, High order patches and thread safety from me - the d3d work
will change a bit soon. Instead of adding new features we'll debug games and
improve performance. It would be good if we had some automated testing
framework to support the process :-)
Unfortunately this isn't easy. Games do not render exactly, so verifying that
a game doesn't show any visual regressions automatically may be more effort
than reward. Here I think we'll have to rely on users testing the games
regularly and testing regressions.
I am more concerned about the performance thing. It is very easy to make some
performance improvement that does more harm than good. Also benchmarks take
quite some time and are affected by many external parameters. So I'd like
some automated and controlled performance testing environment. Instead of
building one from scratch it would be cool if we could reuse existing
software.
cxtest comes to my mind(www.cxtest.org). It is a test suit built by
codeweavers for running regression tests on Windows apps. It can remote
control applications using keyboard input and compares screenshots to
reference ones. It could be used to start benchmarks automatically. A plus
here is that some machines run nightly tests. However, those are VMs, so no
3D acceleration. A problem is also reading back the results. Does anyone know
some applications for doing that? Windows or Linux apps, commercial or open
source ones(prefered, though).
Then we need benchmarking apps. Here regular Windows benchmarks come to my
mind(3DMarkXYZW), games with benchmark facilities(hl2, ut, ...). We can
record tests, get a reference performance counter from windows and run
nightly tests(or manually started tests). A problem we're facing is reading
back the results. Taking screenshots and running OCR on them is error prone,
we need a way to get the numbers from the benchmarks, not an image of the
numbers.
Now we need a concrete collection of benchmarks. A mixture of popular
Benchmarks like 3DMark would be good, and some more cientific benchmarks. So
far I have:
3DMark:
Popular benchmark for testing the overall performance, doesn't give very
detailed results though.
Controlling: Standard windows controls, keyboard events should do the job
Result readback: Can write results to a file, but must take care about the
licensing. Not everything is free, most likely a license is needed.
Half-Life 2:
Nice facility of recordable timedemos. Can record average game demos, but also
demos which stress specific features.
Controlling: Command line parameters
Result readback: Can be asked to copy the console into the clipboard
UT2004:
Popular engine. Has a Linux port, but many mods only ship the d3d renderer.
Controlling: Unknown
Result readback: unknown.
DirectX sdk demos, nvidia / ati demos:
Stress specific rendering features. Good for testing performance(with vsync
removed), or a bad idea?
Controlling, Readback: Source code is available and can be modified. License,
especially possible benchmark clauses?
Other suggestions?
Another nice-to-have thing would be a game independent profiling method,
simmilar to the +fps debug channel, just more detailed. Some games do not
have built-in benchmarking, it would still be nice to use them. That means
facing some new problems? How to tell loading from in-game rendering? How to
remove control those games in a repeatable way, especially if there are some
random elements in the game? More detailed data from wined3d could also be
used to draw nice graphs for other benchmarks :-)
We'll need some hardware diversity too. It would be nice if the tests worked
on Linux and MacOS, and a variety of hardware was used. I want at least
nvidia, ati and intel gpu's, older and newer ones. I could also revive my ATI
mach64 :-)
Any other comments or suggestions? I think once I'm done with the current exam
season and my patch backlog is in I will retire from direct wined3d
development for a few days / weeks to set up a testing environment, then
start fixing games.
Hey everyone,
I have been planning to do some work on wine for a while now, but
after I started working I got myself a new programming job.
I'm worried about the copyright of any external work I do, so I need a
little advice.
What do I need from my employer to clear me to work on wine?
Is something verbal ok, or should I get it in writing?
--
Nathan
>file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
>file: 373 tests executed (0 marked as todo, 0 failures), 0 skipped.
These lines are displayed via printf (include/wine/test.h: 391).
> msvcrt:file done (0)
And this via xprintf (programs/winetest/main.c: 420), which is wrapper over
write syscall.
If you need these line be output in appropriate way, try to add fflush(stdout)
in proper place (into run_test function in include/wine/test.h, I suppose).
--
Kirill
Peter Dons Tychsen wrote:
> OK. Please review this diff:
>
> I will re-submit it if you like it.
>
> /Pedro
Alright looks good now (you might want to remove the extra white space your
patch adds - git complains about those). Just left to make the same change
to the other joystick interface :)
BTW don't forget to cc: the wine-devel list when you replying.
Vitaliy.