Re: Using OpenGL with GTK
On 16 Feb 2014, at 02:59, Rena hyperhac...@gmail.com wrote: What's the ideal way to use OpenGL in a GTK application? It seems like there are a few not very good options: 1) GtkGlExt: great except it doesn't support introspection, so I can't use it from a scripting language without manually writing a binding for it. Not sure if it's still supported? A bug to add introspection has been open for ages. 2) GtkGlArea: seems to be a predecessor to GtkGlExt? 3) SDL: no introspection here either, plus I have to have a separate window for the OpenGL render. Is there another way? you can use Clutter (and Clutter-gtk to embed a clutter “stage” in a GTK window) and cogl (low level GL used by clutter) for opengl-like stuff. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Initial work on a help API
On Thu, 2011-04-21 at 16:16 -0400, Shaun McCance wrote: Hi all, I had a project called Squawk I was working on last year. I chatted a bit with Ryan Lortie about it at the recent help hackfest, and decided to work on it again, but this time directly in GLib and GTK+. The basic idea is that GLib has a help provider API that knows about your application's help. It knows more than just that the help exists. It actually knows about all the topics in your help, their URIs, titles, tags, etc. Then there's a set of GTK+ widgets that consume this. If you want to make a help button in a dialog, instead of just making a button and attaching a static URI to it, you'd make a help button and give it a tag. Then it's up to help authors to tag topics for that button. Then do menus the same way. We can kill off the crappy Help-Contents item, and have the Help menu display whatever topics help authors feel are worth promoting to the menu. You can change widget tags at run-time to make them reflect UI state or what the user is doing. I was looking at reducing the number of patches some Ubuntu packages carry over, and one of them (in several packages) is about launchpad-integration, which adds several items to the Help menu (Get Help online, Translate this application and Report a problem), so I was thinking on writing some GtkHelpMenu widget or something similar that does this automatically. Would that be helpful for upstream GTK? I guess it could do what the launchpad integration thing does (pointing to GNOME bugzilla and translations pages, of course, so that Ubuntu would just have to patch that to point to Launchpad) plus what your code does. So, what do GTK maintainers think about it? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Global Keyboard Shortcuts in GNMOE
On Sat, 2009-05-23 at 18:33 -0700, Sundaram wrote: Hi, I need to do something very similar to GNOME's global-level keyboard shortcuts modifier app. (System-Preferences-Keyboard Shortcuts). Hence I want to refer it's code; I checked it's dialog, but it didn't have any About/Credit's put up on it anywhere. Can someone point me to that project's page or it's source? the source code is in GNOME git (http://git.gnome.org) under the gnome-control-center module. -- Rodrigo Moya rodr...@gnome-db.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Moving useful stuff into the core toolkit (Was Re: Removing libgnome* from nautilus)
On Wed, 2008-10-01 at 20:59 -0400, Allin Cottrell wrote: On Wed, 1 Oct 2008, David Zeuthen wrote: On Wed, 2008-10-01 at 14:22 +0200, Alexander Larsson wrote: I just branched nautilus because I want to work on a small project I have. I want to remove all uses of libgnome, libgnomeui and all the related libs from nautilus. These are not really important to nautilus anymore, and are a large dependency that we mainly don't need. Hopefully this shouldn't be to much work. I'll start today with commiting a removal of the last use of bonobo (we currently use it for unique application functionallity). Cool. As a kinda related question what are your thoughts on moving some of the more useful GIO-related UI classes (NautilusOpenWithDialog for example) into GTK+? I can see stuff like that being useful in Evolution, Firefox, Epiphany etc. [YMMV] Well, my mileage does indeed vary. I could think of various application-specific things that it might be cool to have in GTK from my personal perspective, but I'm not about to try to impose them on other GTK users. IMO, GTK should concentrate on doing the best possible job on those generic GUI functions that are (potentially) common to the greatest number of apps. I'm a bit alarmed by the prospect that GTK should accumulate an increasing proportion of ex-gnome functionality (even though I happen to use gnome myself). For one thing, one very nice property of GTK from the point of view of an app developer is its cross-platform nature. adding gnome functionalities to GTK doesn't imply removing its cross-platform nature, on the contrary, it helps a lot, since having cross-platform implementation so of the most used stuff (open with seems to be in that group) helps a lot in having GTK used for real cross-platform development. If you don't have implementations for such operations, you force developers to use another thing just for that, which might mean they might just give up on using GTK -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Mon, 2007-09-24 at 09:23 -0400, Jody Goldberg wrote: On Mon, Sep 24, 2007 at 02:41:19PM +0200, Rodrigo Moya wrote: On Fri, 2007-09-21 at 16:21 -0300, Johan Dahlin wrote: I'm not sure we should talk about a 'document' there, there are many operations outside of documents which are undoable. yes, we are not talking only about document, and yes, I think it should be in Glib, except for the widgets that might be needed. Agreed. As for transation-based framework, I'm not sure exactly what Jody is thinking about, but to me, if I understood it correctly, it makes a lot of sense to be able to group performed actions into a set that can be undone/redone and even repeated. That would, probably, fit the GIMP's needs, as stated by Sven, to have nested undo groups. Each group would be a transaction, that can be redone/undone/repeated as a single entity. The 'transaction' refered to a mechanism for persisting the details of each operation to a file. 1) The options could be re-played in the case of failure. 2) The data would provide useful hooks for auditing and validation. It seems useful for anything that operates on persistent data, be it a document, or control-center settings. I'm thinking, maybe a crazy idea though, but this could also be useful, once the actions are stored in a file, to be able to repeat/run those actions outside of the application. That is, you could do a set of operations on a document-oriented application, save that to a file, and use that as a sort of 'script' to do the same operations on another document. -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Undo framework
On Sat, 2007-09-22 at 01:01 +0100, Iain * wrote: Do you allow nested undo groups? This is rather important if you want to compose actions from smaller actions and still allow scripts or other higher levels to combine these into a single undo step. We make heavy use of nested undo groups in GIMP. We allow one level of nesting, I can see your point about allowing deeper nesting though and will think about how it could be done. I suppose this is as much of the merging of actions that should take place, I don't see that the UndoManager itself should support automatic merging as each application has different requirements for when a merge should happen, but if we allow multiple nesting of actions then the applications can merge as they see fit. I can see the reason for the non-UI parts to go in GLib, but is there any precedence in having stuff like this in GLib? If it was to go in GLib it would be its own seperate library, which for one thing would kinda suck? why? we already have gthread, gmodule, glib, gobject, gio As for transactional stuff, I would think that it seems overkill for most applications, although it'd be great if we could work out some way to allow those that want it to be able to implement it on top of the base system. I can't see how you could make it generic enough to make everyone happy. this is easy, if the API provides, for instance, a 3-step mechanism: create_context add_stuff close_context thus, normal apps would just call the related 3 functions. More complicated apps would manage different contexts, and be able to associate a context to another one: set_parent_context for instance -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Tue, 2007-05-01 at 12:10 -0500, Hans Petter Jansson wrote: On Mon, 2007-04-23 at 17:03 +0100, Peter Clifton wrote: I've found myself wanting GObject derived GList. The idea is to have a list of things with some GType, and make the API which modifies that list emit changed, deleted, inserted signals, etc. I coded a GObject derived class to do most of this. One thing missing with GList is type safety of course, but if you want, you can add run-time type safety with a class around it. That sounds a bit like you want an MVC data model in GLib. For instance, we could move GtkTreeModel and its associated model parts down. I've been wanting that for a while now, personally. /me too that would make libgda, for instance, not have its own model classes, it could use glib's -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDesktopAppInfo
On Thu, 2007-03-29 at 11:57 +0200, Alexander Larsson wrote: On Thu, 2007-03-29 at 11:27 +0200, Rodrigo Moya wrote: On Wed, 2007-03-28 at 15:51 +0200, Alexander Larsson wrote: On Tue, 2007-03-27 at 15:46 -0400, Dan Winship wrote: Alexander Larsson wrote: Do many apps really require creating launchers from arbitrary desktop files? What is the typical usecase of that? Well, the panel in multiple places (main menu, panel launchers, run dialog). The various panel add-ons/replacements (the Novell main menu and app launcher, Gimmie, deskbar, alacarte, etc). Nautilus, for creating launchers for dropped URLs/apps, and launching them later. Gnome-session for autostart. Beagle, for launching apps in search results. And then there's xfce-panel, Thunar, etc, etc. In the realm of the not-yet-deployed, my EggSMClient code uses the app's desktop file's Exec key to set the XSMP RestartCommand. That also led to a discussion of having a gtk_set_desktop_file() or gtk_application_set_desktop_file() method to call at startup, which would feed EggSMClient the data it needed, plus it could call g_set_application_name() and gtk_window_set_default_icon_name(), and possibly do other setup based on loadable modules, like initializing the bug-buddy signal handlers if the .desktop file includes X-GNOME-Bugzilla- keys, etc. Yeah, there is a clear need for this when implementing the Gnome desktop. But its sort of unix specific, so maybe it doesn't have to be in the very low levels of the stack. OTOH, its not really a large piece of code, especially given GKeyFile. non-GUI apps might need it also, like the new documentation indexer (Spoon - http://live.gnome.org/Yelp/Spoon). In fact, it would be great if this GDesktopAppInfo implemented a .desktop cache, which is much needed for gnome-main-menu and, probably, for spoon. What is Spoon? a replacement for scrollkeeper The risk of adding a specialized thing like a desktop cache to a general library like glib is that it will by accident cause cache bloat in apps that don't require the cache, while at the same time not being aggressive enough on cacheing, and have the special apis needed for the case of the panel. yeah, you're right on this, we don't want to have the cache by default for all apps. -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDesktopAppInfo
On Wed, 2007-03-28 at 15:51 +0200, Alexander Larsson wrote: On Tue, 2007-03-27 at 15:46 -0400, Dan Winship wrote: Alexander Larsson wrote: Do many apps really require creating launchers from arbitrary desktop files? What is the typical usecase of that? Well, the panel in multiple places (main menu, panel launchers, run dialog). The various panel add-ons/replacements (the Novell main menu and app launcher, Gimmie, deskbar, alacarte, etc). Nautilus, for creating launchers for dropped URLs/apps, and launching them later. Gnome-session for autostart. Beagle, for launching apps in search results. And then there's xfce-panel, Thunar, etc, etc. In the realm of the not-yet-deployed, my EggSMClient code uses the app's desktop file's Exec key to set the XSMP RestartCommand. That also led to a discussion of having a gtk_set_desktop_file() or gtk_application_set_desktop_file() method to call at startup, which would feed EggSMClient the data it needed, plus it could call g_set_application_name() and gtk_window_set_default_icon_name(), and possibly do other setup based on loadable modules, like initializing the bug-buddy signal handlers if the .desktop file includes X-GNOME-Bugzilla- keys, etc. Yeah, there is a clear need for this when implementing the Gnome desktop. But its sort of unix specific, so maybe it doesn't have to be in the very low levels of the stack. OTOH, its not really a large piece of code, especially given GKeyFile. non-GUI apps might need it also, like the new documentation indexer (Spoon - http://live.gnome.org/Yelp/Spoon). In fact, it would be great if this GDesktopAppInfo implemented a .desktop cache, which is much needed for gnome-main-menu and, probably, for spoon. Of course, it's still unix-specific, as you say, so why not have an implementation for that, on Windows, that reads the Start menu? Not sure if that would work -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Wed, 2006-10-25 at 17:39 +0100, Emmanuele Bassi wrote: Hi Rodrigo; On Wed, 2006-10-25 at 18:33 +0200, Rodrigo Moya wrote: That could be a route to explore - I think its really important to keep GtkWindow really simple in that respect though - it could be a dialog - it could be a popup window, a popup menu - or even a tooltip, So I would suggest that if we bind such logic into GtkWindow - making it some kind of hybrid composite widget - we should definitly do that in a GtkAppWindow subclass (that could be then used by the GtkApplication in question). and why not have: gtk_window_new - as it is now gtk_window_new_dialog (buttons,...) gtk_window_new_main_app(menus, toolbar, etc) ? Because we have a clear separation: a GtkDialog is a GtkWindow but not the other way around. GtkWindow is a primitive object which should be specialised in subclasses. I'm not sure that having a GtkApplicationWindow is the road to go yay, so it's probably better to have convenience functions on GtkApplication, like: gtk_application_create_dialog gtk_application_create_main_window ? -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Mon, 2006-10-23 at 14:39 +0100, Emmanuele Bassi wrote:
Hi everyone;
...
* API Overview
==
The base cass is GtkApplication - an abstract G_TYPE_OBJECT with a bunch
of methods to be overridden:
struct _GtkApplicationClass
{
GObjectClass parent_class;
...
We have a document-based API using these five vfuncs:
...
gchar * (*new_document) (GtkApplication *application);
gboolean (*save_document) (GtkApplication *application,
const gchar *document_name,
const gchar *document_uri,
gboolean save_backup,
gboolean overwrite,
GError **error);
gboolean (*open_document) (GtkApplication *application,
const gchar *document_uri,
gboolean read_only,
GError **error);
gboolean (*close_document)(GtkApplication *application,
const gchar *document_name,
GError **error);
GSList * (*list_documents)(GtkApplication *application);
...
The vfunc signatures should be self-explanatory.
Each document is addressed by a unique id, using a string; newly created
documents might have a document-timestamp id string, or a
document-monotonic_counter id string; opened documents might use the
MD5 hash of the document URI. Documents have an unique id because there
can be multiple views of the same document and we need to keep a list of
documents as well as windows (and windows for documents) of the
GtkApplication.
Subclasses of GtkApplication *must* override the new_document,
save_document and open_document vfuncs; close_document and list_document
can offer a default implementation (close_document calls save_document
and if successful will remove the document id from the list of known
documents, and list_documents returns the list of known document ids).
so, who would be calling those vfuncs? Gtkapplication internals? If so,
how? Since below you say the app is responsible for creating the UI, how
does Gtkapplication know Open/Close/Save have been selected?
I would really like to have a more generic GtkApplication object, not
really tied to a window (even though it could perfectly have ways for
binding it to a Window). That way, any app (think GUI daemons, like
power manager, for instance) could use it as a central point of access
to the session management, unique apps, main windows, etc.
--
Rodrigo Moya [EMAIL PROTECTED]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Application class
On Wed, 2006-10-25 at 16:03 +0200, Rodrigo Moya wrote:
On Mon, 2006-10-23 at 14:39 +0100, Emmanuele Bassi wrote:
Hi everyone;
...
* API Overview
==
The base cass is GtkApplication - an abstract G_TYPE_OBJECT with a bunch
of methods to be overridden:
struct _GtkApplicationClass
{
GObjectClass parent_class;
...
We have a document-based API using these five vfuncs:
...
gchar * (*new_document) (GtkApplication *application);
gboolean (*save_document) (GtkApplication *application,
const gchar *document_name,
const gchar *document_uri,
gboolean save_backup,
gboolean overwrite,
GError **error);
gboolean (*open_document) (GtkApplication *application,
const gchar *document_uri,
gboolean read_only,
GError **error);
gboolean (*close_document)(GtkApplication *application,
const gchar *document_name,
GError **error);
GSList * (*list_documents)(GtkApplication *application);
...
The vfunc signatures should be self-explanatory.
Each document is addressed by a unique id, using a string; newly created
documents might have a document-timestamp id string, or a
document-monotonic_counter id string; opened documents might use the
MD5 hash of the document URI. Documents have an unique id because there
can be multiple views of the same document and we need to keep a list of
documents as well as windows (and windows for documents) of the
GtkApplication.
Subclasses of GtkApplication *must* override the new_document,
save_document and open_document vfuncs; close_document and list_document
can offer a default implementation (close_document calls save_document
and if successful will remove the document id from the list of known
documents, and list_documents returns the list of known document ids).
so, who would be calling those vfuncs? Gtkapplication internals? If so,
how? Since below you say the app is responsible for creating the UI, how
does Gtkapplication know Open/Close/Save have been selected?
I would really like to have a more generic GtkApplication object, not
really tied to a window (even though it could perfectly have ways for
binding it to a Window). That way, any app (think GUI daemons, like
power manager, for instance) could use it as a central point of access
to the session management, unique apps, main windows, etc.
in fact, if we want to make it easier for the user to create windows
with toolbars and menus, why don't we add convenience functions to
GtkWindow and leave GtkApplication as an 'application management class',
to deal with initialization, list of windows, list of open documents,
access to session management and any other desktop operations, etc, etc?
--
Rodrigo Moya [EMAIL PROTECTED]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: expander.gtk.org
On Tue, 2006-05-02 at 08:10 -0700, Carol Spears wrote: it has its own internet address now: http://expander.gtk.org thanks to everyone who helped track down web log feed(s) and other things. where's the RSS feed? I can't find it on that page? -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Don't multiply by -1 when assigning memory
On Thu, 2006-01-05 at 18:43 +0800, James Henstridge wrote:
Rodrigo Moya wrote:
What Matthias is saying is that in the case of zero args, you don't need
to allocate the full size of GtkBindingSignal: you don't need to
GtkBindingArg embedded at the end of the struct. So the correct answer
would probably be:
sizeof (GtkBindingSignal) + n_args * sizeof (GtkBindingArg) - sizeof
(GtkBindingArg)
hmm, but if I understand it correctly, this would yield an invalid value
when n_args = 0, since it would be:
sizeof (GtkBindingSignal) + 0 * sizeof (GtkBindingArg) - sizeof
(GtkBindingArg)
which will be:
sizeof (GtkBindingSignal) + sizeof (GtkBindingArg)
It would actually be:
sizeof (GtkBindingSignal) - sizeof (GtkBindingArg)
yes, sorry, mistyped it.
is that what we want?
Yes. That allocates enough space for everything except the 1-element
GtkBindingArg array at the end of the structure, which is not a problem
if n_args is 0.
ok, patch attached
--
Rodrigo Moya [EMAIL PROTECTED]
? gdk/quartz/Makefile
? gdk/quartz/Makefile.in
? tests/floatingtest
Index: ChangeLog
===
RCS file: /cvs/gnome/gtk+/ChangeLog,v
retrieving revision 1.7394
diff -u -p -r1.7394 ChangeLog
--- ChangeLog 5 Jan 2006 06:28:57 - 1.7394
+++ ChangeLog 5 Jan 2006 11:20:29 -
@@ -1,3 +1,8 @@
+2006-01-05 Rodrigo Moya [EMAIL PROTECTED]
+
+ * gtk/gtkbindings.c (binding_signal_new): allocate correct amount for
+ signal and arguments.
+
2006-01-05 Matthias Clasen [EMAIL PROTECTED]
* gtk/gtklabel.c (gtk_label_grab_focus): Don't return a value from
Index: gtk/gtkbindings.c
===
RCS file: /cvs/gnome/gtk+/gtk/gtkbindings.c,v
retrieving revision 1.51
diff -u -p -r1.51 gtkbindings.c
--- gtk/gtkbindings.c 5 Jan 2006 04:21:09 - 1.51
+++ gtk/gtkbindings.c 5 Jan 2006 11:20:30 -
@@ -64,8 +64,8 @@ binding_signal_new (const gchar *signal_
guint n_args)
{
GtkBindingSignal *signal;
-
- signal = (GtkBindingSignal *) g_slice_alloc0 (sizeof (GtkBindingSignal) + n_args * sizeof (GtkBindingArg));
+
+ signal = (GtkBindingSignal *) g_slice_alloc0 (sizeof (GtkBindingSignal) + n_args * sizeof (GtkBindingArg) - sizeof (GtkBindingArg));
signal-next = NULL;
signal-signal_name = (gchar *)g_intern_string (signal_name);
signal-n_args = n_args;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Don't multiply by -1 when assigning memory
On Thu, 2006-01-05 at 08:13 -0500, Matthias Clasen wrote: On Thu, 2006-01-05 at 12:25 +0100, Rodrigo Moya wrote: ok, patch attached The patch won't apply, since I reverted the header changes, as mentioned in my last mail. I did the patch from an up-to-date CVS copy, and indeed already committed it after rambokid's approval on IRC. -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATCH] Don't multiply by -1 when assigning memory
Hi
Attached patch fixes a problem I just found out. Running any GTK app
showed this:
GLib-ERROR **: gmem.c:143: failed to allocate 68719477360 bytes
I found the culprit to be the patched function, which was multiplying by
-1 when n_args was 0.
Ok to commit to HEAD?
--
Rodrigo Moya [EMAIL PROTECTED]
Index: ChangeLog
===
RCS file: /cvs/gnome/gtk+/ChangeLog,v
retrieving revision 1.7390
diff -u -p -r1.7390 ChangeLog
--- ChangeLog 4 Jan 2006 11:25:19 - 1.7390
+++ ChangeLog 4 Jan 2006 12:13:02 -
@@ -1,3 +1,8 @@
+2006-01-04 Rodrigo Moya [EMAIL PROTECTED]
+
+ * gtk/gtkbindings.c (binding_signal_new): guard against multiplying
+ by -1 (when n_args is 0).
+
2006-01-04 Michael Natterer [EMAIL PROTECTED]
* gtk/gtkmenutoolbutton.c
Index: gtk/gtkbindings.c
===
RCS file: /cvs/gnome/gtk+/gtk/gtkbindings.c,v
retrieving revision 1.49
diff -u -p -r1.49 gtkbindings.c
--- gtk/gtkbindings.c 28 Dec 2005 04:09:18 - 1.49
+++ gtk/gtkbindings.c 4 Jan 2006 12:13:02 -
@@ -65,7 +65,7 @@ binding_signal_new (const gchar *signal_
{
GtkBindingSignal *signal;
- signal = (GtkBindingSignal *) g_malloc0 (sizeof (GtkBindingSignal) + (n_args - 1) * sizeof (GtkBindingArg));
+ signal = (GtkBindingSignal *) g_malloc0 (sizeof (GtkBindingSignal) + (n_args 0 ? n_args - 1 : 0) * sizeof (GtkBindingArg));
signal-next = NULL;
signal-signal_name = (gchar *)g_intern_string (signal_name);
signal-n_args = n_args;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Don't multiply by -1 when assigning memory
On Wed, 2006-01-04 at 07:34 -0500, Matthias Clasen wrote: On Wed, 2006-01-04 at 13:18 +0100, Rodrigo Moya wrote: Hi Attached patch fixes a problem I just found out. Running any GTK app showed this: GLib-ERROR **: gmem.c:143: failed to allocate 68719477360 bytes I found the culprit to be the patched function, which was multiplying by -1 when n_args was 0. Ok to commit to HEAD? No, thats not the right fix. We do want to subtract one GtkBindingArg size from the GtkBindingSignal size there. that's what it does for all cases, except when it is 0. rambokid approved it on IRC, so it's committed. Let me know what fix needs to be done and I'll provide a new patch, if there's some fix to be done. -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gnome-db] a gtk-app with arm-linux-gcc
On Thu, 2005-06-30 at 16:47 +0530, Raghavendra wrote: Hi all, we are developing a gtk apllication with libgda as a backend processor it works without any problems when gcc is used. but when arm-linux-gcc( as we are developing a application for handheld devices namely simputer) is used it shows - 'libgda/libgda.h : no such file or directory' can anyone help us out? probably a missing -I flag to the compiler? -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On Thu, 2005-06-09 at 00:07 +1000, Jeff Waugh wrote: quote who=Luis Villa Oh, and after the last time we did this, the release team swore mighty oaths to never depend on a released-close-to-gnome-schedule GTK again, since it jeopardizes our release schedule for something that is less tested than the rest of the stack and which in many cases isn't widely used because developers haven't had time to integrate it. I suppose we could reconsider that, but we did it the last time for the same reasons Mark listed, more or less. As a result we had to delay our release and (speaking with my QA hat on) after .0 we still had to track down several issues in gtk that were caused by rushing out a component low-in-the-stack with insufficient real-world testing. So, yeah, I'm pretty strongly against this, though I'm open to persuasion. Oh, and I thought I was the most vocal and conservative about this. :-) How stupid would it be to optionally depend on the new API goodies, so we have the chance to ship 2.6 if needs be? I think that, given the r-t worries, it would be much better to not use any new API goodies at all, as Christian suggested, so that we can return to 2.6 if serious problems are found. In the meanwhile, we can all use jhbuild and test it as much as possible :) -- Rodrigo Moya [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
