Wine Front-End development

[Karl Lattimer]

> Note however, that being a good C programmer
> can be harder than being a good python programmer.

Oh how very true ;), but doesn't this statement in itself answer the
question. python == easy to write, easy to maintain, fun and featureful.

> 
> I see many python developers get into the habit of writing short-term
> maintainable code and replacing it often long-term. I think this is
> just because developers get used to python being so simple to rewrite
> and saying, 'I can fix it later.' This is both a good thing and a bad
> thing.

Thinking through an implementation doesn't just apply to C, I have put a
lot of thought into wine doors, considered many features and would
prefer not to rewrite it in the long term. (Although I did rewrite the
GUI code and introduce a queue iterator this weekend, glade rocks ;)) 

> 
> > 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".
> 
> That's just not true at all. While I see python programmers regularly
> regurgitate this whole 'C is unmaintainable and takes years to write'
> thing, have you considered what language python is written in? And is
> it a buggy train wreck? Those new modules you use after a python
> upgrade, did they take 5 years to write?

This is a bit out of analogy, I know that C can be written in
maintainable and clear and clean, however how often is this evident, how
often are memory leaks an issue in C/C++ versus python, but when you're
talking about downloading files, parsing XML, drawing a GUI, interfacing
with the unix system, managing an install queue and the various other
tasks which are important to the success of such an application are
difficult to achieve in C using a prototype -> develop -> test -> deploy
cycle, admittedly there may be some use of win32 applications to
interface with the wine environment but I think this is something that
for the most part can already be done with regedit, and there is
possibly a requirement for other small applications.

And how many dependent libraries would be required for XML/HTTP in C?

The "train wreck" statement is meant to make you consider that many
developers, myself included would rather not do this in C because it
could very easily end up as a popular Italian dish version of an
application.

A C version of this screams complexity, possibly one reason winetools is
written in bash. You must understand that I'm not saying C is a bad
language, I'm not saying that it is completely unmaintainable, but when
the simplicity vs. complexity issue is considered python wins out. I'm
new to python, after many years writing C/C++/php/perl and various other
bits n bobs. I see it as ideal for this small simple app, I can have a
functional application out much sooner than if I was writing it alone in
C.

> 
> Everybody knows a badly made win32 C program is possibly the worst
> possible thing imaginable, but there are many examples where well
> written, maintainable and relatively bug-free applications were
> written quite quickly in C.

Agreed, however there is always more code and more ongoing development
required to maintain a C application over a python app, this is because
C is a more in depth language. I write C too btw, and I have done GTK in
C, enjoyed it and found it easy to do, however there are some complex
issues with for instance dealing with arrays and linked lists in some
instances which are far easier in python/perl/php/probably any language
beginning with p, except prolog.

> 
> I don't have anything against python, and it is a great language to
> use, but that doesn't mean it's the best possible language to use for
> every conceivable project. Wine is supposed to be a way to run Win32
> programs on UNIX, and not every unix flavour comes with GTK and
> python. I think people would say Wine has enough run-time
> dependencies, and there's no strong reason why another one can't be
> avoided here.

Python and GTK are available for every UNIX flavour, even OSX,
regardless of whether it ships with it. Do you know if SCO currently
ships with wine? does it ship with python?

The point here is that if someone is willing to install wine, chances
are they will have all the libraries required for it on a unix system,
and most unix systems come with python and vast majority of them ship
with gtk.

I seriously doubt that as far as users are concerned that dependencies
would be an issue, the user in general just wants something that works,
and they don't care that 4 extra dependancies are required (python, gtk,
pygtk, pygtk-glade)

K,