meta/gui

[Gustavo Niemeyer]

On Wed, Mar 16, 2016 at 2:37 PM, Sergio Schvezov <
sergio.schvezov at canonical.com> wrote:

>
> El 16/03/16 a las 14:04, Gustavo Niemeyer escribió:
> >
> > [moving this thread to snappy-devel@ -- this is the best public forum we
> > have to discuss these implementation details with relevant parties]
> >
> > Thanks for opening that conversation up, Sergio.
> >
> > It's precisely the right moment for us to figure that one out, because
> > we need to talk about how we want the gadget and kernel snaps to really
> > look like, and the decision we make for gui may serve as good guidance
> > there.
> >
> > Regarding your dislike option 1, I feel like the distinction between
> > both approaches in those terms is too small as far as users is
> > concerned. Having to know about a specific file name in a specific
> > subdirectory is not much harder than having to know about a specific
> > yaml key under a specific yaml parent key. In fact, it's simpler IMO,
> > because that yaml key would point to a file path. So you need to know
> > the file path in addition to the yaml key anyway, and because we
> > wouldn't have an enforced convention for the file path, people would put
> > those files anywhere they please, making snaps look less alike than they
> > could otherwise.
>
> So my strategy so far was that you specify the artifact and snapcraft
> would make sure it goes to the right location. An icon regardless of
> where it pointed to would end up in `meta/gui/icon.<png|svg>`.
>

Right, that fits into what I covered above: the user needs to know about a
particular yaml key name and location, entering a local path by hand, which
will differ across snaps.

Having setup/gui/icon.png feels better all around.

Likewise for the config hook, which far from the simple snap examples we
> have built config hooks as use cases.
>
> > So my preference is in Option 1. Which moves us to the next question:
> > where to store it?
> >
> > My own real preference was ruled out a long time ago. I'd like to have
> > named parts/ as snap/parts/, so we'd have the snap/* namespace for that
> > sort of thing. But it's far too late to change that like this.
> >
> > It also feels unreasonable to pick up parts/gui/. It's way too close to
> > a normal part name, and it also establishes a precedent that we don't
> > want to continue using. Otherwise, once we need something else than
> > gui/, what do we do?  Pick another name there?  The end result won't be
> > pretty.. in the same namespace we'll have a mix up of real part names
> > and blacklisted names that are totally unlike parts. Ugh.
>
> My opinion about using `parts/gui` was just to follow suit with what is
> already a reserved path for local project plugins `parts/plugins`
>

That's slightly less awkward (slightly :), because parts/plugins is indeed
about the part plugins. I wouldn't take that as a good model to base other
features upon.

> So, here is an idea: in the last sprint we agreed to use the "setup/"
> > directory for snapcraft's benefit with the gadget snap.
> >
> > What if we establish that *known* content in setup/<path> ends up in the
> > snap's meta/<path>, as a more general convention?
> >
> > This solves the gui case (setup/gui/<app>.desktop), and opens
> > appropriate doors for the gadget and kernel snaps.
> >
> > Comments?
>
> I am ok with `setup/gui` but it also feels like many projects would use
> a `setup` directory (I say feels as I lack proper research). If no one
> is in nay, I will start a migration path towards this.
>

I don't recall seeing such a directory, but it's such a good name I
wouldn't be surprised something else is picking it up too. It's easy for us
to have an alternative path via snapcraft.yaml when this one is taken.

Let's go ahead then?


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160316/c21b78b1/attachment-0001.html>