nanogui: Support for on-screen keyboard


Previous by date: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next by date: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Alex Holden
Previous in thread: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next in thread: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Alex Holden

Subject: Re: Support for on-screen keyboard
From: Vidar Hokstad ####@####.####
Date: 15 May 1999 19:47:56 -0000
Message-Id: <Pine.LNX.4.10.9905152124500.2715-100000@a.ncg.net>

On Sat, 15 May 1999, Alex Holden wrote:

> On Sat, 15 May 1999, Vidar Hokstad wrote:
> > I agree, when you consider "focus", as in which window receives events
> > etc. But for the on-screen keyboard there's other needs: It's important
> > that we get access to the id of the last window where the user actually
> > "activated" a widget. That's typically different from giving focus to
> > a window...
> 
> I don't see- how is it different? The last graphics active graphics
> context, in the click to activate mode, would be for the window containing
> the text widget you want to write into...

Yes, for click to activate. But the question was whether we'd want to
support other focus methods even for systems using an on-screen keyboard.
In which case, as I wrote above, activating a widget and giving focus to
a window would be two very distinct actions. Maybe it isn't necessary to
support for instance sloppy focus together with an on-screen keyboard, but
it's an issue to consider.
 
> > Low memory situations aren't the only ones: Devices where you _DON'T_ want
> > the user to see that it's really a full window system, and where they
> > aren't allowed to move/resize windows etc.
> 
> Regardless of the fact that I don't see why that would be desirable (why
> not let people have multiple windows, iconisation, etc. if they want it?),

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
one will be useful to the user at a time (even though it would be easy
to let them have all the apps active at a time, it wouldn't give any added
functionality). In addition, the main market is people who don't want a
"computer", to a large extent because of perceived complexity.

But there's lot of other cases too, where multiple windows simply isn't
desired in a user interface, but where having a windowing system at the
bottom would be a win for development. POS type applications, for
instance, where the user has a highly specific set of actions to do,
and where a full system with a window manager will only server to confuse.

> it would probably be better to still have a minimal window manager, but
> customized to present things the way that you want. How are you going to
> handle things like pop-up dialog boxes? They are windows too, but you
> don't want them using the whole screen.

Pop-up dialog boxes will always be presented centered over the window 
of the currently active application. No window manager needed for that.

> It'd be better if you had a very
> simple window manager which knew to draw dialog boxes at the requested
> size, with a border, in the centre of the screen, and allow you to focus
> on them by clicking on them (but possibly not allow it to go "behind" any
> full size windows), but knew to draw full screen windows without a border,
> etc.

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.

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).

As for drawing dialog boxes: They're only windows. No different than
any other windows. I don't need a window manager to draw a rectangle
around the outer limits of the window. And since the only applications
that will be allowed to generate pop-ups will have a fixed position on the
screen, placement of the pop-ups is hardly difficult.

Sure, I'd like a window manager too, because I'd love it for other
projects. But for my main project, I don't need one, and if there will be
some built in window management we can't turn off in NanoX, we will rip
that code out of the version we will be using. But I'd rather have a
switch to turn it off, than having to rip it out of each new version.


Previous by date: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next by date: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Alex Holden
Previous in thread: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Vidar Hokstad
Next in thread: 15 May 1999 19:47:56 -0000 Re: Support for on-screen keyboard, Alex Holden


Powered by ezmlm-browse 0.20.