Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

Dear Dave!

Sorry if this message appears somewhere outside the original thread - I could 
not figure out how to use the list properly, although I really tried this 
time.

>
> Anyway - people kind of missed the whole point of me sending that to the
> list... this person mailed me off-list because he saw me as someone "safe"
> to talk to. That's not a nice way to have things on our mailing list. What
> can we do to change that?

As a first step, you could treat private mails as such. For me, this would 
have been enough.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

Again, I am copying the response I sent to Carol a few moments ago verbatim.

--



Dear Carol!

>
> i have looked at the adobe photoshop web site perhaps 4 times.  for
> information to help my friend run her photoshop le.

Meanwhile, I have tried too, and it was indeed a bit hard to get to 
screenshots.

> can you just explain what the differences are and what should matter to
> us?

Yeah, they show no naked persons, just as I expected. In contrast, the Gimp 
site was doing so until recently. Fortunately, this has now changed.

Best regards,
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

Hello, I noticed this moment that Carol wrote this also to the mailing list. 
Please excuse the confusion, but until recently, it was not necessary for me 
to be subscribed to the list, so I'm not sure if this mail is attached to the 
right thread.

I am copying the reply that I wrote to Carol verbatim - it is a pretty safe 
bet to assume that if I had written the response to be read by all list 
members, I would have phrased many things of the initial post differently.

This mail hopefully also sheds some light on what I meant with "safe".

--



Dear Carol!

Thank you for your message.

> i dont blame people for being intimidated.

When I said it would be "safe" to ask Dave, I meant he very probably would not 
come up with the "don't ask me, I'm a developer"-argument that one can 
(rightfully) expect from a developer. I understand very well the difference 
between developing and FAQ and documentation teams. It is just that the only 
list I follow is the developer list, and David seemed to belong at least with 
one leg (if not with two) to the documentation team too, so it seemed natural 
for me to approach him instead of, say, Sven.

I understand also that my issues have nothing to do with Gimp development, and 
THEREFORE I did not send them to the list myself.


> okay, a few more than three steps, but this has not failed to work since
> gimp-1.0 and the options have never moved.

Thank you.


> what i saw when i saw the photo of this baby was a dork who had a good
> relationship with a beautiful woman.  those are the images i saw and the
> man i came to know while working on gimp development.

Apparently, Dave has understood my point and has taken the photo off the web. 
That was in my opinion the only correct behaviour. I think we can agree that 
we would not show a naked woman in a Gimp advertisement, even if it is 
perfectly natural. So why would you show a naked baby? I think one should not 
do this. On a side note, displaying a static photograph does not do justice 
to the Gimp's functionaliy either. I can use kview for that. Let us both have 
a look at Adobe's screenshot section of photoshop. I bet they are pretty 
proud to show off with features and stuff that their PRODUCT is able to 
provide.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

OK, and this is another reply I had meanwhile sent (to Sven, in this case), 
and I hope the mailing list agent will know where it fits in - apparently 
some parsing of the quoted text is done to make sure that the thread 
hierarchy is maintained.

Sorry if this is getting a bit redundant, but I hope I have now made my point 
clear.

Best regards,
Markus Triska.

---


> It's ridiculous to say that putting such a picture on the internet will
> cause children to be abused

For the record, I want to note that I did not say that, as you seem to imply 
in your reply.

> The picture is in no way offensive and anyone who draws a relation to the 
> Dutroux tragedy is either sick himself or overly cautious.

I think we can agree that most of us rather would not have a screen-shot of an 
adult woman or man, half-naked like this, in the screen-shots section, albeit 
professional models who get paid for their job. I do not know why you make a 
difference for children. If I had not mailed Dave, how long would the photo 
still be around? Maybe his children will be thankful some day, when they 
understand what was going on, that not everyone has a photo of them with no 
clothes on.

Given that Dave seems to have understood my point and removed the picture, I 
consider the issue resolved.

I want to thank you again for your efforts. As far as I can tell, you are 
doing a great job.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

> Do you have problems with posting to the list in general (because there is
> someone or something you cinsider "unsafe") or just because of the rather
> difficult topic?

No, as I outlined in a previous mail, I used "safe" solely to indicate that I 
assumed Dave would have no objections to be asked about some apparently 
simple usability issue (where, in contrast, a "normal" developer could have - 
rightfully - pointed me to some other place). I deducted this from all the 
posts in which Dave stated that developers should also answer questions, and 
that he himself in fact did and had done so.

I can only emphasize again that I know very well the difference between a 
development and a FAQ and documentation team, and I would never have molested 
Dave with my question were it not for him pointing out that he had no problem 
with that and in a sense "begging" for mail.

It certainly has nothing to do with the mailing list (this is only how I came 
to "know" Dave). If Dave would not exist, or would not post such things to 
the developer's list, I would have sent the question to some person working 
on the Wiki, or to the Gimp-User-mailing list, or somewhere else, but never 
to this place (which I, in fact, have not).

It just happens that the developer's list is the only one I follow, and thus 
it seemed natural for me to contact Dave, and the quickest way to get a 
useful reply.

I did not know that it would turn out this complicated and chaotic. I am sorry 
that I have caused you so much trouble and confusion.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

>
> Because that's apples to bananas. Naked woman are sexually attractive to
> normal people. and babies are not.(*)

This obviously can not be the primary reason why we would not show naked 
women. The reason, as I understand it, is that the depicted persons easily 
lose their dignity when they are shown naked. That would be a different thing 
for an artistic, professional picture. For example, I can remember an 
advertisment of an afro-american, muscular man, naked, holding a white, naked 
baby. I have no problem with that, and it would make an excellent 
screen-shot, if not particularly useful to point out Gimp's features (which 
you should strive to accomplish). Having a poorly lit, amateur photograph 
showing a naked child that was presumably just having a bath is to my mind a 
different story.

As I stated in a previous mail, If I had not mailed Dave, how long would the 
photo still have been around? Maybe his children will be thankful some day, 
when they understand what was going on, that not everyone has a photo of them 
with no clothes on.

We need not delve further into those subjects (although I notice that you 
raise interesting points), because Dave has decided to take the photo off the 
web. I think that was a good move, and I'm done with that.

> Hinting that babies are objects of sexual desire is becoming more and
> more commonplace nowadays, in certain cultures at least (mostly, but not
> limited to, the us). I do not believe that this is a good direction.

I live outside the US, and the first thing coming to my mind when I saw the 
photo was the alleged criminal. I had no choice of what I wanted to come to 
my mind, so it was this, of which all newspapers here tell these days. I 
think that it is unreasonable to assume I am the only person who reacted this 
way. If I had known that Dave would forward my mail to the list, I would have 
thought of other reasons that people outside Europe could easily follow. 
Apparently, Dave could.


> I think this is what Sven wanted to hint at with his comment (that such
> people were sick). It is not the right thing to do to make yourself a
> slave of this "babies are sexually attractive" thinking, which is, as you
> hopefully agree, not normal. If you don't, then photos of babies are just
> that, and should evoke feelings of joy, especially for the parents :=>

Yes, absolutely. And on a side note, I wish Dave the best for his son and 
everything, and hope he makes many pictures of him to keep, and to show him 
later. But he does not have to place those in the Gimp screen shots section, 
that's it.

