On Fri, Jun 20, 2014 at 9:01 PM, Jasper St. Pierre
wrote:
> On Fri, Jun 20, 2014 at 11:57 PM, A. Walton wrote:
>
>> On Fri, Jun 20, 2014 at 6:00 PM, Jasper St. Pierre > > wrote:
>>
>>> To better support Wayland with fewer copies and less drawing artifacts,
On Fri, Jun 20, 2014 at 6:00 PM, Jasper St. Pierre
wrote:
> To better support Wayland with fewer copies and less drawing artifacts,
> I've pushed some potentially breaking changes to GDK, namely around
> gdk_cairo_create and gdk_window_begin_paint_region.
>
>
> https://git.gnome.org/browse/gtk+/c
for much.
(sorry for the resend Christian).
On Mon, Oct 7, 2013 at 9:54 PM, Christian Hergert wrote:
> On 10/07/2013 09:36 PM, A. Walton wrote:
>
>> My only question is why GIO and not GDK? This kind of per-platform API
>> would happily reside in GDK and prevent us from adding
op library
between Glib and GTK+), and I can't think of any obvious applications that
would want spell checking and not want GTK+.
Is there a good reason for spell checking to be this low in the stack?
-A. Walton
On Mon, Oct 7, 2013 at 6:36 PM, Matthew Barnes wrote:
> On Mon, 2013-10
.gnome.org/GnomeIrcChannels
Good luck,
-A. Walton
On Wed, Sep 11, 2013 at 2:27 PM, Fan Chun-wei wrote:
> Hi John,
>
> It is indeed a very recent update to glocalfile.c, due to the use of
> dirent. I have opened a bug for it few days ago at
> https://bugzilla.gnome.org/**sho
of Nautilus, I wouldn't imagine it being much
of a savings).
My advice is if you're really interested in this, try it in the small
scale. Write a patch to GtkLabel to make it support taking a GQuark
argument, then port your favorite applicat
tion benchmarks to see how much this means in the
real world and not just for the threaded microbenchmarks that you
wrote? The non-threaded speedups are pretty impressive on their own,
but it'd be nice to see what we could expect from e.g. GStreamer with
these changes applied.
Thanks,
-A. Walton
ing network streams). Probably should do better than "_new"
if we go the interface route. This is how all of the other filter
streams are specified in GIO, IMO it's pointless to diverge much here.
Also wonder if it makes sense as a base class or whether it should be
an interf
ents made. We've had the discussion here twice.
We've had it three times on Ubuntu's lists in the past two years I've
been involved. Anyone want to chime in from Fedora's or SuSE's
community and say how many times they've had it there?
-A. Walton
>
>
2009/4/12 A. Walton :
> 2009/4/12 Grzegorz Kuczyński :
>> Very thanks Regards.
>>
>> Ok I understand the idea, but...
>> how work it? for example:
>> ---
>> struct _GtkWindow
>> {
>> GtkBin bin;
>>
>> gchar *GSEAL (title)
--
> So, when define GSEAL_ENABLE code in gtkwindow.c must change in
> window->_g_sealed__title = new_title; //??
gtk_window_set_title().
> Maybe I can read anywhere for idea macros GSEAL?
> I don't want write stupidity in Wikibooks. Because I want write ana
hout GIcon, from stock
> and
> icon-name (will be better suited to make it buildable).
Have to admit my own ignorance here: shouldn't it be possible to
(Gtk)Build GIcons? We currently have code in the interface for telling
them to serialize and deserialize themselves from a string,
basically have two questions:
>
> 1. How do you create GtkActions with icons based on GIcon?
This is not possible at the moment. Filed #566733 [1] and attached a
preliminary patch.
>
> 2. Are there any plans on adding GIcon counterparts for
> icon-name-based APIs as suggested by
On Wed, May 14, 2008 at 3:15 PM, Stefan Kost <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Emmanuele Bassi schrieb:
>> = minutes for the 2008-05-13 meeting =
>>
> 8< snip 8<
>
>>
>> * rework the gobject tutorial
>> - it is old and unmaintained
>> - the signals section is broken
>> - teaches bad practises
>
is to see what
other application developers would like to see Nautilus expose. I did
some prototype work on this in a git branch when we first discussed
this in IRC a few months ago but at the time I didn't get very far.
Through working on GVFS I've picked up a of understanding he
15 matches
Mail list logo
