Linking to libstdc++ in HarfBuzz

[Behdad Esfahbod]

Hi,

Just asking, does anybody still object about using C++ standard library
(ie. linking to it) in HarfBuzz?

I know I've been one of the bigger opponents myself.  But I can change too.
:)

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

Re: [cairo] color fonts and CAIRO_OPERATOR_SOURCE

[Behdad Esfahbod]

On Wed, Sep 13, 2017 at 11:07 AM, Bill Spitzak <spit...@gmail.com> wrote:

> On Mon, Sep 11, 2017 at 10:39 PM, Behdad Esfahbod <beh...@behdad.org>
> wrote:
> > It was actually not that complicated:
> > https://bugs.freedesktop.org/show_bug.cgi?id=102661
>
> Yes that sounds just like my second suggestion.
>
> To deal with the double-premultiply, I would just special-case OVER
> (and perhaps a few other bounded operators). They cause the current
> code to be run where it uses the glyph color+alpha as the source. All
> other compositing operators ignore the glyph color, and use the glyph
> alpha as the letter shape.
>
> SOURCE can then be used to fill the glyph shapes with a constant color.
>

I'm not sure how I feel about that.


> >
> > On Mon, Sep 11, 2017 at 1:44 AM, Uli Schlachter <psyc...@znc.in> wrote:
> >>
> >> Hi everyone,
> >>
> >> yesterday I was asked to comment here:
> >>
> >> https://github.com/i3/i3/pull/2925
> >>
> >> The issue seems to be: With operator SOURCE, drawing a color glyph
> >> clears the entire surface. So, while "normal" glyphs are supposed to be
> >> a mask that is then filled, color glyphs seem to be handled as an
> >> unbounded source. This doesn't make a difference for OVER, but for lots
> >> of other operators (at least SOURCE) it obviously matters.
> >>
> >> I didn't investigate this at all. I did not even try to reproduce.
> >> Hence, this ping. Could one of you please look at this, confirm this
> >> really happens, and say what should be done about this? Thanks.
> >>
> >> And yes, in the thread on color fonts, Matthias Clasen answered one of
> >> my questions with:
> >>
> >> >> Okay... so what is the new model? What happens when I draw a color
> >> >> glyph
> >> >> with operator XOR and a red source?
> >> >
> >> >
> >> > The red source is ignored for color glyphs because they are used as
> the
> >> > source.
> >>
> >> So apparently this behaviour is by design, meaning that glyphs can only
> >> really be used with operator OVER any more (well, and some others). So
> >> let me ask this another why: Is this really a good behaviour?
> >>
> >> Oh and one more thing: Who updates cairo's docs and all the explanations
> >> on the web page? ("glyphs work like this, except when they do not").
> >>
> >> Cheers,
> >> Uli
> >>
> >> P.S.: The list of recipents is copied from the recent thread on color
> >> fonts. I have no overview of how people ended up in this list. Sorry if
> >> $YOU are the wrong recipent.
> >> P.P.S: Yes, I also included Gtk-devel-list. I vaguely remember someone
> >> saying that this stuff is relevant there. Dear moderator, sorry for the
> >> work that this causes you.
> >> --
> >> 99 little bugs in the code
> >> 99 little bugs in the code
> >> Take one down, patch it around
> >> 117 little bugs in the code
> >>   -- @irqed
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> > --
> > cairo mailing list
> > ca...@cairographics.org
> > https://lists.cairographics.org/mailman/listinfo/cairo
>



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

Re: color fonts and CAIRO_OPERATOR_SOURCE

[Behdad Esfahbod]

It was actually not that complicated:
https://bugs.freedesktop.org/show_bug.cgi?id=102661

On Mon, Sep 11, 2017 at 1:44 AM, Uli Schlachter  wrote:

> Hi everyone,
>
> yesterday I was asked to comment here:
>
> https://github.com/i3/i3/pull/2925
>
> The issue seems to be: With operator SOURCE, drawing a color glyph
> clears the entire surface. So, while "normal" glyphs are supposed to be
> a mask that is then filled, color glyphs seem to be handled as an
> unbounded source. This doesn't make a difference for OVER, but for lots
> of other operators (at least SOURCE) it obviously matters.
>
> I didn't investigate this at all. I did not even try to reproduce.
> Hence, this ping. Could one of you please look at this, confirm this
> really happens, and say what should be done about this? Thanks.
>
> And yes, in the thread on color fonts, Matthias Clasen answered one of
> my questions with:
>
> >> Okay... so what is the new model? What happens when I draw a color glyph
> >> with operator XOR and a red source?
> >
> >
> > The red source is ignored for color glyphs because they are used as the
> > source.
>
> So apparently this behaviour is by design, meaning that glyphs can only
> really be used with operator OVER any more (well, and some others). So
> let me ask this another why: Is this really a good behaviour?
>
> Oh and one more thing: Who updates cairo's docs and all the explanations
> on the web page? ("glyphs work like this, except when they do not").
>
> Cheers,
> Uli
>
> P.S.: The list of recipents is copied from the recent thread on color
> fonts. I have no overview of how people ended up in this list. Sorry if
> $YOU are the wrong recipent.
> P.P.S: Yes, I also included Gtk-devel-list. I vaguely remember someone
> saying that this stuff is relevant there. Dear moderator, sorry for the
> work that this causes you.
> --
> 99 little bugs in the code
> 99 little bugs in the code
> Take one down, patch it around
> 117 little bugs in the code
>   -- @irqed
>



-- 
behdad
http://behdad.org/
___
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]

07fd51fa11ad8 in gtk_container_propagate_draw (container=conta
> iner@entry=0x39ca18d030, child=0x39ca2b1860, cr=cr@entry=0x39ca4fc8b0)
> at gtkcontainer.c:3838
> #99 0x7fd51fa11bc2 in gtk_container_draw (widget=0x39ca18d030,
> cr=0x39ca4fc8b0) at gtkcontainer.c:3658
> #100 0x7fd51fc3b5b3 in gtk_window_draw (widget=0x39ca18d030,
> cr=0x39ca4fc8b0) at gtkwindow.c:10214
> #101 0x7fd51fc2d7cb in gtk_widget_draw_internal
> (widget=0x39ca18d030, cr=0x39ca4fc8b0, clip_to_size=) at
> gtkwidget.c:7017
> #102 0x7fd51fc36b38 in gtk_widget_render (widget=widget@entry=0x39c
> a18d030, window=0x39ca441320, region=) at
> gtkwidget.c:17512
> #103 0x7fd51fad7239 in gtk_main_do_event (event=) at
> gtkmain.c:1824
> #104 0x7fd51f5eb465 in _gdk_event_emit (event=event@entry=0x7ffc9f2
> 97450) at gdkevents.c:73
> #105 0x7fd51f5fb7a5 in _gdk_window_process_updates_recurse_helper
> (window=0x39ca441320, expose_region=) at
> gdkwindow.c:3849
> #106 0x7fd51f5fc9a6 in gdk_window_process_updates_internal
> (window=0x39ca441320) at gdkwindow.c:3995
> #107 0x7fd51f5fcba0 in gdk_window_process_updates_with_mode
> (window=, recurse_mode=) at
> gdkwindow.c:4189
> #108 0x7fd51db8d57d in g_closure_invoke () at /lib64/libgobject-
> 2.0.so.0
> #109 0x7fd51dba0e4e in signal_emit_unlocked_R () at
> /lib64/libgobject-2.0.so.0
> #110 0x7fd51dba9975 in g_signal_emit_valist () at
> /lib64/libgobject-2.0.so.0
> #111 0x7fd51dbaa2df in g_signal_emit () at /lib64/libgobject-
> 2.0.so.0
> #112 0x7fd51f5f428f in _gdk_frame_clock_emit_paint
> (frame_clock=) at gdkframeclock.c:640
> #113 0x7fd51f5f49c1 in gdk_frame_clock_paint_idle
> (data=0x39ca024270) at gdkframeclockidle.c:430
> #114 0x7fd51f5dfb20 in gdk_threads_dispatch (data=0x39ca169d60) at
> gdk.c:743
> #115 0x7fd51d8b3ffd in g_timeout_dispatch () at /lib64/libglib-
> 2.0.so.0
> #116 0x7fd51d8b3597 in g_main_context_dispatch () at
> /lib64/libglib-2.0.so.0
> #117 0x7fd51d8b3938 in g_main_context_iterate.isra () at
> /lib64/libglib-2.0.so.0
> #118 0x7fd51d8b39cc in g_main_context_iteration () at
> /lib64/libglib-2.0.so.0
> #119 0x7fd51e3ea89d in g_application_run () at /lib64/libgio-
> 2.0.so.0
> #120 0x0039c94fddda in main ()
>
>
> On Sat, 2017-07-29 at 17:43 +0100, Behdad Esfahbod wrote:
> > Should be fixed.  Thanks!
> >
> > On Sat, Jul 29, 2017 at 4:45 PM, <iofel...@gmail.com> wrote:
> > > Tried to run gnome-characters with Cairo master, switching to noto-
> > > color-emoji crashes with:
> > >
> > > #0  0x7fd0ecd2868b in raise () at /lib64/libc.so.6
> > > #1  0x7fd0ecd2a417 in abort () at /lib64/libc.so.6
> > > #2  0x7fd0ecd208fa in __assert_fail_base () at /lib64/libc.so.6
> > > #3  0x7fd0ecd20972 in  () at /lib64/libc.so.6
> > > #4  0x7fd0f1370b6e in _cairo_error (status=status@entry=3646361
> > > 312)
> > > at cairo-error.c:68
> > > #5  0x7fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00,
> > > status=3646361312) at cairo.c:400
> > > #6  0x7fd0f13691b1 in cairo_show_text_glyphs (cr=0x3dd89ecc00,
> > > utf8=0x3dd8a41b40 "", utf8_len=4, glyphs=0x7fffada90d60
> > > , num_glyphs=1
> > > , clusters=0x7fffada91640, num_clusters=1, cluster_flags=(unknown:
> > > 0))
> > > at cairo.c:3742
> > > #7  0x7fd0f0283f69 in
> > > pango_cairo_renderer_show_text_glyphs.isra ()
> > > at /lib64/libpangocairo-1.0.so.0
> > > #8  0x7fd0f0284161 in pango_cairo_renderer_draw_glyph_item ()
> > > at
> > > /lib64/libpangocairo-1.0.so.0
> > > #9  0x7fd0f0057e1e in pango_renderer_draw_glyph_item () at
> > > /lib64/libpango-1.0.so.0
> > > #10 0x7fd0f00588b1 in pango_renderer_draw_layout_line () at
> > > /lib64/libpango-1.0.so.0
> > > #11 0x7fd0f0058c65 in pango_renderer_draw_layout () at
> > > /lib64/libpango-1.0.so.0
> > > #12 0x7fd0f028443a in _pango_cairo_do_layout () at
> > > /lib64/libpangocairo-1.0.so.0
> > > #13 0x7fd0ef560bde in ffi_call_unix64 () at /lib64/libffi.so.6
> > > #14 0x7fd0ef56054f in ffi_call () at /lib64/libffi.so.6
> > > #15 0x00007fd0f10ab6f6 in  () at /lib64/libgjs.so.0
> > > #16 0x7fd0f10ad066 in  () at /lib64/libgjs.so.0
> > > #17 0x7fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs,
> > > js::MaybeConstruct) () at /lib64/libmozjs-38.so
> > > #18 0x7fd0ee3584cd in Interpret(JSContext*, js::RunState&) ()
> > > at
> > > /lib64/libmozjs-38.so
> > > #19 0x7fd0ee362324 in j

Re: [cairo] Color fonts

[Behdad Esfahbod]

Should be fixed.  Thanks!

On Sat, Jul 29, 2017 at 4:45 PM, <iofel...@gmail.com> wrote:

> Tried to run gnome-characters with Cairo master, switching to noto-
> color-emoji crashes with:
>
> #0  0x7fd0ecd2868b in raise () at /lib64/libc.so.6
> #1  0x7fd0ecd2a417 in abort () at /lib64/libc.so.6
> #2  0x7fd0ecd208fa in __assert_fail_base () at /lib64/libc.so.6
> #3  0x7fd0ecd20972 in  () at /lib64/libc.so.6
> #4  0x7fd0f1370b6e in _cairo_error (status=status@entry=3646361312)
> at cairo-error.c:68
> #5  0x7fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00,
> status=3646361312) at cairo.c:400
> #6  0x7fd0f13691b1 in cairo_show_text_glyphs (cr=0x3dd89ecc00,
> utf8=0x3dd8a41b40 "", utf8_len=4, glyphs=0x7fffada90d60, num_glyphs=1
> , clusters=0x7fffada91640, num_clusters=1, cluster_flags=(unknown: 0))
> at cairo.c:3742
> #7  0x7fd0f0283f69 in pango_cairo_renderer_show_text_glyphs.isra ()
> at /lib64/libpangocairo-1.0.so.0
> #8  0x7fd0f0284161 in pango_cairo_renderer_draw_glyph_item () at
> /lib64/libpangocairo-1.0.so.0
> #9  0x7fd0f0057e1e in pango_renderer_draw_glyph_item () at
> /lib64/libpango-1.0.so.0
> #10 0x7fd0f00588b1 in pango_renderer_draw_layout_line () at
> /lib64/libpango-1.0.so.0
> #11 0x7fd0f0058c65 in pango_renderer_draw_layout () at
> /lib64/libpango-1.0.so.0
> #12 0x7fd0f028443a in _pango_cairo_do_layout () at
> /lib64/libpangocairo-1.0.so.0
> #13 0x7fd0ef560bde in ffi_call_unix64 () at /lib64/libffi.so.6
> #14 0x7fd0ef56054f in ffi_call () at /lib64/libffi.so.6
> #15 0x7fd0f10ab6f6 in  () at /lib64/libgjs.so.0
> #16 0x7fd0f10ad066 in  () at /lib64/libgjs.so.0
> #17 0x7fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs,
> js::MaybeConstruct) () at /lib64/libmozjs-38.so
> #18 0x7fd0ee3584cd in Interpret(JSContext*, js::RunState&) () at
> /lib64/libmozjs-38.so
> #19 0x7fd0ee362324 in js::RunScript(JSContext*, js::RunState&) ()
> at /lib64/libmozjs-38.so
> #20 0x7fd0ee362614 in js::Invoke(JSContext*, JS::CallArgs,
> js::MaybeConstruct) () at /lib64/libmozjs-38.so
> #21 0x7fd0ee664f13 in js_fun_apply(JSContext*, unsigned int,
> JS::Value*) () at /lib64/libmozjs-38.so
> #22 0x7fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs,
> js::MaybeConstruct) () at /lib64/libmozjs-38.so
> #23 0x7fd0ee363243 in js::Invoke(JSContext*, JS::Value const&,
> JS::Value const&, unsigned int, JS::Value const*,
> JS::MutableHandle) () at /lib64/libmozjs-38.so
> #24 0x7fd0ee4b5485 in js::jit::DoCallFallback(JSContext*,
> js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int,
> JS::Value*, JS::MutableHandle) ()
> at /lib64/libmozjs-38.so
> #25 0x7fd0f1877510 in  ()
> #26 0x7fffada948a0 in  ()
> #27 0x7fffada94368 in  ()
> #28 0x in  ()
>
> On Sat, 2017-07-29 at 16:30 +0100, Behdad Esfahbod wrote:
> > On Sat, Jul 29, 2017 at 11:58 AM, Uli Schlachter <psyc...@znc.in>
> > wrote:
> > > Hi Behdad
> > >
> > > I don't think that is my decision to make. When thinking about
> > > "fonts in
> > > cairo", I'm thinking "Behdad". I'm just asking weird questions from
> > > the
> > > sideline. :-)
> >
> > Thanks. :-)  Pushed  At least ten people already asked me "what's
> > up with emoji" at GUADEC...
> >
> > > Uli
> > >
> > > P.S.: How relevant and up to date is the CC list here? I always get
> > > a
> > > "your message to gtk-devel-list awaits moderator approval"-mail
> > > when
> > > replying to this thread...
> > >
> >
> > My messages go through, yours probably don't because you are not a
> > member.  It's valuable still.
> >
> > Cheers,
> > b
> >
> > > On 28.07.2017 16:38, Behdad Esfahbod wrote:
> > > > Uli,
> > > >
> > > > Can we commit this?  I don't think waiting another few years will
> > > result in
> > > > a superior patchset. :)
> > > >
> > > > Cheers,
> > > >
> > > > behdad
> > > >
> > > > On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod <behdad@behdad.o
> > > rg> wrote:
> > > >
> > > >> Right.  In the future we would want to make it show glyphs in
> > > the input
> > > >> order, ie. not separate color vs non-color.  That's the order
> > > required by
> > > >> CSS for example.  In a show-text-glyphs call with
> > > CAIRO_TEXT_CLUSTER_FLAG_BACKWARD,
> > > >> it might be desirabl

Re: [cairo] Color fonts

[Behdad Esfahbod]

On Sat, Jul 29, 2017 at 11:58 AM, Uli Schlachter <psyc...@znc.in> wrote:

> Hi Behdad
>
> I don't think that is my decision to make. When thinking about "fonts in
> cairo", I'm thinking "Behdad". I'm just asking weird questions from the
> sideline. :-)
>

Thanks. :-)  Pushed  At least ten people already asked me "what's up
with emoji" at GUADEC...


> Uli
>
> P.S.: How relevant and up to date is the CC list here? I always get a
> "your message to gtk-devel-list awaits moderator approval"-mail when
> replying to this thread...
>

My messages go through, yours probably don't because you are not a member.
It's valuable still.

Cheers,
b


> On 28.07.2017 16:38, Behdad Esfahbod wrote:
> > Uli,
> >
> > Can we commit this?  I don't think waiting another few years will result
> in
> > a superior patchset. :)
> >
> > Cheers,
> >
> > behdad
> >
> > On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod <beh...@behdad.org>
> wrote:
> >
> >> Right.  In the future we would want to make it show glyphs in the input
> >> order, ie. not separate color vs non-color.  That's the order required
> by
> >> CSS for example.  In a show-text-glyphs call with
> CAIRO_TEXT_CLUSTER_FLAG_BACKWARD,
> >> it might be desirable to show back-to-front.
> >>
> >> On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen <
> >> matthias.cla...@gmail.com> wrote:
> >>
> >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psyc...@znc.in>
> wrote:
> >>>
> >>>> On 07.07.2017 15:23, Matthias Clasen wrote:
> >>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psyc...@znc.in>
> wrote:
> >>>>>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
> >>>>>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@redhat.com>
> >>>> wrote:
> >>>>>>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> >>>>>>>> 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.
> >>>>>>
> >>>>>> Okay... so what is the new model? What happens when I draw a color
> >>>> glyph
> >>>>>> with operator XOR and a red source?
> >>>>>
> >>>>>
> >>>>> The red source is ignored for color glyphs because they are used as
> the
> >>>>> source.
> >>>>
> >>>> Hi again,
> >>>>
> >>>> I just came up with another question: How are overlapping glyphs
> handled?
> >>>>
> >>>> Let's say I have a red glyph and a blue glyph and I draw them in such
> a
> >>>> way that they overlap. Let's say this additionally overlaps with a
> >>>> non-colored glyph in the same position and I use a green source with
> 50%
> >>>> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
> >>>>
> >>>> What's the visible result?
> >>>>
> >>>>
> >>> Here is what my implementation does: It renders the color glyphs, in
> >>> order, followed by the non-color glyphs.
> >>>
> >>> In practice, I don't think the case of mixed color and non-color glyphs
> >>> in the same call will be all that common.
> >>> Most apps will explicitly set a color font just for the emoji and they
> >>> won't render regular text with an emoji font,
> >>> with the result that runs of color glyphs and non-color glyphs will
> >>> typically be in separate calls.
> >>>
> >>
> >>
> >>
> >> --
> >> behdad
> >> http://behdad.org/
> >>
> >
> >
> >
>
>
> --
> "Why make things difficult, when it is possible to make them cryptic
> and totally illogical, with just a little bit more effort?" -- A. P. J.
>



-- 
behdad
http://behdad.org/
___
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 Fri, Jul 28, 2017 at 6:00 PM, Bill Spitzak <spit...@gmail.com> wrote:

> I think the stacking order of glyphs can remain undefined for
> cairo_show_glyphs. This seems more like something pango would be in
> charge of.
>

We are talking about order of glyphs drawn in one cairo_show_glyphs(), so I
don't see how this is pango's job.


>
> On Fri, Jul 28, 2017 at 7:38 AM, Behdad Esfahbod <beh...@behdad.org>
> wrote:
> > Uli,
> >
> > Can we commit this?  I don't think waiting another few years will result
> in
> > a superior patchset. :)
> >
> > Cheers,
> >
> > behdad
> >
> > On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod <beh...@behdad.org>
> wrote:
> >>
> >> Right.  In the future we would want to make it show glyphs in the input
> >> order, ie. not separate color vs non-color.  That's the order required
> by
> >> CSS for example.  In a show-text-glyphs call with
> >> CAIRO_TEXT_CLUSTER_FLAG_BACKWARD, it might be desirable to show
> >> back-to-front.
> >>
> >> On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen
> >> <matthias.cla...@gmail.com> wrote:
> >>>
> >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psyc...@znc.in>
> wrote:
> >>>>
> >>>> On 07.07.2017 15:23, Matthias Clasen wrote:
> >>>> > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psyc...@znc.in>
> wrote:
> >>>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
> >>>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@redhat.com>
> >>>> >>> wrote:
> >>>> >>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> >>>> >>>> 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.
> >>>> >>
> >>>> >> Okay... so what is the new model? What happens when I draw a color
> >>>> >> glyph
> >>>> >> with operator XOR and a red source?
> >>>> >
> >>>> >
> >>>> > The red source is ignored for color glyphs because they are used as
> >>>> > the
> >>>> > source.
> >>>>
> >>>> Hi again,
> >>>>
> >>>> I just came up with another question: How are overlapping glyphs
> >>>> handled?
> >>>>
> >>>> Let's say I have a red glyph and a blue glyph and I draw them in such
> a
> >>>> way that they overlap. Let's say this additionally overlaps with a
> >>>> non-colored glyph in the same position and I use a green source with
> 50%
> >>>> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
> >>>>
> >>>> What's the visible result?
> >>>>
> >>>
> >>> Here is what my implementation does: It renders the color glyphs, in
> >>> order, followed by the non-color glyphs.
> >>>
> >>> In practice, I don't think the case of mixed color and non-color glyphs
> >>> in the same call will be all that common.
> >>> Most apps will explicitly set a color font just for the emoji and they
> >>> won't render regular text with an emoji font,
> >>> with the result that runs of color glyphs and non-color glyphs will
> >>> typically be in separate calls.
> >>
> >>
> >>
> >>
> >> --
> >> behdad
> >> http://behdad.org/
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> > --
> > cairo mailing list
> > ca...@cairographics.org
> > https://lists.cairographics.org/mailman/listinfo/cairo
>



-- 
behdad
http://behdad.org/
___
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]

Uli,

Can we commit this?  I don't think waiting another few years will result in
a superior patchset. :)

Cheers,

behdad

On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod <beh...@behdad.org> wrote:

> Right.  In the future we would want to make it show glyphs in the input
> order, ie. not separate color vs non-color.  That's the order required by
> CSS for example.  In a show-text-glyphs call with 
> CAIRO_TEXT_CLUSTER_FLAG_BACKWARD,
> it might be desirable to show back-to-front.
>
> On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen <
> matthias.cla...@gmail.com> wrote:
>
>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psyc...@znc.in> wrote:
>>
>>> On 07.07.2017 15:23, Matthias Clasen wrote:
>>> > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psyc...@znc.in> wrote:
>>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@redhat.com>
>>> wrote:
>>> >>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
>>> >>>> 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.
>>> >>
>>> >> Okay... so what is the new model? What happens when I draw a color
>>> glyph
>>> >> with operator XOR and a red source?
>>> >
>>> >
>>> > The red source is ignored for color glyphs because they are used as the
>>> > source.
>>>
>>> Hi again,
>>>
>>> I just came up with another question: How are overlapping glyphs handled?
>>>
>>> Let's say I have a red glyph and a blue glyph and I draw them in such a
>>> way that they overlap. Let's say this additionally overlaps with a
>>> non-colored glyph in the same position and I use a green source with 50%
>>> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
>>>
>>> What's the visible result?
>>>
>>>
>> Here is what my implementation does: It renders the color glyphs, in
>> order, followed by the non-color glyphs.
>>
>> In practice, I don't think the case of mixed color and non-color glyphs
>> in the same call will be all that common.
>> Most apps will explicitly set a color font just for the emoji and they
>> won't render regular text with an emoji font,
>> with the result that runs of color glyphs and non-color glyphs will
>> typically be in separate calls.
>>
>
>
>
> --
> behdad
> http://behdad.org/
>



-- 
behdad
http://behdad.org/
___
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]

Right.  In the future we would want to make it show glyphs in the input
order, ie. not separate color vs non-color.  That's the order required by
CSS for example.  In a show-text-glyphs call with
CAIRO_TEXT_CLUSTER_FLAG_BACKWARD, it might be desirable to show
back-to-front.

On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen <matthias.cla...@gmail.com>
wrote:

> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psyc...@znc.in> wrote:
>
>> On 07.07.2017 15:23, Matthias Clasen wrote:
>> > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psyc...@znc.in> wrote:
>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@redhat.com>
>> wrote:
>> >>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
>> >>>> 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.
>> >>
>> >> Okay... so what is the new model? What happens when I draw a color
>> glyph
>> >> with operator XOR and a red source?
>> >
>> >
>> > The red source is ignored for color glyphs because they are used as the
>> > source.
>>
>> Hi again,
>>
>> I just came up with another question: How are overlapping glyphs handled?
>>
>> Let's say I have a red glyph and a blue glyph and I draw them in such a
>> way that they overlap. Let's say this additionally overlaps with a
>> non-colored glyph in the same position and I use a green source with 50%
>> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
>>
>> What's the visible result?
>>
>>
> Here is what my implementation does: It renders the color glyphs, in
> order, followed by the non-color glyphs.
>
> In practice, I don't think the case of mixed color and non-color glyphs in
> the same call will be all that common.
> Most apps will explicitly set a color font just for the emoji and they
> won't render regular text with an emoji font,
> with the result that runs of color glyphs and non-color glyphs will
> typically be in separate calls.
>



-- 
behdad
http://behdad.org/
___
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 Fri, Jul 7, 2017 at 5:53 PM, Matthias Clasen 
wrote:

> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter  wrote:
>
>>
>> Okay... so what is the new model? What happens when I draw a color glyph
>> with operator XOR and a red source?
>
>
> The red source is ignored for color glyphs because they are used as the
> source.
>

Note that while with Google's (CBDT/CBLC) and Apple's (sbix) color font
formats the red source will be ignored, with the Microsoft (COLR/CPAL) and
Adobe's (SVG/CPAL) the font can have color imaging as well as using the
current foreground color.  So, the glyph image won't be just a source
either.  It will be a mix of source and mask...  Right now those two
formats are not implemented in FreeType though.

-- 
behdad
http://behdad.org/
___
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 Fri, Jul 7, 2017 at 5:55 PM, Matthias Clasen 
wrote:

> It would be great to know if this approach, following Behdad's
> recommendation, will be acceptable.
>

Thanks for the quick implementation.  I quite like your changes and think
this is the right way to do it.


> Review of the changes in https://github.com/matthiasclasen/cairo/tree/
> emoji-again would appreciated as well.
>

I like it after your simplification.  I'll try to review the tricky part
you requested.


> I admit that I haven't thought about necessary documentation updates yet.
>



-- 
behdad
http://behdad.org/
___
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" <mcla...@redhat.com> 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

Color fonts

[Behdad Esfahbod]

Hello,

All of you have asked me about the status of color fonts in cairo.  There's
some discussion here:

https://github.com/googlei18n/noto-emoji/issues/36