> I voiced my opinion on this mainly to not leave Dave in a kind of limbo,
> as if he did something wrong. What he did was not wrong at all.

Again, I have to point out that I never intended to send the mail that Dave 
quoted to the list - I only thought that he would understand the issues I 
raised, and right I was.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

Dear Carol!

> this is the part where you get embarrassed about the weird forwarding
> and spamming.

I am sorry for the inconvenience that I am causing you all as a new user of 
the mailing list (and, indeed, ANY mailing list).

When I answered your mail, I did not know that you had also sent it to the 
list, because I did not look at the mail addresses it was coming from, 
clicked "Reply" (instead of "Reply all"), and the result was that only you 
received my answer.

When I found out that you posted that on the list, I forwarded the mail to the 
list, too. I see nothing "weird" about this, and I have a different idea of 
"spamming". The result would have been approximately the same if I had used 
the CC feature.

> i am curious as to what news markus follows and software he uses and
> plug-ins that came with the software.  what country and the over all
> ideas of his teachers and parents.

Maybe in 50 years from now, you can buy my biography if you are interested, 
which will perhaps contain a time-line of how my habits and opinions changed 
over time. By now, I have no intention to make my habits public. I think you 
will understand that I will not publicly announce the ideas of my teachers, 
relatives and other persons I am associated with (even if they are or were 
not alive any more, and even if they do or would coincide with my own), for 
several reasons, the simplest maybe being that they are nobody else's 
business. About the only hint about the programs I use that I ever gave in a 
program documentation was that I used SUSE Linux, and even that has changed 
by now, so in hindsight, this information was of no use to anyone, and I 
don't see the point.

Of course, if you are interested in how I can accomplish this and that with 
some programs, maybe I can help you. In fact, I will maybe write a tutorial 
for the Gimp in the future, because I think I have achieved now some skill in 
the area of photo enhancing.

> i just see a different image totally.  is it software?  is it because i
> try to have no interest in seeing bad things (unless i have a solution)?
> is it because i am a product of the evil american culture that i cannot
> see anything bad about this image?
>
> while i appreciate someone else being the new person to really abuse the
> mail lists (try cc and one time multiple mailings). ((check to see if it
> is sent to the list or not)).  (((forgive me when i screw up, sometimes
> -- all i get is mail list mail))) and send the email carefully. more
> carefully than me.
>

I do think that I send mail carefully. Do not assume that the possibility that 
the boy was Dave's child had not occurred to me before. However, I see no 
reason why this should change anything, except maybe giving hints to the 
explanation of Dave's reaction, and maybe not. I would have sent my mail to 
Dave also if it was not his boy, but for example my own daughter or son. 

> i am so confused about the problem with the image.

You do not have to be confused any more, the pic you are talking about is 
gone. If I had known that my initial mail to Dave would appear on the list, 
too, I would have phrased it differently so that everyone can follow my 
reasons. Given that I wanted to mail Dave directly, whose mind and thoughts I 
knew a bit from the mailing list, I formulated it as I saw fit to make myself 
understood by HIM, not by anyone else. As I see it, my mail was enough for 
him to make him understand what I wanted to communicate.

That having said, I want to end now this discussion which I did not want to 
happen and would not have started myself in the first place. This is the Gimp 
developer list, not a psychotherapy session.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Baby photos (was: Gimp 2.0)

[Markus Triska]

Dear Branko!

> Dave:
> + when I read this mail, I got defensive a bit - the thought 
> + that someone thought the photo could be viewed sexually kind 
> + of turned my stomach. So I took it down.
> 
> In other words, it's not your point, but the fact that you raised it, 
> that you could think of such a gruesome thing, that made Dave take 
> the picture down.

As I stated before, the "gruesome thing" you mention was not as far fetched as 
you seem to imply, if you follow European news these days. I hope that 
neither Dave nor you nor anyone else thinks that I *myself* found the picture 
arousing, and don't ever half-accuse me of this again.

My intention was exactly to bring to Dave's attention that there could be 
people that think of it that way, and I think that this was exactly what made 
Dave take the picture down, so I don't understand how you can say it was not 
"my point" that had this effect.


Unfortunately, there is no long-term hiding in religion nor is it safe to stay 
in your "dark ages". Abusing children for disgusting pictures IS a problem 
today, which we can not neglect or deny, and saying that children are without 
sin certainly does not improve the situation or makes abusers go away, even 
if it is or were true.

Reading all the mails that I have received in private today, I conjecture that 
I was not the only person feeling that there was something wrong to show the 
picture as it was, even if they do not stand up and say it in public.

> Your morals have nothing to do with it; if they 
> had, Dave would probably not have taken the picture in the first 
> place, let alone posted it.

This might or may not be true, I do not know. I can imagine parents that think 
of their children as so natural and lovely that they really don't think about 
such issues, unless they are told to do so. Also, you did not quote Dave's 
words that immediately preceded your quote, which I consider essential to his 
message:

"... I didn't think of any negative connotations, but indeed I wasn't thinking 
"that way". 

I can only again point out that if I had known that Dave would forward my 
initial mail to a public mailing list, I would have come up with different 
reasons and phrasing. The mail was intended to be read by Dave, not you, nor 
anyone else.

All in all, I don't know what you want from me by writing such a post to the 
list. You think I am abusing children? No, I don't. That I found the picture 
arousing? No, I did not. You think I should not have mailed Dave? None of 
your business. You think the picture should stay? Go make a picture of 
yourself, naked, and put it on the list, but keep your children safe. Dave 
has decided to replace the picture with something more neutral, and I think 
that was OK.


Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp 2.0

[Markus Triska]

Dear Carol!

> i dunno.  he got everything he asked for.  it did not even make sense to
> me and he got it.

Oh yeah, and I got so much more too, thank you very much. 

> this human being should be on the gimp users list.  it is polite and
> nice there.  
> 
> i have a bad opinion of someone who so easily gets to change things on
> an established list.  if you want a friendly mail list about gimp,
> gimp-user list totally fullfills this.  
> 
> is this person with the smutty mind a developer?

Carol, maybe the hint I provided before was to weak for you to notice. I did 
not expect *you* to understand my points. That is why I mailed Dave, and not 
you, and he did.

I am sorry that you have a bad opinion about me, and that maybe you think I 
have a "smutty mind". Maybe if I had mailed Dave at a different point in 
time, catching him in a different mood, things would have turned up more 
brightly. I am very sad that I get to know you all when you are accusing me 
of the worst things one can think of.

Again, I apologize for all the inconvenience and chaos that my private mail to 
Dave has caused.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Baby photos (was: Gimp 2.0)

[Markus Triska]

Dear Simon!


> You have not yet explained what exactly makes you think of Dutroux
> when looking at the Photo and what exactly you think has been gained by
> removing that image in that context. The Dutroux connection is
> especially important, since this is a typical "Totschlagargument" [1]

It rather was the other way around. Only because I continuously read and hear 
about this alleged criminal on the media did I think about this context when 
looking at the photo. You can take that remark out of my initial mail, and 
the point it raised would still be valid.

> 
> In all of your mails you kept the distinction between these three issues
> blurry and unless you try to keep these issues separate and calmly argue
> about this every further discussion is pointless.
> 

