From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1213 invoked by alias); 19 Jul 2002 07:05:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1179 invoked from network); 19 Jul 2002 07:05:35 -0000 Received: from unknown (HELO hotmail.com) (64.4.36.94) by sources.redhat.com with SMTP; 19 Jul 2002 07:05:35 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Jul 2002 00:05:34 -0700 X-Originating-IP: [210.15.2.97] From: "Maggie" To: "stephen miller" , References: <3D377C5D.3050902@pagemiller.com> Subject: Re: GCC Date: Fri, 19 Jul 2002 08:24:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 19 Jul 2002 07:05:34.0976 (UTC) FILETIME=[ADA0E000:01C22EF2] X-SW-Source: 2002-07/txt/msg00848.txt.bz2 As I know,there is a project named dev-c++. Regards Maggie ----- Original Message ----- From: "stephen miller" To: 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 >