Re: [Gimp-developer] Layer locking proposal

2005-06-29 Thread michael chang
On 6/27/05, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,
 
 Simon Budig [EMAIL PROTECTED] writes:
 
  A way to overcome this is to have e.g. two lines per layer. A sample
  mockup is available at
http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png
 
 This might work from a user's point of view but I am afraid that it
 will be a nightmare to implement. There's absolutely no support from
 GTK+ for this kind of UI. Probably even for good reasons.

So you can't do something like a two boxes with columns, in a box, and
then have a list of those boxes?  Something like the way Java Swing
does GUIs? [I'm sorry, but I have no idea how GTK+ works, so it's just
my two cents.]  I don't suppose this would be something to ask the
GTK-Development team about how to implement, would it?  [Similar to
how we're discussing how to implement this here.]
-- 
~Mike
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp-cvs on msys/mingw

2005-06-29 Thread lode leroy




From: Manish Singh [EMAIL PROTECTED]
Reply-To: Manish Singh [EMAIL PROTECTED]
To: michael chang [EMAIL PROTECTED]
CC: lode leroy 
[EMAIL PROTECTED],gimp-developer@lists.xcf.berkeley.edu

Subject: Re: [Gimp-developer] gimp-cvs on msys/mingw
Date: Tue, 28 Jun 2005 09:45:38 -0700

On Tue, Jun 28, 2005 at 12:40:37PM -0400, michael chang wrote:
 On 6/28/05, Manish Singh [EMAIL PROTECTED] wrote:

  Changing stuff outside of gimp should be considered last resort.
 
   which is still not perfect: I modified python.m4 to replace \es by 
/es:

  
  [am_cv_python_pythondir=`$PYTHON -c from distutils import 
sysconfig;

   print
   
sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')

   2/dev/
   null ||
 
  Why is this needed at all? gimp doesn't use $pythondir anywhere.

 I don't know, but maybe this has something to do with python-fu or
 whatever it is [scripting in The GIMP with Python, as opposed to e.g.
 Perl or Script-Fu].  IIRC, some info about Python-Fu building on Win32
 just came through the gimp-devel list, so... *shrugs*


yes. my info on compiling gimp from cvs :-)



Uh, that's what this thread is about, pygimp on Win32.



This is indeed needed to compile the pygimp plugin on Win32/MSYS/MinGW.

This particular test determines the libraries needed to link agains 
libpython.

the result is c:\Python24\Lib\site-packages.

MSYS (especially sh.exe) expects that to be c:/Python24/Lib/site-packages.


The point being, $pythondir isn't used by the pygimp build stuff at all,
so changing the above automake stuff won't actually do anything.

-Yosh



___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp-cvs on msys/mingw

2005-06-29 Thread lode leroy




From: Manish Singh [EMAIL PROTECTED]
On Tue, Jun 28, 2005 at 11:31:48AM +0200, lode leroy wrote:

...

Your libwmf library is too old. Upgrade.


will do. I just took the stuff from tml's gimp-for-windows page


 the autodetection of python on MSYS is not too good:
 the \es need to be replaced with /es, so I added this to

Where did it screw up? You sure you are using a CVS snapshot with all
the relevant changes? The ChangeLog should have:


MSYS (especially sh.exe) needs / instead of \ in the paths.
Printing paths from python (in pythondev.m4 and 
/usr/share/aclocal-1.9/python.m4)



 C:\Python24\lib\site-packages\site-customize.py
Changing stuff outside of gimp should be considered last resort.


I do not see an alternative: /usr/share/aclocal-1.9/python.m4 is not part of 
gimp,

but is used via aclocal...

 which is still not perfect: I modified python.m4 to replace \es by 
/es:


[am_cv_python_pythondir=`$PYTHON -c from distutils import sysconfig; 
print

 sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')
 2/dev/ null ||

Why is this needed at all? gimp doesn't use $pythondir anywhere.


this particular test is used to detect the LDFLAGS to link pygimp against 
libpython


-- lode


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp-cvs on msys/mingw

2005-06-29 Thread Manish Singh
On Wed, Jun 29, 2005 at 09:02:54AM +0200, lode leroy wrote:
  the autodetection of python on MSYS is not too good:
  the \es need to be replaced with /es, so I added this to
 
 Where did it screw up? You sure you are using a CVS snapshot with all
 the relevant changes? The ChangeLog should have:
 
 MSYS (especially sh.exe) needs / instead of \ in the paths.
 Printing paths from python (in pythondev.m4 and 
 /usr/share/aclocal-1.9/python.m4)

Yes, and the configure script should take care of this. This is why I
asked for confirmation that you have all the stuff needed for this to
work (which you did not answer).
 
  C:\Python24\lib\site-packages\site-customize.py
 Changing stuff outside of gimp should be considered last resort.
 
 I do not see an alternative: /usr/share/aclocal-1.9/python.m4 is not part 
 of gimp,
 but is used via aclocal...

Except the stuff you changed isn't used in the build...
 
  which is still not perfect: I modified python.m4 to replace \es by 
 /es:
 
 [am_cv_python_pythondir=`$PYTHON -c from distutils import sysconfig; 
 print
  sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')
  2/dev/ null ||
 
 Why is this needed at all? gimp doesn't use $pythondir anywhere.
 
 this particular test is used to detect the LDFLAGS to link pygimp against 
 libpython

But $pythondir isn't used in LDFLAGS. $PYLINK_LIBS is used, and the
backslash to forward slash transformation is performed on this.

If you're having to make changes to these files, it sounds like you're
not using current enough sources.

-Yosh
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp-cvs on msys/mingw

2005-06-29 Thread lode leroy




From: Manish Singh [EMAIL PROTECTED]
Yes, and the configure script should take care of this. This is why I
asked for confirmation that you have all the stuff needed for this to
work (which you did not answer).


I did run cvs update, and it did compile.


...
Except the stuff you changed isn't used in the build...


I have now reverted my changes to
/usr/share/aclocal-1.9/python.m4, 
C:\Python24\lib\site-packages\site-customize.py

and m4macros/pythondev.m4
and re-ran autogen...



If you're having to make changes to these files, it sounds like you're
not using current enough sources.


and indeed my modifications are no longer needed.



-Yosh


Thanks for adding support for msys to the gimp build files, yosh!

Sorry about the noise.

-- lode


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] is it possible to have layer properties

2005-06-29 Thread Chin2
well i`m wondering if it really difficult to have layer properties in gimp. with all the plugins we have in gimp i think it might be possible to have this without much difficulty. and alsois`,nt it possible to support and save the files in advanced version of psd..


Re: [Gimp-developer] is it possible to have layer properti es

2005-06-29 Thread Michael Schumacher
 Von: Chin2 [EMAIL PROTECTED]

 well i`m wondering if it really difficult to have layer properties in
 gimp. 

We already have some layer properties - opacity, visibility, link state - so
you should specify what you're talking about...

 with all the plugins we have in gimp i think it might be possible to have 
 this without much difficulty. 

...though this tells me that you're probably looking for dynamically applied
filters.

If you're interested in helping, you should look into joining the GEGL
project.

 and also is`,nt it possible to support and save the files in advanced 
 version of psd..
 
What exactly is advanced? AFAIK, the specs for PSD were only available
(under a usable license at least) until PS 6.0 (or maybe psd version 6.0?).
, so anything added afterwards is hard or impossible to support.


HTH,
Michael

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] ANNOUNCE: gimp-poppler version 0.4.0

2005-06-29 Thread Nathan Summers
gimp-poppler version 0.4.0 has been released.  It can be downloaded at
http://rockwalrus.dyndns.org/~rockwlrs/gimp-poppler . This new version
features thumbnailing and the ability to only load individual pages. 
There are other features; check the NEWS file for details.

Unlike previous versions of gimp-poppler, this version relies on
features only present in the developer's version of GIMP.  At present,
it requires a fairly recent version from CVS.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] preview for scrip-fu plugin?

2005-06-29 Thread pepster

Kevin Cozens wrote:


pepster wrote:

Say I have a scrip-fu plugin (I am thinking about wrap sharp), and I 
want to add a preview window to make it more useful.


Does it mean I must re-write the plugin in C, or is there an easier way?



You would have to re-write it in C. There is no easy way to add a 
preview window to Script-Fu.




I tried to make a start but facing immediate problems. Would appreciate 
some pointers -


 1. The scm code calls the (pdb) plugin plug_in_edge. I am not sure how 
my C plugin can make a call to another plugin??


 2. The preview need to render just a sub-region of the preview 
drawable - but a plug-in such as plug_in_edge need a drawable as 
argument. How does one turn a region into a new drawable?



Thanks, Joseph

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] preview for scrip-fu plugin?

2005-06-29 Thread Nathan Summers
On 6/29/05, pepster [EMAIL PROTECTED] wrote:
 Kevin Cozens wrote:
 
  pepster wrote:
 
  Say I have a scrip-fu plugin (I am thinking about wrap sharp), and I
  want to add a preview window to make it more useful.
 
  Does it mean I must re-write the plugin in C, or is there an easier way?
 
 
  You would have to re-write it in C. There is no easy way to add a
  preview window to Script-Fu.
 
 
 I tried to make a start but facing immediate problems. Would appreciate
 some pointers -
 
   1. The scm code calls the (pdb) plugin plug_in_edge. I am not sure how
 my C plugin can make a call to another plugin??

The way to do this is with one of the gimp_run_procedure functions,
but in this case edge-detection is trivial enough that it doesn't make
sense to call a separate plug-in to do it.
In fact, copying the existing edge-detection plug-in might be the best
way to start.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-29 Thread Sven Neumann
Hi,

michael chang [EMAIL PROTECTED] writes:

 So you can't do something like a two boxes with columns, in a box, and
 then have a list of those boxes?  Something like the way Java Swing
 does GUIs?

You can do that in GTK+ but not in a GtkTreeView. At least not without
writing a very complex cell renderer that combines multiple cell
renderers. It would be extremely difficult to get this right and it is
also a user interface that would be unique (and thus hard to use).
I suggest we stick with the classic GtkCellLayout which packs cell
renderers horizontally.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-29 Thread Sven Neumann
Hi,

we haven't been able to come to a conclusion with regard to the GUI
yet, but that shouldn't keep you from starting to work on layer
locking. It probably makes sense to start implementing this from the
bottom up. Whether you then add a GUI for it into the layer row or
somewhere above the layer list, doesn't really matter much. It will be
easy to change later if there's a need to do that.

So, to get you started, why not add locked flags to the GimpLayer
object and make sure that they are correctly respected by the rest of
GIMP? You will probably also want to add a PDB interface to the new
layer properties. Please ask whenever you need help. It is a lot
easier to ask a few questions than to poke around in the source code
for hours.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Krita news

2005-06-29 Thread David Neary


Hi,

So since planet.gnome.org was down, I went over to planetkde.org to see 
what was happening over there, and I saw this blog entry:

http://www.valdyas.org/fading/index.cgi/hacking/krita/16bits.html

Yesterday, Krita reached a major milestone. We can now load, manipulate 
and save rgba images with 16 bits to the channel.


I thought that might interest some of you - we're not the only game in 
town anymore, I think.


Cheers,
Dave.

--
Dave Neary
[EMAIL PROTECTED]
Lyon, France
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] preview for scrip-fu plugin?

2005-06-29 Thread pepster

Nathan Summers wrote:


On 6/29/05, pepster [EMAIL PROTECTED] wrote:
 


Kevin Cozens wrote:

   


pepster wrote:

 


Say I have a scrip-fu plugin (I am thinking about wrap sharp), and I
want to add a preview window to make it more useful.

Does it mean I must re-write the plugin in C, or is there an easier way?
   


You would have to re-write it in C. There is no easy way to add a
preview window to Script-Fu.

 


I tried to make a start but facing immediate problems. Would appreciate
some pointers -

 1. The scm code calls the (pdb) plugin plug_in_edge. I am not sure how
my C plugin can make a call to another plugin??
   



The way to do this is with one of the gimp_run_procedure functions,
but in this case edge-detection is trivial enough that it doesn't make
sense to call a separate plug-in to do it.
In fact, copying the existing edge-detection plug-in might be the best
way to start.

Rockwalrus
 



And then re-implement gausian filtering, and then re-implement map
bumping and ...  - do you get the picture?

Anyway, gimp_run_procedure2 it is.

Now, how do I create a drawable from the region on the fly?

Thanks, Joseph


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer