A couple of feature requests

[fragadelic]

I absolutely love BaCon. I am the dev of the project called remastersys that is a remastering tool for debian and ubuntu.

I am in the process of porting some of my stuff from bash/zenity/kdialog scripting to BaCon with hug.

I have looked around here but haven't found mention of these things so these are the 2 things I'd like to see if at all possible.

1 - progress bar

2 - to be able to place custom icons on a button

With that said, I am in the process of coming up with a progress bar using the canvas portion of hug and I'll post it when I get it done and tested.

Thanks for a great tool.

Neither of the things I mentioned are absolutely necessary but would be very nice to have if possible.

[Pjot]

Hi fragadelic,

Welcome!

For your requests, I will look at the progress bar. Thanks for your code in the other post.

The button with icon can be done with the STOCK command - is this what you are looking for? Note that you have to enable the 'buttons_have_icons' setting in Gconf. You can do this as follows:

gconftool-2 --type boolean --set /desktop/gnome/interface/buttons_have_icons 1

Best regards
Peter

[fragadelic]

From my limited understanding of the STOCK icons in gtk it seems they are limited to just those icons.

What I was thinking of was to be able to put a custom icon on a button. I'm creating a control panel for some system stuff that I created for IceWM. I launch some standard apps for stuff that I didn't make tools for or that the tools are rather complete anyway. It would be nice to include the icon of the app on these buttons.

My code I posted works but would have to be implemented in a better fashion similar to the message dialog windows so that they can be closed properly or hidden.

I have only been playing with BaCon for a few days now and I really like it. I am very impressed with what you have done.

I have included BaCon in my home remaster that I use on older desktops and laptops. Not sure if I'll bother releasing this since most folks are pretty negative towards Ubuntu remasters anyway.

I will keep developing my remastersys tool and I'm hoping to rewrite it in BaCon along with the installer.

[fragadelic]

I also have to thank Barry from Puppy. It was his release of Quirky 1.4 that introduced me to BaCon while reading his release notes. While I currently don't have an interest in Quirky it opened the world of BaCon to me. I have studied the examples on this website as well as the ones he has on his website. Great information from both places.

If I post anything here, feel free to include anything you find useful as everything I do I release under the GPL v2 or GPL v3 license.

[fragadelic]

One other thing I forgot to ask about.

Can you change the hug.bac code for MSGDIALOG so that the title can be set?

Right now is says "HUG Message" and I think it would be good to be able to define the title

MSGDIALOG "title" "text" xsize ysize type buttons

I changed hug.bac MSGDIALOG function like so:

REM --------------------------------------------------------------------------------------------------

FUNCTION MSGDIALOG (STRING title$, STRING text$, int xsize, int ysize, int type, int buttons)

   LOCAL win, table, lbl, but
   LOCAL dialog

   IF type > 4 THEN type = 4
   IF type < 0 THEN type = 0

   text$ = CONCAT$(NL$, text$)
   dialog = gtk_message_dialog_new(0, 2, type, buttons, text$, 0)

   gtk_window_set_title(dialog, title$)
   gtk_window_set_position(dialog, GTK_WIN_POS_CENTER)
   gtk_window_set_default_size(dialog, xsize, ysize)

   WITH hug_widget_properties[hug_pointer]
.widget = dialog
.font = dialog
.focus = 0
.attach = 0
.signal = 7
.s_widget = dialog
.xsize = xsize
.ysize = ysize
.grab = DUMMY_GRAB$
.text = DUMMY_TEXT
.get = DUMMY_GET
.set = DUMMY_SET
   END WITH

   hug_pointer = hug_pointer + 1

   g_signal_connect_data(dialog, "delete-event", HIDE, 0, 0, 0)

   RETURN dialog

END FUNCTION


[Pjot]

Hi fragadelic,

So I have given your ideas some thought. The concept of the Highlevel Universal Gui (H.U.G.) is a small layer on top of GTK which should allow BaCon programmers to create a GUI in a fast and efficient way. Some decisions were made an therefore some things are simply not possible - an icon on a button can be done with STOCK, but as you mention, this is limited to the predefined icons in the GTK library. That is just too bad, but for the H.U.G. concept this simply should be enough.

However, next to H.U.G. it remains possible to use plain GTK calls to setup more fancy things. So if you need an icon on a button, just create your GUI with the generic H.U.G. calls and add the icon with a plain GTK call.

