mikey Wrote:Hey, maybe you could put that little line - like Future BASIC - leading from and 'if' to an 'end if' and indent the if block?
Like:

Code:

blah blah
if A = 1 then
|
| beep
|
end if

That is a very nice way to clarify the code structure! I can't add that today, since I use Apple's TXN library, which just doesn't have the flexibility, but TXN will have to go in the future and then I will have a look at this and some other similar features (like code folding and splittable edit field). Good point!

I didn't make any compiler, that was made by others. (GCC, FPC, GPC, Javac.) The rest was quite enough work. I have done work on interpreters, but I found PPC assembly so daunting that I never made a compiler of it. (I actually consider plugging in some interpreter too just to make it work even if no developer tools are installed.) Making a good compiler is a huge task. I admire those who have managed to do that.

Anyway, I started out compiling at the command-line. I was fed up with Xcode and realized that I was more productive on the command-line (using CW for editing). And I never was a command-line fan at all, I want an IDE.

Nothing wrong with the original, that's the way Xcode works, but this looks like it would be a whole lot smaller. The only non-trivial thing was the Frameworks (and that will go away in future versions).

Hmmm, let me get this straight: LIDE (new name perhaps?) takes C source, then (GUESS) uses gcc to compile them, but how does it take a.out and turn that into .app? Nice IDE BTW. As mentioned previously, I was looking into the posibillities of making a compiler/IDE/Interpreter.

Here's my philosophy toward 'small and easy' things:

Quote:You want to add more features.
You add more features.
Your thing becomes more complicated.
You add more features.

That's the way it works for many projects. One thing that I wanted to explore, prove if possible, was the third way, and that is to take away features that are not needed, either because they have become obsolete over time, or because they were not really needed in the first place but they were worth it when they were added.

It is hard to take away features, not least because nobody appriciates it as work. People are more amazed if you show a super-complicated user interface that looks like a computer console from a 70's movie, than if you show something that is slim and to the point. But if you can make a really good design, you might get some following anyway.

Adding features is easy. I am seriously considering the following:
â€¢ Tabbed editor. Not because I like it but because it is trendy so having that (as option?) might open some doors, make it easier to be taken seriously.
â€¢ Toolbar. I have no problem with making selections in menus (as long as the menus are reasonably short) but I see a trend making everything visible. I don't like that trend, but again, if it is necessary for a modern look, I'll do it. It is easy, and it can be folded away. (The hardest thing with it is to design the icons and select what commands should be available as toolbar items.)
â€¢ File list window, a clickable list of files, built automatically from the #includes of the main program file. A kind of auto-built project window. Not extremely necessary (the Finder is pretty nice for navigating files so who do we need it?) but large project might benefit from it.
â€¢ Merging some windows to multi-pane windows. The message and error windows could be one and the same and thereby also look a little bit fancier.

Most of this is very easy to add. The information, messages, file lists are already there, so it isn't laziness. Well, a little bit of laziness perhaps; It is more meaningful to work on the stuff inside (process management etc) than the GUI since the GUI will have to be rebuilt one day anyway.

I have added one visible feature recently, namely visible icons for the pop-up menus (function menu and included files menu). I realized that many people didn't find them.

Most new features are invisible, like the recently added color coding and function menu support for shellscripts.

And I have managed to take away things. Some things went away from the predecessors to my design, and a few things I have managed to take away later. But why havn't I taken away "Special characters" from the menu? I will do that. Not that I must make an effort to take things out as it is now, but I may need to do it later.

Oddity007 Wrote:Tabbed editors are good for cases where two have 2+ windows that you won't use at the same time, I.e. code and console.

That's true, more or less. I'm not sure I would want to hide the code when looking at the console and vice versa, but your point is correct. Anything you never want side-by-side fits well under tabs.

But the cost is considerable. Not so much in code complexity, some tabs are not hard to do (mainly a problem of making neat graphics for them IMHO), but the cost in user attention, desk space and menu space. That's why I hesitate.

I released 0.7.5 today, and the second row disappears, almost. A major new feature is "auto-frameworks", so any framework #include'd by the main program file is automatically added. Since it is so new, you still have to activate it in the settings, but it seems to work just fine. When it has settled, when it is better tested, it will be default.

Some new things are happening here. My project is moving into the next phase.

Today we stared a student project to evaluate and improve the GUI of Lightweight IDE. That is just the right time, since I have started working on the Cocoa GUI (to make it somewhat future safe and get a better editing engine), and when that is working as it should, it is the time to get some new features in. The concept will be the same, tight, kick-start philosophy, but there are a number of things that I think are needed.

New features being planned: Tabbed editing will come (it is pretty easy). Probably a toolbar too (optional to keep the minimal GUI clean). There will also be a "project info" window with a file list (generate from the code, you still won't have to manually add files). But I don't want to put too much time into those things until the groundwork is revised.

For this evaluation and design, we are looking for people who have tested it enough to have an opinion. Most of all we need "real users" but also those who have tested and have opinions about most vital missing features and how it should work. It will not take much time, it will be some interview questions. So take the chance to influence it!

Thanks for the offer! Maybe that would help. We are getting there though; I got two more from another source today, so the project has more or less what it desperately needs. But one or two with gaming background would not hurt!