Wine Front-End development
kuba at mareimbrium.org
Sat Apr 15 13:57:09 CDT 2006
On Saturday 15 April 2006 10:48, n0dalus wrote:
> On 4/15/06, Karl Lattimer <karl at qdh.org.uk> wrote:
> > 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
> Just because GTK support may be added for themes, doesn't mean that
> wine's tools should be GTK specific. The idea is that you write it
> using Win32 gui controls and then if the user's computer has GTK then
> it gets themed automatically. For this tool to have the best
> compatibility it shouldn't require gtk to be compiled in.
[. . .]
> 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.
[. . .]
I think that this discussion has really degenerated into a long advocacy
*against* everything that open source is good for.
Alexandre's take seems to be that one should simply ignore what's out there
and program like in Win 2.x days. In the meantime, software has moved forward
quite a bit. That's what I make out of it.
If fontforge"made a mess", that's not just because it's an extra dependency.
It's because someone, instead of making the right choice and shipping
whatever files fontforge is building, shipped only the sources. The right
thing to do would be to ship the prebuilt stuff at least until "right"
version of fontforge reaches mainstream. Now we're trying to waste some more
time by ripping fontforge and creating sfd2ttf (?). That's lunacy! Just ship
the damn prebuilt files until the time is ripe to take them out. Of course
the sources should be kept there all the time as well.
Now to my main point: we have to embrace and reuse whatever is out there in
the OSS world. That's the only way to go forward. Advocating "sticking to C"
just because there are various distros out there and some of them might not
have what we need is crazy. That's akin to long and incandescent discussions
people have had on various project lists when time came to drop gcc 2.95/2.96
As far as I can tell, writing any GUI for wine, whether it be winecfg-like, or
winetools-like, or both things at once, is just a big waste if done in C. I'm
familiar with Qt and I can estimate that doing it in C+Win32 API would make
the code at least 5x bigger than if using Qt, for the same functionality. And
it would have way more bugs -- we don't have TrollTech doing our 80% of our
debugging anymore. That's a big difference. Most distros out there have for
example a decent version of Qt (3.x), and I wouldn't for example mind wine's
GUI tool depending on it. Mind you, not wine as a whole, just the GUI tool.
Configure can simply disable building of the tool if say Qt is not present.
Similar argument goes for gtk/glib -- I'm just not mentioning those because I
know little about them.
The whole point about using say Python is yes, Python is written in C, but
when using Python you don't have to rewrite parts of what Python developers
already wrote and debugged for you. Same thing with C++ and Qt: you don't
have to reimplement containers and a whole big brouhaha of things that
ordinarily make C++ and Qt apps tick.
One would think that since Lisp has been around for so long now, everyone
would realize that the old adage "every complex app. has a buggy, poorly
documented implementation of half of common Lisp" is more universally
applicable. I wouldn't be very wrong saying that "every complex C application
has a buggy, poorly documented implementation of most of C++ standard
library". And so on. I believe that people who can reasonably well implement
the (otherwise standard) container stuff etc. in C, during development of
their main project, will be even more productive when embracing C++ standard
library. Same applies at the GUI level: if you're such a pro hacker that you
can effectively write C/win32 applications "in your sleep", you'd be even
more productive when embracing say Qt or gtk.
Doing it in "plain C and Win32" implies reimplementing all this otherwise
irrelevant stuff. It shifts focus from the goal to the means, by having to
develop your own tools. E.g. C++ library is just a tool (means) that helps
you to write your application (the goal). I just don't get the argument that
developing a contemporary GUI application should be done such that all the
tools have to be redone from scratch, as that's what Alexandre's way of doing
More information about the wine-devel