On Thursday 09 October 2008 22:06:55 Chris Ahrendt wrote:
Whew, long post. I'll tackle this as I go.
My wish list would be:
- Some form of a Standard Gui Debugger GDB integration / eclipse etc..
gdb has a standard GUI? Which would that be in your case? I hear Eclipse is useable for C development, but does any Wine dev use it?
- A way to select the debug flags used with an explanation of what
each is for... +seh is for this +relay does that...etc....
See http://wiki.winehq.org/DebugChannels and http://bugs.winehq.org/show_bug.cgi?id=638
Feel free to flesh out the wiki page.
- When you do +relay you could open separate output for each thread or
send the +relay output for each thread to a different pipe so we can then pipe that information to a file or open that pipe and use a tool to look at whats going on.
So you need to start guessing which thread to capture? Do you know about +tid and tools/examine-relay ?
- The ability to turn each of the +relay wine thread output on or
off... Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. A best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesn't give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere.
Actually most of the errors that disappeared for me when using +relay were races and stack smashing bugs. Those are always a pain to debug, and will probably disappear as well when only using parts of +relay.
- A window or output with a list of the important wine structures or
resources that can be watched as the application runs with some explination of what those structures are for. And do the same with the dump. If the execution space is in an application output that fact. If we are in wine and we have the symbols of where we are then dump the code where we are too =)
I don't know how this would be implemented, but it sounds like a performance drag to me. So I take you intend this to be a debugging tool. What's wrong with using a debugger?
- Source code debugging in the GUI with step through, break points,
etc..( not like now in winedbg but more like one of the GUI's mentioned before) and yes I know Gdb sort of works.. why not make it so it really works.. its not like I am asking to use VC++ to debug wine here lol.
Most debugger GUIs on Linux are (somewhat sucky) frontends to gdb. I'm pretty sure it's possible to create something similar for winedbg.
- Loading of application from gui debugger and then run it. This can be
done with gdb now but its not the easiest in the world to do. This would be nice if it was made easier.
Sure, I'm pretty sure this can be done in aforementioned GUI.
- Ability to look at a stack and backtrace in the GUI or exception list
and have the symbol associated with the backtrace placed in the execution trace.
Yup, see above.
- Value Watches within the GUI.
And again. This all sounds like stuff you'd expect from a debugger. I take you volunteer to write a GUI for winedbg?
- Code Checking Some sort of bounds checking... Uninitialized variable checking.... Unreachable Code Checking (I think is being done to an extent with Dan's runs of valgrind)
We're already running static analysis tools and other checkers on the code.
- Use the GUI to help enforce the Wine Coding standard.. most modern
GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now.
What GUI? The last time you talked about a GUI you were talking about a frontend for winedbg. I don't see how this links to coding standards. If you're talking about IDEs, I think you will find that a lot of the Wine developers consider vim or emacs to be all the GUI they need.
- Online help / Context help... point to the IC in the wiki... lots
of good stuff there... just hard to find sometimes....
From the editor?
- Integration with bugzilla... they find a bug... they create it in
the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc...
Your losing me here with "the GUI". Is this going to be a debuger-codechecker-coffe-machine-mail-reader-vcs-compiler program that will also fetch my newspaper?
- Integration with GIT... check and see if there is a new tree out
there.. if so... flag it and git it... (also update the GIT page with the latest instructions. Some of us are not GIT people by background... CVS, etc.. so there is a really steep learning curve and its easy to mess a local GIT tree up and have to reload.
If you can point out what's missing from http://wiki.winehq.org/GitWine I'll gladly add more information to that page.
- Link to whats fixed in the new GIT tree... or a list of it...
something off the main WINEHQ page that says ok here is 1.1.15 here is what we fixed...
It's called "changelog", and we already have that.
- Link to Dan's patchwatcher status... (kinda a workflow sort of
thing) to know whats good and bad...
I'm pretty sure that once patchwatcher is stable, it'll get a prominent link.
- Generation of the GIT patch and then mail it to the list through a
button...
Oh, from the swiss army knife GUI?
You have to remember alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. And no I am not criticizing wine in the least by the above. I really enjoy using wine and hacking around learning things. I want it to be the best it can be..
From looking at what you proposed, you're looking at a couple of man-years of work on a GUI few if any of the existing Wine devs will use. And without wanting to sound elitist, working on Wine is hard. At least hard enough to make learning some command-line tools we require easy.
I'm convinced that someone who can't learn enough on the command-line to run the basic git, configure and make steps will have a very hard time trying to develop Wine code.
That being said, I think a GUI for winedbg would be a nice tool, and if we can come up with a tool that makes translations easier, that'd be helpful as well. I just don't think that it's possible to create The One GUI To Rule Them All.
Cheers, Kai