Anyone interested in collaborating on a RAD

[vovchik]

Dear guys,

Einstein's method comes to mind:

Einstein is quoted as having said that if he had one hour to save the world he would spend fifty-five minutes defining the problem and only five minutes finding the solution.

I tend to agree, and we should, in a nice co-operative way, offer suggestions. As mobeus has done this already, he could provide real guidance for the project or a general scheme that he knows works for this type of endeavour. We probably shouldn't "wing it", although somebody has to make a start.

With kind regards,
vovchik

[fragadelic]

This was initially to see if there was interest and if anyone was willing to work on it. I think it is too much for 1 person to undertake.

My vision of it is to support everything hug currently supports in the same manner that hug uses it. Basically a gui frontend to hug building.

If we decide to do this then we will need to clearly define the goals and divide up the work.

If they could create the Gambas IDE/RAD in Gambas then we should be able to create and IDE/RAD for bacon using bacon and hug.

I think it would probably be easier to have the gui drawn on a canvas that would be easier to manipulate. If we can add an option to preview in realtime without compiling then this would be good.

[fragadelic]

Just to clarify what my intentions of this thread were. I know what options are available as alternatives but I would like to see something that comes from within bacon/hug that could become an official rad/ide for bacon/hug.

The Gambas style of IDE/RAD is much better than Glade or any other addon component. Having it native to the programming language is a must.

[vovchik]

Dear fragadelic,

I agree with you. It should be native - HUG/gtk or gtk/BaCon - generating appropriate imports. And the code generated should be readable, so that it can be tweaked and non-gui functions and subs added easily.

With kind regards,
vovchik

PS. There was a simple gui builder thingy in wxbasic that we could look at. I can't now find the source, though.

[fragadelic]

Any additional info or examples would be great. This is starting to look like there is enough interest to at least give it a shot.

[bigbass]

I agree with you. It should be native - HUG/gtk or gtk/BaCon - generating appropriate imports.

+1 if you change the syntax in any way so that it is not compatible with BaCon or HUG
I am not interested but if this is a predefined goal to be compatible with BaCon and HUG all is possible and will help in what can

Any additional info or examples would be great. This is starting to look like there is enough interest to at least give it a shot.

I do believe that a first step needs to be dominated and that is a deep understanding of this
Adding self-defined widgets to HUG
basic-converter.proboards.com/index.cgi?board=doc&action=display&thread=275

yes you could start with widgets that are already provided in HUG
but by adding a new widget to HUG it will from the start be compatible
and will advance HUG at the same time ;D

Joe

[fragadelic]

It has to produce code just like if you manually entered it in. That is my vision of it anyway.

that way if you wanted to tweak some small portion of it, you could either do it by gui or quickly just edit the bac file.

[fragadelic]

I actually see this kind of replacing hug in a sense as you wouldn't need to know the code explicitly anymore.

[Pjot]

Folks,

I've been reading this thread with a lot of interest. Of course, building a RAD has come to my mind a couple of times in the past. Other people have asked for it.

But it really is a lot of work. Really.

Mobeus is right with his remarks on the design. Implementing a RAD also assumes a lot of knowledge on GTK. It will require all kinds of stuff which is not available in HUG right now, like drag 'n drop, drawing a grid on a form, resizing of widgets on-the-fly and small things like images on buttons, particular mouse event handling on non-canvas widgets etc.

The suggestion of fragadelic, e.g. using a plain canvas for it all, could solve a lot of these issues. But it will remain a lot of work nevertheless. Also drawing on a canvas does not really show how the resulting GUI will look like. I don't see how a 'preview without compilation' can be achieved.

As alternative we could use Glade, like JRS suggested. Not in the sense of adjusting Glade itself to generate BaCon code of course. But it would not be too difficult to create an XML parser which translates Glade generated XML code to BaCon/HUG. Of course, issues remain like how to deal with widgets which are not available in HUG. One needs to know which widgets are allowed and how to use them. Maybe showing a warning already is enough.

But I like the remark from fragadelic, where he says that one "wouldn't need to know the code explicitly anymore". That would be nice. With the Glade approach it then could also be decided to leave HUG, and generate BaCon code from Glade XML strings, but based on real GTK calls. That would broaden the possibilities of a GUI also. Any callbacks or user-defined BaCon code can be isolated in separate functions which are created in one BaCon source file. You would only need to fill in these functions.

As a personal note, I always find it difficult to put energy into something which already exists. I don't like to re-invent the wheel. The BaCon project should be fun. It should not become a job. With Glade, a GUI builder already is in place. Why not use it? It needs a translator to convert the Glade generated XML strings to BaCon code. Of course, I am not sure how feasible this is. Probably there are issues where different Glade versions generate different XML strings. One still needs to know a lot of GTK. It still will be a lot of work. Nevertheless, to me it sounds like a project which is more fun.

