MicroGolded editor released

[Dietmar]

microgolded is a simple yet powerful editor for AmigaOS, MorphOS and UAE.  It is a low cost variant of GoldED AIX, designed for basic editing tasks. The editor is released in form of a single executable, for placement in the system's c folder. microgolded is the ideal editor for the boot CD of your OS because it does not need to be installed: it does not need an assign, catalogs, custom libaries etc. It will run even if the AmigaOS startup-sequence is not functional.

Read more at:
http://golded.dietmar-eilert.de/news.htm

Availability

microgolded is only available online for instant download (pay securely via paypal). The retail price is 10 EUR. On the launch day, the special retail price is only 5 EUR if you go to this page:
http://golded.dietmar-eilert.de/golded/offer.htm

Download

You can download a 30-day trial version by clicking on the link below:
http://golded.dietmar-eilert.de/golded/files.htm

[Dietmar]

>So now there's GoldEd, GoldEd lite, and... GoldEd lite lite?

You must be very averse to upgrading software, GoldED Lite was a product I had in GoldED4 times. That must have been, what, five years ago. Since then there was no lite version, just GoldED Studio: 5, 6, then AIX since about two years (morphed is GoldED Studio 6 for morphos, slightly updated in some areas for their SDK, sponsored by Genesi with hardware and thus free for MorphOS).

[Dietmar]

> One of the reasons I didn't enjoy GED was the requirements for assigns and the huge amount of settings, not to mention the registry style preferences.

An assign is extremely useful, you can use it in macros, in menus, in related programs that need to find your program, in plug-ins, in uninstallation code etc. It's one of the best things about AmigaOS. Not using an assign for a modular application like GoldED that consists of 20+ libraries and external modules is stupid. In the case of microgolded, no assign is necessary because it simply does not have external stuff that needs to find it (such as a starter, an uninstall program, an update program, no macros that need to know where GoldED is, no third-party add-ons etc.). In this case, I can  get away with "progdir:".

As to the registry: It still has registry-style preferences (compiled into the program and saved to a real disk file as soon as you start customizing it) and that's a good thing. The problem is that users hear registry and think Windows and black out. Registry-style just means that the configuration is a tree of objects. Why is that good:

1. "tree" means it's structured. Structured is always good from a developer's point of view. Structured is good for maintainability, clarity, flexibility etc. OS4 will have structured preferences in form of XML. The opposite of structured is flat or mildly structured, like Windows .ini files.

2. "objects" means that its a generic typeless format that can be used with generic code (such as a "save subtree function"). That is incredibly efficient in terms of code size. Saving the menu, keyboard layout, colors, macros, sessions, having undo in dialogs: it's all the same function in GoldED. Having the structure in the file and not in program code is useful, too, but a bit too esoteric to be discussed here.

As far as Windows is concerned: IMHO the bad thing about the registry is that it is a central file to the system, a mega-database, that is difficult to comprehend because it's so large. The format per-se is ok, it's the use that sucks. I don't think a textual format like xml would make it any better if used the same way (regedit is more convenient to use than an editor, it would be incredibly easy to corrupt it with a few careless keystrokes, wouldn't it?).

[Dietmar]

> Forcing more than one assign per program is utter overkill, no matter.

