I was wondering...
If somebody were writing a Wine GUI front-end for uses with the hope that it might possibly make it into the Wine distribution one day, what language(s) and toolkit(s) would be acceptable to the Wine developers for that person to use? Or, of course, do you not forsee that happening?
Rich
Rich Gilson wrote:
If somebody were writing a Wine GUI front-end for uses with the hope that it might possibly make it into the Wine distribution one day, what language(s) and toolkit(s) would be acceptable to the Wine developers for that person to use? Or, of course, do you not forsee that happening?
It's up to Alexandre whether it goes in or not.
If you were to write such a thing, stick to C, Perl (standard kit only) and shell script.
Perhaps extend winecfg to have an "Install" panel that downloaded a list of applications known to work with Wine that could also be freely downloaded?
Mike
On Sat, 2006-04-15 at 03:02 -0400, Rich Gilson wrote:
I was wondering...
If somebody were writing a Wine GUI front-end for uses with the hope that it might possibly make it into the Wine distribution one day, what language(s) and toolkit(s) would be acceptable to the Wine developers for that person to use? Or, of course, do you not forsee that happening?
I'm doing it in python
http://www.qdh.org.uk/wordpress/?cat=6
K,
On Sat, 15 Apr 2006 03:02:22 -0400, Rich Gilson wrote:
If somebody were writing a Wine GUI front-end for uses with the hope that it might possibly make it into the Wine distribution one day, what language(s) and toolkit(s) would be acceptable to the Wine developers for that person to use?
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 ...
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,
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.
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.
Most development time can be cut by thinking the implementation through properly at the beginning. A good C programmer should be able to write a maintainable application in a similar amount of time to a good python programmer. (Note however, that being a good C programmer can be harder than being a good python programmer.)
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.
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?
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.
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.
My two cents, n0dalus.
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,
On Sat, 2006-04-15 at 16:17 +0100, Karl Lattimer wrote:
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)
For what is worth, I personally think you've made the best choice of tools for this project. The problem with the "least common denominator" approaches is that you get a sub-par result. Don't let the rhetoric slow you down.
Python is certainly not a problem dependency, any more then Perl is. If you feel comfortable with it, use it. There are way more desktop apps written in Python than in Perl, that I know of and that matter. Red Hat uses it for most of the stuff they produce, and (like it or not) they are the 800-pounds gorilla in Linux-land.
As for the toolkit, you have a choice of 3: Gtk+, Qt, Win32. Problem with Win32 is that you get an app that looks strange in both GNOME and KDE -- it pleases nobody. Kinda like a Java Swing app. Pick one of GTK+ or QT, and at least make 1/2 of the people happy, the rest will be as unhappy as in the case you would have picked Win32 anyway. GTK+ is a fine choice, if you like it, go for it.
On Sat, 2006-04-15 at 19:54 -0400, Dimi Paun wrote:
On Sat, 2006-04-15 at 16:17 +0100, Karl Lattimer wrote:
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)
For what is worth, I personally think you've made the best choice of tools for this project. The problem with the "least common denominator" approaches is that you get a sub-par result. Don't let the rhetoric slow you down.
Thanks for your support ;)
As for the toolkit, you have a choice of 3: Gtk+, Qt, Win32. Problem with Win32 is that you get an app that looks strange in both GNOME and KDE
The great thing is almost all of the back end stuff (except progress bar updates in the queue runner) are completely toolkit independent, if someone wants to write a win32 UI or a Qt UI and integrate it well into the interface, supply patches for testing then I'll happily accept them if they don't break GTK.
I've even thought of a way of making the progress bar update code work across all UI's so there is easily scope for achieving this.
Tomorrow I create a 'standard' for application packs, this is the archive of resources (scripts, reg files, icons, xml etc...) which make it easy to install windows applications and have them integrate nicely with gnome/kde.
K,
Hi,
On Sat, Apr 15, 2006 at 07:54:12PM -0400, Dimi Paun wrote:
On Sat, 2006-04-15 at 16:17 +0100, Karl Lattimer wrote:
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)
For what is worth, I personally think you've made the best choice of tools for this project. The problem with the "least common denominator" approaches is that you get a sub-par result. Don't let the rhetoric slow you down.
I'm also voting for not going with a C-only version here. It's important to stand on the shoulder of giants and use what's there already. Using C code for a frontend with complex interactions with various subsystems where you'd have to re-code several parts on your own again just doesn't sound right. One should go with a *useful* GUI toolkit and decide this based on its distribution prevalence and its features. One could even see this as a positive vote *for* a certain toolkit, and given some time and a wise choice it will turn out that more and more applications chose the same toolkit thus making it a pretty permanent feature of any Linux distribution. That's just the natural way of OSS development evolution: stuff that's good will be re-used over and over again, and stuff that's not good will die very quickly (incidentally thus punishing those projects that didn't choose a GUI toolkit wisely), and stuff that's worse than a newcomer will get deprecated eventually once the newcomer is fully established.
All this means that it's most likely a bad idea to go back to the 80s and code a complex GUI app which has to interface to all sorts of standard Linux desktop services(!) in C again, unless there's a complete and rich interface to all required services available, which I doubt.
Andreas Mohr
Karl Lattimer wrote:
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,
Isn't this how we are running into the font problems by requiring fontforge? Just because it is available and a user can and wants to install wine doesnt mean that they have all the required dependencies.
Just my 2c
Tom
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
[. . .]
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.
snip
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.
here! here!
Thank you!
Shifting the "goal to the means" is what I meant by;
'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".'
It seems lunacy to ignore tools which are available in favor of a non existent accepted "Alexandre doesn't want it" rhetoric, I always thought open source was about community, and discussing the advantages of one language over another is irrelevant when it comes down to the fact in about 2 weekends worth of actual work I have a nice looking well rounded app, which is well on its way to the full functionality _I_ want out of it, regardless of any other users. I am of course releasing it GNU GPL so others have the benefit of this. I don't know any C win32 programmers which could do what I've done so far in ~380 lines of python.
Lets remember that open source is about, sharing and freedom, sharing ideas as well as software, and giving people freedom to put their own contributions in, and use software how they like. It is not about restricting what functionality is available to users by restricting the programmers. Remember please that the dependencies of pygtk/pyglade do not influence the core of wine, they aren't important to the internals and have no affect on it whatsoever. In this respect it is a completely different animal to fontforge.
I would like wine doors to be included in the wine distribution, but that is not to say I think its necessary. Think of, file-roller. This tool doesn't come bundled with tar, rar, zip, bzip and gzip. It is merely a user interface which uses these tools.
As far as I'm concerned the only thing I want out of the wine community is a series of enhancements and changes to the AppDB in order to provide the functionality I need for my application. Once I have some semblance of an application ready for distribution I will then download the source to the AppDB make the changes myself and hopefully get those changes accepted into CVS and eventually onto the site. However if this fails to occur then I will fund out of my own pocket a server and the other resources necessary to run this service in the hopes that wine users will contribute financially to ensure its survival.
K,
Kuba Ober wrote:
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.
So if a version of gcc got released that didn't produce correct libraries then we should add all of the .so files to the Wine tree? What a good idea!
Of course, the fix is to try to add a configure check for the incorrect ttf files that fontforge produces, or otherwise a version check, as has already been discussed.
On Sat, 15 Apr 2006 22:51:13 +0100, Robert Shearman wrote:
So if a version of gcc got released that didn't produce correct libraries then we should add all of the .so files to the Wine tree? What a good idea!
That ignores the costs/benefits of each individual case. I think it's completely sane to ship TTF files in the source/git trees. They're small, annoying to generate (because many people don't have FontForge), so the cost is low and the benefit is high.
Alexandre already applies the same reasoning to shipping the built configure script.
Certainly adding yet more code we have to maintain to the tree doesn't make much sense.
thanks -mike
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.
So if a version of gcc got released that didn't produce correct libraries then we should add all of the .so files to the Wine tree? What a good idea!
I think you carried the analogy a bit too far: fontforge is a relatively obscure tool, compared to gcc.
Of course, the fix is to try to add a configure check for the incorrect ttf files that fontforge produces, or otherwise a version check, as has already been discussed.
Well, if someone wants to do more work for the sake of argument, then I guess we live in a free world. But still, the fonts are such a fringe part of wine that I just can't see any extra work to be worth it. For a while one can just consider fontforge to be a "proprietary" tool, and wine would just ship the sources and resulting fonts. It's just a matter of being practical.
Configure checks methinks are good for stuff that actually needs to be rebuilt. Do fonts really need to be rebuilt on each and every system? What's the point? Do they change that often, and does every platform have its own ttf format?! It's not the same as C sources that people compile on different platforms, with differing compile options, with different (and often incompatible) compilers and ABIs, and so on.
Cheers, Kuba
"Kuba Ober" kuba@mareimbrium.org wrote:
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.
So if a version of gcc got released that didn't produce correct libraries then we should add all of the .so files to the Wine tree? What a good idea!
I think you carried the analogy a bit too far: fontforge is a relatively obscure tool, compared to gcc.
Of course, the fix is to try to add a configure check for the incorrect ttf files that fontforge produces, or otherwise a version check, as has already been discussed.
Well, if someone wants to do more work for the sake of argument, then I guess we live in a free world. But still, the fonts are such a fringe part of wine that I just can't see any extra work to be worth it. For a while one can just consider fontforge to be a "proprietary" tool, and wine would just ship the sources and resulting fonts. It's just a matter of being practical.
Looks like you are not aware how much pain gcc bugs (like a strength-reduce bug) have caused to Wine. That just again suggests to people to use pre-built Wine packages from a good packager who knows what he does, or just go to wine-users.
Well, if someone wants to do more work for the sake of argument, then I guess we live in a free world. But still, the fonts are such a fringe part of wine that I just can't see any extra work to be worth it. For a while one can just consider fontforge to be a "proprietary" tool, and wine would just ship the sources and resulting fonts. It's just a matter of being practical.
Looks like you are not aware how much pain gcc bugs (like a strength-reduce
We're talking about a couple of fonts and a relatively obscure tool, not about the compiler which compiles the whole wine tree. Comparing fontforge to gcc in the context of this discussion is a long shot to say the least. I'm not trying to say that gcc had no bugs, etc. I'm just arguing for including those silly ttfs in the source distibution, that's all.
Cheers, Kuba
Kuba Ober wrote:
trying to say that gcc had no bugs, etc. I'm just arguing for including those silly ttfs in the source distibution, that's all.
TTF files are binaries, and the current policy is that there should be no binaries in the source tree. (That's why it's called "The Wine Source" and not "a Wine binary".)
configure is a generated file, but not a binary.
Still waiting for sfd2ttf... :)
Mike
On Saturday 15 April 2006 14:57, Kuba Ober wrote:
On Saturday 15 April 2006 10:48, n0dalus wrote: 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.
I must say, the turn this conversation has taken is interesting. In response to what was written above, it does seem to me a curious precedent Alexandre has set. After all, wasn't Wine developed to allow people to get AWAY from Windows? Yet, when we go to make a GUI toolkit to make it accessible to the masses, what are we told? Why, write it for Windows, of course.
I just find it quite.....
amusing; yes, I think that word fits nicely here.
Rich
On 4/16/06, Rich Gilson signman359@gmail.com wrote:
I must say, the turn this conversation has taken is interesting. In response to what was written above, it does seem to me a curious precedent Alexandre has set. After all, wasn't Wine developed to allow people to get AWAY from Windows? Yet, when we go to make a GUI toolkit to make it accessible to the masses, what are we told? Why, write it for Windows, of course.
1. You never mentioned what you want this "front-end" to do. I think that's pretty important to whatever you're talking about. Seems to me it might fit in with winecfg or something else that already exists.
2. Did you read the thread(s) about rewriting WineTools that occurred over the past few months? Are you reinventing that wheel?
3. Putting a GUI toolkit dependency on Wine will never make everyone happy. Even worse, you can't even make a majority of people happy. If you assume GNOME or KDE are available, you're assuming you're running on Linux.
-Brian
Brian Vincent wrote:
On 4/16/06, *Rich Gilson* <signman359@gmail.com mailto:signman359@gmail.com> wrote:
I must say, the turn this conversation has taken is interesting. In response to what was written above, it does seem to me a curious precedent Alexandre has set. After all, wasn't Wine developed to allow people to get AWAY from Windows? Yet, when we go to make a GUI toolkit to make it accessible to the masses, what are we told? Why, write it for Windows, of course.
- You never mentioned what you want this "front-end" to do. I think
that's pretty important to whatever you're talking about. Seems to me it might fit in with winecfg or something else that already exists.
- Did you read the thread(s) about rewriting WineTools that occurred
over the past few months? Are you reinventing that wheel?
- Putting a GUI toolkit dependency on Wine will never make everyone
happy. Even worse, you can't even make a majority of people happy. If you assume GNOME or KDE are available, you're assuming you're running on Linux.
-Brian
Why not use Motif/Lesstif? Sure, it's ugly, but I like it, it's available with most major distributions, exists on non-Linux targets, and a precompiled binary of OpenMotif is provided with Sun Java 1.5/Linux
Then there's the question "OpenMotif or Lesstif, hmm...", which is answered by ./configure, and I say defult to Lesstif on Linux binaries, Motif on solaris.
- You never mentioned what you want this "front-end" to do. I think
that's pretty important to whatever you're talking about. Seems to me it might fit in with winecfg or something else that already exists.
- Did you read the thread(s) about rewriting WineTools that occurred
over the past few months? Are you reinventing that wheel?
- Putting a GUI toolkit dependency on Wine will never make everyone
happy. Even worse, you can't even make a majority of people happy. If you assume GNOME or KDE are available, you're assuming you're running on Linux.
That dependency is just for some sort of a configuration/helper tool. It should not be a key component, i.e. sane defaults should be enough to get it up and running. Besides, the configuration tool can have graphical and text mode front ends, compiled separately. Many RedHat/Fedora configuration tools are done that way.
Why not use Motif/Lesstif? Sure, it's ugly, but I like it, it's available with most major distributions, exists on non-Linux targets, and a precompiled binary of OpenMotif is provided with Sun Java 1.5/Linux
Then there's the question "OpenMotif or Lesstif, hmm...", which is answered by ./configure, and I say defult to Lesstif on Linux binaries, Motif on solaris.
I'd still say that Qt is easiest to use. Trolltech went as far as having the open source Qt/Windows installer optionally download and install the MinGW compiler, and then run the build process for you. Of course, since it's GPL, anyone is free to post the binaries as well.
Besides, who said that the configuration tool has be compiled for Windows?! It only needs to be run in whatever environment wine is running in. That means unixen for now, and I bet that anything that wine runs on, Qt runs on too.
Cheers, Kuba
Karl Lattimer wrote:
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?
I doubt that Alexandre's views have changed. Adding dependencies is bad, as you can see with the FontForge mess.
Mike
On Sun, 2006-04-16 at 00:46 +0900, Mike McCormack wrote:
Karl Lattimer wrote:
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?
I doubt that Alexandre's views have changed. Adding dependencies is bad, as you can see with the FontForge mess.
Yeah I spotted that, but I think thats a different thing entirely. Point taken but still I believe this is different, wine doors is a stand alone application, when I come to packaging the first RPMS i will depend on wine pygtk and pygtk-glade and nothing else, to me that doesn't seem unreasonable, I use fedora which heavily depends on pygtk anyway and I think pygtk-glade is useful and should be used where possible for small gtk apps.
K,
-
Andreas Mohr -
Brian Vincent -
Dimi Paun -
Dmitry Timoshkov -
Karl Lattimer -
Kuba Ober -
Mike Hearn -
Mike McCormack -
n0dalus -
Rich Gilson -
Robert Shearman -
Segin -
Tom Spear (Dustin Booker, Dustin Navea)