Top-level package names, UX questions

[Sergio Schvezov]

El miércoles, 18 de marzo de 2015 18h'16:00 ART, Martin Albisetti escribió:
> On Mon, Mar 16, 2015 at 7:31 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:
>>
>>  * you can only install one foo at a time (choose foo.beuno or foo.jamie)
>>  * you must use it as foo.command
> 
> After talking to Alexander for a bit, I still feel this is the best
> trade off for the command line experience but broadening the view a
> bit to the phone and desktop, there's something worth thinking about
> as well.
> 
> In the command line, the commands are the UI. This works great, 
> feels snappy.
> However, in a GUI (webdm, touch, future desktop), you install apps by
> looking at titles, descriptions and icons. You will be, unless we make
> some changes, unaware of what an app's package name is. You don't care
> on GUIs where you see icons and names what a package's name is, you
> click on icons and titles.
> The proposal we have on the table pushes an awkward interaction there,
> where all GUIs will need to be aware of the fact that the same package
> name can be provided by many developers and you can only run one at a
> time. You'll essentially see 3 "calculator" apps, but 2 of them will
> have the same package name when a third doesn't. The result of
> installing one or the other, which all look alike, will be different
> (one will be co-runnable, the other will want to replace your current
> one). On the desktop it'll be even more awkward, as sometimes you'll
> use the command line, sometimes you'll install from the scope.

The ui, graphical and cli, need to make it clear that a switch will occur.

> I think if we felt this was the right path to go down, even in GUI
> scenarios, we could think about how to make sure developers understand
> that when they pick a package name, they are potentially becoming an
> alternative to an existing set of apps. I fear it might make things
> harder down the line for us, as we might end up with a dozen apps that
> are called "evolution", none of which we feel is the correct use of
> that package name, and we have to rename a dozen existing applications
> with a user base.
> 
> I can think of 2 paths to follow:
> 
> 1) Circle back to unique package names, drop developer extensions for
> them and have people create their own forks with a different package
> name "apache_beuno".
> 2) Allow running apps both by package name "apache.command" or full
> package name "apache.beuno.command", the latter used by GUIs and the
> former by humans from a command line
> 
> 1 feels cleaner from top to bottom, but it puts a bit too much
> emphasis on picking the right name from the beginning, going back to
> Gustavo's comment on "people should be able to pick an identifier
> without being concerned about future unintended conflicts".
> 2 I think addresses both sets of UIs, at the expense of a difference
> in behaviour if you switch from the GUI to the command line.

Option 2 has the problem of assuming binaries are independent, but they may 
depend on services from the same package.


-- 
Sent using Dekko from my Ubuntu device