On Sun, May 3, 2009 at 10:27 PM, Rodrigo Miguel rodrm...@gmail.com wrote:
Anyway, I think the same can be achieved by using custom models and I found
really good examples in gconf-editor, gnucash and the Gtk Treeview tutorial
from Tim-Philip, so I decide write a generic custom model like Win32
Hi,
I have inherited an old version of a glade-based program which I am
trying to clean up. I have applied some fixes and for the most part
things are going well, but 1 function in particular is giving me
trouble and I will readily admit that I don't quite understand how
this is working and how
GTK+ 2.17.0 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/2.17/
http://download.gnome.org/sources/gtk+/2.17/
md5 sums:
a1a1f0b66a240c31cb2733643f9170ba gtk+-2.17.0.tar.bz2
d05eb97727e93c3e59af4e747156cca4 gtk+-2.17.0.tar.gz
sha1 sums:
79f74ecd958b2dd78e7662e9d653bfe2039caf95
In execute_input() i can't see a code to make a infinite loop, If you are
curious, see codes of gdk_input_add() and find out why the GdkInputFunction
recalled, btw have you try g_io_add_watch() instead by making a call to
gdk_input_add() the deprecated one?.
--- ajhwb
--- rga...@gmail.com
Kris,
This
can be avoided by using the fixed height mode (please refer to the
documentation and mailing list archives, a lot has been written about
this already). With this it will basically only call get_value() for
visible items.
That will help a lot, since in the tree view I'm seeing
There is a pending TODO to replace
gdk_screen_get_resolution()/set_resolution() with monitor specific
versions.
API has been added for
get_resolution_for_monitor()/set_resolution_for_monitor(), but they're
currently stubs that affect the global resolution. Does anyone have any
ideas on how they
On Sat, 02 May 2009 at 13:02:39 -0400, David Zeuthen wrote:
My view is that it's not really realistic to do this, I think it's
a convenient thing that I can get/pass well-known data-types like
GHashTable or GPtrArray from/to remote objects. This allows adding
D-Bus support to
GTK+ 2.17.0 is now available for download at:
ftp://ftp.gtk.org/pub/gtk/2.17/
http://download.gnome.org/sources/gtk+/2.17/
md5 sums:
a1a1f0b66a240c31cb2733643f9170ba gtk+-2.17.0.tar.bz2
d05eb97727e93c3e59af4e747156cca4 gtk+-2.17.0.tar.gz
sha1 sums:
79f74ecd958b2dd78e7662e9d653bfe2039caf95
On Mon, 2009-05-04 at 13:26 +0100, Simon McVittie wrote:
On Sat, 02 May 2009 at 13:02:39 -0400, David Zeuthen wrote:
My view is that it's not really realistic to do this, I think it's
a convenient thing that I can get/pass well-known data-types like
GHashTable or GPtrArray from/to
On Mon, 04 May 2009 at 10:25:06 -0400, David Zeuthen wrote:
In contrast, most D-Bus clients that I write these days are not based on
the stick GValue in GHashTable, use GValueArray as a struct design
because it's just incredibly awkward to work with.
You're clearly not happy with the
2009/5/4 Simon McVittie simon.mcvit...@collabora.co.uk:
On Sat, 02 May 2009 at 13:02:39 -0400, David Zeuthen wrote:
o I'm worried that GVariant supports a superset of the D-Bus
protocol.
Right, ideally GVariant as merged in GLib should support exactly the D-Bus
protocol (either by code
On Mon, 04 May 2009 at 20:30:13 +0200, Mikkel Kamstrup Erlandsen wrote:
2009/5/4 Simon McVittie simon.mcvit...@collabora.co.uk:
On Sat, 02 May 2009 at 13:02:39 -0400, David Zeuthen wrote:
o I'm worried that GVariant supports a superset of the D-Bus
protocol.
Right, ideally GVariant
On Mon, 2009-05-04 at 19:12 +0100, Simon McVittie wrote:
You're clearly not happy with the representations chosen by dbus-glib
(and I agree that they're not so good - they rarely match an existing
API, and they don't match the real D-Bus data model either).
I hope I'm misunderstanding your
13 matches
Mail list logo
