Leo wrote:
that'd be http://nagoya.apache.org/wiki/apachewiki.cgi?GumpPython
Ah yes, forgot that, sorry.
I can get you X-over-SSH to a box running red hat if you need it to test
linux GUI stuff.
I am somewhat modem challenged (up the mountain I live) and have slow
connectivity that I can't upgrade. Thanks for the offer though.
I downloaded the wxPython stuff to my M$ and after a few tweaks (and a hack
to wx) it got the GUI working. I must say -- I was very impressed -- repeat
very! I had previously (and privately) thought that I'd not use the Python
GUI (Eclipse does ordered builds fine for small projects) but I completely
take that back that thought. For viewing/manipulating gump metadata, for
testing ant/centipede builds, for displaying "as gump sees it" ... it is
awesome. I will use the significantly. Great job guys!
> BTW: Yes, I understand the risks of investment here, but I think it is
worth
> the shot...
go for it dude! (and keep us informed and the wiki updated ;)
I read a bunch of the code yesterday, after reading a few Python tutorials.
I follow it so much more.
Here are some initial thoughts -- provide feedback if you have time,
otherwise I'll just experiment:
1) There is a TODO in the existing code to actually launch "cvs" or launch
"ant" and capture their exit status and output. I could see the need for
some sort of launcher class to do this, and an result class to capture
status & a file reference for stdout/stderr (combined?) [Perhaps this
launcher could have a "timeout" in it, that would zap a long running process
& set another status.]
2) We need (IMHO) to represent the results of operations per project --
those operations are "configure" (merge/whatever), "update" and "build" & I
see the latter two having the output from above. I could see this having
"project gump status = SUCCESS/FAIL/PREREQ MISSING/TIMEOUT/CONFIG ERROR.
When I think of gump I think "batch builds" so I'd see this as one
aggregating class per project (and a named array per pro, but I fear that'd
impact use cases other prefer (simple re-testing, whatever). Any thoughts on
this?
3) Ok, so given that "result set" we need one or more presentations. I am
eager to work with forrest (via xdocs) so I was thinking of creating some
sort of simple XDoc class w/ Book/Tab/Page type sub-classes. Nothing fancy,
just enough to serialize out some simple xdocs.
Ought I create gump/xdocs for this (as opposed to xdocs)? No point getting
ahead of ourselves and thinking we are creating anything more than just for
gump.
I would love input on what the xdocs tabs ought be. I saw those for the GUI,
and they are very good for a dynamic GUI, but don't see right for tabs for
HTML pages. Perhaps the tabs ought be by object type, module/project/repo,
etc. I'd like to give the user good insight" into everything (like
statistics, like dependencies/dependers) in an easily navigable mechanism
but I don't have it in mind yet. I want to quickly eyeball multiple
projects (typically krysalis group) and I want to see all related result,
I'd like this gump to give better higher level views like groups.
BTW: I see something for RSS, do we need multiple output presenters?
4) I see that GumpBase and gen.py xmlize are pretty useful XML to/from
Object mechanisms. I assume they are not 100% generic (or they'd be in
Python core) but I can see that they'd work for us. Ought these be moved to
a gump/xml ?
All feedback appreciated.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
