Re: GMenuModel has landed

[Tristan Van Berkom <tvb gnome org>]

On Tue, Dec 13, 2011 at 6:53 AM, Matthew Brush <mbrush codebrainz ca> wrote:
> On 12/12/2011 10:45 AM, Ryan Lortie wrote:
>>
>> On Sun, 2011-12-11 at 18:24 -0800, Matthew Brush wrote:
>>>
>>> My (probably misguided) opinion is that if this type of stuff can't go
>>> into GTK+ for some reason, there should be a `glib-ui` or `glib-gnome`
>>> library or something like this.  I have doubts how many apps linking to
>>> GIO without GTK+ are going to need such a model, either because they
>>> don't have a UI at all or are using some other toolkit which likely
>>> provides a mechanism of its own for this.
>>
>>
>> We had this conversation in context of GSettings, a few years ago.  It
>> wasn't really IO, so why should it go in GIO?  We threw around the idea
>> of libgplatform or libdesktop and so on and decided that we should just
>> treat libgio as this.  That's when we started (only half-jokingly)
>> insisting that GIO stands for "GLib Interfaces and Objects".
>>
>
> I think a separate G library would be an *excellent* idea, much more
> sensible and practical from a "consumer" (app developer) POV.  A quick scan
> through the API docs, I'd nominate the following to be moved to a separate
> library:
>
>  - Icons
>  - Settings
>  - Application support
>  - (the menu stuff)
>
> Everything else in there seems to be, even if not purely "IO", at least used
> by or in conjunction with the other stuff that is (I think).
>
>
>> I have a long-held belief that the "model" side of things that are not
>> directly related to widgets should be kept outside of the toolkit.  I'd
>> support, for example, a GtkTreeModel replacement to be merged into
>> libgio.
>>
>
> Yep, I certainly don't disagree with this either, just that it's strange to
> put this type of stuff in the IO library (IMO).  It feels like there's some
> stuff in the G stack that's looking for a home and everything just winds up
> in GIO, like it's a dumping ground for miscellaneous stuff (which I guess it
> is as you said, presently).
>
> I just fear people will start calling GIO "bloated" and GNOME-bound  and
> might cause people who would've otherwise used this excellent IO library to
> either re-write their own or look elsewhere.

I have to agree with Matthew to an extent, no people will probably not
rewrite their own versions of this code just because we eventually become
terribly disorganized, however they will notice the disorganization of the
stack and will become disgusted with it.

GMenuModel in itself is a little stuck, it depends on GActions which
are really tied into the whole DBus thing, so even though conceptually
it might not be IO, actually it is an IPC data model (I'm really starting
to think we should definitely remove the word "Menu" from that
data model, GActionModel or GModel even... and keep it low-level
generic, reusable and "sweet", not a specially targetted dinasaur just
for menus).

I would have to disagree about treemodel, data models, yes, would
be nice to push down the stack from way on top in GTK+, but why
not glib ? Of course I think the treemodel interface would have to
be re-engineered to reach our expectations of excellence before
being pushed all the way down to glib, but I think that would be
more appropriate than "dumping it into libgio just because".

GtkBuilder belongs in glib for instance, not in libgio.

Cheers,
           -Tristan