The remaining part is indeed the cairo patchset.  Matthias had a reworked
version, which Chris Wilson objected to.  I agree with parts of his
objection.  In particular, I don't think we should need to touch every
compositor.

IMO, this is how it should work:

  - Extend glyph cache to also hold a color-glyph object possibly,

  - Early on, perhals in _cairo_surface_show_text_glyphs(), ask scaled_font
to see if it has color.  If it does, call a special function that iterates
over the glyphs, for each, load it and see if it has color.  Show the color
ones using image ops, show the rest using text ops. Or just show all as
image ops, that's feasible too.

With the above, we wouldn't need to touch any compositor whatsoever.

Unfortunately I'm too busy / lazy to do this any time soon.  However, I
just bought my ticket to GUADEC, so working on it together there definitely
is an option.


Cheers,
-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Behdad Esfahbod]

On Mon, Jul 11, 2016 at 1:47 PM, Paul Davis <p...@linuxaudiosystems.com> wrote:
> If soname was changed in keeping with the nominal "standard", it wouldn't be
> that much of an issue. The soname would indicated added API, internal fixes,
> and no change to public API/ABI. No?

Humm.  I don't quite follow.  Common practice for "added API, internal fixes,
> and no change to public API/ABI" is to keep the soname.

> On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod <beh...@behdad.org> wrote:
>>
>> I also think bumping soname every six months would be disaster.  It
>> was painful enough when libstdc++, libpng, libssl, etc changed soname
>> every few years.
>>
>> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
>> <poch...@gmail.com> wrote:
>> > Hi,
>> >
>> > On 21/06/16 16:26, Peter Weber wrote:
>> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
>> >> to
>> >> write about my thoughts, in a careful way. In the first moment, I
>> >> thought
>> >> this is a good idea and just the numbering is misleading. Stability is
>> >> what
>> >> developers want, we need it, we love it. With a few days distance,
>> >> numbering is just a small issue, I see this now entirely different and
>> >> three major issues:
>> >
>> > Here are some thoughts I have about all this, from a downstream
>> > maintainer POV.
>> >
>> > My concern with this new scheme is that GTK+ libraries will have to bump
>> > the
>> > soname every 6 months (if they want to support the latest GTK+). That
>> > can be
>> > manageable for say vte or gnome-desktop, although it may be bad if some
>> > third
>> > party apps pick a dependency on the vte for GTK+ 4.2 but don't update it
>> > for
>> > GTK+ 4.4, as then distros would need to ship an increasing number of
>> > versions
>> > that are unlikely to get any support upstream.
>> >
>> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
>> >
>> > I feel like the X.[024] releases are just snapshots of a development
>> > branch,
>> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
>> > clearly be
>> > labelled as that, regardless of what version number is chosen (be it
>> > 4.0,
>> > 3.99.0, 4.0beta1 or whatever).
>> >
>> > Cheers,
>> > Emilio
>> > ___
>> > gtk-devel-list mailing list
>> > gtk-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>>
>>
>> --
>> behdad
>> http://behdad.org/
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>



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

Re: Gtk+4.0

[Behdad Esfahbod]

I also think bumping soname every six months would be disaster.  It
was painful enough when libstdc++, libpng, libssl, etc changed soname
every few years.

On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
 wrote:
> Hi,
>
> On 21/06/16 16:26, Peter Weber wrote:
>> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> write about my thoughts, in a careful way. In the first moment, I thought
>> this is a good idea and just the numbering is misleading. Stability is what
>> developers want, we need it, we love it. With a few days distance,
>> numbering is just a small issue, I see this now entirely different and
>> three major issues:
>
> Here are some thoughts I have about all this, from a downstream maintainer 
> POV.
>
> My concern with this new scheme is that GTK+ libraries will have to bump the
> soname every 6 months (if they want to support the latest GTK+). That can be
> manageable for say vte or gnome-desktop, although it may be bad if some third
> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it for
> GTK+ 4.4, as then distros would need to ship an increasing number of versions
> that are unlikely to get any support upstream.
>
> But do you expect WebKitGTK+ to bump the ABI every 6 months?
>
> I feel like the X.[024] releases are just snapshots of a development branch,
> with X.6 being the stable release, and I wonder if X.[024] shouldn't clearly 
> be
> labelled as that, regardless of what version number is chosen (be it 4.0,
> 3.99.0, 4.0beta1 or whatever).
>
> Cheers,
> Emilio
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



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

Re: G_UTF8String: Boxed Type Proposal

[Behdad Esfahbod]

On Mon, Mar 21, 2016 at 3:30 PM, Randall Sawyer 
wrote:

> Frankly, the use of the term "character" when referring to a "UTF-8
> encoded Unicode code point" was for me a source of confusion


A character means a "Unicode character".  That's independent of encoding,
so, no, it does NOT mean "UTF-8 encoded Unicode code point".


> when I leapt to the conclusion of the unmet need of a UTF-8-length-aware
> wrapped string type - be it called "G_UTF8String" or "GUString".
>
> I recommend that all Glib documentation be rewritten such that throughout
> all descriptions of g_utf8_*() functions, the parlance "character" be
> replaced with "UTF-8 code point sequence" or equivalent terminology.
>
> Thank you.
>
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



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

Re: G_UTF8String: Boxed Type Proposal

[Behdad Esfahbod]

I like to voice my opinion as well:

  - Bundling data and its length in a boxed type is useful, but that's
gblob,

  - Bundling number-of-Unicode-character is rarely useful indeed,

  - A string API that would require any changes to the string content to go
through editing function calls is painful and will remain unused,

I also have a piece of a more personal opinion:  Many processes that simply
*reject* invalid Unicode text are useless in many situations.  For example,
gedit used to refuse to open a file if it had even a single
invalidly-encoded byte.  I find that annoyingly limited.  Same thing about
Pango.  Fortunately, both have been fixed for many years now.


behdad

On Mon, Mar 21, 2016 at 6:32 AM, Matthias Clasen 
wrote:

> On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
>  wrote:
>
>
> > 2) If the former is true - which it is - then the developer will need to
> > call g_utf8_strlen() to determine if there are multi-byte sequences to
> > navigate - and if there are - g_utf8_offset_to_pointer() to locate the
> array
> > index. Doesn't this increase processing demand?
>
> It does. But whether that is a problem (in general, or for your
> particular use case) can only be answered by  profiling. My theory is
> that you won't be able to notice this on the profile at all, unless
> all your application does is constantly operating on large amounts of
> text. In which case, you really shouldn't be using GString to begin
> with...
>
> > 3) Wouldn't it be helpful to keep track of how many code points
> > ("characters")are stored in the GString - a number which may be less than
> > the value of GString.len - without needing to call g_utf8_strlen() each
> time
> > to find out?
> > 4) Would my efforts be better spent editing patches of "gstring.h" and
> > "gstring.c" - or - to proceed as I am to introduce a parallel
> alternative?
>
> I think we haven't gotten past the 'what is the problem you are trying
> to solve - and is it a problem in the first place ?' part yet.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



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

Re: GTK+ hackfest 2016

[Behdad Esfahbod]

Hi Matthias,

Any idea why the page says Immutable to me?

  https://wiki.gnome.org/Hackfests/GTK2016

I remember having seen this before but don't remember what the resolution
was.

Cheers,
behdad

On Tue, Mar 8, 2016 at 5:02 AM, Matthias Clasen 
wrote:

> Hi,
>
> we've discussed the idea of doing a GTK+ hackfest this year. I've
> started a wiki page with the current plan:
>
> https://wiki.gnome.org/Hackfests/GTK2016
>
> If you are interested in attending, please add your name to the list.
> If you want to see topics added to the agenda, please suggest them on
> this page, too.
>
> Hope to see some of you in Toronto!
>
> Matthias
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



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

Re: glib/gatomic.c

[Behdad Esfahbod]

