[meta-ti] [PATCH 1/3] matrix-gui-browser: port from arago overlay
Maupin, Chase
chase.maupin at ti.com
Fri Jan 27 07:19:58 PST 2012
> -----Original Message-----
> From: Philip Balister [mailto:philip at balister.org]
> Sent: Friday, January 27, 2012 8:54 AM
> To: Maupin, Chase
> Cc: Koen Kooi; meta-ti at yoctoproject.org
> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from
> arago overlay
>
> On 01/27/2012 08:50 AM, Maupin, Chase wrote:
> >> -----Original Message-----
> >> From: meta-ti-bounces at yoctoproject.org [mailto:meta-ti-
> >> bounces at yoctoproject.org] On Behalf Of Koen Kooi
> >> Sent: Friday, January 27, 2012 5:51 AM
> >> To: meta-ti at yoctoproject.org
> >> Subject: Re: [meta-ti] [PATCH 1/3] matrix-gui-browser: port from
> >> arago overlay
> >>
> >>
> >> Op 26 jan. 2012, om 23:44 heeft William Mills het volgende
> >> geschreven:
> >>
> >>> On 01/26/2012 01:46 PM, Chase Maupin wrote:
> >>>> * This package adds a simple web browser GUI application with
> >>>> no decorations used to display matrix on the local display.
> >>>> * Ported from arago overlay
> >>>>
> >>>
> >>> Sorry for hijacking your patch Chase but I have serious big
> >> picture questions about all this stuff going into meta-ti and
> >> especially all into one layer.
> >>>
> >>> meta-ti is suppose to be the TI specific stuff people need to
> >> support their platforms regardless of what layer stack they are
> >> using. I understand we are not layer stack independent yet but
> >> that needs to be the goal. Certainly adding a whole bunch of
> non-
> >> HW related stuff into the same layer is not going to move us any
> >> closer.
> >>>
> >>> When we talked about where matrix belonged before there was
> >> debate about meta-oe or meta-arago. When did I miss the memo
> that
> >> put it into meta-ti??
> >>
> >> Since meta-arago is supposed to be as empty as possible and
> matrix
> >> doesn't play well with others it's a bad fit for both meta-arago
> >> and meta-oe. Maybe we should split the meta-ti repo into 2
> layers:
> >> one for BSP things (including sgx, dsp, etc) and one for 'sdk'
> >> things (matrix).
> >> The idea is to keep reusable TI deliverables together without
> >> forcing people to use arago. Putting matrix in meta-arago would
> >> mean you can only use it with DISTRO=arago, which is a huge step
> >> backwards from the current situation.
> >
> > I think Koen got it right here. We can split meta-ti, but I
> definitely don’t think matrix belongs in meta-arago. As for meta-
> oe my thoughts are:
> >
> > 1. As of now matrix is only maintained by TI and used by TI (and
> Koen to some extent) on our products. So I would put this in a
> layer that we maintain because it would seem strange to me to have
> to go through another set of maintainers to update the SRCREV of
> the package we are developing. Particularly if no one is using it.
> > 2. If people wanted matrix they could still include our layer to
> get it. If we see that happening a lot a there is a request from a
> group of people to have this then we could push it lower, but if we
> are the only ones using it and who care about it then I don't see
> the reason to move this lower in the layer stack.
>
> What do the programs in question do?
Matrix is an application launcher that reads .desktop files and presents icons to the screen (or any remote browser) to launch the applications. We use it for our out-of-box demo to give customers an easy way to evaluate functionality on our devices. You can find out more at http://processors.wiki.ti.com/index.php/Matrix_Users_Guide
The .desktop files use some custom fields as well but we used standard fields where possible.
>
> Philip
>
>
> >
> >>
> >> regards,
> >>
> >> Koen
> >> _______________________________________________
> >> meta-ti mailing list
> >> meta-ti at yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-ti
> > _______________________________________________
> > meta-ti mailing list
> > meta-ti at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-ti
> >
More information about the meta-ti
mailing list