I have no interest in explaining my point of view to each and every individual 
on this list in detail until they all get it, also because many of them have 
apparently already decided that they never will, and also because I do not 
know you at all.

I think that the persons here either are getting my opinion right from the 
start, or they won't ever. I sent word to Dave privately because I somehow 
knew he would be of the first type, and this is why I chose him, and not 
anyone else. I would never have sent this to the list myself, nor to any 
other person from the list, because I knew it would be asking for trouble.

This is perhaps also due to the fact that only those persons that can NOT 
follow my arguments write here again and again, while the persons that share 
my opinion do not stand up publicly, but keep sending me private mails with 
the notice that I must not forward them to the list under any circumstances, 
as if this was the only thing I have in mind, or if I had ever done so.


As I stated in an earlier message, Dave has now removed the photograph in 
question, and I consider the issue resolved. I therefore have no interest to 
explain my point of view any deeper. Maybe Dave can explain to you why he did 
so, and you can then try convincing him that he put the picture back, if this 
is what you want, but please keep me out of that.

Best regards,
Markus Triska.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Baby photos (was: Gimp 2.0)

[Markus Triska]

> I can think of a lot of reasons for Dave to a) remove the image and b)
> keep the image removed. This discussion being the first one (even
> without considering the positions exchanged [1]). I certainly won't ask
> him to put it up again because this is of no vital interest to me.

I know that it was me who triggered that. Why can't you believe this? I hope 
Dave will clarify this on the list so that you can take it for granted.

> What a pity. This could have been an interesting discussion.

One of the reasons that I will not "discuss" this with you is that I feel you 
are more interested in "discussing" per se than what happens to the baby and 
the photo. "Discussing" is of no interest to me with regards to this picture. 
I felt it should not be on the site, for the baby's sake, and Dave felt so, 
too. There is no way for me to make you feel so, too, because you are so 
attached to the wording I choose, and to the structure of my arguments. To 
convince Dave, I needed no arguments, and no structure, but a short message 
sufficed. That Dave removed his own picture should be enough argument for 
you.

This is not "getting too hot" for me, but I consider it a waste of time to 
"discuss" with persons of your mindset. I knew that Dave would not be that 
kind of person, and that is why I mailed him privately. I never wanted to 
"discuss" this on the Gimp developer's list. All I can do know is not defend 
myself, but to clarify the wording of the private mail I sent to Dave for all 
you others, who never were intended to see it.

Best regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] RE: Gimp-developer Digest, Vol 19, Issue 24

[Markus Triska]

> This is news to me! where did Jesus say that?

He might be refering to Luke 18, 15-17.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Baby photos (was: Gimp 2.0)

[Markus Triska]

Dear Marc,

> Please consider that millions of people have heard about this case on TV,
> but so far you are the only person who thinks of this case when looking
> at baby pictures (there is no connection to babies in the dutroux case at
> all...), at least the only person on this list, while many others have
> made it clear to you that they don't think in tis strange way, including
> Dave.

I did not talk about "baby pictures", but about the particular picture that 
was in the screen-shots section. I have asked Dave if he had any other 
pictures of his (dressed) son available, and I offered my help in improving 
the photographs as best as I can.

Also, I have proof that I am not the only person that considered it a bad idea 
to have a picture of an apparently naked, wet child in the screen-shots 
section of a program that is used not only in the US or Europe, but 
world-wide. I want to remind you that there are countries on this world that 
consider an unveiled woman offensive, let alone a naked woman, or child, and 
not everyone will post his thoughts about this matter on the list, perhaps 
mainly due to language differences, and neither would have I, because this is 
not a technical matter that you can "discuss", like say, if we would use C++ 
or some higher level language for the Gimp core code, or when we should get 
rid of deprecated Gtk implementations. Those are the things that you can 
"discuss", because they are intellectually, not emotionally justifiable, and 
do not depend on your culture. Also, there is no "choosing a side", or 
changing your mind by arguments in this issue, as Simon said, and this is why 
I mailed Dave, not you, and not to this list, because I expected he would 
understand my opinion immediately.

> What's also not normal is that you continously insist that you know that
> Dave removed the picture because he follows your reasoning, despite there
> is evidence to the contrary.

Dave clearly stated that he took away the picture as a direct consequence of 
my mail. In his own words: "this discussion (or rather, the original mail) 
made me see a popular website's place in the internet slightly differently". 
He has no problem with baby photos, and neither have I, but you might 
understand that there is some kind of strong correlation between my mail and 
him taking the picture away, or you are the one who is trolling.

> At the moment, you are just trolling, nothing more. And you surely know
> that and still go on with your abuse of this case, which is probably the
> reason why so many people on this list are upset. Shame on you.

I again apologize for all the confusion and trouble I have caused on this 
list, please forgive me. I never meant to send my thoughts about the picture 
to a developer's list. Also, I have clearly stated in an earlier message that 
I want to end now this discussion that I did not want to start in the first 
place, and especially not on this place. It is posts like yours that keep the 
words rolling, because they attack me personally, saying I am "not normal", 
have "a smutty mind", or accusing me of other things, like "trolling" or 
"abusing". You might understand that I can not let that stand as it is.

Regards,
Markus Triska.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: c++ with plugin-template

[Markus Triska]

Christoph Lutz wrote:

> As I didn't know how to set up all the automake/autoconfigure-stuff, I 
> temporary simply changed the  CC-Variable in the  /src/Makefile, 
> but this is insufficient, I guess... Could you please give me some 
> hints, how to change the compiler in the plugin-templates 
> configure/automake-files, so that I could pack and release my plugin?
>

The key file here is configure.in. It contains the line

AC_PROG_CC

which will make the (resulting) "configure" script search for a C compiler. 
gcc is indeed the C compiler (dispite the somewhat misleading name), while 
the C++ compiler is called "g++".

I have recently worked with the gimp-plugin-template myself and found it quite 
useful, so feel free to e-mail me if you have questions, or take a look at 
the "magiceye" plug-in (in the registry) to see how I have done it.

Best regards,
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: c++ with plugin-template

[Markus Triska]

On Thursday 01 July 2004 12:23 am, you wrote:
>
> Right. If a C++ compiler is supposed to be used, you will have to use
> AC_PROG_CXX. See also
>

While we are at it: I noticed that configure.in lacks the typical

AC_LANG_C

line often used in conjunction with AC_PROG_CC to perform additional tests of 
the C compiler. Adding it might cause autoconf to work around some obscure 
errors of broken compilers (perhaps broken optimizations etc.).

Best regards,
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Script-Fu

[Markus Triska]

Hello,

I am currently working on a script-fu to provide previews of the more popular 
plug-ins with varying parameters. The script takes a list of images 
(blur.png, iir.png, rle.png, despeckle.png etc.), applies the respective 
plug-in with varying parameters and writes blur1.png, blur2.png, ..., 
blur(n).png,  iir1.png, iir2.png, ..., iir(m).png etc., along with a file 
that records which filter/parameters were used for which image, for example:

blur1.png: filter Blur Percent 20 Count 5
blur2.png: filter Blur Percent 40 Count 10
...
iir1.png: filter "Gaussian Blur (IIR)" Radius 3 Horizontal 7 Vertical 5
...
edge.png: filter Edge Amount 2 "Wrap Mode" SMEAR Algorithm Differential

