Museum

[pjot]

Yes, about 6 months ago the GTK port was still in progress. Also GTK2.2 was not very stable in itself. Right now, GTK2.4 has improved substantially; I use the GTK2.4 port myself. There are 2 strong and impressive Win32 applications using GTK2.4 now with good and stable results: The GIMP and Ethereal. But the MacIntosh platform still has no access to GTK2 as far as I know.

[newdep]

I think Newlisp should be here too --> http://glade.gnome.org/links.html">http://glade.gnome.org/links.html

:-)

[nigelbrown]

I looked at the GUI framework page :

http://www.geocities.com/SiliconValley/Vista/7184/guitool.html">http://www.geocities.com/SiliconValley/ ... itool.html">http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

again and saw

GraphAPP

that seems to have a straightforward C interface

see

http://enchantia.com/software/graphapp/">http://enchantia.com/software/graphapp/

which continues under active development, latest release:



GraphApp.3.tar.gz - Version 3 source code, portable fonts and extras.

1.6M Tar Gzip File, Latest Update 2004/05/08



This version of GraphApp will work on Linux, Unix or MS-Windows systems. Try the demo programs, imagine (image viewer), tester (event displayer), viewutf8 (show utf8 files), and blend (alpha-blending and image drawing). Many extras are included in this release, such as libPNG, libJPEG, libGIF, zLib and the GNU Unicode portable font. New versions of this file will be uploaded regularly.



An example C program looks straight forward:

/*

 *  clock.c

 *  -------

 *  Digital clock program written using GraphApp.

 *

 *  This is a complex example which demonstrates the use of

 *  timer functions, fonts, and windows. It also uses some

 *  standard C time functions.

 */



#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <time.h>

#include <graphapp.h>



App *app;

Window *the_window;

Font *the_font;

int state = 0; /* 0 = show the time, 1 = show the date */

int hour = -1, minute = -1;

int day = -1, month = -1;



char *month_name[] = {

   "", "January", "February", "March",

   "April", "May", "June",

   "July", "August", "September",

   "October", "November", "December"

};



void draw_clock(Window *w, Graphics *g)

{

   int width, height;

   char the_string[80];

   Rect r = get_window_area(w);



   if (state == 0)

      sprintf(the_string, "%d:%2.2d", hour, minute);

   else

      sprintf(the_string, "%d %3.3s", day, month_name[month]);

   set_font(g, the_font);

   width = font_width(the_font, the_string, strlen(the_string));

   height = font_height(the_font);

   draw_utf8(g, pt((r.width-width)/2, (r.height-height)/2),

      the_string, strlen(the_string));

}



void update_clock(Timer *unused)

{

   struct tm *the_time;

   time_t seconds;

   int newhour, newminute, newday, newmonth;



   tzset();

   time(&seconds);

   the_time = localtime(&seconds);



   newhour = the_time->tm_hour;

   if (newhour > 12)

      newhour -= 12;

   newminute = the_time->tm_min;



   newday = the_time->tm_mday;

   newmonth = the_time->tm_mon + 1;



   if ((hour != newhour) || (minute != newminute)

      || (day != newday) || (month != newmonth))

   {

      hour = newhour;

      minute = newminute;

      day = newday;

      month = newmonth;

      redraw_window(the_window);

   }

}



void handle_mouse(Window *w, int buttons, Point xy)

{

   if (buttons && !state) {

      state = 1;

      redraw_window(the_window);

   }

   else if (!buttons && state) {

      state = 0;

      redraw_window(the_window);

   }

}



void handle_key(Window *w, unsigned long key)

{

   if ((key == ESC)

    || (key == 'q')

    || (key == 'Q')

    || (key == 17))   /* ctrl-q */

      exit(0);

}



int main(int argc, char *argv[])

{

   app = new_app(argc, argv);

   the_font = new_font(app, "unifont", BOLD, 16);

   the_window = new_window(app,

         rect(3,3,font_width(the_font,"HH:MM.",6),18),

         "Clock", FLOATING);

   on_window_redraw(the_window, draw_clock);

   set_window_background(the_window, rgb(0x66,0x99,0xCC));

   on_window_key_down(the_window, handle_key);

   on_window_mouse_up(the_window, handle_mouse);

   on_window_mouse_down(the_window, handle_mouse);

   update_clock(NULL);

   show_window(the_window);

   new_timer(app, update_clock, 15000); /* 15 second timer */

   main_loop(app);

   return 0;

}

I'll try to line by line convert it to newlisp over the next week as a try out (like txt2pdf which is a line by line port) - if I can automate  interface generation to allow it to compile into newlisp and expose itself!! ??SWIG or a server/shared lib



Regards

Nigel

[pjot]

Well, I am curious how you are going to register your callback functions... I'll keep my eyes open on this thread!

[HPW]

>I always hoped somebody would do a new newLISP GUI on top of the current tcl/tk interface.



I find it not bad, and after some learning about Tcl/Tk and the newLISP integration, I think it is a powerfull combination. It is not only a GUI-toolkit, because it come with it's own language and a lot of ready made stuff. You can extend it in many ways using Tcl/Tk packages/megawidgets. And it is available on the wanted target platforms. Besides my neobook work, I find it a attraktiv enviroment for multiplatform.

[nigelbrown]

Perhaps we could come up with a super-generic layer that would be general enough to

usefully drive gtk-server, tk/tcl, and graphapp(or whatever compiled gui is settled on)?



