The talk of gtk 3 coming down the line reminded me a an old question I
once had. I remember reading a paper analyzing X11 performance problems
that concluded drawing operations were slowed because the synchronous
nature of xlib required steps to wait for round trip traffic completion
notifications
Tor Lillqvist schrieb:
Version on win32 (ugli resize grip):
And the versions with the non-ugly resize grip?
2.18.3, is result from pkg-config --modversion gtk+-2.0
don't know how I get more detailed information on Linux System
Do you know the appropriate libraries for the resize grip under
Wait a minute, now I am confused. I thought you said that the look of
the resize grip had changed between two GTK+ versions on Windows? Can
you specify these two exact versions, that you used on Windows, or
not?
Did you use the same theme (or no theme at all) with both GTK+ versions?
--tml
g_signal_handlers_block_by_func() if you just want to block your signal
handler. After toggling GtkCheckMenuItem use
g_signal_handlers_unblock_by_func()
http://library.gnome.org/devel/gobject/unstable/gobject-Signals.html#g-signal-handlers-block-by-func
On 10.8.2010 8:01, KC wrote:
Hi,
Is
Hello, I have developed a GUI application for ARM based product. It has 10
buttons, so I want to link button press to GTK. How can I start to do this?
In which level/layer I have work to get it done?
*Regards,*
* Guruprasad Bhat.*
___
On 21/08/10 12:12, Devin Samarin wrote:
I thought I'd give up update of what the site is looking like now, and
I hope everyone is fine with using this mailing list.
I have integrated tweets from identi.ca in the News Feed on the main page.
I finished the re-design of the GTK-Doc area:
On 12/08/10 11:02, Devin Samarin wrote:
On Thu, Aug 12, 2010 at 1:50 AM, Martyn Russellmar...@lanedo.com wrote:
So my comments:
4. The Downloads page feels the wrong way round to me. I always prefer
more content on the left side where there are multiple columns - must be
my OCD kicking in
On Mon, Aug 23, 2010 at 14:10, Johan Dahlin jo...@gnome.org wrote:
3) g_object_info_get_properties:
transfer could be placed as a GParamFlag and array fixed size / array
null terminated could be added as part of a new g_param_spec_array()
(I am not sure about the latter, are there properties
It might be worth thinking about a gradual path to first allowing new
code to be written with only code to create static typelibs (runtime
registration stuff would be autogenerated), and then in glib/gtk 4.x,
the idea would be to drop the runtime-registration-based introspection
features from
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
01 solves https://bugzilla.gnome.org/show_bug.cgi?id=523260 so I've
attached the patch there too.
Sorry for not inlining, my email client tends to mess it up.
From 040a2451cddb6329686ce9945dd352ea19823510 Mon Sep 17 00:00:00 2001
From: Jon Nordby j...@openismus.com
Date: Thu, 26 Aug 2010
On Thu, Aug 26, 2010 at 1:17 PM, Havoc Pennington h...@pobox.com wrote:
It might be worth thinking about a gradual path to first allowing new
code to be written with only code to create static typelibs (runtime
registration stuff would be autogenerated), and then in glib/gtk 4.x,
the idea
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
eventually figure out how to handles these.
But widgets are supposed to request a size
I talked to Colin. Current plans are that PyGI will only be fully supported on
Gtk3 where Gdk style functionality is going away. See
http://blogs.gnome.org/carlosg/2010/08/23/css-like-styling-for-gtk/ for an idea
of where the styling code is headed. Supporting arbitrary C structs won't be
I moved the URL from
http://eboyjr.homelinux.org:8080/gtk/
to
http://eboyjr.homelinux.org:8081/
It should work (I hope so!)
Devin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On 08/25/2010 08:26 PM, Chris Vine wrote:
This won't work. file descriptor number 1 (stdout) is a file descriptor
you write to, not read from.
If you connect stdout to the write file descriptor of a pipe with
dup2(), and then connect your GIOChannel object to the read file
descriptor of the
On Thu, Aug 26, 2010 at 11:01 AM, Hrvoje Niksic hrvoje.nik...@avl.comwrote:
The good news is that libraries shouldn't require a terminal for stdout
because then they wouldn't work with stdout being redirected to a file
(highly unlikely).
The bad news is that this is harder to do correctly
On 08/26/2010 12:53 PM, richard boaz wrote:
The actual program I intend to use this in is a background process where
the actual processing executes in a separate thread while the main
thread sits in the main loop. With the watch on the read-end of the
pipe, the callback is fired and executes
On 08/26/2010 02:03 PM, Hrvoje Niksic wrote:
Exactly; it doesn't matter which thread is which, it's just important
that they're in different threads or processes, so they don't
deadlock. For example, it wouldn't be enough to place the output sink
in the main loop of a single-threaded
On 08/26/2010 02:16 PM, Magnus Hjorth wrote:
you do (and the size of the output exceeds the pipe's buffer, which is
fairly small), that thread will deadlock deep inside stdio. This can
Is the buffer really that small? I made a simple test program (below) to
check this out, and it seems that
Hi.
First, signal handler for GtkWidget::button-press-event should return
gboolean value, not void. This return value is then used to determine
if the event should be propagated further or not.
If you return FALSE from your signal handler, you indicate that you
haven't handled the event and
On Thu, 26 Aug 2010 14:16:28 +0200
Magnus Hjorth magnus.i.hjo...@gmail.com wrote:
Is the buffer really that small? I made a simple test program (below)
to check this out, and it seems that writes up to 64K work without
blocking on my Ubuntu system. Of course, it is still ugly (and
On 27 August 2010 09:47, Chris Vine ch...@cvine.freeserve.co.uk wrote:
On Thu, 26 Aug 2010 14:16:28 +0200
Magnus Hjorth magnus.i.hjo...@gmail.com wrote:
Is the buffer really that small? I made a simple test program (below)
to check this out, and it seems that writes up to 64K work without
23 matches
Mail list logo
