Re: [Gimp-developer] Histogramm Like Widget

[Alexey V.Chaykin]

- Original Message -
From: Sven Neumann [EMAIL PROTECTED]
To: Alexey V.Chaykin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 3:49 AM
Subject: Re: [Gimp-developer] Histogramm Like Widget


 Hi,

 GIMP 2.0 has a histogram widget but it used by the core only and is
 not exposed to plug-ins. It would be nice to get an idea of the API
 you would expect from such a widget. The GimpHistogramView we use in
 the core is too much bound to the core data structures to be moved to
 libgimpwidgets as is:

   http://developer.gimp.org/api/2.0/app/GimpHistogramView.html

 But it would certainly be a good idea to have libgimpwidgets provide a
 histogram widget. So if you can tell us what you need more
 specifically, that would help a lot. Such development would of course
 not happen in the 1.2 tree but based on the current state of the code,
 that is GIMP 2.0.

Ok, probably I need somthing like this:

GtkWidget-GimpHistWidget
GimpHistWidget* gimp_histogram_new();
void gimp_histogram_set_data(int* y_vals, int* x_vals, int size);
void gimp_histogram_read_data(int** y_vals, int** x_vals, int* size);
void gimp_histogram_set_callback(GimpCallBack* callback); // sets callback
on user-select-action of histogram diapazon (like in core Histogramm
widget), widget provides callback with information of x0 and x1 of diapazon
void gimp_histogram_delete(GimpHistWidget* histogram);

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

[Gimp-developer] PDB requirements (was: PDB named and default parameters)

[Nathan Carl Summers]

On Sun, 21 Mar 2004, Manish Singh wrote:

 On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:
  How far along is the planning? I have heard of Rock's libpdb,
  which I believe he wants to finish for 2.2, but I hadn't heard
  any concrete plans for the often-mentioned forthcoming PDB
  re-write.

 There hasn't been any real planning, other than planning to do some planning
 after 2.0 is out. All I was saying is that we haven't forgot about it.

2.0 is out now. :)

  What requirements would the new PDB have?

 There's a number of issues to be addressed, like GEGL node support,
 efficiency, UI generation, distributed processing, and macro recording
 support.

Macro recording is already trivial with libpdb: you just connect to the
appropriate signal of the Pdb object.

Distributed processing will soon be supported by libpdb using the
WireSocket backend; this will be done by early May.  Implementing
WireSocket is one of the group projects chosen by some of the students in
a class I am taking, so it will be done if they want a good grade. :)

UI generation is mostly out of the scope of libpdb.  I would have to know
more what is specifically meant by UI generation before I could comment
on it.


Efficiency has yet to be addressed by libpdb, although some easy
optimizations have been put in place.  Serious optimization should
probably wait until the feature requirements are more in place and
reasonable profiling can be done.

GEGL node support opens a big can of worms, and there probably is no best
solution.  The first big decision to make is whether plug-ins should be
written as GEGL nodes objects directly, or whether there should be a shim
GEGL node that translates the operations into procedural calls not unlike
those in the traditional GIMP api.

If we do use a translating shim, Libpdb seems like a good fit for this as
well.

It seems like a real shame to lose GIMP's ability to run plug-ins out of
process, so my vote is we rule out dynamically loading gegl nodes using
GPlugIn as the only method, although we may want to be able to do it as
an additional extra-fast method.

CORBA seems like a flexible choice here if we decide to make plug-ins
implemented directly as gegl nodes. Although my guess is it would add
somewhat more overhead than a hand-rolled gimp-specific method, it has the
advantage of being more flexible than anything we could do, and also it
would be something maintained by an outside group instead of another
burden for us.

If we do decide to have plug-ins be native GeglNodes, I recommend that we
still have a PDB for scripting purposes.

Rockwalrus

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