Re: [Chicken-users] cross-platform gui toolkit

[Matthew Welland]

On Monday 05 February 2007 03:54, felix winkelmann wrote:
> On 2/5/07, Brandon J. Van Every <address@hidden> wrote:
> > > is smaller than 1-2 MB,
> > > provides text-editing (multiline), buttons, images, frames,
> > > checkboxes, and a couple more widgets, simple menus, then I'd be
> > > happy.
> > > FLTK could be the one, but is a bit flaky

Is FLTK flakey? I admit I haven't used it a heck of a lot but I've never 
noticed it being flakey. I have an agenda PDA and fltk was very responsive 
on it and it seemed quite reliable. In fact my much faster h2200 with Opie 
seems quite sluggish in comparison but I haven't done a side by side 
comparison.

In chicken bb + opengl seemed to work pretty well but a "canvas" equivalent 
opengl is not. How about bb + cairo + opengl as a starting foundation? I 
really like the idea of building as much as possible in scheme. I'd suggest 
going one step further and striving to keep the scheme portion not too 
chicken specific. Other schemes would only have to provide the interface 
layer and the bulk of the code could be reused.

Phase 1:

| bb | + | cairo | + | opengl |
-----------------------------------
schemish interface layer
-----------------------------------
scheme programs

Phase 2:
Add alternatives to the bb/cairo/opengl layer
gtk/qt/wxwidgets etc.

Phase 3:
Get the schemish interface layer accepted as an sfri

> > And there's actually something rock solid out there?  Chicken doesn't
> > even have automated nightly builds or testing suites.  "It has bugs"
> > especially is not a valid excuse in open source.  You can contribute
> > bugfixes and feature improvements to other communities.  It's a lot
> > more sane than NIH.

I'm working on a light weight personal version of the automated nightly 
builds and I'm hoping to start sending in bug/regression reports one of 
these days. Right now it stops on the errors pasted at the bottom of this 
message. It appears my system is not yet configured correctly to build 
chicken from scratch. Building from the tar ball works fine. I'm also 
running chicken builds in the familiar openembedded build system. I can 
provide my feed path to anyone interested. Not much I admit but we all do 
as much as we can :-)

> > There are reasons to decline other people's software though.  When I
> > look at OpenGL windowing toolkits, I decline the ones written in C++,
> > and the ones that don't have active communities.  There's just no value
> > in 1..3 guys barely getting anything done, almost never making
> > releases, and having a mailing list where crickets chirp.  CPW and GLFW
> > both have poachable C starter code, but that's about all.  I'm not
> > going to go try to save their communities.  The leadership and energy
> > simply isn't there.  We're better off building a community from scratch
> > here.
> >
> > In contrast, WxWidgets, Gtk+, and Qt all have vast communities, far
> > outstripping the size of our little Chicken enclave.  We're small time,
> > small potatoes, and pretty immature compared to them.  It would be
> > great to tap into their resources.  Unfortunately, they may be ossified
> > in their political goals.  I wouldn't bank on "smaller is better"
> > getting much play in those circles.
>
> Sure, but we do our best to improve the situation. I'm not disregarding
> wxWidgets, Qt, or anything. They are fine, for C++ programmers.
>
> In case we have a misunderstanding here: I don't want to write a GUI
> toolkit itself, I want to write a portability library (in Scheme) that is
> able to work with three or four C++ (or C in Gtk) different GUI toolkits,
> whatever is available.

To reiterate: I think this is a brilliant approach. I wish I had the skills 
and time to contribute. 

Matt
--

> cheers,
> felix
>
>
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users

R E S U L T S   F R O M   M Y   A U T O M A T E D   B U I L D
============================================
automake: configure.in: AC_ARG_PROGRAM must be used in `configure.in'
automake: Makefile.am: warning: automake does not support EXTRA_DIST being 
defined conditionally
automake: Makefile.am: warning: automake does not support SUFFIXES being 
defined conditionally
Makefile.am:211: invalid unused variable name: `chicken_static_LDFLAGS'
Makefile.am:209: invalid unused variable name: `chicken_static_SOURCES'
Makefile.am:219: invalid unused variable name: `csi_static_LDFLAGS'
Makefile.am:217: invalid unused variable name: `csi_static_SOURCES'
Makefile.am:210: invalid unused variable name: `chicken_static_LDADD'
Makefile.am:218: invalid unused variable name: `csi_static_LDADD'
+ autoconf
configure.in:9: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:46: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
configure.in:47: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.in:100: error: possibly undefined macro: AM_CONDITIONAL
./configure --prefix=/home/matt/chicken-test/localtestauto
./configure: line 1332: syntax error near unexpected token `1.8.3'
./configure: line 1332: `AM_INIT_AUTOMAKE(1.8.3)'
make BOOTSTRAP_PATH=/usr/local/bin
make: *** No targets specified and no makefile found.  Stop.
make install
make: *** No rule to make target `install'.  Stop.
CMake Error: This project requires version 2.4.5 of CMake.  You are running 
version 2.4.3.

-- Configuring done

Script done on Tue 30 Jan 2007 08:55:04 PM MST

-- 
http://www.kiatoa.com, a self-governing site where *you* can be the boss!
  You make and choose the stories and the classifieds are always free.
     Also, many "best of" polls. Come join in the ballot stuffing!