New beta of PortablE (r6, the beginner-friendly release)

@ChrisH

Kudos to you

I have uploaded a new PortablE beta archive with a very small fix (almost cosmetic):

* When the installer deletes obsolete modules, it will no-longer fail to delete a couple of folders (which was harmless but might have worried some people).
* A small 'bonus' is that the installer will now delete a few obsolete modules that I had previously overlooked.

Users who have already installed the latest release of PortablE do NOT need to download it again!

Today (14th July 2013) I have released a new PortablE beta of my modernised AmigaE programming language. The highlights are:
* Added dynamic lists to the GUI module.
* Added three programs demonstrating dynamic lists: Stacker, SimpleGameLauncher, and DirList.
* Added support for embedding native GUI elements (e.g. MUI objects), so people can work-around any cases where PortablE's GUI system is lacking something they need.
* Added support for dropping files on GUI windows.
* Added support for GUI windows saving/loading their size & position.
* The GUI now auto-activates the first text input item, so you can start typing straight away.
* It now tells the user when the NList or TextEditor MUI classes are required but missing.
* AmigaOS4: Fixed non-drawable bitmaps being moved to video memory by Picasso96, thus potentially saving a LOT of video memory. (A new beta release of PictureAlbum with be forthcoming.)
* AmigaOS4: Fixed a mistake that would have caused non-bitmap drawing with the Graphics module to not work after a planned update to OS4.
* Windows: Fixed installation failing to create the required Assignments.txt file.
* Removed source<>destination restriction for StrCopy(), RightStr() & MidStr(). (I think Chris Y once requested this!)
* Fixed stereo sounds being silent for their second half.
* Fixed various other bugs.

Also note that I have updated & recompiled all the examples.

The full list of changes:
* Added the parameter "startPos=0" to the procedure Val(). This removes the need for pointer arithmetic.
* Added the 'std/pBox' module, to provide a simple but very flexible way of storing various types of data, without needing separate getter/setter methods for all of them.
* In 'std/cPath', added the RenamePath() procedure, so you don't need to open a file anymore to just rename it.
* In 'std/cPath', added the ReadLink() procedure, so it is now possible to get the target of a soft link when the target doesn't exist.
* In 'std/cGui', added support for dynamic lists (see cGuiWindow.beginList(), cGuiList, etc), plus three example programs.
* In 'std/cGui', added support for embedding native GUI elements (e.g. MUI objects), so people can work-around any cases where PortablE's GUI system is lacking something they need.
* In 'std/cGui', added initAllowDropFiles()/etc & getFileDropped()/etc methods to the cGuiWindow class, so GUIs now allow files to be dropped on them.
* In 'std/cGui', added initSaveID()/etc methods to the cGuiWindow class, so GUIs can now automatically save/load their position & size.
* In 'std/cGui', cGuiButton now listens to initUseLeastSpace().
* In 'std/cGui', now activates the first text input item (e.g. cGuiString), so you can start typing straight away.
* In 'std/cGui', now generates an event when you leave a text input item without pressing Enter.
* In 'std/cGui', now tells the user that the NList or TextEditor classes are missing.
* In 'std/cGui', added the queryExtra() method to the cGuiItem class, and made it do something useful for the cGuiList class.
* In 'std/cGui', added the "doNotClear" parameter to the methods getCloseRequest() & getQuitRequest(). And calling those methods will now cause their info to be forgotten unless you supply TRUE for doNotClear.
* In 'std/cGui', window close requests are now queued, so there is no-longer any chance of them being lost in a race condition.
* In 'std/cPath', renamed Exists() to ExistsPath(), Delete() to DeletePath(), and DeleteDir() to DeleteDirPath(). But the old procedures still work for the moment...
* In 'std/cGfxSprites', the setDataBox() & getDataBox() methods of cGfxSprite REPLACE the old set/getDataPtr() methods, and their usage is slightly different. This should be completely future-proof, so no more changes will be needed.
* BUG: Windows: Fixed installation failing to create the required Assignments.txt file.
* BUG: C++: The 'CSH/pAmiga_fakeNewProcess' module (and thus cGfx/cMusic/cSnd) would not work in some situations. Now properly fixed by adding special support to PortablE.
* BUG: C++: For FOR & some other statements, got rid of the (possibly harmless) GCC warning 'comparison is always true/false due to limited range of data type'.
* BUG: Fixed obfuscation of FUNCtions randomly marking it's call() method as being an ORPHAN.
* BUG: Removed source<>destination restriction for StrCopy(), RightStr() & MidStr(). Fixed the type of RightStr()'s eString2 parameter (should have been STRING but was ARRAY OF CHAR for some reason).
* BUG: In 'std/cGfx', fixed the timer continuously generating bogus events, if stopTimer() was called without the last timer event being handled.
* BUG: In 'std/cGfx', AmigaOS4; stopped non-drawable bitmaps being moved to video memory by Picasso96.
* BUG: In 'std/cGfx', AmigaOS4; fixed a mistake that would have caused non-bitmap drawing to not work after a planned update to OS4.
* BUG: In 'std/cGfx', AmigaOS4; worked-around composited scaling not working on 16-bit screens.
* BUG: In 'std/cGfxSprites', the findSpriteAt() method of cGfxStack could wrongly still return the (undocumented) background sprite.
* BUG: In 'std/cSnd', fixed stereo sounds being silent for their second half.
* BUG: In 'std/cGui', fixed string objects (like cGuiString) not generating an event when setState() was used on them.
* BUG: In 'std/cGui', fixed string & number objects generating events despite their contents not changing (in several different circumstances).
* BUG: In 'std/cGui', fixed cGuiStringBox.getState() not returning anything after the GUI is built.
* BUG: In 'std/cGui', fixed getState() returning NILS instead of an empty string for cGuiString/etc, if setState() had never been called.
* BUG: In 'std/cGui', fixed crash if program exited before App was built.
* BUG: In 'std/pShell', Amiga; fixed ShellArgs() to return the exact supplied program parameters, rather than stripping quotes & extra spaces. (Unfortunately still has the old behaviour on Windows.)

