On tor, 2015-01-15 at 16:54 +0800, Cosimo Cecchi wrote:
> Thanks Alex for the explanation. Makes a lot more sense to me now.
>
> On Wed, Jan 14, 2015 at 6:27 PM, Alexander Larsson <[email protected]>
> wrote:
> * Some things are hard to build (glibc and other lowlevel
> stuff), others
> are just painful (webkit). Its very nice for app authors if
> they can
> just rely on this stuff and not have to build and bundle it
> themselves.
>
>
> I agree, but this lies ultimately in the definition of "the GNOME
> platform" (you can change "GNOME" with "KDE" or another platform
> applications can target).
> I would expect that the libraries that are declared as part of the
> platform to be present, regardless of how hard is it to build them.
In general I agree with you, but it depends a lot on what we consider
the "platform". I don't think everything that we ship e.g. in order to
build the full gnome desktop to be necessarily something that we want to
maintain long term for apps to use. Some things are just "internals" to
the desktop, and not something we want apps to use.
For instance, is telepathy in the platform? libchamplain? libwnck?
libgweather? I dunno. There are no obvious answers here.
> * Anything we add to the runtime has the potential to conflict
> with
> something bundled by the application (if it needs a different
> version).
>
> I've currently made the platform pretty minimal. For instance,
> it
> doesn't even have python or perl. I think we need to carefully
> consider
> anything more we add to it.
>
>
> I get your point, but I can see this becoming quite tricky: for
> example, why GJS and Vala and not Python? Ultimately I think the
> platform definition will need to include a set of bindings, together
> with the supported version(s) of the interpreters. I wouldn't find it
> practical e.g. for a python application to also bundle python together
> with the full pygobject bindings, especially because that might depend
> on a different version of gobject-introspection/glib/etc.
Yes, it is tricky. Vala is quite easy imho, as its a very small compiled
language, and thus it is only part of the sdk and not the platform
runtime. Gjs I added for two reasons. First of all we've selected it to
be some kind of recommended language for gnome, and secondly because it
is quite minimal in the sense that it doesn't pull in a huge set of
dependencies, modules, etc.
Python for instance is a lot trickier. First of all you need to pick a
particular major version of it. Then the minor version you pick might
not be good enough for the app, causing the platform one to conflict
with the runtime one (painful, but can be handled in the app). Then you
also have to pick which parts of the python standard library (and
dependencies) you want to include. It will be kind of large, and in some
aspects duplicate things with the gnome based platform we want to
support.
However, I'm not really against python, i think the line we draw should
probably be on the side of including python3 (but not python2). Its a
tricky line though. Which other gnome bindings to we want to
"support"...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[email protected] [email protected]
He's an immortal Catholic dwarf in a wheelchair. She's a man-hating
motormouth museum curator from a secret island of warrior women. They
fight crime!
_______________________________________________
gnome-os-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-os-list
