nanogui: Thread: nanogui widget set

Hi,

I would like to do / participate at a small widgets set for nanogui.
The purpose it to do simple Human machine interface... labels, button,
picture...
and so on...

I don't want to reinvent the wheel... so if there is somewhere a already
started project,
please tell me...

Bye & Regards

Seb
---
lem: http://linuxembedded.com

On Friday, June 11, 1999 8:43 AM, Sebastien HUET ####@####.#### wrote:
: Hi,
: 
: I would like to do / participate at a small widgets set for nanogui.
: The purpose it to do simple Human machine interface... labels, button,
: picture...
: and so on...
: 
: I don't want to reinvent the wheel... so if there is somewhere a already
: started project,
: please tell me...

I completed most of the work getting nano-X to support all of the mini-X api.
This includes support for monochrome bitmaps, rectangle draw and fill, line draw,
and rudimentary color support, which uses a fixed hardware palette.  There is
currently no implementation of a window manager, so windows can't be moved
or resized by the user, although all the api's are in place and work.  There is
considerable work required in implementing a window manager, as well
as an enhanced color model to support any pictures > 16 colors.  Support for
multiple fonts is also non-existent.  If you have custom widget implementations
of anything resembling a button, I'll look at it and tell you how much work
nano-X will require.

In the meantime, I've started working on another project, Micro-Windows.
Micro-Windows runs on top of the device-independent draw engine that I developed
for nano-X.  Micro-Windows currently sports a full-blown window manager, including
window captions, close boxes, user-moveable windows, and a 3d look-and-feel.
Micro-Windows supports full-blown 24-bit RGB color support with 256 color palettes.
256 color device-independent bitmaps, in 1, 4 and 8 bpp are implemented.  Conversion
programs for GIF and BMP files is included.  Micro-Windows supports child windows,
which are required for decent widget or custom control creation, in addition to 
support for any number of ROM or custom proportional fonts.  MS-Windows font
and BIOS ROM font conversion programs are written.

Micro-Windows is a re-implementation of the win32 api that looks almost exactly
like windows but runs in 50k.  I expect to have custom implementations of
button, radiobox, checkbox, picture, and textboxes in a couple weeks.

Greg

: 
: Bye & Regards
: 
: Seb
: ---
: lem: http://linuxembedded.com
: 
:

Greg,

Is it hard to port an already working widget set?
I looked on fltk, it's not big, has a very good gui designer and I just
liked it for X.

Bye,
-=Lajbi=--------------------------------------------------------------------
 LAJBER Zoltan           ####@####.####          http://jht.gau.hu/~lajbi
 GATE Jarmu- es Hotechnika Tanszek                        http://jht.gau.hu
 A member of HuLUG                           http://mlf.linux.rulez.org/mlf

On Friday, June 11, 1999 1:31 PM, Lajber Zoltan ####@####.#### wrote:
: Greg,
: 
: Is it hard to port an already working widget set?
: I looked on fltk, it's not big, has a very good gui designer and I just
: liked it for X.
:

I think the only way to go is to look at porting existing widget/custom control
sets.   The key is to start with a widget set that is fairly simple, and
doesn't use alot of the more sophisticated low-level draw/clip functions.

I'm not familiar with fltk, but I would suggest starting with it's button widget, 
and looking at exactly which Xlib-like calls it makes.  If you want, I'll help with
this if you send me the button source.

Another major consideration is which api the widget is running on top of.  For instance,
the nano-X (mini-X) engine implements a very basic (but suitable) set window-creation
and graphics draw primitives that are almost identical to their Xlib counterparts, but
with the names changed.  Perhaps nano-X should change the names to be 100% compatible.
That's the approach I've taken with Micro-Windows, but with the win32 api.  In any case,
a quick recompile of your fltk button widget, with all the X database stuff removed,
and all the X header files changed to a single "nano-X.h", would be the first step.

In regards to the gui designer, what is the output of this program?  Does it write
a resource file or output C code?  If its a resource file, its still too soon to use that
since none of that is implemented.  With Micro-Windows, I plan on implementing
resource-based dialog templates after I have the base set of controls running.

The other problem is that we could probably get a small implementation of button,
radio, checkbox and static controls, but when you add edit, listbox, and pop-down
listbox, the memory requirements get significantly larger.

Greg

On Fri, 11 Jun 1999, Greg Haerr wrote:

> I think the only way to go is to look at porting existing widget/custom control
> sets.   The key is to start with a widget set that is fairly simple, and
> doesn't use alot of the more sophisticated low-level draw/clip functions.

Well, fltk is _relatively_ small and simple. The lib is around 500k. It
run on X, OpenGL, and win32 api.
 
