Okay, it's a known fact that it will be very difficult getting people to agree on one standard for IDE. Therefore, everyone's own flaver pushes on to the stack before it's later popped off :-/ Now, here's what I see the problem of consistancy is: people have to implement their own way of compatibility. Where's the reusable foundations? Therefore, I propose this, and this is a far as I'm willing to go on the issue until it proves to be successful, then I'll go further, but we all need to give a little to make it happen: The first thing to compatibility is common project file format, perhaps as well workspace, but, project file is more important. Why not create a single library that implements a standard format for files, certain confirgurations, and then allows customization? Then, each IDE could use that (single) implementation and you can guarantee, at the least, that the project file itself will be unified. There will be certain stock functions such as : CreateProject(Path, Name) UpdateProject() AddFile(Path, Name, ProjectName, ) RemoveFile(Name, ) RenameFile(OldName, NewName, ) AddFileAttribute(Name, Attrib, Value) ChangeFileAttribute(Name, Attrib, Value) RemoveFileAttribute(Name, Attriv) GetFileAttribute(Name, Attrib) AddSetting(SettingName, SettingValue) ChangeSetting(SettingName, Value) RemoveSetting(SettingName) GetSetting(SettingName, Value) AddBuildRule(Rule, Value) ChangeBuildRule(Rule, Value) RemoveBuildRule(Rule) GetBuildRule(Rule) AddGroup(GroupName) AddGroupKey(GroupName, Key, Value) ChangeGroupKey(GroupName, Key, Value) RemoveGroup(GroupName) GetGroupKey(GroupName, Key) GetFileCount(FILE_TYPE[0=ALL]): Integer Enumerate(): Returns Key until Null Path = "Path\" Name = "Name.ext" FILE_TYPE: FILE_MODULE = 1 ; asm FILE_INCLUDE = 2 ; inc FILE_RESOURCE = 3 ; res FILE_DOC = 4 ; txt, doc, hlp, rtf, chm... FILE_OTHER = 5 ; *.* NAME_TYPE: NAME_PROJECT ; How it's displayed in project NAME_FILE ; Actual Name GROUP: ENUM_FILE ; "Files" Group ENUM_SETTING ; "Settings" Group ENUM_BUILD_RULE ; "Build Rules" Group "xxx" ; Custom Group Add.../Change... could be merged to a single Update... which is smart enough to know to modify or create the requested... There, this could be enough to keep consistancy and allows people to put their own stuff in there... perhaps I left something out, but, again, this isn't my single effort, hopefully we can agree to at the least, try it... then improve it if necessary. That's the first step, each IDE is programmed in a different language and style, so it'll be more difficult to standardize other parts of it. But other common things could be a task manager, either as an MDI child for those who care, or a modeless dialog for those who aren't using MDI. But one common libary. Other small functionality, such as a template library or repository could also be implemented and shared amonst all projects, despite the language of choice. Just let the individual IDE coders implement their IDE, but provide some building stones we can all share and little by little, we'll build it up. If people would be willing to use a common library for file formats, then I would be willing to contribute some code, and we can all fine-tune it together. However, if people don't even want to go that far, there's no point ever worrying anymore about compatibility, since it won't happen unless someone wants to make a minimal compromise. If we can get this up and going, I will even write COM-ActiveX/MFC/VCL/C/C++ Class Wrappers around it so that everyone could use it on their own respective language of choice. _Shawn This message was edited by Shawn Bullock, on 3/9/2001 11:12:12 AM This message was edited by Shawn Bullock, on 3/9/2001 11:15:01 AM
AGAIN with the common file? ;-) It's just not gonna happen. There are too many ongoing projects with everyone asleep at the switch. An IDE is a glorified file manager, with the ultimate goal of compiling those files by some build rule. How that is managed is detemined by how one defines a project. By how the data is modeled. By what goes into making a project. If all you ever do is make an .asm file, include windows.inc and a few libs, you'll be quite happy with a basic model. My choice (since I learned how) has been to encapsulate data and code as much as possible... I have multiple .asm files each assosciated with a .inc file. Private data/code goes into the .asm, public into the .inc. Inc's are shared by all project members, asm built seperately then linked. I'm not gonna be happy with any IDE that assumes a flat structure for my project. Right now I'm struggling thru with multiple instances of TextPad and far too many custom build bat files. I still miss the simplicity and configurability of Quick Editor. One thought to this process I will interject: I asked myself the other day "what's the difference between a Workspace and a Project?" I had a Project defined as a collection of Files, and a Workspace as a collection of Projects and Files. Projects also have an output product (.obj, .lib, .dll, .exe, ect) Gee, it finally dawned on me to define a Project as a collection of files AND other Projects, and the need for a Workspace dissapears. And since a collection naturally assumes a tree structure, it may be built from leaf to trunk without imposing any more rules into the build rule. Just another two cents worth. Meantime, I'm coding my IDE for my needs to my standards.
Ernie- Your right again in both this and your reply to my last post in the FREE ASM IDE thread, I overestimated people (again), I assumed they were capable of working in a group, after careful thought I realise they're not. However I still think an IDE in a very big project for one, fortunatly your way about it seems to be the most thought out so you will suceed, others will fail. But thats good, they probably weren't going to write a useful IDE after all, so what we'll be left with is one IDE, yours. This being the most thought out will actually be very useful, and I assume very efficient. At that stage there will be two options, go open source or keep everything to yourself. I don't recommend open source. Instead keep the code and then if someone had, for example written an excellent resource editor that would work very well in your IDE maybe you could show them how to adapt it and intregate it and then distribute it with the IDE. This way various people could work on different aspects but they would have to conform to your standards. I personally would trust that they are the most realistic standards out there given your obvious talent and experience. Admitingly I have know idea how these things could be intregated but this is only theory.
Zadkiel, Awww, geee. :-) First off, I've forced myself to design this thing out, since my first feature in mind was "fully scriptable by VBscript or Jscript." That means it need an object model implimented in real COM classes so the script engine can hook into them. At the same time, it gives you a way to do add-ins for free: pass em the same object model, and let the dll code do the control. I spent the first month just coding a docking toolbar control (windows type class, not COM). It's mostly functional (at least it usually docks and undocks without dissapearing), but still needs work-arounds for things I never found methonds for (like resizing an existing rebar bar's width). Then onto a general purpose enumeration (COM) class. Plus a ton of BSTR routines (since COM is based on BSTR string types, I chose to make everything in the app run on BSTRs). Finally, after all that set-up, the MDI interface (with the docking stuff) had the classes grafted in. cWorkspace, cProjects, cProject, cDocuments, and cDocument COM classes were defined (meaning the methods are stubed in). This week, I got enough of the background code completed to actually start on the class code. So the Workspace object (synomous with the user interface) constructor takes a dummy project file name, created a Documents collection by handing it the project file, which then creates a Document object for each file in the project. It's nice to see the code starting to mesh. My whole point in saying all this is nothing is done "on the fly." It's all planned out first, then coded. I've got a 7 page word doc just describing what each object will do. And I constantly cross OUT things as better ways are thought of. Mind you, I cross out first, then code. That's the point. If you don't know what you're going to code, you're not ready to code. If you're not ready to write the HELP file, you're not ready.
You know ernie, I think we have a lot in common... I write dev tools for a living, I know all about planning and thinking things through, I also know about trial in error. There is a difference between writing (an IDE) for actual use, to fill a need, and for hobby just to say you can. There is an obvious need also, to have customization and possible scripting. Mine isn't build on COM simply because I plan to port. Of course, building it with Delphi doesn't make it much easier to port to anything but Linux, either. I thought about doing it in C++ and then, I have an actual C++ interpreter (source code) so I could port it if I needed to an unsupported platform. Then you could script it with C++ (which is cool)... While I'm thinking it through, I have an obvious dissadantage, I'm not as good with win32 assembly as you are. Therefore, I don't see the full gamut of what's need or whatever. Nonetheless, I have my goals and I'll write to fullfill them. If people use it, great, if not, then at least I have an IDE that I've long needed that isn't in existance elsewhere (at this point). I'm also doing it for a learning experience, to bring me closer to Windows and system architecture (for other reasons). I want to write an optimizing compiler sometime. Anyway, about programming asm in modules and using only an inc or two to keep them together, that they all can use, I agree witht that also. I write very modular and cannot stand monolithic source code. Well, good luck, can't wait to use your IDE (yes, just because I have my own doesn't mean I don't use other peoples from time to time). _Shawn This message was edited by Shawn Bullock, on 3/10/2001 1:01:14 PM
Ernie, Have you checked out the MFC source code for the docking toolbar? It might help... Xtreme
Xtreme, Not a bad idea. You wouldn't happen to know what class does docking? I know buttkiss about MFC.