Re: Bug#689824: RFP: yquake2 -- Yamagi Quake II - Enhanced client for Quake II
On 08/10/13 18:53, Jonathan Dowland wrote:
> I was mostly
> interested in trying to specify and write declarative descriptions of
> the dependencies and steps needed to do stuff. Then, the tool could
> run some steps in the background whilst other steps were waiting on
> user prompts, etc. The tool being written in a better language and
> having a GUI were secondary at the time.
I think being written in a real language is a necessary prerequisite for
using structured data, so parsing can be sensible. My vague plan was for
the new g-d-p to select a "target", then initially just run
/usr/share/g-d-p/g-d-p.sh (the current shell implementation) passing it
the target and other stuff as arguments - then we could port a target at
a time from shell to Python-or-whatever. The first-attempt GUI could
just do that in a terminal widget (GNOME Terminal's vte, or equivalent).
> If I
> were planning to have another stab as a solo person, I'd probably go
> for QT this time, but I don't have strong feeling one way or another,
> and I imagine GTK3 would be a smarter choice for others.
Yeah, I'd probably use Python + PyGI + Gtk3 if I did this. I'm not sure
which Python Qt binding is the preferred one these days, but if there's
a good one, that could also be a good choice.
> I'd love to
> have another crack at the declarative end (is YAML still a sane
> choice on that score, I wonder? Seems to be…)
Yes, I think having g-d-p be more declarative is a good goal. That's why
the quake2 bits mostly work from files containing "target" md5sums. The
declarative data that's mostly still missing is "if you're missing files
X, Y and Z, you can get them by downloading W, and unpacking it like this".
> Finally, since I'm ranting on about gdp: I think we need to either have
> a rule of thumb that each 'target' generates precicely one .deb, or
> alternatively not have that rule but handle the discoverability of
> one target:many debs better.
I'm not sure which is better, tbh. One of the things I like about the
quake and quake2 targets is that you can tell them to work on some
random directory, and they'll work out what is sensible to do with it -
separating the demo/shareware target from the full target limits that.
If the targets were declarative, of course, they could have a list of
sub-targets as one of their bits of metadata :-)
In a GUI, I think we'd want the user-facing target to be "I want Quake
II", selecting demo or full after that. I'm not sure how mission packs,
mods, etc. fit - I think there's value in grouping them together.
S
Reply to: