Wine Front-End development

[Karl Lattimer]

> When winecfg was originally proposed I wanted to do it in GTK, and whinged
> loudly when Alexandre said it had to be done using Win32 to keep
> dependencies small. I guess his reasoning hasn't changed, so, for GUIs
> you'd have to do it using Win32 and C :(
> 
> Of course if you aren't bothered about it becoming official you can do it
> however you like ...
> 

If this http://wiki.winehq.org/ThemingSupport is to become a part of
wine (RE: GTK support for themes), I don't see what the problem with
using GTK is. GTK is available on all distributions that I know of, and
definitely all popular distributions. winetools already uses the legacy
GTK+-1.2, also I see that there are advantages of having a GUI for
installing/uninstalling applications separate from wine and win32
provides certain advantages i.e. providing process management, i.e.
killing wineservers when they hang without reason. The main advantage I
see is that the code is far simpler than writing it in C, of course, I'm
not particularly bothered whether my application gets included in wine
distributions, as long as the AppDB can provide support for the features
I want, if the AppDB integration features are dealt with with respect to
my app, then it is possible that someone else will develop a win32 C
application which uses the same features. 

On the subject of dependencies, if the application is not required by
the wine core then surely dependencies are irrelevant, and the shortest
development path (python gtk, glade imho) should be considered as it
means the application will be available much faster than developing it
in C which could take far longer to develop.

Another advantage of python is that you can also run windows
applications in python (which of course would require the windows python
binary) but if someone wanted to create a Qt or win32 UI for wine doors
then I'd happily support them in this endeavor. 

Maybe now we can think more about in general terms what is required for
this kind of user interface, I would like my application to become the
benchmark for this type of tool I have many features already working and
lots of ideas of my own, more community involvement would be appreciated
but at the speed I am writing this I imagine it could be ready for
winetools replacement very soon. 

Your remarks on perl and bash usage seem to me a step backward, perl is
terrible at a hell of a lot of things (I should know, using perl for
many many years and still stabbing myself in the hand when working with
it at times to relieve the pain in my brain), bash is currently used for
winetools and is a nonsense mess of code because quite simply bash
wasn't supposed to do things like that. I employ bash where necessary
and will only use it where appropriate, I believe that over complication
of what is essentially a very simple concept by going down a route of
bad languages and restrictive dependencies inhibits development by
making it difficult for developers to dive in and start work on
something. 

If I say it _must_ be written in C win32, perl or bash then immediately
developers will consider the issues, ok perl could do a lot of it easily
but there are some problems in other areas, bash would be a large amount
of work and win32 C would mean lots and lots of code auditing,
re-factoring and bug fixing, probably resulting in a 5 year development
process to get the application to a point where it is in regular use.
These issues may serve to deter a developer from taking on the project
with a view to "I'm not getting my hands on that train wreck".

There is also the subject of desktop integration, I use gnome, lots of
other people do, GTK fits together nicely and would prevent deviation
from the desktop model, if wine is to use GTK all the better, but this
in itself means that the GTK requirement would exist and various other
requirements around this wouldn't be a great issue. With the current
complexity of linux desktops I believe that restricting the language and
dependencies is silly and uncalled for. Maybe Alexandre's views may have
changed this far on?

K,