What would people see as base-line functionality needed?



Perhaps-

Message box

scrollable, selectable, editable grid

buttons

radio buttons

edit box



(bit of a long base-line wish list perhaps?)



Nigel

[pjot]

Yes, well, something like that. But I fear that in the end people always want more. If you take XDialog as an example, it is quite flexible, but in the end, it *only* is able to create dialogs. This is also the problem with VB Script: a messagebox and inputbox are the only possibilities, it's not possible to setup a complicated GUI.



But the 'super-layer' seems a good idea to me, something like that already exists with wxWindows. It provides a generic API, while the graphical implementation (the 'backend') depends on the OS. However, wxWindows is a C++ framework, I'm not sure how it will integrate with newLisp.

[Lutz]

>>> But I fear that in the end people always want more.



That is why a 'generic' API could be a good idea, an API which is simple and smells like LISP, but thin and smart enough to allow the programmer to use all underlying functionality, I don't have a solution, but it should be possible somehow.



The basic principles are the same in all GUI APIs:



objects (widgets, buttons, scrollbars, text boxes, fonts etc)

properties (color, size etc)

events (click, double click, mouse down/up/drag/enter/exit , keyboard etc)

handlers (attached to events attached to objects)



could be some table driven thing, where you have the generic API on the left and then fill in the specifi API call to Tcl/Tk, mxWindows, GTK etc.



Lutz

[nigelbrown]

As Pjot suggested the callbacks will be a stumbling block. Perhaps a file nl-guicallback.c

will be needed that can be optionally compiled into newlisp. It could provide some

callbackable functions with parameter lists suited to their gui use - eg mouse callbacks,

window callbacks - when callback occurs they could push the call parameters

onto a designated newlisp list which in turn would be polled by newlisp programs to

monitor the gui. Events would be picked off the list and acted on.



An alternative to gui tailored parameter lists would be to have a selection of

functions of various parameter lengths that could be selected from as appropriate

- like the newlisp dlfnc code.



What's been your thoughts on callbacks Lutz?



Nigel

[Lutz]

This is where it gets hairy and the different GUI sets work different. Win32 calls *one* function and passes parameters to it identifyng the type of object and event which happened. You have to do all the rest, looking at the parameters passed and dispatch to the right (callback-) handler function. In the old newLISP I did this the way Nigel is suggesting it, pushing events on a fifo queue, where newLISP would fetch it from.



In GTK, I think, (haven't programmed it in C) you register the callback with the widget, the same you do in Tcl/Tk and I think this is the model most modern GUI APIs follow.



Generally speaking I don't want to put anything into newLISP, which gets too OS or API set specific. Its a slippery road of bloat and maintenance hell. For that reason newLISP was equipped with so many ways to communicate with it. I.e. in the case of GTK-server TCP or FIFO. That puts the burden to the GUI API side.



(dinner is ready, more later)



Lutz

[Lutz]

Having the language and GUI app separated and communicating via TCP has a lot going for it. You can have a distributed situation where newLISP lives on some super computer and the GUI frontend is on your desktop PC. It also separates two computing and software development tasks in a natural way. On one side the language-machine on the other the GUI. UNIX made a good decision when they built their OS the same way. The X windows system and the Os are loosely coupled via TCP and can live on different computers.



Unfortunately when they invented the browser they never thought of dynamic graphics and there are still only proprietary solutions (i.e. Macromedia Flash). I think the W3C has something in the works but the SW Industry seems not to be interested in standardized open solutions / protocols. Perhaps if Mozilla gains enough penetration, things will change. Proprietary GUI systems are one of the last borders to overcome for open protocols computing systems and tools.



Lutz

[adamss3]

It might be worth considering adding callbacks, which opens the door to "native" GUI support as well as having other processes call into newLISP.   It could be used for things other than GUI support.



But, the mechanism that was added should be general purpose and not tied specifically to GUI construction or to any specific OS.

[nigelbrown]

On the question of guis, perhaps rather than spend time on coding,

working on promoting the TCP interfacing with

more examples and beginner tutorials +/- an easy-peazy tcp-gui module

may be the better use of time?



Any thoughts?



Nigel

[pjot]

But the MacIntosh platform still has no access to GTK2 as far as I know.

It might be of interest to know that the GTK-server works on MacOSX. (I had to remove the URL from this posting since the author is not ready with publishing his site.)



Also today I learned that GTK-server can be compiled on Solaris, with some adjustments on the configure script. These adjustments will be available in the next release. The Linux, Windows and BSD platforms already were supported. Next to this I have received reports about successfull compilation on AMDx64 architectures.



So in case somebody wants to create multiplatform user interfaces with GTK and newLisp, it is possible now. ;-)



Peter

[pjot]

Hi,



Today GTK-server 2.0.6 has been released. The interesting thing for newLisp is that the GTK-server now can be compiled as a shared object or DLL. A newLisp script now can import the gtk function like this:

Code Select Expand


(import "gtk-server.so" "gtk")

(gtk "gtk_init NULL NULL")
(gtk "gtk_window 0")
...etc...


A complete demoscript with newLisp can be found in the sourcepackage.



Lutz: I also received instructions on how to compile with GTK2 on MacOSX, you can find these on my website at the documentation section. A screenshot with MacOSX can be found at http://leonardoce.interfree.it/gtkserver/index.html">http://leonardoce.interfree.it/gtkserver/index.html (posted earlier but the site is ready now).



Br,

Peter