GTK2 has been ported to MacOS X

[pjot]

All,



Now also the Mac is able to run GTK applications. The GTK port does not require an additional X-server, but completely depends on Quartz.



Website: http://gtk-osx.sourceforge.net/">http://gtk-osx.sourceforge.net/



Further notes can be found here:



http://developer.imendio.com/projects/gtk-macosx">http://developer.imendio.com/projects/gtk-macosx





It opens the possibility for newLisp to run GTK user interfaces on MacOSX also :-)



Regards

Peter

[newdep]

Pjot... Perhpas you need to post a small example of GTK-Server inhere...Because you changed a lot to the code last year...

..So people can see how easy it is dies days to use it...



*** spam spam spam *** ;-)

[pjot]

Well, you are right. Currently I am porting the GTK-server to MacOSX. Most of the stuff is running already as you can see from the screenshot below :-)



http://www.turtle.dds.nl/newlisp/forum/GTK_on_OSX.jpg">





The schreenshot shows two genuine newLisp programs!



I hope to release a DMG package soon!



Cheers

[Lutz]

Currently I am porting the GTK-server to MacOSX.

That is great news. There also was a rumor some time ago, that Apple would include the GTK framwork in the normal factory install of OSX, just like Java and X-Windows today. That would make it really easy to develop apps which work on both, OSX and Linux (and many other Unix) out of the box without the need to install anything.

[pjot]

There also was a rumor some time ago, that Apple would include the GTK framework in the normal factory install of OSX

That would be nice indeed! The installbase of GTK is quite small compared to Java or wxWidgets which is an advantage.



The major work for GTK-server and MacOSX has been done, MacOSX will be supported from now on. All my GTK apps with newLisp are working fine, including the excellent Comic Book Reader :-)



The package already can be downloaded at the beta section, but as no major stuff is pending it will be released next week as stable (after finalizing the tests on other platforms).



Peter

[pjot]

Besides, newLisp does not need GTK-server anyway.

Code Select Expand


#!/usr/bin/newlisp
#
# DirectGTK using (callback).
#
# PvE, january 2009. No need for GTK-server.
#
#----------------------------------------------------------------------------------------------

