nanogui: Support for on-screen keyboard


Previous by date: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Alex Holden
Next by date: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Warner Losh
Previous in thread: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Alex Holden
Next in thread: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Warner Losh

Subject: Re: Support for on-screen keyboard
From: Vidar Hokstad ####@####.####
Date: 15 May 1999 21:22:55 -0000
Message-Id: <Pine.LNX.4.10.9905152252120.2715-100000@a.ncg.net>

On Sat, 15 May 1999, Alex Holden wrote:

> On Sat, 15 May 1999, Vidar Hokstad wrote:
> > Because it isn't meant to be see as, or treated as, a "computer" by the
> > consumer. It's an appliance. It has a fixed set of applications, and only
> 
> I'm afraid I'm just too much of a geek to wrap my brain around that
> concept. I would probably be trying to figure out how to reflash the ROM
> with something less restrictive within a few minutes of playing with it ;)

Hehe.. I'll probably leave some backdoor in, but most of the boxes will be
sold with subscriptions to misc. services etc., and will be heavily
subsidized, and for those boxes, stuff like that will be breach of
contract. It will be possible to buy it at full price too, though, and in
those cases hacking away will certainly be possible... We're considering
publishing all the needed hardware specs etc. for it too.

We might support overlapping windows etc. in an "advanced" version at a
later time, too, if there's enough interest for it.
 
> > I don't want full screen windows. We won't use that, ever. I want to open
> > windows of a specified size, a specified position, and be able to map,
> > unmap, resize, and change  z-order, and not have the user, nor a window 
> > manager, interfere with any of it.
> 
> What decides where these windows go, how big they are, and what depth
> they are placed at? Wouldn't it be better to use something which plugs
> into the server in the place of an ordinary window manager to do it?

A configuration file will specify positions etc., (off limits for users -
accessible for OEM's only. In theory :-)  and basically no windows
will ever overlap, except pop-up's, which are always placed above the
application window that's active. Which means that positions will be set
when the window is opened, and normally won't be changed (there are some
exceptions, but again, all sizes, positions etc. are known by the
application in question, and will never be changed by anything but the
application itself - there are no reasons to move it into a window
manager. Especially since the window manager would then need to have
specific information about all the applications, and would need to know
which client maps to which applications etc.
 
> > Essentially, I want it like it is now. Or the way X Windows is without
> > a window manager (which is essentially also how NanoX is now).
> 
> I see. You would need want some way for the applications to know what else
> is on the screen though, wouldn't you? Or is there only ever one
> application running, which of course knows what it is doing?

There will be multiple applications, but there will be two types: "normal"
user applications, which will all occupy the same space, and only one of
those windows will be mapped at any time, and misc. applications that will
be placed in fixed positions bordering the application window.

> Okay, so the way it will work is that there are just a few windows in
> fixed positions, which generate pop-ups within their pre-assigned space?

That's mostly it.
 
Regards,
Vidar


Previous by date: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Alex Holden
Next by date: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Warner Losh
Previous in thread: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Alex Holden
Next in thread: 15 May 1999 21:22:55 -0000 Re: Support for on-screen keyboard, Warner Losh


Powered by ezmlm-browse 0.20.