Best regards
Peter

[Deleted]

To be honest, I'm not sure if there is a need for a GUI builder for HUG. HUG is straightforward and extremely easy to use. Even with a complex interface it shouldn't take more than an hour to build it. Something that would work directly with GTK would be, obviously, more useful.

Don't get me wrong. If creating a GUI builder for HUG is a challenge for you, there is nothing wrong with doing it. But there is no point to spend time (a lot of time) on it, if you thinking about it as a tool for other BaCon users.

[fragadelic]

Tomaaz,

Having a gui builder would have been great for a serious project like mine. Take a look at my remastersys-gui frontend I created in bacon/hug for my remastersys project. There are multiple windows with different options on them. This would have been much easier and quicker with a gui rad. Most of the code that gets posted here are small snippets and proofs of concept. I have used bacon/hug to create a real working application that has been released to my userbase on both 32 bit and 64 bit Ubuntu.

You can see it on my website www.remastersys.com/ubuntu.html

Pjot,

I am really not a big fan of Glade but would go with what the consensus decides. One of the issues with Glade and debian/Ubuntu right now is the mix of gtk2 and gtk3 apps. The glade files are completely different.

Glade frequently crashes on Ubuntu 12.04 especially if you use glade2. This is why I believe a standalone gui/rad built from bacon/gtk would be the way to go.

I think a gui/rad would make bacon a more serious option for building apps in linux and it can still remain fun without making it a lot of work. I think we have enough folks here that showed interest and can help with code and testing.

[mobeus]

Tomaaz is right, there is no real need for one. BUT, a community project to build a gui designer is a lot of fun, and it is a great learning experience for everyone, not to mention how much it would improve the user experience with BaCon. Just set realistic goals to begin with and don’t try to make it fancy. The project I was involved with used a language of limited capabilities and BaCon is much more capable than that one ever was.

BaCon as a language has everything you need. HUG does not, but that is not an issue. The goal is to create a designer that will let you build a gui composed of HUG widgets. The designer will have to be created with gtk, we might as well accept that as a given.

The difficult part is the user interface.
To determine if this idea is even feasible you first need to be able to create a window with a working surface, place a widget (a button will do) on the surface and be able to select it, move it around, and resize it. If we can accomplish this much the rest is easy. What will work to our advantage is the GtkFixed layer that HUG uses for the widget container. I think we can ignore the table layout to begin with.

Real widgets or rendered;.
Both have advantages and disadvantages. Real widgets look, well real and rendered widgets usually don’t. Rendered widgets have to be drawn, and someone has to draw every single one of them somehow. Real widgets simply get created. Real widgets lend easier expandability to the designer, it’s easier to add new widgets and it might even be possible to support widgets added to HUG by the user. The user will expect an ID label on each widget. That can be a pain with rendered widgets when the user resizes one. I highly recommend we try to use actual gtk widgets if possible.

Another thing, sizing and especially moving a widget should use a drawn rectangle to indicate size and movement. Continuously refreshing the window, redrawing, resizing, or moving the widget (either rendered or real) while following the mouse movements is always cpu intensive, jerky and slow. Move / resize the widget one time when the mouse is released.

BTW, you do not need drag & drop at all. The widget pallet can be a simple toolbar, click the widget you want and it can either be created at 0,0 right then, or you can accept a mouse click to place it at a specific location.

So what do you say guys?

Regards,
Mobeus

[2lss]

Hi guys.

This sounds very neat so I figured I would throw in my $0.02...

I think using HUG widgets/syntax is a great idea... but only for the gui designing part. I think that the actual 'generated code' should be straight gtk rather than hug imports. That way you get the simplicity of HUG but it would be easily extendable with other gtk widgets. You could probably just include the hug code and then figure out a streamlined way of adding other widgets using METHOD and REGISTER.

As far as the glade xml parser idea goes, The overall concept of designing a gui is good but glade seems way too unstable for use in a project like this. I wonder how hard it would be to port some of the glade code over to bacon (the non-broken parts)?

Actual widgets vs. rendered widgets: I think actual widgets would be nicer but initially it may be better to use plain boxes instead (until the bugs are worked out).


Those are just my opinions. I will help out in any way I can.

[vovchik]

Dear guys,

For what it's worth, Doyle and I worked on a glade2bac prog (old glade) some 2 years ago. Here it is. It is not RAD at all, but translates glade into bac.

With kind regards,
vovchik

Attachments:

[Pjot]

Thanks vovchik,

I forgot about this one completely. This program generates the BaCon template for callback functions. If it is extended so it also generates the IMPORT's and corresponding GTK calls, it would be a complete XML-to-BaCon converter already...

Regards
Peter