nanogui: Thread: GUILib for C

Hi!

There is a lib for C, which looks good and is relatively small:

http://www.cs.su.oz.au/~loki/graphapp/

The bad thing: It does need an additional widget set, like Xaw to run.

---
Martin

On Mon, 18 Dec 2000 ####@####.#### wrote:
> There is a lib for C, which looks good and is relatively small:
> http://www.cs.su.oz.au/~loki/graphapp/
> The bad thing: It does need an additional widget set, like Xaw to run.

Hmm, I think that's really more of a toolkit abstraction layer than a
toolkit itself.

Here's a cool idea: How about hacking something together from  
Enlightenment's built in toolkit? It's actually pretty small and clean,
and most of the X interface is already abstracted out into the functions
in x.c...

The only slight disadvantage is the BSD advertising clause.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

Instead of hacking an existing toolkit, would it really be tough to
start from scratch and design a lightweight and quality toolkit
exclusively for Nano-X that can be dropped in and used with little pain
and/or suffering?  I know there are alot of folks on this list that are
begging for things to do, and that would be a great way to help the
project, and learn about Nano-X at the same time.

That might be just as good as "hacking" in something else, plus we could
put a MPL on it to begin with and not have to deal with any other
licencing issues.

Jordan

  Alex Holden wrote:
> 
> On Mon, 18 Dec 2000 ####@####.#### wrote:
> > There is a lib for C, which looks good and is relatively small:
> > http://www.cs.su.oz.au/~loki/graphapp/
> > The bad thing: It does need an additional widget set, like Xaw to run.
> 
> Hmm, I think that's really more of a toolkit abstraction layer than a
> toolkit itself.
> 
> Here's a cool idea: How about hacking something together from
> Enlightenment's built in toolkit? It's actually pretty small and clean,
> and most of the X interface is already abstracted out into the functions
> in x.c...
> 
> The only slight disadvantage is the BSD advertising clause.
> 
> --
> ------- Alex Holden -------
> http://www.linuxhacker.org/
>  http://www.robogeeks.org/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Mon, 18 Dec 2000, Jordan Crouse wrote:
> Instead of hacking an existing toolkit, would it really be tough to
> start from scratch and design a lightweight and quality toolkit
> exclusively for Nano-X that can be dropped in and used with little pain
> and/or suffering?

Ok, the reason I've been hoping we could avoid this is that it takes a
lot of work to write a decent toolkit. If we do decide to go down this
route, the question is whether we should start from nanowidgets or abandon
it and start again from scratch.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

I know, I know, it goes against every Open Source inclination that I
have ever had too, but I mention this purely for the fact that Nano-X
has yet to have a toolkit that is designed specifically for it, and not
just something that we brought across from X.  I mean, we might as well
have written FLNX from scratch for all the work we have put into it
trying to get it to work with Nano-X.  It does take a ton of work to
design a decent toolkit, but will the ends justify the means?  I would
see most of the work being put into the design stage.  Once we are
beyond that, then we could add widgets in a modular fashion.  For
example, given a very specific framework, I could add a button widget
that I need, and then later on, if you needed a password entry field for
your authentication, then you could add it at your leisure.  The
important thing would be to design a very good framework that would make
this easy for all involved.  Really, its not tough to draw a button --
the tough part is designing it so that it fits into a grander scheme.

I don't know the state of the nanowidgets kit, but I would ask - Why was
it dropped?  Were they hard to use, or did nobody really care that much?

Unless you are working on new hardware or staring at the Nano-X engine 8
hours a day, it is hard to find your place as a contributor to this
project.  I would think that a new widget set would give development
opportunities to a whole new core of programmers that are interested in
helping, but having trouble finding a niche.  But then again, I have
been wrong many times in the past.  What do others think of this?

Jordan

Alex Holden wrote:
> 
> On Mon, 18 Dec 2000, Jordan Crouse wrote:
> > Instead of hacking an existing toolkit, would it really be tough to
> > start from scratch and design a lightweight and quality toolkit
> > exclusively for Nano-X that can be dropped in and used with little pain
> > and/or suffering?
> 
> Ok, the reason I've been hoping we could avoid this is that it takes a
> lot of work to write a decent toolkit. If we do decide to go down this
> route, the question is whether we should start from nanowidgets or abandon
> it and start again from scratch.
> 
> --
> ------- Alex Holden -------
> http://www.linuxhacker.org/
>  http://www.robogeeks.org/

On Mon, 18 Dec 2000, Jordan Crouse wrote:
> beyond that, then we could add widgets in a modular fashion.  For
> example, given a very specific framework, I could add a button widget

Yep, that's probably the nicest thing about nanowidgets- the extremely
lightweight C class framework. One thing it doesn't have which I would
like to see is dynamic positioning and resizing of widgets like Gtk+
ie. the application specifies the relative locations of the widgets, and
the toolkit decides exactly where to place them and how big they are. The
application doesn't have to worry about details like exactly how much
space a text field needs (which varies with the font used, so hard coding
it is a bad idea), or where to place it to get it exactly in the middle of
a window. If the user then resizes the window, it goes through resizing
and repositioning all the widgets automatically. When a widget gets a
resize event, if it's a container it passes the event on (possibly
modified) to it's children, and if it's not a container it redraws it's
contents at the new size. So in the case of standard widgets like text
fields, the application doesn't need to do anything at all when the when
the window is resized.

> this easy for all involved.  Really, its not tough to draw a button --

From my perspective, the hardest thing is making it look nice. What we
could do with is someone with some artistic ability :)

