Re: [Gimp-developer] writing plug-ins

2004-12-04 Thread Sven Neumann
Hi,

Simbul <[EMAIL PROTECTED]> writes:

> BTW, I noticed the template uses gimp_image_menu_new() which is now
> deprecated. What should I use instead? A ComboBox maybe? (I'll have
> to wait until 2.2 if that's the case, right?)

We will try to release an updated gimp-plugin-template for 2.2. If you
are developing for 2.2, you want to use gimp_image_combo_box_new()
instead.


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


Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers

2004-12-04 Thread Sven Neumann
Hi,

"Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> writes:

> Actually, it doesn't even work on a newly created text layer. No
> parasites in there, checking interactively.

Correct. It would only work in freshly loaded XCF files.
>
> There is one thing to do - The plug-in have to manage text layers on
> it's side, creating itsef the parasites it need to store the
> information. - Just like the old Dyn text. Then, the standard
> text-tool api can be used. The plug-in won't know about any other
> text layers but the ones it creates, thought.

Why should a plug-in do this? Plug-ins shouldn't have to deal with the
hacks that GIMP uses to extend the XCF file format. These hacks might
change at anytime and should become part of the API.


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


Re: [Gimp-developer] Some tests of GIMP startup time over NFS

2004-12-04 Thread Sven Neumann
Hi,

thanks for coming up with these numbers. IMO it's worthwhile to look
at GIMP startup time and see if we can improve things there. I have an
idea that might help in this regard and motivated by your mail, I
think I should try to present it here...

Quite some time seems to be spent reading in data files like brushes,
palettes, patterns, gradients, fonts. This gets worse if you start to
add more than what comes with a default GIMP installation. So it seems
that there's some potential for optimization here. Except for fonts
which are handled somewhat differently, the data types I mentioned all
all derived from a common base class, GimpData. So we should be able
to improve things a lot if we can improve how GimpData loads it's
file.

Or when. There is actually no good reason to load all brushes on
startup, nor all palettes, patterns,... Actually it's more like a
waste of resources to load them all into memory. People would probably
install a lot more data files if that wouldn't make GIMP heavier and
slow down startup.

But as soon as more data files are being added to GIMP, another
problem starts to show up. The lack of categories makes it difficult
to handle large amounts of brushes, palettes, patterns, gradients,
fonts. At some point the list just becomes too long. Now this problem
could be addressed at the same time...

So here's the proposal:

Similar to how plug-ins are cached in pluginrc, we could cache
information about our data files. The brushrc would contain a list of
all brushes. For each brush we would store name, size, filename and
file modification time. Each data item also has a list of categories
it belongs to. The GimpDataEditor can then use this info to group
brushes into folders (see bug #119874). What's missing is a preview of
the brush to use for example in the brush dialog.

Now if there was a PNG thumbnail for each data file, we could read
that image instead. For large brushes and especially for animated
brushes, this should be an improvement. For small brushes it would add
an overhead though. If we have to read a 1000 thumbnail files instead
of a 1000 brush files, that wouldn't improve things at all. However if
we put all brush thumbnails into a single file, that should load
rather fast.  We could then even mmap the file at startup and delay
reading the preview to the point where it is actually needed.

This would reduce data loading at startup to parsing a couple of rc
files, attempting to mmap the preview archive or loading the file into
memory if mmap fails. Only at first startup would we have to scan all
brushes, palettes, patterns, ... GIMP would then write the rc files
and generate a file with thumbnails. On subsequent starts GIMP would
only check that the data files still match the cached versions.

If someone wants to work on this stuff, please speak up. I won't have
time to spend on this feature anytime soon but I would try to help if
somone's interested.


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


[Gimp-developer] Judging panel for splashes

2004-12-04 Thread David Neary
Hi all,

The judging panel for the splash contest is Simon Budig, Alan
Horkan, Michael Schumacher, Joao Bueno and Adam Moss. Since they
were in the first 5 but aren't in the final panel, if there is a
need (for whatever reason) for a replacement judge, the
replacements are Joseph Heled and Roman Joost.

The results will be announced (and the splash committed) before
the end of Friday next week (to give the judges time to judge).

Many thanks to FlamingText.com and sourcewear.com for offerring
to sponsor the competition. Since there can be only one winner,
the prize will be a GIMP t-shirt or polo shirt from
http://sourcewear.com and FlamingText will surely help us out on 
another occasion.

Thanks to everyone who entered splashes so far (and those who
haven't yet but will over the weekend), and to our judging panel
for volunteering - I don't envy them ;)

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