|
|
Post by Pjot on May 13, 2012 19:20:37 GMT 1
All, Sometimes I receive requests to add such-and-such widget to HUG. But you can do this yourself, with a little knowledge of GTK. Inspired by the tutorials of bigbass, I thought it would be a good idea to explain how HUG can be expanded with additional widgets. HUG has two functions, REGISTER and METHOD, which provide a convenient extension interface. For this small tutorial we'll look at the GtkPlug/GtkSocket widgets. These are very simple widgets and therefore very suitable for this explanation. The idea is to create a new INCLUDE file which should be added to your programs. Of course the new GTK functions must be imported first. Then, for the 'socket' widget, we will create a SOCK function to create the socket, and we'll create GET function to get the windowID to which it is attached. For the 'plug' widget we will create a PLUG function to create the plug, and a SET function to assign some widget to the plug. So this is how our new INCLUDE file looks like. Let's call it 'sock_plug.bac'. Obviously, some knowledge about how the widgets work on GTK level is assumed. The code contains a lot of comments which explain each step.
' Import GtkSock/GtkPlug functions
gtk$ = HUGLIB$("gtk")
IMPORT "gtk_socket_new(void)" FROM gtk$ TYPE long
IMPORT "gtk_socket_get_id(long)" FROM gtk$ TYPE long
IMPORT "gtk_plug_new(long)" FROM gtk$ TYPE long
' The self-defined GET for the SOCK
FUNCTION GET_winid(NUMBER widget)
LOCAL winid
' Get the windowID from the socket
winid = gtk_socket_get_id(widget)
RETURN winid
END FUNCTION
' Function to create the SOCKET
FUNCTION SOCK(int hug_xsize, int hug_ysize)
LOCAL widget
' Create the socket
widget = gtk_socket_new()
' Register and determine size and signal
REGISTER(widget, hug_xsize, hug_ysize, "plug-added", 0, 0, 0, 0)
' Determine the GET method
METHOD(widget, 3, GET_winid)
' Return the created socket
RETURN widget
END FUNCTION
' The self-defined SET for the PLUG
SUB SET_widget_to_plug(NUMBER plug_widget, NUMBER gtk_widget)
gtk_container_add(plug_widget, gtk_widget)
ENDSUB
' Function to create the plug
FUNCTION PLUG(NUMBER window)
LOCAL widget
' Create the plug
widget = gtk_plug_new(window)
' Register and determine signal (no need for size)
REGISTER(widget, 0, 0, "embedded", 0, 0, 0, 0)
' Determine the SET method
METHOD(widget, 4, SET_widget_to_plug)
' Return the created plug
RETURN widget
END FUNCTION
Now we have our new INCLUDE file ready with the additional widgets. How should they be used? First the program defining the socket. Note that it first includes HUG, and it after that includes our new widgets.
' Get HUG functions
INCLUDE "hug.bac"
' Get our self-defined widgets
INCLUDE "sock_plug.bac"
' Callback for the socket
SUB msg
PRINT "The plug was inserted!"
END SUB
' Create the main window
win = WINDOW("Socket window", 400, 400)
' Create the socket
sock = SOCK(150, 30)
' Add socket to window and setup callback
ATTACH(win, sock, 10, 10)
CALLBACK(sock, msg)
' Get the windowID from the socket
winid = GET(sock)
' Save windowID to a file so the plug can read it
OPEN "/tmp/winid.txt" FOR WRITING AS comm
WRITELN winid TO comm
CLOSE FILE comm
' Endless GTK loop
DISPLAY
Finally, the program which defines the plug.
' Get HUG functions
INCLUDE "hug.bac"
' Get our self-defined widgets
INCLUDE "sock_plug.bac"
' Read winid from a file
OPEN "/tmp/winid.txt" FOR READING AS comm
READLN winid$ FROM comm
CLOSE FILE comm
' Create a widget, has same size as socket
txt = MARK("Hello from the plug!", 150, 30)
' Create the plug
plug = PLUG(VAL(winid$))
' Assign the widget to the plug
SET(plug, txt)
' Make sure the plug is visible
SHOW(plug)
' Endless GTK loop
DISPLAY
Now, start the socket program first and after that the plug program. The result will be that the MARK of the plug program is shown in the window of the socket program. Regards Peter |
|
|
|
Post by Pjot on May 13, 2012 20:09:03 GMT 1
Another demonstration, this time with a GTK statusbar. The statusbar normally appears down below the main window.
The following contains the function STATUSBAR to create the widget, and also a self-defined function for the TEXT method.
' Import GtkStatusbar functions
gtk$ = HUGLIB$("gtk")
IMPORT "gtk_statusbar_new(void)" FROM gtk$ TYPE long
IMPORT "gtk_statusbar_get_context_id(long,char*)" FROM gtk$ TYPE long
IMPORT "gtk_statusbar_push(long,long,char*)" FROM gtk$ TYPE long
SUB TEXT_statusbar(NUMBER widget, STRING txt)
LOCAL contextid
' Get context ID
contextid = gtk_statusbar_get_context_id(widget, "hug")
' Create statusbar
gtk_statusbar_push(widget, contextid, txt)
END SUB
FUNCTION STATUSBAR(int hug_xsize, int hug_ysize)
LOCAL widget
' Create the statusbar
widget = gtk_statusbar_new()
' Register and determine size and signal
REGISTER(widget, hug_xsize, hug_ysize, "text-pushed", 0, 0, 0, 0)
' Determine the TEXT method
METHOD(widget, 2, TEXT_statusbar)
' Make the widget visible
SHOW(widget)
' Return the created socket
RETURN widget
END FUNCTION
The following snippet is a demonstration on how to use the new widget.
' Get HUG functions
INCLUDE "hug.bac"
' Get our self-defined widgets
INCLUDE "statusbar.bac"
' Create window
win = WINDOW("Statusbar demo", 400, 300)
' Create statusbar
status = STATUSBAR(400, 20)
ATTACH(win, status, 0, 280)
' Set a text in the new statusbar
TEXT(status, "Hello world! This is a statusbar.")
' Endless GTK loop
DISPLAY
|
|
|
|
Post by bigbass on May 14, 2012 6:42:40 GMT 1
  Great stuff !I took a big Jump trying to understand this one it was above my level but yes!!!! it works please keep these coming I would love to understand how to add widgets even though I am just starting to figuring out how to use them  *there are two small edits you need to make and the only reason I saw it was because my kids were using the computer and I used my sons' nintendo ds to see your code and I was writing it down with a pencilso I could study it and these two lines caught my attention ' Get the windowID from the socket winid = GET(sock) change it to ----> winid = GET_winid(sock)' Assign the widget to the plug SET (plug, txt) change it to ----> SET_widget_to_plug(plug, txt)because you commented the code so well it made sense new widgets new commands Joe |
