Peter has released his beta v. 2. Check out his site (bottom of my first post).

I have played around with Peter's hug library, which enables GTK GUIs to be created pretty painlessly. Attached is a little program that displays pngs and gifs, shows how to create buttons and to launch child windows, and how to run external progams and get the stdout results back for further processing. A bit of string handling is also in there.

The archive also includes a functioning binary and the hug lib. With a little work, this prog could also become a general pic viewer - although we already have two of Mark's excellent contributions (although they don't run on old puppy versions).

I think you can con bcx basic into giving you gcc code and compiling for linux, you also have a mostly compatable interpeter availabe you would want the one from the yahoo group and you would need a dos emulator for it (unless there is a llinux version I am unaware of). It works with at least 7 c compilers including gcc, windows ce and the wii a. sorry if this is to off topic.I have some expierence with it as a package that may be transferable to the bash one also if someone is after more tools for it and has python with thier version of puppy linux(I haven't tried it yet, I think I have a bash for windows as well as linux so it sounds like it could be cross platform ). .

here is one of my tools for example, I can easily come up with source to html and maybe an ide with highlighting. between bcx basic and csound I have done alot of this type of thing.

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.

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.

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!

Quote:

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.

Thanks go to your BaCON examples and the examples of others. I learned a lot from browsing the code.

Regards,
Doyle

PS: I'm working on the gui with the original FreeBasic code from here:

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:

xml = glade_xml_new_from_buffer(Calc_Gui$, LEN(Calc_Gui$), 0, 0)

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):

Code:

' --------------------
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")

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.

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.

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.

Quote:

PS. Still some work needed - getting rid of the second glade file read....

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.

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

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:

Quote:

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.

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.

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:

Quote:

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.

Yes, I caught this too. It didn't help with the "glade_xml_signal_autoconnect" call however.

Quote:

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.

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.

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.

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.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum