Just some little (unfinished) concept mockup. Seeing that much of it still ends up as a “text box with syntax highlighting” it’d probably make sense to implement it as a gedit plugin.
Copyright © 2007-2011 Siegfried-Angel Gevatter Pujals. Some rights reserved.
Powered by WordPress 3.5.1 ¬ dfBlog Theme 1.2 RC1 design by danielfajardo web
Powered by WordPress 3.5.1 ¬ dfBlog Theme 1.2 RC1 design by danielfajardo web
Lowering barrier to entry & maintenance cost of deb packages is a very valuable effort.
Looking forward to this.
+1
Changelog should not be a bare text field, it should be a frontend to debchange. In particular, do not allow changes to the timestamp or the maintainer address, allow changelog entries to be created directly from bug numbers (just as happens with dch -a –closes 123456). The rest can all be drop down / combo boxes. unstable/experimental etc., automatically work out if a new changelog entry is needed (after an upload) or append to the existing one.
debian/control can also support more than a bare text field – only certain fields are allowed and each field only has certain acceptable content – sounds like there’s room for some buttons and drop-down lists.
Also, link with deb-gview for a GUI viewer of the contents of the resulting packages.
Some form of feedback will be needed during the building of the package and that build process must involve a pbuilder type chroot build if this is to be used for uploads to Debian. Probably better to aim uploads at mentors.debian.net
What software are you using to make the mock-ups? Thanks!
I know James Westby had started some work on a gedit plugin for packaging. I’m not sure how far it got.
http://jameswestby.net/weblog/ubuntu/15-project-cambria.html
https://edge.launchpad.net/~cambria
https://edge.launchpad.net/gedit-ubudev
Thanks for the feedback! However, note that I’m currently not planning to implement this.
I’ve just been thinking about how my ideal Packaging GUI would be (after seeing some quite scary/ stuff out there> and thought I’d share some of my ideas and maybe get someone inspired :).
@ Neil:
Yes, there’s quite some assistance that can be provided for debian/{control,changelog,copyright,etc} files.
I’d rather have them in the form of auto-complete/suggestions and smart pop-up combos (eg. showing up when you click on the release name in the changelog) than replacing the text area with some kind of form, as I’d find that rather limiting, but I guess that’s personal preference, and your approach may well work better for people new to packaging.
I forgot to mention it in the mockup but the “Upload to X” links should be dynamic, changing to “Upload to Mentors/REVU” depending on the user’s privileges (or offering a choice). And it’d certainly be nice to have {p,cow}builder-dist integration.
Thanks for the pointer to deb-gviev. gdebi-gtk shows pretty much the same, but takes much longer to load (since it also offers to install the package).
@ Randall:
I used Balsamiq (its web-based evaluation version): http://balsamiq.com/products/mockups
Why do you wish to ignore ./configure and make? Wouldn’t you like to know if something is messed up with the source/compiling?
@ Siyan:
That’s an allusion to some GUIs out there which consist of buttons like “make” and “./configure”, I didn’t mean to say that the output of running such commands should be ignored but rather that running them should be handled by debhelper 7 at build time rather than having some button for that.