091230:
Second alpha of TransSkel 5. This is improved a great deal, with functions for accessing and re-assigning menu items, graphics (through QDCG), and more. I believe this is now getting close to what is needed for full applications. It still needs more text editing features in order to handle line numbers and breakpoints.
091228:
Important! You need a slightly modified NSApplication.inc to make my Cocoa code work. The change is the declaration of setAppleMenu, at the bottom.
A second alpha is coming soon. The window clobber callback now works properly, and I have added menu item lookup functions that makes it easier to work with nib-based menus.
091224:
Christmas special, TransSkel 5.0a1! So what? What is TransSkel?
It is getting future safe the easy way! TransSkel 5 is a NS/Cocoa-based application framework which makes the task of building a GUI application much simpler, without having to learn the complexity of a full OOP framework with all its special rules and, not least, incompatible object models. Unlike Cocoa, it is code-centered, avoiding to hide other functionality than the layout in nib files.
TransSkel is a callback-based framework, which is an intuitive and flexible way to work. The code gets structured in a very natural way, but doesn't force more rules on you than is has to. And as if that wasn't enough, it includes replacements for some missing calls like NewWindow, Standard File and menu building. They are not identical, since backwards compatibility was not the primary goal, but porting should be a lot easier anyway.
Eventually, I hope to make TransSkel cross-platform as well as cross-language. Unlike Cocoa, it can fulfill both these.
So, to summarize in a point list:
Interesting? I think so. A bunch of features are still missing, so if you want to help, there is a list of things that needs solving.
Merry Christmas!
091220:
0.8.2 is uploaded today, which is a rather small change compared to what I have been spending most time on lately. The new feature is that the Target settings include command-line arguments for the target program, when run (not debugged). Big deal? Well, to some. Yes, it was easy to add.
But the big thing is that TransSkel 5 is getting really close to a first public (preliminary) version. That means a procedural, callback-based API that covers quite a bit of NextStep/Cocoa. It greatly simplifies nibless app building as well as supports loading of layouts from nibs. It has a simplified API for handling many controls (menus, buttons, sliders, text boxes, radio buttons, checkboxes, image wells, basically any NSControl) plus custom views. There is also a standard file dialog unit similar to CarbonStandardFile.
Not all is done yet though. The biggest things yet to solve include:
There are several goals here: To get a nice, intuitive and simple API, to ease porting of old TransSkel- or Carbon-based code, cross-platform compatibility (i.e. Linux, MS Windows and Solaris), cross language compatibility (i.e. C). Supporting nibless NS apps is not a major goal but comes for free. I think we get it all just by following the design ideas of the original TransSkel, but extend it into parts that were left to the Mac Toolbox in these days. Paul did it right back then so why do it wrong? TransSkel and FPC is two big right in my view.
While I have developed TransSkel 5, I have also produced a few new independent ObjP demos. You will see them soon. In some cases, I have written a demo both in ObjC, ObjP and TransSkel5, to compare the results. And of course TransSkel 5 comes out the winner. If it doesn't in some way, I know I must redesign something or add some missing feature. And I do.
Everything great? Well, except for one thing: I think the project needs renaming. At least one time too many, I have seen LWP being ignored in discussions as if people just don't notice that it is mentioned. Maybe I am over-reacting on it, and in a way I like the name, its sales pitch ("Lightweight on your mind") and its reference to Lightspeed Pascal, but it seems to me as if the term "lightweight" a bit too often is interpreted as nothing at all.
091011:
The preliminary Ada version has been up for a while. I indended to make a "real" 0.8 by modernizing the file management, but that turned out to be troublesome. We can't move to FSRefs if that means a lot of work and the result has more problems instead of less. So now I turn my eyes towards moving to Cocoa faster. I thought I might polish up the currrent LWP and make that 1.0, and aim for 2.0 as the Cocoa version, but maybe that is not the best plan.
As mentioned below, a Cocoa-based TransSkel prototype already exists. That is made with PasCocoaKit, which is a nice Cocoa layer working with the old FPC. However, PasCocoa(Kit) is a dead end, an intermediary solution that is being rapidly phased out.
Yesterday, I got the new solution, Objective Pascal, running. The demos worked with LWP with very little changes. However, I had to put back some settings that were removed inb the past since they never changed. Those changes now go in an extra "advanced preferences" box, for preferences that are rarely changed.
So if you want to try Objective Pascal, you should:
1) Download and install the new, preliminary FPC with Objective Pascal support: http://www.thealchemistguild.org/objp.php
2) Ask be for the upcoming LWP 0.8.0, with new settings,
3) Set the path to the compilers in the advanced settings.
4) In the demos, move resources to "Main Resources". Rename the MainMenu.nib til main.nib.
That's all. Then the demos compile and run! I am now working on moving the PasCocoaKit TransSkel to Objwective Pascal. From there, I hope the path ahead will get better. So far, the Objective Pascal demos don't have the nice feel that the PasCocoaKit code has, but I hope I can get around the Cocoa coding style and find something better.
090919:
The new release fixes a number of things in the current IDE. No big changes, except if you have problems with any of the shortcomings being fixed.
Several things are in the pipeline:
I have spent some time recently on PasCocoa/PasCocoaKit. This is somewhat tricky, things are changing fast. I have settled on PasCocoaKit for now for its completeness and relative ease of use. In the long run, we will probably move to a new FPC version with built-in Cocoa support, but PCK works quite well and is pretty complete out of the box.
090907:
Currently, I spend my LWP development time into making groundwork for converting the whole thing to Cocoa. This is rather challenging, but I think it can be done. I have some basic demos running and am trying to build the first start to a brand-new variant of TransSkel. And if I do that right, very little of the application code will need rewriting, except the editor.
I will most likely rewrite the file handling code first, before LWP gets Cocoa-based.
090827:
I am busy with course work and similar things, but:
090811:
New demos (game/graphics rlated), yet another 0.7 release, and new and better pictures in "about". That's plenty for one day.
As mentioned below, two major things are ahead. First, rewriting the file handling code. Then, looking into a full or partial move to NextStep/Cocoa, or at least replace the text editor with something better. It sound to me like if 0.8 will be the better file handling and 0.9 will be a better editor.
I also started to think about class browsers again. I presonally prefer to keep my code so straight and tidy that you don't need that kind of extra tools just to manage a poor design (!), but I fear that something like that will be necessary, because so many people learn bad software design these days. Well, disregarding whether complexity and featurisis are bad things or not, the students of today are encouraged to design that way so I might have to adapt - in some way. I ask myself how to make that fit in a tight GUI. Adding a bad class browser (or similar kind of code analyzer) is easy. Making an elegant one is hard. It always is that way. (And unfortunately you don't always get more pay by making it elegant.)
090802:
Third release in theree days, but this time it isn't just bug fixes but some serious news. The custom settings for frameworks and paths can now be put in "all" files, affecting all projects in the same folder (good for those demo folders with many demos), and you can also specify custom options with ".options" files. So "all." and ".options" are the biggest news.
And as if that wasn't enough, I fixed a bug in the editor that affected 10.5 only. Up-arrow seems to behave much better now.
Unless some vital bugs surface, I consider this the final 0.7, and it is time to look at a more significant step to 0.8. There are some needed rewrites, to improve file handling (should be fairly easy), to improve graphics (mostly done), to replace the text editing engine (pretty hard) and to move the GUI to NextStep/Cocoa (should be possible but doesn't look very nice). And there are a bunch of interesting features to add, too (especially those who do not clutter the interface).
090801:
Ooops! Again!
In 0.7.7, a weird bug appeared for no apparent reason, which made "save as" fail miserably. It seems to be fixed in 0.7.8, but the reason still puzzles me. I will continue testing CarbonStandardFile to make sure there are no more lurking problems.
090731:
The summer has passed, and I noticed that I had some bugs fixed that weren't uploaded. Of course, it is all too obvious that I have few C/C++ users so far, otherwise they ought to have reported the bugs. ANyway, they are fixed. The most annoying one was the inability of 0.7.6 to include .a libraries properly.
As a bonus, I also upload a few dew demos that I think are useful.
One more thing: I have found that FPC 2.2.4 doesn't work well on my old Pismo. I had to downgrade to 2.0.4. So if you get strange errors, referring to line numbers way outside the code, and you use 2.2.4 on PPC, then it is not a problem with Lightweight IDE but with FPC 2.2.4.
090625:
Midsummer has passed, and I have been busy with other things than Lightweight IDE for a while. I'll make some notes here to let you know what I think and work with.
My old game library, Sprite Animation Toolkit (SAT) has been successfully revived during the spring, completely rewritten as a library on top of OpenGL and OpenAL. Some demos and one fully working game exists, which means that although it is not exactly finished, it is already useable. It is developed entirely using Lightweight IDE. When I will release it? Well, I guess it will go to interested "early adaptors" first.
What about Lightweight IDE? I have done some work on a formal report, analyzing what I have done and why, debating the merits of minimalism compared to the conventional ways. For future versions, I have the following things considered or planned:
090516:
After some well needed discusssion in the MacPascal list, the idea to make a file list window as next step is strengthened. But the problems in the process management is even more important. And Ryan Joseph's Cocoa-based text view might be a well needed shortcut to a better editor.
090515:
Agony! Am I getting close to finished, or should I rewrite the GUI to Cocoa as next move, or is it so infinitely much left (code folding, documentation search, code completion...) that I should better give up and do something else?
On the positive side, I think Lightweight IDE is pretty unique. So tight GUI, and still it can do so much. I am particularly proud of the smart C/C++/ObjC building capabilities, despite that they are not my own favourite languages. But when I need to use them, they are handled well. (Except for some object parsing that is needed to improve navigation.)
Considering Cocoa, I got Ryan Josephs PasCocoaKit demos to compile and run under Lightweight IDE. That can be a significant step forward. Unfortunately, it is a lot of work just to get into the essentials of Cocoa, so I don't know if I have that time to spend. But for what it is worth, I might be able to include PasCocoa demos real soon now. Tell me if you want help with using PasCocoaKit with LWP.
For the new version today, 0.7.6, the updates are fairly modest. The option to have color coding applied when idle or on newline might be a fun new feature. I am used to color coding on "save" but if it feels cheap, there you are.
I am having some trouble with timeouts. Is that the same for all or is it just my MacBook?
090511:
I've been busy with LWP lately! The new version is the next milestone for C builds, since the auto-framework feature is added, making it more automatic than ever (and with the option to disable it when needed). Alas, I don't see any way to do the same thing for Pascal.
It also has some nice fixes for all users, most noticably that the icons for popup menus are hidden when they don't contain anything.
The next focus in on finding the problems in the process management, ProcessUtils. The problems have become more frequent with recent versions, with timeouts already when checking version numbers, and later process launches that fails, and once it has failed it seems I can't start any at all.
In the longer run, I know that I must look closer into a transition to Cocoa. The PasCocoa project has made much progress, and is surely the right way. To begin with, their demos look a lot nicer than the Objectional-C ones. (Sorry for the pun but it fits so well.) I have kept the GUI strict, and that will pay off twice. It not only gave us a simple-to-use GUI, a good thing in itself, it also makes it fairly easy to rework. At least that's what I hope.
090503:
Version 0.7.3 was not good. The debugger doesn't work well. Also, I have found some problems with some 0.7 additions. With 0.7.4, I hope it will work better. My tests so far are promising.
090428:
New version again, fixing the most obvious bugs of the new features in the previous version, but also has some work on the debugger. The most apparent change is that the function to run beyond the start if there are breakpoints set now seems to work better. It also has better security in some ways (much needed and we need more). The debugger startup "..." is no longer visible, which I think is a pity. I will try to put that back.
Also, this is probably the last version with QuickDraw graphics. I have a nice new unit re-implementing QuickDraw on top of Core Graphics, making it (almost) as easy to use CG as QD.
090423:
I do a big upload today, two versions of Lightweight IDE and complete sources and demos. Two versions? Yes, there are important changes (scrollbar bug for big files fixed) that I want to deliver independently of more experimental changes (custom controls for making the pop-up menus visible for newcomers).
So the situation is this: Updating to 0.7.1 is recommended and will only make things better as far as I can tell (and my test runs show). The big file bug is gone, and nothing seems to have gotten worse in any way. 0.7.2 has a few revisions in the editor, and since the editor is where we work the most that is sensitive. Do you like the new controls? The extra margin to the right? (You most likely like that extra margin.) And is it stable? I have noted some glitches in the controls, but nothing serious. And yes, the white boxes are dull, but the icons I made for them were horrible so they should not be there until they have been made much nicer.
090420:
I tried PasCocoa with Lightweight IDE today, and althought not all demos ran perfectly, it compiles and runs just fine. This should mean that some PasCocoa demos can be added soon. I can't say I am teribly enthusiastic since Cocoa primarily means reworking things that work well already, but it is a comfort to see that FPC as well as Pascal has a brighter future on the Mac now.
090419:
After making the 0.7 upload, I have started spreading the word about Lightweight IDE a little bit more. I know that the looks (icons, colors etc) need polishing, but considerable functionality is in place so it is now technically a pretty good tool. A pretty good tool with a somewhat unfinished look.
This has lead to several opinions and suggestions. Of course not everybody are enthusiastic right away, but I don't worry about that. The exchange of information is the important thing. I have recently added color coding for shell scripts, which effectively makes Lightweight IDE a development system for yet one more language!
Meanwhile, Richard Ward has added even more new functionality in color coding as well as the debugger.
090416:
And now I have uploaded it, version 0.7. The "middle" version number change is mainly due to the new, smarter C builder, but there are also changes in color coding (a new color scheme plus many new symbols being recognised) and in debugging.
This version is not a major change for Pascal users, but for C/C++/ObjC it is a huge step, making the IDE a viable tool for other things than small demos. That means that it is meaningful to find beta testers/contributors among the C/C++/ObjC users! More users, more opinions, more test situations, more demos, more publicity, then this whole work gets a whole lot more meaningful. Maybe we can even get the Linux port started... Oh well, let's not dream too far yet.
090415:
This is a big day for Lightweight IDE! It is a big day because two the really vital improvements have taken off, the second one today and the first just a day or two ago.
The first one is debugger features. Richard Ward has been busy improving the debugger (after some work on the color coder which will also appear soon). Most importantly, the problem of displaying global variables seems to find its solution.
The second problem, solved today, was to make it build C programs as smart as Pascal programs. I do prefer Pascal but I want the IDE to be useful for C/C++/ObjC too. Actually, it was useable before, but only for small projects, since it always recompiled everything. Not any more. :-)
This means that it is time to move up to 0.7. What is then left for 1.0? Well...
That's quite some list, but note that we are moving into luxuary land. :-) Fewer things are absolutely necessary.
090406:
Really long time since the latest update. The IDE itself has few changes, the change back to cmd-R to run without debugger being the most noticable. "Replace all" is also nice, and the bug fixes are important too.
But the biggest news is the "OpenGL" demo folder. During the computer graphics course I run now, which had its lectures mostly in january and february, I was a bit more productive that usual, and created several new OpenGL demos. What you find in the distribution now are some selected demos that I find mature enough to release. Most demos are in C only, but there are also two Pascal demos.
091228:
I step up to 0.6, by adding GPC support. That support is highly preliminary and not tested much, but at least it worked for my limited tests. But even more important is the timeout in some command that were before assumed to return immediately, which saves us from many lockups.
081221:
Merry Christmas, here comes the Christmas release!
Surprise, surprise, there were some problem left. (As if I didn't know.) With 0.5.2, a few more are fixed.
Here are some problems that are not fixed yet, except as noted below:
Still, the 0.5.2 improvements are not too bad. The up-arrow bug is nice to get around, and I hope search/replace will work better now. There has been some particularly elusive bug in the search/replace code, which I now avoid by using the built-in search feature in TXN.
081203:
0.5 is released!
After this major step, which has been the main focus for the project for the last year or so, it is time to look at where to go next. Here are my thoughts on that subject:
It is pretty good, but the Light Bugs window is pretty crude. It needs tidying up, probably with tabs plus some more parsing of the data. Also, editing while debugging makes no sense.
Here are my primary ideas:
It is necessary for using the IDE for larger C/C++ projects, and
This is too easy to ignore. It is mostly a question of changing some compilation options, and parsing the errors with the GCC parser.
Note for 10.5 users: Changing the debug build preferences to -gw (Dwarf debugging info) should be an advantage, and is likely to be default in the future.
081130:
Lightweight IDE 0.5 is now at its first tests outside my house! I just sent a copy to Richard Ward. It is still unpolished in many ways, but you can now:
Notable limitations:
This means that the basic functionality is there! It is still far from 1.0, but I think this can be a big leap forward for LWP, especially for Pascal development.´
081128:
Whoosh, and a whole month went by, again with work that took all available attention.
But now I am back at the debugger development and integration, and it is rolling along well. I made a lot of the integration yesterday. The debugger unit, editor and main unit have most connections established, and new options are added. "Final build" options as well as debugger build options are added. I am getting optimistic. This just might work, and 0.5 is coming up. Real soon now? Well, when it is usable.
081025:
Yet another minor update, but fixing the text encoding was pretty important so it is not quite that minor after all. No more warnings or crashes when you have a non-7-bit-ASCII character in the path.
But this is the last 0.4 version. I have renumbered my local folder "0.5" because now I start the revision to get the debugger in.
081014:
I have been busy the last weekend and following days! Not only have I done good progress on some paid work, but I also made some very significant progress on the debugger prototype! This means that 0.5 leaped a lot closer. The debugger prototyped (hard wired for debugging a single program at this time) can single-step, it can set breakpoints, and inspect local variables. And so far it does not feel particularly slow either!
My biggest concern now is the GUI for the debugger. The prototype is too crude, but I guess a crude debugger GUI is quite enough for its first version.
081009:
Back on track again. Not that I can spend all my time on LWP, but at least I am back in the code. Some bug fixes have been made, and the window placement seems to work.
I also added a link to Ryan Joseph's related project, Pascal Gladiator. The two projects share some code as well as knowledge, and the fact that he makes an IDE that uses project files is only for the better of Lightweigt IDE. That means that nobody must be forced to work with my heavily simplified concept. I am very fond of the project-less situation and the resulting extremely simple user interface, but everybody's need are different.
Pascal Gladiator is what I would call "more coventional", tabbed editor, single-window, with lots of visible controls. Since that is a popular style, I don't in any way claim that Ryan is doing something wrong. I also claim that nothing is wrong with my approach either. All in all, LWP and Pascal Gladiator are very different approaches to the problem, which should mean that a larger number of people will find an IDE that they like.
080904:
Three months since last update here. Yes, I have been busy, very busy. I have written the second part of my computer graphics and game programming coursebooks, and it was a lot of work. That means that I have had to avoid LWP work almost completely for three months! And I can't do much work on it for yet some time. Today, I uploaded 0.4.2 with Saabino D'Elia's latest changes.
I really wish I could spend some time on LWP, and fix that debugger interface (which the last major changes I did were preparing for) but I am overloaded with more or less paid work that I need to do.
080606:
A little big move is done today! I take the step to 0.4.0, which means that things have happened to the editor that opens the door to a lot more (e.g. setting breakpoints!). What I am talking about is significantly better flexibility. As a small start, you will find a line number field and a small left margin. As a bonus, there are also bug fixes, some other new features and new demos.
A more visible new thing in 0.4.0 is the Quick Ref. If you ever longed for a fast tool for looking up functions, like Think Ref, this just might be a first step towards such a tool. It gives you lightning fast searches in FPCMacOSAll.pas, on function names only.
080626:
Today, I release 0.3.13, which should be the last one before 0.4. This is an important release, since it is the first time someone other than myself, namely Saabino D'Elia, have made changes in the code. And they are quite significant. In my opinion, the most important one is the feature to select font, but the color scheme selection is also significant.
So, why will the next be 0.4? The reason can be found in the Demos folder. The demo "Custom TXN" is my first result with the modification to the text editor that will open the door to many important features (like line numbering and breakpoints). And this is not all. Important new things are coming, and in the next version a few of them will roll in.
080613:
Oh, that dreadful ReadLn/termios problem... Today, i tried hacking around it, and I belieae things are better. Not perfect, but better. There is a strange extra CR for input in PPC, which I havn't figured out yet, but that is a minor annoyance comparing to the problems that were fixed. At least, that's what I think.
080530:
I have been sitting with a termios bugfix for a while now, so I release 0.3.11 with that fix. This is very minor for most of you, but if you use terminal input functions it is vital. It feels like about time to move to 0.4 now, after the "bugfix" level went to two digits, but I have my plan for what 0.4 means and stick to it.
Sadly, my tests on PPC shows that we still have a "termios" problem; if I make it "readln friendly" it works just fine on Intel, but then the PPC lockups are back! So it seems 0.3.11 is "Intel only" at this time. Sorry about that.
080514:
Oh, those bugs...
0.3.9 seems a lot better than the 0.3.3 to 0.3.7 range (which should be avoided), but I found some new bugs. In particular, the "uses" pop-up stopped working (which I use all the time), which was due to an error in the revised FindOrOpen function. So by supporting full paths, I accidentally un-supported most others. Now, 0.3.10, it works better. I will not promise that there are no bugs, but it has worked through my tests.
Also, the font handling revision was meaningless until now, when I figured out that the font numbers are only sometimes compatible with the QuickDraw Text call I was using. Now I see Monaco on both Intel and PPC.
080511:
Reluctantly I must admit that the latest versions of Lightweight IDE have serious problems running on PPC, at least under Tiger. I have mostly tested on Intel, where things seem to work very well, but since Richard Ward alerted me of the problem, I first found the font/color bug fixed in 0.3.8, but then I have found even more serious problems. So if you arte working with PPC you may need to back down to something like 0.3.2 for now. (Before the Leopard fix. It must have happened there.)
Later same day:
I have found some kind of fix for the lockups, but I can't say this is necessarily rock-solid. I have tested it a bit and all seems well, so it should help, but let me know if things got worse on Intel Macs.
080509:
Oops! One of these bugs, a simple little mistake in 0.3.7, which made it pretty useless. I hope 0.3.8 will be better. As a bonus, the need for separate Tiger and Leopard versions is eliminated.
080503:
Second release in two days! And this is a pretty significant one!
Yeaterday, Adriaan van Os and I had a discussion about the benefits of supporting makefiles. My biggest concern is to avoid to complicate the IDE by adding new menu items, settings or, worst of all, demand new mandatory operations by the user. It did cost one setting, for save format of text files, but otherwise nothing changed for the user who doesn't need makefiles! This is good! The change is totally transparent for the quick hack usage that LWP is so good at, while anyone who really needs a makefile has that support. Power and simplicity! An open question is whether there should be some kind of mechanism for running make with other targets than default or "run", but that is irrelevant for now.
Let me stress this: makefiles are supported as an option for advanced users, not for the average user. Anyone who doesn't need makefiles (and LWP is mighty good at making makefiles superfluous) can keep skipping them! But with them, LWP might be of interest for users of GPC and GNAT even without any specific support for these compilers. I would like to add that support, but this opens the door with little effort.
080502:
Time for a new version. This time, I include two versions, one for Tiger and one for Leopard. The Leopard version should work on Tiger too, but the Tiger version has better performance. Sabino D'Elia's demos are back, and a bunch of new demos by myself are also added.
080408:
List time! I just felt like making these two lists, so I did.
I may change this list when I think of more, because there are so many reasons. Also read Owen Hartnett's similar list on Pascal Central.
What about C# or D then? Well, first of all, I havn't tried them, but as I understand, they are designed to be C-like and that is a warning sign. On the other hand, I understand that the mind behind C# is the same guy that wrote Turbo Pascal. A sign of decline or hope?
080330:
After two weeks of work, I think I have found a solution. I run a pthread polling the input, which then forwards the data though an extra pipe. I tried many other approaches and finaly I fond one that works. Beware that 0.3.3 might introduce bugs. Thus, I primarilty recommend it for Leopard at this time.
080324:
"Real soon now" is often longer than you want it to be, and that is all too true in this case. I have searched for information and tried everything, but it still does not work. There is a major difference in process communication between Tiger and Leopard, and everyone who has tried making a GUI front-end to a CLI app must experience this, but very little is written about it. I have Googled on dozens of sets of related terms (forkpty, SIGIO, SIGCHLD, ioctl, fcntl...), and although I have found one or two people with similar problems, there are no answers.
Anyway, I have not given up. There is a simple solution somewhere. But if you can help, please contact me. For now, I hope that the Darwin-Dev mailing list can help me. I posted a question there today.
080322:
I have some good results with the process management under Leopard! There are indeed differences, but I think I have nailed down the important differences. I hope to have a fix ready real soon.
080321:
After reports of erratic behavior under Leopard (error messages were not displayed) I have now tested under Leopard, but still see no problems. For now, my guess is that the problem appears when using old FPC versions. As soon as I know more, I will report it.
080308:
Things are happening, and it is soon time for a minor release. Well, semi-major. 0.3.2 will sport a multi-file search feature, an improvement almost big enough to call it 0.4 (but I won't). It will not be perfect in its first version, but it is a big step for the editor. Apart from that, debugger interface and new text engine are long-term plans that have came a bit closer. Also, the startup time, which got quite a big longer in 0.3.0, is now back at its old lightning fast speed.
080303:
No new release for a month, but not for lack of progress. I am working on very important modules, that will make the upcoming 0.4 and/or 0.5 quite significant. The current plan is:
0.4 will include a crude but not totally unworking debugger interface. (This is more or less working already.)
0.5 will sport a revised text editor, opening the doors for just about any feature we have been missing. (I have a draft running.)
0.6 will integrate the two into a debugger interface somewhat along the lines of Think/CodeWarrior.
And then, of course, the path ahead from 0.6 to 1.0 (if I ever get there) is full of bug fixes and other improvements, but I have not made any version plan for those.
080202:
Today, I decided to upload version 0.3.0, with a number of fixed that I have done from time to time during the winter.
Why 0.3.0? Not because I couldn't call it 0.2.10, and not because it is much different (like the 0.1-0.2 step) but since I added support for Java. I doubt that Java will ever be a high priority, but adding this much was a fairly small thing. Pascal is still top priority, with C/C++ coming second, mixing C and Pascal a good third.
During the spring, I will make further improvements, and some time there will be a 0.4, which should be the first version with some kind of debugger. Beyond that, I look into a major revision of the editor, replacing MLTE with WASTE. That's the big things in the plan. There are more things to wich for, like some simpler form of auto-completion, various things that will be possible with a better editor (code folding?) and smarter ways to build (optimized C compilation, adding frameworks based on C #includes, checking for .a when .c is missing and so on). But first things first.
080118:
No updates in some time. I have not dropped the project, not at all, I am using LWP myself all the time, but I have not had time to work on new features. I have written a course book, plus some other work. Some fresh LWP users have been communicating with me lately, which is very good; they remind me of needed improvements and help me plan the work. Expect new updates in february.
071128:
November has not been the best month, but now at least I have released 0.2.9 with some fixes and new demos. I thought I should have a debugger interface ready by now, but the number of problems have piled up and paid work must be done. The debugger problem is not at all impossible, my process management unit is quite good.
The list of things to fix is long (debugger, replace MLTE, more work on smart C builds, smarter multi-language builds, multi-file search, more editor features...) but on the positive side, it still is a fully usable development system, so let's use it and add features now and then. If you want to help me developing it, please let me know.
071020:
I upload version 0.2.7 today. That is a very promising version. As far as testing has shown, it works very well, and is a major improvement for Lightweight IDE as a C/C++/ObjC development system. Pascal users get their share in a smarter "run" command and support for an entire resources folder to be copied into the bundle.
I like it! If we don't find any alarming bugs, I will return to the debugger problem.
071018:
Lightweight IDE has been moving pretty fast the last weeks. 0.2.6 feels very nice for Pascal development, and C/C++/ObjC work for small projects. The first Objective-C demos have been added to the Demos folder. However, I have found a problem with GCC that has to be solved before it is usable for medium-sized projects. For now, C programs must have all source files in the main folder or they will not work. (Lightweiht IDE will find source files that GCC does not find.)
0.2.7 will be uploaded soon. An important new feature is that it now properly tests all source files on "run" before deciding whether to rebuild or not (point three on the list below). This will make quite a difference. It will now be possible to do "run" with more confidence. You will still have to "build" on resource changes, though. A smaller improvement is that the #include menu now seems to work correctly with C code (point 2 below).
071015:
And now I've found a bug that caused much trouble. 0.2.6 seems very nice so far. I am sure I will find more bugs, but this feels like a good leap foward. Of course, there are still many things to do:
Nevertheless, it is becoming more and more powerful, still without losing its simple interface.
071012:
I am fighting bugs, callbacks that disappear mysteriously (causing the spinning wheel to keep spinning after the process has terminated), and crashes. I am not happy with 0.2.5, it will have to be replaced soon.
071010:
No debugger yet, just a few fixes, but I like the new additions. The error window popup menu means that you can skip all warnings and notes, handy when you are still hunting compilation errors. The expansion of the selection is also nice. I always had problems seeing what line I ended up to.
071008:
I am drafting a first try for a debugger interface. I have some progress, but it is not entirely trivial. Debugging in the editor windows seems a bit too tricky, at least for the first attempt. On the other hand, I really want a tight, uncluttered solution. There are also a few old bugs in Lightweight IDE that will need attention, but nothing that renders it useless. The most irritating one is that the process wheeel often stays on when it should stop.
071004:
Version 0.2.3 will be short-lived! It has some stupid bug that nullifies the color coding. It will be fixed ASAP!
071003:
Version 0.2.3, first universal binary, and a few other minor improvements. And working on debugging. I am also studying alternatives to MLTE.
070902:
I got inspired and implemented a hash table for syntax highlighting, which speeds it up a bit, and most of all allows more identifiers with no loss of speed, also making it possible to make it customizable. And now I am working on a better check for the compilation need at "run", using the same code that builds the file list when compiling C code. This will also be the base for multi-file search.
If the date format confuses you, it is YYMMDD, a common format here.
070831:
New version! I didn't really plan to work on Lightweight IDE during august, but I ran across a bug that needed fixing.
070803
I have been away for over a week, and will not do much work on Lightweight IDE during august, since other work needs priority. But in september, I plan to be back to Lightweight IDE, and work on:
070719
Second update in two days. Fixed the menu bug, and the problem that the nib file was not updated, but most importantly I added security checks for strange paths. Some paths could make the IDE crash, like if you have an Ä in the path, but even more importantly, all characters that can trick a command line to navigate to strange places are disallowed. So thereby there should be no risk for loss of data in other places of the disk, even if you use the strangest folder names.
070718
Rollout time! Today I fixed several problems, and after working on a strange editor but I decided to release a PPC only binary (usable on Intel of course, and fully capable of making universal builds).
This is the first "real" release in three months, but that's not because I havn't worked on it, but because there were so many new and heavily revised components.
070716
The Sourceforge name, and thereby the link, is changed.
More news:
070712
Now the fourth and (for this release) final C/C++ strategy added and working. Only some debugging and fixes and it is ready. As noted below, this will be a major upgrade for C/C++ and Pascal alike. C/C++ gets the much needed support for multi-file builds and Pascal gets universal binary support.
070711
Progress has been good lately.
Some debugging and one more build strategy and it is ready for release.
070706
Great news!
New version of Lightweight IDE is coming real soon now! I have been busy porting the framework underlying Lightweight IDE to "modern Carbon", and now it works. Not only that, I have also made a new build procedure for FPC which means that both Pascal and C can build Universal binaries! And I mean with no effort on the user!
So here are the news in a bullet list:
070608
Lightweight IDE has been in development since last autumn. I have almost completely stopped writing about it in the Pascal list, since I get almost no response from there. It is sad to see that the Pascal community doesn't seem to be intertestedin an IDE written in Pascal with Pascal in mind, but that's the way it is.
But I keep developing, for myself and for the few who wants it, widening the scope to give GCC higher priority.
I made much progress in the autumn, but had to stop development during the late months of 2006. In 2007, I have continued, and made releases every month from february and on. The april release was qute good and I use it for all my development now.
One more thing: My trusty old Pismo is getting phased out. Linking OSX code on a G4 is quite slow, while buidling is lightning fast on my MacBook. At last I have a portable Mac that is truly better than the Pismo! I can wholeheartly recommend an Intel Mac as primary platform for compiling your FPC programs.
Currently, I am working on a modernized version of TransSkel. TransSkel is not a "skeleton program", but a very nice application framework. At first look, it may appear that its callback-based architecture is obsolete in the days of Carbon Events... until you realize how much code it saves. So I have made, and am getting close to finished, what will be TransSkel 4, a fully Carbon Event-savy TransSkel that will work well with modern Carbon.
The new TransSkel will primarily be applied to Lightweight IDE itself, removing the time-wasting WNE loop, and making it easier to plug in other modern technologies, and look a bit better.
Once LWP works in its new "dress", three things have top priority:
- Debugger interface
- Smart building of C/C++.
- Universal builds for Pascal programs
The first is necessary to make it a complete IDE, and the other is what will make it something special to C/C++ users. It should eventually also include smooth integration of mixed-language applications. The third point is important for Pascal compilation; for C, it is already solved.