On Saturday 15 April 2006 10:48, n0dalus wrote:
On 4/15/06, Karl Lattimer karl@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