Better application.library support in system components

AmigaOS users can make feature requests in this forum.
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 »

@chris
could it automatically open an ARexx port as well, using BaseName?
It could, of course.
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?
I initially thought the Application Class should do various stuff like this, including automating certain common operations like iconification. However, during implementation it's becoming increasingly clear that this may not be such a good idea. For example, if the class automates iconification/uniconification, how will you handle situations when you need to do something specific and important before the operation takes place? For example, in applications that need to drop certain resources or pointers before going to iconified state: how will you go about it if the iconification/uniconification is handled automatically and internally by the class? It'd need something like an iconification hook, which would add complexity instead of making things more straightforward.

Another thing in question is handling various input sources (incl. ARexx) by the class' own HANDLEINPUT method. This would require coalescing message port event streams like Window Class does it (merging IDCMP and Workbench AppMessages), which is something Steven Solie seems to be strongly against. And I certainly don't want to implement a kludge.

But I'm all ears for any suggestions.
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
salass00
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 530
Joined: Sat Jun 18, 2011 3:12 pm
Location: Finland
Contact:

Re: Better application.library support in system components

Post by salass00 »

trixie wrote: Another thing in question is handling various input sources (incl. ARexx) by the class' own HANDLEINPUT method. This would require coalescing message port event streams like Window Class does it (merging IDCMP and Workbench AppMessages), which is something Steven Solie seems to be strongly against. And I certainly don't want to implement a kludge.
Would it really? Can't you just check the first message port first and if there are no messages there then check the other one? That's what I would do. BTW if you want to save on signals you can use the same signal for both message ports (look up IExec->AllocSysObject() and ASOT_PORT).
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 »

@salass00

Understood. I'll see what I can do.
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 wrote:@chris
could it automatically open an ARexx port as well, using BaseName?
It could, of course.
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?
I initially thought the Application Class should do various stuff like this, including automating certain common operations like iconification. However, during implementation it's becoming increasingly clear that this may not be such a good idea. For example, if the class automates iconification/uniconification, how will you handle situations when you need to do something specific and important before the operation takes place? For example, in applications that need to drop certain resources or pointers before going to iconified state: how will you go about it if the iconification/uniconification is handled automatically and internally by the class? It'd need something like an iconification hook, which would add complexity instead of making things more straightforward.

Another thing in question is handling various input sources (incl. ARexx) by the class' own HANDLEINPUT method. This would require coalescing message port event streams like Window Class does it (merging IDCMP and Workbench AppMessages), which is something Steven Solie seems to be strongly against. And I certainly don't want to implement a kludge.

But I'm all ears for any suggestions.
This is the reason why i think that the best place for application.class is between root and window class. The default commands from application and arexx could be handled by the HANDLEINPUT method. E.g. the App just gets a WMHI_ICONIFY message even if the command comes from application.library.
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
the App just gets a WMHI_ICONIFY message even if the command comes from application.library.
The problem with iconification messages is that they can be triggered on the application level (Application Library and ARexx iconification commands) as well as on the window level (WMHI_ICONIFY). This is a bit of a mess, reflecting the fact that whereas MUI was concieved as an application-centric system from the very beginning, BOOPSI has so far been developed as a window-centric system. IMHO, iconification should have never been implemented on the window level (you iconify an entire application, not a single window) but what's done is done - we have to live with it and try to find ways to get around all the shortcomings.
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 »

@salass00
if you want to save on signals you can use the same signal for both message ports (look up IExec->AllocSysObject() and ASOT_PORT).
Can I really do that with a rexx port? Looking at documentation, it appears I need to allocate the ARexx message host port using CreateRexxHostPort() from rexxsyslib.library, which does not allow me to set the signal myself like AllocSysObject() would.

Of course, CreateRexxHostPort() returns pointer to a standard Exec struct MsgPort. But would it be legal at all to tinker with the initialized port and set its mp_SigBit to the signal bit the other port uses? (Not mentioning the fact that this won't spare me a signal because CreateRexxHostPort() will already have allocated one.)
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:
if you want to save on signals you can use the same signal for both message ports (look up IExec->AllocSysObject() and ASOT_PORT).
Can I really do that with a rexx port? Looking at documentation, it appears I need to allocate the ARexx message host port using CreateRexxHostPort() from rexxsyslib.library, which does not allow me to set the signal myself like AllocSysObject() would.
It doesn't help with that, but I would strongly recommend to use arexx.class instead - it's so much easier.
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 »

If you are smoothing out rough spots with application.lbrary, I found something that seems a bit odd.

Unless my includes or autodocs are out of date, I found the following error.

The autodoc for application.library lists the tags available. One of them is not defined in libraries/application.h with the others.

from application.doc:

Code: Select all

REGAPP_Name - (STRPTR)
This tag allows you to directly specify the application name.
Mostly used if the application name shall be fixed and not
depending on the file name (as with: REGAPP_WBStartup,
REGAPP_FileLock, REGAPP_Filename)
There is no such define in my copy of include_h/libraries/application.h
where all the other tags are defined.

It MAY be obsolete, since IApplication->RegisterApplication() requires
an application name as the first argument, but I'm really not sure, because
if it can apparently get the name from WBStartup, or from a FileLock, or from
a FileName. It's hard to say whether the appName given as the first
argument of RegisterApplication is used at all... ??

In any case, the autodoc is describing a tag that is not in the header files
for application.library.

Thanks,
LyleHaze
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 »

@chris
It doesn't help with that, but I would strongly recommend to use arexx.class instead - it's so much easier.
Sadly it's not a solution in this particular case. I spent the entire last night fiddling with ARexx Class - only to find it cannot really be used here. My Application Class currently receives input events from two sources - Application Library and ARexx - and when such an event arrives, the AM_HANDLEINPUT method needs to identify the message/command and return its ID so that the programmer can react upon the particular event. In order to do that I, of course, need the message, the trouble being that with ARexx Class the messages are encapsulated. The only thing ARexx Class let's me do is call its own handleinput method, which in turn calls user-defined callback functions where the ARexx messages are processed. This of course takes place on the particular application's context whereas I need to process the messages inside the Application Class. This is why I need to create and use the ARexx port the usual way. But don't worry, I'm nearly there :-)
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
salass00
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 530
Joined: Sat Jun 18, 2011 3:12 pm
Location: Finland
Contact:

Re: Better application.library support in system components

Post by salass00 »

chris wrote:
trixie wrote:
if you want to save on signals you can use the same signal for both message ports (look up IExec->AllocSysObject() and ASOT_PORT).
Can I really do that with a rexx port? Looking at documentation, it appears I need to allocate the ARexx message host port using CreateRexxHostPort() from rexxsyslib.library, which does not allow me to set the signal myself like AllocSysObject() would.
It doesn't help with that, but I would strongly recommend to use arexx.class instead - it's so much easier.
With arexx.class you can pass on OM_NEW a message port that you have created yourself using the AREXX_MsgPort tag.
Post Reply