nanogui: Thread: re:

I agree that the window mgr should be modular, but if you want different window
managers, you might as well use X.   Actually, although it was a good idea,
the fact that X's design allowed for so much flexibility with differing looks and feels
contributed to Microsoft's taking over with their faster, more consistent gui...

The first version of nanoX that I write will definitely have some built-in window
management, in order to keep it small.  In my opinion, *all* of nanoX should be
kept small, so that it can be used where X can't.  Otherwise, why not just use X?

Greg

On Tuesday, May 11, 1999 1:20 AM, Alexander Peuchert ####@####.#### wrote:
> Hi Greg,
> 
> it really looks good, how the Nano-X improves. And it's really cool to
> see someone hacking enthusiasticly like you ... 8-)
> 
> Just my two cents:
> 
> As this thing is called Nano-X, it should stay nano. If you can keep up
> with a modular approach, this is okay, but please don't include features
> that aren't removable afterwards.
> 
> The windowmanager should be modular, too. For example one windowmanager
> for big displays with borders and titlebars, and one windowmanager for
> PDAs, where only one window stays in front.
> 
> In about 2 weeks I gonna start to do a toolkit upon this little thingy,
> except someone else has already started one ... ?
> 
> - alex
> 
> On Mon, 10 May 1999, Greg Haerr wrote:
> 
> > I completely agree with setting up the frame buffer device.  It's a pain in the ass.
> > 
> > I am looking for someone to write an svgalib driver for nanoX, now that it's
> > easy to add drivers.  This will allow nanoX to run on all those millions of Linux
> > systems that are still running < 2.2 kernels...  svgalib also supports mice.
> > 
> > I've got a long list of features too.  But nanoX is still **very** primitive.  I am
> > going to be writing a window manager soon, but I have some big API issues
> > that need to be discussed.  
> > 
> > Currently, I am concentrating on getting nanoX so that it can be readily
> > customized for multiple operating systems, with drivers easily added. 
> > The upper level api work will be next, as that gets into how we'll integrate a window
> > manager, and what the look-and-feel should be like.
> > 
> > I've been on an extreme coding binge, with no stopping yet planned...
> > 
> > Greg
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> > 
> 
> Alexander Peuchert
> ####@####.####
> http://www.peuchert.de ( not very interesting yet ;-) )
> 

On Tue, 11 May 1999, Greg Haerr wrote:

> I agree that the window mgr should be modular, but if you want different window
> managers, you might as well use X.   Actually, although it was a good idea,
> the fact that X's design allowed for so much flexibility with differing looks and feels
> contributed to Microsoft's taking over with their faster, more consistent gui...

Why not do the same as with the display "devices": Use a jump table. That
way it's a minor issue to add a compile time option for including
code that uses dlopen()/dlsym() to load an external module for those that
prefer that to linking in a window manager at compile time.
 
> The first version of nanoX that I write will definitely have some built-in window
> management, in order to keep it small.  In my opinion, *all* of nanoX should be
> kept small, so that it can be used where X can't.  Otherwise, why not just use X?

I agree..

Just one issue: Make sure the system still works fine without any window 
manager, the same way X does.

For our use, for instance, we don't want the windows to be movable or
resizable for the end user, and we don't want any visible borders
stealing screen real estate, and I suspect that to be valid for a fair
share of the PDA/set top box/webpad market.

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

On Tue, 11 May 1999, Vidar Hokstad wrote:

> On Tue, 11 May 1999, Greg Haerr wrote:
> >
> > The first version of nanoX that I write will definitely have some built-in window
> > management, in order to keep it small.  In my opinion, *all* of nanoX should be
> > kept small, so that it can be used where X can't.  Otherwise, why not just use X?
> 
> I agree..
> 
> Just one issue: Make sure the system still works fine without any window 
> manager, the same way X does.
> 
> For our use, for instance, we don't want the windows to be movable or
> resizable for the end user, and we don't want any visible borders
> stealing screen real estate, and I suspect that to be valid for a fair
> share of the PDA/set top box/webpad market.

  I agree with this as well, you want just a plan blah X server going that