The thing is: The "print" command ("(print "test")" ) is not working for me in 
batch-mode (Gimp 2.0.2). It does what it should on the Script-FU console, but 
shows no output when used like

gimp -c -i -d -b '(filter-previews)' '(gimp-quit 0)'

A more simple case: When I create this file ("testprint.scm") in 
~/gimp-2.0/script/:

(define (testprint)
(print "this is a test"))

and invoke

gimp -c -i -d -b '(testprint)' '(gimp-quit 0)'

I get:

batch command: executed successfully.

(and nothing else)

Is this a bug?

Another question: Can I - in Gimp-scheme - define the C-equivalent to 
variables declared "static" (at global, not procedural, level), that is, 
variables that are global (i.e., visible in all procedures), but only in a 
particular file?

If not, can I declare variables that are *global*? How?

I need this for the mapping of filters <---> respective input-files, for 
example, I could use this:

file_for_blur:  blur.png
file_for_iir: iir.png

I know that I can always use "define", like

(define (blur-file) (set! return "blur.png"))

but that would not (really?) allow constructs like:

file_for_blur: blur.png
file_for_blur: blur_changed_my_mind_use_this_instead_but_keep_other_too.png
file_for_blur: use_yet_another.png

that is, set the variable to a different value on the fly (without the need to 
comment out anything).

Moreover, does there exist reference documentation for basic Gimp-Scheme 
things (tutorials aside), like string-append etc.? Some standard 
Lisp-functions don't seem to be implemented ("nth" for example) Should I add 
some? Which ones?

Markus.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Script-Fu

[Markus Triska]

> > (define (blur-file) (set! return "blur.png"))
> >
> > but that would not (really?) allow constructs like:
> >
> > file_for_blur: blur.png
> > file_for_blur:
> > blur_changed_my_mind_use_this_instead_but_keep_other_too.png
> > file_for_blur: use_yet_another.png
>
> You mean like (define blur-file "blur.png")?

Yes exactly - I do not know how this would turn out in Gimp-Scheme (and 
especially of course in versions to come):

(define blur-file "blur.png")
(define blur-file "otherblur.png")

Different versions of Scheme handle this differently. I do not know if this is 
proper Gimp-scheme (re-defining a defined variable), or if one would have to 
use set! for the second definition/assignment. Incidently, no script-fu seems 
to make use of global variables, only of local let* - environments.

Perhaps (define ...) is equivalent to (set! ...) here?

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Script-Fu

[Markus Triska]

> I don't know "officially", but it seems that with any definition of
> define, you can define it first, and then set! it everywhere else.  Even
> if your first define is
>
> (define blur-file '())

Yes, and what's more, one can also use set! alone (without a preceding 
"define"). I do not know if this is common practice in Scheme implementations 
nor if this will change when switching to Guile.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP

[Markus Triska]

You wrote:

> Tiny-Fu is a plug-in for the 2.1 (and later) series of the 
> GIMP. It is essentially a modified version of the 
> Script-Fu plug-in but with some major differences. The main difference is 
> in the Scheme interpreter being used.

TinyScheme does not support arrays at the moment - do you plan to implement 
this feature (i.e., fork TinyScheme), or is such a feature planned by the 
TinyScheme developers?

Otherwise, I can convert scripts that are currently using arrays to use lists 
instead if you have not already done so.

Best regards,
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP

[Markus Triska]

> I have no objections if you would like to update some of the scripts which
> use arrays. I would suggest you contact me before hand so I can provide a
> list of the scripts which need to be updated to avoid duplicating work.  

These scripts (included with 2.0) currently use arrays:

addborder.scm
alien-glow-arrow.scm
beveled-pattern-arrow.scm
blend-anim.scm
chrome-it.scm
copy-visible.scm
crystal-logo.scm
grid-system.scm
hsv-graph.scm
line-nova.scm
neon-logo.scm
sota-chrome-logo.scm
spyrogimp.scm

Are any of them already ported? If not, I will change them to not use arrays. 

Best regards,
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP

[Markus Triska]

> Are any of them already ported? If not, I will change them to not use
> arrays.

Well, at least the trivial cases (where the arrays are used only inside the 
script) - there are some PDB functions that use arrays as arguments or as 
return values, and I don't know what to do with them, for example 
gimp-cursves-spline and gimp-image-get-layers.

There seems to be some correlation between arrays and lists in the PDB, but 
not too much. Am I right in assuming that a PDB STRINGARRAY is equivalent to 
a (Scheme) list in Script-Fu? This seems to be handled differently for 
INTARRAY, which remains a (nonstandard) Scheme-array. So what it comes 
down to is: How do I convert a PDB's array (of integers) to a Scheme list in 
a script and vice versa?

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

[Markus Triska]

> >Are you sure using lists instead of vectors is the right thing to do?
> > Lists are linked lists and as such accessing the i'th element is O(i). In
> > vectors it is O(1). This can cause an order of complexity increase in
> > handling them.

This is true, but not much of a problem, since most scripts only use either 
the first 1 or 2 elements of arrays or work on typically very short arrays, 
or want to pass a (short) array to PDB, where there is no difference between 
list-construction and setting every element of a vector explicitly (the 
latter possibly being even more inefficient).

> No, I'm not sure. For the few scripts I looked at (and for ease of
> implementation), using a list was the easier route to have something
> functional during the early development stages. Using vectors instead of a
> simple list would mean the ability to use functions which would provide
> rough equivalents to the SIOD interpreters array manipulation functions.

As I understand it, there are even *exact* equivalents to the current "array" 
type. No wonder, since a Lisp vector is a special case of an array 
(one-dimensional). In Script-Fu, "arrays" are indeed vectors.

> I will take a closer look at using vectors. It will simplify the work
> needed to update old Script-Fu scripts for use with Tiny-Fu. I will start
> by converting between list and vector. If the approach works well, I will
> bit the bullet and update the marshalling code to use vectors for the
> *ARRAY types.

I also opt for vector because apart from being the natural Scheme equivalent 
to PDB's one-dimensional arrays, it makes writing plug-ins easier for people 
that have no to little practice in converting common "for/while" loops using 
tail-recursion, and current scripts would work practically unmodified, 
without explicit conversions list->vector that would only cost time (with 
everybody ending up calling these instead of working on lists most of the 
time).

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

[Markus Triska]

> By using vectors I was able to very quickly update the portion of those
> scripts which used SIOD array functions. I have not changed the Tiny-Fu
> marshalling code yet but I will do that soon and release a new tarball.

Now since there is essentially a one-to-one correspondence between Tiny-Fu's 
vectors and Script-Fu's "arrays", it might be worth considering adding 
compatibility definitions to "init.scm" (similar to gimpcompat.h for 
plug-ins), that would, depending on a certain "compatibility"-switch in a 
configuration file (or in "init.scm" itself, but I don't know if every user 
will get a copy or you will install the file in /usr/gimpsomething...), 
"define " the current array operations and map them to corresponding 
vector functions. You could then (depending on said switch) also re-define 
set! to use "define" if a variable is not "defined?".


Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

[Markus Triska]

