(And if I put import <gtk/gtk.h> before import sys-core.h the complaint is about stdio.h)
I know it is not your priority, this is why somebody else must do it. You know I have an interest and it is hard so a great opportunity to learn a lot
A lot of compilation error still, lots of pointer issues, I confuse *p and p when I declared
Type * p and then think p is the pointer to use in a function argument that wants a Type *, but I figure it out. Learning by repetition.
This is a warning letting you know that something you are including is bringing in a dependency on things like printf(). We like to not build on top of that stuff if we can.
If you're pulling in a file that includes stdio.h and want to ignore that, you can put:
#define DEBUG_STDIO_OK
At the top of your file, or wherever before you #include "sys-core.h".
I have had a struggle with the connect-signal function, but I won the first battle.
Also added a few TextView and TextBuffer functions now.
I do not yet know how to read in a single character or return it. A character is an issue! type in Ren-C now. It is for the character to be set for masked fields, so for a convenience purpose, not needed right away.
So, with all the examples in the extension it will be a breeze to add other widget types in at a later stage.
Proceeding with the next phase. By now it will be entering Rebol land again.
Time to figure out how to work with all of this and how to store/keep the various widget elements and how to get them updated.
For example a button "Add 1" press leads to the update in another element, say a label element that displays a number, then afterwards the label displays that number plus one.
The way some VIEW implementations, that I have seen till now, work, is iterate over the block collecting items until a new set-word! or widget type is encountered and then construct the desired item.
It is my plan to implement VIEW this way also.
Almost forgetting a very important thing here.
Now the extension can be compiled if you add the extension name to the config file.
There has to be a place for some Rebol code to be placed that deals with the functions in the extension, because unlike the MySQL binding where I considered it to be acceptable to deal with this in the user script, this will provide a VIEW like interface.
But if one is to place the code in a mezz source file there must be a way to discard this when there is no GTK extension.
By the way, I looked at the mezz-math.r code and I saw a MATH func there that should take a block!, but when I did that
>> math [2 + 3 * 4]
** Script Error: add does not allow #[datatype! block!] for its value1 argument
** Where: reduce either math console
** Near: [add [[] [] 2] [multiply [[] [] 3] [[] [] 4]] **]
** File: -tmp-boot-
** Line: 7278
Lucky 2 + 3 * 4 still normally returns 20 (you know I consider this better behaviour)
Need to update the file though to to stay a little actual, must add value for tau.
@hostilefork I need to pass a NULL as an argument to my function
help "NULL"
Found these related words:
NULL void!
null-1? action! Determine if argument would have triggered an...
null-2 action! Make the heavy form of NULL (can't be WORD!-f...
null-2? action! Tells you if the argument is the heavy isotop...
null? action! Tells you if the argument is not a value
help "none"
Found these related words:
none void!
But if I use NULL or none
** Script Error: NULL is ~unset~ (use GET/ANY to GET voids)
** Script Error: none is ~unset~ (use GET/ANY to GET voids)
The g-signal-connect-data function is a tricky thing to implement...
gtk-main
And when closing the applicationwindow
Segmentatiefout (geheugendump gemaakt)
(^ Dutch language)
And exits the R3 console back into the terminal session.
Updated some code now and hereby provide the code to play with:
Point 3 is trivial. It should be inside the ext-EXTENSIONNAME-init.reb
Point 5 is trivial as well, it follow after the new point 5 which is the way opens up to add more similar GUI interfaces for use on systems that do not provide GTK3 natively.
Point 1 I have an idea that it might be helpful to attack this with debug asserts on (I have these turned of atm.) But that could be of no use at all.
Point 2 I had an idea to use the data field in combination with a convenience function that performs the data by use of rebElide of a data block!
(But that can be a bad idea too).
Point 4 anyone can assist to add new functions here. I have a large spreadsheet of available functions.
When I look at the old GTK(2) binding that was made for Red versions before 0.4.2 then I notice that the GTK functions are mapped to the Redbol functions through a cdecl interfacing.
We do this binding with some more handcraftingwork, which may be a bit more work but comes with the advantage of being able to do a little steering inside.
Then when the g_signal_connect_data is available as connect-signal and is being invoked, the arguments need to be passed as well. One of the arguments is the callback function. The way this is passed is by using as-integer! :function.
In Ren-C there seems not to be a way to get a handle like that.
Current state is for example TO INTEGER! only supports the ISSUE! type that was formerly known as CHAR! so #"s" thingy's.
>> gtk-main
Inside self_signal_connect_helper
main level is 1 HIGH
before rebElide of user_data
Greetings from function f!!!
After rebElide of user_data
I must clean up the code, but to preserve working code I just pushed to the r3n branch for you all to reproduce.
Having these things liberates the way to the next level.
I have several code snippets of VIEW and LAYOUT functions laying around so time to decide on how to use GOB!s and what is most efficient for this project.
In the course of all changes that were made to get Ren-C where it is today, how types work has been subject too. The way they used to be in R3-Alpha is incomparable to todays Ren-C source.
So do GOB! type inner working.
If one makes a GOB type
>> gobj: make gob! []
== make custom! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]
you note that this is just a small subset of things you can think of that a graphics object needs.
Extending an existing GOB like you would do with an ordinary object does not work.
>> gobj2: make gobj [extra: 1]
** Error: Datatype does not have a MAKE handler registered
** Where: make console
** Near: [*** make gobj [extra: 1] **]
** Line: 1
As this is rather cryptic code that will be taking me a lot of time figuring out, I will now "invent" a new type of object that will be just an object containing the items I will need in the process. The object type will be called a DOB! a Display OBject.
This will do perfectly for now and will be extensible when needed.
>> dob: make object! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]
** Syntax Error: invalid "pair" -- ""
** Where: transcode if load trap ext-console-impl entrap console
** Near: (line 1) dob: make object! [offset: 100.0x100.0 size: 0.0x0.0 alpha: 255]
** File: -tmp-boot-
** Line: 5307
>> dob2: make dob [extra: true]
== make object! [
offset: 100x100
size: 0x0
alpha: 255
extra: #[true]
]
There may be many other effects of the made changes that make working with Ren-C a challenge. That is not a bad thing, but where we find similar issues, it is good to think about bringing back a thing or two (not change things back but forward!).
Yes, I had already figured that out, I am now in the process of getting the C function callback do exactly that.
And I had that working too, but I think I had it working with some unsaved code on top of it that I did save to commit a change and now I can't get the working version reconstructed.
(The callbacks are working but passing the function or block and rebElide that does not and is very likely to exit the console)
// Signal helper C
static void self_signal_connect_helper(GtkWidget *widget,
gpointer user_data){
rebElide("print {Inside self_signal_connect_helper}");
rebElide("print {before rebElide of user_data}");
rebElide(user_data);
rebElide("print {After rebElide of user_data}");
return;
}
And setting this in g-connect-signal-data
result = g_signal_connect_data(instance, detailedsignal, G_CALLBACK(self_signal_connect_helper), chandler, NULL, flags);
gtk-main
Inside self_signal_connect_helper
before rebElide of user_data
Segmentatiefout (geheugendump gemaakt)
Probably need to cast the chandler to the data format, but somehow this was the change that made the thing work (apparently).
