GCC

[stephen miller <stephen at pagemiller dot com>]

Okay, I came upon your website with the intention to look for "dev 
libraries" that would allow me to create my project and use gcc as the 
backend for it.  I came across your suggestion to email you with my 
intentions.

I know there are several graphical IDE's out there, but I want to create 
a graphical IDE with an interface that I have *never* seen before.  I've 
checked out all of the free IDE's in various places and have determined 
that none of them are what I want, although grabbing some of their code 
might in fact happen :).

I intend, of course, to gpl it.

I want to have it run on windows and linux.

I think my idea is sufficiently good as to warrant the *huge* amount of 
work this will take me.

I am not at all confident that I will ever finish the project
-I am a college student
-I am just learning GTK+ which I'm writing the front end in...
-I have a life outside of college and programming.

But I love this project so far, and hopefully I'll carry it to a 1.0 
release which would allow me to create code files that are compilable 
with the graphical interface.  Because of the interface this will be 
*much* harder than it would be with a file interface.


Also, this is meant to be an IDE for c/c++.  It could also, eventually, 
be adapted to being used with perl and other things.


VERBOSE PROJECT DESCRIPTION, Lector Caveat

I don't want to discuss what I'm going to do for fear of non-acceptance, 
but I'll do so anyway.  The intent is to have each function be 
considered an object.  A global function does not have a parent object 
per say, but a class method is an object that is possessed by a class 
object which is in turn not possessed by anything.  All of the 
"standalone" objects are then possessed by "file objects" which the 
developer will not have to concern himself too much with.

What this allows me to do is to have a function "window" that is the 
function and the function alone.  A text box with the code, a text box 
with comments for *that* function, a gray label for the return type of 
the function, a gray box for the parameters, and a drop down list for 
other functions on its level.  That means if its a "global" function the 
drop down box will have all of the global functions.  If it belongs to a 
class, it will have all the peer "functions".  You will be able to have 
multiple function windows open.

I'll also have a "class window", an "expandible list object viewer", a 
"file viewer", and a "variable viewer".  Each variable can have a 
comment, a type, and a name.  Class variables have levels of publicness, 
like public, private, and protected.  Class windows will have all of the 
"functions" listed in a box, and all of the "variables" listed in a box, 
sorted by their level of publicity, and graphically illustrated in the 
background by their level of publicity.  Ie "public" methods could have 
a low-contrast "sky" pixmap behind it to suggest "freedom".

Picture association is _highly_ important to this interface, to speed up 
development work.  Ideally each picture will be intuitive, easy to 
remember, and catchy.

File viewers allow you to associate top level objects with a file.  The 
"expandible list object viewer" allows you to sort things by file 
associate, or on a complete level.  (think MSVC's OBJ lister in the 
lower left pain by default).

Each window is intended to be freefloating like gimp with one floating 
menu bar complete with icons that is the "master" window.

Any object listed in ANY window can be doubleclicked allowing 
editing/viewing of that object's properties possible. ie the appropriate 
"object editor" for that object will pop up.  I've got a way to keep 
multiple editors for the same object from opening, and from keeping 
multiple views across different kinds of editors of an object "updated" 
at all times.

This system, is to me, a much faster way of coding and reinforces the 
idea of object oriented programming.  I would use it even if it was 
procedural program because a procedure is just its own object, that 
cannot inherit or beget new children yes, but it is a standalone object 
with "connectors" nonetheless.


Okay, before you think, well how does this become compilable? you have 
to ask how the nature of the "file associations" plays into writing text 
files which can then be shipped into g++.  Because you have to worry 
about .h files, extern statements, #pragma's, #includes, etc.  Well each 
file object can have a list of necessary "includes".  Oh hell I could 
attempt to build a method of dragging and dropping a huge list of 
include files as well :).  Or you could "build" your own list of include 
statements that you want to be able to pull from quickly.

This removes a LOT of typing from the dev's hands and becomes much 
quicker mousing around stuff.  It also reinforces function clarity and 
you don't have to keep "scrolling" through tons of pages.  You're eyes 
don't have to move around so much and this decreases confusion.  Picture 
association speeds up "creation" of new objects and so on.  The method 
through which you can create a new "class object" or a "function object" 
exists in several windows, uses the same icon, and is relatively large. 
This far excedes MSVC's classwizard which is both confusing, hard to 
find, buried in menus, and way overdone.  (also imsho non-intuitive).

Well, enough convicing you :p, if you don't agree , thats cool.




_what I could use from you, if anything_
I could use suggestions as to where to look for "increasing" the link 
between gcc and the IDE.  and/or portability issues with gcc's link with 
the GTK+ ide.  Also, anything else you can think of.

I don't want to just have people be aware of the project because its 
quite smile right now, its TONS of notes, lots of little drawings, and 
only a small amount of GTK code (its growing!).  I also have no idea at 
what point to try to get other people interested in the project, either 
by using it and responding, or even developing.

Anyway, go ahead, flame away, I dare ya,

Steve
:wq