All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sean Liming" <sean_liming@sjjmicro.com>
To: "'autif khan'" <autif.mlist@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: Building your own UI
Date: Wed, 8 Feb 2012 11:40:36 -0800	[thread overview]
Message-ID: <000601cce699$8883b720$998b2560$@sjjmicro.com> (raw)
In-Reply-To: <CADzUK1Ldn81UN8=BUf309k604eLeLpkpKneu7T9eOdA7dH9Jzg@mail.gmail.com>


>>> This may be a dumb question, but I'll ask anyway.
>>
>>> Suppose you have a project where you need a very custom user 
>>> interface. Not just a series of applications that appear on a 
>>> desktop like you see in sato, or Gnome, or KDE.  Basically your 
>>> application
> becomes the UI.
>>
>>> I can see 2 approaches to this:
>>
>>> Start with core-image-minimal and add the packages you need to 
>>> support GFX, X11, and your application plus dependencies.
>>> Take core-image-sato and change the applications to be your subtasks 
>>> , and the look-and-feel of the desktop.
>>
>>> What are the considerations of both approaches?
>> >Is one better, or easier than the other?
>> >How would you do this in Yocto?
>>> Where do you look for information you need to accomplish this?
>
>>We are still in the very early stages of architecture design and
>> development
>
>>For now we are leaning towards keeping everything that comes with
> >core-image-sato and writing a full screen app on top of it. Likely to 
> >be written in .NET (mono). A prototype (proof of concept) has been 
> >successfully developed :-)
>
>>As I said - still in very early stages of arch/design and dev. So 
>>things
> >may still change.
>
>
> >If it is okay to jump in an comment, I was going to ask the same 
> >question at some point.
>
> >The need to have the application as the main UI or shell to the system 
> >is important for branding. Launching sato or other desktop would not 
>> be desirable. As an example, Windows uses Explorer.exe as the shell, 
>> but can be replaced with any application. Windows was architected this 
>> way. It would be nice to have similar architecture here, but I know it 
> >is easier said than done. As you said this is early in design.

>We do have a lot of open questions that we will answer in good time:

>1) Should the application be executed as root or as some user or as nobody

>2) Should we trim the image? (we are not short on space or ram)

>3) Aforementioned - should the app run from inittab or rcS.d or something
else

>We will figure out these things when we are on that bridge.

>I do have a question - you have provided the example of Windows - where
explorer is the shell and can be changed. However, there is no argument here
- what are >the clear (no brainer) or subjective arguments for one versus
the other.

There are two reasons or user models: security and branding.

Using the Windows example. A system boots to Explorer desktop and then
launches an application. If someone can close the application and get to the
desktop, it is a security vulnerability someone could get into all sorts of
data and control panel settings.  By switching the application as the shell
(replacing explorer.exe) where the OEM has created a unique UI for the
device, it locks the system down. The custom shell can also provide controls
or back door access for administrative functions like display and network
settings. For Windows the devices boots to the Administrator account so the
application is not impeded from the system.

A custom UI helps with branding by creating a unique UI, the device has a
unique look and feel that tells the user this is a device and they have no
idea what is underneath. Launching Explorer and then the application doesn't
create the unique device look and feel.

Another method that OEMs do with Windows is to have a base shell launches
the main application. Again, the base shell replaces the  Explorer.exe with
something that is unique for the devices. If the main application needs to
be replaced, the main application can be shut down and the base shell still
provides some UI to perform the upgrade.

I am new to Linux embedded so I don't know how this would be architected.






  reply	other threads:[~2012-02-08 19:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-07 15:57 Building your own UI James Abernathy
2012-02-07 16:20 ` autif khan
2012-02-08  6:12   ` Sean Liming
2012-02-08 14:04     ` autif khan
2012-02-08 19:40       ` Sean Liming [this message]
2012-02-07 18:54 ` Joshua Lock
2012-02-07 21:54   ` jfabernathy
2012-02-08  0:47     ` Joshua Lock
2012-02-08 20:52       ` jfabernathy
2012-02-09  1:30         ` Joshua Lock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000601cce699$8883b720$998b2560$@sjjmicro.com' \
    --to=sean_liming@sjjmicro.com \
    --cc=autif.mlist@gmail.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.