Author Topic: RAD TOOL developers wanted  (Read 72628 times)

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
RAD TOOL developers wanted
« Reply #60 on: May 25, 2005, 09:56:45 am »
It seems that RAD development got little bit weird.
As I undedrstant we currently have:
upCASE-s standalone app
wxFormBuilder also stasndalone app
wxSmith (mine) plugin only.
thedeurf also started to work on his own plugin but he decided to join me

IF nothing will be changed,  there will be three different plugins for wxWidget RAD development. Somehow it's good because developers will be able to choose what they want. But shouldn't C::B has one RAD tool system ? And if Yes, which one of projects mentioned above should be used ? (I guess that nobody would like to abandon his project so this may be a serious problem ;) )

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
RAD TOOL developers wanted
« Reply #61 on: May 25, 2005, 10:17:04 am »
Perhaps we could merge the projects, and get the best out of them ?
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

upCASE

  • Guest
RAD TOOL developers wanted
« Reply #62 on: May 25, 2005, 10:32:37 am »
Hi!
Quote from: byo

IF nothing will be changed,  there will be three different plugins for wxWidget RAD development. Somehow it's good because developers will be able to choose what they want. But shouldn't C::B has one RAD tool system ? And if Yes, which one of projects mentioned above should be used ? (I guess that nobody would like to abandon his project so this may be a serious problem ;) )

Right... I disslike the thought of having wasted my time (about 6 month or more now) developing my editor for nothing... Not now as it actually starts working :D
Honestly I don't really know if it will ever be possible to integrate my editor as a "true" plugin. I never intended that when I started it, so maybe it isn't even possible without rewriting most parts.

Quote from: mispunt
Perhaps we could merge the projects, and get the best out of them ?

I doubt this will be possible as I guess we all did it in a different way, with different thoughts on our minds.

Diversity isn't a bad thing after all. C::B will have a GUI plugin like byos. I had plans to make it possible to import rc files and Qt Designer files with my editor and let it generate different project files. Maybe I'll stick with that idea, so changing toolkits will be made easy.

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
Re: RAD TOOL developers wanted
« Reply #63 on: May 25, 2005, 11:22:32 am »
Quote from: rickg22
OK guys. This is serious. I realized that there is NO wxWidgets designer tool in C++. At least not open source.


Heh, currently I see many tools :)

I think that we all should keep working on our codes. Each tool is a valuable thing and none of us - developers has wasted time during creation. As I suppose many wx devecopers will use different tools for different things. And as I guess f.ex. my plygin could be good bor wx Beginners but proffesionals could use upCase's standalone app to use special adventages of his work.
I hope that all apps and plugins will cooperate in future,  so there's nothing to care about for now (QT has really nice tools for it's windows development but these are standalone apps and as I remember Kdevelop use them) :).

Hmm, I have one question dedicated to C::B leaders (mandrav, rickg22), what's Your opinion ?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
RAD TOOL developers wanted
« Reply #64 on: May 25, 2005, 12:14:55 pm »
Quote
Hmm, I have one question dedicated to C::B leaders (mandrav, rickg22), what's Your opinion ?

Plurality and freedom of choice is never a bad thing ;)

Yiannis.
Be patient!
This bug will be fixed soon...

upCASE

  • Guest
RAD TOOL developers wanted
« Reply #65 on: May 25, 2005, 05:31:41 pm »
Hi!
Ok, so here it comes: The new updated development release/snapshot of my GUI editor.

First a new screenshot:


You can download a copy of this beast at http://www.upcase.de/stuff/wxRapid.zip

