newLISP release version 8.5.0

Started by Lutz, April 08, 2005, 12:08:46 PM

Previous topic - Next topic

Lutz

• many improvements and some bug fixes



for release notes 8.5.0 see http://newlisp.org/downloads/newLISP_85_Release_Notes.html">http://newlisp.org/downloads/newLISP_85 ... Notes.html">http://newlisp.org/downloads/newLISP_85_Release_Notes.html

for downloads see http://newlisp.org/index.cgi?page=Downloads">http://newlisp.org/index.cgi?page=Downloads

for documentation see http://newlisp.org/index.cgi?page=Documentation">http://newlisp.org/index.cgi?page=Documentation



Lutz

pjot

#1
The Slackware 10.1 installpackage for newLisp 8.5.0 has been accepted by Linuxpackages with an acceptance grade of 3 ('Excellent').



Direct link:



http://www.linuxpackages.net/pkg_details.php?id=6374">http://www.linuxpackages.net/pkg_details.php?id=6374



Greetz

Peter

Lutz

#2
Thankyou very much Peter!



And now ... who knows how to do Debian packages ;) ?



Meanwhile I am trying to iron out some issues with the TK part on the MacIntosh. Turns out there is Tcl/Tk Aqua on http://sourceforge.net/projects/tcltkaqua/">http://sourceforge.net/projects/tcltkaqua/ . It looks very nice but is a bit slower compared to the otherwise very speedy Mac graphics. But completely acceptable.



There are some issues though starting newlisp-tk, executing it as a Tcl script:



newlisp-tk



doesn't work and the TK-shell 'wish' comes back with error messages. But strangely doing:



wish /usr/bin/newlisp-tk



works fine, after fixing some other Mac specifics in newlisp-tk.tcl. I wonder who on this board is the Mac/TclTkAqua expert ;)



Lutz

newdep

#3
Hello Lutz,



I understand the Multi OS platform problem for the GUI choise, though

if you like to enhance TK then have a look at -> "http://www.tkzinc.org">www.tkzinc.org" TK

integrated with OpenGL.. Though there are a lot of choises with TK flavors

elswhere too.



The problem is to stay compatible with a GUI on more platforms,

I like the choise of TK but only because i programmed a lot in TCL

with TK over the last ten year.. But the choise for TK inside Newlisp

drives me back to direct coding in TCL instead of using newlisp.



To make newlisp special you need to make a choise and integrate

an engine inside newlisp that is able to talk to a Multi OS GUI. This engine

only provides the basics for GUI programming in newlisp, the REAL GUI

programming is done in newlisp-code itself (thats fun! and has far more advantages..) But nevertheless its a big step..



If i look at i.e. "Rep-lib" or "lib-rep" that is an integrated GTK with LISP

version.. Its outdated though..but the offset if good.. Integrated Lisp code for GUI's.



Another choise is to rewrite TK widgets into newlisp code..also a lot of work

to do by yourself..



So if the newlisp community is willing enough to spend time in newlisp-coding in some GUI format the only thing that is left is

the engine that starts it all from within newlisp ;-)





Greeting, Norman...
-- (define? (Cornflakes))

Lutz

#4
Yes it all depends, if it is possible to haved a minimal 'C' call-back interface which could be used to register call backs with GTK. I will look into it, but will only do it if it is possible with a minumum burden for newLISP and without the need to link additional libraries into the newLISP core product, because the main purpose of newLISP is still general scripting and programming.



Lutz

newdep

#5
I agree Lutz ;-) Take your time... and dont hesitate to ring the bell when you

need some input ;-)





Having a "make newlisp_gtk" on my linux machine would look good ;-)



Regards, Norman.
-- (define? (Cornflakes))

pjot

#6
Hm, I guess you need to link the newLisp binary with GTK anyway... otherwise registering callbacks never is possible, this is done with a GTK function. Maybe a separate makefile option can be created, like



make gtk



...which produces a newLisp binary with minimal GTK functionality (e.g. callbacks). The API to GTK-functions can be designed as a separate context (just like our current project X).



Anyways, for questions regarding GTK, please let me know, I am happy to help you out!



Peter

newdep

#7
Hello Lutz,



and when you put the following on top of the newlisp-tk.tcl code?



#!/usr/bin/sh

# the next line restarts using wish

exec wish "$0" "$@"





Norman.



PS: i assume you run MAC OS 10.x
-- (define? (Cornflakes))

pjot