On 13-03-09 04:23 AM, John Emmas wrote:
 
 /* mingw32 does not have MemoryBarrier.
   * MemoryBarrier may be defined as a macro or a function.
   * Just make a failsafe version for ourselves. */
 #ifdef MemoryBarrier
 #define _GMemoryBarrier MemoryBarrier
 #else

 static inline void _GMemoryBarrier (void) {
long dummy = 0;
InterlockedExchange (dummy, 1);
 }
 #endif

 Unfortunately, for MSVC, the 'inline' keyword is only available when building
 as C++.  For standard 'C' we need to use '__inline'.
 
 Hi Behdad,
 
 I just updated to the latest code for gatomic.c.  Although those #pragma
 instrinsics seem to be included now, I'm still getting an error from MSVC
 about the inline keyword (which it doesn't recognise).  It expects
 '__inline'.  Is that something you're still working on?

Humm.  I thought I removed the MemoryBarrier fallback completely.  Where are
you seeing inline?

I'm still trying to get my head around this...

behdad

 I found that the simplest fix was just to #include gutils.h. Thanks.
 
 John
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
 

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

Re: glib/gatomic.c

[Behdad Esfahbod]

On 13-03-07 07:26 AM, John Emmas wrote:
 Hello guys,
 
 This morning I updated from git and found a minor problem in glib/gatomic.c. 
 At around line 530 there's a section of code that looks like this:-

Oops.  My bad.


 /* mingw32 does not have MemoryBarrier.
  * MemoryBarrier may be defined as a macro or a function.
  * Just make a failsafe version for ourselves. */
 #ifdef MemoryBarrier
 #define _GMemoryBarrier MemoryBarrier
 #else
 
 static inline void _GMemoryBarrier (void) {
   long dummy = 0;
   InterlockedExchange (dummy, 1);
 }
 #endif
 
 Unfortunately, for MSVC, the 'inline' keyword is only available when building
 as C++.  For standard 'C' we need to use '__inline'.  I solved the problem by
 adding #include gutils.h, just after #include config.h at the top of the
 file.  That has the effect of converting 'inline' to '__inline'.  If that's
 not an appropriate solution can someone please let me know?

Do all versions of MSVC have MemoryBarrier?  In that case, we should make sure
we never try the function path for MSVC.  Perhaps I should just do that for
mingw32?


 Incidentally, a couple of months ago I need to make a small number of changes
 to that file in order to be able to build using VC8.0. Mostly it just involved
 adding a few lines like this:-
 
 #pragma intrinsic (_InterlockedAnd)
 
 I've attached a full diff for that file in case it's helpful.

Interesting.  I'll push.  Just curious: can you also try building HarfBuzz and
see if we need those there too?

Thanks,
behdad


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

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

Re: glib/gatomic.c

[Behdad Esfahbod]

Would copying what's here in case MemoryBarrier macros is defined work for you:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684208(v=vs.85).aspx



On 13-03-07 07:26 AM, John Emmas wrote:
 Hello guys,
 
 This morning I updated from git and found a minor problem in glib/gatomic.c. 
 At around line 530 there's a section of code that looks like this:-
 
 /* mingw32 does not have MemoryBarrier.
  * MemoryBarrier may be defined as a macro or a function.
  * Just make a failsafe version for ourselves. */
 #ifdef MemoryBarrier
 #define _GMemoryBarrier MemoryBarrier
 #else
 
 static inline void _GMemoryBarrier (void) {
   long dummy = 0;
   InterlockedExchange (dummy, 1);
 }
 #endif
 
 Unfortunately, for MSVC, the 'inline' keyword is only available when building
 as C++.  For standard 'C' we need to use '__inline'.  I solved the problem by
 adding #include gutils.h, just after #include config.h at the top of the
 file.  That has the effect of converting 'inline' to '__inline'.  If that's
 not an appropriate solution can someone please let me know?
 
 Incidentally, a couple of months ago I need to make a small number of changes
 to that file in order to be able to build using VC8.0. Mostly it just involved
 adding a few lines like this:-
 
 #pragma intrinsic (_InterlockedAnd)
 
 I've attached a full diff for that file in case it's helpful.
 
 John
 
 
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
 

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

Re: glib/gatomic.c

[Behdad Esfahbod]

On 13-03-07 07:26 AM, John Emmas wrote:
 +#include intrin.h   /* Added by JE - 02-12-2012 */
 +
 +#pragma intrinsic (_InterlockedAnd)   /* Added by JE - 02-12-2012 */
 +#pragma intrinsic (_InterlockedOr)/* Added by JE - 02-12-2012 */
 +#pragma intrinsic (_InterlockedXor)   /* Added by JE - 02-12-2012 */
 +
  #define InterlockedAnd _InterlockedAnd
  #define InterlockedOr _InterlockedOr
  #define InterlockedXor _InterlockedXor
 +
  #endif

Humm.  Does removing the defines do the trick?  I can't find any references to
the difference between the underscored and plain versions of these :(.

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

Re: bugzilla cleanup

[Behdad Esfahbod]

On 02/05/2013 02:13 PM, Krzysztof Kosiński wrote:
 2013/2/4 Matthias Clasen matthias.cla...@gmail.com:
 Hi everybody,

 a while ago, we've talked about getting a handle on the enormous
 number of open bugs in glib and gtk.
 
 This bug, which makes GOption useless on Windows and has accumulated
 93 comments so far, could be easily fixed (it has patches) if someone
 finally decided which way is preferable.

It can be easily fixed in the sense that every application also would then
need to be fixed...

 https://bugzilla.gnome.org/show_bug.cgi?id=522131

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

Using gub for Windows / OS X binaries

[Behdad Esfahbod]

Hi,

Has anyone around here considered using gub [1] to create GTK+ binaries /
installers for Windows and OS X?  Looks like an easy to use tool.  It already
has specs to build Lilypond and Inkscape.  Which means, it already has spec'ed
the GTK+ stack.  Looks like it's a matter of letting it run for an hour every
release.  I'm bootstraping it right now.  Will report back.

[1] https://github.com/gperciva/gub

Cheers,
-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: reversible

[Behdad Esfahbod]

On 09/27/2012 04:01 PM, Ryan Lortie wrote:
 Would this API make your life easier?  Could it be better?

There are other uses I see for this API:

- It can be used to register release functions to be called at shutdown time,

- It can be used as a cleanup stack [1],

At any rate, what I don't like about the proposed API is that the reversible
is implicit.  That would be cause for endless confusion.  I'd rather see
reversible objects being passed around like GError and GCancelable.  Perhaps
GCancelable can be reused indeed.  You can just add a method to GCancelable
that adds a release function to be called if the cancelable is ever canceled.

b

[1] http://www.freetype.org/david/reliable-c.html
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Volunteers needed gtk-doc'ing HarfBuzz

[Behdad Esfahbod]

Hi,

As part of heading towards releasing HarfBuzz 1.0 this cycle, I'm looking for
volunteers annotating HarfBuzz with gtk-doc stubs (no templates!) and fill in
documentation.  It may, in fact, be a good idea if I work with volunteers on
IRC and explain to them what the API does, and let them document it.  That
would probably surface many tricky points in the current API that I can fix in
turn.

Replies off-lists please.

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

Re: RFC: glocal - automatically freeing memory when it goes out of scope

[Behdad Esfahbod]

On 05/30/2012 05:17 AM, Paul Davis wrote:
 
 
 On Wed, May 30, 2012 at 3:22 AM, Mikkel Kamstrup Erlandsen
 mikkel.kamst...@canonical.com mailto:mikkel.kamst...@canonical.com wrote:
 
 
 alloca() does not provide a callback when cleaning up, and we need that
 for anything that needs a teradown function - which is basically
 everything that is not a string...
 
 
 those who refuse to acknowledge the role of the compiler in supporting
 object-oriented programming are doomed to repeat cfront :)

What's wrong with cfront?  I want cfront back!

/me runs

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

Re: Ropes and String Formatting

[Behdad Esfahbod]

Not really. You ask harder questions, the more you have to wait for an
answer. Some times it will never come. Doesn't mean that people ignored
you, just that no one had anything to add to the thread. Perhaps because
they are all busy doing other things...

behdad

On 2012-05-24, at 8:10 PM, Russell Harmon r...@eatnumber1.com wrote:

Is there any particular reason I'm being ignored?
--
Russell Harmon


On Mon, May 21, 2012 at 6:54 AM, Russell Harmon r...@eatnumber1.com wrote:

 I'm looking to implement two things which I think would be quite useful if
 included in glib.

 - Ropes [1]
 - Custom string formatting helper routines

 What are people's thoughts on this? I was doing a little prototyping and
 was having trouble deciding whether to have the string formatting helper
 routines take and return ropes (which would be algorithmically faster), or
 take and return gchar *s which would probably be faster on very small
 strings, depending on the specifics of the implementation. Or, do you guys
 not worry about performance on that level?

 I was also wondering about what you guys' policy on code simplicity vs
 performance is. String formatting routines (that take and return a gchar *)
 could be implemented relatively easily, but would be very inefficient with
 calls to realloc() on every conversion, or could be implemented much more
 efficiently but with a great deal more code. You can see an example of this
 in some code I wrote last year, [2] although I think I can do better than
 this example by a great deal.

 Lastly, would you guys even be interested in ropes and string formatting
 routines at all?

 Thanks
 Russell Harmon

 [1]: http://en.wikipedia.org/wiki/Rope_(computer_science)
 [2]:
 https://github.com/eatnumber1/getmntinfo/blob/master/getmntinfo.c#L314


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

Re: GLib plans for next cycle

[Behdad Esfahbod]

On 09/06/11 10:05, Alexander Larsson wrote:
 On Thu, 2011-09-01 at 15:16 -0600, Ryan Lortie wrote:
 Another option is to use library load constructors to run the
 initialisation we need to do.  That's certainly possible on Windows
 systems and anything using GCC.  I'm not sure if it's possible to do it
 in a portable way from pure C, though.
 
 In my research for how to implement a resource system for glib I've been
 looking at this. I think its should be possible to do this for all the
 main platforms we're targeting (linux, elf unixes, win32, osx). There
 might be some ancient proprietary unix where it will not work (but
 probably not as this is a C++ requirement too).
 
 So, while the code would be kinda hacky to make this work with all weird
 setups required (like pragmas, ick) it should be quite possible to rely
 on.

In HarfBuzz I'm using the C++ compiler without linking to libstdc++.  I found
it as very rewarding experience.  You get library constructor/destructors for
free there.  I think this approach to library design has serious merit worth
considering.

b

 I have some notes somewhere on how it can be done for all platforms.
 Will write it up some day.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: ./configure -C

[Behdad Esfahbod]

On 08/07/11 14:46, Andy Wingo wrote:
 It came to my attention that some GTK+ folks were not aware of this, as
 I wasn't, before seeing Ralf's presentation.  See
 http://www.gnu.org/s/hello/manual/autoconf/Cache-Files.html for more
 info.  I think you'll find that when hacking on your projects, it's
 quite useful!

What I did in cairo is to enable caching in autogen.sh.  That enables it for
developers, but not for users.

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ team meeting at guadec

[Behdad Esfahbod]

On 08/06/11 05:27, Matthias Clasen wrote:
 On Wed, Jul 27, 2011 at 8:41 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
 Hey,

 I have been slacking off and not pushing for team meetings recently,
 and I haven't even looked at the guadec schedule until today.
 But I guess better late than never: should we aim for a gtk team
 meeting at guadec ?
 
 Concrete proposal: Sunday (ie tomorrow) after the regular program
 Meet at 18:15 outside the Audimax and find a room.
 Any objections to that ?

Yay, will be there.

/me is REALLY excited now...

b
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

gtestutils Re: reftests

[Behdad Esfahbod]

On 05/05/11 04:18, Kristian Rietveld wrote:
 g_assert (allocation.y == rect.y + ((rect.height - allocation.height) 
 / 2));
 
 The output of this failed assertion is not really nice to the eyes.  It would 
 be nice if the assertion macros could be improved to also accept a 
 human-readable string of what's going wrong together with the expected and 
 received value.  But perhaps this is already present in the gtestutils and I 
 missed it.

You can do:

  g_assert_cmpint (allocation.y, ==, rect.y + ((rect.height -
allocation.height) / 2));

and that gives you expected ..., got ... part, but not a message.  What I do
now in HarfBuzz is to do g_test_message() earlier in the code about what's
going on, and then run the test with --verbose and make sense of it.  Far from
what other test frameworks provide, which is a message to print only when the
test fails.

b
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: reftests

[Behdad Esfahbod]

On 05/03/11 16:01, Benjamin Otte wrote:
 (Pango doesn't ellipsize every row, only the
 last one. Bad Pango - and Behdad hasn't even applied my patch for
 this, I need to poke him again as I've just committed that test,
 ooops.)

You see.  No Pango test suite means little confidence that an incoming patch
doesn't break other stuff.  So I have to find and spend a good 45min slot on
it, to read the code, remember all the delicacies, walk through the change,
and convince myself that all the corner cases will still work.  Would have
been much easier if it was here's a new test that fails; here's the patch;
now everything psases.  I know you already know this.  I was wondering if
you're making any progress on the Pango test suite front! :D

Cheers,
behdad

PS. Thanks for the great writeup.  I'm forking it to discuss gtest in general.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Introspection] Trying to remove warnings for Pango-1.0.gir: Boxed or skip?

[Behdad Esfahbod]

On 04/25/11 19:27, Alberto Ruiz wrote:
 Hi,
 
 I removed most warnings while generating Pango-1.0.gir, however,
 there's a last batch of warnings I'm not sure how to get rid of:
 http://pastebin.com/V0ZDRg3r

Thanks Alberto!

 I've been lurking around and all that I can gather is that some of
 those types are not present in the gir, though I'm not sure why. Any
 pointers are welcome.

I see two different cases:

  - The various PangoAttr* are not boxed separately as they subclass
PangoAttribute without a real object system.  See bug 646788 for example.

  - The other cases (PangoEngineShape, etc) are protected behind
PANGO_ENABLE_ENGINE, and perhaps some behind PANGO_ENABLE_BACKEND.  Those APIs
are less stable than the base API and may change between release cycles.  Not
sure they are worth binding. (ie, do we support someone implementing a Pango
backend in Python?  Maybe...)



behdad


 Thanks!

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

Re: Please fill out the GtkLabel questionnaire

[Behdad Esfahbod]

On 04/09/11 11:42, Tristan Van Berkom wrote:
   Labels currently don't wrap and ellipsize both, it would be nice if
   they did however (and it's certainly possible, I would imagine the
   whole text would wrap as much as possible and the text that doesnt
   fit would be ellipsized only on the last line).
  
  Oh? Is this a limitation in Pango or is that just missing inside GtkLabel?
 Looks like we could use pango_layout_set_height ().

Exactly.  As far as I can imagine, wrapping and ellipsizing at the same time
only makes sense if you have both a limited width, and limited height.  And
that's exactly what Pango does.  There are known corner cases unhandled, but
API-wise, it should work.

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Coming to grips with the state of a11y in gtk

[Behdad Esfahbod]

On 02/17/11 09:43, Matthias Clasen wrote:
 Hey,
 
 I've spent the last night poring through gail bugs and code, and came
 to the conclusion that we need to face the tough reality that the
 state of a11y in GTK+ is sadly declining. There were years old patches
 in  bugzilla which fix pretty obvious bugs; on top of that, I've fixed
 at least one bug that would lead to instant segfault in the file
 chooser when a11y is turned on.
 
 I think we need to start over on the gail implementations, essentially.
 
 Now, we obviously can't do that by throwing away all we have now and
 start from a blank slate. The only way this can work, imo, is to move
 implementations from gail to gtk 1-by-1 and fixing them up in the
 process. I wonder if we can come up with some plan for how to organize
 that practically.

If it can be tested easily (ie. without having to put my entire desktop at the
mercy of a11y), and the porting process documented fairly well, I imagine we
can organize a hacking weekend on IRC to port widgets one by one.  If ten
people attend, should make great progress...

behdad


 The current state of affairs cannot be useful for anybody. While I was
 digging at this with accerciser last night, it would let me poke
 things for a bit, but as soon as I look back at the code, accerciser
 would lock up hard, sometimes freezing random other applications in
 the process...
 
 
 Matthias
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building multiple backends on on same system

[Behdad Esfahbod]

On 12/06/10 13:12, Kevin Fox wrote:
 On Mon, 2010-12-06 at 09:53 -0800, Behdad Esfahbod wrote:
 On 12/05/10 17:14, Alexander Larsson wrote:
 Then we add a GdkBackend type that each backend implements. This is a
 singleton created at init to hang global stuff off. Its also useful for
 backend specific code.

 Would it be possible to allow multiple backends at runtime?  Imagine, moving
 your app currently running on your desktop to running on broadway without
 restarting it...
 
 Even nicer, moving from one backend to a new instance of the same at
 runtime. For example, moving an app from X11 on display :0 to X11 on
 display :13

This, I believe, is already possible.  Owen was demoing it years ago...

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Building multiple backends on on same system

[Behdad Esfahbod]

On 12/06/10 13:46, Alexander Larsson wrote:
 On Mon, 2010-12-06 at 12:53 -0500, Behdad Esfahbod wrote:
 On 12/05/10 17:14, Alexander Larsson wrote:
 Then we add a GdkBackend type that each backend implements. This is a
 singleton created at init to hang global stuff off. Its also useful for
 backend specific code.

 Would it be possible to allow multiple backends at runtime?  Imagine, moving
 your app currently running on your desktop to running on broadway without
 restarting it...
 
 I think it will be kinda hard. It will require passing a GdkBackend to
 all global gdk functions, which is a huge API break.

Or have a push/pop gdk_backend...

b
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

CSS3 Flexible Box Layout Module

[Behdad Esfahbod]

FYI

http://dev.w3.org/csswg/css3-flexbox/

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: pixbuflt;-gt;cairo_surface_t conversion

[Behdad Esfahbod]

On 09/03/10 04:17, Benjamin Otte wrote:
 - We convert pixbufs every single time we paint them
 This is important for performance considerations: We convert the pixbuf to an
 image surface every single time we paint it. So whatever we end up doing, it
 won't get any worse. Also, no one has complained yet.

Well, someone had this exact same problem on the XO yesterday.  Now, drawing a
pixbuf is inefficient in many other ways eve nif you cached a cairo image
surface: has to be uploaded to the X server and possibly blit'ed slowly to a
different format, which is exactly what would happen on the XO.

It's not like keeping a cairo_surface_t around solves most of the problem...

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: padding cleanup

[Behdad Esfahbod]

On 08/29/10 19:02, Havoc Pennington wrote:
  - is it called padding or border (border is nice perhaps since it
 contrasts with all the existing stuff called padding)

Why not copy the CSS box model to the extent that it's relevant?

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: padding cleanup

[Behdad Esfahbod]

On 08/30/10 14:01, Havoc Pennington wrote:
 Hi,
 
 On Mon, Aug 30, 2010 at 1:26 PM, Behdad Esfahbod beh...@behdad.org wrote:
 On 08/29/10 19:02, Havoc Pennington wrote:
  - is it called padding or border (border is nice perhaps since it
 contrasts with all the existing stuff called padding)

 Why not copy the CSS box model to the extent that it's relevant?
 
 Yeah (that's why I called it padding). I was just thinking it might be
 less confusing if this was border and all the deprecated stuff was
 padding.
 Or I guess this could match CSS and call it border and not include the
 background.
 
 Should probably first decide if whatever-it-is should include the
 background or not.
 
 Well, first decide if we want it at all ;-)

Well, I was implicitly suggesting that we take all of CSS margin, border,
padding and then some.

behdad

 Havoc
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Wrapping Box Container

[Behdad Esfahbod]

On 08/24/10 13:42, Tristan Van Berkom wrote:
 Is this a kind of widget that we are interested in adding to GTK+ ?

What are the usecases for such a container?  The selection of features looks a
bit arbitrary to me.

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_widget_draw()

[Behdad Esfahbod]

On 08/18/10 07:58, Matthias Clasen wrote:
 
 We are just about to remove that style property, called
 GtkWidget::draw-border, since it has some overhead, and nobody ever
 used it.

Just keep in mind that it's very normal for text ink to leak out of the
allocation area.  So even if the draw-border property is removed, we should
eventually figure out how to handles these.  In vte for example, we always
draw one extra row/column of glyphs outside of the expose are, just in case
they leak into the expose area.  Doing this generally would be very
expensive...  unless...  One way to do this would be:

There's some damage tracking api that has been proposed for inclusion to
cairo.  Using that and custom api (for non-cairo drawing, etc), the widgets
can mark their ink rect during expose.  Then gtk can maintain an ink rect as
well as the usual logical allocation.  Then we just need to intersect the
expose region with the ink rects to determine which childs to expose.  The
order of exposing siblings will be significant in such a world though.

behdad


 See bug http://bugzilla.gnome.org/show_bug.cgi?id=426924

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

Re: GTK+ 2.21.6

[Behdad Esfahbod]

On 08/18/10 12:50, Paul Davis wrote:
 On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
 
 I don't see how that follows. All that is happening in 2.22 is that
 some things are getting deprecated. You can still use them. We are not
 going to take them away from you during 2.x
 
 i wasn't really worried about the deprecations. replacing the
 implementation of all internal drawing methods is OK to do in a stable
 branch?

From what I understand reading the thread, that's your wrong impression.  The
rendering-cleanup branch is NOT being merged into 2.22.  Just that some new
functions where added, and some old ones marked deprecated.  You are imagining
things that are simply not true.

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

Re: GTK+ 2.21.6

[Behdad Esfahbod]

On 08/18/10 12:50, Paul Davis wrote:
 On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:
 
 I don't see how that follows. All that is happening in 2.22 is that
 some things are getting deprecated. You can still use them. We are not
 going to take them away from you during 2.x
 
 i wasn't really worried about the deprecations. replacing the
 implementation of all internal drawing methods is OK to do in a stable
 branch?

From what I understand reading the thread, that's your wrong impression.  The
rendering-cleanup branch is NOT being merged into 2.22.  Just that some new
functions where added, and some old ones marked deprecated.  You are imagining
things that are simply not true.

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: disabling GTK+ features to shrink GTK+

[Behdad Esfahbod]

On 08/16/10 15:29, Enrico Weigelt wrote:
 It grows as soon as certain pages are accessed. And - as already said - 
 unless the distinct functional (sub)modules are aligned into their
 own pages instead of randomly cat'ed to one big contigious text section 
 on linker's will, there's great chance that there're many, many 
 never-accessed areas within pages that still have to be accessed
 (and thus loaded).

So, doesn't gtk's code breakdown by functionality and the file naming
convention automatically provide such a submodule hierarchy?  All the linker
has to do is to link them in the order provided on the commandline.  Then all
of the following will be in a big unused chunk if you don't use the
filechooser stuff:

gtkfilechooser.lo
gtkfilechooserbutton.lo
gtkfilechooserdefault.lo
gtkfilechooserdialog.lo
gtkfilechooserembed.lo
gtkfilechooserentry.lo
gtkfilechoosersettings.lo
gtkfilechooserutils.lo
gtkfilechooserwidget.lo
gtkfilefilter.lo
gtkfilesel.lo
gtkfilesystem.lo
gtkfilesystemmodel.lo


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]

