Re: introspection and broken API
On Fri, 2005-25-03 at 01:06 -0500, Havoc Pennington wrote: On Fri, 2005-03-25 at 00:45 -0500, Havoc Pennington wrote: - put the main loop only in the GLib layer, no gtk_main visible - hide color allocation, just always use the GdkRGB stuff - fix some of the other examples of weird X features leaking through - gdk_drawable_get_size() replaced by get_width()/get_height() accessors - omit deprecated APIs - omit non-multihead-correct APIs A couple other good ones I remembered: - dumping GtkObject out of the class hierarchy - killing off the argument to gtk_window_new I know there are more. Havoc - DnD is heavily based on X selections, and thus weirdness seeps through. Sepecifically, GTK should provide a canonical list of supported GtkTargetEntry's, map those to X selections, then hide the whole mess from the programmer with getter/setters to those targets. Havoc, can I track these comments on live.gnome.org/ThreePointZero, or is there a better place? Cheers, Ryan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Creating objects without deriving from GObject
Thanks for the prompt reply Scott, I appreciate it! However there are still some broader questions. GObjectClass provides dispose and finalize methods; do I have to provide the same for my class? Are there no other interactions I need to know about if I'm not deriving from GObject? On Tue, 2004-13-07 at 07:57 -0400, muppet wrote: On Jul 13, 2004, at 10:00 PM, Ryan McDougall wrote: How does one Choose a GType number so it doesn't collide? http://developer.gnome.org/doc/API/2.0/gobject/gobject-Type- Information.html#g-type-fundamental-next I failed to notice this detail, thanks for pointing it out. But a question remains, why doesn't g_type_register_fundamental not call this function without bothering to ask the user? Where are the fundamental flags documented? i trust you've already seen http://developer.gnome.org/doc/API/2.0/gobject/gobject-Type- Information.html#GTypeFundamentalFlags and http://le-hacker.org/papers/gobject/ . I indeed have read the preceding, and can guess what the first 3 flags mean, but those simple half sentence explanations don't really tell me what the flags imply. I guess I was hoping for more. Thanks for the help! Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Creating objects without deriving from GObject
Hello, I am writing a tutorial on using Glib type system, and developing some simple software as I go. I would like to create class that has no need for GObject (reference counting, properties, etc.), however it appears from the documentation that this makes it a fundamental type. How does one Choose a GType number so it doesn't collide? Where are the fundamental flags documented? How does does a fundamental type interact with the memory manager (which could one day be a garbage collector)? Or is the library designed so that every end user would derive from GObject? If so, aren't there very good reasons why a user might not want to do so? Thanks for your help! As I said its for a tutorial, so answering me will mean answering a lot of people when I'm done. Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: RFC: Part 1 of new GObject tutorial
On Fri, 2004-16-07 at 19:56 +0100, Roger Leigh wrote: Ryan McDougall [EMAIL PROTECTED] writes: As promised I finished the the first part of a tutorial I started writing for the fun of it. It only includes making a pretty lame fundamental class with no inheritance, but its is (hopefully) very comprehensive and clear. There are code examples included. Therefore I'm asking everyone with some experience to give it a read over for technical mistakes, or unclear language. OK. These are all the things I could see: Thanks for the advice, I appreciate the feedback! 1. main() in gobject-tutorial-example1.c should be in a separate file--it's not part of the class implementation. True. It adds another file, but if I beef up the example then it would be more worth it. 2. The class finaliser does nothing, so personally I would not include it. Throughout I tried to be as complete as possible so anyone using it as a template wouldn't miss something. 3. Should people really be encouraged to use fundamental types, rather than deriving from GObject? No, thats why I will developer it further to use GObject and the new macros introduced in 2.4. 4. While the example works, I personally find examples easier to follow when they have a useful purpose. Currently I can see what your example is showing, but I can't see a /point/ to it. Compare it with this example: http://people.debian.org/~rleigh/gtk/ogcalc/ogcalc-1.0.4.tar.gz (this was even simpler than your tutorial nine months ago!) I would suggest keeping the class the same, but give the class name and fields some names and purpose that the reader can relate to. You have a point, but I don't think I'll have time to do so until I've finished the prose part, which for me is the most important. If you can make one simple class do something interesting without adding superfluous code, you are more than welcome to help me out with a patch! 5. The tutorial text could use some line wrapping. If you use Emacs, try M-x text-mode and then press M-q while point is in each paragraph, which will nicely flow the text. It's not too readable on a text terminal :( I will consider my formatting further. Actually I wouldn't mind some XML/HTML guru showing me how to make it presentable in that form. 6. You might find a typesetting system such as LaTeX makes writing much easier :) Feel free to copy stuff out of my tutorial, providing your licence is GPL-compatible. 7. objects' livetimes. I think you mean lifetimes. Yeah, there are a couple type-os. ;) 8. The unfinished part 2 needs to be vary careful in describing base/class/instance init/finalise functions, in order to clearly differentiate their role, execution order, required usage and examples of each. I think I have finally understood that myself, but you are welcome to submit anything you think I've missed. Next section will tackle inheriting from GObject, and the one after will be about inheriting from our custom class. Sounds great! I am finding GObject very nice, but will really appreciate some more documentation on the subject. I look forward to reading it. Regards, Roger Once again, thanks for the comments. Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: RFC: GObject FAQ
On Wed, 2004-25-08 at 02:39 +, Tiago Cogumbreiro wrote: Hello list, I've just created a GObject FAQ where I try to answer, hopefully correctly, some questions I've had while programming with GObject. http://s1x.homelinux.net/documents/gtk/gobject-faq.html I would like to receive comments on bugs/typos it may contain as well as more entries if needed. Next thing I intend to do is to explain: - how interfaces should be implemented more throughly - properties - signals PS: That page also contains a simple guide on threaded programing which I've already brought to the list and some thoughts about Signals versus Listeners Interfaces. Thank you all for your time, Tiago Cogumbreiro Hi Tiago, I recently did a similar thing: writing down the answers to my own questions as I learnt GObject. However there are some differences. My text is really ugly, not like your site which is quite nice. My perspective tries not just to state how GObject currently is, but to also justify *why* it is that way -- in other words I try to ask myself how would I do OO in C. So my question to you is can we collaborate? I think I have more text than you currently, so I would like to merge your text with mine, then mark the result up and post it on your site with credits to both of us. What do you think? Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject tutorial next version
On Thu, 2004-26-08 at 08:14 -0400, muppet wrote: On Aug 26, 2004, at 3:33 AM, Ryan McDougall wrote: [spelling errors snipped] by apologizing for digressing, you're digressing. how about a footnote or appendix instead? LOL. Its true that learning any sort of code requires a lot of parallel learning, and the structure could be better. But sometimes it helps to explain why we seem to be leaving the main point, then returning. jumping straight into how do derive your own base object type without GObject, but still using GTypeInstance, is rather confusing. are you trying to show that you should do it yourself, or that this is the hard way to do it? remember that many people will skip the prose and jump straight to the code, so putting the example of a Hard Way and not necessarily the right way to do it first may be very misleading. Thats a really good point, maybe you could point out how I could make it better. When writing this I had one main goal, teach myself GObject; and two main assumptions, that each person learn differently, and there are more than one tutorial available. That is the driving reason for the way it looks. I took the route that made most sense to me: How would I implement OO in C and took GObject as the given answer. In that sense its perfectly logical to pursue Object Based programming (no derivation) before Object Oriented. A perfect example is your stated truism that all people will skip the prose and go straight for the code. Its just not true because thats not what I'd do. I want code *and* explanation, which is what I've given. People who just want code can look else where for far shorter examples. I tried to state as much in the wording, but perhaps I've failed. Any ideas? I am going to merge what I have with what Tiago has done, so there will be more How do I do X later on. Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_value_new Macro?
On Thu, 2004-26-08 at 15:59 +0800, James Henstridge wrote: On 26/08/04 14:22, Ryan McDougall wrote: Also, your macro looks like it might break sometimes. The g_value_init() function expects the GValue to be zeroed out (the type field at a minimum), and g_new() doesn't guarantee this. replacing it with g_new0() would fix this problem. I spotted where the docs say it must be zero init'd, but I can't see in the source *why* thats needed. I guess so you don't call init on a value that has already been init'd without calling reset first. Perhaps its my ignorance of GValue, why is memory allocation GValue's problem, thus necessitating an unset function. Shouldn't I dealloc my own pointers? If you are doing this for your tutorial, it would probably be better to document the common usage of GValues rather than using a non standard g_value_new() macro. For some internal code, I prefer to pass a heap allocated GValue pointer to some unnecessary copies of stack alloc'd GValues, so I use it outside of the tutorial (which can be changed). Basically I don't see any reason *not* to add it once the g_new0 bug is fixed. James. Thanks James! Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GObject tutorial next version
On Fri, 2004-27-08 at 02:57 +, Tiago Cogumbreiro wrote: One thing I've learned from reading the big reference on GObject documentation[1] is that howtos/quick refs/faqs and theoretical explanations don't, usually, mix. While reading it I usually wanted to I disagree. Sometimes you want to know how without why, and sometimes you want to know why. Thats why there is all kinds of types of doc to look at. I always have a tutorial and reference open beside each other. Maybe you could explain in the document why you chose GTypeInstance and why we use GObject instead. The same thing regarding to GTypeClass versus GObjectClass. Also, when G_DEFINE_TYPE_EXTENDED is introduced the reader should know the differences between these types, otherwise i think it's a bit confusing on why the object definition changed because of one macro. Wasn't the reader supposed to know how to define a class already? Why did the procedure changed? I already have the following in the doc: notice While we will reuse the ideas and patterns we have discussed above throughout the text, attempting to create a fundamental type that behaves as it should with other GTK+ code is very difficult and in- depth. It is recommended that you always create new types by deriving from GObject, since it does a lot of background work to make things behave how GTK+ assumes it should. From now on all our objects will derive from GObject, which will be the subject of our next section. /notice I have introduced the macro after GObject. One more thing, introducing constructors before properties doesn't seem to be the best thing to do, because constructors are only used to check properties passed through the g_object_new marked with G_PARAM_CONSTRUCT. Therefore i think you should just introduce the user the _init method. Also why do you show _finalize and _dispose? For one thing readers will usually only use _finalize, another is that you don't explain the difference between them. I actually tried my best to explain the difference between them. Its all there in the text. Did you skip the text and go straight to the code? ;) So maybe first you could explain the _init and _finalize methods then explain properties and the go back and explain the _constructor. Constructor is presented first since its a more fundamental OO concept than properties (which is just a nice mechanism). But in reality the two are intertwined. If I show properties first then people that means GObject is basically the LAST thing I show. Theres no perfect way to treat something so complicated. Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_value_new Macro?
On Thu, 2004-26-08 at 23:16 -0400, muppet wrote: On Aug 26, 2004, at 10:56 PM, Ryan McDougall wrote: GValues are used in code that runs a *lot* (marshaling code for signals, property mechanism, etc), and need to be fast. allocation on the stack is far faster than allocation on the heap, and you don't have to worry about it failing (it happens automatically, even). thus, the GValue API, like the GtkTreeIter API, is designed to allow you to use values on the stack. if it's on the stack, you're not going to be calling free() on it, so you need some way to release any resources it may contain; hence g_value_unset(), which brackets nicely with g_value_set_*(). Don't get me wrong, I see where unset is useful when your programming generically (wrt to types), but I don't know why I can free the pointer inside the value if I want to. unnecessary copies of stack alloc'd GValues? could you elaborate here? from what i can see, you always pass GValues by reference, not by value. why would they be copied? I want to pass a GValue from my API to some user code. How can I do that on the stack? I could ask them to pass in their own GValue and and copy the value to theirs, but I do that in several places, which results in unnecessary copying. the only place where i see heap-allocated GValues being necessary is in something like a collection container, where you're going to hang on to them for longer than the stack frame will be alive. in that case, g_new0() by itself is sufficient, but g_value_new() would be nice for readability. How did you know I was writing some container code? ;) As usual, Scott, and his quotes about his pregnant wife, rock. ;) Cheers, Ryan ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
GObject tutorial next version
This covers everything except signals, which is the last thing to do. Warning currently its in plain text format since I haven't gotten around to fancifying it yet, however it WILL be prettied up. I'd appreciate feedback on technical, spelling, grammar, or style points. Cheers, Ryan GObject Tutorial Copyright Ryan McDougall (2004) Purpose - This document is used for two purposes: one is as a tutorial on learning Glib's GObject Type System, and the other is a step-by-step how-to for using the system. The tutorial proceeds from the point of view of designing an Object-Oriented type system in C, where GObject is the presumed solution. It is thought that this manner of presenting the material will better justify the form that the library currently takes, and help explain the steps required use it. The how-to is presented after the tutorial in a step-by-step, matter-of-fact, form with no explanations, so that it will be useful to the merely pragmatic programmer. Audience - The tutorial is meant for those who are familiar with OO concepts, but are just beginning to learn GObject or GTK+. I will assume previous knowledge of an OO'ed language, and a basic command of C. Motivation - While writing an OO system in a language that doesn't support it may sound like a foolish exercise in masochism to some, there are indeed some good reasons why one would want to do such a thing. While I will not try to justify the authors' decision, and will assume that the reader has some good reason for using Glib, I will point out some important features of the system: - C is the most portable programming language - system is fully dynamic, so types can be added at run-time - system is more extensible than a standard language, so new features can be added quickly In OO languages object oriented features and abilities are a matter of syntax. However since C doesn't support OO natively, the GObject system has to graft on object orientation manually. Often this requires some tedious, or occasionally mystifying things in order to accomplish this goal. It is my intention to enumerate all the necessary steps and incantations necessary to make this process work; and hopefully even elaborate on what it means to your program. 1. Creating a single Object with no Inheritance Design - In OO, an object consists of two types of members bound under one object reference: data fields and method functions. One way to accomplish this in C is with C structs, where data fields are regular public members and methods are implemented as function pointers. This implementation however has several serious flaws: awkward syntax, type-safety, and lack of encapsulation to name a few. However there is more practical problem -- it is a serious waste of space. Every instance object needs a 4-byte pointer for each of its methods; all of which will be identical class wide, and thus totally redundant. That is to say if we have a class with only four methods, and a program with 1000 instantiation objects of that class, we are wasting almost 16KB. Clearly we'd be better off memory-wise if we only kept one copy of those pointers in a table that could be accessed by any object in its class. Such as table is called a virtual method table (vtable), and one copy is kept in memory by the GObject system for each class. When you want to call a virtual method, you must ask the system to find the object's vtable; which as we have said above is just a struct with function pointers. With this you can now dereference the pointer and thus call the method. definition We will call these two types instance struct and class struct, and instantiations of those structs instance objects and class objects respectively. The combination of the two structs as a conceptual unit will be called a class and an instantiation of that class will be called an object. /definition The reason why functions given by this process are called virtual is because it dynamically looks up the appropriate function pointer at run-time and thus allows inherited classes to override a class method (by simply assigning a new function pointer to the corresponding entry in the vtable). This allows derived objects to behave correctly when cast to a base class, and corresponds to what we know of virtual methods in C++. convention Although this saves space and allows virtual methods, it also means that methods can no longer be tied syntactically to an object via the dot operator.Therefore we will use the convention that class methods will be called on objects as follows: NAMESPACE_TYPE_METHOD (OBJECT*, PARAMETERS) /convention Non-virtual methods will be implemented inside a regular C function, and virtual functions will be implemented by calling the appropriate method from the vtable inside a regular C function. Private methods will be implemented within the source file, but not be exported via the header file. notice While OO normally uses
RF Review: a simple tutorial on GTK+ DragNDrop
http://live.gnome.org/GnomeLove/DragNDropTutorial I tried to make its as clear and correct as I could, but it quite possible there are major errors or generally heinous abuse of the API. In particular the use of X selections may be way off. Please take a look and leave either comments or edits on the wiki. Cheers, Ryan ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
