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

2004-07-06 Thread Kevin Cozens
On Tue, 2004-07-06 at 19:45, Sven Neumann wrote:
> The fact that the PDB uses arrays doesn't necessarily mean that a
> language binding such as Tiny-Fu needs to represent them as arrays.
> One of the most annoying bits of Script-Fu is that it forces you to
> work with arrays even though the natural choice for a scheme dialekt
> would be lists. If Tiny-Fu cannot provide backward-compatibility, then
> it should overcome this mistake and map the PDB API to lists.

Tiny-Fu makes no attempt to provide backwards compatability with the
SIOD Scheme interpreter way of doing things. It expects scripts to
follow the current Scheme standard as defined in the R5RS document.

Since the R5RS does not define an array type, any script which uses
arrays either internally or when dealing with PDB calls needs to be
modified to use a list. The marshalling code of Tiny-Fu converts between
PDB *ARRAY and Scheme lists as needed. The alternative would be to use a
Scheme vector but instead of a list. Using a list seemed like the
simplest approach.

-- 
Cheers!
 
Kevin.  (http://www.interlog.com/~kcozens/)
 
Owner of Elecraft K2 #2172|"What are we going to do today, Borg?"
E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus:
Packet:[EMAIL PROTECTED]|  Try to assimilate the world!"
#include|  -Pinkutus & the Borg

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


Re: [Gimp-developer] Script-fu-server and queuing

2004-07-06 Thread Oscar Picasso
> My solution is not yet implemented. But a lot of what needs to be done
> is in GIMP 2.0 already. There's really no good reason not to use GIMP
> 2.0.

I would love to. I tried to install the rpm for fedora core 1 but it didn't
work. I also tried to compile it but I've very busy now. I will try again as
soon as I have some time.

> Did you mean to send this mail to the mailing-list? I'd prefer to have
> such discussions on the list so please respect that and move the
> discussion back to the list.

It was intended for the list. I'm just realizing that the list address doesn't
appear on the "To" field, unlike other lists I use, so the "reply" instinct
doesn't work here.

Oscar

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] easy questions

2004-07-06 Thread Sven Neumann
Hi,

Zack <[EMAIL PROTECTED]> writes:

> I have a couple basic questions for the people who know the GIMP
> code well.  The first is, how intimately is the GIMP tied to GTK+?

Most of the core code (but none of the plug-ins) has a clean
separation of the GUI from the core functionality. However since a
good deal of code is GUI code I'd say it is quite intimate with GTK+.

> The second is, I haven't looked at the code at all, but is the GIMP
> multithreaded and/or does it absolutely require a multitasking OS?
> Thank you...

It makes use of multi-threading if compiled with the --enable-mp flag
and however it is compiled, it absolutely needs a multitasking OS.


Sven

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


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

2004-07-06 Thread Sven Neumann
Hi,

Markus Triska <[EMAIL PROTECTED]> writes:

> > 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.

The fact that the PDB uses arrays doesn't necessarily mean that a
language binding such as Tiny-Fu needs to represent them as arrays.
One of the most annoying bits of Script-Fu is that it forces you to
work with arrays even though the natural choice for a scheme dialekt
would be lists. If Tiny-Fu cannot provide backward-compatibility, then
it should overcome this mistake and map the PDB API to lists.


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


[Gimp-developer] easy questions

2004-07-06 Thread Zack
Hi folks,
I have a couple basic questions for the people who know the GIMP code well.
The first is, how intimately is the GIMP tied to GTK+?
The second is, I haven't looked at the code at all, but is the GIMP multithreaded
and/or does it absolutely require a multitasking OS?
Thank you...
 
		Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!

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

2004-07-06 Thread 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


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

2004-07-06 Thread 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


Re: [Gimp-developer] Windows CE port?

2004-07-06 Thread Sven Neumann
Hi,

Zack <[EMAIL PROTECTED]> writes:

> Has anyone begun or even thought about a Windows CE
> port of The GIMP (and GTK+)? I think it would be a useful tool for use
> by hobbyists and photographers on the road, especially
> when WinCE devices come along that have actual hard drives.

Please propose this on the gtk-devel list since GIMP is portable
code. Almost all the platform-specific code is in GLib and GTK+.


