Re: GCC

["Maggie" <maggie_shh@hotmail.com>]

As I know,there is a project named dev-c++.

Regards
    Maggie
----- Original Message ----- 
From: "stephen miller" <stephen@pagemiller.com>
To: <gcc@gcc.gnu.org>
Sent: Friday, July 19, 2002 10:41 AM
Subject: GCC


> 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
>