Better application.library support in system components

AmigaOS users can make feature requests in this forum.
blmara
Posts: 76
Joined: Thu Jun 23, 2011 9:03 am
Location: Vantaa, Finland

Better application.library support in system components

Post by blmara »

Hi! After the latest update of ScreenBlankerEngine there seems to be two registrations of the Engine to application.library. This can be seen both by AppManager by Ami603 and winbar.docky. The latter shows now application 'sys/ScreenBlankerEngine' but clicking the entry in winbar.docky does nothing. Nor it or its preferences can be activated byt AppManager functions. Actually, it seems that most of the system components, including AmiUpdate and others that have some kind of preferences editor, don't listen to application.library messages. By these messages programs could be started, closed, put to front, prefs editor opened, made to create a new document or print a document, as shown in AppManager. For the future it would make the system more consistent if all system components would listen to these messages.

Marko
Marko
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Better application.library support in system components

Post by trixie »

@blmara

1) Forget AppManager, there's a much better replacement in the making and almost finished (also replaces Exchange);
2) Otherwise I can only agree with you - take a look what I wrote in the Wiki as a general guidance for programmers.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
ZeroG
Posts: 124
Joined: Sat Jun 18, 2011 11:31 am
Location: Germany

Re: Better application.library support in system components

Post by ZeroG »

I think it would be a good idea to add a new "application.class" between root.class and window.class that handles this kind of things.
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Better application.library support in system components

Post by trixie »

@ZeroG
I think it would be a good idea to add a new "application.class"
Making it a class is only a different way of doing it. Currently, programmers need to use application.library to register their app and report some info about it to the OS - if there was a class, they'd have to do the same, only they'd do it using the object-oriented API. Yes, this application stuff could have been implemented via BOOPSI, like MUI does it. But then again, the functionality wouldn't be available to apps that do not use the BOOPSI framework for their GUI.
between root.class and window.class that handles this kind of things.
As window.class is a direct descendant of rootclass, you can't squeeze another class in between - window.class cannot become a child of application.class unless the former is reworked. But as a stop-gap, it would be possible to write a BOOPSI wrapper for application.library and implement it on the same level as window.class. If anybody gives a damn, that is.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Better application.library support in system components

Post by trixie »

@ZeroG, blmara

OK, I bit the bullet and started working on the Application Class. It's an object-oriented (BOOPSI) wrapper for the Application Library and various other functionality, and it supports the following features at the moment:
  • Application registration and unregistration.
  • Application Library message processing, using a dedicated AM_HANDLEINPUT method and an Intuition-style event loop.
  • An unlimited number of BOOPSI windows can be added to the application object.
To be implemented soon:
  • Sending messages to other applications or to Ringhio.
  • Automatic creation of the About requester (incl. a custom image).
Future plans:
  • Help system
  • Preferences handling (using the PrefsObjects system)
I'm currently testing the class in various projects of mine, and it still needs some implementation thoughts here and there. Once the concept proves functional and useful, I'll move the entire project over to OpenAmiga.org.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 525
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: Better application.library support in system components

Post by LyleHaze »

blmara wrote:Hi! .... By these messages programs could be started, ....

Marko
I am new to application library, and have included it in my last few programs, but I am unaware of this particular feature.
How can application.library start a program? If I understand the operation correctly, it is restricted to working with programs
that have registered, and I expect that a program that is not running is not registered either.

Did I miss something here?
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Better application.library support in system components

Post by trixie »

@LyleHaze
I am new to application library, and have included it in my last few programs, but I am unaware of this particular feature.
How can application.library start a program?
There is no such feature in Application Library, Marko got it wrong.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
ZeroG
Posts: 124
Joined: Sat Jun 18, 2011 11:31 am
Location: Germany

Re: Better application.library support in system components

Post by ZeroG »

@trixie
Nice Class, is it possible to add catalog handling to it?
User avatar
trixie
Posts: 409
Joined: Thu Jun 30, 2011 2:54 pm
Location: Czech Republic

Re: Better application.library support in system components

Post by trixie »

@ZeroG
is it possible to add catalog handling to it?
That is indeed the plan, and the particular implementation idea is the following (to make things as straightforward as possible):
  1. You create (OM_NEW) the application object with some initialization tags, one of them being APPLICATION_BaseName. The basename is required and it is the application name without spaces, i.e. "SuperApp" (such a format is needed for registration: Application Library won't allow spaces in app names).
  2. Still at creation time, the class will look for a catalog whose name is basename + ".catalog", i.e. "SuperApp.catalog". If such catalog file is found, the class will open it and return a struct Catalog pointer in APPLICATION_Catalog.
  3. You can then OM_GET the catalog pointer and provide/update the object's APPLICATION_Description with a localized description string from the catalog.
  4. Then you invoke the launch method, which will register the application and open its window.
EDIT: Automatic catalog handling now implemented!
Last edited by trixie on Sun Mar 16, 2014 1:38 pm, edited 1 time in total.
The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
chris
Posts: 562
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: Better application.library support in system components

Post by chris »

trixie wrote:@ZeroG
is it possible to add catalog handling to it?
That is indeed the plan, and the particular implementation idea is the following (to make things as straightforward as possible):
  1. You create (OM_NEW) the application object with some initialization tags, one of them being APPLICATION_BaseName. The basename is required and it is the application name without spaces, i.e. "SuperApp" (such a format is needed for registration: Application Library won't allow spaces in app names).
  2. Still at creation time, the class will look for a catalog whose name is basename + ".catalog", i.e. "SuperApp.catalog". If such catalog file is found, the class will open it and return a struct Catalog pointer in APPLICATION_Catalog.
  3. You can then OM_GET the catalog pointer and provide/update the object's APPLICATION_Description with a localized description string from the catalog.
  4. Then you invoke the launch method, which will register the application and open its window.
Hmm, could it automatically open an ARexx port as well, using BaseName? And maybe respond to some default commands like QUIT, or anything application.library supports could be handled exactly as if it had come from there?
Post Reply