Please Please make an IDE. All I want is a PET download with an icon to press so I can follow what your doing/explaining, from running examples/tutorials and perhaps in time learn to code. Only it seams one has to be a programer just to install these things in order to learn how to program!!!!

Mark, I guess JWM's interference is because GINS is using stdin and stdout. Perhaps we need to redesign GINS to use two different fifo piping streams. There is 0, 1, 2 already assigned to stderr, stdin, stdout, but 3,4,5 are available. In the long term, that might be the best thing to do for GINS.

Mark, you sure are having coding marathons! While you're at it, why not hack FreeBasic into FreeGin
...I wonder though, it might not be so difficult to patch in your stuff.

ginsbasic does not use stdin stdout, as in ginsbasic the gins-functions are called directly as C functions.
The external gins is not needed, the functions are compiled into in the ginsbasic-binary.
Not not using the long way of invoking the shell.
This is one of the advantages.
I could remove the complete i/o handling (thread.c is removed completely).

I think it is an Xserver issue.
The Xserver receives a mouse-signal (buttonpress).
JWM grabs it, to be able to move windows or handle the click on the windowtitle-buttons.

Then it does not "re-send" the event correctly, so that the application running in that window can receive it.

But I wonder, why this just happens with the gins functions, not with other applications.
Maybe this guess is totally wrong.

Concerning freebasic:
I think the internal handling of variables will be completely different.
Puppybasic (wxBasic) uses its own type "variant".
But some code might be usefull, like a bubblesort written in C.
The one written in Basic is quite slow.
Mark

gtk_createobject() will look if the objecttype (here GtkButton) is supported by ginsbasic (this is just a matter of building a lot of "if"s).
Then it is added to a global GList, so it remains in memory, when the C-function returns to Basic. Also the name (button96) will be added to such a list.

