On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: > On Sun, 21 Mar 2004, Manish Singh wrote: > > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: > > > 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. Have you given any thought on how to macroize interactive paint functions? > 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. :) Heh. Maybe local UNIX sockets are faster than pipes. Would be good to benchmark. > 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. Generate a UI from a PDB entry. Like a generalized -fu that the scripting languages currently have. This makes an easy way of generating property panes for nodes in a graph say, made out of PDB nodes. > 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. Yeah. For macro recording things should to go through the PDB in the app itself, so the within process boundary case things should be lightweight and fast. > 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. Yes, that's undetermined. > 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. I dunno. CORBA is pretty heavyweight, there isn't an ORB out there that does things efficiently. > If we do decide to have plug-ins be native GeglNodes, I recommend that we > still have a PDB for scripting purposes. A node has inputs and outputs, and so do PDB functions, so there isn't much difference there. I've thought about doing a proxy GObject framework, which would allow IPC of arbitrary objects, but I haven't fleshed it out in my mind yet. One thing I've thought about would be to use the object and type system features, like every PDB function is an object, with properties for parameters. A paramspec has everything we need: type, name, descriptions, defaults, possible bounds. Maybe something like a PDB function is an object, you set properties on it, then run the execute method. Also have a print method for a textual representation. Then just instantiate and string together these objects, and run through then. Sort of like CellRenderers in GtkTreeView. This might be a complete and total abuse of the object system tho, and not scale at all. I might do a quicky implementation and see. Using paramspecs somehow is tempting though. -Yosh
