gtkbasic-0.0.2
I will add a small IDE (a grafical programming tool) to generate programs using some templates.
The IDE will allow to create a project, open it in Glade, and edit the program that handles the events.
It also will include a list of all functions.
But before I do that, I wanted to finish the inbuilt functionality first.
I want to find a better solution for handling objects, maybe I can use a C struct (a table) to manage them.
Then you could use stuff like
button1 = gins_gtknewobject("GTKButton")
gins_gtk("window_add" , "window1" , "GINSOJECT:button1")
But this is a bit tricky, so no idea how fast I'll be in making progress.
Maybe I should start the ide first, to mayke it easier to use the already existing functionality.
Mark
The IDE will allow to create a project, open it in Glade, and edit the program that handles the events.
It also will include a list of all functions.
But before I do that, I wanted to finish the inbuilt functionality first.
I want to find a better solution for handling objects, maybe I can use a C struct (a table) to manage them.
Then you could use stuff like
button1 = gins_gtknewobject("GTKButton")
gins_gtk("window_add" , "window1" , "GINSOJECT:button1")
But this is a bit tricky, so no idea how fast I'll be in making progress.
Maybe I should start the ide first, to mayke it easier to use the already existing functionality.
Mark
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!!!!
Wonderful work your doing Mark no need to rush.
Wonderful work your doing Mark no need to rush.
it is pretty simple.
Install libglade with petget.
Download and extract http://noforum.de/files/wxbasic/ginsbas ... -0.0.1.tgz
Copy the file ginsbasic001 to /usr/bin/
Then you can start the examples by typing some comands in the consolewindow.
If you extracted to /root/:
cd /root/ginsbasic-0.0.1
./testtextview.pb
or
./calc
or
./testfilechooser.pb
To edit the layout of the windows, install Glade with petget.
Run it from the menu or by typing "glade".
Then you can open one of the .gladefiles I supplied, like
/root/ginsbasic-0.0.1/calc.glade
To modify the things that happen, when a button is clicked, open calc.pb in your texteditor.
Try to play around by modifying values, to see what happens.
Tell me if it works, or if you have the same problem as Barry.
Mark
Install libglade with petget.
Download and extract http://noforum.de/files/wxbasic/ginsbas ... -0.0.1.tgz
Copy the file ginsbasic001 to /usr/bin/
Then you can start the examples by typing some comands in the consolewindow.
If you extracted to /root/:
cd /root/ginsbasic-0.0.1
./testtextview.pb
or
./calc
or
./testfilechooser.pb
To edit the layout of the windows, install Glade with petget.
Run it from the menu or by typing "glade".
Then you can open one of the .gladefiles I supplied, like
/root/ginsbasic-0.0.1/calc.glade
To modify the things that happen, when a button is clicked, open calc.pb in your texteditor.
Try to play around by modifying values, to see what happens.
Tell me if it works, or if you have the same problem as Barry.
Mark
I found out, why the calculator does not work for Barry.
He uses JWM.
JWM grabs buttonclicks.
If you replace in calc.pb
with
Then it works better, but still erratic.
The Window will just update, after you move the mouse outside the button, or click it a second time.
Very strange behaviour.
I use Icewm, so did not encounter this problem myself.
Unfortunately I have no idea, how gins could be modified to work around this issue.
Mark
He uses JWM.
JWM grabs buttonclicks.
If you replace in calc.pb
Code: Select all
if event = "GDK_BUTTON_PRESS" then
Code: Select all
if event = "GDK_BUTTON_RELEASE" then
The Window will just update, after you move the mouse outside the button, or click it a second time.
Very strange behaviour.
I use Icewm, so did not encounter this problem myself.
Unfortunately I have no idea, how gins could be modified to work around this issue.
Mark
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
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
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
no update, just a short note on (slow) progress.
I now can create Gtk objects natively in Basic, without gins/glade. They also can be "mixed" with glade objects.
I now started on:
gtk_createobject("GtkButton" , "button96")
gtk("gtk_box_pack_start " , "vbox1" , "Gtk:button96" , "1" , "1","1",0)
gtk() is just the now renamed gins_gtkwidgetfunction().
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
Mark
I now can create Gtk objects natively in Basic, without gins/glade. They also can be "mixed" with glade objects.
I now started on:
gtk_createobject("GtkButton" , "button96")
gtk("gtk_box_pack_start " , "vbox1" , "Gtk:button96" , "1" , "1","1",0)
gtk() is just the now renamed gins_gtkwidgetfunction().
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
Mark
No new download yet, just info on progress:
Working testprogram:
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.
Mark
Working testprogram:
Code: Select all
//-- load file and show the window
gins_glade("test.glade")
gins_set("window1" , "100" , "100" , "<uposition>")
gins_main()
//-- test new objectstuff
//-- add new elements to a window made with glade
gtk_createobject("GtkButtonWithLabel" , "button96", "testbutton" , 0)
gtk("gtk_box_pack_start" , "vbox1" , ":button96" , "0","0","0",0)
gtk("gtk_widget_show" , ":button96" , 0 ,0,0,0,0)
gtk_createobject("GtkLabel" , "label77", "testlabel" , 0)
gtk("gtk_box_pack_start" , "vbox1" , ":label77" , "0","0","0",0)
gtk("gtk_widget_show" , ":label77" , 0 ,0,0,0,0)
//-- create a completely new window
gtk_createobject("GtkWindow" , "NewWindow", 0 , 0)
gtk("gtk_widget_show" , ":NewWindow" , 0 ,0,0,0,0)
gtk_createobject("GtkHBox" , "NewHBox", "0" , "0")
gtk("gtk_container_add" , ":NewWindow" , ":NewHBox" , "1","1","0",0 )
gtk("gtk_widget_show" , ":NewHBox" , 0 ,0,0,0,0)
gtk_createobject("GtkButtonWithLabel" , "button77", "wwwbutton" , 0)
gtk("gtk_box_pack_start" , ":NewHBox" , ":button77" , "1","1","0",0)
gtk("gtk_widget_show" , ":button77" , 0 ,0,0,0,0)
//gtk("gtk_window_resize" ,"window1" , "100" , "100", 0,0,0)
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.
Mark
I renamed it now to gtkbasic 0.0.2.
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/gtkbasi ... -0.0.2.tgz
http://noforum.de/files/wxbasic/gtkbasi ... 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.
Mark
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/gtkbasi ... -0.0.2.tgz
http://noforum.de/files/wxbasic/gtkbasi ... 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.
Mark
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.(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.
Code: Select all
Eg Preprocess pseudo-code
DefineArray = (TOPLEVEL, 1),
(POPUP, 2),
(etc, 4)
....
For Each DefineArrayIndex
SearchAndReplace ProgramText, DefineArrayIndex(0), DefineArrayIndex(1)
Next
BTW you probably already know, but | is bitwise OR, but for the purposes of passing settings like this it's effectively the same as +
DB
I made a dotpup of a minimally enhanced version 002.
Download:
http://dotpups.de/dotpups/Programming/Gtkbasic-002.pup
It includes some Forum-messages as "documentation" (ahem, sorry, no real one yet).
But it has a very cool fileselection-dialog.
It is so easy to use from shellscripts:
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/v ... php?t=1042
Mark
Download:
http://dotpups.de/dotpups/Programming/Gtkbasic-002.pup
It includes some Forum-messages as "documentation" (ahem, sorry, no real one yet).
But it has a very cool fileselection-dialog.
It is so easy to use from shellscripts:
Code: Select all
#!/bin/bash
#--------------------------------------------------------
#-- setup the path to the dialogs
GBdialogPATH=/usr/local/Gtkbasic-002
FILECHOOSER="$GBdialogPATH/dialog-multifilechooser/GBdialog-multifilechooser"
#---------------------------------------------------------------
# modes (1-4) open file , save file , open folder , create folder
# multiselect only for mode 1
# -- open multiple files -----------------------------------
title="Open Files"
folder="/usr/share/audio"
wildcards="*.au"
mode="1"
multiselect="1"
result=`"$FILECHOOSER" "$title" "$folder" "$wildcards" "$mode" "$multiselect" 2>/dev/null`
#-- display the choice: -----------------------------------
xmessage -center "you chose:
$result
bye bye...
"
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/v ... php?t=1042
Mark
I updated all the Gtkbasic002 packages.
There was a bug in the way I handled Textiterators.
Those iterators thell a function, where to start and stop a modification of text.
Now you can directly adress one of 6.
Example:
Now is:
This comand "fills" Textiterator 1 and 2 with the position of the start and end of the currently selected Text in buf1.
Then you can for example delete this part of the text with:
As you have 6 Iterators, you also could handle a second (and third) Textbuffer, while iterators 1 and 2 are already in use.
Stupid example, but it uses the same commands with just different values just to illustrate the difference.
So you enter a number from 1 to 6 for the placeholders, that are described as TextIterators in the documentation.
Mark
There was a bug in the way I handled Textiterators.
Those iterators thell a function, where to start and stop a modification of text.
Now you can directly adress one of 6.
Example:
Code: Select all
gtk("gtk_text_buffer_get_selection_bounds",":buf1" , "dummy" , "dummy" , 0, 0,0 )
Code: Select all
gtk("gtk_text_buffer_get_selection_bounds",":buf1" , "1" , "2" , 0, 0,0 )
Then you can for example delete this part of the text with:
Code: Select all
gtk("gtk_text_buffer_delete", ":buf1" , "1" , "2" , "1", 0,0)
Code: Select all
gtk("gtk_text_buffer_get_selection_bounds",":buf2" , "3" , "4" , 0, 0,0 )
gtk("gtk_text_buffer_delete", ":buf2" , "3" , "4" , "1", 0,0)
So you enter a number from 1 to 6 for the placeholders, that are described as TextIterators in the documentation.
Mark
Updated the 002 archives.
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.
Mark
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.
Mark
A mouse bug with gtkbasic002?
Dear Mark,
I don't know whether other users can replicate this "feature", but I get "11" entered into the demo calc program each time I press, ofr example, a single "1". Upon a mouse click, a single number appears in the input field. When I move the mouse away, and the number is still highlighted, a repeat of the original input takes place. I don't know whether that is a bug in the calc program itself (calc.pb), which i've not examined yet, or a general problem with mouse button handling in gtkbasic002.
Has anybody else experienced that same problem?
With kind regards,
Vovchik
PS. I just downloaded and tested the new version and the bug still seems to be there, if, indeed, it is in gtkbasic002 and not in calc.pb.
I don't know whether other users can replicate this "feature", but I get "11" entered into the demo calc program each time I press, ofr example, a single "1". Upon a mouse click, a single number appears in the input field. When I move the mouse away, and the number is still highlighted, a repeat of the original input takes place. I don't know whether that is a bug in the calc program itself (calc.pb), which i've not examined yet, or a general problem with mouse button handling in gtkbasic002.
Has anybody else experienced that same problem?
With kind regards,
Vovchik
PS. I just downloaded and tested the new version and the bug still seems to be there, if, indeed, it is in gtkbasic002 and not in calc.pb.
This is a bug in JWM I think.
Look at calc.pb
You see:
GDK_BUTTON_PRESS is a good signal, but captured by JWM.
With Icewm it works fine, if you have a different windowmanager than JWM, replace the line like this:
Now it works correct in Icewm, but not at all in JWM.
This issue currently is unresolved.
If I find time, I will write Joe Wing (JWM) to see, if he has an idea.
I also may try to modify the internal signal-handling.
If a "GDK_BUTTON_RELEASE" is detected, it might be catched, and instead a "GDK_BUTTON_PRESS" might be sent. But I'm not shure, if my knowledge is good enough to do that.,
I will try it next week, when I hopefully have more free evenings (no more dentist or Server-room upgrade at work or journey to Hamburg).
On wednesday I'll finally get 9 new teeth in my bottom jaw, at moment I have some made of plastic. Feel a bit like "Mr. Data"
This button-issue has high priority, as it is essential.
Mark
Look at calc.pb
You see:
Code: Select all
if event = "GDK_BUTTON_RELEASE" or event = "GDK_BUTTON_PRESS" then
With Icewm it works fine, if you have a different windowmanager than JWM, replace the line like this:
Code: Select all
if event = "GDK_BUTTON_PRESS" then
This issue currently is unresolved.
If I find time, I will write Joe Wing (JWM) to see, if he has an idea.
I also may try to modify the internal signal-handling.
If a "GDK_BUTTON_RELEASE" is detected, it might be catched, and instead a "GDK_BUTTON_PRESS" might be sent. But I'm not shure, if my knowledge is good enough to do that.,
I will try it next week, when I hopefully have more free evenings (no more dentist or Server-room upgrade at work or journey to Hamburg).
On wednesday I'll finally get 9 new teeth in my bottom jaw, at moment I have some made of plastic. Feel a bit like "Mr. Data"
This button-issue has high priority, as it is essential.
Mark
Thanks for clarification!
Dear Mark,
Thanks for the code snippet. Everything now works as it should in calc.pb under IceWM, which is my standard WM. JWM must have a bug related to mouse signal handling.
MfG,
Vovchik
Thanks for the code snippet. Everything now works as it should in calc.pb under IceWM, which is my standard WM. JWM must have a bug related to mouse signal handling.
MfG,
Vovchik