Re: Color fonts

[Matthias Clasen]

On Thu, Jun 29, 2017 at 11:18 PM, Matthias Clasen  wrote:

> I had another go at this here:  https://github.com/
> matthiasclasen/cairo/tree/emoji-again
>

I've spent some more time on this branch. It now uses paint only for
clusters that consists
purely of color glyphs, rewriting the inputs to remove handled clusters,
and then falls through
the show_glyphs code paths.

It seems to work ok, at least as far as gedit / pango let me test easily.
I'm less confident that
the CAIRO_TEXT_CLUSTER_FLAG_BACKWARD case is entirely correct, that is hard
for me
to judge.

An unrelated observation: pango treats the gap between an emoji modifier
base and a variant selector
as a cursor position. That looks like a bug.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

On Jun 30, 2017 7:51 PM, "Matthias Clasen"  wrote:

On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> Hi,
>
> On 28.06.2017 14:23, Behdad Esfahbod wrote:
> > All of you have asked me about the status of color fonts in
> > cairo.  There's
> > some discussion here:
>
> what was the solution to make this fit into cairo's drawing model?
> Text
> / glyphs are used as a mask and a mask does not have colors.
>

There is no solution to that. The assumption in cairo's drawing model
about glyphs/fonts has simply been invalidated by reality.


Correct.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Matthias Clasen]

On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> Hi,
> 
> On 28.06.2017 14:23, Behdad Esfahbod wrote:
> > All of you have asked me about the status of color fonts in
> > cairo.  There's
> > some discussion here:
> 
> what was the solution to make this fit into cairo's drawing model?
> Text
> / glyphs are used as a mask and a mask does not have colors.
> 

There is no solution to that. The assumption in cairo's drawing model
about glyphs/fonts has simply been invalidated by reality.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_signal_connect() and G_OBJECT

[Emmanuele Bassi]

The first argument of `g_signal_connect()` is a gpointer (i.e. a
`void*`), so you don't need a cast at all — C will implicitly cast any
pointer to `void*`, and from `void*` to any other pointer.

Additionally, as you discovered, signals are GTypeInstance features —
you can emit signals on anything that inherits from GTypeInstance, not
just GObjects.

The reason why you see a cast macro is a layer of "extra security":
you can check that you're passing the object you meant to be passing,
instead of a NULL pointer or some garbage. This "extra security" is
mostly cargo-culted through tutorials, so people learn the habit and
transmit it.

Personally, I find it pointless; internal state should be checked with
`g_assert()`, and all cast macros can be compiled away with
`G_DISABLE_CAST_CHECKS`, so that buys you almost nothing.

Ciao,
 Emmanuele.

On 30 June 2017 at 11:20, Ingo Brückl  wrote:
> Hi,
>
> it seems that it was common practice to cast the first argument of
> g_signal_connect() to G_OBJECT when I started developing applications with
> GTK+ quite a while ago. At least I've learned it that way and am doing it
> ever since.
>
> I repeatedly see usage of g_signal_connect() without that cast which seems
> to make sense since "instance" only has to be a gpointer and will be checked
> G_TYPE_CHECK_INSTANCE at run time.
>
> So I'm just curious. Is/was there a reason for the G_OBJECT cast? Was it
> necessary back in the days (when GTK+ 2 took over from GTK+ 1)?
>
> Ingo
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Color fonts

[Bastien Nocera]

On Thu, 2017-06-29 at 23:18 -0400, Matthias Clasen wrote:
> I had another go at this here:  
> https://github.com/matthiasclasen/cairo/tree/emoji-again

I rebased your old branch on top of 1.14.10 (the current stable):
https://fedorapeople.org/~hadess/emoji/cairo-emoji-5-rebased-on-1.14.10.patch
for posterity more than anything.

I've also updated the COPR. Installing both packages in there should
get you colored emojis in Characters and other GTK+ 3.x apps.

https://copr.fedorainfracloud.org/coprs/hadess/emoji/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

g_signal_connect() and G_OBJECT

[Ingo Brückl]

Hi,

it seems that it was common practice to cast the first argument of
g_signal_connect() to G_OBJECT when I started developing applications with
GTK+ quite a while ago. At least I've learned it that way and am doing it
ever since.

I repeatedly see usage of g_signal_connect() without that cast which seems
to make sense since "instance" only has to be a gpointer and will be checked
G_TYPE_CHECK_INSTANCE at run time.

So I'm just curious. Is/was there a reason for the G_OBJECT cast? Was it
necessary back in the days (when GTK+ 2 took over from GTK+ 1)?

Ingo
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list