Wine Front-End development

[Kuba Ober]

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 
support.

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 
things implies. 

Cheers, Kuba