Re: [devel] API changes proposed

[eazel7]

On Wed, 16 Mar 2005 09:36:21 +0100, Sven Herzberg <address@hidden> wrote:
> Am Samstag, den 05.03.2005, 22:05 -0300 schrieb Ezequiel Pérez:
> > · The comparission block/whatever <> template attributes can't set
> > permanent changes in an attribute independent from the template, I think
> > it'd be better an cria_block_is_set (CriaBlockAttribute attribute)
> > function being CriaBlockAttribute an enum and adding in the CriaBlock
> > private structure an boolean array for with the setted values of those
> > attributes. - A decission at this point would help me to do not code
> > twice the writer
> 
>   Please suggest some API and not just "this need to change". I fell
> very uncomfortable with your idea of having an "is_set" function for
> each attribute.
there is just one is_set function, not one for each attribute.
I'm not watching the code right now, but this would give you an idea
of what I mean:

typedef enum {
  CRIA_BLOCK_COLOR,
  CRIA_BLOCK_FONT_FAMILY,
  CRIA_BLOCK_FONT_BOLD,
  CRIA_BLOCK_BG_COLOR,
  CRIA_BLOCK_BORDER_WIDTH,
  CRIA_BLOCK_BORDER_COLOR,
  CRIA_BLOCK_LAST_ATTR
} CriaBlockAttribute;
// and etcetera

typedef struct {
//...
  gboolean set_attr[CRIA_BLOCK_LAST_ATTR];
//...
} CriaBlock;

//this function to know if the value is set specifically for that element, 
//if not it shouldn't be written to the specific block source
//on the xml (or whatever be the format)
gboolean
cria_block_is_set (CriaBlock *block, CriaBlockAttribute attr)
{
  return block->set_attr[attr];
}

//this function to set/unset the attribute when setting it's
//attr specifically for that block or taking it from the tamplate
void
cria_block_set_attr (CriaBlock *block, CriaBlockAttribute attr, gboolean val)
{
  block->set_attr[attr] = val;
}

there's no need to write more than one is_set function

> 
> > · To use the red:green:blue format at the xml instead the #rrggbb will
> > simplify the color writing and let us use the libxml function
> 
>   We should definitely support the #rrggbb format; if you want the other
> format too, then add code to the parser that understands it and then add
> the necessary code to the presentation-writer.
ok
> 
> > · Clarify the use of the GORect or replace the coordinates system, and I
> > rather an relative system instead a coordinates based one. That would be
> > better when changing the screen size or the slide default size.
> 
>   Where's the problem with GORect and the coordinates?
I think that it'd be better to use a float value to define the
position of the elements, using a fractionary value. if the
presentation is 640x480 and a tittle block is centered at 20%left and
20% right margins, 0.2 and 0.8 values are enough to keep that
proportion if the presentation area changes to 800x600. but this is
just a idea.
> 
> Regards,
>   Sven
> --
> Sven Herzberg <address@hidden>    · GNOME Deutschland <www.gnome.de>
> Jabber <address@hidden>         · ICQ <177176642>
> GnuPG <F020 B158 2696 6D6A 2870 F53C 0565 FD6B B1C3 0AFE>
> Criawips <www.nongnu.org/criawips>· GnomeGCJ <gnome-gcj.sourceforge.net>
> 
> 
> _______________________________________________
> criawips-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/criawips-devel
> 
> 
> 
>