Hi Max!
Thanks for the input, these are some useful suggestions. I agree
with you to make it a seperate tool, because of the different audiences.
My original idea of the tool would be to help a maintainer with
creating the info file by removing as many tasks from the CLI to the
GUI. As you know I come from a Mac background, not a *nix background,
and I still sometimes am struggling in the terminal. Which is why I
thought of creating this tool that could make things hopefully a bit
easier. So tasks for the tool actually would include build, validate,
otool, etc. However, the build function will make it look like
FinkCommander, and I will be duplicating a lot of code. You already
take it a whole step further (which is very good) by suggesting all
the other functions.
I like your idea of 'automatically populating' the fields. Currently
my tool is just a plain texteditor with some wrappers for various
commands, and an output filed for fink. The maintainer still will
need to type in a lot of info, and many fields are not required, so a
texteditor seems a logical choice. The only alternative that I can
think of right now is a page with many editfields, but that could
become very crowded very quickly. If you have some suggestions on how
to do this in a non-text-editor mode, I'd like to hear that.
And I am sure interested in your other UI suggestions :)
cheers,
- Koen.
just my two cents, but I definitely would keep those two apart.
They have very different target audiences (I might use your tool, I
probably never will use FinkCommander). To be honest, I probably
wouldn't use a (Re)build button anyway; it would be useful to an
extent provided you add a window logging the output of Fink (and
which makes it possible to save it to a file). But then while
writing a package I need to run lots of shell commands anyway (to
examine the .deb file, to run & test the programm, to use "otool"
and "nm" to analyze the executable / shlibs etc.)... so I am in the
terminal anyway and entering "fink rebuild FOO" isn't much effort...
That said, I have thought about a tool similar to what you describe
myself several times in the past years, and I am glad to hear you
are working on this... One idea (not sure if you already have that)
would be to add a user preference for a default Maintainer field
value (I hate to retype mine every time) which is used when
creating a new package :-). Some other things:
* Some validation features could actually be built into your app
(like, mark missing required fields, or mark the "Description"
field in yellow/red if the text length is longer than the
recommended length)
* A "Fetch" button which downloads the source
* An MD5/SHA1 tool to compute the checksum of the source file(s)
and automatically populates the corresponding fields, if desired
* The same for the patch file checksums, once that is "in the wild"
* Package homepage URL should have a button to automatically "surf"
to it
* Since some authors like to write comments into their .info file,
it would be nice if your tool could preserve those comments, and
maybe also the order of fields. I can give you some code /
suggestion as to how to achieve that, I had to do it myself for
another app in the past.
* I also have lots of UI suggestions, if you are interested in
hearing them, feel free to drop me a line, but I don't want to spam
here any more than I already did :-)
Cheers,
Max
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