> Another major consideration is which api the widget is running on top of.  For instance,
> the nano-X (mini-X) engine implements a very basic (but suitable) set window-creation
> and graphics draw primitives that are almost identical to their Xlib counterparts, but
> with the names changed.  Perhaps nano-X should change the names to be 100% compatible.
> That's the approach I've taken with Micro-Windows, but with the win32 api.  In any case,
> a quick recompile of your fltk button widget, with all the X database stuff removed,
> and all the X header files changed to a single "nano-X.h", would be the first step.

I will try.
 
> In regards to the gui designer, what is the output of this program?  Does it write
> a resource file or output C code?  

C++ code, not bad at all.

The other way for me is to write a realy small widget set.
This oen should be not LGPL, but MPL. It seams I need it, becouse I going
to use touch screens, and the normal mouse-orinted widgets not well suited
to point by a finger.

Bye
-=Lajbi=--------------------------------------------------------------------
 LAJBER Zoltan           ####@####.####          http://jht.gau.hu/~lajbi
 GATE Jarmu- es Hotechnika Tanszek                        http://jht.gau.hu
 A member of HuLUG                           http://mlf.linux.rulez.org/mlf

On Friday, June 11, 1999 2:33 PM, Lajber Zoltan ####@####.#### wrote:
: On Fri, 11 Jun 1999, Greg Haerr wrote:
: 
: > I think the only way to go is to look at porting existing widget/custom control
: > sets.   The key is to start with a widget set that is fairly simple, and
: > doesn't use alot of the more sophisticated low-level draw/clip functions.
: 
: Well, fltk is _relatively_ small and simple. The lib is around 500k. It
: run on X, OpenGL, and win32 api.
:  

What I meant here is not what the fltk toolkit is ported to, but what api
the tools are written in.

On Fri, 11 Jun 1999, Greg Haerr wrote:

> What I meant here is not what the fltk toolkit is ported to, but what api
> the tools are written in.

Maybe I don't understand your question, sorry.

From the README file:
 Written directly atop Xlib (or the WIN32 API) for maximum speed, and
 carefully optimized for code size and performance. 
     
Precise low-level compatability between the X and Windows version
(only about 10% of the code is different). 

As I see: if nano-X drawing primitives named like counterparts in Xlib,
there is no need for porting ,just re-building.

For more about fltk: http://fltk.easysw.com/about.html

Bye,
-=Lajbi=--------------------------------------------------------------------
 LAJBER Zoltan           ####@####.####          http://jht.gau.hu/~lajbi
 GATE Jarmu- es Hotechnika Tanszek                        http://jht.gau.hu
 A member of HuLUG                           http://mlf.linux.rulez.org/mlf

On Fri, Jun 11, 1999 at 09:30:41PM +0200, Lajber Zoltan wrote:
> Greg,
> 
> Is it hard to port an already working widget set?
> I looked on fltk, it's not big, has a very good gui designer and I just
> liked it for X.

IMHO, besides being small, one very important thing we need to
look at is application availability OR programming ease.

Yes, I know most people want to use nanogui for embedded systems
ONLY. But restricting the project in this manner would probably
kill it. Perhaps one extremally small widget set AND one with
available apps (and I mean source code) would be the best way to
go, and would also make sure that the core system remains
flexible.

And the "very small" widget set should probably be easy to code
for; people don't want to spend weeks coding something this
specialized, IMHO.

[]s,
                                               |alo
                                               +----
--
      I am Lalo of deB-org. You will be freed.
                 Resistance is futile.

http://www.webcom.com/lalo      ####@####.####
                 pgp key in the web page

Debian GNU/Linux       --        http://www.debian.org

: >From the README file:
:  Written directly atop Xlib (or the WIN32 API) for maximum speed, and
:  carefully optimized for code size and performance. 
:      
: Precise low-level compatability between the X and Windows version
: (only about 10% of the code is different). 

That sounds good.  What you'll want to port is the library that
implements fltk on X.


: 
: As I see: if nano-X drawing primitives named like counterparts in Xlib,
: there is no need for porting ,just re-building.
: 

nano-X drawing primitives all start with GrXXX, Xlib uses X(XXX), so
there is definitely a need to rename the functions.

: IMHO, besides being small, one very important thing we need to
: look at is application availability OR programming ease.

I completely agree.  Few people these days will use graphical
systems that support "modern" user interface constructs, unless
of course it's being built for very custom purposes only.  In regards to
programming ease, I am extremely familiar with the win32 api, so
that's why I implemented it, so that I could code upper level custom controls
extremely rapidly.  I'm sure that there are a number of equivalent Xlib hackers, too.

: 
: Yes, I know most people want to use nanogui for embedded systems
: ONLY. But restricting the project in this manner would probably
: kill it. Perhaps one extremally small widget set AND one with
: available apps (and I mean source code) would be the best way to
: go, and would also make sure that the core system remains
: flexible.

	I want to build both, too.
: 
: And the "very small" widget set should probably be easy to code
: for; people don't want to spend weeks coding something this
: specialized, IMHO.
: 
	Yep, that's why I'm doing it, because most people don't enjoy coding buttons... ;-)