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
gt
On Wed, Sep 13, 2017 at 11:07 AM, Bill Spitzak wrote:
> On Mon, Sep 11, 2017 at 10:39 PM, Behdad Esfahbod
> wrote:
> > It was actually not that complicated:
> > https://bugs.freedesktop.org/show_bug.cgi?id=102661
>
> Yes that sounds just like my second suggestion.
>
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, drawi
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_signa
xt*,
> 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 S
o 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 resu
on't see how this is pango's job.
>
> On Fri, Jul 28, 2017 at 7:38 AM, Behdad Esfahbod
> wrote:
> > Uli,
> >
> > Can we commit this? I don't think waiting another few years will result
> in
> > a superior patchset. :)
> >
> > Chee
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 wrote:
> Right. In the future we would want to make it show glyphs in the input
> order, ie. not separate c
2017 at 1:59 PM, Matthias Clasen
wrote:
> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter wrote:
>
>> On 07.07.2017 15:23, Matthias Clasen wrote:
>> > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter wrote:
>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>
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
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 h
On Jun 30, 2017 7:51 PM, "Matthias Clasen" wrote:
On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> Hi,
>
> On 28.06.2017 14:23, Behdad Esfahbod wrote:
> > All of you have asked me about the status of color fonts in
> > cairo. There's
> > some
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 hi
uite 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 wrote:
>>
>> I also think bumping soname every six months would be disaster. It
>> was pa
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 d
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 e
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 painfu
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
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 voi
On 13-03-07 07:26 AM, John Emmas wrote:
> +#include/* 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
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.
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 define
On 02/05/2013 02:13 PM, Krzysztof Kosiński wrote:
> 2013/2/4 Matthias Clasen :
>> 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 f
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
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 lik
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 docum
On 05/30/2012 05:17 AM, Paul Davis wrote:
>
>
> On Wed, May 30, 2012 at 3:22 AM, Mikkel Kamstrup Erlandsen
> 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
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
On 09/06/11 10:42, Ryan Lortie wrote:
> On Tue, 2011-09-06 at 10:14 -0400, Behdad Esfahbod wrote:
>> 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 the
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 possib
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,
On 08/06/11 05:27, Matthias Clasen wrote:
> On Wed, Jul 27, 2011 at 8:41 PM, Matthias Clasen
> 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
I don't arrive till Sunday afternoon. Bu I don't have much to discuss at the
GTK+-level either.
behdad
On 07/27/11 14:41, Matthias Clasen 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
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-rea
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 inco
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
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 ellipsi
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 ob
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
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 stu
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 a
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
On 09/21/10 18:02, Emmanuele Bassi wrote:
> - possibly deprecate ::destroy altogether: use weak-pointer/weak-ref
Everyone knows that weak pointers as implemented currently are racy and
unsafe, right?
behdad
___
gtk-devel-list mailing list
gtk-devel-li
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 compl
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
On 08/30/10 14:01, Havoc Pennington wrote:
> Hi,
>
> On Mon, Aug 30, 2010 at 1:26 PM, Behdad Esfahbod 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 existin
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
On 08/26/10 16:13, Federico Mena Quintero wrote:
> On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote:
>> 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
>> ev
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-bord
On 08/18/10 12:50, Paul Davis wrote:
> On Wed, Aug 18, 2010 at 12:44 PM, Matthias Clasen
> 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
>
>
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 chanc
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 real
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.
On 05/15/2010 03:56 PM, Christian Persch wrote:
> Hi;
>
>> Behdad Esfahbod 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 c
On 05/15/2010 03:08 PM, Ryan Lortie wrote:
> On Sat, 2010-05-15 at 14:45 -0400, Behdad Esfahbod wrote:
>> 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, avoi
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,
On 05/14/2010 09:08 PM, Matthias Clasen wrote:
> I'm pondering changing the way we treat the gdk-pixbuf.loaders and
> gtk.immodules files in GTK3. Currently, we locate these in
> $sysconfdir/gtk-3.0, but that is subtly wrong, since the content of
> the files is architecture dependent (library paths
On 05/09/2010 10:46 AM, Matthew Bucknall wrote:
>
> It seems to me that, in the long term, GIO would be a good place to add
> GObject serialization/persistence. Is anyone considering something like
> this? Would those responsible for GIO consider adding such functionality
> to it? I'd be happy to
On 05/07/2010 06:35 PM, Matthias Clasen wrote:
> But by the same token, the utilities need to be renamed too since they
> generally work by loading the modules, gathering some information, and
> writing it out into some index file.
Yes please. Plus, makes packaging a lot easier (no?) and reduces
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
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 commen
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
__
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
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 fil
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
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.
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
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 1
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.
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 imple
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
On 03/16/2010 01:18 PM, Daniel Elstner wrote:
> Hi,
>
> Am Dienstag, den 16.03.2010, 13:01 -0400 schrieb Behdad Esfahbod:
>>>
>>> I've made a glib branch where I tried to optimize the UTF-8 decoding
>>> routines:
>>> http://git.collabora.co.uk
On 03/16/2010 11:20 AM, Mikhail Zabaluev wrote:
> Hello,
>
> I've made a glib branch where I tried to optimize the UTF-8 decoding routines:
> http://git.collabora.co.uk/?p=user/zabaluev/glib.git;a=shortlog;h=refs/heads/fast-utf8
Before any changes are made, can you provide real-world performance
On 03/02/2010 05:55 PM, Filippo Argiolas wrote:
> Anyway, I still think that breadcrumb could be a subclass of this
> "button group" (a subclass widget *is* more complicated than the
> widget it subclasses), but maybe I didn't get the whole breadcrumb
> thing.
Just because a breadcrumb may be impl
ompletely 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).
&
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
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 deta
On 11/30/2009 08:30 AM, Matthias Clasen wrote:
On Mon, Nov 30, 2009 at 7:27 AM, Christian Persch 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 de
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 t
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 c
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
g
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
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
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.or
On 11/10/2009 04:45 PM, Emmanuele Bassi wrote:
4. text-buffer 3.0 request (jessevdk)
- split TextView: single TextBuffer driving two TextView widgets
- there are problems with selection and cursor handling
- move some things from the TextBuffer to the TextView, like the
new EntryBuffer in gtk+
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, Chri
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
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 pre
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
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 t
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
On 05/07/2009 03:28 PM, Alexander Larsson wrote:
The prototypes for e.g. g_initable_new() is purposely the same as
g_object_new(). However, if we change it from:
gpointer g_initable_new (GType object_type,
GCancellable *cancellable,
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.
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://
On 04/27/2009 11:40 AM, Havoc Pennington wrote:
Hi,
On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbod 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 l
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 in
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 va
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 dec
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,
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 we
1 - 100 of 361 matches
Mail list logo