is very small. The real Nano-X. Having window managers modular will give
Nano-X Scalability.  Vidar wants to use it on a PDA/Webpad, where I would
like to use it as a Linux Distribution Install since it will be much
smaller and faster than X.  So I would like to add at some point a nice
looking window manager.  Nano-X could become huge! But only if people want
to add a whole bunch of options to it for customization, but you can still
make it very small by just using the core.  Perfect for everyone.

-------------------------
Kevin Lindsay
Stormix Technologies Inc.

00 75 CB D4 20 AB 02 8B  2E 22 C0 E7 F3 9A 2D 72

On Tue, 11 May 1999, klindsay wrote:
>   I agree with this as well, you want just a plan blah X server going that
> is very small. The real Nano-X. Having window managers modular will give
> Nano-X Scalability.  Vidar wants to use it on a PDA/Webpad, where I would
> like to use it as a Linux Distribution Install since it will be much
> smaller and faster than X.  So I would like to add at some point a nice
> looking window manager.  Nano-X could become huge! But only if people want
> to add a whole bunch of options to it for customization, but you can still
> make it very small by just using the core.  Perfect for everyone.

That's right, a small but modular core server which lets you plug in
different WMs for different situations. It would be nice to have both WMs
which are scaled down to fit a palmtop's memory availability and screen
size, like EPOC, and ones with all the bells and whistles like 
Enlightenment and WindowMaker. I could see people moving away from X
entirely once it becomes stable, providing we have support for GTK+ (and
hence Gnome and Mozilla), and a decent Window Manager; I almost certainly
will myself.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Tue, 11 May 1999, Vidar Hokstad wrote:
> Why not do the same as with the display "devices": Use a jump table. That
> way it's a minor issue to add a compile time option for including
> code that uses dlopen()/dlsym() to load an external module for those that
> prefer that to linking in a window manager at compile time.

I agree that would be the best way to do it.

> Just one issue: Make sure the system still works fine without any window 
> manager, the same way X does.

Of course.

> For our use, for instance, we don't want the windows to be movable or
> resizable for the end user, and we don't want any visible borders
> stealing screen real estate, and I suspect that to be valid for a fair
> share of the PDA/set top box/webpad market.

Do you want no WM at all, or do you want a simple WM which always makes
the main windows full screen (but presumably not the dialog boxes), and
provides some means akin to alt-tab which lets you switch between them,
and a "menu" button which brings up a control panel?

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Tue, 11 May 1999, Greg Haerr wrote:
> I agree that the window mgr should be modular, but if you want different window
> managers, you might as well use X.   Actually, although it was a good idea,
> the fact that X's design allowed for so much flexibility with differing looks and feels
> contributed to Microsoft's taking over with their faster, more consistent gui...

That's only one side of the story. A lot of people (myself included)
_like) the fact that there are a million and one different window
managers, most of them extremely configurable (and more recently,
themeable), to play with. People keep saying that "users want the
interface to always look exactly the same so that they only need to learn
it once", but to me that's just plain boring. The fact that Motif is
non-free did the most damage, IMO. Only now with modern widget sets
like GTK+ can you really produce a _decent_ looking X app.

> The first version of nanoX that I write will definitely have some built-in window
> management, in order to keep it small.  In my opinion, *all* of nanoX should be
> kept small, so that it can be used where X can't.  Otherwise, why not just use X?

X is _really_ big and bloated. Just adding a versatile set of hooks to
Nano-X which allow you to link in a decent WM if you want isn't going to
cause a significant amount of bloat.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Tue, 11 May 1999, Alex Holden wrote:

> Do you want no WM at all, or do you want a simple WM which always makes
> the main windows full screen (but presumably not the dialog boxes), and
> provides some means akin to alt-tab which lets you switch between them,
> and a "menu" button which brings up a control panel?

No WM at all would be the best for us. We _do_ want multiple windows on
screen at the same time, but we want the software - not the user - to have
full control over movement, resizing, mapping and unmapping etc. For us,
having a windowing system instead of drawing on a raw framebuffer device
etc. is just a matter of convenience from a software development
standpoint - the user won't see much of it. Our device isn't really meant
to be perceived as a computer by the end user, but an appliance...

An "alt-tab" function would be great for more generic functions, but in
our case we'd have to disable it, as well as any menu buttons.

But by all means, any features that's easy to disable is a good feature
:-)

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

