meta/gui

[Sergio Schvezov]

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>`.

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`

> 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.

Thanks for your input!