[Behdad Esfahbod]

On 08/04/10 16:33, Havoc Pennington wrote:
 I have a personal project where I'm not using convenience libraries
 for files that are part of a half-dozen executables because it's
 faster to compile files 6 times than it is to use a libtool library.

Are you exaggerating for effect or is this really the case?  I have a hard
time believing that libtool (2.x) performance is *that* bad.  And I only hack
on libraries...

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gdbus-binding-tool

[Behdad Esfahbod]

On 05/19/2010 11:20 AM, David Zeuthen wrote:
 My plan is to actually port some real things (udisks,
 gnome-disk-utility, polkit, maybe the monitor part of gvfs) to use
 this code generator.

Would be good to test it with some code that someone other than you wrote also
:-).

Kind of a side-note.  Can the code generation be done using cpp (a pre-compile
invocation of cpp).

behdad

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

Re: thoughts on GSettingsList

[Behdad Esfahbod]

On 05/15/2010 03:56 PM, Christian Persch wrote:
 Hi;
 
 Behdad Esfahbod behdad behdad org wrote:
 In g-t, the user names a profile and can rename it later.  The name
 can have arbitrary Unicode characters.  Logically it means that the
 name cannot be used directly in the conf database, so g-t cleans it
 up.  Moreover, since profile renames are supported, the conf name for
 a new item may already be taken.  Say:

   - User creates profile Remote Server, it shows up in the database
 as profiles/remote-server/

   - Later on, use renames Remote Server to Old Server.  The
 database key remains at profiles/remote-server/

   - User creates new profile called Remote Server, the database key
 profiles/remote-server/ is taken, so we use profiles/remote-server-2/
 
 That might be how g-t used to work, but it doesn't do it this way
 anymore. It just uses ProfileN as gconf directory name for new
 profiles, where N is the first unused number.

Right.  But it would be more useful for browsing if it does use the profile
name as a hint like it used to...

behdad


   Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: thoughts on GSettingsList

[Behdad Esfahbod]

Hi Ryan,

Let me just dump my thoughts on this based on my experience with g-t.  It may
help with your design.

In g-t, the user names a profile and can rename it later.  The name can have
arbitrary Unicode characters.  Logically it means that the name cannot be used
directly in the conf database, so g-t cleans it up.  Moreover, since profile
renames are supported, the conf name for a new item may already be taken.  Say:

  - User creates profile Remote Server, it shows up in the database as
profiles/remote-server/

  - Later on, use renames Remote Server to Old Server.  The database key
remains at profiles/remote-server/

  - User creates new profile called Remote Server, the database key
profiles/remote-server/ is taken, so we use profiles/remote-server-2/


It would be immensely helpful if GSettingsList can do the cleaning up and
dup-avoiding part.  So, add_item() will in fact get a name *hint*, clean it
[1] up, avoid dup, and return the key name.

Needless to say, the key name is useless for UI use, so at least in g-t we
always have to have at least one non-default key in the profile which would be
its name.


[1] For the actual cleaning, I suggest you transcribe it to ASCII, lower-case,
replace non-alnum with dashes, remove repeated dashes.


Other than that, I know you already know, but is worth stressing: please avoid
magic keys and values if you can :P.

behdad




On 05/13/2010 06:01 PM, Ryan Lortie wrote:
 Hi all,
 
 I've been putting off GSettingsList for a while because of a criticism
 that vuntz raised during the hackfest.  It's a fairly valid criticism
 that I'll describe here, along with my thoughts for a solution.  This is
 a bit of a request for comments and a hopes that the braindumping
 process itself will prove to be useful.
 
 If you don't know, GSettingsList is a way to have a list of like-typed
 GSettings instances associated with a given parent.  For example, you
 could store your list of gnome-terminal profiles or Telepathy accounts
 using this mechanism.
 
 The API is something like
 
 
string add_item ();
void rm_item (string name);
GSettings get_item (string name);
string[] list_items ();
 
 If gnome-terminal had its list of profiles and had Default and
 bigfont profiles, the layout in dconf would look something like this:
 
   /apps/g-t/stuff...
   /apps/g-t/profiles/
   /apps/g-t/profiles/Default/
   /apps/g-t/profiles/bigfont/
 
 also, there is a /apps/g-t/profiles/list key.  It is a list of
 strings: ['Default', 'bigfont'].
 
 What vuntz didn't like (and what I don't like) is that you can remove an
 item from the list but still have garbage settings left for it in the
 database.
 
 Going forward it makes sense (and I would like) to tie the existence of
 a item of the list to the result of calling the directory enumeration
 API on dconf (ie: it's impossible to have garbage, because if you have
 garbage then it's not garbage, but recognised as a valid list item).
 
 The main issue with this is that it goes somewhat against the dynamic
 creation/removing of paths that dconf follows.  Consider, for example,
 that we create a new profile white that has all the default settings
 (as per the schema) to start with.  This means that no key in dconf
 starts with
 
   /apps/g-t/profiles/white/
 
 which means that white won't show up when we enumerate
 /apps/g-t/profiles/.
 
 There are two main solutions here:
 
1) change how dconf works to support explicit empty directories.
   There are a lot of reasons that I don't like this, and I guess I
   don't need to explain them.  It's also difficult to express in the
   file format (but definitely not impossible).
 
2) Store some sort of /apps/g-t/profiles/.exists key.  This is what
   my current line of thinking is (and I guess many people are
   familiar with this hack from some other semi-related uses).
 
 The idea then is that you bring a list item into existence using
 .exists and remove it using the reset call that is implemented by
 the backend (which is a recursive directory removal).
 
 =
 
 There are three main unsolved issues here, though.  This system, when
 compare with the old one, suffers a major feature regression: it is no
 longer possible to permute the order of the items in the list.  I'm not
 sure if anyone cares about this.  I used to think it was important, but
 I'm happy to abandon/ignore it if nobody complains too loudly.
 
 =
 
 The second issue is how we deal with seeding the default contents of the
 list.  There are a few approaches that can be taken here.
 
   - null approach: list initially contains zero items.
 
   - this is very easy, but probably insufficient.
 
 
   - better approach: list initially contains one item where the default
 values of that item are taken from the schema for items (ie: the
 default values of the initially-existing item are equal to the
 default values that would be applied to newly created items)
 
   - maybe a 

Re: [cairo] Pango underline does not work with cairo scale.

[Behdad Esfahbod]

Known bug.  Fixed it in pango master repository right now.

http://git.gnome.org/browse/pango/commit/?id=1caf2947f0941e2354dd4f43d56934e1ec706b6e

http://git.gnome.org/browse/pango/commit/?id=34e05035af0ce854df1cc2f77c0b11dbc1a3cb36

behdad

On 04/30/2010 02:53 AM, Magicloud Magiclouds wrote:
 Hi, the code is following. In a scaled cairo context, the underline is
 not scaled as the text. test.png shows that the underline is ever
 larger than the 00.
 The version of pango is 1.28.0-1. The version of cairo is 1.8.10-4.
 
 #include cairo.h
 #include pango/pango.h
 
 int main () {
   cairo_surface_t * s = cairo_image_surface_create
 (CAIRO_FORMAT_ARGB32, 1280, 800);
   cairo_t * c = cairo_create (s);
   cairo_scale (c, 10, 10);
   PangoLayout * l = pango_cairo_create_layout (c);
   pango_layout_set_text (l, 00, 2);
   PangoAttrList * attrs = pango_attr_list_new ();
   pango_attr_list_insert (attrs, pango_attr_underline_new
 (PANGO_UNDERLINE_DOUBLE));
   pango_layout_set_attributes (l, attrs);
   cairo_move_to (c, 1, 1);
   pango_cairo_show_layout (c, l);
   cairo_surface_write_to_png (s, test.png);
   return 0;
 }
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

