EasyGUI wrappers?

[SamuraiCrow]

I see there's a third-party EasyGUI clone for AmigaOS 1.2 on Aminet.net but I was wondering if Jason Hulance ever released the official versions as open-source? I was thinking of trying to make a wrapper for ClassAct/React and MUI using their equivalents in EasyGUI and making more plugins as needed.

[SamuraiCrow]

I found the original version in the AmigaE 3.3a demoversion archive but the 3.3b3 version did not include source.

[dmcoles]

I had some thoughts about this a while ago and I did have a bit of a look at the code with the same idea.

Never actually got any further than that though.

[SamuraiCrow]

It'd be a wonderful addition to the Framework. I don't know if anybody will use it though. It's late to the party.

[SamuraiCrow]

Maybe a GUI.library based on the syntax of EasyGUI might be useful. Including that in the Framework might even open the door to EEC going cross-platform.

[Hypexed]

It is designed to use Gadtools. But it does hide that so using it as a GUI builder for other engines should be quite possible. I can't find any version info in the EasyGUI source I have.

The wrapper for OS1.2 is not stand alone. it relies on an old technique in the early 90's for running new OS2 software on old OS1.3 systems using gadtools13.library to emulate the interface. I first found this library when running a demo Deluxe Music on my A500.

Some limitations or quirks of EGUI could be improved. For example always using a resizable window despite not needed. It also included lots of code you won't need in a simple interface though there is a lite version. Because of this I created my own simple GUI builder called GTK for Gadtoolskit. It's a simple stacker based engine that just stacks a few simple gadgets vertically.

[SamuraiCrow]

The initials GTK normally are associated with GIMP ToolKit on Posix platforms like Linux. Having a wrapper for E to use any GUI would be nice though.

[Hypexed]

Yes, but GIMP isn't normally associated with the Amiga and I'm not aware of any Amiga GIMP port being around in the early 2000s. :-) Plus when I thought up "GTK" I'd never heard of GIMP nor knew about this funny looking OS called Linux. :-D

[SamuraiCrow]

Is the source available? I'm trying not to waste too much time on a development system that won't be used much but I'd like to look at it. (All the same, the name should be spelled out for the sake of disambiguation in the present era.)

[dmcoles]

I found the original version in the AmigaE 3.3a demoversion archive but the 3.3b3 version did not include source.

The easygui source code and binary easygui.m that is in the public Amiga E 3.3a demo version (http://aminet.net/package/dev/e/amigae33a) are dated 09-Oct-1997 and the release package for easygui 3.3b.3 (http://aminet.net/package/dev/e/EasyGUI_v33b3) is dated 10-Jun-1997 so i believe the source code included in the E 3.3a package is probably the final code. The included readme in the easygui folder also refers to the version being 3.3b.3. Compiling the source code using EC REGS=5 produces a binary match for the version included with the amiga e package but it is slightly larger than the one in the easygui 33b3 release package.

[SamuraiCrow]

Thanks for doing the research! This may be useful after all. I've got some ideas brewing but if @Hypexed wants to share his code, that might give us a better starting spot anyway.

[SamuraiCrow]

If I continue this idea, I'll probably break compatibility with EasyGUI and use a more flexible syntax.

[SamuraiCrow]

After looking more carefully at the EasyGUI sources, there seems to be an anti-pattern of enums in a case statement. I think inheritance would be preferred in this case. If nothing else it would be more maintainable.

[SamuraiCrow]

Update

I've forked Rebuild from the original by @dmcoles but the only difference is that I've marked the License.md file so GitHub can find it. (It's just a cut-and-paste job from the Readme.md file.) It is presently hard-coded to use Reaction but it is maintained and looks better than MUI Builder and is more maintainable as well.

@Hypexed , if you don't want to share the source to GadToolsKit, maybe take a look at the others. MUI Builder is stuck at version 2 and the version 3 source is supposed to be the start of an almost-total rewrite of it anyway. It's written in C and is difficult to maintain. The E generator on the Aminet is out-of-date and closed source anyway. I'm not the author but I figured putting the source on GitHub would be more visible than the original SourceForge SVN. Rebuild uses inheritance to generate all the exports and is monolithic as a result.

My Question

Would a cross-GUI compatible builder and API still benefit the Amiga community at all? I think Rebuild is a good start and having an import engine to read in MUI Builder files can be done. Both file formats are text-based anyway and source code is available for both. I just wonder who would use such a thing in this day and age when Amiga is just a final lawsuit away from being taken off of life-support.

[SamuraiCrow]

Answering my own question:
Amiga doesn't need app development unless it can duplicate the success of its contemporaries on other platforms. Having started out development of a Dart app for browsing forums on any one of 5 operating systems, (Android, iOS, Linux, macOS and Windows specifically, in alphabetical order,) I can say from experience, that Flutter is the best app development system out there for native applications.

What Does Flutter Do Well?

• Hot reloading of GUI applications as soon as you save a file you've edited
• Wraps languages custom to those operating systems: Kotlin on Android, Swift on iOS and macOS, and C++ on Linux and Windows
• More widget types than MUI or BOOPSI can shake a stick at

Can AmigaE Do What Flutter Does?

Point 1:

• Compiling each local emodule to a shared library would make the program modular enough to exclude unchanged components.
• An E-specific Make replacement like EBuild can add functions to auto-generate dependency trees to allow automated rebuilds.
• Doing hot swapping quickly requires both of those plus one additional item: hardware support of enough memory to debug the overhead-laden libraries.

We have some of that started but a long way to go.

Point 3:
Both MUI at MorphOS and BOOPSI native at AmigaOS 3 team are being developed slowly but modularly. Modularity has the advantage of allowing 3rd party development and interoperability.

Point 2:
This is the most important part. If AmigaE could do what Dart Native can already do, we wouldn't have to beat Flutter. We could join them!

AmigaE has a list type as powerful as Dart's! Being weakly typed eliminates the development overhead of type micro-management but makes it ill-suited to getting to a debugged state.

Solution and Conclusion

If Amiga really needed an application source both easy to debug and powerful to develop in, making an AmigaE backend for Dart would be a splended solution to Amiga cross development!

Ultimately, for something like this to exist it will take effort: team effort. If apps need porting Amiga, Dart is a source. Do you agree?