On Tuesday, May 11, 1999 3:58 PM, Alex Holden ####@####.#### wrote:
> On Tue, 11 May 1999, Greg Haerr wrote:
> > I agree that the window mgr should be modular, but if you want different window
> > managers, you might as well use X.   Actually, although it was a good idea,
> > the fact that X's design allowed for so much flexibility with differing looks and feels
> > contributed to Microsoft's taking over with their faster, more consistent gui...
> 
> That's only one side of the story. A lot of people (myself included)
> _like) the fact that there are a million and one different window
> managers, most of them extremely configurable (and more recently,
> themeable), to play with. People keep saying that "users want the
> interface to always look exactly the same so that they only need to learn
> it once", but to me that's just plain boring. The fact that Motif is
> non-free did the most damage, IMO. Only now with modern widget sets
> like GTK+ can you really produce a _decent_ looking X app.

	I agree.  Except that most of the work in writing window managers
(except for the expose event/z-order calculations, which is handled "internally"
in the X model) is writing all the code to draw the good-looking window frames, 
etc.

	But in the nano project, it's really a moot issue, since we're all in agreement
that at least the draw-code side of the window manager needs to be available as
a detachable api that would allow anyone to code their own look and feel, should
they really find the time and energy to do it.  I'm actually in favor, stated in another
email, that we don't get locked into *any* window management theology at the mid-level
api's for nanogui, so that the nanogui graphics engine could be used, for example,
for my nano-win32 project. ;-)

	In another email, I will propose a development track for nanoX v0.4:
separation and identification of this "mid-level" api from the user-level X-like
api's now present in nanoX.  By creating this api early, various folks on this
mailing list could start out feasability testing certain concepts, like whether
or not nanoX should/could support GDK directly, or whether it's built on top
of nanoX.  Getting more developers in the game will help us determine how much more work
the base nanogui graphics engine needs to support the "cool stuff."

Greg

> 
> > The first version of nanoX that I write will definitely have some built-in window
> > management, in order to keep it small.  In my opinion, *all* of nanoX should be
> > kept small, so that it can be used where X can't.  Otherwise, why not just use X?
> 
> X is _really_ big and bloated. Just adding a versatile set of hooks to
> Nano-X which allow you to link in a decent WM if you want isn't going to
> cause a significant amount of bloat.

	Agreed.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 

Alan, 
	In the middle of my sleep last night I finally realized what you are talking 
about, and you are right:  the hotspot doesn't matter, since it's not drawn.

	The problem is that the bogl libraries relocate the drawn cursor image
by offseting from the x,y hotspot, and I was then stating that the image drawing location
then was concerned with the hotspot.

	The correct answer is that no drawing routines should concern themselves
with the hotspot cursor location; this is not a draw issue, it's an intersection issue
for events, etc.  Thus, the bogl libraries should remove any hotspot offset adjustment
from the low-level bogl_pointer draw routine...
Greg

On Monday, May 10, 1999 12:34 PM, Greg Haerr ####@####.#### wrote:
> No, the hotspot is relative to the image itself.  The upper level routines
> don't check hotspot negative relativity before erasing the cursor.  
> 
> The cursor is always clipped if a graphics draw request intersects with the cursor.
> If there's no interesection, then you're right, it's not undrawn.
> 
> Greg
> 
> On Monday, May 10, 1999 12:00 PM, Alan Cox ####@####.#### wrote:
> > > 	Well, I understand that, except that with negative hotspot
> > > numbers, the graphics subsystem can't create proper "cursor clipping bounding
> > > boxes" for the mouse cursor.  In other words, when graphics output
> > 
> > Umm.. the hot spot doesnt matter surely. Your hot spot can be the other side
> > of your desk even, its not drawn so doesnt need clipping ?
> > 
> > The DOS port is funny btw. Maybe we will get Gtk for DOS next 8)
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> > 
> > 

Greg Haerr ####@####.#### writes:

	   The correct answer is that no drawing routines should concern themselves
   with the hotspot cursor location; this is not a draw issue, it's an intersection issue
   for events, etc.  Thus, the bogl libraries should remove any hotspot offset adjustment
   from the low-level bogl_pointer draw routine...

Okay, that shouldn't be a problem.  I guess you're right, it is a bit
of a layering violation, but it worked well with my BOML mouse
interface.  I'll make a change in newer versions.