On Thu, Jan 15, 2015 at 5:15 PM, Alexander Larsson <[email protected]> wrote:
> > 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. > Yes, we definitely need to become more formal about this definition in the context of GNOME. FWIW, jhbuild has currently a distinction between "gnome-devel-platform" and "gnome-extended-devel-platform" [1], even though they don't look particularly curated. It's of course better to start small and then expand rather than the opposite, but without getting into the specifics too much, the example of Telepathy is something I would include in the platform, since from the client perspective it's convenient to have one contact store managed by the OS and one defined API to access it; it also makes it possible to have a "contacts" kind of permission in the sandbox. 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"... I personally think only four are currently worth including: gjs, vala, python and gtkmm. With regards to python, I tend to agree with you on where the line should be drawn, even though I am not an expert on the details of its standard library; in general I think it would be an interesting exercise to put together a minimal build with whatever is necessary to get pygobject running. Note that I believe python is a direct dependency for gobject-introspection to be able to build an introspected library, which some applications will want to do. [1] https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-3.16.modules#n1177 Cosimo
_______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