GoldED itself needs and installs exactly one assign (golded:"). The rest of the assigns is for other programs. gcc needs a few, ispell needs one, vbcc needs a lot, the basic interpreter needs one, the devkits: package gets one etc. All that is quite beyond my control. The total number depends on what you install and if you install just GoldED, you get one assign.

> And forcing generic assign names onto system, such as "Dialogs:" or "Data:", that is just plain stupidity.

Yes, I agree, and what exactly is your point? As if any of those were used by GoldED. Well, BASIC: used by the BASIC interpreter was a bold choice, so sue me

>As for the registry - ENVARC: and ENV: for crying out loud!

Now that's smart. A typical golded configuration with dozens of file types installed, is 400 KB. ENV: is in RAM. There is absolutely no justification to put anything into env: but simple strings. Besides, I dislike programs that clutter the system. For that reason, no GoldED files are installed outside the GoldED folder. Not to env:, not to envarc:, not to libs:, not to fonts:, not to locale:

>As I see it, GoldED is a pile of poopoo:
>it doesnt follow the amigaos way of storing settings

So what is the amigaos way of storing settings? Every application seems to use a different approach. Even if a semi-standard like IFF is used, there hardly is an advantage in that.

>* it instead tries to recreate a tiny microsoft windows-like world of its own, with its own registry like system

Linux world, Windows world, Microsoft world, whatever. The stuff swapping over from there (like the IDEs) tends to be good and I like it. Natuarally, that shows in my software. As to this obsession with the word registry, please do something about it. Like, think of it as a configurtation file in a format you don't understand. Just like the configuration file of any other Amiga program.

* it requires several generecly named assigns that very well might crash with assigns or volumes the user might have already

"golded:" is hardly generic and "data:" etc. are results of your vivid imagination.

> well referred to via PROGDIR: per default, and perhaps a user chosen path fomr the settings.

"progdir:" is only valid in the context of the program that evaluates "progdir:". This limits is usefulness. It is utterly useless in install scripts, uninstall scripts, rexx macros, add-ons, configuration files not parsed by the main program etc. There is no way an application like GoldED can be written without an assign or the functional equivalent, an env variable. Choosing an assign over an env variable was an obvious choice.

>* .. and with those icons, it even looks like a microsoft wannabe program.

Now you start to sound a bit mad You forgot to mention that the updates are named "servicepacks" and that the GoldED web site is hosted on a Windows PC. Gosh, where do these creeps come from?

>AIX? Have you discussed that name with IBM and Motorola?

As a resident of AIX La Chapelle, I'm a semi-approved user of the AIX name Anyway, that name is not going to be around much longer, it will be changed to GoldED Studio IDE later this year.

[Dietmar]

> the download page loads blank here.

Have you waited? The page is based on a redirection domain (the domain maintainer provides a frame page and the content loads from another provider). The frames initially are blank and can stay blank for a while, with any browser, the content provider is a bit slow.

[Dietmar]

> I'm curious though, why not give the end-user the option to decide what they want to do.

Why not give the end-user the option to decide if a car should have four wheels or just three and save the price of one? For a program like GoldED (that is not a single executable but a modular design with many programs), knowing where the package is installed is essential. It has to be noted down somewhere. Related programs, including scripts, can not put up dialogs at run-time to query the user where they find the main program. There are several ways to note the location of a program, such as assigns or env-variables, but only assigns are completely transparent to the system. If you have an env variable, you have to have code that evaluates it - everywhere. For example, if a program has a string field that describes the location of the xyz folder, "golded:xyz" is easy. With env variables, you have to start usig placeholders and substitute their value. Using env over assigns to locate software just makes no sense in large applications, so naturally developers use assigns. That many assigns can make the list of assigns in file dialogs useless is not a problem of assigns per-se but a design flaw in the OS (the OS could have a per-assign flag that says "do not show this assign in user places" that would be respected by ASL etc).

>The registry preferences. Not everything needs to be saved. You should only save options that differ from the default settings.

GoldED does not have any default settings. That's the beauty of formats such as XML: the structure of the preferences is not stored in the software but in the files, giving near-endless flexibility. The editor just loads the tree of objects, it doesn't know its structure except in broad strokes. If it needs the setting of anything, such as "overwrite mode", it looks up the symbol GLOBAL_OPTIONS_OVERWRITE (but it does not know exactly where in tree it is).

> Those settings could be saved in XML format when 4.0 hits.

Generally speaking yes, but in this case I will stick with a binary default format (it's a structured format just like XML anyway). I already have a command in the editor that can save the settings as text file, because sometimes it's convenient to have text (search and replace), but it blows up the size of the files by a factor of five or more. Since the settings can be very large - for example the syntax setup contains 200 KB of OS constants that should be highlighted - that is just not acceptable.

> but it just feels out of place with the rest of the Amiga programs. Are there any options to use Reaction/MUI or release the window gadget toolkit publically? If more tools had the same GUI, it would fit better into the system

This GUI system started with GoldED5 (before 1998). The version before that was Gadtools-based. Gadtools has no treeviews, so I had to start implementing my own treeview or use the only other quality choice at that time, MUI. MUI back then was plain shareware and therefore not acceptable for a commercial program. As to releasing the code to the public, I have no such plans as it is not in a releasable state. MUI or any other Amiga toolkit can not be used easily because my gadget system is designed to directly use the underlying object tree, ie it is integrated tightly. If you rename a node in a tree or delete it, the toolkit does that. Clasic Amiga toolkits use a totally different approach, they pass actions and values into and out of the toolkit via tags and notifications. They do not directly work with attached objects. Btw, I don't think it looks totally out of place, it's basically gadtools style.

>Features I would love to see, a toggle key. Something that would change the layout of the keys at the press of a single button (say numlock on a 104+ keyboard). The ability to change the toolbar images would be nice as well.

That's possible with filetypes in GoldED (not in microgolded, which had no filetypes). For example, the C/C++ mode uses a drop-down menu to toggle the toolbar from SAS/C to gcc etc. You could do the same with a key: keys, menu items, etc. are all configured in the same dialog. In microgolded, you would have to use conditional code, ie. configure certain keys with the internal IF command. Example: "if NUMLOCK=TRUE, then do THIS else do THAT"). If you mean to change toolbar images to better images, that's obviously possible, too.