AM_GSETTINGS (was Re: GLib 2.25.2 released

[Behdad Esfahbod]

On 04/23/2010 06:25 AM, Matthias Clasen wrote:
 * Install a AM_GSETTINGS autoconf macro similar to AM_GCONF

Quick feedback:

dnl AM_GSETTINGS

- Rename to GLIB_GSETTINGS or something.



dnl Defines GSETTINGS_SCHEMAS_INSTALL which controls whether
dnl the schema should be compiled

- The comment is mostly useless and wrong.


AC_DEFUN([AM_GSETTINGS],
[
  AC_ARG_ENABLE(schemas-install,
AC_HELP_STRING([--disable-schemas-install],
   [Disable the schemas installation]),

- If the arg name is to stay what it is for compat reasons, at list the
comment should be more clear.  Imagine you do configure --help in, say,
evolution and see Disable the schemas installation.  Not very helpful.
Should talk about gsettings at least.




  AC_SUBST(gsettingsschemadir, [${datadir}/glib-2.0/schemas])
  AC_SUBST(gschema_compile, `pkg-config --variable gschema_compile gio-2.0`)

- Historically upper-case variables have been used.



gschema_xml_files := $(wildcard *.gschema.xml)

- Not a huge fan of wildcards.



check-gsettings-schema: gsettings_schema_validate_stamp
CLEANFILES += gsettings_schema_validate_stamp

- Maybe add to MOSTLYCLEANFILES instead.


  _GSETTINGS_SUBST(GSETTINGS_CHECK_RULE)



Note: the macro doesn't even check that the installed glib version has
gsettings!  Should check that $(gschema_compile) is not empty.


Cheers,
behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: AM_GSETTINGS (was Re: GLib 2.25.2 released

[Behdad Esfahbod]

On 04/23/2010 10:04 AM, Matthias Clasen wrote:

 - Rename to GLIB_GSETTINGS or something.
 
 Fine with me. Lets get the name right while this is still unstable.
 Can you fix the things you raised ? Otherwise, I'll try to get it done
 before the next release, but I might forget...

I can.  It may be a good time to step back and design what m4 macros glib
should provide.  I can code whatever we decide.

So far I see three in m4macros:

  - glib-2.0.m4: The finding part is deprecated in favor of pkg-config.  The
rest is defining the following:

  AC_SUBST(GLIB_GENMARSHAL)
  AC_SUBST(GOBJECT_QUERY)
  AC_SUBST(GLIB_MKENUMS)


  - glib-gettext.m4: Does a bunch of stuff.  Needs to stay it seems.  But can
use renaming and new API.

  - gsettings.m4: Exports AC_SUBST(gschema_compile) and a make snippet.  And a
--disable arg.



Also, gobject-introspection does:

AC_SUBST(INTROSPECTION_SCANNER)
AC_SUBST(INTROSPECTION_COMPILER)
AC_SUBST(INTROSPECTION_GENERATE)
AC_SUBST(INTROSPECTION_GIRDIR)
AC_SUBST(INTROSPECTION_TYPELIBDIR)
AC_SUBST(INTROSPECTION_CFLAGS)
AC_SUBST(INTROSPECTION_LIBS)
AC_SUBST(INTROSPECTION_MAKEFILE)

These definitely need to be prefixed by GOBJECT_.
Also defines a --disable arg.


So here's what I suggest:

  - I know gsettings is included in gio, but I suggest providing a separate
.pc file for it.  And please, don't clutter the gschema namespace.  Use
gsettings-schemas, gsettings-schema-compile, etc.

  - Have on GLIB_INIT macro that does:

* For all binaries shipped with glib, define a macro in their uppercase
name.  If backward compatibility is not an issue, I would suggest just
exporting the glib bindir and let users do $GLIB_BINDIR)/glib-mkenums instead.

* For anything else, generate for features requested.

* Do a version check also?

So, one would do something like:

GLIB_INIT (gettext settings introspection)



behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: How to calculate the font size?

[Behdad Esfahbod]

On 04/14/2010 09:57 PM, Magicloud Magiclouds wrote:
 Hi, could someone help me? Pango's maillist seems inactive. Thank you.
 
 On Wed, Apr 14, 2010 at 3:31 PM, Magicloud Magiclouds
 magicloud.magiclo...@gmail.com wrote:
 Hi, I am not quite familiar with the font thing. Now I have a simple
 request, I do not know how to meet it:
 Say I have a background (i.e. a cairo surface) which size was not
 certain when the function was made, I have to write a 0 at (1%, 3%)
 with the size of 5%, all % means the size of the actual background.
 How to do it? Thanks.

Calculate the 5%, use it as your font size?  Make sure you set the absolute
font size.

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

Re: FYI: New project. libctrans

[Behdad Esfahbod]

On 04/04/2010 11:22 AM, ENRIQUE ARIZON BENITO wrote:

 I think people in charge of glib development could be interested in
 integrating it with glib since I have found no equivalent.

Maybe you can explain in a paragraph what problem you are trying to address?

behdad


 Regards,
 
 Enrique
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve internal use of inlines

[Behdad Esfahbod]

On 03/29/2010 06:10 PM, Mikhail Zabaluev wrote:
 Hi,
 
 Here's another branch that tries to solve some problems with usage of
 G_INLINE_FUNC and G_IMPLEMENT_INLINES in Glib:
 http://git.collabora.co.uk/?p=user/zabaluev/glib.git;a=shortlog;h=refs/heads/implement-inlines

Hi Mikhail,

Please file a but, and explain the problem you are trying to solve first.

behdad

 It consigns all non-inline emissions for functions declared with
 G_INLINE_FUNC to one dedicated source file, to make sure no other
 source file needs to have G_IMPLEMENT_INLINES defined and possibly
 ends up using non-inlined implementations of these functions inside
 the library.
 
 Enjoy,
   Mikhail
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve internal use of inlines

[Behdad Esfahbod]

On 03/30/2010 01:25 PM, Behdad Esfahbod wrote:

 Please file a but

A bug I meant :).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

On 03/27/2010 06:57 PM, Daniel Elstner wrote:
 However, for other invalid conditions to result in defined behavior,
 explicit checks would be required in the code.  I see no reason to pay
 the cost for insufficient validation checks in light of the fact that
 the documentation explicitly states that the behavior is undefined if
 the input is not valid UTF-8.  It might be a different matter if it
 would write past the end of a buffer or something, but that's not the
 case here.

Well, there's a bit more to it.  Just because some bytes in a file are invalid
acording to the spec doesn't mean your text editor should refuse to open the
file.  While g_utf8_get_char() and friends do assume valid UTF-8 data, it's an
unwritten assumption that for invalid bytes they simply skip the byte and
return -1.  And I want to keep it that way and perhaps even document it.  I
think I use that in Pango IIRC.

Anyway, getting way off-topic here.

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

On 03/26/2010 05:43 PM, Daniel Elstner wrote:
 Hi Behdad,
 
 Am Freitag, den 26.03.2010, 13:25 -0400 schrieb Behdad Esfahbod:
 
 * The construct borrowed from glibmm, as beautiful as it is, is WRONG for
 6-byte-long UTF-8.  It just doesn't work.  We historically support those
 sequences.
 
 What?  In what way exactly is it wrong?

Err, you're right.  My bad.  It's still broken though since it doesn't check
that the fragment bytes all start with the bits 10.  Missing error checking.

behdad

 --Daniel
 
 
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

On 03/27/2010 04:27 PM, Daniel Elstner wrote:
 Hi,
 
 Am Samstag, den 27.03.2010, 16:12 -0400 schrieb Behdad Esfahbod:
 
 Err, you're right.  My bad.  It's still broken though since it doesn't check
 that the fragment bytes all start with the bits 10.  Missing error checking.

Looking at:
http://git.collabora.co.uk/?p=user/zabaluev/glib.git;a=commitdiff;h=9ace0f84dcbb7d95996c93c2236e0ec0253ee479

 It is not meant to check for errors.

Good point.

 I think it is totally arbitrary to handle some potential errors but not
 others.  And I think the current implementation does not do that check
 either -- it will behave differently, but it is still undefined.

The current implementation definitely does the check:

-  for ((Count) = 1; (Count)  (Len); ++(Count))
\
-{  \
-  if (((Chars)[(Count)]  0xc0) != 0x80)   \
-   {   \
- (Result) = -1;\
- break;\
-   }   \
-  (Result) = 6;  \
-  (Result) |= ((Chars)[(Count)]  0x3f);   \
-}

Anyway.  Nice construct :).  For future reference, it must be used with 32bit
ints only.  Otherwise it can go wrong.

behdad


 --Daniel
 
 
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

On 03/27/2010 05:21 PM, Daniel Elstner wrote:
 Well, I assume that ints are at least 32 bit wide on any platform
 supported by GLib.  But if you meant to say that it would break with
 larger ints, I don't see why.  As long as the type is unsigned, it
 should be fine.

If the utf8 byte has more than 6 leading 1 bits, and with a 64bit int, the
construct tries to consume 7 or 8 bytes.  Right?

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

On 03/27/2010 05:49 PM, Daniel Elstner wrote:
 Hi,
 
 Am Samstag, den 27.03.2010, 17:40 -0400 schrieb Behdad Esfahbod:
 On 03/27/2010 05:21 PM, Daniel Elstner wrote:
 Well, I assume that ints are at least 32 bit wide on any platform
 supported by GLib.  But if you meant to say that it would break with
 larger ints, I don't see why.  As long as the type is unsigned, it
 should be fine.

 If the utf8 byte has more than 6 leading 1 bits, [...]
 
 That's an oxymoron.
 
 [...] and with a 64bit int, the
 construct tries to consume 7 or 8 bytes.  Right?
 
 Undefined behavior.

Sure, I wasn't referring to valid data.  In valid UTF-8, there is no 5byte or
6byte sequences either.

b

 --Daniel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

Sorry for replying so late.  I saw a few replies implying that the developer
time to implement a (to me, unmeasurably) useful feature has been spent
already so I should go ahead and commit it.  There are various flaws with that
argument:

  - It ignores the fact that writing a patch is a small part of the time spent
on a change.  Ignoring the maintainer review time as well as future
maintenance.  If you think I should commit without spending significant time
on it, well, there's a reason you're not the maintainer :P.  In short, it's
the maintainer that is taking the risk, not you or the patch author.  Guess
why I'm replying this late?  Because reading 18 messages and 20 patches takes
time.  Time I could spend on fixing a bug that has a measurable impact at least.

  - It also assumes that the patch is ready, and useful.  The original patch
series had various flaws.  A few I list:

* Introduce 256 new relocations!

* Inlined a public function, but just to make an indirect function call
instead.  What's the point of inlining then?!

* Had unknown impacts on systems with higher function call overhead.

* Was not tested in real-life situations.  Perf tests are not realistic.
Calling g_utf8_next_char a million times in a loop is nothing like real-life.
 In real life strings that are processed are really short.  Memory cache
effects make any micro-optimization you make look like noise.

* Changed the semantics of the glib UTF-8 functions.  Dealing with UTF-8
coming from outside world is very sensitive matter security-wise.  There's
backward compatibility also.  Can't just decide to return a different value
from now on.

* The construct borrowed from glibmm, as beautiful as it is, is WRONG for
6-byte-long UTF-8.  It just doesn't work.  We historically support those
sequences.


That said.  I'm not being unfair to anyone here.  I personally am a utf-8
microoptimizing geek myself.  See for example this blogpost:

  http://mces.blogspot.com/2008/04/utf-8-bit-manipulation.html

So I'm not even willing to commit my own optimization to that code without
seeing real-world numbers first.

Another idea, now that people are measuring: What about this:

static const int utf8_mask_data[7] = {
  0, 0x7f, 0x1f, 0x0f, 0x07, 0x03, 0x01
};

#define UTF8_COMPUTE(Char, Mask, Len) \
  G_STMT_BEGIN { \
Len = utf8_skip_data[(guchar)(Char)]; \
Mask = utf8_mask_data[Len]; \
if (G_UNLIKELY ((guchar)(Char) = 0xfe)) \
  Len = -1; \
  } G_STMT_END



behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Faster UTF-8 decoding in GLib

[Behdad Esfahbod]

Final note: Please file separate bugs for any individual optimization you
think is worth performing (or is an obvious improvement).

Thanks,
behdad

On 03/26/2010 01:25 PM, Behdad Esfahbod wrote:
 Sorry for replying so late.  I saw a few replies implying that the developer
 time to implement a (to me, unmeasurably) useful feature has been spent
 already so I should go ahead and commit it.  There are various flaws with that
 argument:
 
   - It ignores the fact that writing a patch is a small part of the time spent
 on a change.  Ignoring the maintainer review time as well as future
 maintenance.  If you think I should commit without spending significant time
 on it, well, there's a reason you're not the maintainer :P.  In short, it's
 the maintainer that is taking the risk, not you or the patch author.  Guess
 why I'm replying this late?  Because reading 18 messages and 20 patches takes
 time.  Time I could spend on fixing a bug that has a measurable impact at 
 least.
 
   - It also assumes that the patch is ready, and useful.  The original patch
 series had various flaws.  A few I list:
 
 * Introduce 256 new relocations!
 
 * Inlined a public function, but just to make an indirect function call
 instead.  What's the point of inlining then?!
 
 * Had unknown impacts on systems with higher function call overhead.
 
 * Was not tested in real-life situations.  Perf tests are not realistic.
 Calling g_utf8_next_char a million times in a loop is nothing like real-life.
  In real life strings that are processed are really short.  Memory cache
 effects make any micro-optimization you make look like noise.
 
 * Changed the semantics of the glib UTF-8 functions.  Dealing with UTF-8
 coming from outside world is very sensitive matter security-wise.  There's
 backward compatibility also.  Can't just decide to return a different value
 from now on.
 
 * The construct borrowed from glibmm, as beautiful as it is, is WRONG for
 6-byte-long UTF-8.  It just doesn't work.  We historically support those
 sequences.
 
 
 That said.  I'm not being unfair to anyone here.  I personally am a utf-8
 microoptimizing geek myself.  See for example this blogpost:
 
   http://mces.blogspot.com/2008/04/utf-8-bit-manipulation.html
 
 So I'm not even willing to commit my own optimization to that code without
 seeing real-world numbers first.
 
 Another idea, now that people are measuring: What about this:
 
 static const int utf8_mask_data[7] = {
   0, 0x7f, 0x1f, 0x0f, 0x07, 0x03, 0x01
 };
 
 #define UTF8_COMPUTE(Char, Mask, Len) \
   G_STMT_BEGIN { \
 Len = utf8_skip_data[(guchar)(Char)]; \
 Mask = utf8_mask_data[Len]; \
 if (G_UNLIKELY ((guchar)(Char) = 0xfe)) \
   Len = -1; \
   } G_STMT_END
 
 
 
 behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: On Ctrl+tab

[Behdad Esfahbod]

Hi Jud,

Thanks for bringing this up.

How about: those who care come up with a replacement combination for focus
navigation in GTK+, and a patch to implement ctrl+tab to change tabs, and
submit that for upstream inclusion and see if we get any substantial (other
than breaks back-compat)?

Personally I think it would be a significant compatibility step forward.

behdad

On 01/12/2010 08:01 PM, Jud Craft wrote:
 I hate to force open an old topic, but this recently came up as an
 Ubuntu launchpad bug for their Paper Cuts project.  [1]
 
 The essence of the problem is that while Ctrl-Tab is reserved by GTK for
 keyboard navigation, it has also been claimed by many popular
 applications on Windows, Mac, and Linux for tabbed-document navigation.
 
 Due to its ubiquity, the conflict is very evident in GNOME programs,
 where the behavior is completely different, even on the same Linux
 operating system - between Epiphany and Firefox, Empathy and Pidgin,
 Anjuta and MonoDevelop as examples.
 
 And arguably, Firefox and Pidgin are more popular than GTK and even
 other GTK applications (note that Pidgin itself is one).
 
 Behdad Esfahbod brought this up on desktop-devel-list, but the thread
 previously lost momentum.  However, aside from continue as is, nothing
 was ever resolved.
 
 
 
 1.  https://bugs.launchpad.net/bugs/504405
 ___
 desktop-devel-list mailing list
 desktop-devel-l...@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Fwd: pango @ introspection.m4

[Behdad Esfahbod]

On 01/04/2010 01:35 PM, Philip Withnall wrote:

On Mon, 2010-01-04 at 06:09 -0500, Paul Davis wrote:

any comments?


It's explained in the bug report[1]: Pango is now dependent on
gobject-introspection, and while Behdad will probably include
introspection.m4 in the next release, in the long term the dependency
will hold.


Yes, it will be automatically included in tarballs.  But for building from git 
one needs to have the introspection.m4 file available on the system.


behdad


In short, you need to install gobject-introspection= 0.6.7.

Regards,
Philip

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=604770



-- Forwarded message --
From: Paul Davisp...@linuxaudiosystems.com
Date: Sat, Jan 2, 2010 at 3:51 PM
Subject: pango @ introspection.m4
To: gtk-devel-listgtk-devel-list@gnome.org


what is this?

http://git.gnome.org/browse/pango/commit/?id=fd15a3a04c69af0f5c04cde8c659269d0b139c28

as far as i can tell, pango doesn't use introspection, and this was
added without including introspection.m4 to the pango tree, thus
rendering it unbuildable on a system that doesn't happen to have
introspection.m4 lying around in another convenient location.

what is going on?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list




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

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

Re: updated introspection big-picture

[Behdad Esfahbod]

Hi Colin,

I still want to see the cairo parts moved to cairo-glib.

Cheers,
behdad

On 12/09/2009 01:25 PM, Colin Walters wrote:

Hi,

I'd like to get introspection and the JS bindings into a bit more
productized state; there's a lot of interest from various parties.
Now,  there are a lot of details here, but I wanted to write up my
current thinking on how the big picture should work.

The result is:

http://live.gnome.org/GObjectIntrospection/Roadmap

Any thoughts appreciated; I'll try to get a separate page/blocker bug
list for what we need to do to get introspection into GObject and more
finalized which is a blocker for everything that follows.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


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

Re: A few comments on GVariant

[Behdad Esfahbod]

On 11/30/2009 08:30 AM, Matthias Clasen wrote:

On Mon, Nov 30, 2009 at 7:27 AM, Christian Perschc...@gnome.org  wrote:

Hi;


- g_variant_type_matches docs say: This function defines a bounded
  join-semilattice over GVariantType for which G_VARIANT_TYPE_ANY is
  top.
  If you do want to go into that much detail, there should be a
  more complete definition of how that ... thing ... is constructed :-)


I'd just drop that kind of thing; I did study lattice theory and know
what a bounded join-semilattice is, but I doubt this information will
help anybody to use GVariant...


Isn't the hierarchy simply a tree?

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes of the GTK+ Team Meeting - 2009-11-27

[Behdad Esfahbod]

On 11/26/2009 07:11 AM, Alexander Larsson wrote:

On Thu, 2009-11-26 at 12:09 +, Emmanuele Bassi wrote:

On Thu, 2009-11-26 at 12:47 +0100, Alexander Larsson wrote:


I don't have any problem with doing this, even if I don't see much
benefit. Just do it for all I care, but please make sure that make
distcheck still works.


What about using AM_SILENT_RULES?


should already be working, but it's turned off by default.


Sweet

/me wires make V=0 into hands


export V=0 ?


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

Re: GConverter commited

[Behdad Esfahbod]

On 11/24/2009 11:09 AM, Shaun McCance wrote:


So with my implementation, by the time you get to the
magic, you've already set up a GConverterInputStream
with the magic decompressor.  If the stream turns out
to be uncompressed, you'd have to do a null conversion.
I suppose the magic decompressor could just have the
null conversion built in.


Isn't it like a matter of memcpy() in convert(), and nothing in reset()?  Not 
that I oppose a cat-converter.


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GConverter commited

[Behdad Esfahbod]

On 11/24/2009 03:29 AM, Alexander Larsson wrote:

On Mon, 2009-11-23 at 17:22 +0100, Alexander Larsson wrote:

On Mon, 2009-11-23 at 10:52 -0500, Behdad Esfahbod wrote:

On 11/23/2009 10:30 AM, Alexander Larsson wrote:


Please check out this API and give comments on it. I think its pretty
good, as we've talked about this a bit on irc over the years, but
feedback is always good.


Starting to look into them.  Any reason g_convert_get_type() is not defined
using G_DEFINE_* macros?


cutnpasteitis maybe?


No, its because there is no macro to do this for interfaces:

https://bugzilla.gnome.org/show_bug.cgi?id=320482

There are one year old patches in the bug report that look very good to
me, and has had some feedback from timj, including this:

i think we can add this to gtype.h as is, unless
more issues are being brought up 

So maybe we should just commit this?


Right, that's what I vaguely remembered...  See also:
https://bugzilla.gnome.org/show_bug.cgi?id=449565

Lets get this committed please...  The sooner we commit them, the sooner we 
can all switch to thread-safe type registration...


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GConverter commited

[Behdad Esfahbod]

On 11/24/2009 03:36 AM, Alexander Larsson wrote:

On Mon, 2009-11-23 at 21:57 -0600, Shaun McCance wrote:


I'll be using the bzip2 and lzma converters in Yelp.  I'm not
sure about the magic converter.  I might just throw it away and
go off the file name.  The magic detection is not suitable for
general use, though I think it's OKish for Yelp.  Although this
Debian bug report concerns me:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364260


lzma is detected by shared-mime-info (i.e GContentType), but only if it
has the right extension. Extending the database with magic info
shouldn't be that hard though.


Also, when putting together chains of streams when content may
or may not be encoded, I think it would be useful to have some
sort of NullConverter, i.e. a GConverter that doesn't change
anything.  Would anybody else find that useful?


I'm not sure why you'd need this, you just don't add a
GConverterInputStream in that case.


Anyway, since I was one of the people wanting this, I thought
I'd share my first experiences with it.  I'm curious what other
people would like to do about GConverters for other compression
schemes.  The code is simple enough that I don't really mind
keeping it in Yelp.  But if other people are doing this stuff,
maybe we should talk about how to share code.


Yeah, sharing things like this is good, but we don't want every app to
link to these libraries, and even gio plugins are not free (even when
not used) since we load them once to see what extension points they
support.


A gmodule-level caching scheme is in order...  Pango and gimp can use them 
too...


Its not a lot of code either, nor is it very complicated, so maybe cut
and paste is not such a horrible idea.


Well, we know where that would lead :).


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GConverter commited

