Include directory structure, and installation packages
Daniel van Vugt
daniel.van.vugt at canonical.com
Wed Mar 27 03:16:56 UTC 2013
OK, a definition of "toolkit" with respect to client headers was given
on the hangout last night. That is anything intended to support
/toolkit/ ports (Qt, GTK etc).
It seems the confusion has arisen because "toolkit" in the client
headers is being used to encompass things that are not
"toolkit"-specific at all. That's what I would like to see fixed.
Firstly, it is possible and even desirable to write native Mir apps
without a "toolkit". Not just the examples we have now, but games are
great examples. The "game" use case is never going away, and hopefully
will arrive ASAP.
Secondly, "toolkit" is a broad word that could arguably be applied to
/any/ API or set of APIs. I would rather we used words that are better
at identifying the subject matter like "client" and "server". But there
must be others...
On 22/03/13 09:40, Daniel van Vugt wrote:
> I completely agree. Mir is a:
> (1) server library
> (2) client library
> so it should have:
> (1) server headers
> (2) client headers
> (3) /maybe/ common headers
> The word "toolkit" does not immediately or obviously come in there.
> "toolkit" to the wider English-speaking audience is a vague word that
> could mean many things with regards to software and libraries.
> If we're to use the word "toolkit" anywhere, can someone please define
> it for the rest of us?
> - Daniel
> On 22/03/13 05:43, Robert Ancell wrote:
>> I don't think the name of mir_toolkit is a side issue. We have two
>> external library interfaces. A client interface (libmirclient.so) and a
>> server interface (libmirserver.so). The names on the includes should
>> reflect that.
More information about the Mir-devel