Hi,
I certainly don't like the way your patch works. What I
like
instead is a way to get/set GMarkup markup-parser and data
on
your PangoLayout. Then you can get the current parser and
data,
embed them into your own data, and set your own parser and
data
that will fallback to Pango's parser/data for tags it
doesn't
like...
This should let you do what you want, but doesn't allow
implementing arbitrary markup parsers, as it doesn't expose
the
MarkupData struct (and it really shouldn't.) Another
approach is
to go one step further and make the markup-parser paroperty
take
a function with similar signature as pango_parse_markup and
data
so you don't even have to use GMarkup (and GMarkup is not
in the
Pango API currently.) But then you cannot do what you
currently
want to do. Something in between should be possible, I'm
not
sure.
behdad
On Fri, 7 Apr 2006, Kalle Vahlman wrote:
> Hi!
>
> Ever since I decided I'd use a markup tag in my
widgets[1] for
> activatable text and embedding icons, I've been
suffering from my
> crappy C-string foo. I just don't seem to get it right
with C, but the
> reason for that could be motivational too ;)
>
> The idea is to take a string with markup and replace
the tags with
> attributes (both standard pango and custom attributes),
but my code is
> currently far from robust.
>
> The other problem with parsing the tags is that it gets
very tricky
> since you need to do it before parsing the string with
pango (since
> it'll choke on the custom tags) and thus you need to
keep track of the
> attribute indexes by hand so that you know where to
apply them after
> the markup tags are gone.
>
> This made me really want to have the possibility to
extend the pango
> markup language so that I could register my tags there
with a handler
> and have it "just work". So I poked at it
and found out that extending
> pango markup would not be too hard to implement.
>
> The attached patch is a quick stab at it to start the
conversation. It
> seems to work and was trivial to use (when compared to
the hack I had
> to produce earlier  .
>
> What I did was:
>
> - move the MarkupData and OpenTag to a public header
> - ditto for the TagParseFunc type
> - create a pango_markup_register_tag(tag_name,
TagParseFunc) function
>
> So I could simply create a function matching the
TagParseFunc
> signature and call the register_tag with the tag name
and function.
> Internally, the registering happens to a hash table
from which the tag
> names are looked up if they don't match the builtin
ones.
>
> I'm not sure if the MarkupData or OpenTag really offer
things that
> should be available for applications. If not, they
could be wrapped
> away with another function which would just offer the
attribute list.
> But I guess this would depend on the use cases for the
extended tags.
> For my particular uses, simply adding the attributes is
enough.
>
> Overriding the builtin tags should not be allowed in my
opinion, nor
> would queuing old tag handlers really be useful (as the
scope is just
> the application anyway).
>
> Thoughts? Obvious downsides? Am I on crack? Is it Good
crack?-)
>
> [1] http://iki.fi/zuh/scw
>
> --
> Kalle Vahlman, zuh iki.fi
> Powered by http://movial.fi
> Interesting stuff at http://syslog.movial.fi
>
--behdad
http://behdad.org/
"Commandment Three says Do Not Kill, Amendment Two
says Blood Will Spill"
-- Dan Bern, "New American Language"
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
|