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
Better application.library support in system components
Re: Better application.library support in system components
@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.
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
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
Re: Better application.library support in system components
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.
Re: Better application.library support in system components
@ZeroG
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.I think it would be a good idea to add a new "application.class"
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.between root.class and window.class that handles this kind of things.
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
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
Re: Better application.library support in system components
@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:
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.
- Sending messages to other applications or to Ringhio.
- Automatic creation of the About requester (incl. a custom image).
- Help system
- Preferences handling (using the PrefsObjects system)
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
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
- LyleHaze
- 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
I am new to application library, and have included it in my last few programs, but I am unaware of this particular feature.blmara wrote:Hi! .... By these messages programs could be started, ....
Marko
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?
Re: Better application.library support in system components
@LyleHaze
There is no such feature in Application Library, Marko got it wrong.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?
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
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
Re: Better application.library support in system components
@trixie
Nice Class, is it possible to add catalog handling to it?
Nice Class, is it possible to add catalog handling to it?
Re: Better application.library support in system components
@ZeroG
That is indeed the plan, and the particular implementation idea is the following (to make things as straightforward as possible):is it possible to add catalog handling to it?
- 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).
- 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.
- You can then OM_GET the catalog pointer and provide/update the object's APPLICATION_Description with a localized description string from the catalog.
- Then you invoke the launch method, which will register the application and open its window.
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
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
Re: Better application.library support in system components
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?trixie wrote:@ZeroG
That is indeed the plan, and the particular implementation idea is the following (to make things as straightforward as possible):is it possible to add catalog handling to it?
- 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).
- 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.
- You can then OM_GET the catalog pointer and provide/update the object's APPLICATION_Description with a localized description string from the catalog.
- Then you invoke the launch method, which will register the application and open its window.