Now when you call gtk("gtk_box_pack_start , ... , "Gtk:button96" ...
then this function looks, if an argument has a ":" in it.
If yes, it uses this value to get the formerly stored object from the GList, and runs the wanted function with it.
Also this will work:
gtk("gtk_box_pack_start , ... , "Glade:button1" ...

This would use a button from the loaded glade-file instead.

I currently just checked it with this button.
I loaded a window made with glade, created this new "internal" button, and then attachedd it to the window. Works!

Now that I found a concept, there remains a lot of work.
I will have to enhance the code to support not only buttons.
And I must rewrite the script that generates gins.c , because now it shall no longer "drop" functions that use objects as arguments.
So a lot to do for the next weekend(s).

And I should think about a new name.
Hmmm... no search-results for:
http://www.google.com/search?hl=en&q=gtkbasic

New Gtk-objects will be recognized by the arguments passed to a Gtk-function, if their names start with ":".
They are stored in a struct, that is iterated with help of a Glist.
Maybe it could be done also without the glist using pointers, but I'm not experienced enough yet. That could remain for a final code-optimization.

I now must extend this argument-type-detection for the glade-objects, too.

Then I must rewrite my buildscript, to recognize this new functionality.
When a new Gtk-widget is created, also the events will automatically will be assigned to the "events()" function, so you can request them like those of the glade-widgets.

I added a new TextView example, that now has better support for buffers and Iterators. So you can replace very precisely parts of a text, e.g. selected text.

I also added a Multifilechooser.
It can be run as standalone-widget (like Xdialog) from shellscripts. Example-script is included.
Note, it has "file-open" behaviour by default.
In Glade, you can choose among 4 types (File save, Select Folder, Create Folder).
I'll extend that widget later, so you can choose such options with a argument passed to the widget-script.

You can download a small binary with examples and ginsfunctions.txt, and a source-pack.
Source is for C-coders only.
http://noforum.de/files/wxbasic/gtkbasic/Gtkbasic-0.0.2.tgz
http://noforum.de/files/wxbasic/gtkbasic/Gtkbasic-0.0.2-source.tgz

Run "make install" or simply copy the file gtkbasic002 to /usr/bin.
Then type commands similar to this:
cd /whereyouextracted
./nameOfScript.pb

I had no time yet to build a small IDE, I'm sorry.
I had to write a lot of code to wrap the objects, and there still is a lot of cleanup needed. But now it should be already usable to write an IDE, so lets see...
---------------------------
Internals:
You now can use several objects as arguments for other objects.
This works best with those generated with the gtk_functions, not with the ones created with glade.

The code is generated automatically, I just had to replace some with selfwritten ones (mostly the new() should not be used, use gtk_createobject() instead).

--------
A problem I now encountered are "enums".
These are options like Gtk_window_new (TOPLEVEL | POPUP).
It seems I can not pass them as variables, what makes it complex to write a lot of "if / else" statements.
It also blows up the code (the interpreter now is already 250 kb uncompressed).
Enums are used often for creating new widgets to set default-options.
I'm not shure yet how to deal with this issue.

(MU) A problem I now encountered are "enums".
These are options like Gtk_window_new (TOPLEVEL | POPUP).
It seems I can not pass them as variables, what makes it complex to write a lot of "if / else" statements.

Not sure if this is what you mean but if the code is based on C++ then things like TOPLEVEL in this case will usually be #defines and handled by the C preprocessor. Maybe it would be easier to make a basic preprocessor that took an array (or .csv) of couplets for each define, then just do a search and replace before running.

Code:

Eg Preprocess pseudo-code

DefineArray = (TOPLEVEL, 1),
(POPUP, 2),
(etc, 4)
....

For Each DefineArrayIndex
SearchAndReplace ProgramText, DefineArrayIndex(0), DefineArrayIndex(1)
Next

Might be a bit slower but probably smaller and easier to maintain in long run.

BTW you probably already know, but | is bitwise OR, but for the purposes of passing settings like this it's effectively the same as +

I plan to build more such dialogs.
Thats all for now, no IDE and such yet, as I'm fiddling a lot on the internal stuff, as described here (xwin_getdir):
http://wxbasic.sourceforge.net/phpBB2/viewtopic.php?t=1042

Changes:
GDK_DELETE event now will NOT be sent to the Gtk-mainloop any longer, but only detected by the Basic-program.
Reason:
In Glade, you create 2 windows.
A mainwindow and a dialog.
Window is visible, dialog not.
If you click a button, the dialog is shown.
Now the problem: If the dialog is closed, it is destroyed.
If you click the button again, the program crashes, because the dialog does not exist any more.

With the patch, you can do this:
In the mainloop, if GDK_DELETE is detected, you use
gtk("gtk_widget_hide" , "dialog" , ...)
Now this dialog becomes invisible, but is no longer destroyed, as the event is no longer processed any further.
If you wanted to destroy the dialog, you now had to call gtk("gtk_widget_destroy,...).

I included "ide.pb", which is a very rough layout-prototype of the planned ide.
It has no functionality yet, but you can click on "new" to open a dialog.
This dialog can be closed and reopened with the new gtkbasic002.

I found another bug:
Opening dialogs/other windows sometimes results in a "Xlib async error", and the program freezes.
I tried some quick tests to catch the Xlib-errors (as I did already in some xwin_ functions in Puppybasic. But I had no success yet, I must do more tests with this issue.

--------------------
another issue:
radiobuttons.
If you select the option to set one active by default, glade crashes, if you reload your project.
You then must remove that line with a texteditor.
Also Gtkbasic crashes, if you send a activate-command for a radiobutton to libglade.
Radiobuttons use gslists from Glib, so I suspect there is a library-conflict somewhere.
Must google for that bug.

-----------------------
Next "long" weekend I drive 550 km to Hamburg and must hand over my old appartment, so I will not be online (maybe just very short) or develop stuff.
I'll return monday or wednesday, not shure yet.