For the full list of changes & additional details, please see the documentation's History chapter.

Congrats.
Out of curiosity what does Wouter Van Oortmerssen thinks about PortablE?

Kamelito

@Kamelito
He knows of PortablE, but I never asked him his opinion of it... in some ways it would be a bit unfair to ask him his opinion of a project that is heavily-inspired-by-but-different-from his own work, especially when he has long since moved on to other things (and AmigaE was one of his less radical language experiments). I have no doubt that he would have chosen to do *some* things differently, had he the time & motivation to continue AmigaE, but it is hard to say what since so much time has passed (it would doubtless look very different to AmigaE v3). The differences between AmigaOS4 & MorphOS give some idea of how much choice there is even for things based-upon & compatible-with the same parent thing (AmigaOS3.x).

The original AmigaE was heavily tied to AmigaOS & the 680x0 CPU, seemingly without much though to future portability, and that meant I had to make a number of changes to maximise portability (between different OSes *and* different CPUs). It's certainly *possible* he would have chosen to minimise portability (i.e. make it difficult to re-use the same source code for different OSes and/or CPUs) and instead concentrate on other aspects (such as allowing maximum low-level access).

I chose the path of maximum portability, so as to minimise the work needed:
(1) to write programs for Amiga & other OSes (thus hopefully making it viable to continue supporting the Amiga despite it's small userbase).
(2) to support multiple PortablE targets (OSes & CPUs), and thus hopefully be able to continue using & developing PortablE even if something bad happens to the Amiga (or I stop using the Amiga for some reason).

It's certainly possible he would have had different priorities (in a sense he did, as that was why he stopped developing AmigaE!).

I'm glad you wrote about portability how about an OS X port :)
Kamelito

@Chris_H

Do portable have support of rmb drop-down menus ? I just tryed stacker, simplegamelaucher and dirlist : none of them have any RMB menu, so it's a bit not follow the amigaos_interface_style_guide and looks a bit limited when no RMB is possible (even for simple About,Exit and OpenFile in simplegamelaucher).

Screenshots and examples looks interesting, but as far as i remember year ago stop-factor for me was something about those drop-down menus.

@kas1e
Yes you can add menus (some of my programs do have them!), but there is not yet any *portable* way to do so (i.e. needs Amiga-specific code). The lack of a portable solution is mainly down to me not being sure how to handle Intuition's limited number of menu items AND very limited depth.

Examples are supposed to be SIMPLE, hence they don't have many things (menus happen to be one of the missing things).

In my real programs I often don't bother with menus, since there often seems virtually nothing useful I could put in them (and adding menus just for the sake of adding them seems daft). If you want to argue UI philosophy, then please start a new thread!

EDIT: Please note the difference between "PortablE" and "portable"! The first is my programming language, the second is the general term for making something work on different systems

@Kamelito
Ask me about OS X (and Linux) when/if I finish the Windows port of PortablE (i.e. full GUI, Graphics, Sound, etc support). With luck I may have been able to use abstractions like SDL that also exist on OS X (and Linux), although the lack OS X might still be tricky due to (I think) needing expensive Mac hardware to compile (and of course test) Mac programs.

After a user reported the problem, I've released a minor update to PortablE which fixes it to work with AmigaOS4's current SDK (better late than never):
http://cshandley.co.uk/portable/

This does mean you will probably be unable to cross-compile OS4 programs using AmiDevCpp (on a Windows PC), at least until AmiDevCpp is updated to match OS4's SDK (or you update it manually).

If your installation of PortablE already works, then there is NO reason to install this update.

@ChrisH

Is the new SDK available? :S

@Chris
Sadly I'm talking about the *last* SDK, i.e. the one from some time ago. At the time of it's release I was far too busy with other things to even think about it, and then later I had too many things on my programming 'to do list', so it didn't get dealt with until now (I had also delayed dealing with it, as I had been thinking about trying to fully automate the handling of SDK updates, but that's probably far too complex to get done any time soon).