# Define libraries for each platform
(case ostype
    ("Win32"
(set 'GTK "libgtk-win32-2.0-0.dll")
(set 'GOBJECT "libgobject-2.0-0.dll")
    ("OSX"
(set 'GTK "/Library/Frameworks/Gtk.framework/Libraries/libgtk-quartz-2.0.0.dylib"))
(set 'GOBJECT "/Library/Frameworks/GLib.framework/Libraries/libgobject-2.0.0.dylib"))
    (true
(set 'GTK "libgtk-x11-2.0.so")
(set 'GOBJECT "libgobject-2.0.so")))

# Get the necessary functions
(import GOBJECT "g_signal_connect_data")
(import GTK "gtk_init")
(import GTK "gtk_window_new")
(import GTK "gtk_window_set_title")
(import GTK "gtk_window_set_default_size")
(import GTK "gtk_window_set_position")
(import GTK "gtk_table_new")
(import GTK "gtk_container_add")
(import GTK "gtk_button_new_with_label")
(import GTK "gtk_table_attach_defaults")
(import GTK "gtk_entry_new")
(import GTK "gtk_widget_show_all")
(import GTK "gtk_entry_get_text")
(import GTK "gtk_main")
(import GTK "gtk_exit")

# Callback to exit program
(define (exit_prog)
    (gtk_exit 0)
    (exit))

# This callback receives the signaled widget (the button), and receives the additional data too, namely the entry
(define (print_content button widget)
    (println (get-string (gtk_entry_get_text widget))))

# This callback receives the signaled widget which was the entry itself
(define (print_entry widget)
    (println (get-string (gtk_entry_get_text widget))))

# Initialize GTK
(gtk_init 0 0)

# Define the mainwindow
(set 'win (gtk_window_new 0))
(gtk_window_set_title win "DirectGTK")
(gtk_window_set_default_size win 150 100)
(gtk_window_set_position win 1)

# Connect the delete signal to the mainwindow
(g_signal_connect_data win "delete-event" (callback 0 'exit_prog) 0 0 0)

# Define a table
(set 'table (gtk_table_new 30 30 1))
(gtk_container_add win table)

# Define the other widgets
(set 'entry (gtk_entry_new))
(gtk_table_attach_defaults table entry 2 28 5 15)
(g_signal_connect_data entry "activate" (callback 1 'print_entry) 0 0 0)

(set 'button1 (gtk_button_new_with_label "Exit"))
(gtk_table_attach_defaults table button1 17 28 20 25)
(g_signal_connect_data button1 "clicked" (callback 0 'exit_prog) 0 0 0)

(set 'button2 (gtk_button_new_with_label "Print text"))
(gtk_table_attach_defaults table button2 2 13 20 25)

# Define a callback and send the entry as additional data
(g_signal_connect_data button2 "clicked" (callback 2 'print_content) entry 0 0)


# Show
(gtk_widget_show_all win)

# Mainloop
(gtk_main)


Now I do have some questions on the callback implementation.



1) Why do we need to pass a handle? For example, (callback 1 func) passes a '1'. Can newLisp not take care of such handles by itself?



2) Why can there be only 8 of those handles? For most purposes it is sufficient, and as the program demonstrates we can use the same callback multiple times when this is suitable to us.



3) In the newLisp sourcecode I see that callback functions can accept arguments to a maximum of 4. For OpenGL this will do, but for GTK it is no good! Callbacks can sometimes receive up to 8 arguments.



Thanks in advance!



Regards

Peter

[pjot]

(I don't know why  am spamming so much tonight, but this will be my last post ;-) )



Anyway, I have studied your 'nl-import.c' a little and it is clear to me how the callback stuff was implemented. So now for some remarks, skipping the 'with-all-due-respect' stuff. ;-)



In my humble view the housekeeping of the callback functions (so the handle I am complaining about), can be kept internally to newLisp, because point is that each callbacked function has a unique name. This name already is a handle!



So, when the newLisp function (callback) is invoked, the name of the callbacked function could be stored internally, in some additional array for example, where the indexnumber of the array points to the used callbackname. NewLisp can use the indexnumber to decide which of the 8 C-callbacks in 'nl-import.c' should be invoked. Each time the user sets up a new callback, newLisp must check the name of the callbacked function. If it is already used, then also use the same C-callback in 'nl-import.c'. If not, assign a free slot in one of the C-callbacks of 'nl-import.c'. If there is no free slot, generate an error like "ERR: no callback slot available".



Also it might be interesting to create a possibility to remove existing callback functions. Suppose we have assigned (callback 'myfunc), then we can also do (no-callback 'myfunc).



BTW there are also good workarounds to overcome the limit of 8 callback functions. For example, create a generic callback function and within that function decide what to do based on incoming data.



However, for the amount of arguments IMHO they really should be extended to 8 instead of 4.



Good night and welcome back home!

Peter

[Lutz]

Thanks for the 'callback' review :-) and special thanks for the example program, how to use the GTK libraries on Win32, Linux and on Mac OS X. Lets hope, the rumor comes true, that Apple will include the GTK framework in a future OS version by default, like it is already the case on Linux.



To your questions and observations: True to newLISP's philosophy the current implementation of the callback interface is minimal. Numbering the callbacks allows for less code, faster processing and the possibility to reuse the same numbered function slot for a different function.



I was not aware of the higher requirements of parameters in the callback function when using GTK, having experience only with OpenGL and Win32. For the 10.0.1 release update, I will add 4 more parameters and also add a few more callback slots. All this can be done with minimal additional memory requirements and without additional code.

[pjot]

Yes 8 arguments is absolutely necessary, look for example at the "drag-data-received" signal in GTK:



http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-drag-data-received">http://library.gnome.org/devel/gtk/stab ... a-received">http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-drag-data-received



The user function (=callback function) receives 8 arguments here.

Numbering the callbacks allows for less code, faster processing and the possibility to reuse the same numbered function slot for a different function.

Well, I understand it is less code on C-level, but why should the newLisp programmer be bothered with the internal housekeeping of the interpreter?



And also in my proposition, the newLisp programmer can reuse the same callback function for a different function.



The implementation of this concept is minimal, one additional array which can be looked through, using the indexnumber in the array as handle for the actual C-callback in 'nl-import.c'. Let's say this will add a 150 bytes extra to the interpreter?



The newLisp program itself will look better with less code!



Cheers

Peter

[pjot]

For those of you who are still not convinced, a newLisp program directly with GTK.



Should run on MacOSX, Linux/Unix and Win32 without changes.



http://www.turtle.dds.nl/newlisp/fractal.jpg">



The code is here:



http://www.turtle.dds.nl/newlisp/fractal.lsp">http://www.turtle.dds.nl/newlisp/fractal.lsp





Regards

Peter