meta/gui

[Sergio Schvezov]

El 16/03/16 a las 15:13, Gustavo Niemeyer escribió:
>
>
> On Wed, Mar 16, 2016 at 2:37 PM, Sergio Schvezov
> <sergio.schvezov at canonical.com <mailto: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?

+1 from me.