From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1964 invoked by alias); 19 Jul 2002 05:13:22 -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 1953 invoked from network); 19 Jul 2002 05:13:20 -0000 Received: from unknown (HELO binky.wru.org) (208.30.238.133) by sources.redhat.com with SMTP; 19 Jul 2002 05:13:20 -0000 Received: from pagemiller.com (joshua.wru.org [205.159.53.21]) by binky.wru.org (Postfix) with ESMTP id 258161F3FA for ; Fri, 19 Jul 2002 00:13:16 -0500 (CDT) Message-ID: <3D377C5D.3050902@pagemiller.com> Date: Fri, 19 Jul 2002 07:52:00 -0000 From: stephen miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: GCC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00844.txt.bz2 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