- I implemented most of the widgets in a basic form (meaning: some og them don't work as expected).
- wxPropertyGrid has been updated to a development release after a short mailing with its creator Jakko.
- XRC code generation works almost perfectly.
- For the XRC code, a cpp/h file will be generated that loads the XRC and gives you control over the used variables.
- Basic support for event handlers has been implemented. I used a hacked version of wxLongStringProperty for that, displaying a STC editor. wx classes should be colorized.
- Event handling code will be generated in the cpp/h files, but don't expect too much :D

I hope you find this a good thing. Still, a lot is missing. There will be Menu bar editing and Status bar creation (it's there in a basic form) in the next release, maybe tool bar support too. Some problems with not existing widgets (like wxCalendarCtrl) for XRC will have to be reviewed. Aynway, I think it's getting better and better. Hopefully there will be something that really works in the near future.

Oh yes: There will be "pure" C++ code generation.
Cross your fingers that I find the time for these changes :D

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
RAD TOOL developers wanted
« Reply #66 on: May 25, 2005, 05:57:06 pm »
OK I think diversity is good. Evolution in action! :D Survival of the fittest *evil grin*.

And I'm sure that someone'll be able to integrate upCase's wxRapid with C::B. But you know, I think we should post a thread on each plugin under the development forum. And then each author would explain *in his own words* how his plugin works.

This way we could do a brainstorm and perhaps merge the important parts of each plugin.

 mean, there are COMMON things in the plugins. Like the properties pane, the object tree (above the properties), the widgets palette, and of course, the GUI area. So if each one says how each one is implemented, maybe someone out there can take the best out of each and paste the code like crazy :P.

So feel free to create your "my RAD Editor" threads. I'm 100% sure that many good things will come out of it.

Anonymous

  • Guest
RAD TOOL developers wanted
« Reply #67 on: May 25, 2005, 11:45:10 pm »
I' m up for joining byo on wxSmith with two requests:

1. A proper plan of attack--er, some kind of informal or formal documentation--is draw up and modified as needed to manage this very important project.  Something like an action list of development items subdivided as needed.  Or something else.

2. Since this is apparently the first and only RAD plugin, all other standalone candidates are reviewed for partial inclusion to minimize reinventing the wheel, as it were.  Perhaps all involved can make their case for their own priorities.  This doesn't mean each would be involved, but any code could be contributed and reviewed.

My reasoning for this is that, while others have stated the obviousness in diversity, it occurs to me that "united we stand, divided we fall".  I would hate to see all this fabulous energy wasted.  I've also seen other project deteriorate due to lack of perseverance--note the other attemps at public domain RAD tools that have wasted away.  So let's capture this energy in a unified effort while we still can.

I expect (1) will take some time (month or two) and (2) will impact (1) and may depend on the cooperation of others.

DreadNot

  • Guest
RAD TOOL developers wanted
« Reply #68 on: May 25, 2005, 11:47:19 pm »
Sorry  :oops:.  Wasn't logged in.  The above was mine.

DreadNot

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
RAD TOOL developers wanted
« Reply #69 on: May 26, 2005, 12:33:23 am »
Yes, I forgot to mention :P While diversity is a good thing in evolution, so is DNA recombination.

Anyway, I just tested byo's plugin, and I think we can work from there: Improve the interface, etc. However, without a manual (or blueprint) it'd be hard to improve specific parts. What *particularly* worries me is the object construction handling of events. Byo's approach is to make a derived class out of each widget. While it does work, i'm sure there's an alternative approach, like trapping the events so they won't get to the widgets or something. I think I read something in the wxWidgets manual about disabling events for GUI designers (and that's what we're doing, right?)

upCase, how did you implement this part?

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
RAD TOOL developers wanted
« Reply #70 on: May 26, 2005, 02:05:34 am »
Quote from: rickg22
What *particularly* worries me is the object construction handling of events. Byo's approach is to make a derived class out of each widget. While it does work, i'm sure there's an alternative approach, like trapping the events so they won't get to the widgets or something.


Yep, I know it can worry, I've created these few widgets currently available in wxSmith rather for testing that for a real working. In fact all system could be reduced to one or few classes which would easily handle all default widgets. In fact there's no neeed to derive class for each widget in preview - it will be simpler to add event handler to existing widget. I just haven't focused on that problem yet :oops:

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837
RAD TOOL developers wanted
« Reply #71 on: May 26, 2005, 02:40:51 am »
I've just created new topic dedicated to wxSmith:

http://www.codeblocks.org/index.php?name=PNphpBB2&file=viewtopic&t=372

Anonymous

  • Guest
RAD TOOL developers wanted
« Reply #72 on: May 26, 2005, 10:33:41 am »
Hi!
Quote from: rickg22
What *particularly* worries me is the object construction handling of events. Byo's approach is to make a derived class out of each widget. While it does work, i'm sure there's an alternative approach, like trapping the events so they won't get to the widgets or something. I think I read something in the wxWidgets manual about disabling events for GUI designers (and that's what we're doing, right?)

upCase, how did you implement this part?

I created one master class as a base class for all widgets. This class is an eventhandler for stuff like moving, clicking, etc. The widgets are derived from this class, as well as sizers. The base class also stores meta infos like variable names.
Just let me say that the way I did it works, but it's not really elegant. The widget creation part is a real mess and doubles some things. It works though :D

thedeurf

  • Guest
RAD TOOL developers wanted
« Reply #73 on: May 27, 2005, 11:04:59 pm »
there is a screenshot of my wxFormDesigner :



It's not a CB plugin but i'll integrate it later when it will be stable and complete.

The icons are not the definitive ones it's not finished at all

You can modify controls with a drag and drop as the delphi manipulation system... 8)

but i progress as well as possible !  :D

Anonymous

  • Guest
RAD TOOL developers wanted
« Reply #74 on: June 02, 2005, 09:19:35 am »
No offence to anyone, but I think the RAD idea needs some sort of management. Put someone in charge of RAD for Code::Blocks. I know having more than one RAD provides diversity and options, but it also wastes too much time on re-inventing the wheel.

In this case, 3 people are doing essentially the same thing! All are re-inventing the same wheel!

Why not organise everyone into diverting their energies working on the same wheel?
Getting all the developers together produces far better results than three separate solutions which are semi-complete with half-hearted to no decent documentation.

We use upCASE's code as the basis. We discuss what we want in Ver 1.0 of RAD for Code::Blocks. We set goals for each version, etc. This is where all developers wanting to get involved has their say at what they want to add. The person in charge of RAD makes sure everyone agrees to the features they want to add.

We start off with, a version that is labelled EXP (eg : Ver 1.0-EXP) for experimental. This is where developers throw in their contribution, add a new feature, etc. This is not guaranteed to work 100% stability.

After all the features (goals) have been achieved, we freeze development and test.
=> Ver 1.0-ALPHA-1, Ver 1.0-ALPHA-2, etc.

We fine-tune and tweak for max stability and performance.
=> Ver 1.0-BETA-1, Ver 1.0-BETA-2, etc.
=> We also take the time to document the new features and tutorials, etc.

Once its solid as a rock, it will be released
=> Ver 1.0-STABLE.
=> With full documentation.
=> This is the complete and polished one.



Yes I know, this approach requires more effort. BUT:

(a) All developers will have a strong purpose and their energies are focused on the goals. (So they don't feel so overwhelmed and have more time to spend on family, etc).

(b) Developers won't be doing redundant things. (I find it ridiculous if 20 people are doing the same thing!)

(c) The result is a FAR more polished RAD than anything (open-source wise) out there.

(d) The community will recognise it (Code::Blocks and RAD) without the need to advertise. If you're good at something, you don't need to say a thing. Your creation and skills says everything for you....And if you know your software is crap, you could do what MS does and start ridiculous FUD campaigns like "Get the Facts". :)

(e) The overall IDE with RAD will be a far more polished solution, which could rival some commercial solutions. Everyone loves rock stable software.

(f) If you attract attention of companies supporting open-source, you get quite a number of new features from them. (It could be something that no one else has thought about, but they like to add to your code). Who knows, you may even get monetary support from organisations and folks who love using your tools.


You may have wondered why I'm suggesting all this. Well, its that I'm sick of most open-source solutions doing things without properly defined goals and management. ie : Its all over the place. Bugs remain open, documentation and help files is incomplete, etc, etc. A simple thing like a checklist really does go a long way!

Everyone is wanting to do their own thing and the result is a software that isn't good as it should be. That pisses me off. Half-baked solutions written by programmers in their spare time. (Bill Gates is laughing, as all this software isn't a threat to his profits).

What's worse is they lack the proper documentation. Every newbie would like to contribute and use open-source software...But if there is no documentation with tutorials and such included with software, folks get a little fustrated and use something else.

Take wxWidgets as the prime example. There is no proper tutorials to get newbies started and understanding of the tools...Sure, a book is coming to address this issue...Why didn't they have some documentation like a electronic handbook in the first place? There wouldn't need to be visiting Amazon.com to buy a stinking book just to get a clear grasp of wxWidgets. (You saved a few thousand trees as well).

I'm saying all this because I see Code::Blocks have alot of potential. This potential could be ruined if everyone does their own thing.

mandrav has laid out the basis (Code::Blocks) for us to build on. All we have to do is organise ourselves into teams that are responsible for a particular plug-in. (Or a feature of that plug-in)...Say wxWidgets's network component, etc.