> The solution is to add a line to the let block with the
> name of the variable in parenthesis (no initial value is required). A few
> of the standard Script-Fu scripts had a define that used set! but no let
> statement so a let had to be added first. I don't see how this can be
> handled automatically without a change to TinyScheme itself.

I have explained this above - re-define "set!" to use the TinyScheme 
"defined?" command to see if a variable is already defined, and if this is 
not the case, define it.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp 2.0.2 and elusive detachable "tear-ablemenus"

[Markus Triska]

> I guess that if no one else has this problem, it is a kde problem.

That would also be my guess. I've been using Gimp with KDE 3.[012] for some 
time, and although I (contrary to you) never ran into anything that I knew 
should work but didn't, there surely were moments that made me doubt the 
cleverness of its focus policy. Gnome 2.6.(2, currently) works better for me 
with regards to that, so I recommend that you give it a shot (if possible) 
and see if the problem remains, to narrow down the range of imagined 
possibilities.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp 2.0.2 and elusive detachable"tear-ablemenus"

[Markus Triska]

On Tuesday 13 July 2004 06:24 am, Joseph Heled wrote:

> Your remark about "focus policy" sent me to the KDE control center - and
> yes, it is a focus problem of sorts. I was running with "focus strictly
> under mouse" (CC/Look & Feel/Window Behavior/Focus). When I Change that to
> "Click to Focus", the menu remains until the window focus is lost. Would
> you do me a favor and see under which policy you run and if you get the
> same problem if you switch to another policy? (actually all you have to do
> is to detach a menu and switch focus by clicking on another window).
>
> Still, the menu disappears after a focus lose and does not return. This can
> be either a KDE bug or GTK bug.

I have now tried both options ("focus strictly under mouse" and "click to 
focus") in KDE 3.2.3 without problems: I can tear off menus and they receive 
focus when under the mouse / I click on them (depending on the setting). They 
do not disappear magically. In short: works perfectly.

I consider it unlikely that we will easily find the exact cause of the problem 
(could be deep inside Qt), and even if we do, the fix could be non-trivial. 
Depending on how much you want working tear-off menus (beside other 
advantages of newer KDE versions), an update of KDE and/or Qt would therefore 
still seem to be the easiest way to fix the problem. For instance (assuming 
the worst possible outcome of an attempted KDE update), backing up my entire 
system and doing a complete re-install would cost me approximately 12 hours, 
maybe more, but not more than 15 hours. I guess that this is still nothing 
compared to locating the problem and fixing it, but I could of course be 
wrong (with both).

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] OSCon attendance

[Markus Triska]

>
> 2. Its main developer (Tom Lord) is desperately in need of cash, as he is
> currently unemployed. (or at least was the last time I checked).

Visit http://gnuarch.org/ for more information. While he is de facto 
unemployed, as you say, he puts it more brightly:
---
Are these "after hours hobby projects" or what? In fact, no -- since early 
2002, these projects are what I do. I don't have a day job that subsidizes 
this work. Although I'm now working on developing some start-up  projects, in 
the meantime...


By the way: Tom Lord is also working on a new implementation of Scheme (Pika 
Scheme), supporting Unicode. Considering that we could use Tom's Pika Scheme 
instead of TinyScheme, and that he can work on Pika Scheme by living on 
donations that come from his Arch project, it follows that Arch is without a 
doubt a proper sub-project of the GIMP. I'm therefore all the more for GIMP 
to win.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Scheme [was Re: [Gimp-developer] OSCon attendance]

[Markus Triska]

On Thursday 15 July 2004 02:25 pm, Shlomi Fish wrote:

> Another implementation of Scheme? Aren't the ones in:
>
> http://www.schemers.org/Documents/FAQ/#implementations
>
> enough? Or isn't any of them better suited as a starting point?

Please ask Tom, not me, because he is doing it, or visit his page for more 
information. His version could have advantages that others lack. Diversity is 
at most very rarely (never?) a drawback. Besides, I hear some people are 
implementing already available software just to see what it is like. There 
surely are thousands of other legitimate reasons why one would implement 
another version of Scheme.


> Do you mean that you're all the more for Arch to win?

No, I did not.

Each of the nominated projects is very good (see Dave's post for some details 
about the GIMP). The Arch - GIMP relation was a joke, if you don't mind. The 
fact remains that Tom's Pika Scheme has Unicode support, which TinyScheme 
lacks, so it could be worth a look.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: Scheme [was Re: [Gimp-developer] OSCon attendance]

[Markus Triska]

On Thursday 15 July 2004 07:12 pm, Shlomi Fish wrote:

> Anyone can go and write another
> editor or bug tracker or window manager, if he'd like. That's one of the
> rights that Liberalism gives you. But if someone wishes to embark on
> something like that I'd advise him to contribute to an existing project
> instead of starting a new one.

You should have told Tom Lord that he better contribute to one of the many 
existing versioning systems *before* he started writing Arch. That had 
probably left GIMP competing solely with Valgrind.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Adaptive Contrast Enhancement

[Markus Triska]

On Friday 16 July 2004 07:31 am, Martin Weber wrote:

> I started to port the plugin Adaptive Contrast Enhancement to GIMP-2.0, but
> because I do not now enough about the internals I was not able to finish
> the port. I think this plugin is very usefull, so is there anyone who could
> have a look at and finish the port. Here you find it:
> http://registry.gimp.org/plugin?id=1438

I once wanted (and still want) to port the plug-in to 2.0 because it was 
requested in comp.graphics.apps.gimp, but I then saw that there are two 
different versions (Alex Stark's and yours). Have you made other changes to 
the plug-in, or did you simply start a port? I'm asking that because people 
might want to use the original ("clean") plug-in if that has become more 
wide-spread than your version, and if they differ significantly. Also, 
porting a not fully functional plug-in is quite useless.

(P.S.: I hope your version DOES differ from the initial version, because what 
I see from the sample shots of ace, the results do not look very impressive.)

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] filetype plug-in to get type of entity (file/directory)

[Markus Triska]

Hi,

this is a trivial plug-in that implements one single call:

file-get-type 

returning the type of the entity pointed to by 'path' (currently only: 0 = 
directory, 1 = file). (Symbolic constants like TYPE-DIRECTORY or such should 
be added if this is included.)

I'm also attaching a script that recursively traverses a given directory and 
returns a list of path names to (exclusively) regular files that are located 
inside this directory or any of its sub-directories for further processing. 
Try with

(all-files "/home/yourname/testdir")

on the Script-FU console, where "testdir" is a directory containing a few 
directories and files, NOT a few thousands (can cause problems on the 
console).

I'm giving this another shot (after bug #145370, taking your feedback into 
account - TinyScheme currently lacks a similar feature), because it seems to 
me that batch-processing is the single most often asked issue on the 
comp.graphics.apps.gimp NG, and it would be great if we could just give 
people a script similar to the sample I'm attaching, tell them to copy it to 
~/.gimpXY/scripts/ and let's rock, without the need to download and compile a 
separate plug-in. After the transition to TinyScheme, they would simply type:

gimp -c -i -b "(map my-specialized-conversion (all-files "allmypictures"))"

no matter which platform they are on.

Markus.

;; sample recursive traversal and return all files (needs filetype plug-in)
;; written by M. Triska <[EMAIL PROTECTED]>, July 16th 2004



