Re: pre-summit introspection status
On Fri, Oct 10, 2008 at 4:17 AM, Gustavo J. A. M. Carneiro < [EMAIL PROTECTED]> wrote: > On Thu, 2008-10-09 at 21:34 -0400, Behdad Esfahbod wrote: > > Colin Walters wrote: > > > For those not tracking Planet, here's a pre-summit status report on > > > introspection: > > > > > > http://cgwalters.livejournal.com/21209.html > > > > > > Feedback I think would be most helpful is on the annotation syntax, > > > and more eyes checking coverage in gir-repository and filing bugs for > > > the things we're doing wrong. > > > > I have a comment on annotation syntax. I don't like that the annotations > are > > in comments. In Berlin I suggested to Johan that something like Qt's > "slots" > > trick can be used. That is, preprocessor macros that normally expand to > > nothing, but the scanner defines them to something special. Then one > could do > > things like: > > > > /** > > * gtk_list_store_set_column_types: > > * @store: a #GtkListStore > > * @n_columns: > > * @types: : List of types > > */ > > void > > gtk_list_store_set_column_types (GtkListStore *list_store, > > gint n_columns, > > GType*types G_IR_ARRAY > > G_IR_ARRAY_LENGTH(n_columns)); > > > > > > > > Johan didn't see any immediate benefit in that and suggested that it > makes for > > a worse syntax and formatting, and I agreed. > > > > But most recently I was reading the static analysis literature and came > across > > the idea of using gcc user-attributes for source code annotation. Take > the > > above example, then one can define: > > > > #define G_IR_ARRAY __attribute__((user(g_ir_array))) > > > > On the face, it's not much different from what I proposed earlier. > However, > > it has an immense power: you can use gcc or gcc-compatible frontends. > > Moreover, you can write static analyzers that check, for example, that > the > > array is not shorter than its claimed length. The possibilities are > uncountable. > > > > If you don't like the syntax, it can be done on the prototype like, much > like > > G_GNUC_PRINTF stuff: > > > > void gtk_list_store_set_column_types (GtkListStore *list_store, > > gint n_columns, > > GType*types) > > G_IR_ARRAY(types, n_columns); > > > > So, here I am proposing it. Recently some guys at Google used that > format for > > thread-safety static analysis. See: > > > > https://docs.google.com/View?docid=ddqtfwhb_0c49t6zgr > > > > > > Personally, I think we should use whatever is easiest to parse, not what > is more sexy. As far as I can tell, the __attribute__ stuff is only > easier to parse if you use something like GCC-XML (with its associated > problems) to parse the header files. Otherwise the current gtk-doc > syntax appears to me much simpler to parse for a simple > python/perl/whatever script. > Let's also not forget another use of the gtk-doc annotations: it will allow gtk-doc to present this information in some standard way in the actual documentation. Knowing that something is an array of some length is obviously important for using an API, not just for binding to one. Michael > > -- > Gustavo J. A. M. Carneiro > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > "The universe is always one step beyond logic" -- Frank Herbert > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection
On Mon, Sep 1, 2008 at 7:33 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> 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 between the .gir in gir-repository/upstream and
>>> apply fixes/patches on top of them
>>> * Write a new module, eg pybank which interacts with the typelibs only
>>>
>>> That means that the old cruft we collected in PyGTK will only
>>> be cruft there and not upstream. For future modules we'll use the
>>> more 'dynamic' bindings as available in pybank.
>>>
>>
>> About the xml format... What is the advantage of having the c library
>> meta data stored in xml format instead of s-expressions? The .defs
>> files used for Python bindings are very succinct in comparison to the
>> ugly .xml files GIR brings to the table. Writing and updating
>> s-expressions is much easier than xml.
>>
>
> There were a couple of reasons to switching to xml over s-expressions.
> The primary one is that XML is more popular, most modern languages
> have parsers builtin which will make it easier to write tools upon it.
> Other reasons includes that xml is more flexible.
>
> The GIR XML is meant to be processed & modified by tools, not human beings.
>
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);
...
}
>
> And presumably, you would still have to hand-write large parts of the
>> bindings using something analogous to PyGTK's overrides. I can't think
>> of any automagic that would turn this C function:
>>
>> void gtk_label_get (GtkLabel *label, char **text);
>>
>
> We solve that by adding annotations in the gtk-doc comment.
> The specific case you mentioned will have something like this:
>
> /**
> * gtk_label_get
> * @label: the label
> * @text: (out): the text of the label
> */
>
> Which will in turn be create the following XML snippet:
>
>
>
>
> The idea is to annotate most of the available API so almost the complete
> bindings can done without manually overriding parts.
>
> Johan
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GProxy, Dynamic Method Invocation
On Tue, Jul 1, 2008 at 3:08 PM, Johan Dahlin <[EMAIL PROTECTED]> wrote: > 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 libgirepository API which is backed up by a binary > typelib. > The main thing that seems to be missing from libgirepository's dynamic invocation, relative to the "GProxy" proposal, is cross-language support. Currently, it seems libgirepository only supports invocation of C functions via libffi. What about just basing that on GClosure instead, with a libffi implementation of GClosure (I think one already exists)? > > Johan > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection
On Mon, Jun 9, 2008 at 4:21 PM, Michael Lawrence <[EMAIL PROTECTED]> wrote: > > > On Sun, Jun 1, 2008 at 8:00 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote: > >> This mail is long overdue, but I finally got my act together and started >> to >> prepare for an initial release. >> > > [snip] > > >> >> == GIR XML Format == >> >> The core of the GObject-introspection is an XML format which is called GIR >> ( >> GObject Introspection Repository) which contains the API introspection >> metadata for a library or interface entity. >> >> GIR currently contains three different XML namespaces: >> - core >>contains features available in popular programming languages, >>classes, methods, functions, interfaces, properties, strings, >>enums etc. >> - c >>contains features specific to the C language: >>identifiers, symbol names, C types >> - glib >>contains features specific to GLib/GObject: >>signal, GType, flags, paramspec, >> >> The separation of different data in different namespaces allow you >> to reuse it allows you to arbitrarily extend the metadata available >> in different languages. >> > > I've noticed that the Typelib is missing an attribute for the API version, > that is, something similar to the "since" in gtk-doc. My guess is the GIR > format is missing that, as well. I think it would be useful to track the > version at which each symbol was introduced, so that language bindings, for > example, can build against multiple versions of a library. > > Also, an indication of whether a function has variadic arguments would be > useful. I can't find that in the typelib, as far as I've looked. > I'd like to append to this suggestion a field for the default value of a parameter, perhaps stored as a ConstantInfo in the typelib. ConstantInfo seems to only support numeric values now, but it might be good to make the value a GValue, so that we can have e.g. string constants too. > > Thanks for picking up this project and doing a great job, > Michael > > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject-Introspection
On Sun, Jun 1, 2008 at 8:00 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote: > This mail is long overdue, but I finally got my act together and started to > prepare for an initial release. > [snip] > > == GIR XML Format == > > The core of the GObject-introspection is an XML format which is called GIR > ( > GObject Introspection Repository) which contains the API introspection > metadata for a library or interface entity. > > GIR currently contains three different XML namespaces: > - core >contains features available in popular programming languages, >classes, methods, functions, interfaces, properties, strings, >enums etc. > - c >contains features specific to the C language: >identifiers, symbol names, C types > - glib >contains features specific to GLib/GObject: >signal, GType, flags, paramspec, > > The separation of different data in different namespaces allow you > to reuse it allows you to arbitrarily extend the metadata available > in different languages. > I've noticed that the Typelib is missing an attribute for the API version, that is, something similar to the "since" in gtk-doc. My guess is the GIR format is missing that, as well. I think it would be useful to track the version at which each symbol was introduced, so that language bindings, for example, can build against multiple versions of a library. Also, an indication of whether a function has variadic arguments would be useful. I can't find that in the typelib, as far as I've looked. Thanks for picking up this project and doing a great job, Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What's about the efficiency of using c to OOP compare to the c++'s abstraction?
On 10/25/07, Clemens Eisserer <[EMAIL PROTECTED]> wrote: > > > 5) unimportance: C++ might bring some small speed improvements, or it > > might not (see Qt's linking problems, though they might have fixed > > that), but in any case, 10% speed improvements in a widget toolkit > > internals are almost invisible to the user > > > > .. probably some more I've missed. > > Well I guess 5 and the last point are quite tied together. A strong > paint is maintainance and code readability. When looking at GTK's code > I am quite confused for the first time and getting used to this > strange coding style takes quite some time. > Except QT's signal&slot system I don't know to learn new a new OOP > model just to hack a bit in QT. Of course, just because GObject is implemented in C, it doesn't mean one has to write C code to use it. Take a look at Vala, for example. Even with no prior knowledge of C#, it was easy to pick up. Last but not least search for "performance problem" on the GTK list's > and the same for the QT lists. It may be that QT just has way less > developers and such search results are stupid in general, but to some > degree numbers talk for themself. (By the way you can also search on > nvidia's linux forums ;) ) > > lg Clemens > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On 9/19/07, Raffaele Sandrini <[EMAIL PROTECTED]> wrote:
>
> Ok i see there is need to clarify things.
>
> On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote:
> > On Wed, 19 Sep 2007, Raffaele Sandrini wrote:
> >
> > > Hi there,
> > >
> > > While implementing abstract properties in Vala we encountered a
> problem
> > > regarding string properties with getter and setter functions:
> > >
> > > public interface Test.MyIface {
> > > public abstract string text { get; }
> > > }
> > >
> > > A getter function of an abstract string property looks like:
> > > char* test_my_iface_get_text (TestMyIface* self) {
> > >char* value;
> > >g_object_get (G_OBJECT (self), "text", &value, NULL);
> > >return value;
> > > }
> > >
> > > Property accessors in Vala always return weak references. This leads
> to
> > > a memory leak in the calling function of the getter.
> >
> > i'm not sure what you mean with weak/strong references when it
> > comes to strings. in C, pointers can be handed out which point to
> > 0-terminated char arrays that represent strings. there's on reference
> > counting for strings in C as there is in C++. per convention,
> > for glib/gtk programs, some such string pointers must be g_free()-ed
> once.
>
> With strong/weak references is talk about ownership. If some code needs
> ownership over a string it will dup the string.
>
> >
> > callers of getters have to free the returned string in C.
> > for glib/gtk programs, if the caller doesn't need to free the string,
> > the return value should be G_CONST_RETURN gchar*.
>
> That's right since the getters do not claim ownership they do not need
> to free the strings. The problem is the caller assumes a weak reference
> and will dup it if it needs ownership.
> The point here is that we are talking about *abstract* properties i.e. i
> do not know whether the implementation uses a static string or not. I
> have to call g_object_get whether i want to or not.
>
> >
> > > We want property accessors to return weak references so just redefine
> > > the accessors to return a strong reference is only a
> last-resort-option.
> >
> > requesting that all string return types should be const char* is
> technically
> > not possible, because some strings need to be constructed in getters.
> >
> > people who don't want to deal with these memory allocation issues (const
> > strings vs. caller-needs-to-free strings) should stay away from C, maybe
> > even C++, and use python, java, scheme, other-garbage-collected
> languages.
>
> Vala needs to deal with this issues to enable users who do not want to
> deal with it an easy life.
>
> >
> > > Since we do not see a way around this (yet) and we could not find an
> > > example with strings in another project. I'm asking here if there is a
> > > nice way around this.
> >
> > i'm really not sure i understand your problem here...
>
> We need a way to steal the string from the property i.e. to make sure
> its not a copy of the original.
It's difficult to imagine how one would enforce this, given that the
implementation has complete freedom to copy the string. The GOB string
getters always returned an allocated string. I'm afraid you may have to
resort to that in general.
>
> > > BTW: There are equal issues with properties returning objects only
> there
> > > you can add a hack into the getter unrefing the object before
> returning
> > > it. This is not applicable with strings.
> >
> > this is not applicable with objects. as soon as you called unref(obj),
> > the object will be destructed and gone, you can't hand it on any
> further,
> > "obj" will point to freed memory.
> > in some rare cases and if you're lucky, the object might stay around
> > a little longer because someone else could coincidentally hold another
> > reference. but this can't be relied upon.
> > a well formed getter implementation might do:
> >return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL));
> > once you g_object_unref() this return value, it'll be instantly
> vaporized with
> > a crushing noise (if you hooked up pulseaudio via destruction emission
> hooks ;)
>
> You can check the ref count first. Take a look at the GtkFileChooser
> interface
> there this hack is used several times. (and annotated as such)
>
> All we need from you is either a solution or the statement that this is
> not possible with gobject properties ;).
>
> Forgot to post the bug against Vala:
> http://bugzilla.gnome.org/show_bug.cgi?id=472904
>
> Hope things are more clear now.
>
> cheers,
> Raffaele
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Graphing widgets for GTK+
On 6/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On 6/29/07, Kieran Clancy <[EMAIL PROTECTED]> wrote: > I'll have a look at the gtkplot API, it may give a good structure for > starting this. This project will probably use cairo directly instead > of using a canvas widget. Your call, of course, but I would consider using a canvas widget. If you make a canvas object for a data series (ie. the single object would draw all 1000 points in a series) you can avoid having to build huge canvas object sets. Right, but it would be great if the base canvas and this multi-point canvas item used the same optimized drawing routines, which would handle stuff like avoiding redundant drawing and handling interaction with individual points. This would require abstraction of those algorithms from the canvas itself. Plus using the canvas framework will make interactivity easy (or easier), since it already has a nice framework for handling selections, dragging, optimising updates, and so on. Finally your users will thank you for not reinventing a lot of the canvas API and forcing them to learn it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Graphing widgets for GTK+
On 6/29/07, Kieran Clancy <[EMAIL PROTECTED]> wrote: Hi, (I hope this is the right place to post this.) I am in my uni break for the next 3 weeks and am interested in doing some big development on GTK. One thing I thought seemed lacking in GTK is a set of widgets for easily producing simple graphs. I've written up a rationale and a fairly exhaustive list of _possible_ features here: http://live.gnome.org/KieranClancy/GtkGraphing I am looking for comments regarding the best way to arrange the infrastructure for this (name spaces, gobject stuff), from the perspective of the developers of GTK, with a view that it might one day be included in GTK. That way it can be used by applications in the Gnome desktop (instead of having many separate graphing implementations). Any comments would be very appreciated. That's a very nice outline. One comment I have is that scientific applications often need to plot large amounts of data and require substantial interactivity. Traditional canvas designs are probably not efficient for this purpose (ie drawing hundreds of thousands of points and updating immediately in response to user interaction). I don't know if you want to consider this application in your design, but I thought I would mention it. For an example of this based on GTK+, see GGobi (http://www.ggobi.org), which provides interactive graphics for multivariate data analysis. We are currently refactoring the display framework of GGobi for improved clarity, flexibility and performance, so your ideas are interesting to us. We would love to be able to borrow functionality provided by GTK+ or some related library. Michael Many thanks, Kieran. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkActionEntry doesn't allow closures?
On 5/26/07, Jason Hickey <[EMAIL PROTECTED]> wrote:
I am developing a GTK+ binding for OMake (http://omake.metaprl.org).
OMake has a functional language, so it has closures, etc.
Pardon me if I am daft, but,
- One cannot simply pass a GClosure where a GCallback is expected
(!?).
GTK+ is usually nice--each signal can be paired with data, making it
easy to form closures.
Am I missing something, or is it not possible to deal with closures
in GtkActionEntry?
struct _GtkActionEntry
{
const gchar *name;
const gchar *stock_id;
const gchar *label;
const gchar *accelerator;
const gchar *tooltip;
GCallback callback;/* Ummm, what about closures? */
};
I believe this post belongs on gtk-list, but one possible solution to your
problem is to have your wrapper pass a custom C callback and to replace the
user-data with your closure. Then your callback can just invoke that
closure.
I looked at the GTK+ binding I wrote for R and found that I just
reimplemented the convenience functions that take a GtkActionEntry as a
parameter. I am not sure why I did that, but that's another alternative.
That way your code handles connecting the callback to a signal, so you can
use a closure.
Michael
BTW, thank you for GTK+, "thou art god" as Heinlein might say.
Jason
--
Jason Hickey http://www.cs.caltech.edu/~jyh
Caltech Computer Science Tel: 626-395-6568 FAX: 626-792-4257
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/2/07, Rob Taylor <[EMAIL PROTECTED]> wrote: Michael Lawrence wrote: > On 5/2/07, Rob Taylor <[EMAIL PROTECTED]> wrote: >> >> Damon Chaplin wrote: >> > On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: >> >> Michael Lawrence wrote: >> > >> >>> I made some suggestions along those lines a while ago on the >> GtkDocFuture >> >>> page: http://live.gnome.org/DocumentationProject/GtkDocFuture. >> It's at >> the >> >>> bottom of the page. >> > >> > I'm not sure I like the idea of the gtk-doc comments containing extra >> > tags for return values and arguments. It could get pretty messy. >> >> Agreed. >> >> > >> >> Yeah, hmm, my take is that the introspection data should live in the >> >> code, and gtk-doc should pick these up for the docs (just like signals >> >> and object hierarchy). > > > Well, I think we both agree that there needs to be an API somewhere for > storing the metadata in memory. I'm looking forward to your prototype. It > would be great if the API were integrated with GClosure; that way language > bindings could leverage existing marshaling code to support invoking > methods > introduced by the language. I was planning on using ffi, so we can lose all the marshalling code. How does that sound to you? I guess using libffi closures would work, but GClosure is definitely better documented. Would libffi be bundled with GLib given that there's no current release? Relatedly, I'd like to see pygobject's g_cclosure_marshal_generic_ffi in glib proper. > I'll be able to tell more after hashing out my >> >> prototype. One point I'm interested in from that POV: are there any >> >> plans for gtk-doc to document signals/properties on interfaces? (e.g . >> by >> >> instantiating objects pretending to implement them?) >> > >> > gtk-doc documents signals/properties on interfaces already. >> > >> >> Ah good! I had the impression it didn't ATM :) >> >> Thanks, >> Rob Taylor >> > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/2/07, Rob Taylor <[EMAIL PROTECTED]> wrote: Damon Chaplin wrote: > On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote: >> Michael Lawrence wrote: > >>> I made some suggestions along those lines a while ago on the GtkDocFuture >>> page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the >>> bottom of the page. > > I'm not sure I like the idea of the gtk-doc comments containing extra > tags for return values and arguments. It could get pretty messy. Agreed. > >> Yeah, hmm, my take is that the introspection data should live in the >> code, and gtk-doc should pick these up for the docs (just like signals >> and object hierarchy). Well, I think we both agree that there needs to be an API somewhere for storing the metadata in memory. I'm looking forward to your prototype. It would be great if the API were integrated with GClosure; that way language bindings could leverage existing marshaling code to support invoking methods introduced by the language. I'll be able to tell more after hashing out my >> prototype. One point I'm interested in from that POV: are there any >> plans for gtk-doc to document signals/properties on interfaces? (e.g. by >> instantiating objects pretending to implement them?) > > gtk-doc documents signals/properties on interfaces already. > Ah good! I had the impression it didn't ATM :) Thanks, Rob Taylor ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/1/07, Rob Taylor <[EMAIL PROTECTED]> wrote: Michael Lawrence wrote: > On 5/1/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> Michael Lawrence wrote: >> > I am wondering what is happening with GObject introspection. It seems >> > that it has been in the works for some time now but that development >> has >> > stalled. >> >> Rob Taylor started working on it again, see >> http://bugzilla.gnome.org/show_bug.cgi?id=363228 > > > Ok thanks for pointing that out. > The original bug is here: > http://bugzilla.gnome.org/show_bug.cgi?id=139486 Hmm, I'll try and link all these together in some sensible dependancy. >> 1) What are the overall goals of the project? From what I gather the >> > goals are twofold: >> > a) To define a common representation (GIDL) for GObject-based API's. >> > Binding generators can then be ported to use a standard format rather >> > than the current assortment of defs files, GAPI, etc. >> > b) To support run-time introspection by accessing a binary blob of >> > metadata. >> >> Combining a) and b) I would say part of the goal is run-time binding >> generation, i.e. right now most of the bindings involve a couple megs of >> static function stubs, ideally this could be replaced with perhaps a >> couple hundred K of generic code that built binding objects on demand >> (much as e.g. dbus-python works) > > > My thoughts as well. Ditto :) >> 2) How is the GIDL/metadata generated? The Vala project has some scripts >> > that generate GIDL from header files. This is obviously a difficult >> > task, because things like memory management, in/out parameters, etc >> > cannot be automatically derived from header files. Thus, human >> > annotation is necessary. >> >> My preference is this pipeline: >> - Scan headers (or code in other language) and generate a base IDL >> file (or in-memory parse tree) >> - Allow "magic comments" in the headers to modify the IDL that would >> otherwise have been created. Similar to gtk-doc comments. > > > I made some suggestions along those lines a while ago on the GtkDocFuture > page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the > bottom of the page. Yeah, hmm, my take is that the introspection data should live in the code, and gtk-doc should pick these up for the docs (just like signals and object hierarchy). I'll be able to tell more after hashing out my prototype. I'm thinking that gtk-doc-like markup may be a more convenient way to express some of the metadata. There is already too much code required to create a GObject class. Then again, meta-languages like Vala would take care of this stuff behind the scenes anyway. I'll wait to see your prototype. One point I'm interested in from that POV: are there any plans for gtk-doc to document signals/properties on interfaces? (e.g. by instantiating objects pretending to implement them?) > Michael > > - Allow a "merge file," a lookaside IDL file that overrides or adds to >> the scanned IDL - similar to magic comments but not in the C code >> itself >> - Output (or keep in-memory parse tree, as appropriate) the resulting >> IDL >> - Output a binary type lib containing the same information >> >> A pipeline should also be possible where you write the IDL file first >> and then a C header is generated. This is useful when the IDL file is >> part of a spec or shared between multiple apps. >> I really don't want force people not coding dbus applications down this path of IDL-driven development. Some sort of interface description is required for language bindings as well, which means this applies to pretty much every GObject-based library. I'm aiming to get introspection such that, if need be, you could code it by hand but have some useful tools and macros to help make life easier. The current plan for dbus-glib is to have a tool that generates introspectable GInterfaces from annotated xml (or dbus-doc xml and a separate glib type annotation). The provider object would implement the Ginterface, the remote end could then be a factory-produced object implementing the GInterfaces corresponding to the dbus interfaces on the object. Again, we seem to be discussing dbus-glib issues in the wrong forum, so I've cc'd in the dbus mailing list. Thanks, Rob Taylor ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject introspection
On 5/1/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: Hi, Michael Lawrence wrote: > I am wondering what is happening with GObject introspection. It seems > that it has been in the works for some time now but that development has > stalled. Rob Taylor started working on it again, see http://bugzilla.gnome.org/show_bug.cgi?id=363228 Ok thanks for pointing that out. The original bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=139486 1) What are the overall goals of the project? From what I gather the > goals are twofold: > a) To define a common representation (GIDL) for GObject-based API's. > Binding generators can then be ported to use a standard format rather > than the current assortment of defs files, GAPI, etc. > b) To support run-time introspection by accessing a binary blob of > metadata. Combining a) and b) I would say part of the goal is run-time binding generation, i.e. right now most of the bindings involve a couple megs of static function stubs, ideally this could be replaced with perhaps a couple hundred K of generic code that built binding objects on demand (much as e.g. dbus-python works) My thoughts as well. 2) How is the GIDL/metadata generated? The Vala project has some scripts > that generate GIDL from header files. This is obviously a difficult > task, because things like memory management, in/out parameters, etc > cannot be automatically derived from header files. Thus, human > annotation is necessary. My preference is this pipeline: - Scan headers (or code in other language) and generate a base IDL file (or in-memory parse tree) - Allow "magic comments" in the headers to modify the IDL that would otherwise have been created. Similar to gtk-doc comments. I made some suggestions along those lines a while ago on the GtkDocFuture page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the bottom of the page. Michael - Allow a "merge file," a lookaside IDL file that overrides or adds to the scanned IDL - similar to magic comments but not in the C code itself - Output (or keep in-memory parse tree, as appropriate) the resulting IDL - Output a binary type lib containing the same information A pipeline should also be possible where you write the IDL file first and then a C header is generated. This is useful when the IDL file is part of a spec or shared between multiple apps. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gobject introspection
Hi, I am wondering what is happening with GObject introspection. It seems that it has been in the works for some time now but that development has stalled. Here are somethings IMHO need to be considered before introspection is ready for prime-time: 1) What are the overall goals of the project? From what I gather the goals are twofold: a) To define a common representation (GIDL) for GObject-based API's. Binding generators can then be ported to use a standard format rather than the current assortment of defs files, GAPI, etc. b) To support run-time introspection by accessing a binary blob of metadata. 2) How is the GIDL/metadata generated? The Vala project has some scripts that generate GIDL from header files. This is obviously a difficult task, because things like memory management, in/out parameters, etc cannot be automatically derived from header files. Thus, human annotation is necessary. In some langauges, eg Vala, we can derive everything from the language itself. That solves a lot of headaches. 3) There needs to be a clean way of combining the descriptions extracted from the headers with the annotations, like the "metadata" mechanism in GAPI. 4) How does the GIDL coexist with existing runtime metadata like GEnum and GType? 5) Runtime introspection seems to come pretty close to defining a common runtime between languages. Currently, gobject-introspection seems to be designed only for invoking C functions (using libffi). Maybe that could be abstracted so that each language that provides GTypes could have its own marshaling implementation. Parameters would just be sent as GValues. For invoking methods defined in a dynamically-typed language, type checking would be disabled. 6) Is libffi even necessary? Given that the blob of metadata needs to be generated beforehand, why not also generate a hash table of wrappers that marshal C functions? 7) Would gobject-introspection remain a separate library or be merged into GObject? That's all the main ones for now. I hope this generates some discussion, because I'd love to see gobject-introspection reach fruition. Thanks, Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: directx gdk backend?
On 2/10/07, Tor Lillqvist <[EMAIL PROTECTED]> wrote: Michael Lawrence writes: > From what I have read, it sounds like Windows Vista has regressed from XP in > that it no longer offers any hardware acceleration for GDI. Don't believe all you read. Not long ago, somebody claimed on gtk-list that Vista wouldn't support the traditional Win32 API at all. Of course, that was very far from the truth. > Does this mean that GDK will perform more slowly on Vista compared > to XP? No idea. If you are concerned, do some measurements. > The performance of GDK is already slow when drawing lots of > graphics, mostly due to this bug: > http://bugzilla.gnome.org/show_bug.cgi?id=51828, Do you have any measurements to back up this claim, that drawing multiple rectangles after eachother (which is what the bug seems to be about) is something that would be happening a lot? It may not happen in most use cases, but it happens often in a statistical graphics app I am developing. win32 is significantly slower than X11 when drawing many points. When drawing plots with say 25000 circles, Windows is at least 5x slower. Unfortunately, Windows is by far the most common platform for our user base. I realize that this is not a common use case, so I would be willing to invest some of my own time to fix this, if it's at all feasible to bring Windows even to X11. Would DirectX be the best way to go or are there other possible optimizations? Thanks, Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
directx gdk backend?
Hi, From what I have read, it sounds like Windows Vista has regressed from XP in that it no longer offers any hardware acceleration for GDI. Does this mean that GDK will perform more slowly on Vista compared to XP? The performance of GDK is already slow when drawing lots of graphics, mostly due to this bug: http://bugzilla.gnome.org/show_bug.cgi?id=51828, which apparently will never be fixed. Is there a reason why that won't be fixed? Is it a lot of work? Since MS is putting all of its efforts into DirectX now, would it make sense to move to that for drawing? Thanks, Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
c/invoke for gobject-introspection?
Hi, I understand that one of the hurdles for gobject-introspection is the fact that its dependency libffi is not actively maintained. Has anyone considered c/invoke? http://www.nongnu.org/cinvoke/ Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What about official GTK+ installer for win32?
On 10/26/06, Jernej Simon+AQ0-i+AQ0- <[EMAIL PROTECTED]> wrote: On Thu, 26 Oct 2006 13:40:48 -0400, Dominic Lachowicz wrote:> My experience leads me to believe that we'd benefit from an official> installer that didn't dump crap into System32 and for maintainers not > to include GTK+- in their installers. At that point, I don't look any> different than a typical end-user.It's not that any official GTK+--related installers put stuff in System32,it's other programs that do this. And Windows always searches System32 before PATH, which causes problems when somebody put an old (or broken)version of a DLL that's included in the GTK+- runtime installer there.This is one advantage of bundling GTK+ with packages. The package installers can place the dlls in the same directory as the executable, which I think trumps system32. Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What about official GTK+ installer for win32?
On 10/25/06, Urs Stotz <[EMAIL PROTECTED]> wrote: On Tue, Oct 24, 2006 at 10:41:09PM +0200, Tomasz Jankowski wrote:>> [...] To maintain such a project it need automated builds and testing.Tor Lillqvist has written about the problems with differend version ofGTK+ on Win32. Could be the installation to differend directories anda program loader a solution? The program loader set the enviroment for the GTK+ program an start it.Given the current prevalence of GTK-based apps on Windows, it seems reasonable to just bundle the binaries with the application. However, as the number of GTK-based packages grows, the inherent inefficiency of monolithic installations will take its toll. Modular systems are simply easier to maintain. I don't want to have to release a new installer every time a bug-fix release of some dependency is released. The user should have the freedom to easily update everything at will. I have trouble accepting the argument that stuff on Windows changes too fast for apps to adapt. It's true that software originally developed for unix-like systems will have some growing pains when moving to Windows, but these should fade with time. Also, with modern package management systems on Linux, I rarely feel constrained to depend on a earlier version of a package. The dependency system will handle it for me. I feel that a sophisticated package management system for Windows is a must for open-source to become mainstream on Windows. Of course, the construction and maintenance of such a system would be a monumental task and far beyond the scope of GTK+. Michael ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gobject introspection and gtk-doc
Hi, There's been a lot of discussion about GtkCanvas, but I've heard little about another planned feature for GTK+: introspection. I think that gobject introspection would greatly facilitate the language independence of GTK+ and gnome. I believe there are plans for scraping the introspection metadata out of the header files, like pygtk does for its defs files. Obviously, the header files do not contain all of the necessary information, like in-out parameters, memory ownership, etc. These require manual human annotation of the metadata. My idea is, why not annotate the header files (or C) files themselves with this information? It could be integrated with gtk-doc, so that the information could be presented in a standard way in the documentation. For example, there is no standard, fixed way of saying that a parameter is meant as an "out" parameter in the docs. Another example would be whether a return value is owned by the caller. If this stuff was added to the gtk-doc annotations it could be used both for generating metadata blobs as well as the documentation. The metadata would require much less human maintenance (perhaps none) and the documentation would be easier to understand by both human and machine. Machine understanding is important when transforming the GTK+ docs while trying to manipulate or filter out information like in/out parameters and memory ownership. For example, for my language binding RGtk2, I produced R documentation from the GTK+ docs. RGtk2 hides memory management from the user and stuff like "out" parameters are handled very differently in R than in C. It would be nice if this information was included in a machine-readable way in the docs. Thanks, Michael Lawrence ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ canvas?
Gustavo J. A. M. Carneiro wrote: However, I would argue that to display a very large document in a canvas creating a canvas item for each document item is not the best solution; I'd rather have a pool, or cache, of visible canvas items, and just reconfigure them on the fly to show the portion of the document currently visible. I definitely agree that a model based on per-item objects is inefficient when dealing with a large number of items. In this case, one is usually employing the canvas from a data-oriented perspective rather than one that is serving in a GUI role. Approaching the problem of a canvas from a data-oriented perspective suggests that a different type of model is required. One example would be a tabular model, like GtkTreeModel. In this case the rows would be the items and each column would contain variables describing the items. These items would then be mapped to their appearance using something analogous to the GtkCellRenderer. There would be one or more renderers per column that would serve to take the values for each row (item) and use them to decorate the item view. The renderers could also map user interaction with a item view back to the row in the table. Given that GTK+ is centered around the GUI, the goocanvas model makes sense to me. Granted, it would be much more useful if the canvas model could be mapped to other view types. For example, the GtkTreeView could show the hierarchy of items. , so having a markup language as an integral part of a canvas design is of interest. Markup in the text item sounds fine. Anything else sounds like reinventing HTML. I think Havoc's idea of integrating HTML and the canvas is very interesting. HTML would serve nicely for serialization of the canvas and the canvas would provide a interface for integrating widgets within an HTML document. They (HTML rendering and a canvas) are also two things that GTK+ sorely needs, in my opinion. Michael Lawrence ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