#8
By the way: I just installed the Slack 10.1 package in a Slack 10.0 environment, and it works well.



So the newLisp 8.5.0 package for Slackware is compatible with Slackware 10.0 (and also 10.1 of course).



Peter

Lutz

#9
Thanks for wish-restart-trick, works wonderful. With that all Mac-newLISP-TcltkAqua problems are officially solved! Coming weekend we will have a 8.5.1, which installs on the Mac.



Is there some stuff in GTK-server which is interesting to look at for the callback interface? Is it possible to register always the same function for all widgets and then just filter and dispatch? This seems to be the way GTK-server works?



Lutz

newdep

#10
Hello Lutz,



Befor you start looking into GTK ;-) there are 2 intresting GUI toolkits

that have multi platform support. that is WxWindows (big) and FLTK

(Tiny).. For a newlisp GUI binding i think that FLTK is even more

intresting..





--- http://www.fltk.org">www.fltk.org ---

FLTK (pronounced "fulltick") is a cross-platform C++ GUI toolkit for UNIX®/Linux® (X11), Microsoft® Windows®, and MacOS® X. FLTK provides modern GUI functionality without the bloat and supports 3D graphics via OpenGL® and its built-in GLUT emulation.



FLTK is designed to be small and modular enough to be statically linked, but works fine as a shared library. FLTK also includes an excellent UI builder called FLUID that can be used to create applications in minutes.



FLTK is provided under the terms of the GNU Library Public License, Version 2 with exceptions that allow for static linking.

---



Norman.
-- (define? (Cornflakes))

Lutz

#11
FTK looks very interesting to me, it seems to work fine as a shared library, I wonder how the callback stuff works. Petere says with GTK you don't get away without having some callback function integrated into newLISP, which is what I don't like because other GUI libraroes can do without it. Look at SDL/openGL I did some stuff with it, just with normal 'import' functions in newLISP.



SDL keeps the event queue and you can call SDL_PollEvent to fetch event tokens. If FTK works a similar way than that could be the way to go. I love openGL based stuff, because openGL is 3D, fast and on every PLatform. Of course haviong FLUID is also a big plus.



But I still don't want to discard GTK, it is hugely popular for some reason, but there must be a way to keep the callback/event queue stuff out of newLISP. Perhaps a little stub library similar to SDL could be written, which keeps the event queue and call back function?



Lutz

pjot

#12
Well, it works like this:



The GTK-server reads a configfile, which contains GTK function definitions, and also a callback signal for each widget. For example, it reads the "clicked" signal for the GTK button widget.



During realization of each GTK function, the widget is connected to that signal using the GLIB function "g_signal_connect".



Now, each widget can listen to more than 1 signal. A GTK button for example, also can listen to the signal "enter". So when the mousepointer enters the button, a signal is created. The GTK-server also is able to connect more signals to 1 widget.



Also, a function is needed to realize a GTK function.



So 2 functions in newLisp would be sufficient: a callback function, and a realization function.



The problem with GTK is, that is uses callback functionality which cannot be put externally, other than with an extra binary (e.g. GTK-server like). Until 2.4 it has no event queue.



But maybe with the new 2.6 release there are new possibilities. I will investigate it.

pjot

#13
Quote
Perhaps a little stub library similar to SDL could be written, which keeps the event queue and call back function?

Well, this is the GTK-server concept! Hm... maybe I can rewrite it in a way that newLisp opens functions in this stub LIB. The STUB lib then, in it's turn, can realize the GTK functions, and keeps track of the callbacks, just like the GTK-server does right now.



NewLisp only has to import a couple of functions then, no need to change the source.



This can be done... I think. I'll puzzle with it after working time.



Peter

Lutz

#14
YES, that is the way SDL.so/dll works. It would make for a real tight integration fo newLISP and GTK-server. You could even GTK-server compile as shared library and have it all in there. There is nothing special in having callbacks in shared libraries or importing other shared libraries into shared libraries.



I liked FLTK but its documentation shows only C++ bindings and no way how to make a shared library for MinGW or Linux/Unix.



GTK may not be the latest, but I think it is so much more mature and the best supported and documented. It will probably not go away for a very long time and is still relatively small inspite of its advanced development stage. What also is convincing is, that the latest Bittorrent client on Win32 ships with GTK libraries similar configured to what you do with your Chat application, having all the GTK/Pango stuff in the installer.



I have no experience with GTK on MacOSX though.



Lutz