ubuntu-phone team mailing list archive

[Gerry Boland <gerry.boland@xxxxxxxxxxxxx>]

Hey,
reply inline

On 13/11/13 10:40, Thomas Voß wrote:
> On Wed, Nov 13, 2013 at 11:19 AM, Michael Zanetti
> <michael.zanetti@xxxxxxxxxxxxx> wrote:
>> On Wednesday 13 November 2013 10:01:24 you wrote:
>>> On Wed, Nov 13, 2013 at 9:30 AM, Michael Zanetti
>>>
>>> <michael.zanetti@xxxxxxxxxxxxx> wrote:
>>> Okay, let's clarify the problem "complexity" here:
>>>
>>>   (1.) We need to parse a very simple text file format that is well-spec'd.
>>>   (2.) Value types are constraint and well-defined:
>>> http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
>>>   (3.) Keys are simple strings that don't need further interpretation.
>>>
>>> Just parsing and validating this data, exposing well-known, default
>>> keys and making that accessible to any sort of toolkit is really
>>> simple. Please point out places where I'm oversimplifying the problem,
>>> but I think this is really simple to implement and expose via an API.
>>> A second step then would be toolkit-specific APIs, including toolkit
>>> specific types and so on. But that toolkit-specific API is a second
>>> layer from my POV.
>>
>> I'm not saying that this is a complex task. Still I think we don't need yet
>> another lib. And this would give a perfect chance to actually do what we tell
>> people we do: Collaborate with others.
>>
> 
> Oh, I'm totally aligned with that and I'm actually proposing to unify
> the parsing across toolkits as much as possible by means of a simple,
> well-tested low-level library that does exactly that.

We'd first need to see if the other toolkit developers would even want
this. GTK has its own solution, the one we rely upon today on the
desktop. Qt is a more OS agnostic toolkit, so I expect great resistance
to adding a linux-specific API. KDE as a result has written and
maintains its own. EFL probably has it's own. XFCE too. Why would they
change?

Can we write a lower-level library in a way that respects the toolkit's
existing API? Maybe we'd have to do it without C++11 support (or C
alone?). And then persuade the maintainers it won't introduce breakages.

This does not sound trivial, and frankly I think we've more important
things to do. There are more efficient ways to collaborate.


> 
>>>
>>> I do agree that we shouldn't pull in lots of
>>>
>>>> dependencies for this, but given that we use Qt in all the places we
>>>> consume it, makes it seem like a good idea to at least look at the
>>>> existing Qt implementations before coming up with something ourselves.
>>>
>>> Well, we need to consume desktop file entries from Vala, too, as per
>>> Gerry's list.
>>
<snip>
> One thing we have to keep in mind is that our ecosystem is not Qt/QML
> only, but also consists of HTML5/JS and Go is in the pipeline to
> become a first class citizen, too. On top, we need to make integration
> of different runtimes as easy as possible to ease porting of e.g. game
> engines. While I do agree that toolkit-specific APIs are required,
> too, we as platform maintainers need to make sure that different
> runtimes/toolkits can easily leverage our platform offerings. For
> that, I'm proposing a layered approach that offers a low-level
> reference implementation meant to be consumed by toolkits and
> runtimes.

I think we need to keep our requirements clear. For this particular
case, parsing desktop files is primarily a task for shell and process
supporting shell (lenses, upstart-app-launch). I cannot think of a
common use-case where an application would want such abilities.

As a result, let's just choose something that will work for our needs.

I'm not against diversity of toolkits, but we really need to focus on
having at least one good developer story, and not have several poor
options for a developer. And we need to target our resources to
executing that in the best way possible.

What worries me about this diversity discussion is the logical
conclusion: we will up with a huge mass of pure C/C++ libraries that we
have to write and maintain ourselves, and additionally we'll have
wrappers for Qt/Go/HTML+JS [1]. This would be a nightmare.
-G


[1] and I'm of the opinion that wrappers frequently are forced to mirror
the design of the low-level wrapped API upon the high-level API,
resulting in an API which does not respect the higher-level language's
design paradigm.