[Behdad Esfahbod]

On 11/23/2009 10:30 AM, Alexander Larsson wrote:


Please check out this API and give comments on it. I think its pretty
good, as we've talked about this a bit on irc over the years, but
feedback is always good.


Starting to look into them.  Any reason g_convert_get_type() is not defined 
using G_DEFINE_* macros?


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO will link with -pthread soon

[Behdad Esfahbod]

On 11/11/2009 11:10 PM, Ryan Lortie wrote:


libdbus links against libpthread.


My only question  is: can't this be fixed instead?  I don't immediately see 
why not..


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: pango-cairo backward compat

[Behdad Esfahbod]

On 11/05/2009 05:37 PM, Allin Cottrell wrote:


I'm trying to write a function in such a way that (a) it doesn't
use currently deprecated code if that's avoidable while (b) it
builds OK against earlier versions of pango. I'd be grateful if
any pango expert could take a quick look at this and see if
anything looks wrong:

PangoLayout *gp_cairo_create_layout (void)
{
 static PangoFontMap *fontmap;
 PangoContext *context;
 PangoLayout *layout;

 if (fontmap == NULL) {
 fontmap = pango_cairo_font_map_new_for_font_type(CAIRO_FONT_TYPE_FT);
 if (fontmap == NULL) {
fontmap = pango_cairo_font_map_get_default();
 }
 }

#if PANGO_VERSION_MAJOR  1 || PANGO_VERSION_MINOR= 22
 context = pango_font_map_create_context(fontmap);
#else
 context = pango_cairo_font_map_create_context((PangoCairoFontMap *)
   fontmap);
#endif
 layout = pango_layout_new(context);
 g_object_unref(context);

 return layout;
}

My main concern is whether the cast from PangoFontMap to
PangoCairoFontMap is kosher.


Yes, that's fine.

behdad


Thanks!

Allin Cottrell

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

Re: Pango problems

[Behdad Esfahbod]

On 10/15/2009 05:22 PM, Geoff Johnson wrote:

Out of no where my program decided to start having problems with Pango
rendering. The GUI now shows text as the standard no character boxes and all
of the icons that were there have been replaced by the red x file icon.

When I run the program I get a lot of errors like:


This is definitely a problem with your linker or installation.  Has nothing to 
do with Pango or GTK+ AFAICS.


behdad




(xpath_test:11200): Gtk-WARNING **: Error loading theme icon
'gtk-media-record' for stock: Unable to load image-loading module:
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so:
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so: ELF load command
alignment not page-aligned

(xpath_test:11200): Pango-WARNING **:
/usr/lib/pango/1.6.0/modules/pango-basic-fc.so: ELF load command alignment
not page-aligned



All of the code used was pretty much cut and pasted from another application
that still displays fonts and icons correctly so I'm not sure what happened
to this one. I can provide source code if anyone requires it.

Build system
-
Linux 2.6.24-24-generic #1 SMP Fri Sep 18 16:49:39 UTC 2009 i686 GNU/Linux
GLib: 2.16.6
GTK+: 2.12.9
GCC: 4.2.4
Pango: 1.20.5

Thanks,
Geoff
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

Re: GDateTime

[Behdad Esfahbod]

Hi Christian,

Can we move discussion here:
https://bugzilla.gnome.org/show_bug.cgi?id=344005

behdad

On 10/04/2009 04:57 AM, Christian Hergert wrote:

Hello good folks,

I spent some of my free time recently putting together a DateTime
solution for GLib.  It is starting to get to the point where it is
usable.  Most of the work now seems to be finishing up string parsing,
polish, improving documentation, and i18n/l10n compliance for which I
could use suggestions and comments from the community.

The GDateTime opaque type represents a date and time down to
100-nanosecond intervals between 1/1/1 and 12/31/.  I find it
considerably easier to use when compared to time_t, struct tm, and other
limiting time types.

My branch is the datetime branch available at
git://git.dronelabs.com/glib.

This is my first attempt at building something for glib so please let me
know if I've not followed some conventions properly.

-- Christian


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


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

Re: GDateTime

[Behdad Esfahbod]

On 10/04/2009 06:07 PM, Behdad Esfahbod wrote:

Hi Christian,

Can we move discussion here:
https://bugzilla.gnome.org/show_bug.cgi?id=344005


Err, I noticed that it's not exactly the same thing, but the two need to be 
discussed together.


behdad


behdad

On 10/04/2009 04:57 AM, Christian Hergert wrote:

Hello good folks,

I spent some of my free time recently putting together a DateTime
solution for GLib. It is starting to get to the point where it is
usable. Most of the work now seems to be finishing up string parsing,
polish, improving documentation, and i18n/l10n compliance for which I
could use suggestions and comments from the community.

The GDateTime opaque type represents a date and time down to
100-nanosecond intervals between 1/1/1 and 12/31/. I find it
considerably easier to use when compared to time_t, struct tm, and other
limiting time types.

My branch is the datetime branch available at
git://git.dronelabs.com/glib.

This is my first attempt at building something for glib so please let me
know if I've not followed some conventions properly.

-- Christian


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


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

Re: pango and Type 1 FontName

[Behdad Esfahbod]

On 09/23/2009 11:07 AM, Allin Cottrell wrote:


I wonder, is there a way to get hold of the FontName for a Type 1
font, given the family name as returned by a user's selection of a
font in the GTK font selector?

E.g. the user selects Bodoni MT and we want to map this to the
FontName in the afm file, BodoniMT, for the benefit of a
traditional PostScript-oriented application.  (Simply removing
spaces would work in this case but I'm not sure if it would work
in general.)

Or if this is not something pango handles, might fontconfig do the
job?


At this time neither pango nor fontconfig does that.  Though there are plans 
for fontconfig to expose Postscript family name in the future.


behdad



Thanks.


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

Re: fonts list using pango

[Behdad Esfahbod]

On 09/17/2009 12:46 PM, Manu TM wrote:

Hi,

I've been unsuccessfully looking for a way to dump a list of all
available system fonts using pango but without poping-up a gtk font
chooser button. Does anybody have a clue or know a link to some good doc
about this? Many thanks in advance.


http://library.gnome.org/devel/pango/unstable/pango-Fonts.html#pango-font-map-list-families

Use pango_cairo_font_map_get_default() as your fontmap.

behdad



Manu TM

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

Re: [Usability] Gtk+ Font Dialog improvements

[Behdad Esfahbod]

On 07/19/2009 10:42 PM, Henrique Carvalho Alves wrote:


I wanted feedback from someone more experienced in the Gtk+ stack and C,
willing to implement this mockup, maybe a branch or patch against
GtkFontSelection(Dialog), and leveraging
pango_language_get_sample_string() for providing a better preview text.


For the implementation we may be able to convert the glade file into a .ui 
file and embed it directly in GTK+.


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkLabel, GtkMisc, alignment and containers; an idea

[Behdad Esfahbod]

On 07/07/2009 10:29 AM, Davyd Madeley wrote:

On Tue, 2009-07-07 at 13:25 +0100, Behdad Esfahbod wrote:


Generally agreed.  Makes the code so much simpler...


How do we avoid breaking API/ABI though?


Donno.  I'm not the most qualified person to talk about GTK+ widgets anyway.

behdad


One idea was to use a #define GTK_LABEL_NEW_SEMANTICS which renamed
GtkLabel and gtk_label_* to GtkNewLabel and gtk_new_label_* until GTK+
3.0, when we drop the old label mode.

--d


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

Re: GtkLabel, GtkMisc, alignment and containers; an idea

[Behdad Esfahbod]

On 07/07/2009 09:53 AM, Davyd Madeley wrote:

So, I was looking at why a GtkLabel with a RTL control code didn't seem
to right-align the text in a GtkLabel. The answer being that the width
of the PangoLayout is set to -1, rather than the width of the
allocation.

So I was wondering how you'd fix this. My immediate thought was to set
the PangoLayout to always have the width of the allocation. This would
allow for RTL control codes to function + make the justify modes in
GtkLabel work how people think they should (rather than how they do).

Unfortunately it breaks gtk_misc_set_alignment(), you can no longer
align a smaller PangoLayout inside a bigger allocation.

Thus I was thinking about how this might be fixed properly, and I came
up with the following idea. It breaks API and assumptions in GTK+, and I
don't yet have an idea for a migration path; but I'll share it anyway.

My idea:

(1) Make alignment a child-property of the GtkContainer. This would
allow any widget that wasn't EXPAND|FILL to be aligned within it's
available space. It would remove the requirement for GtkAlignment in a
lot of cases. This could be added to GTK+ without breaking API.

(2) Remove the GtkMisc class. Alignment is now a child-property.

(3) Make the PangoLayout of labels always fill their allocation. This
would make features like the RTL control code and PangoJustify work as
developers expect. If developers want a left-justified, right-aligned
text block, they can set the widget to not be EXPAND|FILL, and set the
align-x child-property to 1.0. This will likely require extended layout
for wrapped labels.

