BaCon - Bash-based Basic-to-C converter/compiler
Dear Puppians,
Peter has released his stable version 1 rc. Get it here: http://www.basic-converter.org/.
He also modified/enhanced HUG (gtk API) and a few other things. My Pikona uses an older version of HUG. I will update it pretty soon. I am waiting for some others to post BaCon code here. It is a very nice, structured language that produces reasonably small executables - perfect for situations where things get messy and/or slow in bash - and unix progs can be called and the results captured into a var.With HUG, very decent GUIs can be written rather painlessly. Give it a try - you won't regret it.
With kind regards,
vovchik
Peter has released his stable version 1 rc. Get it here: http://www.basic-converter.org/.
He also modified/enhanced HUG (gtk API) and a few other things. My Pikona uses an older version of HUG. I will update it pretty soon. I am waiting for some others to post BaCon code here. It is a very nice, structured language that produces reasonably small executables - perfect for situations where things get messy and/or slow in bash - and unix progs can be called and the results captured into a var.With HUG, very decent GUIs can be written rather painlessly. Give it a try - you won't regret it.
With kind regards,
vovchik
Glade file converter
It's in no way perfect but maybe useful for someone trying out BaCON.
Comments, bug reports, improvements, etc. welcome. Especially improvements to the code.
Get it here: http://basic-converter.proboards.com/in ... &thread=21
Enjoy!
Doyle
Comments, bug reports, improvements, etc. welcome. Especially improvements to the code.
Get it here: http://basic-converter.proboards.com/in ... &thread=21
Enjoy!
Doyle
regards,
mechanic
mechanic
bacon glade stuff
Dear Doyle,
You mentioned on Peter's forum that you were working on a glade2Bacon converter. I would love to see the source and would find that program very useful. Imagine drawing a complex gui in glade, passing it through your prog and, presto, a wonderful GTK gui running in BaCon. Keep at it. I would be willing to lend a hand too.
With kind regards,
vovchik
PS. Sorry, I should have looked at the board and read you message carefully before posting. Wow. I can't wait to play with it. Thanks.
You mentioned on Peter's forum that you were working on a glade2Bacon converter. I would love to see the source and would find that program very useful. Imagine drawing a complex gui in glade, passing it through your prog and, presto, a wonderful GTK gui running in BaCon. Keep at it. I would be willing to lend a hand too.
With kind regards,
vovchik
PS. Sorry, I should have looked at the board and read you message carefully before posting. Wow. I can't wait to play with it. Thanks.
Re: bacon glade stuff
Thanks, it's nowhere near finished yet but it does a couple of simple glade gui examples that I have here. Of course it needs parsing of more controls and I would welcome anyone to help make it into a much more complete application. It sure would be nice to use the Glade designer for BaCON apps!vovchik wrote:Dear Doyle,
You mentioned on Peter's forum that you were working on a glade2Bacon converter. I would love to see the source and would find that program very useful. Imagine drawing a complex gui in glade, passing it through your prog and, presto, a wonderful GTK gui running in BaCon. Keep at it. I would be willing to lend a hand too.
Thanks go to your BaCON examples and the examples of others. I learned a lot from browsing the code.PS. Sorry, I should have looked at the board and read you message carefully before posting. Wow. I can't wait to play with it. Thanks.
Regards,
Doyle
PS: I'm working on the gui with the original FreeBasic code from here:
http://www.siebke.com/freebasic/glade2bas.zip
regards,
mechanic
mechanic
Some glade thoughts
Dear mecahnic (Doyle),
I tidied up the callback prog a little (nothing substantive), just because I tend to work that way, and had another look at Peter's calc.bac program. What he does there is incorporate the *.glade source within the *.bac file via
This means that there are no glade runtime dependencies, although the source is larger and a bit uglier! I think this would be nice for your glade callback prog, since the *.bac source would then contain all that would be required for compilation and only one binary without dependencies - apart from GTK - would be the result. Please have a look at the attachment. And the glade file could be read in like this (this is what I use):
In testing one of my glade files, SUBS were created for checkboxes, but no subs or signal processing for the buttons (I had to do that manually).
Incidentally, I like the size of the generated binaries - some 26k for simple guis.
With kind regards,
vovchik
I tidied up the callback prog a little (nothing substantive), just because I tend to work that way, and had another look at Peter's calc.bac program. What he does there is incorporate the *.glade source within the *.bac file via
Code: Select all
xml = glade_xml_new_from_buffer(Calc_Gui$, LEN(Calc_Gui$), 0, 0)
Code: Select all
' --------------------
FUNCTION CAT(STRING FILENAME$)
' --------------------
LOCAL fileline$, txt$ TYPE STRING
IF FILEEXISTS(FILENAME$) THEN
OPEN FILENAME$ FOR READING AS catfile
WHILE NOT(ENDFILE(catfile)) DO
READLN fileline$ FROM catfile
txt$ = CONCAT$(txt$, fileline$, NL$)
WEND
CLOSE FILE catfile
END IF
RETURN CHOP$(txt$)
END FUNCTION
x$ = CAT("myfile.glade")
Incidentally, I like the size of the generated binaries - some 26k for simple guis.
With kind regards,
vovchik
- Attachments
-
- glade-stuff.tar.gz
- (4.16 KiB) Downloaded 1181 times
Now glade xml is integrated into generated source
Dear Doyle,
I have done a little work. Please look at the attachment. I now read the glade and turn it into DATA statements and have those statements read by the generated program, so there is no external glade file needed to run the prog. Please have a look. After this, we should look at signal connects so that the buttons work.
With kind regards,
vovchik
PS. Still some work needed - getting rid of the second glade file read....
I have done a little work. Please look at the attachment. I now read the glade and turn it into DATA statements and have those statements read by the generated program, so there is no external glade file needed to run the prog. Please have a look. After this, we should look at signal connects so that the buttons work.
With kind regards,
vovchik
PS. Still some work needed - getting rid of the second glade file read....
- Attachments
-
- mkglade-new.tar.gz
- (21.63 KiB) Downloaded 1119 times
Re: Now glade xml is integrated into generated source
WOW! Very good work! Thanks!
Thank you for the ideas and the code!
Regards,
Doyle
PS: Maybe we should take this to the BaCON forum? (Or not, doesn't matter to me.)
I'll take a look at the buttons and automatically adding a "gtk_main_quit" at the correct place in the code so the generated file will end correctly.vovchik wrote:Dear Doyle,
I have done a little work. Please look at the attachment. I now read the glade and turn it into DATA statements and have those statements read by the generated program, so there is no external glade file needed to run the prog. Please have a look. After this, we should look at signal connects so that the buttons work.
I really like this way of building the new file and the way you format your code. I looked at some older *.glade files that I found just browsing around and the parsing code will have to be slightly modified in order to read these older glade files. I don't know if it's worth the effort right now.
PS. Still some work needed - getting rid of the second glade file read....
Thank you for the ideas and the code!
Regards,
Doyle
PS: Maybe we should take this to the BaCON forum? (Or not, doesn't matter to me.)
regards,
mechanic
mechanic
a bit of advice from Peter
Dear Doyle,
We seem to be getting somewhere and making progress, I think this little program has nice potential. Peter has been looking at the thread and just sent me a note, referring to his calc.bac program that also uses glade, with the following:
With thanks and kind regards,
vovchik
We seem to be getting somewhere and making progress, I think this little program has nice potential. Peter has been looking at the thread and just sent me a note, referring to his calc.bac program that also uses glade, with the following:
If you can get the buttons and quit stuff working, I think we are in business. There are lots of apps with ready-made guis that will be easy to port to BaCon and then customize. Think of all the python and c stuff, for instance. And, the binaries are small.I see the comment on top (calc.bac) has an error, because the 'export-dynamic' flag, to enable callbacks from Glade to the BaCon program, should be used with the '-o' option - this comment is corrected now.
With thanks and kind regards,
vovchik
Re: a bit of advice from Peter
Yes, I caught this too. It didn't help with the "glade_xml_signal_autoconnect" call however.vovchik wrote:Dear Doyle,
We seem to be getting somewhere and making progress, I think this little program has nice potential. Peter has been looking at the thread and just sent me a note, referring to his calc.bac program that also uses glade, with the following:
I see the comment on top (calc.bac) has an error, because the 'export-dynamic' flag, to enable callbacks from Glade to the BaCon program, should be used with the '-o' option - this comment is corrected now.
OK, I wondered why you said something about the button callback subs not being generated. It's because the glade file has no signals defined in it. I am catching the signal names and using that to generate the code. My test files just happened to have the signal code in the glade file.
If you can get the buttons and quit stuff working, I think we are in business. There are lots of apps with ready-made guis that will be easy to port to BaCon and then customize. Think of all the python and c stuff, for instance. And, the binaries are small.
Try a glade file which has the signals defined to see the callback subs being generated in the code.
I can do this without the signals defined but this would double the signal subs generated in the code. Sort of messy but one could probably catch this possibility and only generate one sub.
So what do you suggest? Try to make the callbacks without the signals being defined in the glade file or specify that the signals must be defined in the glade file if the user wants the callback subs generated for them.
I need a list of all controls that will need a callback sub generated. I have devhelp here and have tried to make such a list. Unfortunately, being new at using gtk, I may have missed some controls or added some that don't need a callback defined.
Thanks for your help. I appreciate it.
regards,
mechanic
mechanic
signals and callbacks
Dear Doyle,
Please have a look at the attached archive. Peter put together a glade.bac file that is used as an include. It has all the necessary and useful imports and libs defined. I'll re-read your message and hope to post something sensible soon regarding signals.
With thanks and kind regards,
vovchik
Please have a look at the attached archive. Peter put together a glade.bac file that is used as an include. It has all the necessary and useful imports and libs defined. I'll re-read your message and hope to post something sensible soon regarding signals.
With thanks and kind regards,
vovchik
- Attachments
-
- bvl-src.tar.gz
- (19.07 KiB) Downloaded 1133 times
Re: signals and callbacks
Thanks but I have a copy of the glade.bac file here. I may need to add all of the IMPORTs in there but for now, it seems I have all needed.vovchik wrote:Dear Doyle,
Please have a look at the attached archive. Peter put together a glade.bac file that is used as an include. It has all the necessary and useful imports and libs defined. I'll re-read your message and hope to post something sensible soon regarding signals.
With thanks and kind regards,
vovchik
Here is the latest source that I have. I am still working on automatically adding the close signal and connecting it correctly so that is not finished yet.
I am not adding the signals *IF* the user doesn't add them to the glade file in the Glade GUI designer. I don't want to second guess the user. They might not want the callbacks generated (can't see why but if they want them, they'll have to add them in the designer.)
Please share your thoughts on the code. What else is needed? What would be good to have added?
- Attachments
-
- mkglade.tar.gz
- (3.62 KiB) Downloaded 979 times
regards,
mechanic
mechanic
Latest glade converter for BaCON
Hi all, I completely rewrote the code making it simpler. Please test and let me know of any bugs. Seems to work on all of my test code here.
- Attachments
-
- mkglade-1.tar.gz
- (2.85 KiB) Downloaded 989 times
regards,
mechanic
mechanic
Dear Doyle,
GREAT work. I would do as you suggest - if no signal connect, just load the Glade file and add them. mkglade now picks up and makes the SUBs for my glade widgets. The only think that might be added as "standard" is a gtk_exit SUB by default.
I am now testing with various Glade files and will report back.
Thanks.
With kind regards,
vovchik
PS. I think
IMPORT "gtk_exit(int)" FROM "libgtk-x11-2.0.so" TYPE void
and the callback for closing a prog
' ---------------
SUB exit_prog()
' ---------------
gtk_exit(0)
END SUB
might be useful in nearly all cases.
GREAT work. I would do as you suggest - if no signal connect, just load the Glade file and add them. mkglade now picks up and makes the SUBs for my glade widgets. The only think that might be added as "standard" is a gtk_exit SUB by default.
I am now testing with various Glade files and will report back.
Thanks.
With kind regards,
vovchik
PS. I think
IMPORT "gtk_exit(int)" FROM "libgtk-x11-2.0.so" TYPE void
and the callback for closing a prog
' ---------------
SUB exit_prog()
' ---------------
gtk_exit(0)
END SUB
might be useful in nearly all cases.
nice compile
Dear Doyle,
Try compiling the attached. Works nicely.
With kind regards,
vovchik
Try compiling the attached. Works nicely.
With kind regards,
vovchik
- Attachments
-
- egdesigner.glade.tar.gz
- (5.86 KiB) Downloaded 1016 times
parsing error
Dear Doyle,
The attached glade file gives a parsing error when compiling the binary. I think mkglade is missing something or getting confused. Have a look at the generated source. Bacon will point you to the line numbers.
With kind regards,
vovchik
The attached glade file gives a parsing error when compiling the binary. I think mkglade is missing something or getting confused. Have a look at the generated source. Bacon will point you to the line numbers.
With kind regards,
vovchik
- Attachments
-
- PupWebTV.glade.tar.gz
- (941 Bytes) Downloaded 968 times
Re: parsing error
Ok, multiple signals defined in this glade file. None of the examples that I have here are like that. I hope I have it fixed. Please test and let me know.vovchik wrote:Dear Doyle,
The attached glade file gives a parsing error when compiling the binary. I think mkglade is missing something or getting confused. Have a look at the generated source. Bacon will point you to the line numbers.
This little program is looking good to me!
EDIT: The egdesigner glade file won't compile as is. I had to increase the array limits in mkglade to the following and recompile mkglade.bac:
Code: Select all
RECORD glade[1000]
LOCAL class$ TYPE STRING
LOCAL id$ TYPE STRING
LOCAL signal$[100] TYPE STRING
LOCAL handler$[100] TYPE STRING
LOCAL wtype TYPE NUMBER
END RECORD
Code: Select all
IMPORT "gtk_exit(int)" FROM "libgtk-x11-2.0.so" TYPE void
' ---------------
SUB exit_prog()
' ---------------
gtk_exit(0)
END SUB
- Attachments
-
- mkglade-3.tar.gz
- (3.01 KiB) Downloaded 966 times
Last edited by mechanic on Mon 06 Sep 2010, 17:11, edited 1 time in total.
regards,
mechanic
mechanic
weird ascii codes and mixup in sub sames
Dear Doyle,
Just tested mkglade2 and have weird sub names and other either low ascii (ACK, BS) or high ascii char appearing in sub names and bvits and pieces of the glade file (e.g. <widget>).
Please see attached file.
With kind regards,
vovchik
Just tested mkglade2 and have weird sub names and other either low ascii (ACK, BS) or high ascii char appearing in sub names and bvits and pieces of the glade file (e.g. <widget>).
Please see attached file.
With kind regards,
vovchik
- Attachments
-
- glade2bac-src.tar.gz
- (4.2 KiB) Downloaded 977 times
Re: weird ascii codes and mixup in sub sames
Weird! I looked at the *.bac file and it was messed up. I then ran mkglade3 on it and it did fine. I *think* some of the test files are not created correctly by whoever did the designing. For instance, if the glade file has a "delete_event" instead of a "destroy" the app won't close correctly. I don't know enough about he glade file format to know if this is right or not.vovchik wrote:Dear Doyle,
Just tested mkglade2 and have weird sub names and other either low ascii (ACK, BS) or high ascii char appearing in sub names and bvits and pieces of the glade file (e.g. <widget>).
Please see attached file.
BTW, a LOT of problems in the glade file can be fixed by opening the file in Glade 3.6.7, checking version and deprecations and resaving it.
Let me know if mkglade3 is ok for you.
regards,
mechanic
mechanic
glade version
Dear Doyle,
I can't really run glade 3.6.7 on my usual development machine,because I still have puppy 3.01 and it uses gtk 2.10. Glade 3.6.7 requires gtk 2.14. I had been using glade 3.0.0 but just compiled 3.2.2 using Barry's ./configure line, which worked fine. I am still getting confused SUBs (bits and pieces of the glade file being used for the SUB name - i.e. weird stuff in the generated *.bac file - and the subsequently compilation bombing). I don't know what is causing that, but I will now look at the code in mkglade-3 to see whether I can figure it out. I am intrigued, because it looks like a processing or parsing error and not necessarily glade. Old mkglade (I think from 1 am last night) works fine with those glade files.
With thanks and kind regards,
vovchik
I can't really run glade 3.6.7 on my usual development machine,because I still have puppy 3.01 and it uses gtk 2.10. Glade 3.6.7 requires gtk 2.14. I had been using glade 3.0.0 but just compiled 3.2.2 using Barry's ./configure line, which worked fine. I am still getting confused SUBs (bits and pieces of the glade file being used for the SUB name - i.e. weird stuff in the generated *.bac file - and the subsequently compilation bombing). I don't know what is causing that, but I will now look at the code in mkglade-3 to see whether I can figure it out. I am intrigued, because it looks like a processing or parsing error and not necessarily glade. Old mkglade (I think from 1 am last night) works fine with those glade files.
With thanks and kind regards,
vovchik
Re: glade version
Sorry, I didn't think about that. I'm running lucid puppy 5.01 (5.1?). I started with version 4, got all of the dev stuff on it and then when lupu came out I set it up for my bacon/bcx programming envirionment.vovchik wrote:Dear Doyle,
I can't really run glade 3.6.7 on my usual development machine,because I still have puppy 3.01 and it uses gtk 2.10. Glade 3.6.7 requires gtk 2.14. I had been using glade 3.0.0 but just compiled 3.2.2 using Barry's ./configure line, which worked fine. I am still getting confused SUBs (bits and pieces of the glade file being used for the SUB name - i.e. weird stuff in the generated *.bac file - and the subsequently compilation bombing). I don't know what is causing that, but I will now look at the code in mkglade-3 to see whether I can figure it out. I am intrigued, because it looks like a processing or parsing error and not necessarily glade. Old mkglade (I think from 1 am last night) works fine with those glade files.
I want to create a *.SFS file with all of my programming stuff in it so I don't have to manually add it when upgrading puppy. So far I've not had the time to figure that all out. I'm thinking of making something along those lines using bacon.
What version of Bacon are you using? Bash? I think Bash ver. >= 4.0 is required for the latest bacon version I have.
If you want, you can send me the glade files that don't work and I'll try them here. The last one in the attachment (PupWebTV) worked fine with mkglade3 here.
All of the other, smaller glade files seem to be ok too.
Send to:
mekanixx at gmail dot com
regards,
mechanic
mechanic