There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
--- Segin segin2005@gmail.com wrote:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
Dude, you need a bit more constructive in your comments, or you'll be getting a lot of resentment on this list REAL fast.
Just a word of advice, Hiji
M-Halo: Electronic Rock http://www.mhalo.com
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Segin wrote:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
:-) I'd think the more likely conclusion is, winetools really needs some upgrading; (it seems, as long as it's hard for newbies to use wine with commonly-used windows apps, there is a need for some tool to ease installing them such that they can use it - in the current situation there is probably still a need for such tool)
On Tue, Mar 28, 2006 at 11:50:17AM +0200, Joris Huizer wrote:
Segin wrote:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
:-) I'd think the more likely conclusion is, winetools really needs some upgrading; (it seems, as long as it's hard for newbies to use wine with commonly-used windows apps, there is a need for some tool to ease installing them such that they can use it - in the current situation there is probably still a need for such tool)
The original statement is not true, the magic done by winetools is not just in the config file.
Ciao, Marcus
Marcus Meissner wrote:
On Tue, Mar 28, 2006 at 11:50:17AM +0200, Joris Huizer wrote:
Segin wrote:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
:-) I'd think the more likely conclusion is, winetools really needs some upgrading; (it seems, as long as it's hard for newbies to use wine with commonly-used windows apps, there is a need for some tool to ease installing them such that they can use it - in the current situation there is probably still a need for such tool)
The original statement is not true, the magic done by winetools is not just in the config file.
Ciao, Marcus
I know that, which is why i was careful in choosing the word 'most' :-)
* Segin segin2005@gmail.com [27/03/06, 21:32:29]:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
So, I seem to have an IQ of 0, but still I at least seem to be able to use a mail client. Seems like these things really are easy to use these days.
I haven't used winetools in a long while, but back when I did, I could use it to run programs I couldn't run on plain wine myself. If I'm running an older system, I can still use that exact version of wine a winetools, and that program is still running. Could you explain on how that gives it "no point in existing AT ALL, PERIOD"?
Could I assume that the 2.4 Linux Kernel I'm running on my router doesn't have any point of existing, either, just because it's outdated?
Sheesh, if people spent as much time fixing winetools (or wine, for that matter) as they did writing emails about why winetools is bad, this discussion would be utterly useless and without a point AT ALL, PERIOD.
Kai
Kai Blin wrote:
- Segin segin2005@gmail.com [27/03/06, 21:32:29]:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
So, I seem to have an IQ of 0, but still I at least seem to be able to use a mail client. Seems like these things really are easy to use these days.
Erm, no, you have a typing monkey using the mail client for you :-P
I haven't used winetools in a long while, but back when I did, I could use it to run programs I couldn't run on plain wine myself. If I'm running an older system, I can still use that exact version of wine a winetools, and that program is still running. Could you explain on how that gives it "no point in existing AT ALL, PERIOD"?
How? The biggest thing that makes WineTools work is it's ability to set DLLOverrides via a config file that Wine no longer acknoleges, therfore that is gone, and only a few things will work via WineTools, if at all. You can't install IE with WineTools (You can with IEs4Linux, and if you are good enough, you can merge the ies4linux wine setup into the main one without fubaring it. I did. I wouldn't suggest that regular user do this, though.) I digress, and let you know that the programs installable via it's 'database' are outdated, and some have broken URLs!
Could I assume that the 2.4 Linux Kernel I'm running on my router doesn't have any point of existing, either, just because it's outdated?
LOLFAIL. 2.4 is no more "older" than 2.6 in reflect that is it still in active development, and the developers will respond to commentary about it. The same cannot be said about winetools.
Sheesh, if people spent as much time fixing winetools (or wine, for that matter) as they did writing emails about why winetools is bad, this discussion would be utterly useless and without a point AT ALL, PERIOD.
Hey!! That's my line!
Kai
Segin
Am Di, Mär 28, 2006 at 03:21:01 -0500 schrieb Segin:
How? The biggest thing that makes WineTools work is it's ability to set DLLOverrides via a config file that Wine no longer acknoleges, therfore
As this myth is floating around on this list since a long time I have to repeat:
WineTools is not using a deprecated config file. It uses the regular registry way since a long time.
that is gone, and only a few things will work via WineTools, if at all.
So this is also not true.
You can't install IE with WineTools (You can with IEs4Linux, and if you are good enough, you can merge the ies4linux wine setup into the main
If you use IEs4Linux you are actually using the overrides setup of WineTools as they took it from us. This also means that you have the most critisized *=native override included. We are working on this so you will probably have this on IEs4Linux soon after we fixed that.
Regards Joachim von Thadden
Am Mo, Mär 27, 2006 at 09:32:29 -0500 schrieb Segin:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
No need to BELLOW! What you are writing is definitely not true. WineTools does not use a config. It uses the registry. Otherwise it would work like plain Wine as this is ignoring the config. And then there would not be a thread about the DLLOverrides it uses.
Regards Joachim von Thadden
Am Mo, Mär 27, 2006 at 09:32:29 -0500 schrieb Segin:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
IMHO winetools has a still useful feature, and that is it allows users to easily create an initial wine drive, configure and install some applications and otherwise assist in new wine users to get to grips with wine in an easy and I use this term loosely 'user friendly' way.
The problem is that wine tools hasn't adhered to any usability guides and doesn't provide a community orientated feedback, or use the community to gain information about applications. The design of winetools was created initially by frank of frankscorner but he isn't a UI programmer, just an every day hacker. The fact that the whole application is written in bash using Xdialog is a bad start, the code scared me, 3000+ lines of bash.
I'm aiming to change this, I welcome any help especially in python. The main aim of the project I am working on with a couple of new found friends, is to improve accessibility of wine to new linux users to help get people switch from windows to linux. This aim is shared among the wine developers and users I believe.
And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive, and I would rebut that you are in fact the one of lower than average intellect as it requires a certain type of stupidity to insult your peers in general terms.
K,
PS, a little about the projects I have worked on before, I wrote gnome-settings-visualeffects a while back, and got too many flames and crank emails too many eye candy enthusiasts asking dumb questions so eventually i scrapped it. I also worked on the new freevo webserver2 code which was displayed this year at CeBIT. I work on human interfaces every day and I'm looking to bring some gnome HIG zen to winetools, oh and a snappy new name... wine doors ;) (say it quickly three times)
Karl Lattimer wrote:
Am Mo, M�r 27, 2006 at 09:32:29 -0500 schrieb Segin:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
IMHO winetools has a still useful feature, and that is it allows users to easily create an initial wine drive, configure and install some applications and otherwise assist in new wine users to get to grips with wine in an easy and I use this term loosely 'user friendly' way.
The problem is that wine tools hasn't adhered to any usability guides and doesn't provide a community orientated feedback, or use the community to gain information about applications. The design of winetools was created initially by frank of frankscorner but he isn't a UI programmer, just an every day hacker. The fact that the whole application is written in bash using Xdialog is a bad start, the code scared me, 3000+ lines of bash.
I'm aiming to change this, I welcome any help especially in python. The main aim of the project I am working on with a couple of new found friends, is to improve accessibility of wine to new linux users to help get people switch from windows to linux. This aim is shared among the wine developers and users I believe.
And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive, and I would rebut that you are in fact the one of lower than average intellect as it requires a certain type of stupidity to insult your peers in general terms.
K,
PS, a little about the projects I have worked on before, I wrote gnome-settings-visualeffects a while back, and got too many flames and crank emails too many eye candy enthusiasts asking dumb questions so eventually i scrapped it. I also worked on the new freevo webserver2 code which was displayed this year at CeBIT. I work on human interfaces every day and I'm looking to bring some gnome HIG zen to winetools, oh and a snappy new name... wine doors ;) (say it quickly three times)
Python!!?! i almost did a C | N > K (that would be cola, pepsi rather, through nose to keyboard)
ok ok ok ok although i almos-t ruined a perfectly free and good keyboard, i don't like python cause i don't know it, and the learning curve has been... dreadful.
Can't we do this in C?
Python!!?! i almost did a C | N > K (that would be cola, pepsi rather, through nose to keyboard)
ok ok ok ok although i almos-t ruined a perfectly free and good keyboard, i don't like python cause i don't know it, and the learning curve has been... dreadful.
Can't we do this in C?
I hope you meant C++, unless you think it's productive to do a poorly documented and bug-ridden reimplementation of half of C++ standard library* everytime you want to do something other than a hello world application.
Actually, for tools like wine doors it'd be more concise to do the logic in Lisp, rather than Python or C++. The problem is that wine-hackers-wise, I would bet we have way more people skilled in C++ than people skilled in Python than people skilled in Lisp, so methinks that C++ is the right way to go, just because of the sheer number of developers available
C++ (and Python) gives you an advantage of being able to directly** leverage Qt to have wine doors that can either work as a regular unix application, or a windows application under wine itself. Heck, it'd work just fine on Intel Mac boxen, and on PPC Mac boxen whenever wine will utilize some emulator platform.
Cheers, Kuba * yes, it's a slightly modified quote from somewhere else ;) ** as opposed to say doing only the GUI in C++ and logic in Lisp
On 3/28/06, Kuba Ober kuba@mareimbrium.org wrote:
Python!!?! i almost did a C | N > K (that would be cola, pepsi rather, through nose to keyboard)
ok ok ok ok although i almos-t ruined a perfectly free and good keyboard, i don't like python cause i don't know it, and the learning curve has been... dreadful.
Can't we do this in C?
I hope you meant C++, unless you think it's productive to do a poorly documented and bug-ridden reimplementation of half of C++ standard library* everytime you want to do something other than a hello world application.
Actually, for tools like wine doors it'd be more concise to do the logic in Lisp, rather than Python or C++. The problem is that wine-hackers-wise, I would bet we have way more people skilled in C++ than people skilled in Python than people skilled in Lisp, so methinks that C++ is the right way to go, just because of the sheer number of developers available
C++ (and Python) gives you an advantage of being able to directly** leverage Qt to have wine doors that can either work as a regular unix application, or a windows application under wine itself. Heck, it'd work just fine on Intel Mac boxen, and on PPC Mac boxen whenever wine will utilize some emulator platform.
Cheers, Kuba
- yes, it's a slightly modified quote from somewhere else ;)
** as opposed to say doing only the GUI in C++ and logic in Lisp
Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how about................... COBOL!! LMFAO gimme a break..
Seriously though, why not break winedoors up into different components, and then have different submaintainers, and each component can be written in the language that that submaintainer is most comfortable with? Obviously each piece of code would go thru the project maintainer, and so if someone started writing another "door" in bash, then that door could quickly be closed (pun intended).
As for the GUI, make it C or C++, only because that is the most widely used language in linux..
Tom
Can't we do this in C?
I hope you meant C++, unless you think it's productive to do a poorly documented and bug-ridden reimplementation of half of C++ standard library* everytime you want to do something other than a hello world application.
Actually, for tools like wine doors it'd be more concise to do the logic in Lisp, rather than Python or C++. The problem is that wine-hackers-wise, I would bet we have way more people skilled in C++ than people skilled in Python than people skilled in Lisp, so methinks that C++ is the right way to go, just because of the sheer number of developers available
C++ (and Python) gives you an advantage of being able to directly** leverage Qt to have wine doors that can either work as a regular unix application, or a windows application under wine itself. Heck, it'd work just fine on Intel Mac boxen, and on PPC Mac boxen whenever wine will utilize some emulator platform.
Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how about................... COBOL!! LMFAO gimme a break..
I was pretty serious when I said about Lisp. Once you get to know it, it's an extremely agile and productive programming language that has way more power than Python does. Lisp might be considered more obscure, that's sure, but that's due to people mostly being clueless (sorry, had to say that). For example there's no Python implementation that I know of that would even remotely compare (performance-wise) to Frantz Lisp, when running "dirty first-cut" code.
Fortran is about as good as C is, as there are about as good Fortran compilers as there are C compilers, so at least tool-wise those are on similar footing. Since more people know C, it's obvious that Fortran would be a bad choice.
I'd say that Pascal and Ada are serious languages to consider as well, the only problem is that there are no serious bindings for any of them to Qt :) Well, there are FPC to Qt bindings, and Ada to Qt bindings, but they are nowhere near PyQt.
I'll leave COBOL out because I know nothing about it. I looked for some decent and affordable tools and I couldn't find any besides Kobol from TheKompany, so that's a bit few for my liking, and with a bit of a shortish history. Frantz Lisp has been around for so much longer, and there are many decent enough free Common Lisp implementations.
Seriously though, why not break winedoors up into different components, and then have different submaintainers, and each component can be written in the language that that submaintainer is most comfortable with? Obviously each piece of code would go thru the project maintainer, and so if someone started writing another "door" in bash, then that door could quickly be closed (pun intended).
As for the GUI, make it C or C++, only because that is the most widely used language in linux..
Making it C implies not using Qt*, and I just can't see why anyone would *not* want to use Qt. I'm dead serious. It's probably the only framework right now that has any future, besides .net offerings and whatever is available for Java. Everything else (gtk, wxWidgets, . . .) simply has no support (compared to Qt). It's stupid to use dead solutions.
I was also pretty serious about C being a bad language choice. C and C++ are vastly different languages that share some syntax, that's all. Saying "C or C++" is akin to saying "C or Lisp", "C or Python" etc.
Cheers, Kuba
* Sure, you can develop bindings from C to Qt, but what's the point?
PS. I consider Tcl/Tk to be an equally dead abomination, although in widespread use. Consider that Latin is also pretty widely used (way more than Tcl/Tk methinks), yet equally dead. Dead is dead, right? :) So I covered all bases, I think.
On Tue, 2006-03-28 at 17:22 -0500, Kuba Ober wrote:
I was pretty serious when I said about Lisp. Once you get to know it, it's an extremely agile and productive programming language that has way more power than Python does.
Even if that statement were true (I seriously doubt you can qualify it with any actual evidence), 'power' isn't the only concern in choosing a programming language for a project. Python has excellent community support, tons of third party modules, several mature IDEs, and most of all is easier for a new programmer to pickup than any other language I've tried.
I'm also curious how you think that Lisp can somehow more concisely represent the logic for this app. I haven't looked at any GUI bindings for Lisp, but if they look anything like the OCaml ones it's just going to be a dump of imperative code, which mostly defeats the point of using a functional language in the first place.
Python stole from Lisp what most people like about Lisp anyway.
Lisp might be considered more obscure, that's sure, but that's due to people mostly being clueless (sorry, had to say that). For example there's no Python implementation that I know of that would even remotely compare (performance-wise) to Frantz Lisp, when running "dirty first-cut" code.
The Python community pretty openly states that if performance is a major concern for your project that Python is the wrong choice. You can code part of your project in C (the performance critical parts) and the rest in Python in some cases. If your app has a flat performance profile then it's well known that Python isn't the best choice. Then again, no one is going to use Lisp in that case either.
Bottom line -- this is a configurer. It's not run super often and what it does isn't that computationally intensive anyway. Performance isn't a concern.
Making it C implies not using Qt*, and I just can't see why anyone would *not* want to use Qt. I'm dead serious. It's probably the only framework right now that has any future, besides .net offerings and whatever is available for Java. Everything else (gtk, wxWidgets, . . .) simply has no support (compared to Qt). It's stupid to use dead solutions.
Although I agree that Qt is the best choice, I'd have to disagree that gtk is dead. wxWidgets will probably be around for some time too, if for no other reason than that using Qt in C++ is a bit annoying because it needlessly reinvents the wheel (there's a lot of overlap between Qt and boost and even standard lib). It's the same reason gtkmm has more appeal to some C++ coders than Qt.
On Tuesday 28 March 2006 23:30, Joseph Garvin wrote:
On Tue, 2006-03-28 at 17:22 -0500, Kuba Ober wrote:
I was pretty serious when I said about Lisp. Once you get to know it, it's an extremely agile and productive programming language that has way more power than Python does.
Even if that statement were true (I seriously doubt you can qualify it with any actual evidence), 'power' isn't the only concern in choosing a programming language for a project. Python has excellent community support, tons of third party modules, several mature IDEs, and most of all is easier for a new programmer to pickup than any other language I've tried.
Only after you were exposed to C/Modula-like languages in the first place. For someone who never programmed before it's easier to pick up Scheme than C, and I could hardly agree more with Natasha: http://www.inf.hs-zigr.de/~wagenkn/Natasha_Chen.html
I've resisted switching from Pascal to C/C++ my whole high school, as I considered C too have too convoluted a syntax. My opinion hasn't changed, it's just that for a long time gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can essentially make a living not having to use a single pointer-to-function for a month at a time. But again, C++ is not C.
I'm also curious how you think that Lisp can somehow more concisely represent the logic for this app. I haven't looked at any GUI bindings for Lisp, but if they look anything like the OCaml ones it's just going to be a dump of imperative code, which mostly defeats the point of using a functional language in the first place.
You can program in Lisp in both functional and imperative styles, and I guess that most Lisp programs have both styles in them. It mostly depends on what's handy at the moment :)
Python stole from Lisp what most people like about Lisp anyway.
Well, functions aren't exactly first class citizens in Python, they were on their way to becoming so for some time AFAIK (more and more every release). That's something that was in Lisp since day one, OTOH.
Lisp might be considered more obscure, that's sure, but that's due to people mostly being clueless (sorry, had to say that). For example there's no Python implementation that I know of that would even remotely compare (performance-wise) to Frantz Lisp, when running "dirty first-cut" code.
The Python community pretty openly states that if performance is a major concern for your project that Python is the wrong choice. You can code part of your project in C (the performance critical parts) and the rest in Python in some cases. If your app has a flat performance profile then it's well known that Python isn't the best choice. Then again, no one is going to use Lisp in that case either.
IIRC the only reason that Orbitz became so good is because they had their flight search logic coded initially in Lisp. That's not only a fairly hardcore CPU-bound task, the choice of language made them way more agile feature-wise in their startup years. Right now they ported most of the code to C++, but I bet it was only feasible to do so after they got the architecture figured out and kinda settled down after hacking away in Lisp initially.
Bottom line -- this is a configurer. It's not run super often and what it does isn't that computationally intensive anyway. Performance isn't a concern.
I know. I'm not overly concerned about that. I mainly wanted to redirect the flamewar elsewhere and have some fun at the same time. Yay :)
Making it C implies not using Qt*, and I just can't see why anyone would *not* want to use Qt. I'm dead serious. It's probably the only framework right now that has any future, besides .net offerings and whatever is available for Java. Everything else (gtk, wxWidgets, . . .) simply has no support (compared to Qt). It's stupid to use dead solutions.
Although I agree that Qt is the best choice, I'd have to disagree that gtk is dead. wxWidgets will probably be around for some time too,
Hanging around for some time vs. having full backing by a company are two different things. Last time I checked there was no single company of the size of Trolltech, or bigger :), whose bread and butter was developing gtk or wxWidgets, and who would have real good reason to develop either one of them further. I know that there are other thriving open source projects (Linux kernel, anyone?) where there is no single controlling company in charge, but those projects have achieved their critical mass long time ago and are past the infant stage. I don't see gtk or wxW anywhere near a critical mass.
if for no other reason than that using Qt in C++ is a bit annoying because it needlessly reinvents the wheel (there's a lot of overlap between Qt and boost and even standard lib).
Which is mainly of historical origin, as there was simply no decent implementation of boost or standard lib in the times when Qt began shipping. With model/view architecture supported so well by Qt4, you can have all your data in whatever containers you want, there's a tiny bit of interface code to write to get it to the widgets, that's all. I.e. Qt doesn't force you not to use boost, C++ library and so on.
Cheers, Kuba
Typos, typos everywhere :)
I've resisted switching from Pascal to C/C++ my whole high school, as I considered C too have too convoluted a syntax. My opinion hasn't changed, it's just that for a long time gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can
should have been
I've resisted switching from Pascal to C/C++ my whole high school, as I considered C to have too convoluted a syntax. My opinion hasn't changed, it's just that gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can
Cheers, Kuba
Tom Spear wrote:
Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how about................... COBOL!! LMFAO gimme a break..
Seriously though, why not break winedoors up into different components, and then have different submaintainers, and each component can be written in the language that that submaintainer is most comfortable with? Obviously each piece of code would go thru the project maintainer, and so if someone started writing another "door" in bash, then that door could quickly be closed (pun intended).
As for the GUI, make it C or C++, only because that is the most widely used language in linux..
What about perl? I'm not a perl programmer or anything but wouldn't that be as prevalent in a Linux environment as C or C++? I believe GTK+ could be used for the UI and I don't know if QT could also be used or not.
I'm sitting back and watching this discussion and I just wanted to mention perl for you guys to consider. :)
I'll shut up now. :)
Peace...
Tom
Tom Williams wrote:
Tom Spear wrote:
Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how about................... COBOL!! LMFAO gimme a break..
Seriously though, why not break winedoors up into different components, and then have different submaintainers, and each component can be written in the language that that submaintainer is most comfortable with? Obviously each piece of code would go thru the project maintainer, and so if someone started writing another "door" in bash, then that door could quickly be closed (pun intended).
As for the GUI, make it C or C++, only because that is the most widely used language in linux..
What about perl? I'm not a perl programmer or anything but wouldn't that be as prevalent in a Linux environment as C or C++? I believe GTK+ could be used for the UI and I don't know if QT could also be used or not.
It is possible to link to GTK+ and QT with the same binary, but it's best to use a system of modules and common calls/elements to do the GUI stuff in seperate dlopen()ed modules so that anyone that has a taste for a odd, weird, or obsolete toolkit could also make a UI plugin for such, while not modifying the core at all (Motif plugin, anyone?)
I'm sitting back and watching this discussion and I just wanted to mention perl for you guys to consider. :)
I'll shut up now. :)
Peace...
Tom
* On Tue, 28 Mar 2006, Karl Lattimer wrote:
And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive,
Yes, he didn't write any single patch yet that was accepted, still he manages to joke calling one of the developers being a monkey. (Given that monkeys can't even distinguish between MUAs and MTAs nowadays)
Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
On Wed, 2006-03-29 at 12:27 +0300, Saulius Krasuckas wrote:
- On Tue, 28 Mar 2006, Karl Lattimer wrote:
And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive,
Yes, he didn't write any single patch yet that was accepted, still he manages to joke calling one of the developers being a monkey. (Given that monkeys can't even distinguish between MUAs and MTAs nowadays)
Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
Justified, expulsion... Do we need a lynch mob or do you just mailman it?
/me wraps his rope 13 times around itself....
Unlucky for some
K,
Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
Poppycock. The discussion he initiated ain't that useless, and as I see it, he was rather addressing a possible reply denying the (read: /his/) fact, that this one reason (why it is useless) is inargueable, than a certain person (sarcasm, anyone?).
So, Inargueable, eh?
Well. Depends.
I use both Sidenet and Winetools, they both provide an easy way to have a quick and simple (more or less basic) setup for wine established.
But in reality those (original) scripts are pretty much useless to me since I don't use the ~/.wine path, because I a) have multiple versions of wine installed (compiled) and b) need to use multiple instances of those wine-versions. Of course, after modifying the scripts, everything works as supposed.
Also, Winetools give you the ability to install several additional applications per button, but I don't think that should be the future. If I want to install Office then it has to work via double clicking the setup.exe. /Period/.
Wine should provide an own beautiful setup (something like wineprefixcreate+), to install the directory structure and whatnot, the rest has to be considered as working out of the box. And if not, there is still the AppDB.
In the end, one will find Winetools/Sidenet or any derivates useful, the other not. But those tools *should* become useless one day. And that is inargueable, despite of any IQ.
-Ray
On 3/29/06, Ray Jones rayjones@gmx.net wrote:
Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
Poppycock. The discussion he initiated ain't that useless, and as I see it, he was rather addressing a possible reply denying the (read: /his/) fact, that this one reason (why it is useless) is inargueable, than a certain person (sarcasm, anyone?).
So, Inargueable, eh?
Well. Depends.
I use both Sidenet and Winetools, they both provide an easy way to have a quick and simple (more or less basic) setup for wine established.
But in reality those (original) scripts are pretty much useless to me since I don't use the ~/.wine path, because I a) have multiple versions of wine installed (compiled) and b) need to use multiple instances of those wine-versions. Of course, after modifying the scripts, everything works as supposed.
Also, Winetools give you the ability to install several additional applications per button, but I don't think that should be the future. If I want to install Office then it has to work via double clicking the setup.exe. /Period/.
Wine should provide an own beautiful setup (something like wineprefixcreate+), to install the directory structure and whatnot, the rest has to be considered as working out of the box. And if not, there is still the AppDB.
In the end, one will find Winetools/Sidenet or any derivates useful, the other not. But those tools *should* become useless one day. And that is inargueable, despite of any IQ.
-Ray
This is the most well said email I have seen on this topic yet. Yes I am saying mine were pointless, including this one :-D
Tom
Saulius Krasuckas wrote:
- On Tue, 28 Mar 2006, Karl Lattimer wrote:
And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive,
Hardly. I have actually done something good. I got people to addresses the Winetools problem a bit early. Sure, it would have gotten adressed anyways, but only after enough complains come rolling in, months or years from now. When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end result was nothing but good, so why shun me? I was just getting a matter addressed before we have no choice but to address it. We can't just put it off forever, you know.
Yes, he didn't write any single patch yet that was accepted, still he manages to joke calling one of the developers being a monkey. (Given that monkeys can't even distinguish between MUAs and MTAs nowadays)
I haven't written any patches, namely because my eariler code changes i find cause signal 11. Recently I am working on something that will be offloaded months from now (if i dont find it to be too fustrating) as a huge diff, so keep your eyes peeled. If it doesn't work on either of my systems, it's broken, and sending a diff is a waste of everybody's time.
Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
On 3/29/06, Segin segin2005@gmail.com wrote:
Saulius Krasuckas wrote:
- On Tue, 28 Mar 2006, Karl Lattimer wrote:
And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive,
Hardly. I have actually done something good. I got people to addresses the Winetools problem a bit early. Sure, it would have gotten adressed anyways, but only after enough complains come rolling in, months or years from now. When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end result was nothing but good, so why shun me? I was just getting a matter addressed before we have no choice but to address it. We can't just put it off forever, you know.
It was already being addressed in the wine tools -> wine doors thread. So your flame (more like attack) did nothing good at all that wasnt already being done. Next time you have something that you want done (or addressed) just bring it up in a new thread, and dont be so rude about it. You will find a much more positive result (as opposed to 3 threads all going on about how bad of you it was to say what you said to the doc in private).
I haven't written any patches, namely because my eariler code changes i find
cause signal 11. Recently I am working on something that will be offloaded months from now (if i dont find it to be too fustrating) as a huge diff, so keep your eyes peeled. If it doesn't work on either of my systems, it's broken, and sending a diff is a waste of everybody's time.
I wouldn't do it in a huge diff. Break it up, because I have noticed that AJ usually wont commit huge diffs as is.
Tom
On Mon, 2006-03-27 at 21:32 -0500, Segin wrote:
There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
Thought it might be interesting to refer back to the email that kicked all of this off and try to look at it in detail.
There is one reason, inarguable
Anything is arguable, if one has arguments that can be backed up with evidence.
(if you reply to this you have a IQ of 0)
Everyone has an IQ of more than 0. If they didn't, it is unlikely they would be able to read and so would not be in a position to respond. I also believe that anyone who reads this list has demonstrated a remarkable degree of intelligence in trying to move as far away from Windows as possible. The inference of this statement seems to be 'I am right because I am. I deny you the right to disagree - if you do I have already marked you out as an imbecile and you are not worthy of any consideration' - sounds rather fascist to me.
as to why WineTools is useless.
I have used Winetools when necessary, when there was no other easily available option. IE is required for me to use online banking. I have complained to my bank, and asked them to support FireFox and they have declined. Winetools helped me achieve what I needed. For my specific needs, winetools was useful.
Most of the WineTools 'magic'
Implication by use of quotation marks - winetools claims to be magic. It does not, as far as I know.
is in it's ~/.wine/config file, which Wine no longer uses/acknoleges,
Ignoring the poor spelling and concentrating on the details, I have used versions of winetools that supported the config file, and more recently, versions that support the newer registry configuration. Given my understanding of current wine configuration I think the statement may be misleading. If I am wrong, I am happy to be corrected, preferably in a private email.
WineTools is utterly useless and has no point in existing AT ALL, PERIOD.
I have already described at least one reason for it to exist. Shouting isn't necessary, but if it makes segin feel better, that's entirely up to him.
The point of this email is not to argue as to whether winetools is good for Wine or not - I can see both sides of the argument. Neither do I believe that any form of banning is necessary. I'm opposed to censorship generally, and given that no individual attack was made such sanctions could be counterproductive, given that segin has offered to submit code to wine in the future.
All I can suggest is that when individuals have an opinion they believe strongly in, perhaps it might be a good idea to read though any open message they send before hitting 'Send' to see if it is readable and stands up to rational criticism.
I have the greatest of respect for the entire wine community (no exceptions) and know that with rational debate and argument wine will be a huge (maybe the biggest) factor in ending the Windows monopoly.
-
Dominic Wise -
Hiji -
Joachim von Thadden -
Joris Huizer -
Joseph Garvin -
Kai Blin -
Karl Lattimer -
Kuba Ober -
Marcus Meissner -
Ray Jones -
Saulius Krasuckas -
Segin -
Tom Spear -
Tom Williams