Re: [Gimp-developer] tool plug-in changes

2002-02-23 Thread Sven Neumann

Hi,

Nathan C Summers [EMAIL PROTECTED] writes:

 I am going to need to make some changes to facilitate tool plug-ins.  
 First, a good amount of code needs to be shared between the core and the
 plug-in.  I've split off a libgimptool to contain this code.
 
 Second, a lot of the information contained in the gimptool object needs to
 be syncronized between corespace and pluginspace.  Currently, these
 members of the struct are accessed directly, so this isn't possible.  
 I've split off a class called GimpToolControl that encapsulates this
 information.  GimpToolControl on the plugin side will know how to
 syncronize with the core.
 
 Any comments?  I will probably commit tommorow.

well, if you want us to comment on your changes before you commit them,
you should probably post a patch. Since this is a substantial change,
I'd very much appreciate if you did.


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



[Gimp-developer] GIMP from CVS now needs intltool to build

2002-02-23 Thread Sven Neumann

Hi,

I should probably inform you of the change I've committed to CVS
yesterday since it involves anyone who builds gimp-1.3 from CVS.
The build from CVS now depends on intltool. intltool is a set of
perl scripts available from 

  ftp://ftp.gnome.org/pub/GNOME/stable/sources/intltool/

Chances are that your distribution has it already packaged for
you. The intltool collection can be used to do these things:

 o Extract translatable strings from various source files (.xml.in,
   .glade, .desktop.in, .server.in, .oaf.in).

 o Collect the extracted strings together with messages from
   traditional source files (.c, .h) in po/$(PACKAGE).pot.

 o Merge back the translations from .po files into .xml, .desktop
   and .oaf files.  This merge step will happen at build respective 
   installation time.

It also replaces the update.sh and update.pl scripts that used to live
in the po directories.

We need this especially to solve the problem of translating the GIMP
tips file. I'll check in a new tips file later that is XML formatted
and we will use intltool to extract strings for translators and to
merge the translations back into the XML file.

At the moment intltool is already used to handle translation of the
gimp-1.3.desktop file for the GNOME-2.0 menu I've checked in
yesterday. BTW, if someone wants to contribute a similar file so 
we register ourselves in the KDE menu, please contact me.

You will only need intltool if you build from CVS. All the necessary
tools will be contained in the tarball created by 'make dist', so
this change doesn't affect the casual user who wants to build The
GIMP from tarball.

Please let me know if these changes introduced any problems for you...


Salut, Sven

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



[Gimp-developer] Problem deleting mask saved to channel

2002-02-23 Thread Cindy Huyser

Hello, all,

I'm in the process of writing a little plug-in that will automate the
process of converting a selection to a mask. My goal is to add a layer
to the image containing the mask made from the selection. The outline of
my process is:

1) Save the selection to a channel
2) Duplicate the original layer
3) Add alpha to the original and duplicate layers
4) Add a layer mask (transparent/black) to the duplicate layer
5) Copy the selection mask saved as a channel
6) Paste the copy buffer onto the duplicate layer
7) Anchor the pasted layer
8) Delete the selection mask channel

I've been everything except for deleting the selection mask channel.  So
far, I've tried:

1) calling gimp_channel_delete() on the channel ID, either preceded by
gimp_selection_clear() or by itself.  The call returns TRUE.
2) calling gimp_drawable_delete() on the channel's drawable, with and
without preceding it by a call to gimp_drawable_detach().

I flush and update the drawable for the duplicated layer when the
routine is finished, as I do the drawable associated with the saved
selection mask (except, course, when I call delete() on the selection
mask channel). 

In every case, the selection mask channel remains visible in the Layers
dialog.  I have been working with a grayscale test image, so the
selection channel mask and gray channels are the only channels that
appear in the dialog.

I'm still pretty much a newbie at doing this, so I'm sure there's
something I've overlooked. Any ideas?

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



Re: [Gimp-developer] tool plug-in changes

2002-02-23 Thread Nathan C Summers

On 23 Feb 2002, Sven Neumann wrote:
 Nathan C Summers [EMAIL PROTECTED] writes:

[snip]

  a good amount of code needs to be shared between the core and the
  plug-in.  I've split off a libgimptool to contain this code.

[snip]

  Any comments?  I will probably commit tommorow.
 
 well, if you want us to comment on your changes before you commit them,
 you should probably post a patch. Since this is a substantial change,
 I'd very much appreciate if you did.

No problem.  An annotated patch is available at 
http://www.gimp.org/~rock/libgimptool-patch.gz

The main issue with this patch is that libgimptool needs some knowledge of 
various enums and structs that normally shouldn't be known outside of the 
core, such as GimpObject and the various cursor enums.  I'm not sure 
exactly which is the best way to expose these things to the library.  We 
could put them in their own library, or we can create our own header files 
along the lines of the EK and DOUBLE EEK sections of 
libgimpgimptool.h, or we, at some penalty in the size of the binary, can 
create some perl magic that keeps the pluginspace and corespace header 
files binary compatible, and forgo all code sharing, or we can play with 
the -I's in the Makefile.am such that the core header files work (which 
would in practical terms say that there is no real separation between 
core and libgimptool.)

Any comments would be appreciated.

Rockwalrus

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