A while ago, I started working on a GUI project designer for fb (which I haven't released any code yet) and I initially aimed for full compatibility with VB.
But now, I realize that VB compatibility may not be desirable. I mean, there are lots of vb clones floating around, from hbasic to kbasic (and even Qt to some extent -- don't flame me about this ;)
Also, micro$hit has dropped support of VB6, and VB.NET is very hard to reproduce outside of windows using open-source software.
Right now, I'm more inclined on having something that does what people want, instead of just a blind imitation of what M$ did more than a decade ago. This could be a community project that turns out to be entirely original and fun.
So, give your ideas -- what features would you want in a GUI development platform? Be crazy -- let go of your innermost banal desires you want in a graphical development system.
Okay, I'll start: My favourite feature would be a fast, simple graphics interface for rapid deployment of gfx demos.
GUI Designer thoughts
Hi acetoline,
First of all, I would like to tell you that I am following your and jofers' posts on your work on a GUI designer for a time now and this makes me feel confident on the future of FB. Some time ago, not knowing the Win32 API at all and thinking it was a GUI designer, I wrote a post to Ketilo on the FBIde (RADAsm) topic. As I found it still reflects my current thoughts on the subject, I am pasting it below. My apologies if you find it long or have already read it before:
"Without any intent of making you feel "responsible" of this huge task, but rather using this place as a platform to share my opinion with all the community of advanced Freebasic programmers (because writing such an application is anything but trivial), I sincerely think that the most urgent addition needed to the "Freebasic software arsenal" is a Gui Designer.
IMO, this is CRUCIAL in order to get an even larger audience to FB and also VERY important to bring professional programmers to use Freebasic in their daily work. It is also significant to keep the existing user base "loyal" to FB in allowing them to, when they feel capable of, go further, from "hobby programming" with FB, to professional programming with FB, without switching to another language like VB or C, C++... just because they would be otherwise limited either to program "console" (not GUI) applications or to make them but entirely by hand, which is real pain.."
Now about the features I find necessary or useful:
1) Support of a good bunch of controls or support of a set of basic controls with the possibility to implement newer ones later (perhaps as "plugins"?).
2) Support of a sort of form to put all these controls on.
3) A software implementation for using the controls (in the software you write with the GUI designer) which are as concise as possible but still mnemonic, especially if a feature like "autocomplete" as you type for objects and methods is not implemented.
4) To be talked about once 1), 2) and 3) are available which is already quite a lot of work :)
I hope that I have not once again misunderstood (as I did for FBEdit) what you mean by GUI designer. What I understood you are willing to make or contribute to is a GUI based RAD designer, with the same paradigm as VB, but using FB as the underlying language and compiler. So, an event-based dev. system.
Zek.
First of all, I would like to tell you that I am following your and jofers' posts on your work on a GUI designer for a time now and this makes me feel confident on the future of FB. Some time ago, not knowing the Win32 API at all and thinking it was a GUI designer, I wrote a post to Ketilo on the FBIde (RADAsm) topic. As I found it still reflects my current thoughts on the subject, I am pasting it below. My apologies if you find it long or have already read it before:
"Without any intent of making you feel "responsible" of this huge task, but rather using this place as a platform to share my opinion with all the community of advanced Freebasic programmers (because writing such an application is anything but trivial), I sincerely think that the most urgent addition needed to the "Freebasic software arsenal" is a Gui Designer.
IMO, this is CRUCIAL in order to get an even larger audience to FB and also VERY important to bring professional programmers to use Freebasic in their daily work. It is also significant to keep the existing user base "loyal" to FB in allowing them to, when they feel capable of, go further, from "hobby programming" with FB, to professional programming with FB, without switching to another language like VB or C, C++... just because they would be otherwise limited either to program "console" (not GUI) applications or to make them but entirely by hand, which is real pain.."
Now about the features I find necessary or useful:
1) Support of a good bunch of controls or support of a set of basic controls with the possibility to implement newer ones later (perhaps as "plugins"?).
2) Support of a sort of form to put all these controls on.
3) A software implementation for using the controls (in the software you write with the GUI designer) which are as concise as possible but still mnemonic, especially if a feature like "autocomplete" as you type for objects and methods is not implemented.
4) To be talked about once 1), 2) and 3) are available which is already quite a lot of work :)
I hope that I have not once again misunderstood (as I did for FBEdit) what you mean by GUI designer. What I understood you are willing to make or contribute to is a GUI based RAD designer, with the same paradigm as VB, but using FB as the underlying language and compiler. So, an event-based dev. system.
Zek.
My idea would be to create a GUI designer in the following way. You can design forms, put controls on them, use events, etc and the program should automatically generate the .bas file needed. It should also save the layout of the forms, controls as comments in the bas file in order to easily recognize them later. And when a user writes the code for an event, it should also be saved in the .bas file, but the users should only see the code they are writing.
This way a project can easily be compiled even if the designer is not installed and the code could also easily be changed if needed.
This way a project can easily be compiled even if the designer is not installed and the code could also easily be changed if needed.
I would think this is important for FB too. But wouldn't the first step be to agree on which GUI library to use? I see a few different projects going on (C wrap of wxWidgets, Eodor's Simple GUI, Sis...' BCXGui, and some GUI's that are implemented in gfxlib only).
My $0.02 , take the library that does the best on these:
A professional look, because many end users don't trust "crude GUIs" for professional programs.
Has tons of example code, thereore migration is easy.
Can code in ASCII text
Handles events easy (like Form.OnClick = MyClickSub) rather than WndProc
My $0.02 , take the library that does the best on these:
A professional look, because many end users don't trust "crude GUIs" for professional programs.
Has tons of example code, thereore migration is easy.
Can code in ASCII text
Handles events easy (like Form.OnClick = MyClickSub) rather than WndProc
And the following should be kept in mind:
- speed. fast drawing
- normal memory consumption
- relatively small output file size (perhaps if an external lib is used it should be dynamically linked)
It would also be great if it would be multiplatform. But I think in order to achieve this it would be better for the gui to be coded separately for each os, or to use wxwidgets.
- speed. fast drawing
- normal memory consumption
- relatively small output file size (perhaps if an external lib is used it should be dynamically linked)
It would also be great if it would be multiplatform. But I think in order to achieve this it would be better for the gui to be coded separately for each os, or to use wxwidgets.
-
joseywales72
- Posts: 206
- Joined: Aug 27, 2005 2:02
- Location: Istanbul, Turkey
I think, first and foremost, a FB GUI must be multiplatform. I agree with JohnK about professional look and this leads me to a conclusion of a tried and tested GUI library idea. My candidate here is GTK. It is portable, written in C, actively developed and has a large user base. Also GTK headers are already translated into FB.
There would be some objections to GTK, I'm aware of its shortcomings. It's bloated, needs a huge runtime. Also some may say that it already has a GUI designer, namely Glade,so why bother? Etc. etc..
But in defense of GTK, I say that, we can make GTK more usable and accessible to FB users by wrapping it a la QGTK. http://www.geocities.com/hebrak/gnu/qgtk_en.htm
My two cents...
Anil
There would be some objections to GTK, I'm aware of its shortcomings. It's bloated, needs a huge runtime. Also some may say that it already has a GUI designer, namely Glade,so why bother? Etc. etc..
But in defense of GTK, I say that, we can make GTK more usable and accessible to FB users by wrapping it a la QGTK. http://www.geocities.com/hebrak/gnu/qgtk_en.htm
My two cents...
Anil
I've just looked at QGTK and it seems to me that this is a really interesting way of creating a simple and usefull class for GUI programming. I think that someone would try to tralnslate the source code from Pascal to FB (it doesn't seem a very difficult taskl, all that is needed is the necessary time).joseywales72 wrote:I think, first and foremost, a FB GUI must be multiplatform. I agree with JohnK about professional look and this leads me to a conclusion of a tried and tested GUI library idea. My candidate here is GTK. It is portable, written in C, actively developed and has a large user base. Also GTK headers are already translated into FB.
There would be some objections to GTK, I'm aware of its shortcomings. It's bloated, needs a huge runtime. Also some may say that it already has a GUI designer, namely Glade,so why bother? Etc. etc..
But in defense of GTK, I say that, we can make GTK more usable and accessible to FB users by wrapping it a la QGTK. http://www.geocities.com/hebrak/gnu/qgtk_en.htm
My two cents...
Anil
The programs written with QGTK are very concise and simple. I like this work.
The last thing you want to do is rely on external libraries for this kind of thing. I think that's one of the largest problems. For Windows, you're best off using the Windows API for GUI development, because it doesn't get any faster, more efficient, or small (code-wise) than that. As soon as you start using a third-party GUI library, you're hosed on all three counts, ESPECIALLY on size. For *nix, you might have little choice but to use a library of some kind...most are GTK-based afaik. Using GTK in the Windows environment is a recipe for disaster, only a very very few applications developed with GTK for Windows turn out very good at all, and then it's still at the expense of size.
There's some tradeoff to be done when it comes to multiplatform GUI development. You can go generic (using GTK, wxwidgets, etc) and sacrifice size fo ease of development (YOUR development, not that of the end-user), or you can go OS-specific, which will be the most efficient and space-saving at the expense of your own development time. You simply can't have both.
When I started working on my FBXL project, I had no intentions of making it cross-platform simply because it's better to have a perfect system on one platform than a broken, bloated, slow, etc. system on multple platforms.
There's some tradeoff to be done when it comes to multiplatform GUI development. You can go generic (using GTK, wxwidgets, etc) and sacrifice size fo ease of development (YOUR development, not that of the end-user), or you can go OS-specific, which will be the most efficient and space-saving at the expense of your own development time. You simply can't have both.
When I started working on my FBXL project, I had no intentions of making it cross-platform simply because it's better to have a perfect system on one platform than a broken, bloated, slow, etc. system on multple platforms.
Although I like the cross-platform idea in itself, in practice as some of you have already stated, it has some drawbacks:
1) Size of executable. I remember trying a RAD environment using Wx Widgets generating an exe of 2 Mb or more just for a "Hello Word!": AHEM...
2) The used GUI should work in a way end users on the platform are used to. IMO, the finished application should not "destabilize" the end user introducing a different feel for basic operations.
For example, as a Windows user, one thing I really do not like is the kind of file boxes or directory boxes GTK produces: you can not (at least I have not seen any) organize the displayed files by date, type, size, ... before deciding which one to open or save.
3) The used GUI should not induce noticeable overhead at execution time. Once again it looks to me that GTK apps in windows bring some lagging when manipulating menus or other objects, etc..
So maybe the best way to do this is not to code a cross-platform system directly but coding a system which could be "relatively easily" adapted to another platform (a good part of it being modular?).
Z.
1) Size of executable. I remember trying a RAD environment using Wx Widgets generating an exe of 2 Mb or more just for a "Hello Word!": AHEM...
2) The used GUI should work in a way end users on the platform are used to. IMO, the finished application should not "destabilize" the end user introducing a different feel for basic operations.
For example, as a Windows user, one thing I really do not like is the kind of file boxes or directory boxes GTK produces: you can not (at least I have not seen any) organize the displayed files by date, type, size, ... before deciding which one to open or save.
3) The used GUI should not induce noticeable overhead at execution time. Once again it looks to me that GTK apps in windows bring some lagging when manipulating menus or other objects, etc..
So maybe the best way to do this is not to code a cross-platform system directly but coding a system which could be "relatively easily" adapted to another platform (a good part of it being modular?).
Z.
Thanks for the feedback, guys. I'm not really fond of using gtk, but there doesn't seem to be any other way for reaching cross-platform compatibility fast.
Right now, I think it's best to continue on a windows-only implementation. The library is difficult to choose, because the current gui systems available are either not compatible with an object-oriented, event-driven interface, or are incomplete.
TheScorp, thanks for your suggestions. That's basically whats on the list right now.
Currently, the biggest obstacle that I am facing (perhaps because of my n00b-ness) is a good way to get editable forms working (under windows for now). What I mean is something like a dialog-box editor.
I haven't found any resources on how to code something like this, for example: you drag your mouse to create a textbox on a form.
It's always possible to fake it, but I really don't like that option. I would really appreciate if anybody could point me in the right direction here.
Right now, I think it's best to continue on a windows-only implementation. The library is difficult to choose, because the current gui systems available are either not compatible with an object-oriented, event-driven interface, or are incomplete.
TheScorp, thanks for your suggestions. That's basically whats on the list right now.
Currently, the biggest obstacle that I am facing (perhaps because of my n00b-ness) is a good way to get editable forms working (under windows for now). What I mean is something like a dialog-box editor.
I haven't found any resources on how to code something like this, for example: you drag your mouse to create a textbox on a form.
It's always possible to fake it, but I really don't like that option. I would really appreciate if anybody could point me in the right direction here.
You are welcome acetoline.
I have personally no idea about how to perform this (I am currently a novice VB-FB programmer with no knowledge of the Win32 API yet).
However, if you need an address, I believe KetilO, the author of RadASM and FBedit is a kind of wizard who knows exactly how to perform this. Furthermore from their topic, I read that FBEdit is currently written with FBEdit, that is IMO in FB using FBEdit as an editor :)
So if he is wishing to help, I definitely believe this is one of the right guys to ask to.
Z.
I have personally no idea about how to perform this (I am currently a novice VB-FB programmer with no knowledge of the Win32 API yet).
However, if you need an address, I believe KetilO, the author of RadASM and FBedit is a kind of wizard who knows exactly how to perform this. Furthermore from their topic, I read that FBEdit is currently written with FBEdit, that is IMO in FB using FBEdit as an editor :)
So if he is wishing to help, I definitely believe this is one of the right guys to ask to.
Z.
I have just downloaded the last version of FBEdit and you know what?
One of the sample projects is, well, the FBEdit sources in FB ;)
Thank you KetilO!!
As it has a Dialog/Form editor, controls, properties etc, I believe there is a lot to learn from it.
The URL is
http://www.assembler.ca/radasm/Upload/FbEdit.zip
I hope that helps.
Z.
One of the sample projects is, well, the FBEdit sources in FB ;)
Thank you KetilO!!
As it has a Dialog/Form editor, controls, properties etc, I believe there is a lot to learn from it.
The URL is
http://www.assembler.ca/radasm/Upload/FbEdit.zip
I hope that helps.
Z.