(define (all-files directory)
  (let* ((outlist '())
 (entitylist (cadr (file-glob (string-append directory "/*")
(while (not (null? (car entitylist)))
   (if (= (car (file-get-type (car entitylist))) 1)
   (set! outlist (cons (car entitylist) outlist)) ;; file
   (set! outlist (append outlist (all-files (car entitylist)
   (set! entitylist (cdr entitylist)))
outlist))


/* The GIMP -- an image manipulation program
 * Copyright (C) 1995 Spencer Kimball and Peter Mattis
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */


#include 

#include 
#include "libgimp/gimp.h"

/* Utility function useful for batch processing
 * Author: Markus Triska <[EMAIL PROTECTED]> 
 * 
 * 0.8 initial version, July 16h 2004
 */

#define FILETYPE_DIRECTORY 0
#define FILETYPE_REGULAR   1

static void   query  (void);
static void   run(const char*name,
  gint  nparams,
  const GimpParam  *param,
  gint *nreturn_vals,
  GimpParam **return_vals);

GimpPlugInInfo PLUG_IN_INFO =
{
  NULL,/* init_proc */
  NULL,/* quit_proc */
  query,   /* query_proc */
  run, /* run_proc */
};

MAIN ()

static void
query ()
{
  static GimpParamDef filetype_args[] =
{
  { GIMP_PDB_STRING, "path", "Path of entity to check" }
};

  static GimpParamDef filetype_return_vals[] =
{
  { GIMP_PDB_INT32, "type", "Type of entity: DIRECTORY (0), REGULAR (1)" }
};

  gimp_install_procedure ("file_get_type",
      "Get type of an entity pointed to by 'path'",
  "Useful in scripts (e.g., batch processing)",
  "Markus Triska <[EMAIL PROTECTED]>",
  "Markus Triska",
  "2004",
  NULL,
			  NULL,
  GIMP_PLUGIN,
			  G_N_ELEMENTS (filetype_args),
			  G_N_ELEMENTS (filetype_return_vals),
			  filetype_args,
			  filetype_return_vals);
}

static void
run (const char*name,
 gint  nparams,
 const GimpParam  *param,
 gint *nreturn_vals,
 GimpParam **return_vals)
{
  static GimpParam values[2];

  *nreturn_vals = 1;
  *return_vals = values;

  values[0].type = GIMP_PDB_STATUS;
  values[0].data.d_status = GIMP_PDB_CALLING_ERROR;

  if (strcmp (name, "file_get_type") == 0)
{
  *nreturn_vals = 2;
  values[0].data.d_status = GIMP_PDB_SUCCESS;
  values[1].type = GIMP_PDB_INT32;
  

Re: [Gimp-developer] Adaptive Contrast Enhancement

[Markus Triska]

> Then I began to port it and release 0.6.44 that is not fully clean and some
> points have not been ported yet. So if you have time and enogh knowledge it
> would help a lot.

I have modified the plug-in to compile against GIMP 2.0. You can start it 
already (Image -> Colors -> Adaptive Contrast, should maybe be moved to 
"Layer->Colors"), but it is not fully functional (for example, OK/Cancel 
buttons do not work, but the preview does). The changes I made are mostly 
autotools-related (mainly configure.in). I also removed the "intl" program 
from the distribution. I did not modify any internals, in case you want to 
restructure the plug-in further.

You can download the intermediate 0.6.45 version from:

http://stud4.tuwien.ac.at/~e0225855/gimp-ace-0.6.45.tar.gz

What still needs to be done: The dialog handling (dialog.c) is deprecated. I 
marked the few lines I had to change to make the plug-in compile with 
"TODO" (2 occurrences in dialog.c). You would now use "gimp_dialog_run" to 
present the dialog (take for example "gimp-2.0.2/plug-ins/common/mblur.c" to 
see how it should be done) and check for GTK_RESPONSE_OK.

gimp_ace.c: gimp_plugin_help_register has changed. I don't know what you want 
to do with the call (make a web-page for the project etc.), or what you 
should point to (e.g., on-disk HTML documentation). It is commented out for 
now and also marked with "TODO". (There is also another occurrence of "TODO", 
namely in glaceG.c, but I did not add that, so apart from this, grepping for 
"TODO" should lead directly to the relevant places.)

I think you now have a pretty solid basis to work on (because the necessary 
infrastructure is there), but please feel free to e-mail me in case you need 
further assistance with enhancing the plug-in. Good luck.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] compose - decompose nitpicking

[Markus Triska]

On Wednesday 21 July 2004 09:42 am, Sven Neumann wrote:

> Sure, the plug-in is far from perfect. There's some code in compose.c
> that tries to guess some useful default values for the layers it
> preselects. This code could certainly be improved. I am not sure
> though if it makes sense to attempt to guess the compose mode from the
> given layer names. It's probably more useful to remember the last used
> mode (which is what the plug-in does already).

For a start, I'm attaching a patch that makes "compose" use the layers in 
reverse order (if the image has more than MIN_COMPOSE_LAYERS = 3 layers, 
otherwise use old behavior). No attempt is currently made to guess the mode.

Markus.
*** oldcompose.c	Wed Jul 21 17:34:11 2004
--- compose.c	Wed Jul 21 21:18:52 2004
***
*** 105,110 
--- 105,112 
  
  /* Maximum number of images to compose */
  #define MAX_COMPOSE_IMAGES 4
+ /* Minimum number of layers necessary to compose from layers */
+ #define MIN_COMPOSE_LAYERS 3
  
  
  /* Description of a composition */
***
*** 1069,1074 
--- 1071,1078 
GtkWidget *image;
GtkWidget *image_option_menu, *image_menu;
GSList*group;
+   gint32 *layer_list;
+   gint   nlayers;
gint   j, compose_idx;
gboolean   run;
  
***
*** 1087,1092 
--- 1091,1098 
  
gimp_ui_init ("compose", TRUE);
  
+   layer_list = gimp_image_get_layers (gimp_drawable_get_image (drawable_ID), &nlayers);
+ 
dlg = gimp_dialog_new (_("Compose"), "compose",
   NULL, 0,
  			 gimp_standard_help_func, "plug-in-compose",
***
*** 1148,1154 
  			GTK_FILL, GTK_FILL, 0, 0);
gtk_widget_show (label);
  
!   composeint.select_ID[j] = drawable_ID;
composeint.channel_menu[j] = image_option_menu = gtk_option_menu_new ();
image_menu = gimp_drawable_menu_new (check_gray,
 image_menu_callback,
--- 1154,1160 
  			GTK_FILL, GTK_FILL, 0, 0);
gtk_widget_show (label);
  
!   composeint.select_ID[j] = ((nlayers >= MIN_COMPOSE_LAYERS) ? layer_list[nlayers - (j + 1)] : drawable_ID);
composeint.channel_menu[j] = image_option_menu = gtk_option_menu_new ();
image_menu = gimp_drawable_menu_new (check_gray,
 image_menu_callback,
***
*** 1161,1166 
--- 1167,1173 
gtk_option_menu_set_menu (GTK_OPTION_MENU (image_option_menu),
  image_menu);
  }
+   g_free (layer_list);
  
/* Set sensitivity of last menu */
gtk_widget_set_sensitive (composeint.channel_menu[3],
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] compose - decompose nitpicking

[Markus Triska]

On Wednesday 21 July 2004 09:20 pm, you wrote:


> For a start, I'm attaching a patch that makes "compose" use the layers in
> reverse order (if the image has more than MIN_COMPOSE_LAYERS = 3 layers,
> otherwise use old behavior). No attempt is currently made to guess the
> mode.

Sorry, should read "...has *at least* MIN_COMPOSE_LAYERS = 3 layers".

This solution is not perfect either, but arguably not worse than before, and 
in many cases much better.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] filetype plug-in to get type of entity (file/directory)

[Markus Triska]

On Wednesday 21 July 2004 08:07 pm, Kevin Cozens wrote:

> This is just a taste of the possibilities for scripting in GIMP using
> Scheme based scripts with Tiny-Fu. What would you like to do today? :-)

Thank you for your explanation, Kevin. I was not aware of all the useful 
extensions you are incorporating into Tiny-Fu. I'm really looking forward to 
seeing (and implementing?) many scripts that will then become easy and, most 
of all, possible (it is now only a matter of time until someone implements 
all the functionality of GIMP in some Scheme script, oh wait - that's Emacs 
already).

By the way: I favour the current convention (used throughout GIMP scripts) of 
parenthesizing [for example, instead of:

(let* (
         (dir-stream (open-dir-stream dir))
         (file)
         )
(mycode)
)

I write:

(let* ((dir-stream (open-dir-stream dir))
         (file))
(mycode)) 
]

because it has become the de-facto standard for Scheme (also used in 
TinyScheme's "init.scm", in Emacs etc.) and it is recommended in all books 
and tutorials I could find in print and on the web, so apart from the fact 
that I use this style habitually by now, maybe sticking to it will help both 
newcomers (being accustomed to the style from the tutorials) and professional 
Lisp coders (having seen more braces, so to speak) to follow the code. It 
also saves many lines containing only ")" and thereby allows to grasp more 
code at once. Maybe you also find it advantageous (or even, more beautiful?) 
if you try it some day (well, it can't hurt to try both for some time and see 
which one is more appealing).

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Selecting new constants for '(file-type file)'?

[Markus Triska]

> I want to define some constants related to file type for use in Tiny-Fu. My
> current thinking is to use FILE_TYPE_FILE (0), FILE_TYPE_DIR (1), and
> FILE_TYPE_LINK (2). The last one being for *nix systems only. Are
> there  any other file types that should be handled (ie. nodes on *nix
> systems)?

Maybe I have not given this enough thought, but I would opt for 
FILE_TYPE_NONEXISTANT (although this can hardly be called a "file" type) so 
there is some well-defined behaviour if the path to check points nowhere. 
Also, what happens with access permissions ("not readable")? The call should 
be well-defined in this case, too, so maybe (to cover both cases), there 
should be some "FILE_TYPE_ERROR" and other predicates to check for 
existence/permission.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] gimp-plugin-template: install

[Markus Triska]

On Friday 23 July 2004 09:04 am, Joseph Heled wrote:

> Can someone tell me how to configure gimp-plugin-template so that it
> installs locally(~/gimp-2.0) instead of the global /usr/local?

You can type

./configure --help 

for a list of parameters that influence the installation. Maybe

./configure --prefix=/home/myname/gimp_plugins/

or similar does what you need (install where you have write-access to).

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] "Extrude"-filter and lots of triangles

[Markus Triska]

Hello,

a week or so ago, there was a request on comp.graphics.apps.gimp about the 
availability of the PS extrude-filter, used for example in this tutorial:

http://www.voidix.com/cystal.html

I spent a couple of hours working on a GIMP equivalent and I am attaching a 
horrible sample picture created with the plug-in as it stands so far (it 
currently uses random values for the colours of the pyramids and knows 
nothing about anti-aliasing). I'm for now using a quick and terrible hack to 
fill the triangles (see attached source if you are curious) and want to ask: 
Which method do you recommend to fill lots of triangles from within a 
plug-in? Is there a (fast?) Gimp function for this that I can use, maybe 
capable of anti-aliasing?

I think there is no obvious way to use tile iterators for this effect (little 
spatial locality), I am currently (g|s)etting the whole image at once - would 
you recommend that I get and set a region for each triangle I draw or some 
better compromise? I have not tried it yet -  could it be too slow if there 
are very many triangles, or slower than the swapping that could happen when 
processing the whole image at once? I'm asking this because I could only 
benchmark on my own system, which hardly is representative.

Best regards,
Markus.

External links:
Current version of the plug-in: http://stud4.tuwien.ac.at/~e0225855/extrude.c
Horrible picture mentioned: http://stud4.tuwien.ac.at/~e0225855/extrude.png
<>/* The GIMP -- an image manipulation program
 * Copyright (C) 1995 Spencer Kimball and Peter Mattis
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */

/* Plug-in (eventually) implementing Photoshop's "Extrude" effect
   Written by Markus Triska <[EMAIL PROTECTED]>
   August 2nd, 2004 - far from finished, just started working on it */



#include 
#include 

#include 



static void  query  (void);
static void  run(const char*name,
			 gint   nparams,
			 const GimpParam*param,
			 gint  *nreturn_vals,
			 GimpParam   **return_vals);

static void  extrude_render (GimpDrawable *drawable);

struct MemImage {
  long bpp;
  guchar *data;
  gint width, height, halfwidth, halfheight;
} theimage;


typedef struct pyramid_tag {
  GimpVector3 triangles[4][3]; /* four triangles */
  GimpRGB colours[4];
  int order[4];
} Pyramid;


GimpPlugInInfo PLUG_IN_INFO =
{
  NULL,  /* init_proc  */
  NULL,  /* quit_proc  */
  query, /* query_proc */
  run,   /* run_proc   */
};



void 
lines_intersection(GimpVector2 p1, GimpVector2 p2,
		GimpVector2 p3, GimpVector2 p4,
		GimpVector2 *intersectionpoint)
{

  float a1,b1,c1,  /* constants of linear equations */
a2,b2,c2,
det_inv,  /*  the inverse of the determinant of the coefficient */
m1,m2;/* the slopes of each line */

  /* compute slopes, note the kludge for infinity, however, this will
 be close enough */

  if ((p2.x-p1.x)!=0)
m1 = (p2.y-p1.y)/(p2.x-p1.x);
  else
m1 = (float)1e+10;   /* close enough to infinity */

  if ((p4.x-p3.x)!=0)
m2 = (p4.y-p3.y)/(p4.x-p3.x);
  else
m2 = (float)1e+10;   /* close enough to infinity */

  /* compute constants */

  a1 = m1;
  a2 = m2;
  
  b1 = -1;
  b2 = -1;
  
  c1 = (p1.y-m1*p1.x);
  c2 = (p3.y-m2*p3.x);

  /* compute the inverse of the determinant */

  det_inv = 1/(a1*b2 - a2*b1);

  /* use Cramer's rule to compute x and y */

  intersectionpoint->x=((b1*c2 - b2*c1)*det_inv);
  intersectionpoint->y=((a2*c1 - a1*c2)*det_inv);

}



static void 
fill_triangle(struct MemImage memimg, GimpVector2 *points, GimpRGB rgb)
{

  GimpVector2 tempvector,intersec1,intersec2;
  gint curr_y, sortruns = 0;

  if ((points[0].y == points[1].y) && (points[1].y == points[2].y)) return;

  /* 
 We enforce the following order on the points:
 (a) non-decreasing y coordinates
 (b) for y1 == y2, the point with lower x comes first

 This leaves 4 types of triangles to handle:

 0  10 0  0
    / \   /|  |\
 | /   /   \   1 / |  | \ 1
 |/   |-\\ |  | /
 2   1  2 \|22|/
  */

  GimpVector2 sortedpoints[3];
  sortedpoints[0] = points[0]; sortedpoints[1] = points[1];
  sortedpoints[2] = p

Re: [Gimp-developer] "Extrude"-filter and lots of triangles

[Markus Triska]

On Monday 02 August 2004 11:20 pm, you wrote:

> Well, the quick-and-dirty way of doing it would be to select a triangle
> shape and use the GIMP's fill function. :)

This is exactly what I want. For this I

#includeand
#include 

Is there a drawback of this method or something else I should know (I found
 no "core" plug-in including a header ending "_pdb.h", but I guess this is
 because none uses this)?

> I'm afraid I don't see why there is a lack of locality here: each triangle
> to be filled indeed has locality.  Of course, if the triangle is
> sufficiently small, only one tile needs to be involved.

Yes, each triangle has locality and of course, the whole effect also has
locality (the drawable), but I meant locality with regards to tiles when
using a tile iterator: I see no easy method to set up a tile iterator and
iterate by some constant amount, because no matter how big I make that
amount, there are always cases where triangles will cross a tile
intersection. I did not look at the select and fill code, so I am not sure
(especially wrt anti-aliasing) if a triangle started on tile A can be
continued on tile B without visible jags. When I have the effect working, I
will try such things, but it is not that important for now.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] "Extrude"-filter and lots of triangles

[Markus Triska]

On Tuesday 03 August 2004 06:35 pm, Markus Triska wrote:

> This is exactly what I want. For this I
>
> #includeand
> #include 

Can anybody beat this amount of stupidity? I just found out that these files 
are included via "libgimp/gimp.h".

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] "Extrude"-filter and lots of triangles

[Markus Triska]

On Tuesday 03 August 2004 05:35 pm, Michael Schumacher wrote:
>
> May I suggest that you start from the gimp plug-in template? It help you
> to get e.g. the build configurations and the i18n of your plug-in right.
>

Thank you for this suggestion. I have successfully used the plug-in template 
before and will add i18n and so on later. I currently work only on one single 
file  (which can be conveniently compiled using gimptool), but as soon as I 
add Gtk UI code in a separate file, I will switch to using autotools.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: "Extrude"-filter and lots of triangles

[Markus Triska]

On Tuesday 03 August 2004 07:08 pm, William Skaggs wrote:

> Actually I would go about this differently:  Start by
> making a list of all of the triangles, recording their
> vertices.

I have this list available already, so this would be no problem.

> Then go through the image, and for each pixel,
> figure out which triangle is visible there, and render
> its color.  I think this would be a lot faster, and it
> lets you work with a tile iterator as well.

Even if I had an easy way to determine the right triangle, this would make
anti-aliasing harder because no pixel would "know" if it is part of an edge
or even nearby. My guess is that the advantage of using a tile iterator would
not outweigh the additional computing time necessary for the approach you
suggest, but I have not tried it yet, and this is why I asked for stats
initially.

> If you start searching from the center of the image, and
> work outward, then the first triangle you find that
> overlies the point will be the one that is visible,
> so the search can be done pretty efficiently.
> In fact,
> there may even be a way of calculating which triangle is
> visible above a given pixel without having to do any
> searching.

The search would be additionally complicated by the fact that you can 
optionally give the pyramids random heights and modify the viewing distance,
so the perspective projection has to be taken into account more explicitly. I
therefore don't think that the method you suggest would be easier or faster.

I have meanwhile modified the plug-in to use GIMP's selection and fill method
(with anti-aliasing enabled). The result now looks better and also rendered
quite fast (there's currently a problem on the left side of the pyramids in
the horizontal center of the image which I will of course fix):

http://stud4.tuwien.ac.at/~e0225855/extrude2.png


To fill a triangle, I use:

gimp_palette_set_foreground ...
gimp_free_select 
gimp_edit_fill 

Is there a better way to do this? The "set_foreground"-part changes the colour 
menu in the user interface, can I avoid this somehow? Why does the call take 
a pointer - is it safe to modify the variable after the call? Another 
question: Do I have to call gimp_drawable_flush and gimp_drawable_update at 
the end of processing? What do these things do? I called them when I worked 
on the pixel data directly, but I have now commented these calls out as I 
only use internal GIMP functions and don't copy or modify the pixel 
regions/arrays directly.

And something else: The documentation for "gimp-drawable-mask-bounds" reads
"...returns the whether there...".

Markus.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] starts with 0 or 1?

[Markus Triska]

On Sunday 08 August 2004 10:17 pm, Simon Budig wrote:

> ordinal numbers start at 1

1 is no ordinal number, you most likely mean "1st"?

Whether you assume 0 or 1 being the 1st natural number is only a matter of 
convention and convenience (depending on the subject matter). Most people 
start to count from 1, so it makes sense to use "1" as label for the 1st 
object, but it is nevertheless arbitrary, as one could for example also have 
used the labelling "a", "b", "c", ..., with "a" denoting the 1st object etc.

> Hence the number "0" in the ancient version of the IFS Compose plugin
> was a bug and has been corrected for the Version 1.2.

One of the advantages of the current style is that the object with label "n" 
is the n-th object (I personally have no idea if the order of the objects 
actually matters in the case of IfsCompose, from what I see: if at all, not 
much). The previous mapping was not exactly a "bug", but less convenient with 
respect to this.

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] "Extrude"-filter and lots of triangles

[Markus Triska]

On Sunday 15 August 2004 12:56 am, you wrote:

> This was an interesting plug-in, the latest one "more interesting" than the 
first.

Thank you, the current version produces even "better" results (all sides are 
now drawn in correct order).

> Do you intend to have a user Dialogue interface for the plug-in?

Yes, now that I have got the basics somewhat right, the following parameters 
could be set/changed in a dialog:

*) height of pyramids  / random height? (boolean toggle)
*) size of pyramids 
*) viewing distance 
*) direction of light vector 

(later: pyramids/blocks; don't hide partially visible objects)

I still need to figure out useful default values for the settings (currently 
height = 80, size = 50, distance = 250, light vector = constantly changing to 
test the shading code, in the .c-file on the web it is (1,0,0), but need not 
be normalized).

If you are interested in coding up (parts of) the dialog, just fetch 
the .c-file from the web and insert the code wherever you see fit, I can 
merge your changes later with my own latest version.

The most appealing part of this task is probably the representation of the 
light vector - of course, 3 text-boxes each holding an integer would 
"suffice" (certainly for the initial version of the plug-in), but you may 
find an easy way to actually show and let users interactively edit the vector 
in pseudo-3D.

Best regards,
Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer