R.O.M.E. Application Framework

[NerdFencer]

This is the start to an application framework that I have had cooking in my head for a little while now. Here is the general idea...

• A handy menu appears, and is the core UI of the framework
• Many different "modules" place icons on this list for the user to select
• Infinite numbers of modules can operate at once without multiple instances driving them
• ROME handles the core events, doling them out to the appropriate active modules
• ROME will handle many of the repetitive code tasks for the programmer, allowing them to more easily create a powerful digital tool-belt

So far here is what I have

• Basic framework that handles windows and modules
• Dynamic module menu
• 3 Example Modules (demonstrating different uses and techniques)
• Download GUI API (creates and manages a GUI for file downloads)

Some advantages...

• Faster application dev time
• Convenient menu
• Less scripts floating around (on a flash drive, this is extremely useful)
• Reduced memory use when running multiple scripts (one instance of AutoIt)

Updated to v 0.0.3
-Updated to be far more modular
-ROME.au3 and API.au3 now generated by generate.au3
-Dynamic detection of modules and API additions

Updated to v 0.0.2
-Many bug fixes
-Added DownMan API
-Added "Windows Tools" Example Module (actually useful :D)

Previous Downloads: 142

Comments, Suggestions, and Modules are Quite Welcome

ROMEv003.zip

Edited February 12, 2010 by NerdFencer

[nugame]

keep going.

[NerdFencer]

Updated to v0.0.2

Fixed many bugs and began adding extra functions...

Any suggestions for things to add to the API?

[jvanegmond]

I like the idea of this project and how professionally you've handled it so far, but I'm really not fond of parts of the implementation.

I think that the way you set up the plugin system makes no sense. The /API/ folder contains both core functionality of ROME as well as functionality of the modules. The /Modules/ folder contains a core file for the ROME plugin system.

In my opinion, the modules folder should only contain other folders. These other folders contain the actual modules, which place all the files they require in there, as well as a main.au3 file which is the entry point for ROME. The terminology modules and plugin confused me too. Which is which, or what is the difference between them? Define your terminology and stick to it.

Why you haven't used dynamic including is a little bit of a mystery for me. You can write self-modifying code that will include all the necessary module code, or you can let each module run in its own process and you can be responsible for the interoperability between ROME and those modules, or the modules amongst themselves.

In short:

I'd like to see a new setup of the files:

/main.au3 ; The entry point from the users point of perspective to run.

/libraries/*.au3 ; Containing all the functions of the core ROME functionality

/modules/modulename/main.au3 ; The main entry point for each module

/modules/modulename/*.au3 ; any additional files the addons may require. Think UDF libraries, etc.

Rename modules to plugins or plugins to modules.

Use some way of dynamic including or provide more flexibility.

But of course, as always, how you deal with this if at all is up to you.

[NerdFencer]

I had something similar coming to mind, but hadn't gotten around to it...

Your ideas combined with that have lead me here...

Structure

|-Core.au3: Entry point for the user to run ROME

|-Generate.au3: Generates fresh copies of ROME.au3 and API.au3

|-Modules: Folder

.|-ROME.au3: Registers all the modules, generated by Generate.au3

.|-Category Name: folder

..|-Category.ini: File used by Generate.au3 to create categories

..|-Module Name: Folder

...|-Module.ini: File used by Generate.au3 to register the module (defines main script file and function to register the menu items)

...|-Module.au3: File name determined in Module.ini. The core file for the module. must include a function to register menu items

..|-Another Module: Folder

...|-You get the point

..|-Another Category Name

...|-And the cycle can continue

|-Libraries

.|-API.au3: Generated by Generate.au3 - Entry point for ROME to its API

.|-WinSys.au3: Default critical library that handles the window

.|-TreeSys.au3: Default critical library that handles the tree

.|-DownMan.au3: Default non-critical library that provides a download GUI system

I am creating a module that will automatically generate blank modules so that nobody needs to learn the system before creating modules of their own.

Any comments/suggestions?

[NerdFencer]

Updated making everything MUCH more dynamic