> I don't know the state of the nanowidgets kit, but I would ask - Why was
> it dropped?  Were they hard to use, or did nobody really care that much?

I think it's just that nobody has been working on it except for
Screenmedia. I'm not sure what the latest status is with regard to them
sending us their latest code. They said they were going to look into it,
but felt it unlikely that their managers would let them release it until
they actually release their product based on it (they regard the look and
feel of it a trade secret or something). Legally they're perfectly within
their rights to do this until they release a product which uses it.

> Unless you are working on new hardware or staring at the Nano-X engine 8
> hours a day, it is hard to find your place as a contributor to this
> project.  I would think that a new widget set would give development
> opportunities to a whole new core of programmers that are interested in
> helping, but having trouble finding a niche.  But then again, I have
> been wrong many times in the past.  What do others think of this?

Maybe. Perhaps if we get a basic working core and some demo apps in place,
people will come along and write the more complex widgets (file selector,
scrolling text window, canvas, etc.) for us...

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

On Mon, 18 Dec 2000, Alex Holden wrote:
> On Mon, 18 Dec 2000, Jordan Crouse wrote:
> > beyond that, then we could add widgets in a modular fashion.  For
> > example, given a very specific framework, I could add a button widget
> 
> Yep, that's probably the nicest thing about nanowidgets- the extremely
> lightweight C class framework.

After the first compile and run of demos w/nanowidgets, I wasn't able to
muster much enthusiasm.  At the time the toolset had more problems than it
does now (it dumped core if I blinked).  With all of its macro magic for
object-orientedness, after several hours of plotting out program flow I
sort of gave up trying to troubleshoot nanowidgets.

I expect those with C++ vocabs and mindsets have had an easier time.

But my $0.02 worth:  if a widget set is going to be created from scratch,
can we stick to C unions and structs and functions in implementing our
classes?

Or maybe this a personal preference sort of thing.  I have object-oriented
tendencies because I used to use java; and i know that object-oriented
programming in straight C doesn't require use of macros.


> > I don't know the state of the nanowidgets kit, but I would ask - Why was
> > it dropped?  Were they hard to use, or did nobody really care that much?
> 
> I think it's just that nobody has been working on it except for
> Screenmedia.

I was planning to use nanowidgets in my projects.  Wanted to, anyway, at
the outset.  I'd use the nanowidgets kit if it became reliable or at the
very least if could figure out how to troubleshoot it.  I haven't tried
lately, but I've noticed that the demos don't crash as easily as they used
to.


> > Unless you are working on new hardware or staring at the Nano-X engine 8
> > hours a day, it is hard to find your place as a contributor to this
> > project.  I would think that a new widget set would give development
> > opportunities to a whole new core of programmers that are interested in
> > helping, but having trouble finding a niche.  But then again, I have
> > been wrong many times in the past.  What do others think of this?
> 
> Maybe. Perhaps if we get a basic working core and some demo apps in place,
> people will come along and write the more complex widgets (file selector,
> scrolling text window, canvas, etc.) for us...

I'm interested in this.  I spend alot of time banging on Nano-X and RTEMS
in an embedded application, and since I'm under the gun I haven't been
putting too much energy into general apis.  But I'd be happy to start
doing that sort of thing, and I'll be able to contribute quite a bit after
the start of the new year.

-- Kaben Nanlohy

On Mon, 18 Dec 2000, Kaben Nanlohy wrote:
> After the first compile and run of demos w/nanowidgets, I wasn't able to
> muster much enthusiasm.  At the time the toolset had more problems than it
> does now (it dumped core if I blinked).  With all of its macro magic for
> object-orientedness, after several hours of plotting out program flow I
> sort of gave up trying to troubleshoot nanowidgets.

Ah, you spotted the obvious flaw- the reason the widget class stuff is so
clean and simple to use is because of the complex macros that do most of
the work for you behind the scenes, which can be a pain to debug if the
bug is in the macros...

> But my $0.02 worth:  if a widget set is going to be created from scratch,
> can we stick to C unions and structs and functions in implementing our
> classes?

It is based on structures and callbacks just like you'd expect; the macros
just hide the complexity from the programmer. My main complaint about them
is that it's not completely obvious how to use them and there isn't any
documentation, but it's actually quite elegant once you see how it works.
We could replace the macro generated object structures with explicitly
defined structures and replace the macros which do things like creating
and destroying objects, but it would require the programmer to write more
code. Swings and roundabouts. Remember the original C++ compiler was even
worse- instead of a few relatively simple C macros, it used a complex
preprocessor. Actually I think if I was to start again from scratch, I
probably would go the route of making things more explicit even though it
generates more work for the programmer, but that's just a personal
preference.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

The problem with a new toolkit is that using it requires knowledge of
a new API.  That is where embedded QT shines.

>>>>> "Jordan" == Jordan Crouse ####@####.#### writes:
    > Unless you are working on new hardware or staring at the Nano-X
    > engine 8 hours a day, it is hard to find your place as a
    > contributor to this project.  I would think that a new widget
    > set would give development opportunities to a whole new core of
    > programmers that are interested in helping, but having trouble
    > finding a niche.  But then again, I have been wrong many times
    > in the past.  What do others think of this?

+-------[ Nick Papadonis ]----------------------
| The problem with a new toolkit is that using it requires knowledge of
| a new API.  That is where embedded QT shines.

Assuming you already know embedded QT, and there's no interface layer.

-- 
Totally Holistic Enterprises Internet|  P:+61 7 3870 0066   | Andrew Milton
The Internet (Aust) Pty Ltd          |  F:+61 7 3870 4477   | 
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068    ####@####.####