On Tue, Aug 31, 2010 at 9:01 AM, Giovanni Campagna
wrote:
> Il giorno lun, 23/08/2010 alle 09.10 -0300, Johan Dahlin ha scritto:
>> [not on gtk-devel, so CC me replies]
>>
>> On Fri, 20 Aug 2010 01:59:09 Giovanni Campagna > com> wrote:
>> > First of all, sorr
and
getters and setters, constructor(s)
* header: everything
* gir: everything
The rest of the actual class logic would be in an overridden file
which is used as input by the idl compiler when source/header classes
are generated.
Of course, this would have to be accepted by the gt
typelib
for GNOME 3.
> 8) On the other hand, all GTypeInstance get a GIObjectInfo, but only
> GObject has properties and signals. Would it be more appropriate to
> move GObject specific code down the hierarchy?
Designed for the GstMiniObject which lacks properties,
would be easy to exten
use introspection, and this was
> added without including introspection.m4 to the pango tree, thus
> rendering it unbuildable on a system that doesn't happen to have
> introspection.m4 lying around in another convenient location.
>
> what is going on?
>
--
Johan Dahlin
_
because i have to "blacklist" those
> C-function calls to make my bindings compile...
This is another case of missing annotations, you need to add a Gio annotation
to get that specific case right.
Hope this helps
--
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
dn't be a blocker for
integration into glib proper. It's more of a 'nice feature' to support.
--
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
ions
PRO: Development process would be separate, leave more control to the
introspection team
CON: Additional dependency for all libraries in the stack
Colin Walters & Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
t-introspection?
Not as far as I know. You'll likely to run into other problems further
on, compiling
typelibs needs to be done on the target CPU.
--
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
e git://git.gnome.org/
Thanks to Owen Taylor and Kristian Høgsberg for helping us converting
the repositories.
--
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Hi Richard,
2009/2/10 Richard Dale :
> When I built a mixed C/C++ program, I had a couple of problems with the
> argument names used in functions in the girepository.h header. There were args
> called 'namespace' and 'type-info' and I changed them to 'gnamespace' and
> 'gtype-info' respectively. P
On Mon, Feb 2, 2009 at 1:57 PM, Behdad Esfahbod wrote:
> Hi,
>
> I'm trying to make a pango devel release but I can't get the
> gobject-introspection stuff happy. Main reason is that it requires 0.6.2 but
> rawhide only has 0.6.1, but there's also a bunch of autotools-related
> improvements that
-devel-list@gnome.org or #introspection at irc.gnome.org
Homepage: http://live.gnome.org/GObjectIntrospection
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
2009/1/17 Gary Kramlich :
> I've run into a few issues with g-ir-scanner and was hoping someone
> could help.
>
> First off, I'm getting a ton of warnings about unable to find include
> files, as well as syntax errors. I assume this is because I'm trying to
> generate my .gir off of the source dir
Soup. They should
at some point go upstream as well.
All contributors to this release:
Colin Walters
Dan Winship
Étienne BERSAC
Ross Burton
Havoc Pennington
Jani Monoses
Johan Bilien
Johan Dahlin
Jürg Billeter
Lucas Rocha
Mikkel Kamstrup Erlandsen
Owen Taylor
Philipp Sadleder
Ross Burton
Steve Fréc
d
in the tarball for more information.
Thanks to all contributors to this release:
Étienne Bersac, Johan Bilien, Jürg Billeter, Johan Dahlin,
Tommi Komulainen, Tom Parker, Lucas Rocha, Andreas Rottmann
Colin Walters, Dan Winship, Owen Taylor
GObject-Introspection requires flex, bison, pyt
a header scanner, Colin Walters for helping out
everywhere and making sure the release got done. Richard Hult & Tor
Lillqvist for testing and making sure it works on MacOS X & Win32.
See http://live.gnome.org/GObjectIntrospection and the README included
in the tarball for more info
On Thu, Oct 30, 2008 at 10:26 AM, Tim Janik <[EMAIL PROTECTED]> wrote:
Hey All.
[..]
To allow reliable subscription to all GLib/Gtk+ bugs, I suggest that:
a) We *always* use [EMAIL PROTECTED] as "QA Contact" for components.
b) We use "Default Assignee" in cases where individuals will tackle
Behdad Esfahbod wrote:
Colin Walters wrote:
Here is a patch, should apply to the latest git.
I also like to see gobject enum types for cairo.
Also, should the type names be CairoContext-like or simply cairo_t? If this
is going to be used by introspection stuff, CairoContext sounds correct.
Colin Walters wrote:
(Using this list for gobject-introspection development for now,
probably ignore if you're not jdahlin =))
I was looking a bit today about applying our shiny new introspection
tool to Totem, with an eye to eliminating the manual binding
infrastructure, and more generally figu
Murray Cumming wrote:
On Mon, 2008-09-08 at 10:09 -0500, Mike Kestner wrote:
On Sun, 2008-09-07 at 17:39 +0200, Johan Dahlin wrote:
Paul Pogonyshev wrote:
Johan Dahlin wrote:
[...]
> I'm leaning towards using the "ownership" terminology instead of "tr
Paul Pogonyshev wrote:
Johan Dahlin wrote:
[...]
> I'm leaning towards using the "ownership" terminology instead of "transfer".
typedef enum {
GI_OWNERSHIP_CALLER, /* caller owns it, caller should free it after use */
GI_OWNERSHIP_CALLEE /* callee owns i
Alexander Larsson wrote:
On Mon, 2008-09-01 at 09:35 +0200, Johan Dahlin wrote:
I'm proud to announce the initial release of GObject-Introspection.
Colin Walters and I have been hacking madly on it for the past couple of
weeks and we have finally reached a point to where we're read
Murray Cumming wrote:
On Mon, 2008-09-01 at 16:33 +0200, Johan Dahlin wrote:
[..]
As I've told Johan, this won't be possible for significant amounts of
the API, because human thought really is required to make truly usable
APIs. And I worry that the auto-generation will create ba
Michael Lawrence wrote:
[..]
The VAPI format from the Vala project is a nice human-writeable format
that should soon be convertable to GIR (currently can be converted to GIDL).
Example:
public class Gtk.Label : Gtk.Misc {
public void get(out text);
...
}
Using an IDL such as VAPI has been
BJörn Lindqvist wrote:
2008/6/2 Johan Dahlin <[EMAIL PROTECTED]>:
An alternative here is make a clean break, eg only use this in new
language bindings and make the typelib/GIR define the API.
For Python I plan to;
* Convert PyGTK .defs to .xml, still keep them locally
* Find out the c
, python (2.5 or higher) and
glib. ffi 3.0.1 or higher can optionally be used.
Reports bugs to
http://bugzilla.gnome.org/enter_bug.cgi?product=glib&component=introspection
Contract us at: gtk-devel-list@gnome.org or #introspection at irc.gnome.org
Homepage: http://live.gnome.org/GObjectIntrospe
Morten Welinder wrote:
2008/8/25 Mathias Hasselmann <[EMAIL PROTECTED]>:
Hi,
The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES
and GTK_STOCK_NO encourages creation of horrible user interfaces.
[..]
(For the record, I seem to have lots of _RESPONSE_ lying around,
but no
Patrick Hallinan wrote:
On Mon, 2008-07-28 at 10:06 -0400, Owen Taylor wrote:
On Sun, 2008-07-27 at 14:40 -0400, Patrick Hallinan wrote:
On Sun, 2008-07-27 at 14:24 -0400, Paul Davis wrote:
On Sun, 2008-07-27 at 14:08 -0400, Patrick Hallinan wrote:
Hi,
I wish to help with the development of
Owen Taylor wrote:
On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote:
On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote:
Hi,
IMO, if you're still using GtkCTree and GtkCList, which were
deprecated when GTK+ 2.0 was released 6 years ago, you're asking for
trouble.
Well, they do work
Murray Cumming wrote:
Every time that a parallel-installable GTK+ 3.0 has been proposed, and
now that it has been decided, I have asked for a list of actual useful
features that it will make possible. I've had no luck so far.
We need to offer people a future with some specific advantages so it
d
Mikkel Kamstrup Erlandsen wrote:
[..]
* Relation to GObject-introspection. As far as I can tell GProxy and
GObject-introspection are two completely different things. Maybe I do
not understand the implications of GObject introspection fully?
No, they are actually related
You should check the li
Felipe Contreras wrote:
2008/6/29 Johan Dahlin <[EMAIL PROTECTED]>:
Havoc Pennington wrote:
Hi,
2008/6/25 <[EMAIL PROTECTED]>:
1）I use glib's main event loop, but why glib's main event loop don't support
epoll/kqueue?
The GLib event loop has been designed to
Havoc Pennington wrote:
> Hi,
>
> 2008/6/25 <[EMAIL PROTECTED]>:
>> 1）I use glib's main event loop, but why glib's main event loop don't support
>> epoll/kqueue?
The GLib event loop has been designed to handle a low number of file
descriptors. Typical Gtk+ applications uses only 1 file descripto
Htëchnö mkö wrote:
I need to stop a process if gtk_events_pending() is true and the next
GtkEvent-type is not a expose-event.
But I did not find tools in gtk to get the next event in gtk event
queue, like gdk_event_peek() return the next event in gdk event queue
how i can access manually to
Yevgen Muntyan wrote:
[..]
> Say, this Gtk-3.0 idea sucks. It brings nothing to application
> developers, yet application developers will be effectively forced
> to migrate to avoid problems. You are doing a disservice to
> application developers with this. It's a road to 4.0? Give me
> a break, ca
GTK+ C function to convert from a GObject
> to a custom data-structure and any necessary code to handle when a
> function modifies parameters.
We're using a complete bison/lex based C parser which so far has been
able to parse the whole stack, it is different from earlier header pars
Havoc Pennington wrote:
> Hi,
>
> On Sun, Jun 1, 2008 at 11:53 AM, Yevgen Muntyan <[EMAIL PROTECTED]> wrote:
>> Too bad gobject-introspection depends on python-2.5. Is
>> it going to be a dependency only for gobject-introspection
>> itself, or is it going to be a dependency for projects
>> which u
Yevgen Muntyan wrote:
> Hi there,
>
> On Jun 1, 2008, at 10:00 , Johan Dahlin wrote:
>
>> [gobject introspection stuff]
>
> Too bad gobject-introspection depends on python-2.5. Is
> it going to be a dependency only for gobject-introspection
> itself, or is i
This mail is long overdue, but I finally got my act together and started to
prepare for an initial release.
== Introduction ==
GObject-introspection is a package which will collect and extend the API
metadata for GObject based libraries. The main motivation of this work is to
centralize all in
Cody Russell wrote:
> Is there a definitive format we should be using right now in ChangeLog?
> I mean mostly where we put the bug# and stuff. I noticed that recently
> there are two different formats being used:
[..]
> Does it matter which one I use when committing stuff, or is there a
> preferre
Buenos dias,
Tim Janik wrote:
> Hello Gtk+ Crowd.
...
> Further comments are of course welcome, we intend to keep the
> document updated as new issues are raised/solved.
The proposed plan to migrate to Gtk+ 3.0 is going to remove public struct
fields and introduce new accessors for these attribut
Vlad Grecescu wrote:
> Hello list,
>
> I don't know if there's any interest / work in progress on this, but
> noticing that the new Gio implementation lacks a directory monitor for
> windows I wrote one (patch against 2.15.4 attached, should work on
> 2.15.5 too)
Excellent!
I am sure win32/gtk
amol wrote:
> Hi,
> When we do gtk_buildable_set/get_name for any object created through
> GtkBuilder, GtkBuildable does g_object_set/get_data to return the
> corresponding name of object if its set/get_name are not overridden.
> But GtkWidget overrides set/get_name of buildable interface and doe
Martyn Russell wrote:
> Hi,
>
> The final draft of the new GTK+ web site has been complete with help
> from Andreas Nilsson and are now available here:
>
> http://imendio.com/~martyn/gtk/draft-final/
>
> The plan is to upload these pages on Tuesday sometime. If anyone has any
> issues to take
Sorry for being late in the game for comments, but here we go.
In general this api differs slightly from JUnit/python, which has the
following (main) methods:
assertEqual
assertNotEqual
assertTrue
assertFalse
assertRaises
Perhaps the term "equals" could be used instead of "cmp".
asse
amol wrote:
> Hi
> If i used gtk_builder_add_from_string to parse some string for builder
> which already has some content then application terminates with
> following message
> >Gtk-ERROR **: file gtkbuilder.c: line 567
> (apply_delayed_properties): assertion failed: (object != NULL)
> if
Havoc Pennington wrote:
> Hi,
>
> I had a random thought at the summit; what if we add a new library in
> the stack (perhaps shipping with GLib or GTK tarball, I don't know).
> Call it libgapplication. It would contain:
>
> - GApplication
> - GSettings
> - dbus main loop hooks
> - ...
k.org/
Overview of Changes from PyGTK 2.11.0 to 2.12.0
===
The GTK+ Team:
Gustavo Carneiro, Johan Dahlin, John Finlay
Christian Robottom Reis
Special thanks to:
Gian Mario Tagliaretti
Paul Pogonyshev
Thanks to everybody else who has contributed to PyGTK+ 2
Jody Goldberg wrote:
> On Fri, Sep 21, 2007 at 05:51:26PM +0100, Iain * wrote:
>> Hi,
>>
>> I've had an undo framework in Marlin for years now, but recently
>> people have been using it in other things (notably Ross in Tasks - ok,
>> actually, he's the only one) and we discussed suggesting this for
Murray Cumming wrote:
> On Wed, 2007-06-27 at 11:12 -0300, Johan Dahlin wrote:
>> Murray Cumming wrote:
>>> By the way, if GtkBuilder can't be used for multiple top-level widgets,
>>> we should probably check that gtk_builder_add_from_*() are not called
>>>
kUIManager merges for
widgets), but we might support it in the future.
> And this would make it even more useful to have *_new_from_file() and
> *_new_from_string().
See http://bugzilla.gnome.org/show_bug.cgi?id=447969 for a simplified API.
[1]: http://developer.mozilla.org/en/docs/
ture by adding a "rootnode" property
> to the builder if its really needed.
>
> For your particular use case though, you dont need to instantiate
> a useless window; there's no need for toplevel ui objects to be
> GTK_TYPE_WINDOW().
I think the proper solution to this probl
Murray Cumming wrote:
> On Tue, 2007-06-26 at 10:42 -0300, Johan Dahlin wrote:
>> Murray Cumming wrote:
>>> On Tue, 2007-06-26 at 14:19 +0300, Kalle Vahlman wrote:
>>>> 2007/6/26, Murray Cumming <[EMAIL PROTECTED]>:
>>>>> libglade&#
xml parser of GtkBuilder
is implemented.
> I am concerned that this makes it impossible to use GtkBuilder to define
> the properties for a single widget, without instantiating a useless
> invisible window object. That's a technique that I use currently.
That sounds like a sensible use
all children.
gtk_widget_destroy(window) should later free all the resources, including
GObjects such as GtkUIManager, GtkTreeModel.
If you want to reuse objects such as treemodels for other purposes outside
of the GtkBuilder hierarchy you'd have to fetch the object before unreffing
Torsten Schoenfeld wrote:
> On Mon, 2007-06-18 at 09:55 -0300, Johan Dahlin wrote:
>
>>>> void (* set_property)(GtkBuildable *buildable,
>>>> GtkBuilder*builder,
>>>>
Hubert Figuiere wrote:
> Murray Cumming wrote:
>
In the new header file of gtkbuilder, it use typename as parameter's
name, typename is a keyword of C++, so when compile C++ application such
as gtkmm, thunderbird, it will cause compile error, so it is better to
change it to ano
Torsten Schoenfeld wrote:
> On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
>
>> gtkbuildable.h
>> ==
>>
>> GtkBuildable is an interface which is implementable to allow a GObject
>> subclass to customize the behavior of how it is going to be
Johan Dahlin wrote:
> Morten Welinder wrote:
>>> user_type and user_data which I proposed doesn't make too much sense,
>>> it's
>>> also difficult to support since you can't (AFAICT) use a GValue as
>>> user data.
>> It woul
Havoc Pennington wrote:
> Hi,
>
> Johan Dahlin wrote:
>> Havoc Pennington wrote:
[...]
> A possible convenience API could be to have a global singleton builder
> or a hash of per-file builders and then something like:
I reported this as;
http://bugzilla.gnome.org/s
Tim Janik wrote:
> On Wed, 13 Jun 2007, Johan Dahlin wrote:
>
>> Samuel Cormier-Iijima wrote:
>
>>> gint gtk_builder_enum_from_string(GType
>>> type,
>>> const char
>&
Tim Janik wrote:
[..]
>> Would that be enough?
>
> why? what is the type specification good for if it's not an object?
> and, didn't an earlier variant of your code match object="button"
> to some "button" object from the builder file? so then, the straight
> forward mapping of the GSignal API wou
Damon Chaplin wrote:
>> I think its quite important here to not repeat one of the
>> the most obvious mistakes of glade/libglade, swapping the
>> signal based on the fact that an "object" was specified
>> is confusing - it also rules out the use case of specifying
>> a signal that is not swapped &
Damon Chaplin wrote:
> On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote:
>
>> Anyway, my point here is not wrt code that exists already in Gtk+,
>> I am of the opinion that GContainer iface is "missing", and that
>> objects in general use other objects in general, and in that process
>>
Steve Frécinaux wrote:
> On Thu, 2007-06-14 at 10:41 -0300, Johan Dahlin wrote:
>
>> Let's use this xml attributes for the signal tag;
>>
>> name: signal name
>> handler: handler to connect the signal to
>> after: optional, boolean if True,
Morten Welinder wrote:
>> user_type and user_data which I proposed doesn't make too much sense,
>> it's
>> also difficult to support since you can't (AFAICT) use a GValue as
>> user data.
>
> It would be marginally useful for providing constant user data like...
>
> * Strings: "oink"
> * Translat
Tim Janik wrote:
> On Wed, 13 Jun 2007, Johan Dahlin wrote:
>
>> Johan Dahlin wrote:
>>> Christian Persch wrote:
>>>> Hi;
>>>>
>>>>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>>&g
Morten Welinder wrote:
>> Since it accepts a nick, name or number, it's using
>> g_enum_get_value_by_nick/name internally.
>
> ...in which case it belongs in glib.
Large parts of GtkBuilder "belongs" to glib, (de)serialization of objects is
not tied to a graphical toolkit. It's difficult as it is t
*string);
>
>
> Just curious, but why do you have gtk_builder_enum_from_string when
> something
> similar already exists in GObject as g_enum_get_value_by_nick/name?
Since it accepts a nick, name or number, it's using
g_enum_get_value_by_nic
Tristan Van Berkom wrote:
[..]
>>> Another important point that was raised:
>>>
>>> On Wed, 2007-06-13 at 10:01 -0300, Johan Dahlin wrote:
>>> [...]
>>>> Well, actually swapped handlers are supported, using the object attribute,
>>>>
der, and ofcourse I can port it in...)
Something like this would be better, to have an api which would
define a relation between an and a .
I don't know how this should be done right now, but it could easily be
supported in the future without breaking the API, such as adding
a couple of
Christian Persch wrote:
> Hi;
>
> Le mercredi 13 juin 2007 à 11:07 -0300, Johan Dahlin a écrit :
>> Is there are reason to prefer glade_xml_signal_connect[data] to the
>> connect_signals() api? Assuming we add a user data argument to
>> connect_signals, see separate dis
Christian Persch wrote:
> Hi;
>
> Le mercredi 13 juin 2007 à 10:01 -0300, Johan Dahlin a écrit :
>> Johan Dahlin wrote:
>>> Christian Persch wrote:
>>>> Hi;
>>>>
>>>>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *bu
ra parameter is not a big deal.
> Putting a DestroyNotify there will create the following (easy) bug scenario:
Actually a GDestroyNotify is probably not a very good idea since the life
cycle of the data structure is normally not tied to the process of
connecting the signals.
--
Johan Dahlin
the
user data
2) Add a new method which is similar to gtk_builder_connect_signals but
accepts user_data and perhaps a GDestroyNotify.
Any preference? I'm leaning towards the latter.
--
Johan Dahlin <[EMAIL PROTECTED]>
Async Open Source
__
Johan Dahlin wrote:
> Christian Persch wrote:
>> Hi;
>>
>>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>>>const gchar *handler_name,
>>>
Christian Persch wrote:
> Hi;
>
>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
>>const gchar *handler_name,
>>GObject *object,
>>const gchar *signal_name,
>>
Tim Janik wrote:
> On Tue, 12 Jun 2007, Johan Dahlin wrote:
>
>> Hi,
>>
>> During the Gtk+ developer meeting today it was decided that there
>> will be a
>> final GtkBuilder discussion before it gets committed to trunk.
>> The current plan is that th
Paolo Maggi wrote:
> Hi,
>
> why do gtk_builder_add_from_file and gtk_builder_add_from_string return
> a guint instead of a gboolean?
>
> If the positive number returned on success has a special meaning it
> should be documented, otherwise I think it is better to use a gboolean
> like you do in gtk
Yevgen Muntyan wrote:
> Johan Dahlin wrote:
>> [snip]
>>
>
>> /**
>> * gtk_buildable_set_name:
>> * @buildable: a #GtkBuildable
>> * @name: name to set
>> *
>> * Sets the name of the buildable object, it's used to synchronize
>
Steve Frécinaux wrote:
> On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
>> Hi,
>>
>> During the Gtk+ developer meeting today it was decided that there will be a
>> final GtkBuilder discussion before it gets committed to trunk.
>> The current plan is t
he documentation for:
> GtkBuilderConnectFunc: s/intented/intended/ and s/non NULL/non-%NULL/
> gtk_builder_connect_signals_full: s/interpeted/interpreted/
> gtk_buildable_set_property: s/neeeded/needed/
> gtk_buildable_construct_child: s/outsideof/outside of/
Thanks, I'll fix this
Havoc Pennington wrote:
> Hi,
>
> Johan Dahlin wrote:
>> Havoc Pennington wrote:
>>> Is the Hello, World simplest use case as short and simple as it possibly
>>> could be? That's always a handy final litmus test for an API.
>>
>> How do you do an
Matthias Clasen wrote:
> On 6/12/07, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>> Havoc Pennington wrote:
>> > Is the Hello, World simplest use case as short and simple as it
>> possibly
>> > could be? That's always a handy final litmus test for an API
h would make it easier to
port applications using libglade which has such an api.
--
Johan Dahlin <[EMAIL PROTECTED]>
Async Open Source
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
*buildable,
GtkBuilder *builder,
const gchar *childname);
--
Johan Dahlin <[EMAIL PROTECTED]>
Async Open Source
demo.glade
Description: application/glade
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Murray Cumming wrote:
> On Thu, 2007-06-07 at 10:41 -0300, Johan Dahlin wrote:
>> Murray Cumming wrote:
>>> On Wed, 2007-06-06 at 18:24 -0300, Johan Dahlin wrote:
>>>>> GladeXml has a lookup_type() vfunc for this, which I added (I think) so
>>>>> th
Andrew Cowie wrote:
> On Tue, 2007-06-05 at 14:38 -0300, Johan Dahlin wrote:
>
>> I'm not sure how a language such as Java solves this problem, but a
>> similar solution is required for libglade (glade_xml_get_widget),
>
> Tangentially, since you ask:
>
>
Murray Cumming wrote:
> On Wed, 2007-06-06 at 18:24 -0300, Johan Dahlin wrote:
>>> GladeXml has a lookup_type() vfunc for this, which I added (I think) so
>>> that we could instantiate gtkmm GTypes rather than GTK+ GTypes. This
>>> allows GladeXml to delegate the de
Murray Cumming wrote:
> On Tue, 2007-06-05 at 11:02 +0200, Andy Wingo wrote:
>> Hi Tristan,
>>
>> On Mon, 2007-06-04 at 15:32 -0400, Tristan Van Berkom wrote:
>>> One thing that might or might not be a can of worms is
>>> language bindings. I wonder if someone more experienced
>>> than myself in th
Tristan Van Berkom wrote:
> On Mon, 2007-06-04 at 16:04 -0300, Johan Dahlin wrote:
[..]
> One thing that might or might not be a can of worms is
> language bindings. I wonder if someone more experienced
> than myself in this realm could point out how we plan
> to load widgets w
[A_Z]{2,} | [A-Z][a-z0-9]+
>
> As I said, "something like" ... to correct myself:
>
> WORD := [A-Z]{1,2}[a-z0-9]+ | [A_Z]{2,}
>
> Not that anybody probably would have noticed...
Good point, I think you just found a bug in the implementation
t.cgi?id=89349
--
Johan Dahlin <[EMAIL PROTECTED]>
Async Open Source
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Alberto Mardegan wrote:
> ext Tristan Van Berkom wrote:
>> I think it would be much better for everyone if we get GtkBuilder done
>> now and not evolve on libglade, my concern here is mostly based on
>> the diverse ways in which you can represent widgets in xml: libglade
>> might do it one way, Gtk
Behdad Esfahbod wrote:
> On Tue, 2007-01-30 at 08:22 -0500, Johan Dahlin wrote:
>> + atypes = g_new (ffi_type *, n_args);
>> + args = g_new (gpointer, n_args);
>
> How about using gslice?
>
Does it really make sense to use GSlice when allocating an array of
pointers?
Johan Dahlin wrote:
> Hi,
>
> Attached is a patch that adds a generic cclosure marshaller using libffi to
> gobject. The reason for this is to allow signals of GObjects written in a
> language binding to call signal callbacks in C.
> It's not just a theoretical case, Edw
n the
near future?
Comments and suggestions on the patch are welcome.
--
Johan Dahlin
Mudanças de propriedades em: tests/gobject
___
Nome: svn:ignore
- Makefile
Makefile.in
accumulator
defaultiface
gvalue-test
ifacecheck
if
Tristan Van Berkom wrote:
> On Tue, 2007-01-23 at 13:21 -0200, Johan Dahlin wrote:
[..]
>>> Showstoppers:
>>> =
[..]
>> Which other parts are incomplete, could you provide a list of interfaces
>> you'd like to have documented.
>> GtkBui
Hi Tristan
Tristan Van Berkom wrote:
> Hi all,
>As we discussed in the last meeting - here is my evaluation the
> state of affairs on the gtkbuilder front, it mostly includes all the
> stuff I think is essentially needed before the code is production ready,
> and a few unclear points I think
Magnus Bergman wrote:
[..]
>> Platform and desktop customization needs, especially in the embedded
>> market go far beyond the themability support Gtk+ currently offers.
>> E.g. for touchscreens, special input methods (hand writing
>> recognition or virtual keyboards) need to be implemented, and
>
1 - 100 of 124 matches
Mail list logo
