I read your story about winetools a couple weeks ago around the same time that I tried using winetools on FC5 test 3, it didn't go well with winetools and I was looking for another solution and couldn't find one that fitted well with my criteria.
I started thinking of packages like RPMs and started breaking down a wine application installation into what we would need to run it directly from the application menu.
What I came up with this is, its pretty raw right now, its simply a small self contained package for managing the install process of a wine application, soon I'm going to start work on creating a package repository and the package browser but would really like to use the appdb for supplementary information, i.e. screenshots version compatibility etc...
http://www.qdh.org.uk/wordpress/?cat=6
I have also considered having a way of making apps install gobally on a machine so any and every user has access to them, and considered using inotify to watch events and provide a way of handling this.
This is still in the beginning stages and I would be grateful for any input you may have. I was very interested in what was published here,
http://www.winehq.org/?issue=308#Winetools..%20part%20II
I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however there are some useful little bits in there which I have been cannibalising when necessary into my own application. The beauty of this is that it is only an application shell, in theory the appdb could be the central configuration repository containing all the information to make an app work. Available apps can be browsed, downloaded if possible or installed from a cd drive with minimal fuss.
I have one other who has joined in the project, his name is Alex Doukas and I believe he has also recently joined wine-devel.
Right now we're at the stage of building up some script archives and starting to put together application packs for the most important stuff, I will be working on the downloaders/xml parsers within the next couple of weeks and hopefully we should soon have a working application where the community keeps it up to date.
To prevent duplication of work I would suggest that suggestions to my project will be accepted, I hope to provide some public space for bug tracking etc... in the next couple of weeks and even public SVN. I currently have this configured and running but unfortunately do not have a great deal of bandwidth. The more people who join in the better, python programmers especially welcome, any scripts should eventually be posted to the bugzilla. Once the application db and my application fit together nicely we could have users publishing scripts in the appdb.
Karl Lattimer wrote:
[...] I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot [...]
Is THIS enough to get rid of Winetools?
Guys, WineTools clearly works for some people, there's no need to lay into it. After all, Wine itself has some slightly ugly areas of code still :)
I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however
This "clusterf*ck of nonsense" helped me to get a microcontroller development suite running under Wine, which otherwise would not install natively. After over ten years designing and developing embedded systems, there is one thing that stands out. Code that is 'nonsense' does not work at all. Code that works may not be elegant, it may not be pretty and you may hate the style, but it _works_ and therefore it is not nonsense. This code works, is useful and serves a purpose. Just because you don't like the way it is written does not make it nonsense. Language, please!
John.
On Fri, 2006-03-24 at 19:00 +0000, Dr J A Gow wrote:
I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however
This "clusterf*ck of nonsense" helped me to get a microcontroller development suite running under Wine, which otherwise would not install natively. After over ten years designing and developing embedded systems, there is one thing that stands out. Code that is 'nonsense' does not work at all. Code that works may not be elegant, it may not be pretty and you may hate the style, but it _works_ and therefore it is not nonsense. This code works, is useful and serves a purpose. Just because you don't like the way it is written does not make it nonsense. Language, please!
Fair point that it has been useful to you, it has been useful to me also. Here's what I see.
* An over complicated bash script, with way too many difficult to maintain parts * An inflexible application, which can only have new applications added to it by the maintainer * A terrible confusing GUI
My choice of words was strong I admit, but I think this application is ready to go to silicone heaven.
What I am proposing and indeed working on is;
* An appdb integrated application manager * A clean UI which fits with gnome HIG * A flexible, expandable, small and simple application which is easily maintained but can do everything winetools does.
Maybe nostalgia will keep some people using winetools, or trying to fix something which is broken. Or maybe a couple people could lend a hand with this and we could have something better ;)
K,
Karl Lattimer wrote:
Fair point that it has been useful to you, it has been useful to me also. Here's what I see.
- An over complicated bash script, with way too many difficult to
maintain parts
- An inflexible application, which can only have new applications added
to it by the maintainer
- A terrible confusing GUI
My choice of words was strong I admit, but I think this application is ready to go to silicone heaven.
Your points are quite true. I was only really pointing out that something that enables individuals to Get Work Done Quickly (however bad the tool might be technically) is of considerable value. That, of course, does not mean that the tool shouldn't be replaced when it starts to suffer from 'bit-rot'. But let's not completely can it until a viable replacement is available otherwise we could undermine the perceived 'usefulness' of Wine when it comes to a necessary rush-job.
I should add I don't use Winetools as a matter of course - I used it once to get me out of a hole, and it did!
What I am proposing and indeed working on is;
- An appdb integrated application manager
- A clean UI which fits with gnome HIG
- A flexible, expandable, small and simple application which is easily
maintained but can do everything winetools does.
This sounds like an excellent idea.
Maybe nostalgia will keep some people using winetools, or trying to fix something which is broken. Or maybe a couple people could lend a hand with this and we could have something better ;)
K,
Also note that most of Winetools prior usefullness was killed when we killed ~/.wine/config
Dr J A Gow wrote:
Karl Lattimer wrote:
Fair point that it has been useful to you, it has been useful to me also. Here's what I see.
- An over complicated bash script, with way too many difficult to
maintain parts
- An inflexible application, which can only have new applications added
to it by the maintainer
- A terrible confusing GUI
My choice of words was strong I admit, but I think this application is ready to go to silicone heaven.
Your points are quite true. I was only really pointing out that something that enables individuals to Get Work Done Quickly (however bad the tool might be technically) is of considerable value. That, of course, does not mean that the tool shouldn't be replaced when it starts to suffer from 'bit-rot'. But let's not completely can it until a viable replacement is available otherwise we could undermine the perceived 'usefulness' of Wine when it comes to a necessary rush-job.
I should add I don't use Winetools as a matter of course - I used it once to get me out of a hole, and it did!
What I am proposing and indeed working on is;
- An appdb integrated application manager
- A clean UI which fits with gnome HIG
- A flexible, expandable, small and simple application which is easily
maintained but can do everything winetools does.
This sounds like an excellent idea.
Maybe nostalgia will keep some people using winetools, or trying to fix something which is broken. Or maybe a couple people could lend a hand with this and we could have something better ;)
K,
On Sat, 2006-03-25 at 14:02 -0500, Segin wrote:
Also note that most of Winetools prior usefullness was killed when we killed ~/.wine/config
Now we rely on winereg? is that correct (I should know this ;)
I've been making some steady progress today, managed to get CD auto detection working (from some freevo code) and I've added basic SAX parsing for package lists. I hope I can get a base shell working soon.
I would love it if people would get involved, a few good coders can have SVN/trac access I'll work on opening up to the public soon.
pygtk/pyxml/wine hackers/shell scripters very welcome.
Some clarification i need is on how wine executes applications.
AFAIK this is how it works.
wine runs the wineserver and wine-pthread and when the application exits cleanly wineserver goes too, otherwise winedbg starts. I have code waiting for wine exit (similar to winetools) which currently works but I'd like to make sure i'm on the right track ;)
I'd also like to know what is the best way to kill a wine process and when it should be killed (currently I'm waiting indefinitely for wine to exit, then waiting 5 minutes on the wineserver).
When is the best time to use wineboot? What purpose does it serve, what can it break.
Cheers, K,
-
Dr J A Gow -
Karl Lattimer -
Mike Hearn -
Segin