Re: gtk-mailund-980804-0.patch.gz
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list redhat com
- Cc: Tim Janik <timj gtk org>, Gtk+ Devils <gtkdev gtk org>
- Subject: Re: gtk-mailund-980804-0.patch.gz
- Date: 06 Aug 1998 11:46:03 -0400
Thomas Mailund Jensen <mailund@daimi.aau.dk> writes:
> This looks great!
>
> One thing though...what exactly will be the sematics of inserting data
> with a give key on an interval.
>
> E.G. [some text, a link, some text with with some hidden text]
> | | |
> - V V
> ("link", <<>>) ("hidden", <<>>)
>
> Let us say this is a text with 3 properties, where prop. 0 has no user
> data, prop. 1 has a link, and prop. 2 has "hidden" text as
> data. Adding data with keys not in the intervals current list is
> simple, if we add a link to hidden in prop. 2 we get:
>
> [some text, a link, some text with with some hidden text]
> | | | | |
> - V V V V
> ("link", <<>>)("hidden", <<>>) ("link",<<>>)("hidden", <<>>)
> |
> V
> ("hidden", <<>>)
>
> so we now have 5 prop.
>
> But if we then want to make the entire text a link (with different
> data), what would we get? Eigther:
>
> [some text, a link, some text with with some hidden text]
> | |
> V V
> ("link", <<>>) ("link",<<>>)
> |
> V
> ("hidden", <<>>)
>
>
> or
>
> [some text, a link, some text with with some hidden text]
> | | | | |
> V V V V V
> ("link",<<>>) ("link", <<>>)("link", <<>>)("link",<<>>)("link", <<>>)
> | | | |
> V V V V
> ("link",<<>>)("hidden", <<>>)("link",<<>>)("hidden",<<>>)
> |
> V
> ("link",<<>>)
>
> In the first the old "links" in the text is replaced (and equal
> properties is merged), in the other we remember the old links.
>
> On a following lookup they will behave equally, the topmost (the new)
> link will be found.
>
> With the first we reduce the number of properties, with the other we
> could get a stack-like behaviour of the user data. (if we add a
> pop/delete-data function).
>
> The complexity of the two is about the same...which one do we want? I
> only need the first solution for my editor...but perhaps someone else
> would like the stack solution.
>
> well...that's just my thougths...
I'd prefer the first - partly from the standpoint that it is
simpler, partly from the standpoint that it doesn't make sense
to me to have multiple identical properties on the same bit
of text (The GtkObject code that Tim wants to reuse can't
handle it), and partly because I think it will
be more compatible with a future rewrite of the text widget.
(I'm thinking that a future rewrite of the Text widget will
probably go to a heirarchical structure - sort of XML like -
instead of the current flat property list, which each
node having a set of properties attached to it. Properties
in child nodes will override properties on parent nodes.
In that future scheme, it will make sense to have multiple
identical properties on a single bit of text, though only
one will apply at once, and only one would be specified
per node. So the first scheme would just be, in some sense,
a special case of that - with a completely flat tree, while the
second scheme wouldn't really map onto a heirarchy at all.)
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]