Sven

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


Re: [Gimp-developer] rearranging Xtns Menu

2004-07-06 Thread Carol Spears
On Tue, Jul 06, 2004 at 09:47:50PM +0200, David Neary wrote:
> Moin Mlle Spears,
> 
> Carol Spears wrote:
> > there are things that belong directly to the scripting things that get
> > used when writing scripts.  if you are writing script-fu, the python
> > console is of no use to you, for instance.
> > 
> > i put only things that would be useful for writing scripts into these
> > Xtns menu options.
> 
> That has a certain logic. How about Console->Perl,
> Console->Python and Console->Script-fu instead? Then again, if
> the actual plug-ins are in more functional positions, I'm happy.
> 
consider the tear off menu:

Console:
 Perl
 Python
 Script-Fu
 Tiny-Fu

consider this tear off menu:

Python:
 Browser
 Console
 Server

even more, i am considering what the average script-fu writer does while
always being faced with the fact that there is a perl console available
-- they work so much in their own little space now.

the temptation here is to move them around for tactile reasons instead
of smart menu making 

carol

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


Re: [Gimp-developer] Improving the mouse wheel zoom

2004-07-06 Thread Michael Schumacher
Joao S. O. Bueno wrote:
I like this idea.
Stan, would you mind filling this as a request feature at GIMP bugzilla?
It helps developers keep track of the features wanted, and you will have some 
feedback on it each time it is considered, or implemented, by the developers.
 
http://bugs.gimp.org 
IIRC there is already such a report (zoom to where the cursor is).
HTH,
Michael
--
The GIMP > http://www.gimp.org| IRC: irc://irc.gimp.org/gimp
Sodipodi > http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] rearranging Xtns Menu

2004-07-06 Thread David Neary
Moin Mlle Spears,

Carol Spears wrote:
> there are things that belong directly to the scripting things that get
> used when writing scripts.  if you are writing script-fu, the python
> console is of no use to you, for instance.
> 
> i put only things that would be useful for writing scripts into these
> Xtns menu options.

That has a certain logic. How about Console->Perl,
Console->Python and Console->Script-fu instead? Then again, if
the actual plug-ins are in more functional positions, I'm happy.

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Improving the mouse wheel zoom

2004-07-06 Thread Philip Lafleur
Joao S. O. Bueno wrote:
Stan, would you mind filling this as a request feature at GIMP bugzilla?
 

There is already a report about this on bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=79384
Philip
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


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

2004-07-06 Thread Kevin Cozens
At 03:27 PM 07/06/2004, Joao wrote:
One of the major showstopers for script-fu as of lately is it inability to
handle UTF-8 strings. Is tiny scheme able to do so?
No, TinyScheme does not handle UTF-8 strings. UTF-8 support is already on 
the ToDo list since Sven already raised the issue on #gimp.

Cheers!
Kevin.  (http://www.interlog.com/~kcozens/)
Owner of Elecraft K2 #2172|"What are we going to do today, Borg?"
E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus:
Packet:[EMAIL PROTECTED]|  Try to assimilate the world!"
#include|  -Pinkutus & the Borg
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] rearranging Xtns Menu

2004-07-06 Thread Carol Spears
moin mr. neary,
On Tue, Jul 06, 2004 at 08:34:18PM +0200, David Neary wrote:
> Carol Spears wrote:
> > the bug report suggests this rearrangement of the Xtns menu (which is a
> > huge mess if you install all of the difference scripting options that
> > the linux gimp has):
> 
> Agreed :)
> 
> > The New Structure /Xtns/:
> > 
> > * Perl -->
> 
> 
> 
> > * Script-Fu -->
> 
> 
> 
> > * Python -->
> 
> 
> 
> One thing I would really like to see is plug-ins installing
> themselves according to their function, rather than what language
> they are written in. This is more work, of course (or perhaps not
> - maybe it's just a case of removing the Perl, Python and
> Script-fu menus and keeping all the structure underneath).
> 
there are things that belong directly to the scripting things that get
used when writing scripts.  if you are writing script-fu, the python
console is of no use to you, for instance.

i put only things that would be useful for writing scripts into these
Xtns menu options.

carol

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


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

2004-07-06 Thread Joao S. O. Bueno
On Tuesday 06 July 2004 15:59, Kevin Cozens wrote:

>
> It would be helpful to know of anything that might block this. Other than
> the lack of support for binary data (ie. it can't work with GIMP parasites)
> at the moment, and the translation files need to be updated, I think
> Tiny-Fu is in as good a shape (if not better in some ways) than Script-Fu.
>

OOPS...

One of the major showstopers for script-fu as of lately is it inability to 
handle UTF-8 strings. Is tiny scheme able to do so?

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


Re: [Gimp-developer] Improving the mouse wheel zoom

2004-07-06 Thread Joao S. O. Bueno
I like this idea.

Stan, would you mind filling this as a request feature at GIMP bugzilla?
It helps developers keep track of the features wanted, and you will have some 
feedback on it each time it is considered, or implemented, by the developers.


http://bugs.gimp.org 

Thank you.

JS
-><-

On Tuesday 06 July 2004 15:44, Stan Gatchel wrote:
> All,
>
> I really enjoy and use GIMPv2 a lot. One small improvement I recommend
> is when zooming with mouse wheel (shift key down) have it zoom in to the
> location of the cursor, i.e, instead of zooming into the frame at the
> center (which is what I think GIMP currently does).
>
> When I do this now, I have to adjust the window view so I can see the
> area of interest. But if I can tell GIMP where I want to zoom in the
> field of view just by pointing with the cursor, this tedious adjustment
> operation can be avoided. I use zoom all the time so this would be a
> real time saver.
>
> Thanks,
>
> Stan Gatchel
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


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

2004-07-06 Thread Kevin Cozens
At 02:18 PM 07/06/2004, Markus wrote:
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?
No, I do NOT want to fork TinyScheme. I am trying to keep patches to 
TinyScheme which would be only be required for use with Tiny-Fu to a 
minimum. Some TinyScheme patches I currently have will be passed back to 
the author of TinyScheme so others can benefit from those changes and/or 
bug-fixes.

Arrays as used with SIOD are not defined in the R5RS (the current document 
defining the Scheme language). I have chosen to use lists instead.

Otherwise, I can convert scripts that are currently using arrays to use lists
instead if you have not already done so.
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.

Cheers!
Kevin.  (http://www.interlog.com/~kcozens/)
Owner of Elecraft K2 #2172|"What are we going to do today, Borg?"
E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus:
Packet:[EMAIL PROTECTED]|  Try to assimilate the world!"
#include|  -Pinkutus & the Borg
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


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

2004-07-06 Thread Kevin Cozens
At 01:18 PM 07/06/2004, Sven Neumann wrote:
We talked about script-fu and tiny-fu at GIMPCon and agreed that we'd
like to see Script-Fu removed from the GIMP source tree as soon as
Tiny-Fu is available as a separate package that can replace it.
The Tiny-Fu tarball can exist in the GIMP source tree just as Script-Fu 
does now since its of a comparable size. Having it as a separate package 
would make it easier for others to try it who aren't building GIMP from source.

 This
could happen for GIMP 2.2 provided that Tiny-Fu is ready by that time.
It would be helpful to know of anything that might block this. Other than 
the lack of support for binary data (ie. it can't work with GIMP parasites) 
at the moment, and the translation files need to be updated, I think 
Tiny-Fu is in as good a shape (if not better in some ways) than Script-Fu.

I have a couple of questions about Tiny-Fu.
No, problem. I don't really have an FAQ yet so your questions can help me 
create one.

(1) Is Tiny-Fu supposed to run scripts written for Script-Fu?
The answer is yes, however...
I wanted to keep Script-Fu on my machine while working on Tiny-Fu. As a 
result, I had to make them co-exist. The scripts run by Tiny-Fu must end in 
.sct rather than .scm as they do for Script-Fu. Also, any references to 
Script-Fu in scripts must be changed to Tiny-Fu (preserving case).

Once those changes have been done, some scripts will work as is. Some 
scripts need to have variables defined before first use. Some scripts 
(especially those that work with GIMP parasites, use arrays, or use 
features of Scheme unique to the SIOD interpreter) will need other changes. 
The web page contains some information about updating a Script-Fu script 
for use with Tiny-Fu.

If so,
will this be some kind of compatibility layer or perhaps just a
script that helps to convert old scripts?
A script could be created to handle the simpler changes required to make a 
Script-Fu script work with Tiny-Fu but some scripts will still require 
changes to be made by hand.

(2) Is Tiny-Fu supposed to run as a permanent extension like the
current Script-Fu implementation or will it start a new
interpreter when needed and exit when the script is done?
I made a full copy of Script-Fu as the starting point for Tiny-Fu. It 
currently works just like Script-Fu does but that doesn't meant it can't 
(or won't) change in the future.

(3) Somewhat related to question (2), will Tiny-Fu allow scripts to be
run concurrently?
[snip]
 That would put more pressure on making the
core reentrant.
This quote from the TinyScheme authors web site might help. "As an embedded 
interpreter, it [TinyScheme] allows multiple interpreter states to coexist 
in the same program, without any interference between them."

With the recent changes to GIMP regarding context and the fact I access all 
features of the TinyScheme interpreter via its interface mechanism, it 
should be possible to have scripts run concurrently.

Cheers!
Kevin.  (http://www.interlog.com/~kcozens/)
Owner of Elecraft K2 #2172|"What are we going to do today, Borg?"
E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus:
Packet:[EMAIL PROTECTED]|  Try to assimilate the world!"
#include|  -Pinkutus & the Borg
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Improving the mouse wheel zoom

2004-07-06 Thread Stan Gatchel
All,
I really enjoy and use GIMPv2 a lot. One small improvement I recommend 
is when zooming with mouse wheel (shift key down) have it zoom in to the 
location of the cursor, i.e, instead of zooming into the frame at the 
center (which is what I think GIMP currently does).

When I do this now, I have to adjust the window view so I can see the 
area of interest. But if I can tell GIMP where I want to zoom in the 
field of view just by pointing with the cursor, this tedious adjustment 
operation can be avoided. I use zoom all the time so this would be a 
real time saver.

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


Re: [Gimp-developer] rearranging Xtns Menu

2004-07-06 Thread David Neary
Hi Carol,

Carol Spears wrote:
> the bug report suggests this rearrangement of the Xtns menu (which is a
> huge mess if you install all of the difference scripting options that
> the linux gimp has):

Agreed :)

> The New Structure /Xtns/:
> 
> * Perl -->



> * Script-Fu -->



> * Python -->



One thing I would really like to see is plug-ins installing
themselves according to their function, rather than what language
they are written in. This is more work, of course (or perhaps not
- maybe it's just a case of removing the Perl, Python and
Script-fu menus and keeping all the structure underneath).

Cheers,
Dave.

-- 
David Neary,
Lyon, France
   E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
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

2004-07-06 Thread 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


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

2004-07-06 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
> (1) Is Tiny-Fu supposed to run scripts written for Script-Fu? If so,
> will this be some kind of compatibility layer or perhaps just a
> script that helps to convert old scripts?

There are a few small differences between Tiny-Scheme and SIOD, some
of them are listed on the webpage.

Tiny-Fu will not run the same scripts as Script-Fu, since SIOD allows
some dirty tricks that are not nice. The most evil thing (that gets
fixed by Tiny-Fu) is the use of (set! ) on a not yet defined variable.

Some scripts do that kind of stuff and there even were some bugs
in the Scripts because of this. These Scripts need to become sanitized
to be able to run under the new Scheme interpreter.

There are some other differences, but I am not exactly sure about their
consequences. Some might be hidden by some small helper functions, I
am however not sure if this is desireable.

Bye,
Simon

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


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

2004-07-06 Thread Sven Neumann
Hi,

Kevin Cozens <[EMAIL PROTECTED]> writes:

> I have created a web page for Tiny-Fu. The URL for the page is:
> http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html
> A tarball of Tiny-Fu is available but at the moment it must be hooked
> in to the GIMP 2.1 source tree using the supplied patch file. A
> standalone version will be available later.
> 
> The web page contains additional information about the plug-in as well
> as the status of the work being done on it. Currently it is somewhere
> between the alpha and beta stage of development. It ran its first
> script in April of this year (ts-helloworld.sct) and as of July 6, I
> have updated 57 of the 96 Script-Fu scripts to work with Tiny-Fu.

We talked about script-fu and tiny-fu at GIMPCon and agreed that we'd
like to see Script-Fu removed from the GIMP source tree as soon as
Tiny-Fu is available as a separate package that can replace it. This
could happen for GIMP 2.2 provided that Tiny-Fu is ready by that time.

I have a couple of questions about Tiny-Fu. Please excuse if they are
already answered on your web-page, I didn't look at it yet. Just point
me to the FAQ then.

(1) Is Tiny-Fu supposed to run scripts written for Script-Fu? If so,
will this be some kind of compatibility layer or perhaps just a
script that helps to convert old scripts?

(2) Is Tiny-Fu supposed to run as a permanent extension like the
current Script-Fu implementation or will it start a new
interpreter when needed and exit when the script is done?

(3) Somewhat related to question (2), will Tiny-Fu allow scripts to be
run concurrently? I know that the GIMP core doesn't like this very
much at the moment but it would still be nice to have a script
engine that allows it. That would put more pressure on making the
core reentrant.


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


Re: [Gimp-developer] rearranging Xtns Menu

2004-07-06 Thread Sven Neumann
Hi,

Carol Spears <[EMAIL PROTECTED]> writes:

> I also attached a version of web-browser.scm that reflects some of
> these proposed changes.

Before GIMP 2.0 we basically agreed that we should not have any
external links in our menus. The reason for that is that we don't have
any control over these web pages and would have to release a new
version of GIMP when the link changes.  Links to external pages should
be kept on www.gimp.org.

I basically like the proposed menu structure except for all the Help
and Test menus. They should IMO not be there.


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


[Gimp-developer] Windows CE port?

2004-07-06 Thread Zack
Hi,
 
Has anyone begun or even thought about a Windows CE
port of The GIMP (and GTK+)? I think it would be a useful tool for use
by hobbyists and photographers on the road, especially
when WinCE devices come along that have actual hard drives.
 
Thanks.
 
		Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

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

2004-07-06 Thread Kevin Cozens
Greetings, everyone.
For some months now I have been working on a new plug-in for the 2.1 
version of GIMP. I have been calling this new plug-in Tiny-Fu. Some of the 
people on this list who use the #gimp IRC channel have already heard about 
this plug-in.

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.

I have created a web page for Tiny-Fu. The URL for the page is:
http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html
A tarball of Tiny-Fu is available but at the moment it must be hooked in to 
the GIMP 2.1 source tree using the supplied patch file. A standalone 
version will be available later.

The web page contains additional information about the plug-in as well as 
the status of the work being done on it. Currently it is somewhere between 
the alpha and beta stage of development. It ran its first script in April 
of this year (ts-helloworld.sct) and as of July 6, I have updated 57 of the 
96 Script-Fu scripts to work with Tiny-Fu.

Cheers!
Kevin.  (http://www.interlog.com/~kcozens/)
Owner of Elecraft K2 #2172|"What are we going to do today, Borg?"
E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus:
Packet:[EMAIL PROTECTED]|  Try to assimilate the world!"
#include|  -Pinkutus & the Borg
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] rearranging Xtns Menu

2004-07-06 Thread Carol Spears
hi,

i took out a bug report on this:
http://bugzilla.gnome.org/show_bug.cgi?id=145507

i am also still jet lagged from the very wonderful conference experience
(OT, if we had had one more day in Norway, the plan was to WAR Drive
Bergin and get beta back in action; we had a WiFi Sniffing gimp
developer )

the bug report suggests this rearrangement of the Xtns menu (which is a
huge mess if you install all of the difference scripting options that
the linux gimp has):

The New Structure /Xtns/:

Module Manager
DB Browser
Plugin Details
Unit Editor
* Perl -->
  Browser
  Console
  Server
  
  * Help -->
* Documentation -->
* Bookmarks -->
  * Test -->
* Script-Fu -->
  Browser
  Console
  Server
  
  * Help -->
* Documentation -->
* Bookmarks -->
  * Test -->
* Python -->
  Browser
  Console
  Server
  
  * Help -->
* Documentation -->
* Bookmarks -->
  * Test -->
--
* Animation -->
* Render -->
  * Art -->
  * Patterns -->
  * Shapes -->
  * Themes -->
* Web -->
  * Logos -->
  * Navigation -->
* Low Res Print -->
  * Logos -->
  * Navigation -->
* High Res Print -->
  * Logos -->
  * Navigation -->
   * Utilities -->



I also attached a version of web-browser.scm that reflects some of these
proposed changes.

there is a chance that my reordering is not good, flawed, named poorly
or ill-timed and probably some discussion of this here is good before i
continue to get involved with it.

carol

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


[Gimp-developer] GUADEC, gimp convention and gimp developers

2004-07-06 Thread Carol Spears
the gimp convention was a wonderful event.

not only are the gimp developers smart and fun, but they were gentlemen
as well.  

thank you everyone who was involved in such a wonderful experience and
who helped or contributed to include me.

carol

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


Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin

2004-07-06 Thread Sven Neumann
Hi,

Tor Lillqvist <[EMAIL PROTECTED]> writes:

> > When I started to implement the GDK clipboard functionality I was
> > hoping there was better support for it in the win32 GDK backend.
> 
> Thinking a bit more on it, adding support for cut&paste of images to
> gdk/win32 would probably not be hard at all. Much code from
> winclipboard.c can be reused. For interoperability with other Windows
> apps one presumably should store/accept image data in/from the Windows
> Clipboard in the predefined "CF_DIB" format (DIB ==
> "device-independent bitmap"; basically an in-core BMP I think).

The first thing to do then would be to add a GdkPixbuf module for the
"CF_DIB" format. It can be bundled with GIMP in the Win32 installer.


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


Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin

2004-07-06 Thread Tor Lillqvist
> When I started to implement the GDK clipboard functionality I was
> hoping there was better support for it in the win32 GDK backend.

Thinking a bit more on it, adding support for cut&paste of images to
gdk/win32 would probably not be hard at all. Much code from
winclipboard.c can be reused. For interoperability with other Windows
apps one presumably should store/accept image data in/from the Windows
Clipboard in the predefined "CF_DIB" format (DIB ==
"device-independent bitmap"; basically an in-core BMP I think).

I doubt I have time to do it before going on vacation for three weeks
next Saturday, though. Hans or somebody else wanna try?

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


Re: [Gimp-developer] Image cut-n-paste; Mac clipboard plugin

2004-07-06 Thread Sven Neumann
Hi,

Tor Lillqvist <[EMAIL PROTECTED]> writes:

> Sven Neumann writes:
>  > What is the state of support for the GDK clipboard in the win32
>  > backend?
> 
> For the *GDK* clipboard only cut&paste of text is supported. The
> winclipboard plug-in uses the Windows clipboard directly. 
> 
>  > Michael reported that he can't even copy and paste image data
>  > from one GIMP instance to the other on Win32. Would that be supposed
>  > to work?
> 
> Yes it does work. (Although I now notice that it always copies the
> whole drawable to the Windows clipboard, not just the selection as one
> would expect).

I was actually asking about the newly added support for the system
clipboard which is supposed to obsolete the winclipboard plug-in.
Well, you basically answered that above. So the answer is that it is
_not_ supposed to work :( This is rather unfortunate. When I started
to implement the GDK clipboard functionality I was hoping there was
better support for it in the win32 GDK backend.


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


Re: [Gimp-developer] color management

2004-07-06 Thread Sven Neumann
Hi,

Tor Lillqvist <[EMAIL PROTECTED]> writes:

> Er, what's "linear" about sRGB? It's gamma encoded (and that's a good
> thing). Doesn't the term "linear" in the context of colour spaces mean
> one with components that are linear in intensity, i.e. a linear
> transformation of the CIEXYZ colour space, which sRGB isn't. Or am I
> confused?

It's probably me who's confused. I think I picked up that term at
GIMPCon and probably misunderstood it or ripped it out of context.

> I don't know, maybe we should also allow other (more wider gamut)
> internal working colour spaces than sRGB?

Well, we have only one internal color space. We just need to agree on
what we want to call it...


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