On Tue, Aug 31, 2010 at 9:01 AM, Giovanni Campagna
scampa.giova...@gmail.com 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 scampa giovanni gmail
com wrote:
First of all, sorry
)
* 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 gtk+/library maintainers.
--
Johan Dahlin
GObject specific code down the hierarchy?
Designed for the GstMiniObject which lacks properties,
would be easy to extend if you had a real-world use case for it.
Last comment: why none of this API uses GObject and is not even a
registered boxed?
See B)
--
Johan Dahlin
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
this helps
--
Johan Dahlin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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
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
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
clone git://git.gnome.org/modulename
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 rd...@foton.es:
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'
On Mon, Feb 2, 2009 at 1:57 PM, Behdad Esfahbod beh...@behdad.org 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
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 g...@reaperworld.com:
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
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, python (2.5 or higher) and
glib. ffi 3.0.1 or higher can optionally
. 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écinaux
. 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 information.
All contributors to this release:
Johan Bilien
Jürg Billeter
Johan Dahlin
John Ehresman
Tommi Komulainen
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
the
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
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 transfer.
typedef enum
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 ready for more
) and
glib. ffi 3.0.1 or higher can optionally be used.
Reports bugs to
http://bugzilla.gnome.org/enter_bug.cgi?product=glibcomponent=introspection
Contract us at: gtk-devel-list@gnome.org or #introspection at irc.gnome.org
Homepage: http://live.gnome.org/GObjectIntrospection
Johan Dahlin
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 changes
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 bad API
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
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
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 descriptor (the X
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 it going to be a dependency for projects
which
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 use
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
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
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
nicola fragale wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have a problem with a signal I'm trying to implement. My signal has 2
parameter, the second is an enum.
This is the code
~ rubrica_cards_view_signals[MARK] =
~g_signal_new(mark,
~
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 does
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 does
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 up
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
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.
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
- ...
Session
/
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.12.0
/
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.12.0
/
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.12.0
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
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/XUL_Overlays
--
Johan Dahlin [EMAIL PROTECTED]
Async Open
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
twice on the same instance.
Or does merge mean
objects such as treemodels for other purposes outside
of the GtkBuilder hierarchy you'd have to fetch the object before unreffing
the builder.
[1]: http://bugzilla.gnome.org/show_bug.cgi?id=447967
--
Johan Dahlin [EMAIL PROTECTED]
Async Open Source
window object. That's a technique that I use currently.
That sounds like a sensible use case.
I'm using a similar technique in Kiwi, but I do actually instantiate the
main window and throw it away.
--
Johan Dahlin [EMAIL PROTECTED]
Async Open Source
___
gtk
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's _new() function has a root parameter:
http://developer.gnome.org/doc/API/libglade
without a toplevel window.
--
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
Torsten Schoenfeld wrote:
On Mon, 2007-06-18 at 09:55 -0300, Johan Dahlin wrote:
void (* set_property)(GtkBuildable *buildable,
GtkBuilder*builder,
const gchar *name
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 built.
Some of the GtkBuildable methods have
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 another name like
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 would be:
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
*string);
Just curious, but why do you have
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/show_bug.cgi?id=447969
--
Johan
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 would be marginally useful for providing constant user data like...
* Strings: oink
Tim Janik wrote:
On Wed, 13 Jun 2007, Johan Dahlin wrote:
Johan Dahlin wrote:
Christian Persch wrote:
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
GObject
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
* Translated strings:
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, set flags to G_CONNECT_AFTER
swapped: optional, boolean
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
of
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 has an
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
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 there will be a new developer release in the
end of
the week
Johan Dahlin wrote:
Christian Persch wrote:
Hi;
typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder,
const gchar *handler_name,
GObject *object,
const gchar
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 [EMAIL PROTECTED]
Async
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 *builder,
const gchar *handler_name
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 discussion.
I don't think we need
be
supported in the future without breaking the API, such as adding
a couple of new vfuncs to the GtkBuildable class.
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,
eg
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,
eg:
object class=GtkButton id=button/
object class=GtkEntry id=entry
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_nick/name internally.
--
Johan Dahlin [EMAIL PROTECTED]
Async Open Source
___
gtk-devel
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 to get
* gtk_buildable_get_internal_child (GtkBuildable*buildable,
GtkBuilder *builder,
const gchar *childname);
--
Johan Dahlin [EMAIL PROTECTED]
Async Open Source
demo.glade
Description: application
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
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.
--
Johan Dahlin [EMAIL PROTECTED]
Async Open
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
the name
* if the object already has it's own concept of name
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 this realm could
point, I think you just found a bug in the implementation I wrote,
where GtkUIManager needed a special case since the guessing heuristic
resolved at gtk_ui_manager_get_type, GtkVBox is handled properly though.
--
Johan Dahlin [EMAIL PROTECTED]
Async Open Source
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 written in other languages
?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
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, Edward Hervey recently ran
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? I thought it was mostly useful
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.
GtkBuildable is mainly interesting for third party application
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 need
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
I'm a bit worried about performance of that. As far as I can tell, you
cannot optimize for the case of methods implemented in C being called
from C; the emit/notification cycle always marshals the arguments to
GValues and back. This offers excellent flexibility, but at the price
of
Very good read, thanks for a great summary.
Alexander Larsson wrote:
[snip]
We likely don't want the full gnome/unix vfs implementation in
glib, instead glib will only ship an implementation of the vfs API for
local file access, and one that communicates to the vfs
daemon(s). Then we ship the
Gian Mario Tagliaretti wrote:
2006/8/30, W. Borgert [EMAIL PROTECTED]:
OK, as both GooCanvas and CCC come with a demo application, I
just tried out both. At first glance I can only say, that the
GooCanvas demo is more impressive than the CCC one. Maybe
GooCanvas is more feature-rich, but
Murray Cumming wrote:
In the GTK+ meeting at GUADEC
( http://www.gtk.org/plan/meetings/20060625.txt )
there was talk of making GtkLabel editable.
For what is this needed?
As Sven pointed out, it would be useful for UI builders to be able to edit
the text of buttons and labels inplace.
Easy B wrote:
Hi guys
Now that Anders is not actively coding on the port anymore, I guess
nobody really is. Well I would love a nice and complete gtk port on the
mac so I'm trying to contribute where I can. The next thing I want to
give a try is the menubar. I'm aware of the long
with GtkUIManager itself, start a dialog about
that, but it's a separate discussion unrelated to this.
--
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
Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making the
code available for public review.
I went ahead and attached the patch to
Behdad Esfahbod wrote:
On Thu, 11 May 2006, Yevgen Muntyan wrote:
Johan Dahlin wrote:
Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making
Yevgen Muntyan wrote:
Johan Dahlin wrote:
Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making the
code available for public review.
I
Morten Welinder wrote:
When Glade is used with a recent gtk+, it will write lots of
properties that old gtk+ will not understand. Now if those
properties were non-default that is unavoidable, but it is
irritating that one cannot readily edit a glade file on a
new system without hand-patching
[snip]
There should be only one obvious way of doing a specific task.
GtkUIManager is the currently the obvious way of creating menus and
toolbars
Here you go, python programmer in action :)
Seriously speaking, GtkUIManager is not and may not be perfect. The
single fact that it
Damon Chaplin wrote:
On Wed, 2006-05-10 at 11:51 -0300, Johan Dahlin wrote:
We've made a couple of important decisions:
* GMarkup based parser which parses and creates the object tree in one step
go instead of saprving a whole tree in memory.
* breaking xml format compatibility
It'll be fairly easy to add support for this in the signal tag,
so you can specify the data argument. It would require two attributes
one for the data and one for the type, then you'd do:
signal name=activated handler=quit_cb data=window1
data-type=GObject/
void quit_cb (GtkAction
Damon Chaplin wrote:
On Wed, 2006-05-10 at 11:51 -0300, Johan Dahlin wrote:
We've made a couple of important decisions:
* GMarkup based parser which parses and creates the object tree in one step
go instead of saprving a whole tree in memory.
* breaking xml format compatibility
Dan Winship wrote:
Johan Dahlin wrote:
Over the last couple of weeks Henrique Romano and I have been working on
GtkBuilder, a UI constructor intended for inclusion in GTK+.
I'd like to discuss the API and some of the decisions before making the
code available for public review.
I went
1 - 100 of 107 matches
Mail list logo