The MESSAGEBOX request is easy to do as you demonstrate yourself, but the downside is that the H.U.G. API will break. Already there are a couple of applications in the field which will become incompatible once this feature is added.

Some time ago I was using a certain programming language fanatically, but the developer kept changing the API all the time. This is very frustrating as everybody needed to rewrite their applications all the time to keep up with the latest version. It is one of the main reasons I have left that language (next to some other issues like performance) and started the BaCon project.

So the stability of the BaCon API is THE number one requirement. This cannot be emphasized enough! Programs created with BaCon build 1 should still be compilable with current versions of BaCon. Therefore it is really not recommended to request for a change in the existing API.

There is nothing against adding new features though. The progressbar was a good thing to do and does not break anything. There is always flexibility to add new ideas, if they seem useful - BaCon and H.U.G. would not exist as they are now without the valuable input from many users, including you.

So to make a long story short, it does not seem a good idea to change the MESSAGEBOX (API break), nor to extend the possibilities of the STOCK buttons further (concepf of small layer starts to become GTK itself).

I hope you can agree with these ideas. If not, then as always, I am open to your suggestions or arguments to convince BaCon users (including myself) otherwise.

Thanks and best regards
Peter

[fragadelic]

The icon issue isn't a big one.

The message dialog one, on the other hand, IMHO is an issue since it doesn't look too good when you see the message dialog come up with "HUG Message"

The average end user will have no clue what this is and it would be better served to have something related to the program or message being conveyed.

A possible solution would be to add an additional function with a new name just adding the title$ to it. This way folks that would like the message box with a custom title would have it and all previous bacon programs would still work.

The current one is called MSGDIALOG so why not add one called MSGBOXDIALOG that adds the title$ option.

I fully agree with not breaking the API but extending it usefully is good. A few extra lines won't make a big difference in the hug.bac but the added function would be great.

[fragadelic]

Another option is to just change the "HUG Message" to only say "Message"

The HUG part is what is confusing especially to someone who has no clue what HUG is.

[Pjot]

The average end user will have no clue what this is

You are right about that, and an additional function to determine the title can be done. It would even be better if the same function could accept a variable amount of arguments, I am looking into that now.

Another option is to just change the "HUG Message" to only say "Message"

That is no problem, of course. I will change this shortly.

Regards
Peter

[vovchik]

Dear fragadelic,

After using BaCon for some time, as I have, you will be absolutely delighted that Peter is very cautious about changes in syntax and APIs. We can all do our little enhancements, but frequent syntax changes are not only frustrating but counterproductive - look at Vala and Genie. Peter is VERY aware of that fact. And I am glad you like BaCon. The more the merrier. I, for instance, need a slider and will just implement that via straight GTK calls. HUG and your own calls can co-exist nicely, provided you do not duplicate IMPORTs. And, as for gtk buttons, you can write a temporary gtk rc file with the icon definitions for your gtk style to take care of a one-off, non-standard button. I once did that and I think I succeeded (don't ask for details, it was long ago).


WIth kind regards,
vovchik

[fragadelic]

I didn't think about breaking the api to be truthful but that is a very good reason to keep things the same.

The possibility of variable input or just an additional function or even just to make it say Message would be good enough.

I have to say that I absolutely love BaCon and HUG. This suits me so well I can't believe it. I couldn't have come up with a better idea myself other than Barry's idea of a bash to c converter but I know that would be very difficult.

I have been scripting in bash using gtkdialog,zenity,dialog,xdialog and kdialog for a long time but I like BaCon much better.

I also really appreciate the fact that Peter is so accepting to ideas for improvements,etc. I should have known about breaking the api since I am the same way with my remastersys program. I get requests from people but they usually are desktop environment specific or just specific to their needs and adding them or making changes to accomodate their ideas would break everything else.

I'll have to study how to include other gtk calls but for now HUG meets all of my needs quite well and is very easy to use.

I am just sorry I never came across BaCon earlier. It truly fits me like a glove. I got my start with computers on an Apple II at school and then later got a Vic 20 for home. Those bring back many great memories.

[Pjot]

I got my start with computers on an Apple II at school and then later got a Vic 20 for home. Those bring back many great memories.

Well I started the same way, and it's cool you do recognize the same VIC-20 feeling, as this was intended to be so

Regards
Peter

[Pjot]

Hi Fragadelic,

I forgot to mention, the titles for the dialogs (both msgbox and selector) were changed.

Best regards
Peter