Almas Designer: Second development preview version released
Almas Designer: Second development preview version released
Hi!
I've released the second development version of my Almas Designer: a dialog editor for wxWidgets. It is still too new, but I'll become happy if you test it and let me know about your opinions about it, specially about it's style of code generation.
Home Page: http://almas.sourceforge.net
Thanks!
I've released the second development version of my Almas Designer: a dialog editor for wxWidgets. It is still too new, but I'll become happy if you test it and let me know about your opinions about it, specially about it's style of code generation.
Home Page: http://almas.sourceforge.net
Thanks!
Yes! An screenshot is available here: https://sourceforge.net/project/screens ... _id=144105
(It's scaled down to 640 * 480)
(It's scaled down to 640 * 480)
Thanks!
About the differences, well, some of them are what I prefer personally; so others may don't like them at all!! So, I'm not going to say that my program is better.
One of them is event handling support. You can set event handlers for widgets and the program will create an empty handler for you.
Another one is the generated code. You are not forced to derive a new class from the class which the program generates and you can edit the class directly. However, the program doesn't generate a lot of comments in the code.
Also, some additional properties are supported by my program such as stock buttons (the downloadable version doesn't support them very well, but the latest code supports it).
Finally, Almas designer is just a bit different; and might not be better.
Currently, you can't draw the components by mouse; but you are allowed to not using sizers. X/Y and width/height properties are available and the position and dimensions of the components can be controlled by them. Yes, it's not an easy way for doing so and the program can be called as a sizer based editor (at least currently).
Sorry if it's a bit long
About the differences, well, some of them are what I prefer personally; so others may don't like them at all!! So, I'm not going to say that my program is better.
One of them is event handling support. You can set event handlers for widgets and the program will create an empty handler for you.
Another one is the generated code. You are not forced to derive a new class from the class which the program generates and you can edit the class directly. However, the program doesn't generate a lot of comments in the code.
Also, some additional properties are supported by my program such as stock buttons (the downloadable version doesn't support them very well, but the latest code supports it).
Finally, Almas designer is just a bit different; and might not be better.
Currently, you can't draw the components by mouse; but you are allowed to not using sizers. X/Y and width/height properties are available and the position and dimensions of the components can be controlled by them. Yes, it's not an easy way for doing so and the program can be called as a sizer based editor (at least currently).
Sorry if it's a bit long
Hi heda,
it seems that your tool is very similar to wxFormBuilder, how usable/stable is it right now?
Did you know about wxFormBuilder before start to develop your program?
wxFB also works on Linux, oh yes, it's not perfect, but it's opensource, and I invested much time on it. Before start wxFB I was looking for a opensource gui editor that let me add my custom widgets (and contribs) into the editor easily and I didn't find any.
After the first release, a few projects were born for wxWidget GUI design but it seems that nobody works on a plugin (DLL) extension mechanism. All editor that I know lack this feature and wxFB implement an approach that has many limitations.
Please, consider join to wxFB Team.
Regards,
Jos
it seems that your tool is very similar to wxFormBuilder, how usable/stable is it right now?
Did you know about wxFormBuilder before start to develop your program?
wxFB also works on Linux, oh yes, it's not perfect, but it's opensource, and I invested much time on it. Before start wxFB I was looking for a opensource gui editor that let me add my custom widgets (and contribs) into the editor easily and I didn't find any.
After the first release, a few projects were born for wxWidget GUI design but it seems that nobody works on a plugin (DLL) extension mechanism. All editor that I know lack this feature and wxFB implement an approach that has many limitations.
Please, consider join to wxFB Team.
Regards,
Jos
Please join wxFB
I second Jos
Hi!
Yes, my tool is similar to yours to some extent! About it's usability, well, it is not usable currently as it has only 6 widgets (however, I've implemented 6 new ones yesterday). And I have not tested it much but I think it is fairly stable (It shouldn't crash).
Before starting thinking about writing this program, I had an older version of wxFB. But I should admit that I didn't expect such a fast progress in it's development. (Your program is really nice, I have downloaded a new version recently.) Also, (I don't know why but) I don't like subclassing approach very much; and I liked some features which I didn't find in wxFB. So, I decided to work on them. I thought about extending your code, but, I'm just a kid programmer and I really scared when faced with many source files your program has. Also, unfortunately I can't understand your language and so I can't get anything from your comments in the code.
Finally, I found that writing such a program from scratch will help me a lot to learn wxWidgets more as I'm new to it too!
I really respect the time you've spent on it, keep the good work.
Currently, I've spent some time on Almas and I can't stop working on it at this time; and as we are using different approaches, I think it's not possible (at least I'm not able) to merge my code in yours. Thanks a lot for your invitation.
Plugin support was in my mind when I decided to work on this program, and the program structure is based on this idea. Currently, there is no plugin loader in the program (as I don't expect anyone willing to write plugins for my app! at least currently) but it doesn't need much work (I think!).
I don't know what do you mean by talking about "limitations" so I can't compare it with my approach.
Thanks again
Hedayat
Yes, my tool is similar to yours to some extent! About it's usability, well, it is not usable currently as it has only 6 widgets (however, I've implemented 6 new ones yesterday). And I have not tested it much but I think it is fairly stable (It shouldn't crash).
Before starting thinking about writing this program, I had an older version of wxFB. But I should admit that I didn't expect such a fast progress in it's development. (Your program is really nice, I have downloaded a new version recently.) Also, (I don't know why but) I don't like subclassing approach very much; and I liked some features which I didn't find in wxFB. So, I decided to work on them. I thought about extending your code, but, I'm just a kid programmer and I really scared when faced with many source files your program has. Also, unfortunately I can't understand your language and so I can't get anything from your comments in the code.
Finally, I found that writing such a program from scratch will help me a lot to learn wxWidgets more as I'm new to it too!
I really respect the time you've spent on it, keep the good work.
Currently, I've spent some time on Almas and I can't stop working on it at this time; and as we are using different approaches, I think it's not possible (at least I'm not able) to merge my code in yours. Thanks a lot for your invitation.
Plugin support was in my mind when I decided to work on this program, and the program structure is based on this idea. Currently, there is no plugin loader in the program (as I don't expect anyone willing to write plugins for my app! at least currently) but it doesn't need much work (I think!).
I don't know what do you mean by talking about "limitations" so I can't compare it with my approach.
Thanks again
Hedayat
Oh, sorry buildere, I've written the previous answer before reading your post! You're right, but I think that merging the codes are not easy. When I wanted to start working on the program, I felt that it's much harder for me to implement my ideas in another one's work than writing from scratch. Also, I thought that the main author may don't like what I want to do.
However, I think that it is not that bad: wxDesigner and DialogBlocks are commercial, wxRapid and wxDevCpp are Windows only (AFAIK). It is the first time I am hearing about wxSmith, and I don't remember anything about visualwx (is it a free linux designer?!).
Oh..no, I don't know if I'm right! But, if I'm unable to join wxFB, I'll try to present some real differences
Thanks
However, I think that it is not that bad: wxDesigner and DialogBlocks are commercial, wxRapid and wxDevCpp are Windows only (AFAIK). It is the first time I am hearing about wxSmith, and I don't remember anything about visualwx (is it a free linux designer?!).
Oh..no, I don't know if I'm right! But, if I'm unable to join wxFB, I'll try to present some real differences
Thanks
Probably this approach is the easiest way to implement code generation. In my opinion, is more elegant create a subclass in other file than editing generated file. Dialogs often have a lot of GUI code, it can be hard to read a source file that mix GUI code with your functional code. With this approach, your application will be more readable and let you make GUI modifications safely.heda wrote:Also, (I don't know why but) I don't like subclassing approach very much; and I liked some features which I didn't find in wxFB
what features do you miss on wxFB?
Yes, I must translate itheda wrote:Also, unfortunately I can't understand your language and so I can't get anything from your comments in the code.
Perhaps you can't merge your code, but if you want to follow with Alma development, you have to write and debug many things that are implemented on wxFB.heda wrote:I think it's not possible (at least I'm not able) to merge my code in yours. Thanks a lot for your invitation.
The question is:
Can you implement an special feature that you need on wxFormBuilder?
or are your forced to write another program from scratch?
wxFB plugin interface is very simple, it creates a wxObject (wxWindow/wxSizer) instance from an object-tree-node (IObject). You can't access to other nodes (parent/children) so there are problems with components such wxNoteBook or wxSplitterWindow. There are patches on wxFB code to handle these components, so plugin interface needs a new design. wxFB must be unaware of concrete components, it must handle all of them in a same way. It's not true in the current code.heda wrote:I don't know what do you mean by talking about "limitations" so I can't compare it with my approach.
Regards.
Yes, I'm agree with you. But I don't mix the GUI code with the rest of the class. All of the GUI creation is done in a single file in my program.Dialogs often have a lot of GUI code, it can be hard to read a source file that mix GUI code with your functional code.
As I'm not much fimilar with your code, I can't answer you correctly. But I thought that it might be hard for me when I was thinking about implementing my ideas.Can you implement an special feature that you need on wxFormBuilder?
About the plugins, well in this special situation I think my plugins are a bit more flexible than yours, in the other hand, they are a bit more complicated to write. They are responsible to do many things, such as their own code generation.
As I've said, most of them are some personal preferences or small things such as event handling support and the code generation style I've mentioned before. Also I said that when I decided to write my own, your program didn't have much widgets. But Almas's base structure is almost finished (except the XRC generation) and I can't leave it.what features do you miss on wxFB?
Good Luck
Re: Please join wxFB
wxWorkshop has not been abandoned. There are 3 of us working on it:buildere wrote:some of them abandoned like ... wxWorkshop.
http://wxworkshop.sourceforge.net/news.htm
I'm currently fixing the autoconf packages for the Linux version of it, and we're getting into debugging the main problems now with the current wxWorkshop build, using wxWidgets-2.6.1, before we start to finally implement those features that have been missing out of it. New source code is in the CVS Repository. It is now building under Linux (with the gcc-4.0.1 compiler), and MS Visual Studio 2003.
--James