Re: [Gimp-developer] GIMP website project planning
On 25 May 2001 23:58:43 -0400, Tom Rathborne wrote: > Now, I know most of us here are hackers and before you go killfiling > and /ignoring me for suggesting that there should be a manager, just Well, hackers have "managers" too. They are just called "Project maintainers" or "head developers". > think about it for a bit and let me know if there's anyone you know > who has time to do any technical/design/content _and_ make sure > that nothing is dropped on the floor. Now, I could be interested in the design front, since I somehow think the only way to make this new site happen is to take some responsibility on it, and make it happen together instead of just. Just discussing it wont make it happen, no matter how good opinions are voiced :-) There is just one problem with this beautiful idea: I will be away on holiday for about 2 weeks. On the other hand, maybe you will have come up with good ideas for the content and structural organization of the site by then, and one can then start thinking about design matters like navigation stuff etc. Tom: To avoid the original problem with the current site, does your perl thingy have good docs so people can learn it and maybe try it out on their machines to get an idea how it works, in case it needs to be expanded or developed further in the future and for some reason you dont have the possibility to do it? I like the content separation in it, but I am worried a bit about this side. Not that PHP is the Holy Grail in this, no way. More likely the Ugly Bowl of Spaghetti unless someone coordinates it as well. But it is easier to find people who can cook more spaghetti of course.. I am not really sure. I would vote for the PHP if there was someone to look after the code. In that sense Tom's perl thing looks more easy to work with, but we'd need docs - and it will be harder to expand should we need to add some new functionality, unless Tom is around to do it. And this was what we wanted to avoid in the first place. Anyway. See you in a while :-) Tuomas -- .. | Tuomas Kuosmanen | Ximian | Art Director | | [EMAIL PROTECTED] | www.ximian.com | `' ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: SUBSCRIBE GIMP RICK ROSS
On Sat, 26 May 2001, Guillermo S. Romero / Familia Romero wrote: > [EMAIL PROTECTED] (2001-05-26 at 0910.30 +0300): > > BTW, the mailing-list page on www.gimp.org still has Ezmlm-ish > > instructions. Is it still relevant to mailman? > > Try sending a mail to [EMAIL PROTECTED] > with subject (or body) "help". You can do near everything with that > mail address (except request resend password, IIRC). > I did not ask you what I should do, as I'm already subscribed to the mailing-list. What I do wish to know is whether the information on the web-pages is still pertinent. If it's not, than one of the webmasters should modify it. Regards, Shlomi Fish > GSR > > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer > -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] A more experienced programmer does not make less bugs. He just realizes what went wrong more quickly. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: SUBSCRIBE GIMP RICK ROSS
Shlomi Fish wrote: > What I do wish to know is whether the information on the > web-pages is still pertinent. It is not. ezmlm has been retired. www.gimp.org is not current. > If it's not, than one of the webmasters > should modify it. Capital idea. But since the former webmaster, Adrian Likins, announced some time ago that his personal/family/business responsibilities has grown to a degree that he cannot web master www.gimp.org, the site has suffered from bit-rot, of which this is only one example. We don't have multiple webmasters. We don't even have one -- just emergency (and insufficient) maintenance from time to time. Web site maintenance is clearly a team effort; it shouldn't befall the lot of one person. See recent threads "The GIMP Webpage", "New GIMP Webpage the 2nd", "GIMP website project planning" and related threads -- and consider helping if time and interest permits (Thank you in Advance). be good, be well Garry ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP website project planning
Tom Rathborne wrote: > So. Here we go: > > I'd like to nominate Carol Spears <[EMAIL PROTECTED]> to the > position of coordinator. She seems really determined to help us > all sort this out, and she doesn't know enough about anything to > have a too-strong opinion. Yes, that's a complement, Carol Indeed it is. Good staff have passions; managers have projects. Both mindsets are very important for an effort to succeed. On a related front, one individual at least has posted a web site shortcoming as a GIMP bug in bugzilla. See http://bugzilla.gnome.org/show_bug.cgi?id=55109. I'll be happy (scratch that: "content") to inventory others and document them in bugzilla, where they can be tracked. Objections? Should "Gimp Web" be a tracking project separate from "Gimp" the program? Be good, be well Garry ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: SUBSCRIBE GIMP RICK ROSS
[EMAIL PROTECTED] (2001-05-27 at 1206.08 +0300): > > Try sending a mail to [EMAIL PROTECTED] > I did not ask you what I should do, as I'm already subscribed to the My point is that you do and check if the methods are compatible. I dunno if new and old software use similar commands. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP website project planning
On 27 May, Garry R. Osgood wrote: > I'll be happy (scratch that: "content") to inventory others and > document them in bugzilla, where they can be tracked. > Objections? Great idea. > Should "Gimp Web" be a tracking project separate from "Gimp" the > program? I'd say that a website for an opensource program strongly belongs to the program itself but if people want to have a issuetracking system to track bugs/ideas/tasks then I'd rather create an own component "www.gimp.org" or "GIMP website" for it then leaving it in "General". Tell me whatever option you desire and I'll take care of it. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Scheme style, draft 1
Hi:
I read the elisp rules as inspiration, and here is what I think we
should do with Scheme scripts, comments / doubts with []:
- use prefixes for your own functions, so you avoid problems. [does
Gimp's Scheme provide "encapsulation"? if not, this is a must]
- indent in Emacs style, with spaces instead of tabs. [maybe we should
provide pointers to indent apps that do it, not everybody has Emacs.
Also instructions for common editor, like vim]
- put "(" & ")" in the same line that "text", not alone in other
lines.
- cut lines that are longer than 80. [70?]
- write documentation strings, so the PDB can show something. And
something useful, not "no info yet".
- for comments use ";" (right), ";;" (code level), ";;;" (left) and
"" (left, separate areas of file).
- first line of files ";;; filename --- one line description".
- one blank line, and third ";; Copyright (C) the owner" (the script
owner(s), not the Gimp owner).
- license, with the blank lines as separation.
- another blank line, and headers like ";; header: content". See
http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_657.html
for the list. [put here the list]
- end files with ";;; filename ends here"
- do not add "Copyright" to the copyright field in the register
function, it look weird to see "Copyright: Copyright (C) owner".
- the path, if the script launchs a dialog, must end with "...", if
automatic action, do not put "...". [people complain about UI, no? so
start applying this basic concept]
- data format as -mm-dd. Fill with "x" if unknown (2001-05-xx),
but only if applicable (Copyright is , not -xx-xx).
- add "_" before strings, so can they be translated.
- provide nice ranges for variables, all that will work, not more (it
could cause errors), not less (just cos the effect looks weird too
big, does not mean it can not be used as base for other thing).
- provide sane defaults, at least for normal uses. Take the common
cases and apply the script. If a script to remove red eyes look poor
when you try to remove the red of a car, it is fine, but not if the
input are faces, and all them "fail".
- use "foo" string for logos. [which string? logo name? "the gimp"?]
- use constant names when you call plugins, not numbers, if they exist
(DISCARD is better than 1). Look script-fu-constants.c for them.
[include a list?]
Make a pointer to elisp doc, so we give credit about inspiration.
Explain why, so everyone knows it (the draft is too short). Put it in
CVS and Gimp site (aka this can be one of the test docs for the new
system).
I am not a Scheme guru at all, so I guess I have put something stupid
or miss a basic item. I would like to see comments from Scheme people,
or lisp users in general.
Fixes? Changes? Who decides?
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Scheme style, draft 1
On Sun, 27 May 2001, Guillermo S. Romero / Familia Romero wrote:
> Hi:
>
> I read the elisp rules as inspiration, and here is what I think we
> should do with Scheme scripts, comments / doubts with []:
>
> - use prefixes for your own functions, so you avoid problems. [does
> Gimp's Scheme provide "encapsulation"? if not, this is a must]
>
Actually, I believe every Gimp-Fu script is encapsulated but I'm not sure.
In any case, using prefixes is a good idea.
> - indent in Emacs style, with spaces instead of tabs. [maybe we should
> provide pointers to indent apps that do it, not everybody has Emacs.
> Also instructions for common editor, like vim]
>
I use spaces to indent, because that's how I configured my editor (gvim).
However, some other users may use tabs, and I don't see anything wrong
with that.
> - put "(" & ")" in the same line that "text", not alone in other
> lines.
>
I personally dislike the usual:
(define (myfunc a)
(if (> a 0)
(sqrt a)
(sqrt (- 0 a
style which puts all the ")"'s on the last line. I prefer C-like style
like that:
(define (myfunc a)
(if (> a 0)
(sqrt a)
(sqrt (- 0 a))
)
)
I once sent a message to a mailing-list, I'm a member of, asking why the
Scheme style was not indeed so. The reply I received did not convince me
that it was a good idea. You can find it at:
http://groups.yahoo.com/group/hackers-il/message/500
> - cut lines that are longer than 80. [70?]
>
I normally indent even expressions. For instance, the pythagoras theorem
becomes:
(sqrt
(+
(* a a)
(* b b)
)
)
In any case, if your lines get too long, one should probably out-source
part of the code as a different function. Most Script-Fu scripts are
almost completely linear so it's not a very big concern.
> - write documentation strings, so the PDB can show something. And
> something useful, not "no info yet".
>
This is a good idea. I believe I followed it for my "Bugs in a square"
script. Check:
http://t2.technion.ac.il/~shlomif/MathVentures/bug_square.html
Do you want not to accept scripts that do not follow this regulation?
> - for comments use ";" (right), ";;" (code level), ";;;" (left) and
> "" (left, separate areas of file).
>
> - first line of files ";;; filename --- one line description".
>
> - one blank line, and third ";; Copyright (C) the owner" (the script
> owner(s), not the Gimp owner).
>
> - license, with the blank lines as separation.
>
> - another blank line, and headers like ";; header: content". See
> http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_657.html
> for the list. [put here the list]
>
> - end files with ";;; filename ends here"
>
> - do not add "Copyright" to the copyright field in the register
> function, it look weird to see "Copyright: Copyright (C) owner".
>
> - the path, if the script launchs a dialog, must end with "...", if
> automatic action, do not put "...". [people complain about UI, no? so
> start applying this basic concept]
>
> - data format as -mm-dd. Fill with "x" if unknown (2001-05-xx),
> but only if applicable (Copyright is , not -xx-xx).
>
> - add "_" before strings, so can they be translated.
>
> - provide nice ranges for variables, all that will work, not more (it
> could cause errors), not less (just cos the effect looks weird too
> big, does not mean it can not be used as base for other thing).
>
> - provide sane defaults, at least for normal uses. Take the common
> cases and apply the script. If a script to remove red eyes look poor
> when you try to remove the red of a car, it is fine, but not if the
> input are faces, and all them "fail".
>
> - use "foo" string for logos. [which string? logo name? "the gimp"?]
>
I'd rather people each used the string of each choice. It adds to the
scripts' colour. (I really like Bovination's "Fear the Cow")
> - use constant names when you call plugins, not numbers, if they exist
> (DISCARD is better than 1). Look script-fu-constants.c for them.
> [include a list?]
>
A must I believe, because they may change in future version.
> Make a pointer to elisp doc, so we give credit about inspiration.
> Explain why, so everyone knows it (the draft is too short). Put it in
> CVS and Gimp site (aka this can be one of the test docs for the new
> system).
>
> I am not a Scheme guru at all, so I guess I have put something stupid
> or miss a basic item. I would like to see comments from Scheme people,
> or lisp users in general.
>
Script-Fu has the advantage of being easier to compile than the other
scripting interfaces. However, for most practical reasons, I believe I
would prefer scripting with perl, because I can do everything perl does in
Gimp-Perl scripts. (files, sockets, CPAN modules and all)
Script-Fu uses SIOD, which is not an R4RS compatible Scheme
implementation. (For instance, "set!" can create a new variable). Does
anybod
