Re: Attribute handling (was: Re: [devel] API changes proposed)

[msevior]

> Am Mittwoch, den 16.03.2005, 08:05 -0300 schrieb 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
>
>   This is very static and we would have problems to extend this scheme
> easily as it would mean to extend the enumeration, recompile the whole
> application (just because the size of the enumeration and the arrays
> changed).
>
>   The other disadvantage is waste of memory: I promise, you don't want
> to have the whole array AND the formatting information stored in memory
> for EACH structure (given my current presentations this would result in
> about 80 arrays of which none would be used).
>
>   So, as long as won't get a dynamic structure for this, I won't accept
> it, because there are still lots of machines with a lot few memory than
> (eg.) mines. We should only store information that we need.
>
>   The main problem we need to fix is to have a dynamic structure that
> keeps the formatting information and that provides information about
> whether or not an attribute is set.

Amybe an idea from AbiWord can help here. We store our attributes as const
char * strings. As you point out this makes the scheme very extensible.
You can just define new properties and values as you need them.

The problem of memory consumption is (partially) solved by only storing
each unqiue collection of attributes in an array data structure which
accessed by a unique integer identifier.

So every block with identical attributes has the same identifer. You don't
store N copies of the same attributes you just store 1.

During the editting phase each set of attributes is compared to the list
already record. If it's unique, it's added to the list and given a new
identifier.

This might help.

Good luck with the project, it's great to see you hacking again Sven!

Martin


>
> 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
>