nanogui: Thread: nanoWidgets


[<<] [<] Page 1 of 1 [>] [>>]
Subject: nanoWidgets
From: Greg Haerr ####@####.####
Date: 4 Oct 1999 17:40:21 -0000
Message-Id: <01BF0E5C.E2F37790.greg@censoft.com>

Vidar,
	I've integrated your changes into my last release, as you've read.
I also wanted to let you know the following changes after looking at your code:

	o GR_MODE_XOR should work now, it doesn't in older versions
of nano-X.

	o I made a change to set the default font to something quite a bit
skinnier for nano-X.  This will allow dialogs to look much better.  As a result,
your text field sizes are off.

	o Some of the widget_setfg/bg code, as well as GrNewWindow, was using
integers, rather than defines for color constants.  I had to make up values for "55",
which I don't understand.

	o I rather very painstakingly went through each and every file in
nano-X-0.5pre3 and compared it to the changes I've made since, and integrated
all changes (except dir and filename changes) into the tree.  The reason the
diff is so huge is that Alex changed almost every directory and filename.

	o I debugged all the GrXXX calls that are made over the network,
and found quite a few bugs.  All these are fixed in 0.84.

Greg

Subject: Re: nanoWidgets
From: "Vidar Hokstad" ####@####.####
Date: 4 Oct 1999 17:51:59 -0000
Message-Id: <19991004174802.15451.qmail@mail.relight.com>

On Mon, 4 Oct 1999 11:37:48 -0600 you wrote:
>Vidar, 
> 
>I've integrated your changes into my last release, as you've read. 
>I also wanted to let you know the following changes after looking at your 
>code: 
> 
> 
>o GR_MODE_XOR should work now, it doesn't in older versions 
>of nano-X. 

Great. That should clean up a lot of stuff.

Does text clipping work too? I seem to remember seeing something related
to that in your code. That was one of the big limitations.

>o I made a change to set the default font to something quite a bit 
>skinnier for nano-X.  This will allow dialogs to look much better.  As a result, 
>your text field sizes are off. 

Ok.. I'll take a look at it, and make an effort to do the calculations
correctly, so that they handle multiple font sizes this time :-) 
 
There's another issue with the textfields too: ESC isn't a good choice
to use as a special case for termination in the keyboard driver.....
Is that still in? I'd like to be able to handle cursor movement and
other escape sequences properly...

>o Some of the widget_setfg/bg code, as well as GrNewWindow, was using 
>integers, rather than defines for color constants.  I had to make up values 
>for "55", 
>which I don't understand. 

That's fine, none of those are meant to stay anyway :)

I'll integrate your changes with my code, and probably upload an updated
version tomorrow.

Regards,
Vidar
Subject: RE: nanoWidgets
From: Greg Haerr ####@####.####
Date: 4 Oct 1999 18:06:55 -0000
Message-Id: <01BF0E60.A1C6E8C0.greg@censoft.com>

: >o GR_MODE_XOR should work now, it doesn't in older versions 
: >of nano-X. 
: 
: Great. That should clean up a lot of stuff.

	Almost all the drivers that I've written now support XOR.  Let
me know if/when it doesn't work for you.  The OR and AND modes aren't
all implemented yet.




: 
: Does text clipping work too? I seem to remember seeing something related
: to that in your code. That was one of the big limitations.

	Text clipping works in windows, but I can't clip text with a clip
region other than the entire window clip region, yet.  But it's coming...  This
is part of a big "region" redo for when microwindows supports regions (even
just sets of rectangle implementations.)  Currently, the clip code
is all associated with a window.




: 
: >o I made a change to set the default font to something quite a bit 
: >skinnier for nano-X.  This will allow dialogs to look much better.  As a result, 
: >your text field sizes are off. 
: 
: Ok.. I'll take a look at it, and make an effort to do the calculations
: correctly, so that they handle multiple font sizes this time :-) 

Let me know if the font structure doesn't have enough info to correctly
position the text.



:  
: There's another issue with the textfields too: ESC isn't a good choice
: to use as a special case for termination in the keyboard driver.....
: Is that still in? I'd like to be able to handle cursor movement and
: other escape sequences properly...

	Funny!  When I first ran your nanoWidgets and saw the textfield
cursor, the first thing I did was hit an arrow key to move it, and of course
the program quit!  ha ha.  I think microwindows should handle the arrow key
processing... I suppose you want me to add that?  I seem to remember
some fancy code that knows the difference between ESC and ESC [ A.

Greg

Subject: RE: nanoWidgets
From: "Vidar Hokstad" ####@####.####
Date: 4 Oct 1999 18:26:29 -0000
Message-Id: <19991004182234.15584.qmail@mail.relight.com>

On Mon, 4 Oct 1999 12:04:37 -0600 you wrote:

>Text clipping works in windows, but I can't clip text with a clip 
>region other than the entire window clip region, yet.

Thats okey... The widgets use windows extensively, since they're as
lightweight as they are.

>Funny!  When I first ran your nanoWidgets and saw the textfield 
>cursor, the first thing I did was hit an arrow key to move it, and of course 
>the program quit!  ha ha.  I think microwindows should handle the arrow key 
>processing... I suppose you want me to add that?  I seem to remember 
>some fancy code that knows the difference between ESC and ESC [ A. 

Maybe... The ESC thingy should be possible to disable easily anyway... For
the applications I'll be using it for, being able stop the window system
is a no-no (at least for the "non-geek" version :-). And I already handle
it somewhat. It should probably be a lot better though. I'd like to see
input from more people on that.

I'm working on a listview widget now (to handle <select> tag's in HTML)
and when that's semi-working I'll take a look at what's required for a
good widget for <textarea>... That will of course require more extensive
text processing.

Vidar.
Subject: RE: nanoWidgets
From: Greg Haerr ####@####.####
Date: 4 Oct 1999 18:42:37 -0000
Message-Id: <01BF0E65.88DBB890.greg@censoft.com>

 Maybe... The ESC thingy should be possible to disable easily anyway... For
: the applications I'll be using it for, being able stop the window system
: is a no-no (at least for the "non-geek" version :-). And I already handle
: it somewhat. It should probably be a lot better though. I'd like to see
: input from more people on that.
: 
	ESC exit is only there now for developers.  I think perhaps
I should change it to ESC ESC.  That would allow support for arrow keys.
In an application release, of course, there should be no keystroke exit.
This can be accomplished with a "setup" api from the application to 
the server.

Greg
Subject: Re: nanoWidgets
From: "Bradley D. LaRonde" ####@####.####
Date: 4 Oct 1999 18:50:05 -0000
Message-Id: <026601bf0e98$4ea928f0$b8119526@ltc.com>

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Vidar Hokstad' ####@####.####
Cc: ####@####.####
Sent: Monday, October 04, 1999 2:39 PM
Subject: RE: nanoWidgets


> Maybe... The ESC thingy should be possible to disable easily anyway... For
> : the applications I'll be using it for, being able stop the window system
> : is a no-no (at least for the "non-geek" version :-). And I already
handle
> : it somewhat. It should probably be a lot better though. I'd like to see
> : input from more people on that.
> :
> ESC exit is only there now for developers.  I think perhaps
> I should change it to ESC ESC.  That would allow support for arrow keys.
> In an application release, of course, there should be no keystroke exit.
> This can be accomplished with a "setup" api from the application to
> the server.

FWIW, X uses Ctrl-Alt-Backspace.

Regards,
Brad

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.