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
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
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
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
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+,
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
