RE: [gtkmm] Re: Gtkmm or Qt?
- From: Murray Cumming Comneon com
- To: davejf frontiernet net, gtkmm-list gnome org
- Subject: RE: [gtkmm] Re: Gtkmm or Qt?
- Date: Wed, 27 Aug 2003 08:13:35 +0200
> From: Dave [mailto:davejf frontiernet net]
> For gtkmm or any of the others to become a dominant toolkit,
> I think it is
> important for it to be supported by a good C++ RAD IDE,
> because that would
> greatly reduce the learning curve needed to build non-trival
> applications
> using gtkmm and would break-down the initial acceptance
> barrier for people
> like me who are new to these frameworks.
Sure, a good development environment is always a nice thing. There are now 3
projects that I know of that are working on this, with some good chance of
success - anjuta, scaffold, KDevelop.
However, I don't believe they are focused, organised, or release-scheduled
enough. Someone who cared about this would get involved and help them get
with the program.
[snip]
> What I think a lot of developers would like to see is a
> development tool
> where you could:
>
> 1) start a project
Anjuta and KDevelop (and probably scaffold) have new-project wizards, for
gtkmm too.
> 2) add a standard dialog (*)
Glade can add a dialog, and there has been recent discussion on
desktop-devel-list about improving the defaults. For instance, making the
default alerts more GNOME HIG-compliant.
> 3) start dropping widgets on it "visually" (**)
Glade can do this. I don't think it does drag and drop, but that's a feature
that you could add if you think it's important.
> 4) produce the event handling stubs through the IDE
Yes, I would like to have a little right-click-on-class thing for this. This
could be added to existing IDEs.
> 5) fill in the event stubs with custom code through built-in
> code editing
You want the IDE to write your code for you?
> 6) build/run the project (***)
Existing IDEs do this.
> 7) Repeat 2 - 6 ad infinitum
>
> * The IDE would add the header and code files also when a
> dialog was added
If a derived dialog is needed. libglademm 2.1.0 is part of this.
> ** The IDE would construct (in the code files) the widgets added to a
> dialog
Generated code is a problem. You end up with macros saying DONT_TOUCH_THIS.
Anyway, if you are using libglademm then this would not be necessary.
> *** The IDE would support multiple compilers using a
> command-line build
> scheme, not one requiring makefiles which rely on some
> external (other than
> the compiler) build tools.
No, the configure/makefile system works. There is no reason to tie the
configuration and/or build system to the code editor. MSVC++ has massive
problems because of this, massive conceptual problems that I have
experienced with every single MSVC++ project. It's OK for the IDE to help
you to edit the build files, and the existing ones try to do that.
> In other words, a language and library centric (as opposed to compiler
> centric) RAD IDE that could be used throughout the entire
> lifecycle to build
> a large GUI project in it's entirety, with standard C++.
As others have said, there is no reason or advantage to hardcoding all this
stuff together. As with all software development, modularisation is
necessary for quality. However, there is no reason that everything can not
work nicely together. If necessary, people might specify interfaces between
components, for instance so that new-project wizards work with all IDEs
(Anjuta and KDevelop are doing this), or so that you can use whatever
debugger you like (I suspect this is nearly there), or so that you have a
choice of class browser.
> I'm not alone in my opinion about a good IDE - take a look at
> http://www.fltk.org/poll.php?r15 for example.
That doesn't say that people believe that an FLTK IDE is necessary to use
FLTK. The 2nd choice is web browser.
> I know *just* the above would take quite an effort, not to
> mention adding a
> good debugger, class browser and all of that in version 2 or
> 3... or 7 or
> whatever, but IMHO the most important thing is the "wow" factor,
> productivity and reduced learning curve that such a tool
> would provide for a
> toolkit.
As soon as you consider reimplementing this much stuff just for a nebulous
idea of integration, you should start hearing alarm bells.
Another alarm bell is: So, we have an IDE for gtkmm. Can I have an IDE for
libxml++ now? And one for each of my 4 database libraries? What, I need to
choose just one IDE? But I need to use lots of libraries in one project.
> In order to get cross-platform GUI development to take off, I
> think it is
> vital to provide good tools along with the toolkits.
Sure, but I think it's a matter of
- a few gtkmm-specific features.
- packaging
- bug-fixing
Murray Cumming
murrayc usa net
www.murrayc.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]