Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 09:27:37AM -0800, Jasper St. Pierre wrote: The learning path for writing a GTK+ application should be: GLib - GObject (at least the basis) - a bit of GIO - and finally GTK+. All GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's important to explain what it is, at least briefly. I disagree. The learning path for writing a GTK+ app should start with GTK+ and let them venture into the utility libraries of GLib and Gio when they need to. No need to start with here's the library that seemingly reinvents all of C99 because people sometimes still use SunCC in TYOOL 2015. It's all the debate between the bottom-up and top-down approaches. Maybe a good compromise is a mix between the two, because it's more fun to show a window with three buttons than learning how to create a signal. But sooner or later a developer needs to know GLib and GObject. For a potential book about GTK+, there can be a short chapter on GLib to learn the basis, then an introduction to GTK+ with some basic explanations on how to _use_ a GObject class, then a chapter to know how to _write_ GObject classes. For what it's worth it was roughly the path chosen in GGAD. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 3:37 AM, Sébastien Wilmet swil...@gnome.org wrote: On Thu, Jan 22, 2015 at 10:51:38PM +, Alberto Ruiz wrote: I agree with Paul here, GTK+ targets people who want to do desktop apps. I would actually try to sell all the new stuff for developers like the new introspection tool, the new widgets and some of the new CSS work with snippets. One purpose of the flyer that I had in mind is to explain what to learn for writing a GLib/GTK+ program, providing an overview. If people have never heard of GObject, they will look at some code and will be afraid of all the macros and other boilerplate code that they don't understand. The learning path for writing a GTK+ application should be: GLib - GObject (at least the basis) - a bit of GIO - and finally GTK+. All GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's important to explain what it is, at least briefly. I disagree. The learning path for writing a GTK+ app should start with GTK+ and let them venture into the utility libraries of GLib and Gio when they need to. No need to start with here's the library that seemingly reinvents all of C99 because people sometimes still use SunCC in TYOOL 2015. Also, it's important to note that GObject was intentionally designed with bindings in mind. It's also a selling point for many people. In general, Linux users know what is GTK+. GLib, GObject and GIO on the other hand are less well known, but deserve more attention (e.g. for writing daemons, as explained in the brochure). For the images, there is already a GNOME flyer with some screenshots if I remember correctly, so in my opinion it's not really important to include lots of GTK+ screenshots (but one more image at the end could be better). Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 10:39:17AM -0500, Paul Davis wrote: Event loop programming is simultaneously completely fundamental to all user-interactive software, and as such ought to require no introduction at all, but as you note it is (pathetically) lacking from the education experienced by many in the field. If you're going to draw an event loop then I think you want to capture something a bit less abstract than what you have. Events (keyboard,mouse,touch,network,serial,other data sources) = application response (computation, communication, request drawing changes) = redraw = REPEAT That's the actual useful event loop. Yeah, the GMainContext state diagram is a bit abstract without more explanation. So I've replaced it by another schema, which is really straightforward to understand now. The redraw part is specific to GTK+ or a graphical application, so it's better to not mention it in the GLib section. I explain a bit later that it can be used to write daemons. Thanks for your feedback, Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
I don't see much of a debate there. Most people want to solve a problem, and start from the problem, not from the tool to solve it, it's not like home improvers go hey there's this really nice drilling machine, I should buy some shelves to learn how to use it. People who are likely to use GTK will start from the problem they want to solve and are in need for a graphical toolkit to draw widgets that do what they want. Quite frankly advertising C/GObject as the reference language for newcomers is something we already agreed was not recommended during the UX hackfest and that's why we decided to choose JavaScript as the entry point. Point them at what the toolkit does and the easiest way to use it, and people will learn as they go. GObject and GIO by themselves are of no interest for most people wanting to write apps, specially in C. 2015-01-23 18:05 GMT+00:00 Sébastien Wilmet swil...@gnome.org: On Fri, Jan 23, 2015 at 09:27:37AM -0800, Jasper St. Pierre wrote: The learning path for writing a GTK+ application should be: GLib - GObject (at least the basis) - a bit of GIO - and finally GTK+. All GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's important to explain what it is, at least briefly. I disagree. The learning path for writing a GTK+ app should start with GTK+ and let them venture into the utility libraries of GLib and Gio when they need to. No need to start with here's the library that seemingly reinvents all of C99 because people sometimes still use SunCC in TYOOL 2015. It's all the debate between the bottom-up and top-down approaches. Maybe a good compromise is a mix between the two, because it's more fun to show a window with three buttons than learning how to create a signal. But sooner or later a developer needs to know GLib and GObject. For a potential book about GTK+, there can be a short chapter on GLib to learn the basis, then an introduction to GTK+ with some basic explanations on how to _use_ a GObject class, then a chapter to know how to _write_ GObject classes. For what it's worth it was roughly the path chosen in GGAD. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 1:05 PM, Sébastien Wilmet swil...@gnome.org wrote: But sooner or later a developer needs to know GLib and GObject. I've been using GTK for 15 years. I still know very very little about GObject and I plan for it to remain that way. For a potential book about GTK+, there can be a short chapter on GLib to learn the basis, then an introduction to GTK+ with some basic explanations on how to _use_ a GObject class, then a chapter to know how to _write_ GObject classes. For what it's worth it was roughly the path chosen in GGAD. Writing GObject classes is not typically something that application developers will do. There are a few nice GObject-based libraries that are external to the g* stack, but not many. It really isn't central to programming with GTK. And if you use a different language binding, it becomes even less relevant. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 06:18:02PM +, Alberto Ruiz wrote: I don't see much of a debate there. Most people want to solve a problem, and start from the problem, not from the tool to solve it That's why the brochure begins by an introduction to GTK+ and an architecture overview. People who are likely to use GTK will start from the problem they want to solve and are in need for a graphical toolkit to draw widgets that do what they want. Exactly. People who use GTK+ applications already know what is possible to do with GTK+. Or if they use KDE or Windows or whatever, the applications and the desktop are the visible part that they already understand well. You just need to say you can do that with GTK+. On the other hand, what happens under the hood isn't obvious, and can be interesting (e.g. for a CS student) even if the person doesn't want to write a GTK+ app. At FOSDEM there are some Belgian students (like me several years ago) that traverse every stand and take as many things as possible, be it stickers, brochures, pens, etc. I have that public in mind too. Imagine a young student who reads the GTK+ brochure, and then several years later he/she wants to write a daemon, ideally the student will remember the brochure about GLib/GObject and event-driven programming and will start learning GLib! Point them at what the toolkit does and the easiest way to use it, and people will learn as they go. GObject and GIO by themselves are of no interest for most people wanting to write apps, specially in C. Uh, it's quite the contrary IMHO. If a developer chooses the C language and wants to write a GTK+ application, it's advised to write GObject classes to have a good code architecture. Look at gedit for instance, it's full of GObject classes. You create a subclass of GtkApplication, a subclass of GtkWindow for your main window, subclasses of GtkGrid or GtkBox for some other components that you have in your application, etc. Without GObject, you can write structs, allocate them and pass a pointer as the self argument, but GObject is much more powerful. It's interesting to create signals for example. For developers who choose a higher-level language, knowing the basis of GObject is useful too: what is a GObject signal, what is a property, oh there is actually an object hierarchy and I can call a function from the parent class, etc. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 01:38:05PM -0500, Paul Davis wrote: Writing GObject classes is not typically something that application developers will do. There are many apps in GNOME, written in C, full of GObject classes. Look at gedit for instance. By reading the answers of this thread, it seems that GObject should be something we should hide to newcomers because it's a bit painful to use. It's indeed a bit painful, but I hope that some better tools will exist in the near future (Builder) to create, rename, refactor GObjects while still keeping a good indentation, to format the function prototypes and headers automatically, completion of signal and property names, static-analysis tools to detect if a signal callback has a wrong prototype, less boilerplate code (GProperty, signals? syntactic sugar?), and I probably forget other things. It's a bit off-topic, but maybe if GObject was created with only the C language in mind, everybody would be happy with C/GObject. But since GObject was created with bindings in mind, it's a bit more painful in C. But it has the advantage that if one day there exists a wonderful high-level language, someone just needs to write good GObject introspection support, and suddenly millions of lines of GObject code can be used in the high-level language. Supposing that the binding support is really stable and that API documentation targetting the high-level language is available, there is still a potential problem: the exposed API can be weird to use in the high-level language because it doesn't use all the features of that language. So ideally you need to write a wrapper for each library (a bit like the *-glib wrappers to GObjectify some libraries). This last thing really happens, for example one reason why the MonoDevelop developers have written another text widget in C# is because GtkTextView had a weird API in C# (but some can argue that it's also the case in C :-). Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 3:06 PM, Sébastien Wilmet swil...@gnome.org wrote: For developers who choose a higher-level language, knowing the basis of GObject is useful too: what is a GObject signal, what is a property, oh there is actually an object hierarchy and I can call a function from the parent class, etc. quite the contrary. the entire point of almost all existing language bindings is to make the object model be idiomatic to that language. I work in Gtkmm and have also worked in pygtk quite a bit. There's no reason whatsoever to understand GObject at all with these bindings. Look, I understand that you think that GObject is pretty cool (it is), that it, along with glib, can serve as useful building blocks of non-graphical applications (they can) and that this fact should be more widely known (it should). But is that the purpose of a brochure on GTK+ ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Jan 23, 2015 12:06 PM, Sébastien Wilmet swil...@gnome.org wrote: On Fri, Jan 23, 2015 at 06:18:02PM +, Alberto Ruiz wrote: I don't see much of a debate there. Most people want to solve a problem, and start from the problem, not from the tool to solve it That's why the brochure begins by an introduction to GTK+ and an architecture overview. People who are likely to use GTK will start from the problem they want to solve and are in need for a graphical toolkit to draw widgets that do what they want. Exactly. People who use GTK+ applications already know what is possible to do with GTK+. Or if they use KDE or Windows or whatever, the applications and the desktop are the visible part that they already understand well. You just need to say you can do that with GTK+. On the other hand, what happens under the hood isn't obvious, and can be interesting (e.g. for a CS student) even if the person doesn't want to write a GTK+ app. At FOSDEM there are some Belgian students (like me several years ago) that traverse every stand and take as many things as possible, be it stickers, brochures, pens, etc. I have that public in mind too. Imagine a young student who reads the GTK+ brochure, and then several years later he/she wants to write a daemon, ideally the student will remember the brochure about GLib/GObject and event-driven programming and will start learning GLib! That seems like an extremely bizarre and specific use case to optimize for, especially given that GLib's event loop isn't that well designed for server scenarios. They'd be better served by libev / libevent. Point them at what the toolkit does and the easiest way to use it, and people will learn as they go. GObject and GIO by themselves are of no interest for most people wanting to write apps, specially in C. Uh, it's quite the contrary IMHO. If a developer chooses the C language and wants to write a GTK+ application, it's advised to write GObject classes to have a good code architecture. Look at gedit for instance, it's full of GObject classes. You create a subclass of GtkApplication, a subclass of GtkWindow for your main window, subclasses of GtkGrid or GtkBox for some other components that you have in your application, etc. Without GObject, you can write structs, allocate them and pass a pointer as the self argument, but GObject is much more powerful. It's interesting to create signals for example. For developers who choose a higher-level language, knowing the basis of GObject is useful too: what is a GObject signal, what is a property, oh there is actually an object hierarchy and I can call a function from the parent class, etc. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 09:00:53PM +, Chris Vine wrote: You are looking at it from the perspective of a GTK+ developer and not an application developer. (I'm not a GTK+ developer, I just contribute a little) Application developers not providing applications specifically for the gnome stack almost never need to sub-class the library-provided GTK+ widgets. For example, contrary to what you think, they do not sub-class GtkWindow for their main window. Instead they use the (generally) perfectly adequate GTK+ container system to put things in GtkWindow objects, or in library-provided sub-classes of GtkWindow. If they want to be particularly rigorous, they may provide a convenience factory function for the purpose. If that doesn't work they probably use another toolkit, because OO with GObject is a pain for the application developer writing in C (and as I say, normally completely unnecessary). Nor for that matter would they normally sub-class GtkApplication: they just connect to GApplication signals to customize behaviour. Only in very specialized circumstances is derivation necessary in the average application. Yes, for a small application it's another possible code architecture. But I would still recommend to write C code in object oriented style (if the C language has been chosen). Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, 23 Jan 2015 21:06:05 +0100 Sébastien Wilmet swil...@gnome.org wrote: Uh, it's quite the contrary IMHO. If a developer chooses the C language and wants to write a GTK+ application, it's advised to write GObject classes to have a good code architecture. Look at gedit for instance, it's full of GObject classes. You create a subclass of GtkApplication, a subclass of GtkWindow for your main window, subclasses of GtkGrid or GtkBox for some other components that you have in your application, etc. Without GObject, you can write structs, allocate them and pass a pointer as the self argument, but GObject is much more powerful. It's interesting to create signals for example. You are looking at it from the perspective of a GTK+ developer and not an application developer. Application developers not providing applications specifically for the gnome stack almost never need to sub-class the library-provided GTK+ widgets. For example, contrary to what you think, they do not sub-class GtkWindow for their main window. Instead they use the (generally) perfectly adequate GTK+ container system to put things in GtkWindow objects, or in library-provided sub-classes of GtkWindow. If they want to be particularly rigorous, they may provide a convenience factory function for the purpose. If that doesn't work they probably use another toolkit, because OO with GObject is a pain for the application developer writing in C (and as I say, normally completely unnecessary). Nor for that matter would they normally sub-class GtkApplication: they just connect to GApplication signals to customize behaviour. Only in very specialized circumstances is derivation necessary in the average application. Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, 23 Jan 2015 22:29:02 +0100 Sébastien Wilmet swil...@gnome.org wrote: Yes, for a small application it's another possible code architecture. But I would still recommend to write C code in object oriented style (if the C language has been chosen). Just to be clear, I completely disagree. Whether to use GObject-style OO has almost nothing to do with application size. The GTK+ library is generally well enough designed to render the derivation of custom widgets unnecessary in almost all cases. The unnecessary use of GObject derivation is as much an affectation as anything else. The OO fad of the 1990s is now well over. We now have the functional fad (and as it happens GTK+ has bindings for most functional languages). The truth, as always, lies somewhere in between. Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, 23 Jan 2015 23:24:18 +0100 Sébastien Wilmet swil...@gnome.org wrote: I said object oriented style, not GObject. You can write C code with an OO style without using GObject. What you actually said was: Uh, it's quite the contrary IMHO. If a developer chooses the C language and wants to write a GTK+ application, it's advised to write GObject classes to have a good code architecture. Look at gedit for instance, it's full of GObject classes. You create a subclass of GtkApplication, a subclass of GtkWindow for your main window, subclasses of GtkGrid or GtkBox for some other components that you have in your application, etc. Without GObject, you can write structs, allocate them and pass a pointer as the self argument, but GObject is much more powerful. It's interesting to create signals for example. As I said, the idea that most application developers will want to derive their main window from GtkWindow rather than pack a library provided GtkWindow class, or derive GtkApplication instead of using GApplication signals, is way wide of the mark; and to market GTK+ on the basis that GObject presents an easy way of doing so, is also (in my view, not yours) wide of the mark. We don't agree. Let's leave it at that. Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 09:40:56PM +, Chris Vine wrote: On Fri, 23 Jan 2015 22:29:02 +0100 Sébastien Wilmet swil...@gnome.org wrote: Yes, for a small application it's another possible code architecture. But I would still recommend to write C code in object oriented style (if the C language has been chosen). Just to be clear, I completely disagree. Whether to use GObject-style OO has almost nothing to do with application size. The GTK+ library is generally well enough designed to render the derivation of custom widgets unnecessary in almost all cases. The unnecessary use of GObject derivation is as much an affectation as anything else. I said object oriented style, not GObject. You can write C code with an OO style without using GObject. The OO fad of the 1990s is now well over. We now have the functional fad (and as it happens GTK+ has bindings for most functional languages). The truth, as always, lies somewhere in between. GTK+ is object-oriented, so it makes sense to me to write the application in the same style. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 20, 2015 at 10:24 AM, Carlos Garcia Campos carlo...@gnome.org wrote: One important thing is that preview providers should be out of process, since unfortunately it's very easy to make things crash with buggy files (which are very common). That could be done by every provider, but if we force that at a higher level it would be much better. That would also ensure that preview providers don't block the UI main thread, assuming the communication with the provider processes will be always asynchronous unconditionally. I ultimately agree, and I wrote a paragraph to that effect in my proposal... It's tricky to enforce this in the library, because it effectively means inventing a way for a process to draw into another process that doesn't look like libbonobo, and I didn't really want to go that path... Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: recently-used.xbel
On 22/01/2015 19:48, Emmanuele Bassi wrote: I honestly don't really understand what are you trying to achieve. do you want to add files, or is it just an issue of displayed files? I want to prevent files of a particular type from getting displayed in the 'Recently Used' list. AFAICT that would mean me needing to prevent them from getting added to 'recently-used.xbel'? Here's the scenario... our dialog can display two types of file - let's call them typeA and typeB. But our application can only understand files of typeB. If the user selects a file of typeA, we defer to a 3rd party app which converts it to typeB. The conversion never needs to get done more than once. So there's no need for files of typeA to ever appear in the Recently Used list. a GtkRecentManager is a GObject; you just connect to the changed signal, like you would on any other GObject instance. I guess what I'm asking is this Our app interacts with the file chooser dialog through an object of type Gtk::FileChooserButton (strictly speaking, that's a gtkmm object so maybe I'm posting on the wrong list anyway...) But the RecentManager object isn't a member of Gtk::FileChooserButton. It's a member of one of the panes that gets displayed when the resulting FileChooser dialog gets displayed after pressing the button. So what API calls do I need to eventually arrive at a pointer to the RecentManager object? It's a long way down the chain with several objects in between. From the Gtk::Filechooser button, I assume:- 1) I'd need to get a pointer to the FileChooser dialog. 2) I'd then (possibly) need to get a pointer to the relevant pane?? 3) I'd then (possibly) need to get a pointer to the 'Recently Used' list object?? 4) And ultimately I'd need to get a pointer to the Gtk::RecentManager object so I could add a changed handler Does that make sense or am I over-thinking all this?? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Thu, Jan 22, 2015 at 10:51:38PM +, Alberto Ruiz wrote: I agree with Paul here, GTK+ targets people who want to do desktop apps. I would actually try to sell all the new stuff for developers like the new introspection tool, the new widgets and some of the new CSS work with snippets. One purpose of the flyer that I had in mind is to explain what to learn for writing a GLib/GTK+ program, providing an overview. If people have never heard of GObject, they will look at some code and will be afraid of all the macros and other boilerplate code that they don't understand. The learning path for writing a GTK+ application should be: GLib - GObject (at least the basis) - a bit of GIO - and finally GTK+. All GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's important to explain what it is, at least briefly. Also, it's important to note that GObject was intentionally designed with bindings in mind. It's also a selling point for many people. In general, Linux users know what is GTK+. GLib, GObject and GIO on the other hand are less well known, but deserve more attention (e.g. for writing daemons, as explained in the brochure). For the images, there is already a GNOME flyer with some screenshots if I remember correctly, so in my opinion it's not really important to include lots of GTK+ screenshots (but one more image at the end could be better). Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject introspection for cairo
Il Thu, 22 Jan 2015 09:50:00 -0800 Jasper St. Pierre jstpie...@mecheye.net scrisse: Cairo-GObject provides access to enums, but it won't automatically get you great cairo bindings. It might actually get you 90% of the way there, though, and I'd be interested seeing how far you can run with just that, and be happy to merge patches that make it easier. Hi Jasper, I'm not arguing against developing glue code for cairo. In fact my specific problem is exactly a missing access to an enum type. My knowledge on bindings internals is limited, but I think exposing the GBoxed wrappers can also help the lifetime management of the underlying types, and I bet memory leaks are the n.1 problems in language bindings. Ciao. -- Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Thu, Jan 22, 2015 at 10:01:55PM +0100, Sébastien Wilmet wrote: https://github.com/swilmet/gtk-brochure https://people.gnome.org/~swilmet/gtk-brochure.pdf I've pushed an update. I've simplified the GObject section, and added a state diagram of the GLib event loop. An event loop and event-driven programming is not often taught at the university, so with a diagram readers will better memorize what it is. I've tried to add a screenshot of gnome-clocks, but the headerbar is barely visible, the image is too small. The flyer is more about presenting the lower-level stack. I think by explaining that GTK+ is to create applications with a graphical user interface, readers will understand what that means… If not, there is a GNOME flyer for users, as well as a demo computer on the stand to try GNOME 3. Sébastien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ brochure for FOSDEM
On Fri, Jan 23, 2015 at 10:06 AM, Sébastien Wilmet swil...@gnome.org wrote: On Thu, Jan 22, 2015 at 10:01:55PM +0100, Sébastien Wilmet wrote: https://github.com/swilmet/gtk-brochure https://people.gnome.org/~swilmet/gtk-brochure.pdf I've pushed an update. I've simplified the GObject section, and added a state diagram of the GLib event loop. An event loop and event-driven programming is not often taught at the university, so with a diagram readers will better memorize what it is. I'm not sure you can cover all potential interest in the g* stack with a single two-sided brochure. Nobody cares about GObject except: * die-hard C coders (who are neverthless open-minded enough to want to use an object model) * people working on the g* stack itself * people working on the internals of language bindings Event loop programming is simultaneously completely fundamental to all user-interactive software, and as such ought to require no introduction at all, but as you note it is (pathetically) lacking from the education experienced by many in the field. If you're going to draw an event loop then I think you want to capture something a bit less abstract than what you have. Events (keyboard,mouse,touch,network,serial,other data sources) = application response (computation, communication, request drawing changes) = redraw = REPEAT That's the actual useful event loop. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: recently-used.xbel
On Fri, 2015-01-23 at 11:55 +, John Emmas wrote: [snip] So what API calls do I need to eventually arrive at a pointer to the RecentManager object? [snip]: If you just call Gtk::RecentManager::get_default() (or gtk_recent_manager_get_default) instead of instantiating it yourself then you can get it anywhere you like. I don't know why gtk_recent_manager_new() even exists. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
