Hi,
I would like to know how can I scroll my gtk application window programmically?
I have tried this, but the scroll bar does not make and the content of
the window did not get refresh?
GtkWidget* topLevelWindow;
GdkWindow* win = topLevelWindow-window;
gdk_window_scroll (win, 1, 880);
Kalle Vahlman wrote:
2007/11/14, Alp Toker [EMAIL PROTECTED]:
Matthias Clasen wrote:
Well, I have certainly considered C ABI compatibility to be the main
deciding
factor when making such decisions. I'd say if C# interfaces are inflexible
like
that then mapping GObject interfaces directly
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by the binding. Of
course, if this is a more general problem, *then* it might be
approperiate to refrain from adding
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by the binding. Of
course, if this is a more general problem,
Alexander Larsson wrote:
On Wed, 2007-11-07 at 16:18 -0500, Behdad Esfahbod wrote:
On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote:
glib would need dbus as a build requirement for this to work (needs the
dbus types), and the glib header for the function would have to be
separate
On Wed, 2007-11-14 at 12:02 +, Gustavo J. A. M. Carneiro wrote:
I guess that new vfuncs are usually tested for NULL before being
called.
Actually, I'd expect this for all vfuncs. In general, I'd expect the
interface to adapt to not having its new vfuncs implemented. C can
do
that.
On Qua, 2007-11-14 at 12:18 +0100, Murray Cumming wrote:
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by
Alp Toker wrote:
Alexander Larsson wrote:
On Wed, 2007-11-07 at 16:18 -0500, Behdad Esfahbod wrote:
On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote:
glib would need dbus as a build requirement for this to work (needs the
dbus types), and the glib header for the function would have
On Wed, 2007-11-14 at 11:39 +, Alp Toker wrote:
Alex, this topic seems to become popular again every few weeks, and will
probably keep doing so until work is started on some kind of real
libgdesktop module.
GTK+ is used by applications and platforms that don't support libdbus
fully
On Wed, 2007-11-14 at 12:18 +0100, Murray Cumming wrote:
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote:
Matthias is right IMO, if you need to limit the additions of
GInterface methods for C#, it should be done by
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
GtkCellLayoutIface clif;
Bar baz;
} Foo;
is going to see random crashes when
On Wed, 2007-11-14 at 09:30 -0500, Morten Welinder wrote:
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
No issues with GIO being in GLib. I'm looking forward to working with
GIO and gvfs.
So, I assume you're talking about the dbus/glib mainloop integration
library havoc mentioned. (Because if you think gvfs should use some shim
to allow you to replace the dbus implementation you're out of your
On Wed, 2007-11-14 at 14:56 +, Alp Toker wrote:
No issues with GIO being in GLib. I'm looking forward to working with
GIO and gvfs.
So, I assume you're talking about the dbus/glib mainloop integration
library havoc mentioned. (Because if you think gvfs should use some shim
to allow
On Wed, 2007-11-14 at 14:00 +0100, Alexander Larsson wrote:
I guess that new vfuncs are usually tested for NULL before being called.
Actually, I'd expect this for all vfuncs. In general, I'd expect the
interface to adapt to not having its new vfuncs implemented. C can do
that.
That is
On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote:
In the case you describe GetCells is a pretty core part of the
interface, and its clearly hard to not have it do much. However, that
doesn't mean there are times when its useful. For instance, the default
implementation of the
Alp Toker wrote:
Matthias Clasen wrote:
Well, I have certainly considered C ABI compatibility to be the main deciding
factor when making such decisions. I'd say if C# interfaces are inflexible
like
that then mapping GObject interfaces directly to C# interfaces was probably
wrong.
On Wed, November 14, 2007 11:11 am, Mike Kestner wrote:
On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote:
In the case you describe GetCells is a pretty core part of the
interface, and its clearly hard to not have it do much. However, that
doesn't mean there are times when its
Whyever would you do that? Such a struct would never be useful.
It is a simple use of an existing type in the API. I can create my own
instances of such a type, even if I cannot hand them off to anything
GObject related. I could store signal handlers there, for example.
Bottom line: a
On Wed, 2007-11-14 at 16:32 +, Alp Toker wrote:
Alexander Larsson wrote:
This seem like a totally backwards implementation. You're enforcing a
weird non-native dependency on dbus for windows. A better approach would
be to have a platform independent api for notification (possibly in
On Wed, 2007-11-14 at 17:40 +0100, Murray Cumming wrote:
On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote:
[snip]
While it may not break C ABI/API to add a method to an existing
GInterface, adding a method to an interface is a clear break in C#.
You
must implement all members of a
On Wed, 2007-11-14 at 22:01 +0100, Alexander Larsson wrote:
I think this is similar to a problem we have in gtkmm. When a GTK+
widget implements an extra GInterface, we can't just add a base
class to
our existing C++ class, because that would break ABI in C++. So we
just
don't wrap it,
Hi,
A few dbus integration questions from an application developer who is
somewhat familiar with gtk internals and the win32 port.
* Would gtk be usable on posix-like platforms that do not have dbus
installed and configured? Does OS X fall into this category?
* What happens when something is
Am Mittwoch, den 14.11.2007, 17:40 +0100 schrieb Murray Cumming:
On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote:
[snip]
While it may not break C ABI/API to add a method to an existing
GInterface, adding a method to an interface is a clear break in C#.
You
must implement all
On Wed, 2007-11-14 at 16:44 -0500, John Ehresman wrote:
Hi,
A few dbus integration questions from an application developer who is
somewhat familiar with gtk internals and the win32 port.
* Would gtk be usable on posix-like platforms that do not have dbus
installed and configured? Does
25 matches
Mail list logo
