Re: [g-a-devel] RFC: AtkText simplification (take 2)

[Trevor Saunders <trev saunders gmail com>]

>   b) Add the generic boundary now. The enum would be something like:
>     typedef enum {
>       ATK_TEXT_BOUNDARY_CHAR,
>       ATK_TEXT_BOUNDARY_WORD_START,
>       ATK_TEXT_BOUNDARY_WORD_END,
>       ATK_TEXT_BOUNDARY_SENTENCE_START,
>       ATK_TEXT_BOUNDARY_SENTENCE_END,
>       ATK_TEXT_BOUNDARY_LINE_START,
>       ATK_TEXT_BOUNDARY_LINE_END
>       ATK_TEXT_BOUNDARY_WORD,
>       ATK_TEXT_BOUNDARY_SENTENCE,
>       ATK_TEXT_BOUNDARY_LINE
>     } AtkTextBoundary;

why not define the enum like this

     typedef enum {
       ATK_TEXT_BOUNDARY_CHAR,
       ATK_TEXT_BOUNDARY_WORD_START,
       ATK_TEXT_BOUNDARY_WORD_END,
       ATK_TEXT_BOUNDARY_SENTENCE_START,
       ATK_TEXT_BOUNDARY_SENTENCE_END,
       ATK_TEXT_BOUNDARY_LINE_START,
       ATK_TEXT_BOUNDARY_LINE_END
       ATK_TEXT_BOUNDARY_WORD = ATK_TEXT_BOUNDARY_WORD_START,
       ATK_TEXT_BOUNDARY_SENTENCE = ATK_TEXT_BOUNDARY_SENTENCE_START,
       ATK_TEXT_BOUNDARY_LINE = ATK_TEXT_BOUNDARY_LINE_START
     } AtkTextBoundary;

Since the start and generic constants have the same meaning I don't see
a reason they can't have the same value and that way you never need to
break ABI just source code compatability.

Trev

> Right now I prefer a). The main problem with b) is that we would have
> three pairs of macros that would mean exactly the same. Of course, the
> main problem of a) is that we don't have right now a specific schedule
> for the API break so that means that we don't yet when the generic
> boundary would be added (FWIW, this is another candidate for our list of
> ATK3 bugs).
>
> BR
>
> -- 
> Alejandro Piñeiro Iglesias
>
>
> _______________________________________________
> gnome-accessibility-devel mailing list
> gnome-accessibility-devel gnome org
> https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel