Re: [guppi-list] a guppi-based app

[Jon Trowbridge <trow emccta com>]

On Wed, Oct 11, 2000 at 04:43:13PM +0200, Daniel Kottow wrote:
> i have actually build something which uses guppi...
> its called cluster-senses and is supposed to allow interactive
> examination of cluster models, specially finite mixture models. go
> http://www.inf.tu-dresden.de/~dk17/cluster-senses to find out
> more. 

Cool ---  your screen shots look really nice. 
 
> 1a) when building a barchart object (guppi-object-barchart) the font
> type is not considered on the categorical axis.

The font needs to be set separately on the axis.

> 1b) it is not possible to use "" as a categorical axis label

This is a bug.  I've fixed it in my local tree, and I'll send it off
to CVS (along with some other goodies) later today.

> 2) i had trouble using guppi_seq_scalar_append_repeating, crashes
> ocurred...

I can't reproduce this.  Can you provide more details, or a backtrace?

> 3) in my app i destroy some guppi-object-xxx and build new ones,
> including widgets. by that, the parent window gets confused with the key
> handling, as if it still were connected to the destroyed objects. you
> can try this out easily if you load two cluster definition files in
> cluster-senses and then press a key over a histogram window. (seems like
> i really would appreciate someone trying cluster-senses..)

Some Guppi objects might not be properly disconnecting all of their
signals when they are destroyed.  I'll look into this.

> 4) i had problems using the autoconf example which is on the CVS server
> under guppi3. AC_PROC_LIBTOOL was somehow unknown by autoconf and i
> ended up copying a whole section of LIBTOOL stuff from configure.in in
> guppi.

Sounds like your libtool isn't properly installed.  You should have a
libtool.m4 file somewhere like /usr/share/aclocal.

> i will start talking rather freely now...

> all the plug-in thing gave me pretty much complications. once i started
> linking directly against the plug-ins, everything got easier, since i
> could just call the "member" functions. 

I guess I've always figured that people using C should manipulate
the plug-ins via gtk_object_{get,set}.  Maybe that is excessively
inconvenient. :-/

One option might be to have plug-ins install their .h files under
their directories.  (In case anyone hasn't checked recently, plug-ins
are no longer just a .so file, but a whole directory --- this allow
plug-ins to keep all related files (images, .glade files, etc. as well
as the .so file) in one place.  Credit for this very good idea goes to
Jody.)  Then we could add some args to guppi-config for dealing with
plug-ins.  So

  guppi-config --cflags scatter axis foo bar 

would return the compiler args required to be able to #include from
the various plug-in directories.  We could signal an error if any of
the needed plug-ins were missing --- this could be used in
configure.in files to require certain plug-ins for certain guppi-using
apps.

> consider also that it is virtually not possible now to write new
> plug-ins and try them with guppi installed, unless you compile them into
> the guppi plug-in dir...hackhack

You can manually change the plug-in search paths using the
guppi_plug_in_path_*() functions defined in guppi-plug-in-spec.h.
Hacky, but I don't know of a better way to handle this.

> at the beginning i started with libguppitank, but of course it was to
> limited. i think there is missing some intermediate level between the
> plug-ins, which are very very modular (so i always kept avoiding their
> proper initialization) and the tank. 

Guppi now supports "composite plug-ins", which lets you build a new
plot plug-ins up out of other plot plug-ins, complete with custom
layouts and config dialogs.  The idea is that composite plug-ins
should combine very low-level plug-ins into more manageable,
higher-level constructs.

Composite plug-ins are actually easier to write that "standard"
plug-ins -- see the "xybox" plot plug-in for a simple example.

> some comments also on performance. for manipulating guppi-data objects i
> used guppi_seq_scalar_raw(). this improved the performance like a 1000%
> over the element access guppi_seq_scalar_get(). 

Yes.  guppi_seq_scalar_raw() lets you directly access a chunk of
memory, whereas guppi_seq_scalar_get() requires multiple function
calls for each lookup.  Remember, though, that not all GuppiSeqScalars
will be able to support raw look-up, in which case
guppi_seq_scalar_raw() will return NULL.  (One example of this is
"functional" GuppiSeqScalars where each sequence value is calculated
on-the-fly, rather than being stored in a block of memory somewhere.)
So for maximum efficiency and generality, you should probably do
something like this:

gconstpointer seq_raw;
gint seq_stride;

seq_raw = guppi_seq_scalar_raw (my_seq_scalar, &seq_stride);

/* Look up the i-th item, put it in x */

x = seq_raw ? guppi_seq_scalar_raw_get (seq_raw, seq_stride, i) :
              guppi_seq_scalar_get (my_seq_scalar, i);

This will give you super-fast lookups when possible, and will use the
slow interface otherwise.


> finally i have a question concerning the plug-in libraries. currently i
> am hard wiring the PLUG_IN_DIR (of an installed guppi) in my configure.
> can you think of an easy way to circumvent that? (i am really no
> configure freak) or are you going to change things soon in that
> direction?

Well, you shouldn't really need to access the PLUG_IN_DIR.  But maybe
that information should be made available via guppi-config or
something like that.

-JT

-- 
GNU/Linux: Free your mind and your OS will follow.