Hello all,
First of all, I'll introduce myself: I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS university in Brazil. I have worked with Wine in GSoC 2011 (http://www.google-melange.com/gsoc/project/google/gsoc2011/lfzawacki/8001) and pretty much enjoyed the experience.
I'd like to work again with Wine for this year's GSoC and with this email discuss some possible projects.
*Joystick Configuration Tool*
This seems like a natural project for me to work since I'm very familiar with DirectInput and have access to some josysticks, including force feedback. I'm not sure about what "Support system joystick calibration" is though. Is it related to bug 24235 ?
*Scons Wine*
I think this could turn out to be very worthwhile project, but there's little documentation about it. To make Scons aware of Winelib would it be enough to create an environment that uses the winelib compilers, libs and includes? Then it would be a question of programatically generating the build script, much like winemaker does for the makefile.
I've also been looking at Winemaker and trying to convert some visual studio projects from random google code repositories with moderate success. As a part of this project I could test it with numerous samples, e.g Nehe tutorials (http://nehe.gamedev.net/), and with assorted open source projects targeting windows, and make these just work with Winemaker.
*Winetricks*
Other ideas fall in winetricks territory so I don't know if they constitute a valid Wine GSoC project, but they're:
* Regression Testing GUI. Help a user download the repository, compile wine and run assisted or automated bisections. * Compatibility and exchange of installation recipes with other frontends like PlayOnLinux * Winetricks and AppDB integration. A way to mirror in AppDB the dependencies and workarounds employed by winetricks recipes.
I wait for feedback. I'm also available at IRC if someone wants to discuss this in more depth.
Am 19.03.2012 06:22, schrieb Lucas Zawacki:
*Scons Wine*
I think this could turn out to be very worthwhile project, but there's little documentation about it. To make Scons aware of Winelib would it be enough to create an environment that uses the winelib compilers, libs and includes? Then it would be a question of programatically generating the build script, much like winemaker does for the makefile.
I'm not sure if that's outdated. I mean how many people are converting Applications to winelib, how many of them want to use scons for that, and how many of them can't do it theirselfs? But maybe i'm wrong...
I've also been looking at Winemaker and trying to convert some visual studio projects from random google code repositories with moderate success. As a part of this project I could test it with numerous samples, e.g Nehe tutorials (http://nehe.gamedev.net/), and with assorted open source projects targeting windows, and make these just work with Winemaker.
Which projects were that, or what problems did you have? Often there are small problems which are easy to fix by hand, but would need special handling in winemaker.
I'm not sure if that's outdated. I mean how many people are converting Applications to winelib, how many of them want to use scons for that, and how many of them can't do it theirselfs? But maybe i'm wrong...
Actually I think you're right, I don't know how much interest is there for this project or why it is about scons. Maybe the person responsible for this suggestion could provide more context?
Which projects were that, or what problems did you have? Often there are small problems which are easy to fix by hand, but would need special handling in winemaker.
I tried several projects with labels 'CPlusPlus' and 'VisualStudio' in google code, some notable trouble I had was:
* Compile errors related to c++ headers as it seems to be using my linux headers and I don't know if that's correct (or a problem on my side). * wrc compile errors, that were due to encoding mismatches. Solved with iconv * undefined reference to WinMain (tried variations of -mwindows and -mconsole with no success) * winemaker choking on .sln and .vcxproj files (perl uninitialized strings)
I can file bugs for these if you want.
On Mon, Mar 19, 2012 at 00:22, Lucas Zawacki lfzawacki@gmail.com wrote:
Hello all,
First of all, I'll introduce myself: I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS university in Brazil. I have worked with Wine in GSoC 2011 (http://www.google-melange.com/gsoc/project/google/gsoc2011/lfzawacki/8001) and pretty much enjoyed the experience.
I'd like to work again with Wine for this year's GSoC and with this email discuss some possible projects.
*Joystick Configuration Tool*
This seems like a natural project for me to work since I'm very familiar with DirectInput and have access to some josysticks, including force feedback. I'm not sure about what "Support system joystick calibration" is though. Is it related to bug 24235 ?
*Scons Wine*
I think this could turn out to be very worthwhile project, but there's little documentation about it. To make Scons aware of Winelib would it be enough to create an environment that uses the winelib compilers, libs and includes? Then it would be a question of programatically generating the build script, much like winemaker does for the makefile.
I've also been looking at Winemaker and trying to convert some visual studio projects from random google code repositories with moderate success. As a part of this project I could test it with numerous samples, e.g Nehe tutorials (http://nehe.gamedev.net/), and with assorted open source projects targeting windows, and make these just work with Winemaker.
*Winetricks*
Other ideas fall in winetricks territory so I don't know if they constitute a valid Wine GSoC project, but they're:
- Regression Testing GUI. Help a user download the repository, compile
wine and run assisted or automated bisections.
IMHO, this effort is better spent elsewhere. It's a cool idea, but GUI's are notoriously difficult to automate in testing. To make it worse, you have to wait for the application to install/test, which is a large time/space investment. It's also unreliable. The time is better spent boiling down failures into isolated testcases and getting those testcases into Wine's, where they are tested daily, on a broad range of systems, with thousands of tests in under 10 minutes.
- Compatibility and exchange of installation recipes with other
frontends like PlayOnLinux
- Winetricks and AppDB integration. A way to mirror in AppDB the
dependencies and workarounds employed by winetricks recipes.
Winetricks is not a mentoring organization for Google Summer of Code. That said, it theoretically could be under Wine's umbrella (as I did with Appinstall, which did gui testing in 2009), but I think most would rather see work done on Wine directly.
- Compatibility and exchange of installation recipes with other
frontends like PlayOnLinux
- Winetricks and AppDB integration. A way to mirror in AppDB the
dependencies and workarounds employed by winetricks recipes.
Winetricks is not a mentoring organization for Google Summer of Code. That said, it theoretically could be under Wine's umbrella (as I did with Appinstall, which did gui testing in 2009), but I think most would rather see work done on Wine directly.
Is this the general feeling of the list, e.g. would it be a waste of time to craft a proposal involving winetricks?
On 03/18/2012 11:22 PM, Lucas Zawacki wrote:
Hello all,
*Joystick Configuration Tool*
This seems like a natural project for me to work since I'm very familiar with DirectInput and have access to some josysticks, including force feedback. I'm not sure about what "Support system joystick calibration" is though. Is it related to bug 24235 ?
You got it! That's the bug I was talking about.
There are other smaller things in dinput to fix of course: - Fix forcefeedback (multiple bugs). - Create helper thread on demand not at the same time as DInput (bug 21403).
-Vitaliy
About the joystick configuration tool proposal. My plans are:
* Start development as a standalone program, and then include it in the control panel * Enumerate all the joysticks with dinput * Simple windows GUI. Prototypes are here http://dl.dropbox.com/u/2701879/wiki/gsoc/dialog1.png (main screen) and here http://dl.dropbox.com/u/2701879/wiki/gsoc/dialog2.png (visualization/calibration). I don't know how I could draw the axis and buttons to give the visual feedback, I guess it's something to do with GDI? Or maybe embbeded pictures in the dialog? * Show supported force feedback devices and provide some controls for testing/setting it * Write settings to registry after user confirms calibration. * jscal stores the calibration settings in a file so it's probably enough to have an "Import calibration" option and read from this file. * Use the linux sysfs interfaces to get vid/pid and automatically detect "duplicate" drivers (this is extra but I think could be useful)
Also I've yet to try to configure force feedback on linux with my joysticks so I can take a look at the ff bugs.
-
André Hentschel -
Austin English -
Lucas Zawacki -
Vitaliy