nanogui: Thread: nano-X 0.6

: 
: I thought Nano-win was going to be a widget set implemented on top of
: Nano-X too. It at least wants to be optional.
:
	Yes - this is very important.  Any custom window or widget implementations
must run on top of the mini-x (or win32) api, and be placed in separate files, without
access to any internal data structures.  In that way, it's all optional.

On Wednesday, June 23, 1999 11:15 AM, Alex Holden ####@####.#### wrote:
: On Wed, 23 Jun 1999, Greg Haerr wrote:
: > 	Attached is my latest cut of nano-X.  This includes all the fixes
: 
: I grabbed it from the ftp site and was about to mail you to say I'd got it 
: immediately before I recieved this mail ;)
: 
: > up through yesterday for compiling and running under ELKS.  You might
: > want to post this file unchanged under nano-X.0.61gh.tar.gz, as well
: > as of course work on integrating it into your changes.
: 
: How about if you put that and other things like it in some directory on
: your server, and I'll set up a cron job to mirror it every night to
: ftp.linuxhacker.org/pub/microwindows/ ? I'm going to stay late tonight,
: get the CVS set up, and start integrating it.
: 
: > uses, and we need to think about whether we want that or not.  The RGB
: > color model mods are included in the version that I've posted with the
: > micro-windows project, however.
: 
: Yes, I'm not really sure what to do about the colours. There seem to be
: two main possible ways:
: * The clients ask the server how many bits of colour depth the display has
: and thenceforth simply supply the relevant sized colour words.
: * The clients always talk RGB and the server converts it to whatever it is
: using at the time.
: The first one makes the server more lightweight, and slightly reduces the
: network bandwidth if you're running the server in a low bit depth, but the
: client or widget set has to be more complex. X seems to use a much more
: complex model where an application can request different colour maps and
: things, but I don't think we want to support that level of complexity.
: 
: > 	I would also like your comments as to the look and feel of microwindows.
: > Why don't you download it and try it out.  It runs on cfb8 framebuffer, so you
: > shouldn't have any problems...
: 
: I did download it, and I did have problems. It appears to clear
: about 3/4 of the screen to black, and then segfaults (in a memset()
: operation, I'm not quite sure where because GDB wouldn't behave). I'm
: running an 8bpp framebuffer, and tried various screen sizes between
: 640x480 and 1600x1200. I haven't tried your Nano-X yet to see whether the
: problem is in there or in microwindows, I'll do that later tonight. Also,
: I had to change the bit in graph3d.h where you include tgmath.h instead
: of math.h on *nix systems (math.h is fine on every Linux system I've
: worked with, but I've never seen a tgmath.h).
: 

Does anybody have any input as to libc changes lately for Linux?

My system has tgmath.h which defines sin() and cos().  math.h 
doesn't define them.

Other systems have math.h that define sin() and cos().

My 3d graphics package for micro-windows requires trig functions,
but it appears that the headers are changing....

On Wed, 23 Jun 1999, Greg Haerr wrote:
> 	Sure, if you want to mirrow the Micro-Windows download area,
> use microwindows.censoft.com/pub/microwindows.

Done.

ftp:// or http://(www.,ftp.,)linuxhacker.org/pub/microwindows/

is a nightly mirror of microwindows.censoft.com/pub/microwindows.
It's a non-deleting mirror, ie. if all the files on
microwindows.censoft.com accidentally got nuked, linuxhacker wouldn't
also delete them at the next sync.

> 	I think that the RGB model is the way to go.  Check it out in Micro-windows.

I think you're right about that.

> 	I didn't include the RGB model in your nano-X distribution because of
> tons of changes, on top of other changes.  In addition, I've been thinking that nano-X
> probably should become completely X-compliant in the api's that it provides,
> much like micro-windows does for win32.  In this way, It's actually a mini-replacement
> for X.

I'm not sure about that, X is Pretty Damn Big. Several things in it are
much more complicated than we want, and some are not the ideal model for
what we want either (eg. the seperate font server instead of a simple bit
of code in the server which can load font files from a fixed directory).

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

 
: I'm not sure about that, X is Pretty Damn Big. Several things in it are
: much more complicated than we want, and some are not the ideal model for
: what we want either (eg. the seperate font server instead of a simple bit
: of code in the server which can load font files from a fixed directory).
: 

	I'm saying that for as many items as possible, it might
be nice if the api were identical.  In that way, widget sets can be converted
from X to nano-X with less effort.

	This is the same problem I'm solving with micro-windows.  For instance,
I'm working with the Wine group to accomplish two things:  one, porting
of their entire control set (button, radio, checkbox, scrollbar, combo, listbox, and edit)
to run on top of micro-windows.  Believe me, you don't really want to rewrite
everything from scratch.  Two, making Wine run on top of Micro-Windows'
graphics engine and framebuffer device.  This would allow running windows programs
thru wine without X, if desired.

On Wed, 23 Jun 1999, Greg Haerr wrote:
> : I did download it, and I did have problems. It appears to clear
> 	Are you running the vga16 framebuffer as well?  You might "undo" 

I just tried microwindows 0.81 and it worked first time (apart from the
math.h thing). I don't know what changed to make it work, but it's pretty
impressive.

A few points:

* Giving focus to a window doesn't bring it to the top, which means that
the height placement rules are effectively hard wired because the
depth of a window never changes.
* The redrawing algorithm is so slow (seconds on a Pentium 150, presumably
minutes on an 8088) that the current window movement algorithm isn't
really ideal (ie. it looks ugly when you grab a window and move it around
and it leaves trails which take a second to disappear). The "slow window
move algorithm" seems to be  faster than the "fast window move algorithm"
and doesn't leave as many ugly trails.
* It would look better (and possibly be more efficient, depending on how
you implement it) if the drawing of windows was Z sorted from back to
front, instead of just basing the clipping on Z order (at the moment, the 
background is drawn last, which doesn't look very nice).
* The 3D app revealed another problem with the "client compiled into the
server" model that I hadn't thought of before- if a client wants to use
100% of the processor time, the server doesn't have any chance to do
things like moving the mouse until the client asks the server to do
something. This reveals this in the very wierd mouse movement behaviour
over the 3D window, as the server can only move the mouse whenever the
application does enough processing to ask it to draw another frame.
* The animated buttons don't seem to look quite right (the bottom and
right hand sides of the button should move too, right?).
* It looks and behaves almost exactly like Windows (a bad thing in my book ;).

Are you planning to announce it on Freshmeat now or wait until more it's 
more advanced first (or do you want me to do it for you)?

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

: I just tried microwindows 0.81 and it worked first time (apart from the
: math.h thing). I don't know what changed to make it work, but it's pretty
: impressive.
	I've fixed the math.h problem for the next cut.


: 
: A few points:
: 
: * Giving focus to a window doesn't bring it to the top, which means that
: the height placement rules are effectively hard wired because the
: depth of a window never changes.

	I've got that coded temporarliy for now.  I wanted to test the window
move algorithm when painting low-zorder windows.  Mousedown on the 
non-caption are to bring it to top.  (this is a one line change in windefw.c)


: * The redrawing algorithm is so slow (seconds on a Pentium 150, presumably
: minutes on an 8088) that the current window movement algorithm isn't
: really ideal (ie. it looks ugly when you grab a window and move it around
: and it leaves trails which take a second to disappear). The "slow window
: move algorithm" seems to be  faster than the "fast window move algorithm"
: and doesn't leave as many ugly trails.

	The current algo is close to MS's for faster machine window repaint.
I'll write one that draws an XOR frame and it'll appear far better on slower
machines.



: * It would look better (and possibly be more efficient, depending on how
: you implement it) if the drawing of windows was Z sorted from back to
: front, instead of just basing the clipping on Z order (at the moment, the 
: background is drawn last, which doesn't look very nice).

	Yes, I agree.  Again, I was just trying to get the dang thing out.
This whole thing was written at home over the last two weeks.  My next
plan is to start optimizing.  In another email I noted that what I really
need is update regions, and then only the portion that's effected is redrawn,
unlike now, where everything gets redrawn.  (the wallpaper flicker
is ugly, I agree.)

	Also, when I implement off-screen drawing, the desktop window
can avoid the background flicker that you see now.  Another way is to
add application-level clipping, so that it could clip the background erase
to the not-intersection of the background wallpaper.  That's coming too..



: * The 3D app revealed another problem with the "client compiled into the
: server" model that I hadn't thought of before- if a client wants to use
: 100% of the processor time, the server doesn't have any chance to do
: things like moving the mouse until the client asks the server to do
: something. This reveals this in the very wierd mouse movement behaviour
: over the 3D window, as the server can only move the mouse whenever the
: application does enough processing to ask it to draw another frame.

	Humm.  Let's keep thinking about this.  This will become
a bigger issue on slower machines, also.


: * The animated buttons don't seem to look quite right (the bottom and
: right hand sides of the button should move too, right?).


	Not in the MS model ;-)  That button is 100% MS compatible....
I'm not suggesting that that's the only button, though, but I wanted to write
at least one 3d custom control.



: * It looks and behaves almost exactly like Windows (a bad thing in my book ;).

	That's because it's "*Micro-Windows*" !!  All the look
and feel is in one file, windefw.c, the default window proc.  I am looking
forward to other look-and-feels.  I'll explain a little more how, later.



: 
: Are you planning to announce it on Freshmeat now or wait until more it's 
: more advanced first (or do you want me to do it for you)?
: 

	I'd like to announce it as soon as I have a web page/server.  Thanks
for thinking about it though.

Greg