Meeting on irc.gnome.org:#gtk-devel Meeting started November 1 2004 17:03 EST (21:03 UTC) In attendence: Anders Carlsson (andersca), Owen Taylor (owen), Jonathan Blandford (jrb), Manish Singh (yosh), Matthias Clasen (matthias), John Ehresman (jpe), Ray Strode (halfline), Robert Ögren (roboros), Maciej Katafiasz (mathrick), Carlos Garnacho Parro (garnacho), Tim Janik (rambokid), Tor Lillqvist (tml), Jody Goldberg (jody) looks like we're reasonably complete... so, what do we have to discuss today ? matthias: I had a date w/ vektor to discuss colors. But I think we both forgot jrb: maybe we can discuss the results next week... jrb: ...or do you mean the meeting took place but both of you forgot the results ? matthias: the meeting didn't take place. I was more mentioning it in case others had interest in the topic jrb: I would certainly be interested (we discussed it a bit already...) owen: one thing I wondered about on the way home is the current status of Pango, and what your plans are for 1.8 owen: will 1.8 go out together with GTK+-2.6, and will it have the renderer changes necessary to support rotation ? matthias: Hmm, without GTK+ additions, the 1.6 => 1.8 changes don't really have a lot of point. 1.8 does add PangoRenderer, but I haven't done the work to support that in GTK+, which is fairly extensive and might conceivably require some PangoRenderer changes. matthias: So, there is some argument for backing that out and just do the planned script additions (tibetan, syriac, sinhala) for 1.8. matthias: I do want to do a 1.8 of some sort to go along with GTK+-2.6. Or I could stripstream the script additions into a 1.6.x dot release, but that's a little questionable. owen: so no rotation in GTK+ 2.6 ? what GTK+ changes are necessary to support it ? matthias: If I don't have a new draft of the GTK+ changes for PangoRenderer by the meeting next week, I'd say it's no go for 2.6. matthias: Well, the API is tiny ... just gtk_label_set_angle() or something like that. But to maek that works requires porting GDK to PangoRenderer. There's a draft of that patch, but it isn't quite finished, and doesn't address GtkTextView. owen: ok. <=> GtkTextView interface with derivation is something that is hard to predict without doign the GtkTextView work. matthias: I'll see if I can find some time in the next week to take another look and see how far away that is from being finished. owen: probably not a good idea to do the pangorenderer changes if the higher layers are not done, and are likely to add new requirements... matthias: You mean to Pango? Yeah. That's why I'm thinking of backing it out of Pango if I don't get the GTK+ changes in for GTK+-2.6. owen: although I think many people expect rotated labels in 2.6... matthias: Sigh, yes. owen: maybe not rainbowcolored text set in spirals in a textview though... matthias: jody is... I'll see what I can do. Have to tear myself away from luminocity and dri driver fixing. Nov 01 17:16:28 * matthias wouldn´t have problems to tear himself from the dri driver... I have spent the last few days concentrating on docs, trying to get the 2.6 additions reasonably documented anything else on agenda? if not, I'd like to discuss http://lists.gnome.org/archives/gtk-devel-list/2004-October/msg00123.html a bit author couldn't make it here, as he's in GMT+5, but I was asked to proxy for him :) mathrick: How different is that from the gobject-branch of libglade ? matthias: hmm, good question, didn't check that matthias: any informative url handy? mathick: Two comments a) Really should make sure we have rambokid before going into extensive discussion of gobject serialization b) I tend to suspect this is something best developed for a whiel as an independent library owen: 1) yes, definitely, and jody too 2) quite reasonable owen: I'd add 3) to that, finish introspection first, at least do so before letting that in mainstream gobject mathrick: Oh, a third: c) Personally, I think widget state serialization (saving paned positions, treeview expansion, window sizes, etc.) would be a much more immediately useful activity. I don't think it's the same thing, though. owen: no, he was doing that for entirely non-widgetish gobjects AFAIK owen: I think the two (object serialization vs state saving) are almost separate use cases mathrick: I agree with your 3) to some extent, I think it's first on the queue of major gobject additions. though probably doesn't h ave a lot of direct interference with this one way or the other owen: I want introspection stuff to have kind on .net-ish attributes support, that should influence any API heavily owen: realistically, major gobject additions will be going nowhere if we rely on rambokid to review them - it takes anywhere between months and years to get him to review (relativly simple) bug fixes/optimizations... matthias: Well, he *claimed* to be going to have more time to work on GTK+. But yeah, he's pretty absent. But serialization is something he did a lot of work on in particular. mathias: For introspection, I think we should work on getting something we are happy with, then put the screws (;-) on rambokid to get it in. Or, if we are lucky, he'll have time to participate from the beginning. owen: mitch was half-planning to drive to Hamburg with a box of beer to foster patch review... hi jody good evening folks hey jody jody: what would you expect from serialisation infrastructure supposed make you happy? matthias: I can't find anything meaningful on glade-gobject, that makes it rather hard to compare these two mathrick: libglade has a cvs branch which supports non-widget objects mathrick: http://cvs.gnome.org/viewcvs/libglade/?only_with_tag=libglade-gobject-support-branch matthias: do you know how complete was it meant to be? Are the GObjects targetted totally arbitrary, or need to be somehow special-cased for that? mathrick: jrb would know more about it... jrb: ? ...since he wants to use it for tree model stuff. mathrick: it was meant to be used just like the Widget stuff jrb: ie, you need to inform glade of any gobject you plan to use beforehand? mathrick: that is, GObjects were supposed to be first class objects that you could get, but you still need the register the type mathrick: yes, of course. there's really no other way unless you randomly look for _get_type symbols and hope that they work jrb: well, with full introspection, yes there is mathrick: to/from string operations for all of the common data types but for today, I guess there isn't and some of the utility functions in libglade jody: are multiple types needed / useful? or just bytestream is everything you want? I definitely need multiple types k mathrick: There should also be hooks to help versioning and hooks to handle renaming/retyping jody: yeah, I want versioning in together with introspection :) jody: retyping? retyping what? mathrick: schema evolution in DB parlance...change the types of member between versions... ah so versioning with sugar on top, basically? hmm, can't remember if that was discussed, I think not... but how much of changes to how GTK+ is written for example would be acceptable to bring in introspection? mathrick: you want to be able to deserialize from an older version into a newer one, and be able to influence how that is done... would IDL be acceptable solution? mathrick: retying == changing the type of an attribute eg you start with a 'line_width' as an int then make it a float a few versions later jody: yeah, I can see that now gah, it sucks that rambokid isn't here mathrick: I can't see us rewriting gtk+ in IDL. It should be possible to add extra information necessary for introspection without rewriting all existing gobject based code... mathrick: a generic "here's a i/o context serialize all flagged properties" seems possible matthias: yeah, but what I'd like it to become is "typelib is authoritative", not headers mathrick: Lets 's try to think of this as incremental matthias: so probably something like .h -> IDL -> typelib mathrick: I don't see why we can't keep .h authoritative for C based objects. mathrick: headers already say nothing about signals and properties... the class_init() registrations are authoritative for them.... owen: because I want bindings to be first class citizens mathrick: if we have other objects that want to use other ways of maintaining their typelib, so they can do that mathrick: So? headers basically define the C binding... matthias: yes, that's why I want to generate IDL from code once, and then work on IDL from there on matthias; i would say rather, that headers are the definition of objects implemented in C. well, that doesn't necessarily mean IDL but amount of thing you need to stuff into C that aren't C anymore increases s/aren't/isn't/ owen: with IPN, the headers increasingly loose that role as well... I kinda dislike rpm headers cruft err, s/IPN/IPD (Sidenote. I realized that I'm really not happy with how object properties are bound in C. I'm not sure if it's worth providing an alternate method) matthias: IPD == ? mathrick: instance private data = private structs mathrick: I'm not saying that headers are *all* that is used to implement the object. ah mathrick: idl ? That seems like overkill owen: we want and really need to have .h 100% reconstructible from IDL mathrick: I don't see why owen: what are you envisioning ? something more based on conventions, like java beans ? mathrick: I'd prefer to see a thin wrapper to get/set property matthias: No, setter/getter functions rather than the big switch. mathrick: good lord why ? owen: because I want to be able to define object in Py, and then inherit from it in C, call it, with no custom glue needed hmm s/IDL/typelib/ in the above IDL would be implementation detail of C code mathrick: Inherting C from Python is *hard*. I spent a day discussing that with hp once. I'm not sure it's worth trying to do. typelib should be the source of any type info owen: inheriting maybe not, but calling definitely owen: stick the setter/getter in the paramspec ? matthias: I don't think that quite works because of, e.g., interfaces owen: it's saddening that we spend whole days discussing what languages are acceptable for libs and writing bindings from m-to-n languages owen: win32 has COM, they have no notion of bindings. COM is gross, but works But g_object_class_install_property(), g_object_class_override_property() could have variants that took a setter/getter as arguments so reference implementation of jabber was written in Delphi and noone had any problems with it mathrick: GObject is much less gross than COM from C. It's even less gross than COM from C++ owen: I don't deny that :) mathrick: I don't think our goal should be be to reinvent the COM wheel... MS has largely moved on from that, after all. owen: also, in my Python code I can't really define full-fledged new types. To implement new TreeModel Py needs to have special hand-crafted GenericTreeModel to support that owen: COM is only one implementation what I want is real language transparency mathrick: Rather, our goal should be to solve the language binding problem ... to allow implementing an object in any language and binding it any interpreted language without compiled glue code. owen: exactly owen: that's my primary goal mathrick: Well, that's because PyGObject doesn't try to generically handle interfaces owen: because it can't, really owen: you cannot reliably override vmethods from Py owen: Py is still the best one when it comes to overriding C stuff mathrick: You coudl, with introspection information and something like libffi owen: that's what I want to do, yes mathrick, given enough info, you could do interfaces in pygtk owen: but introspection needs info ie, typelib and *really* supporting bindings needs shifting responsibilities here it seems to me that some sort of libffi is needed jpe: yes mathrick: Sure. But the typelib can still be a generated artifact from header files and classic gobject properties owen: no mathrick: Why not? owen: you need to be generating .h from typelib The typelib, *for objects implemted in C* Why? owen: since if I implmement some PyFooObject, I add that to typelib Nov 01 18:01:42 * owen goes into 3-year-old mode :-) and then we can determine what info the ffi needs and what is the best way to supply it mathrick: It doesn't have to work the same for obejcts implemented in C and objects in python to access from C, you need to generate headers *from* typelib owen: it should mathrick: typelibs for python objects would obviously not be derived from headers... mathrick: Why should it? owen: I don't want to differentiate between C and anything else it's artificial mathrick: I do. Because C doesn't look much like python. mathrick: well, the languages are different owen: but we can support both I think C objects should define their interface in C source files mathrick: In python, I have all these wonderful introspection, dynamic object creation, etc, facilities. That I can use to easily bind to something defined with a typelib owen: I want to do my best to make Python exactly as good citizen as C owen: yup owen: and I want to use that from C just as if it were written in C mathrick: if you force everybody to use idl, there is no c anymore... at least from a C programmers perspective... mathrick: That doesn't mean making the C object definition process worse or more complicated. Or even different - a danger since we huge piles of GObjects already around owen: that should really go into `pkg-config --cflags gobject foopylib` matthias: now we also have IDL of a kind, just less convenient mathrick: Using python objects from C would be a cool goal, and maybe we can enable it, but it shouldn't be the primary goal of the introspection work or drive the overalll outline matthias: and IDL is only detail I don't think idl files or xml files need to be or should be required matthias: what really matters here is that typelib rules, no headers jpe: how do you envision filling in the typelib information, then ? owen: uh, not having that now sucks enough. I want next iteration to have all the cool features possible right from beginning mathrick, I think for C objects you go from .h files to the typelib jpe: yes jpe: but arbitrary is still typelib mathrick: You stiill haven't explained why having idl be canonical for python objects and having header files be canonical for C objects doesn't work fine for Python files you go from .py to the typelib idl isn't needed for python either owen: because that wouldn't work for python owen: python is too dynamic owen: so it all should happen as I type, really jpe: (There is some argument for making IDL files canoncial for python ... python isn't strongly typed, it doesn't have interfaces, etc) the typelib is just an implementation detail that provides the info needed for libffi owen: if I open up interactive python session, I have no IDL at the beginning. If I define some gobject in the meantime, it should show up in typelib right away mathrick: I'm sorry, why doesn't it work for python? How does python care if someone typed in a IDL file or typed in a header file for the C object owen, I agree you want to better define the interfaces in python, but I'd suggest doing it in python mathrick: Umm, there is no global type library for the system that is dynamically updated. Interfaces repositories in my experience are a horrible idea. owen: uhh, slower, I can't type fast enough ;) I agree, the idea shouldn't be to export python's full dynamism into C mathrick: But if you want to enable using python objects for C, you have to accept the fact that python objects can't be changing their methods on the fly. owen: yes, I can see that most Python objects don't change their methods mathrick: Because the C objects (to preserve any sort of C interface that isn't the worlds most horrible interpreted language) need to be compiled against a header file generated based on a fixed typelib. owen: but that shouldn't matter for how Py programmer *writes* his code, just how that code works owen: and Py program starts with no custom classes, all the types are defined at runtime. There's no reason not to generate that info at runtime for GObject too mathrick, the C programmer will probably generate a proxy lib from info in the typelib and then compile it mathrick: I haven't looked at PyORBit a lot, but if it's like CORBA::ORBit it may be a good model for implementing defined interfaces from an interpreted language. owen: Py runtime can take care of doing all that owen: yes, I had a talk with michael and jamesh, and more will follow jpe: yes, that's the plan mathrick: If you dont' care about export to compiled languages, sure. But if you do care about export to compiled lanugages, then you need a *fixed* typelib, not a runtime-generated typelib. only what is defined when the proxy lib is generated will be available owen: these two don't conflict :) owen: if python can work out all the types at runtime, that means it's enough info to work. Why should that be harder than typelib.save() to fixate that? jpe: You can actually get away without a proxy lib with some magic. #define gtk_widget_show(w) (void (*) (GtkWidget *))((GenericObject *)w->vtable[53])(w) mathrick: Basically, because I believe it makes for bad python development workflow. owen: the system should probably have multiple typelibs chunks, merged into one global typelib by kind of linker most likely what will happen is that there will be well defined interfaces that both .py and .c code will know about mathrick CORBA::ORBit is almost "import foo.idl" owen: uhh, that *is* python workflow mathrick: I don't see any reason to have a global typelib. owen: global for given process not any registry or anything mathrick: Python isn't smalltalk. Most people continually start their apps from scratch. mathrick: Ther eisn't some sort of workspace concept where you rejoin a workspace, modify the code. (That was a common paradigm in time sharing days. APL worked like that. Smalltalk I think mostly works like that) owen: uh-oh, you lost me now owen: I don't see what is your objection here mathrick: I'm saying, to make changes to my python code, I edit the code, restart the program owen: yes owen, you're right about Python v Smalltalk owen: yes, smalltalk works like that mathrick: So I could edit the IDL file and restart the program too, if I wanted to change the definition of an interface mathrick: Having to run my program in some special 'dump the typelib' mode seems backwards to me. owen: umm, a bit of apples and oranges here :) owen: lemme explain owen: I mean, Python starts app with clean slate -- it knows of no types besides builtins owen, I think the more useful python example is defining an object that supports an interface that is already well known owen: so almost everything you defing means kind of patching Py's typelib at runtime, right? s/defing/defining/ owen: now, in fact GObject also works that way in binary on disk, it knows no types all happens at runtime owen, you could bring in the .idl file or you could just use the typelib's api directly mathrick: I think the word "typelib" is being used a little confusingly here. But yes, the registry of types is built up at runtime mathrick, pygtk doesn't quite do everything at runtime owen: so, what really is different between GObject-from-C and GObject-from-Py is that C demands to know definitions beforehand, which you need to supply mathrick: The point I'd make though is that in order to use a python object from a compiled language, we need an on disk representation of the type of that object. An in memory representation isn't enough sorry guys, I have to leave this very entertaining discussion now...see you later cya matthias matthias: later owen: yes, but that's technical detail for now, we can safely leave that alone for a minute mathrick: I think it's a very important technical "detail" that implies a lot about how things should work from python owen: yes, I'll get back to it in a minute owen: now, Py is dynamic, so it has no problem with supplying GObject at runtime with type info it learns as it goes owen: so, there is no reason for both Py and GObject themselves to insist on having any sort of fixed representation -- so far no C exists yet mathrick: Sure. Though providing GObject with data requires providing it a lot more than python normally has. (Which I'll get back to in a moment) owen: suppose there is piece of C code that manipulates some GFooInterface owen: now, I can implement that iface in Py, pass the implementor to C, have it do its job, with no fixed representation in the process so IDL here would be superficial there is one special case mathrick: Sure, *if the iface* is originally defined in C with a header file. where we need to use info from dynamic language in a static language owen: but still, the typelib here is who knows everything about types, IDL is still not necessary to generate headers for C IDL is only textual representation of info typelib stores owen: so, we don't really need IDL, as long as we provide some way to dump typelib into persistent form mathrick: Sure. it's really a workflow issue. There's no reason it couldn't be done with a PyObject.writetypeLib() owen: it may turn out that IDL is really the most convenient, but that we will see mathrick: But in order to have an object interface usable from multiple languages, we need to have a good concept of stability. Of an idea that it *is* an interface. owen: yes owen: but that comes only from different conventions used in languages, not from the fact that C is better than Python. I want situation where there is exactly no difference between the two, as far as GObject is concerned Doing that with PyObject.writeTypeLib() just seems pretty inconvenient to me as opposed to an IDL, because Python code isn't really structured around interfacse owen: so everything that remains is different workflow If there were python header files, that might be a quite different thing owen: I think we could even do that using the type info itself owen: just as there could be Serializable attribute there could be FixatedType attribute you could supply mathrick: But in order to use the 'type info' to generate a type lib, I have to have some way of getting my program to run in a special mode where it registers all its types and dumps them to a file. Ugh. so Python would see that and automatically dump info owen, it might be possible to come up with a reasonable interface to do it all in python owen: that's no different from running "generat-py mylib.tlb" :) owen: my point is, it is possible to do somehow, we will see what is the most practical way jpe: Sure, there could be conventions, etc. But considering that defining strongly typed interfacse in Python is horrid (look at how GObject signals work). I tend to think a typelib would be nicer mathrick: Oh, I'm not suggesting generate-py mylib.tlb That's dreadful. I'm suggesting 'import mylib.tlb' yay, rambokid hey a lot of modules only define classes and functions, so running a utility to import the module and inspect it might be reasonable mathrick: Anyways, where we *started* here wasn't arguing for IDL files for Python. But against IDL files for C. rambokid: just when we have most typing intensive stuff already discussed :> rambokid: I hate you :P mathrick: thank you ;) owen: yes mathrick: We should start of f from whatever is most convenient for a particular language, and generate a typelib file (ELF chunk, etc) from that. mathrick: hush, i told him the meeting and plans involved beer owen: IDL would be pure tradeoff for C carol: hehe owen, I use a metaclass to make defining signals easier and while it is clunky, it beats having a separate IDL file owen: yeah owen: question here is -- do we want to embed all the stuff in .h and .c, or do we decide it's too kludgy and move to IDL? owen, and python will grow type annotations over time mathrick: We can easily have a system where we have 'IDL => typelib' 'typelib => IDL' 'header => typelib' and use header files as the authorative source for gobject implemented objects. owen: IDL would be question of convenience here mathrick: Someone is free to have gob3/gmoc. But I'm pretty positive we won't wnat to go that route for GTK+ mathrick, as someone who used .idl files with a CORBA orb, do everything in .c & .h owen: well, I want to get it to the state where .h files can be 100% accurately regenerated from typelib jpe: Hmm, from what I've seen, attempts to introduce tpye annotations into python have been pretty uniformtly shot down owen: since, regardless of what is generated from what, typelib should be _the_ source owen: of course, typelib can be generated from .h mathrick: that's not going to happen for C objects. Sorry. I think we can lay that down as a groundrule for this work. owen, Guido is reserving some keywords for it and has implied it will eventually be added owen, there's no timeline for it, though mathrick: For one thing, did you see my "object-file-less header file trick above" ? (based on XPCOM, actually) owen: if I make my KillerPyLib, you're going to generate from typelib ;) owen: what trick, no? jpe: You can actually get away without a proxy lib with some magic. #define gtk_widget_show(w) (void (*) (GtkWidget *))((GenericObject *)w->vtable[53])(w) I saw something in the ctypes documentation that there's a way to get type info out of gcc owen: ah, yeah mathrick: If you do that for your generated header files, you don't want your C-implemented-header files to be at all like that. You want to call the real C methods, not some vtable proxy. owen: yup owen: I think it's going to work that way mathrick: typelib isn't the authoritive source. It's the authoritative way to exchange type information owen: it's meant to be 110% compatible with today's GObject owen: yeah, that definition is more precise mathrick: The authoritative source is whatever works best for the person defining the Object. For GTK+, that's header files. (We may have a gmoc change of heart. It's conceivable. But for now, I'd bet against it.) owen: I don't insist on gmoc happening. I want gmoc to be fully feasible if we decide it's too much burden to write endless /* @methodof@ */ stuff owen: beast kinda does that with its own idl compiler. that thing is very flexible and implements 99% of the non signal-processing stuff for plugins. it'd be too specific and non-standard i guess for adoption though. mathrick: I think by making parsing smart about how GObjects normally work ... like gtk-doc is smart .. I don't think we'll have as much annotation as you expect. rambokid: mental note to look into it added :) http://beast.gtk.org/sfidl-manual.html owen: yeah, that's to be evaluated in practice I guess http://beast.gtk.org/plugin-devel.html both documents are still being worked on though mathrick: But sure, anything that allows object definition without header files for other languages can be used with gmoc style approach. owen: is gmoc a vapourware term for gobject-moc or did someone start such a thing already? rambokid: vapourware rambokid: It's purely a vaporware name. for gobject-moc / gob-future we should name it "mob" :) moc + gob mathrick: Except that gob is sort of (but not really) moc + gobject already owen: yeah, it's elaborate cpp, I know really i think, GObject got very far in using C. when ading (much) more sugar/functionality to it though, i think the language situation should be reevaluated, i don't see much point in going very much farther in C if C++ is ubiquitously available. mathrick: gob (last time I looked) is a bit more like cfront because you define your object implemetnations not the just the interface. rambokid: C++ isn't much of an advance from C. rambokid: C++ sucks you really want to go to C++? rambokid: no matter if it is ubiquitous or not by means of conventions, C++ can be just as easily bindable as C and it can integrate with the GObject framework well. rambokid: As faras type systems go. After all, you need moc, or libsigc++, or whatever to make it a decent object system rambokid: in terms of type system, C++ == C, ie almost non-existant owen: if you say that, you haven't actually tried to grasp the concepts behind that language, "The C++ Programming Language" by bjarne would e.g. be a good guide for that. rambokid: I'm definitely in the managed runtime camp as far as long term direction. What I'd like to see short term is just a good full introspection system for GObject so that we can export GObjects to interpreted languages or to a managed runtime without code generation or manual binding glue rambokid: I think I did, and I still hold that C++ has no real type system rambokid: I spent several years programming C++ before I ever wrote pure C program mathrick: i said ubiquitous since when gtk+ started out, C++ wasn't an option in practice, due to changing standards and lacking cimplementations rambokid: that's orthogonal owen: the interesting concepts became aparent only in recent years rambokid: C++ isn't sufficient for what we need and want it, and introspection stuff will only strengthen that discrepancy rambokid: While some of the C++ syntatic sugar could have been useful for GTK+/GObject, I want events, I want introspection, I want garbage collection, I want properties. mathrick: practical considerations are never orthogonal if you intend to actually get something done ;) owen: exactlt my view (on managed thing) rambokid: C++ sucks, GObject doesn't, and it actually works rambokid: All of that stuff isn't in C++ without a thick layer on top. And I don't see any reason to move in that direction when better alternatives are available. rambokid: C++ doesn't buy us a thing over GObject rambokid: since they operate in totally different domains owen: i've tried various introspectable procedure (function) things in beast over the years, and i don't really think there're good ways to get it done conveniently without either templates or code generation. mathrick: I'm not sure I'd say that. I would agree that they are largely orthogonal axes. owen: I mean, switch to C++ doesn't invalidate need to have GObject on top, so C++ doesn't buy us a thing we still need to do that work owen: if with managed runtime you mean apps working in a mono-like runtime-env long-term, yes, i'd second that. mathrick: C++ provides wonderfull tools to implement introspection. owen: and I personally come to hate C++ rambokid: like? rambokid: Despite not having types as first class objects? mathrick: "Hate" is hardly ever a valid arguemnt rambokid: I _come_ to hate it rambokid: I started as fanboy, after reading Stroustrup didn't really even know C at tge time rambokid: (OK, that's changed a bit recently with RTTI, but it's still very weak in the introspection realm. In C# or Python you can iterate the methods of a class and call them without generating any code) rambokid: what are the tools you have in C++ that aren't there in C? rambokid: I mean tools that are useful for anyone else than C++ code that is note that i'm not really advocating replacing GType/GObject with C++ here. i just don't think with hand-crafted type+object+signal stuff in C you can get a certain distance and after that things just become too inconvenient. rambokid: then we can switch to more elaborate language, like Python rambokid: anyways, I'm hoping that we can figure out introspection for current gobjects with header file annotation and analysis. We already do most of that with gtk-doc, and the various language binding header scanners already. If we can't, well, then we'll reevaluate. rambokid: GObject is really only a runtime and i think GObject explores most of what's possible in that, so we shouldn't go much farther. large code-gen macros like G_DEFINE_TYPE() are a typical symptom at this point. we're close enough to wanting a moc to stay convenient enough. hmm, related question: how good is libffi at portability and workingness on platforms we support? mathrick: yes, because there's no way to implement GObject with static typing in C. mathrick: it wasn't good enough when i wrote GSignal. rambokid, you may be right about GObject based C code is complex, but C++ probably isn't much better rambokid: hmm mathrick: but nowadays they ship it with gcc for java, so i'd expect it to get good enough if it isn't already. rambokid: My general feeling is we should work on making GObject introspectable, because that works well for any way we should go forward. but no, it's never going to allow the programmer on the street to easily write OO programs. rambokid: that was when? 8 years ago? rambokid: ah, ok :) mathrick: it's not necessarily as fast as our current (optimized) marshallers though. rambokid: And it is never going to be blazingly efficient. rambokid: yeah, but libffi is here for thunks we'd need to be generating for bindings rambokid: I do sometimes wonder if libffi could be *more* efficient because it doesn't have big wads of generated code to foul up l1 caches rambokid: And at least optionally having marshaller == NULL use libffi could make signal-definition-for-novices easier owen: as for .h file analysis, i've never liked putting semantic app information into comments. the enum nicks are already a stretch. so at that point i (personally) rather turn to a different language (like porting beast to C++) rambokid: (I can get glib-genmarshal going in Makefile in 30 seconds flat. But that's not typical) jpe: i'm not even saying code with GObject is necessarily complex, but definitely clumsy and inconvenient to write. thus people do much less derivation than would be usefull for the problem domains, and you start to see crutches like G_DEFINE_TYPE() pop up. rambokid: but that's purely C's trait, not GObject's owen: right (about not esily writing OO) rambokid: I can do class Foo(gobject.GObject): easily mathrick: the cause doesn't matter if the effects keep us from doing good OO ;) rambokid: and that's why I asked if that would be acceptable to use IDL for C, some time before you joined :) mathrick: no, gtk(+) was 8 years ago, GSignal was around 2000/2001 iirc (as long as you don't forget to chain up the constructor and get a mysterious crash deep in PyObject C code. But maybe that is fixable with metaclass) maybe some of 2002, when did we release 2.0? rambokid: Mar 2002. Gobject was first half of 2001 mostly rambokid, I agree (which is why I use python); to make C++ work requires a fair amount of work and the results are only usable by those who know the particular dialect of C++ owen: that's general weakness (or strength) of python's class model owen, the need to chain up is fixable owen: as for caches, lots of marshallers bloat apps, yes. but in practice only a small amount of them gets used, so usually there's not too much marshalling code to be kept in caches (as far as my experiences go) owen: yes, marshaller==NULL falling back to something like libffi was mentioned pre-GSignal, and i if i'm not mistaken, the GSIgnal API should allow for such an extension. when is 2.6 scheduled as of today? dec 15? owen: yep, i can derive a new object in a couple minutes with a good skeleton of functions i need in place. the point is, most other people can throw around GObject code/rule like us ;) s/most other people can/most other people cannot/ i hope i didn't completely ruin the discussion you all had when i joined... ;) rambokid, I think the situation w/ C++ GObject would be worse than it is now rambokid: no, we were summoning you from beginning :) rambokid: No, it was tailing off. Actually, originally we were looking for your for GObject serialization discussion. But that got sidetracked into introspection, and it's 2 hours later now, so probably about it for this meeting :-) mathrick: someone should have /msg'ed me then. there's always a good chance i'm near the machine... rambokid: ah, I quickly scanned channels and you were on none, didn't think of it i'm not vey fond of the serialization discussion. i'm reading it on the list, but from all i figured about object serialization over the last 5-7 years, it is *very* application specific. i could list like 5-10 points off head that'd be missed by a generic implementation (and interface even) in glib. mathrick: #gtk+ ? rambokid: joined 1h after discussion started :) [rambokid] #mono @#gimp #beast @#gtk+ @#gnome-hackers @#gnome #gnome-de #commits mathrick: no, i'm on all these channels all day long. i just rejoin from time to time due to ppp reconnections rambokid: ah, right, so I missed you there anyway ;) bad thing is, I need to get my ass moving on that introspection thing, discussing is nice, but doesn't get things done :| (which is kinda sad ;) rambokid: hmm, still here? yes. (i ought to be in bed already though ;) rambokid: there's ongoing discussion on #gstreamer, and Company is mumbling about not being able to unregister type rambokid: is it possible to do? and if not, would it be possible to add unregistering? no. no for both? mathrick: no, very hard, we decided against it during GObject design. (OK, I think rambokid explained to me how hard it was and why he wasnt' going to add it) no for unregistering, what's the other issue? rambokid: 1) is that possible now? 2) can that be added? were the issues :) mathrick: company has unloading and library-dependancy problems. he doesn't really have gtype problems. rambokid: no, he wants to be able to totally remove types mathrick: ok, then no on both ;) as owen said, it was a design decision. mathrick: basically, there's no point in removing type ids. mathrick: i talked to company the other day on irc, just him thinking he needs type id removal doesn't mean this would solve the problems he's facing. rambokid: ic rambokid: well, I can see that useful in arch so much plugin-oriented as gst mathrick: it is not. type id removal would basically mean two things: 1) existing type handles become invalid (that's as good as "unregistering" quarks) 2) you couldn't reload a dynamic type. (1) doesn't buy you anything, and (2) canbe done by convention. yeah, but (2) needs code, which would reside in libgstreamer, which we want unloaded. That's the Company's concern if I got it correctly mathrick: You can unload all code associated with a type ... the main thing you can't do is reuse the same type name with a different object heirarchy mathrick: you are aware that type implementation unloading (objects, interfaces...) *is* supported by GType? rambokid: yes mathrick: then i don't understand what code you want to unload but can't i know what company's problem is though. he's got plugins that need third party libs that may or may not be unloadable and may or may not need intitialization or be already initialized. (kinda like using libgtk from within a plugin only) rambokid: hmm, I think it goes like that: we load type plugin, register dynamic type. it's completed at some point. then we unload it, and want g_type_plugin_complete_type_info() to fail from now on. But to know if / when to fail, we need bookkeeping code, which is a drag, and also that code can reside in unloaded lib mathrick: I think the thread safety flaws in gobject would be a much more interesting windmill to tilt at ;-) for gst heh g_type_plugin_complete_type_info() can't fail. owen: oh, i desperately want atomic refcounts, just too little time... mathrick: i don't even know what "g_type_plugin_complete_type_info() fails" could possibly mean, other than: "the program is broken, bail out". rambokid: hmm, so can you fail to reload dynamic type? no, the type system guarantees the caller that he'll also gets the type he requests (e.g. g_object_new() cannot fail) s/also/always/ rambokid: right, and Company wants to be able to fail ie, when we load plugin, we don't want to commit to that type being available forever mathrick: i guess you could create wrapper code for g_object_new() that can check and fail. that wouldn't work for say widgets which use g_object_new() internally, but for all places where you call your wrapper constructor. you need to write your own creation code anyway since it needs to be able to handle failing object creation then. (as an aside, libgtk widgets are static types anyway) rambokid: yeah, it's not like we want arbitrary types to disappear, but our plugins should be completely unloadable and leave no traces mathrick: "unloadable" is the wrong term rambokid: s/unloadable/whatever is right/ then :) mathrick: the type system can't allow for that. say you load plugin A introducing Foo and then some code derives Bar from Foo (or uses values/pspecs with type Foo etc.) so once Bar (or the related values/pspec/etc code portions) is used, Foo must be reloadable. full removal of it would break sorta unrelated code portions. (at least from a type system API perspective) rambokid: in general case yes, but if you use such removable type, you should be aware of consequences :) mathrick: no. if that were the case, plugin types couldn't be used the same way static types are. i.e. you suddenly had to query is_plugin(type) before doing g_object_new(type) and check for NULL (or check for NULL from g_object_new() everywhere). this special casing were explicit non-goals in the gobject design (partly due to GtkObject), and is what i suggested earlier you add around your gstreamer types only. yeah, I guess so anyway, it's 2AM I should be sleeping :) (it's not just g_object_new() though, as i mentioned earlier, there're values, signals etc. that use type ids) me too, need to get up at 8. night. nite Meeting ended November 1, 20:04 EST (00:04 UTC)