Developing a core shell protocol

[Pekka Paalanen]

On Tue, 12 Feb 2013 08:51:26 +0100
Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

> On 11.02.2013 11:06, Pekka Paalanen wrote:
> > I want to make sure again, that when we talk about shells in Wayland,
> > we usually talk about public shell interfaces in the protocol. Therefore
> > all of Linux desktop, regardless of DE or its components (KDE, Gnome,
> > gnome-shell, kwin, ...) are under the one and same shell for desktops.
> > This is about the generic shell interfaces towards all applications, of
> > course, that can somehow make sense on any DE.
> 
> Not exactly. Android, Ubuntu and KDE publicly aim to work on all form
> factors. How will a desktop only wl_shell, as you outlined, serve those
> projects concepts?

I can imagine two choices there:

A. Have separate, form-factor based shell interfaces, that will make
applications adapt to the fullest for the form factor in use. Pro:
top usability and integration. Con: you actually have to implement each
shell interface in every compositor and toolkit (toolkit, not
application, as toolkits should be able to abstract the form factor
towards app code).

B. Just use wl_shell, the desktop shell interface, but try to adapt its
compositor side implementation to each form factor. Toolkits and
applications would not be directly aware of the form factor at all.
Pro: just one version of toolkit code needed, so all applications
will just work somehow. Con: usability might not be that
good, integration will suffer.

There's also the third option: A+B. If it makes some sense to run
desktop applications on the system of your choice, your compositor can
implement wl_shell in addition to the specific shell interface.
Applications written to support the specific form factor will use the
specific shell interface, and other will use wl_shell. All apps will
work, some better than others.

I agree with David Herrmann. Can you really write a good application
without caring about the form factor at all? Or is it possible to
abstract the form factor issues in the toolkit well enough, so that
application code would be completely form-factor independent?

The above is all my speculation. I have no idea how those projects aim
to achieve the goal of working on all form factors. Knowing how they
intend to implement it might help with our shell discussion. Do you
have any insight on what they are doing?

> To illustrate a bit: attaching a monitor or TV, keyboard and mouse to a
> phone is all what is needed for a desktop. That is long on the software
> agenda. The difference for phone, TV, desktop computers and so on is
> fading away quickly. These devices will more and more run on similar
> computer hardware and their CPU/GPU fits already in a USB stick.

Right, so this is about changing the form factor in flight, assuming
one does not want to restart applications or launch a completely new
instance of the DE. In that case I can see only option B as feasible.

I still think that we have not defined the scope of this discussion
well enough. The difference between a traditional desktop with a
keyboard and a mouse, and a touchscreen device with a virtual keyboard
as needed etc. is not that big, when compared to a TV/set-top box. And
like you said, the difference is only becoming smaller. What
differences do we have to care about in the end? What
differences actually matter to applications? Should this discussion be
limited to desktoppy devices and exclude others? Phone, TV and laptop
could all be desktoppy, if it makes sense.

Also, wl_shell interfaces are still in their infancy and need more
features even for the traditional desktop. It just might sensibly grow
to support all these different desktoppy scenarios. Afterall, the
obvious and naive approach is to just implement wl_shell on everything,
where you can install third party software.

Should we turn all devices into desktops hardwarewise, or work on the
devices' terms?

I'm afraid I lost the primary question. :-)


Thanks,
pq