(4) Profit.

Thoughts?


Generally agreed.  Makes the code so much simpler...

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ Hackfest around Boston Summit

[Behdad Esfahbod]

Hi everyone,

Since the last attempt to organize a GTK+ hackfest failed and not many GTK+ 
people seems to be going to GUADEC, I wonder whether there's interest to 
organize a hackfest around Boston Summit.  That would make mclasen, ssp, and 
davidz readily available.  What do the rest of the team think?


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: .gitignore files

[Behdad Esfahbod]

On 05/02/2009 08:38 AM, Mathias Hasselmann wrote:

Am Samstag, den 02.05.2009, 14:25 +0200 schrieb Vincent Untz:

Le samedi 02 mai 2009, à 14:14 +0200, Mathias Hasselmann a écrit :

Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod:

git.mk.

What's this git.mk?

http://git.gnome.org/cgit/pango/tree/git.mk

Vincent


Oh, fancy! Nice!

+1

Why isn't this brilliant logic part of automake already? :-D


I'm proposing that.

behdad


Ciao,
Mathias

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

Re: .gitignore files

[Behdad Esfahbod]

On 05/01/2009 04:18 AM, Davyd Madeley wrote:

.gitignore files, to improve switching between branches easily.


I'd rather add my git.mk.  Matthias, want me to go ahead and do that?

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Review of gnio, round 1

[Behdad Esfahbod]

On 04/27/2009 09:53 AM, Alexander Larsson wrote:

With gnome 2.26 out and the GResolver branch landed it is time to start
look at merging the gnio network code into gio. I'm posting this here,
plus CC:ing the involved people instead of on bugzilla in order to get
feedback from others who may be interested but unaware of this work.


Thanks Alex.



There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this, since it makes
the code harder to read for very little gain. Like, it probably makes
sense for the inlined version of g_once_init_enter() to use G_LIKELY,
but I don't think it makes sense for e.g. error checking when creating a
socket, which is not gonna happen a lot.


I think I can answer this part since I use G_UNLIKELY extensively myself.  The 
way I see it, it's not just a hint for the compiler, it's also an annotation 
of the source code for the next person reading it, saying this branch is 
expected to happen in exceptional cases only, not the norm.  And I find it 
extremely useful for that.




Having e.g. g_io_stream_get_output_stream() fallback on the property in
case no vfunc is specified in the interface is IMHO pretty weird. A much
more natural way would be to have the property implemented in the common
code, based on the get_output_stream vfunc. This would be more efficient
and need less code in inheriting classes. However, this is only possible
if we change GIOStream to a baseclass instead of an interface.


Not sure I'm following.  But wanted to point out making decisions based on 
whether a vfunc is NULL is a very bad idea for bindings.


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Review of gnio, round 1

[Behdad Esfahbod]

On 04/27/2009 11:40 AM, Havoc Pennington wrote:

Hi,

On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbodbeh...@behdad.org  wrote:

There is a lot of G_UNLIKELY() calls in places that really are not in
any way performance sensitive. I'm not sure I like this, since it makes
the code harder to read for very little gain. Like, it probably makes
sense for the inlined version of g_once_init_enter() to use G_LIKELY,
but I don't think it makes sense for e.g. error checking when creating a
socket, which is not gonna happen a lot.

I think I can answer this part since I use G_UNLIKELY extensively myself.
  The way I see it, it's not just a hint for the compiler, it's also an
annotation of the source code for the next person reading it, saying this
branch is expected to happen in exceptional cases only, not the norm.  And
I find it extremely useful for that.



I don't really know much about modern processors or compilation, but
my understanding is that the penalty for being wrong on G_UNLIKELY()
is quite high. And as we know from the old premature optimization
cliche it can be a bit hard to predict which codepaths get hit. For
example, I can certainly imagine uses of IO or socket APIs where IO
errors are hit reasonably often.

I thought G_UNLIKELY was really exclusively for cases where we know
the unlikely case will almost never be hit, like one-time
initialization, and that it was discouraged in cases where it's just
probabilistic, like this is probably a bit less common


My use case is mostly for 1) programmer errors, and 2) alloc failure errors. 
Both of which are safe to assume they never happen.


behdad


But somebody should probably ask some gcc gurus

Havoc


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

Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)

[Behdad Esfahbod]

On 04/21/2009 04:11 PM, Kalyanov Dmitry wrote:

I think that using pass-by-value struct will bring more headache for language
bindings developers, because this complicates ABI and not every language's
foreign function interface supports passing structs by value. (I think that
passing structs by value is not part of C language, but of C++ (or am I
wrong?),


I think you are wrong.

behdad



so it is problematic to support)
I would support having both kinds of accessors: simple ones (option a) and
convenient for C (option b). Just the same as with other kinds of functions,
e.g., g_object_get and g_object_get_property. One part of interface for
convenience of C programming, one part for convenience of other languages.


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

Re: FYI: better UTF8 decoder.

[Behdad Esfahbod]

On 04/13/2009 05:00 AM, Butrus Damaskus wrote:

Hi!

This page: http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ claims to
have better (quicker and smaller?) utf8 decoder. Maybe it would be
worth to look at it?


Funny how he claims reduced complexity.  That's definitely the most complex 
UTF-8 decoder I've seen.


Anyway, as I said on my own UTF-8 decoding post [1], not worth changing glib 
unless someone shows a real profile of a real application with UTF-8 decoding 
taking a measurable part of the total run time.


behdad

[1] http://mces.blogspot.com/2008/04/utf-8-bit-manipulation.html


BBD

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

Re: Moving GLib and GTK+ to git

[Behdad Esfahbod]

On 04/03/2009 03:04 AM, Edward Hervey wrote:

   FWIW, In GStreamer git repositories we use that same rule for the
one-liner with a subtle variation:
   * We do allow capital letters (seriously, who cares? It looks nice)
   * Considering you want to have as much info as possible in that
one-liner, we try to prefix it with a word giving a clue as to where the
work was done (without looking at the modified files). Doesn't apply if
it's a change accross the whole module.
   Ex :
rtspsrc: allow http:// on the proxy setting, or
Mark unused arguments using G_GNUC_UNUSED glib macro.


Right.  In cairo and pango we do the same, with a slightly different syntax. 
For example:


[win32] Fix horizontal glyph positioning bug
[test] Memfault checks
[surface] Propagate region allocation failure
[traps] Propagate allocation failure
[region] Use const cairo_rectangle_int_t consistently
[scaled-font] Global glyph cache

I find that quite useful.

behdad


  Edward

BR,
Martin

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

Re: Moving GLib and GTK+ to git

[Behdad Esfahbod]

On 03/31/2009 03:05 PM, Matthias Clasen wrote:


Some things that we need to sort out include

ChangeLog: The git way of doing things is to do small commits, with
meaningful commit messages, and forego a separate ChangeLog file.
Everybody who I talked to about this recommended going this way, so
I'd say we should follow this. I'll add a final note to the current
ChangeLog indicating this.

I'll figure out what to do about autogenerating ChangeLogs in release
tarballs in time for the next releases...


Feel free to copy from Pango.  Pango only has one ChangeLog though.  You may 
want to consolidate gtk's many ones now.




The one deviation in this from our current ChangeLog entry style is
that it moves the bug reference from the short explanation to the main
description.
I'm not entirely sure which is better here, a little experimentation
may be needed to come up with the best style.


For Pango I continue to use the bug title line as my short summary.  If 
needed, I retitle the bug first.  For example:



commit cf13cde8a80c9a1a9d4c9e343c634350da59991a
Author: Behdad Esfahbod beh...@behdad.org
Date:   Thu Mar 26 01:03:43 2009 -0400

Bug 571291 – Unicode 5.1 support in pango - Indic Lanuages

Add char class for new characters.
Patch from Rahul Bhalerao.

commit 477747bc1ef1078b06c4e1c615a1a912e6ada299
Author: Sebastian Dröge sl...@circular-chaos.org
Date:   Mon Mar 23 19:16:58 2009 -0400

Bug 576298 – Fails to link pango-view if --without-x is specified but 
cairo has X11 support


commit c82e8ad9dda142b1acfbcb86054750e082600893
Author: Behdad Esfahbod beh...@behdad.org
Date:   Mon Mar 16 17:25:33 2009 -0400

Bug 547963 – man page for pango-view

commit 69e1f7921525c2849d937b5a822475007a4f9a2f
Author: Behdad Esfahbod beh...@behdad.org
Date:   Mon Mar 16 16:57:58 2009 -0400

Bug 502804 – pango-view or pangocairo-view option to annotate

Added --annotate.

Also fixes:
Bug 502801 – per-backend pango-view options


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving GLib and GTK+ to git

[Behdad Esfahbod]

On 03/31/2009 03:50 PM, David Zeuthen wrote:

Personally I prefer non-capital and no periods; it makes the output of
'git log |git shortlog' nicer to look at (see [1] for an example) but
maybe that's just me. I think capital letters would work nice here too;
trailing periods would probably look weird though.


While I prefer to capitalize sentence starters, NOT capitalizing makes it 
easier to start a commit summary with an API symbol name or other identifiers 
that should not be capitalized.


behdad


  David


[1] :

David Zeuthen (198):
   [...]
   add some notes about terminology
   use the term Name instead of Label when creating a partition
   rework terminology for filesystem labels / partition labels
   fix compiler warnings introduced by the last set of patches
   add some experimental code for grid-based layout
   fix some criticals where we tried to access non-existant widgets
   rework partition table handling

Matthias Clasen (13):
   HIG fixes
   trivial coding style fix
   avoid dialog resizing
   don't allow empty passphrases
   improved spacing for sections
   [...]


___
gnome-i18n mailing list
gnome-i...@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


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

Re: GtkLabel: angle and ellipsize are incompatible?

[Behdad Esfahbod]

On 03/28/2009 01:22 PM, Yu Feng wrote:

Dear List,

I noticed this line in gtklabel.c:

gtk_label_ensure_layout:
...
   if (angle != 0.0  !label-wrap  !label-ellipsize  !
label-select_info)
 {
   /* We rotate the standard singleton PangoContext for the widget,
* depending on the fact that it's meant pretty much exclusively
* for our use.
*/
...

Why is ellipsize incompatible with angle? There at least won't be any
problems when the angle is 90, 180, 270, will there?


Mathias Hasselmann has a patch for that.  I'll review and merge it today.

behdad


Regards,

Yu

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

No GTK+ Hackfest this year

[Behdad Esfahbod]

Hi,

Some may have heard that I've been planning the Bolzano GTK+ Hackfest.  Well, 
given the economy, we are canceling that plan for now.  We are still looking 
into organizing smaller, focused, hackfests around GUADEC and Boston Summit, 
like the introspection hackfest last year.  If you have suggestions, contact 
me off list.


Cheers,
behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: No GTK+ Hackfest this year

[Behdad Esfahbod]

On 03/25/2009 06:56 PM, Andreas Nilsson wrote:

Behdad Esfahbod wrote:

Hi,

Some may have heard that I've been planning the Bolzano GTK+ Hackfest.
Well, given the economy, we are canceling that plan for now.

The global economy or the GNOME Foundations economy?


Well, the two are not really separate.  Last year we raised over 80% of the 
GTK+ hackfest expenses from the advisory board members, and many companies 
paid for airfare of their employees going to the hackfest.  This year we 
failed to do the former, and I expect the latter also being an issue for many 
of the companies.


And the foundation budget is also tight this year.  We don't want to dip into 
our cash reserves too much.  Stormy and J5 are working on a financial report 
and budget for the year which will better explain the foundation numbers.


behdad


- Andreas


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

Re: No GTK+ Hackfest this year

[Behdad Esfahbod]

On 03/25/2009 07:37 PM, Alberto Ruiz wrote:


Behdad, do we have an estimate of how much money the former one costed
(including accomodation, and travel expenses)?

It would be interesting to have that information at hand to figure out
how much money should be raised so that the Foundation could afford
it.


According to my notes:

- Sponsorship money received: 7500 USD + 10236 Euros

- Expenses:

  * 960 Euros + 9800 USD: flight+train for 13 people

  * 5870 Euros: accommodation/venue for ~28 people for a week

  * 1890 Euros: food (breakfast, snacks, three dinner+parties)

  * 900 Euros: misc expenses (tshirts, chairs, power strips, flipcharts, 
markers, video cassettes, etc)


That means about 15 people's airfare was covered by their employers.

This year we had a very generous offer form TIS Innovation Park in Bolzano 
(http://www.tis.bz.it/) and had booked rooms in a decent hostel for very very 
reasonable price.  That would could cut the accommodation+misc+food costs way 
down.  However, I expect we'd need to pay for more airfare as I expect 
companies not being able to send a large delegation like they did last year.


That said, the sponsorship offers we received this year was only about 10% of 
last years, leaving the other 90% to the Foundation to cover, which is really 
hard given that for that amount, there are things more urgent to do.  For 
example, the recent push to hire a part-time sysadmin.


Anyway, tough times, make more a more conservative spending plan, be it for 
foundations or the companies.  By organizing smaller hackfests around other 
events we can get more done for the buck.  As nice as it is to have everyone 
in the same room working together for a week, it seems to be in the best 
interest of the parties involved to postpone such an event for now.


Hope that helps,

behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Plans for GTK+ in the next cycle

[Behdad Esfahbod]

On 03/24/2009 08:24 AM, Murray Cumming wrote:


Other things are of course possible, depending on people signing up to
do the necessary work.


I like to review David's resolution-independence work and help land it.



I think it's long past time to get extended-layout in. I'll get someone
at Openismus to push it if a maintainer will review it.
http://mail.gnome.org/archives/gtk-devel-list/2007-November/msg00145.html


Good point.  Mathias, do you have an up to date git branch of it?


behdad
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: enumerating available fonts

[Behdad Esfahbod]

On 03/18/2009 05:14 PM, Chuck Crisler wrote:

How do I enumerate the fonts available on a system? I suspect
XListFonts() may not yield all of the nicer fonts but I haven't been
able to find anything promising in Pango.


pango_font_map_list_families()?

behdad


Thank you!
Chuck

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