|
|
|
Post by Pjot on May 14, 2012 6:59:42 GMT 1
Hi bigbass, No, It really should be a plain SET and GET. That is the idea of the METHOD directive: add self-defined functions for your widgets which then can be executed with the standard SET, GET, GRAB$ and TEXT. Best regards Peter EDIT: as usual make sure to use the latest hug.bac which I uploaded last weekend. |
|
|
|
Post by bigbass on May 14, 2012 17:09:38 GMT 1
Pjot
it works as advertised with the new HUG!
I did learn how to debug the METHOD and by pass it for testing
that will help me when someday I can make a simple widget (some gtkdialog widgets don't have equivalents yet)
this is something I wanted to do but reading GTK widgets for me is like a building starting on the eight floor with no steps... a big jump
so your how to widget tutorial made an elevator to the eighth floor !
just have to really study it well but having an example makes a world of a difference
a big thanks for this tutorial
Joe
|
|
|
|
Post by bigbass on May 15, 2012 16:36:08 GMT 1
 what I understood about your tutorial in a quick view image this gets repeated for each new GTK function * the same INCLUDE file gets updated as you go another will be each step gets added using your excellent code example above in blocks taking only one GTK function and converting it there is so much information we could learn about HUG in just your one example taking time to break down each part I can vision many more widgets getting added now this is fun! Joe |
|
|
|
Post by bigbass on May 16, 2012 6:58:21 GMT 1
|
|
|
|
Post by vovchik on May 16, 2012 9:35:16 GMT 1
Dear Joe, Here is a bacon snippet for making a toolbar widget. Now it has to be HUGified.... With kind regards, vovchik PS. ONly the Quit button is functional for now, but that shows how to do it. Attachments:
|
|
|
|
Post by bigbass on May 16, 2012 14:46:12 GMT 1
Hey vovchik WOW ! ;D I went to sleep thinking about how the GTK functions have to get converted to HUG functions and it makes you have to think too much when there are many functions to convert (because of different naming) I am saying this because after looking at your code that's what you did I really love the way you conserved the most you could of the original GTK function name and it's a neat trick to use the lower case for the commands (geany syntax highlighting allows for this) you also by passed a few steps placing everything in one file (It makes the GTK function part easier to understand when its used in BaCon and less code ) the conversion to IMPORTS is clouded in mystery for me but I guess you have some way to explain this part clearly in a how to we are close to having a direct conversion tool from GTK to HUG I am sure after this demo ANY widget GTK has is ours ;D Some clear the ground some plant the seed some water and care for the plants and some harvest some transport the product and everyone has the good fortune to wake up to a BaCon breakfast ! Thanks friend Joe |
|
|
|
Post by vovchik on May 17, 2012 10:53:28 GMT 1
Dear all, This is a spinner demo. It creates a toolbar and puts a spinner at the end of an hbox. You can turn it on and off using the appropriate buttons. With kind regards, vovchik Attachments:
|
|
|
|
Post by Pjot on May 17, 2012 11:38:40 GMT 1
Hi vovchik,
Nice!
Just one hint: don't forget to add a callback for the "delete-event" signal in case the main window exits. Otherwise the GTK mainloop simply will continue without the GUI being visible.
Thanks and regards
Peter
|
|
|
|
Post by vovchik on May 17, 2012 16:32:40 GMT 1
Dear Peter, Thanks. Just did that, and the new attachment reflects the useful little mod. With kind regards, vovchik Attachments:
|
|
|
|
Post by bigbass on May 22, 2012 16:28:23 GMT 1
Peter this is a great tutorial so much we can learn from this I asked vovchik this question Me And vovchik responded with this since I needed this info others may need it also to follow along with the adding widgets soon I will have some widget to add but still a lot of GTK reading P.S I wanted to study the status bar example because it was easier and found this source code link developer.gnome.org/gtk-tutorial/2.22/x919.html it does compile correctly as is this will help in understanding the step from GTK to HUG Joe |
|
|
|
Post by vovchik on May 25, 2012 21:48:23 GMT 1
Dear guys, Here is a little calendar widget for HUG. With kind regards, vovchik Attachments:
|
|
|
|
Post by bigbass on Dec 4, 2012 15:37:01 GMT 1
This Thread has been important to me since the first time I read it
however I was confused with the GTK part IMPORTS
so I got stuck there and had to move on to other things
but .... since I read what Peter wrote in another thread today it is now clearer to me about the
the TYPE used why we use LONG in the IMPORTS
The reason I am posting this is I want more widgets (and inspire someone else to help )
I would like to help convert code snippets into simple standard widgets we could use and recycle
Joe
Pjot posted all this below
In case of GTK, it was designed in a way that one needs to
typecast widgets in case of some functions. These functions
actually check the type of parameter passed. If you look at
C programs using GTK you'll see the same thing.
With IMPORT though, for each pointer we provide the "long"
type. This is in fact a memory address where the GTK
function would find the information needed. So for each
type of widget we use "long", whether it be a GtkTable,
GtkWindow, GtkButton etc. These all are subclasses of
GtkWidget. But as we always use "long", so a memory
address, there is no need to typecast to something else.
The C compiler, which compiles the IMPORT statement to the
'dlopen' API, cannot know the exact types of the functions
in a Shared Object - it has to rely on the definitions we
are providing. While with the header file method, the C
compiler knows the exact type for each argument, as these
are described in the header files.
So in a way, this whole IMPORT usage is a kind of a hack,
which, fortunately, turns out to work well.
As a basic guideline, I would say "try the IMPORT method",
and if that is not sufficient, you can always fall back to
the "header file method".
An additional advantage of the IMPORT method is, that the
resulting executable has no binary dependency on the
external library it is using. So even when that external
library is not available on the system, the program will
run, allowing to use some other library or to emit a decent
warning message on the command line. With the header file
method, the executable simply will not even run.
|
|
