I can see it now. When I extend my AmigaAMP directory window, move the Prefs icon to the far right and snapshot it (at position 900, 500), the icon after iconification is placed at that position, ie. near the middle of my WB screen. The Window Class apparently reads the position from the icon and then uses it at iconification time. This is quite likely nothing that can be controlled from within applications.
Another question is whether this is logical behaviour. The position stored with the icon is its location relative to the program drawer window. But iconification has nothing to do with the program drawer, does it? It just collapses the program into an icon on the Workbench, and it should preferably place the icon in a position where it can be easily found to de-iconify the program. I see no logic in using coordinates that refer to the icon's position within the program drawer window.
I can see it now. When I extend my AmigaAMP directory window, move the Prefs icon to the far right and snapshot it (at position 900, 500), the icon after iconification is placed at that position, ie. near the middle of my WB screen. The Window Class apparently reads the position from the icon and then uses it at iconification time.
Exactly, that's it.
Quote:
This is quite likely nothing that can be controlled from within applications.
In an ancient Bugzilla entry about making it possible to snapshot an AppIcon, I found a reference to WBAPPICONA_SupportsSnapshot, which can apparently be specified when creating it. Then the snapshot coordinates, received as an AppMessage with am_Class==AMCLASSICON_Snapshot, would need to be maintained by the application itself, either in an icon on disk or as separate coordinates in a prefs file or whatever.
I don't know whether this is actually possible and/or practical, but maybe you - with your experience - can tell whether it would make sense? (I'm just paraphrasing some of the old discussion from Bugzilla above.)
Quote:
Another question is whether this is logical behaviour. The position stored with the icon is its location relative to the program drawer window. But iconification has nothing to do with the program drawer, does it? It just collapses the program into an icon on the Workbench, and it should preferably place the icon in a position where it can be easily found to de-iconify the program. I see no logic in using coordinates that refer to the icon's position within the program drawer window.
Definitely true. I think it might just be some "quick" solution made way back when and never revisited until now. It would be nice to have a system-wide supported way of specifying/saving AppIcons' preferred positions.
In an ancient Bugzilla entry about making it possible to snapshot an AppIcon, I found a reference to WBAPPICONA_SupportsSnapshot, which can apparently be specified when creating it. Then the snapshot coordinates, received as an AppMessage with am_Class==AMCLASSICON_Snapshot, would need to be maintained by the application itself, either in an icon on disk or as separate coordinates in a prefs file or whatever.
I don't know whether this is actually possible and/or practical, but maybe you - with your experience - can tell whether it would make sense?
Well even if it did, the problem here is that WBAPPICONA_SupportsSnapshot is a tag for Workbench Library's AddAppIcon() function: in Window Class-based windows, AddAppIcon() is called internally by the class, and the programmer has no way to specify the tag.
In an ancient Bugzilla entry about making it possible to snapshot an AppIcon, I found a reference to WBAPPICONA_SupportsSnapshot, which can apparently be specified when creating it. Then the snapshot coordinates, received as an AppMessage with am_Class==AMCLASSICON_Snapshot, would need to be maintained by the application itself, either in an icon on disk or as separate coordinates in a prefs file or whatever.
I don't know whether this is actually possible and/or practical, but maybe you - with your experience - can tell whether it would make sense? (I'm just paraphrasing some of the old discussion from Bugzilla above.)
The AppIcon snapshot stuff definitely works (Wet uses it if you want an example). For iconification, I always end up not using the built-in window.class stuff for various reasons (that I can't remember), but adding an AppIcon manually and supporting snapshotting is pretty easy to do. It's also something window.class ought to be handling internally, and probably even creating a config file for - however I don't see why applications can't just set the relevant position in their WINDOW_Icon DiskObject. window.class would still need an update to support snapshot/unsnapshot and pass the values back to the application though.
Another question is whether this is logical behaviour. The position stored with the icon is its location relative to the program drawer window. But iconification has nothing to do with the program drawer, does it? It just collapses the program into an icon on the Workbench, and it should preferably place the icon in a position where it can be easily found to de-iconify the program. I see no logic in using coordinates that refer to the icon's position within the program drawer window.
That's an application bug. At the very least, the icon position should be cleared in the DiskObject structure before it is passed via WINDOW_Icon or by a direct call to AddAppIcon.
I thought it even said as much in one of the AddAppIcon AutoDocs or RKRM, but I can't find it now.
That's an application bug. At the very least, the icon position should be cleared in the DiskObject structure before it is passed via WINDOW_Icon or by a direct call to AddAppIcon.
Sorry, I have to disagree - it's a Window Class bug. The keyword here is "implementation". As the class encapsulates the appicon stuff from Workbench Library in order to provide the iconification feature, it should also be responsible for filling the provided DiskObject structure with meaningful values. Sure, the AddAppIcon() autodoc specifies how to initialize the structure but the BOOPSI programmer normally does not use the Workbench Library API at all. So I see no point in doing the WB stuff internally in the class, only to require such a thing as manually initializing a DiskObject.
This is how it should work properly:
- The programmer provides a pointer to a DiskObject structure and passes it in WINDOW_Icon. - The Window Class internally creates a copy of the structure and initializes it with values suitable for appicon use (according to the AddAppIcon() autodoc).
But yes, the current workaround is to clear the DiskObject manually, setting do_CurrentX and do_CurrentY to ICON_NO_POSITION - which I'll do in the AmigaAMP prefs right away. Thanks for the tip and explanation!
EDIT: Fixed and sent to the AmigaAMP author, with a suggestion to do the same for the main program.
So I see no point in doing the WB stuff internally in the class, only to require such a thing as manually initializing a DiskObject.
You're not manually initialising the DiskObject - you're just (re)setting the position to either (a) not snapshotted or (b) the user preference.
window.class has no need to modify the DiskObject it is passed (and neither should it be fiddling with icon parameters without being asked). People shouldn't be blaming the OS when the icon appears in exactly the place that was specified by the application!
I don't know whether this is actually possible and/or practical, but maybe you - with your experience - can tell whether it would make sense?
Well even if it did, the problem here is that WBAPPICONA_SupportsSnapshot is a tag for Workbench Library's AddAppIcon() function: in Window Class-based windows, AddAppIcon() is called internally by the class, and the programmer has no way to specify the tag.
Well, there you go - shows I was right about not knowing what I was talking about .
Of course you can get around Window Class and handle the Workbench Library stuff all yourself, but that somewhat defeats the purpose of having the class. And although it may work in this particular case, I'd generally recommend not mixing APIs: either you do the GUI in an object-oriented way, or you don't. Don't create a class-based window if you then bypass the object and use non-BOOPSI functions; the object will be unaware of the changes you make.
I can put it to BZ without recopy the same on other forums, but just need to clear text of it. Something like this maybe:
title: improve how window.class works when do icon position
body:
By logic , that how window.class should reacts when programmer want specific icon position:
- The programmer provides a pointer to a DiskObject structure and passes it in WINDOW_Icon. - The Window Class internally creates a copy of the structure and initializes it with values suitable for appicon use (according to the AddAppIcon() autodoc).
But currently it didn't works like this, and there should be done workorounds like to clear the DiskObject manually, setting do_CurrentX and do_CurrentY to ICON_NO_POSITION.
Well it's all a question of philosophy (and a topic for discussion).
My point of view is this: if the Window Class provides a dedicated tag for the icon that will be used when iconifying (WINDOW_Icon), the class should ensure that the provided DiskObject is ready for iconification purposes. If there is a requirement that icons used as appicons must have their coordinates set to ICON_NO_POSITION (as specified by the Workbench Library autodoc - see the comments for the AddAppIcon() function), the class should do the very minimum and ensure that the value is in place. The reason is consistency: I believe all programs should behave in the same way when iconified.
trixie wrote: My point of view is this: if the Window Class provides a dedicated tag for the icon that will be used when iconifying (WINDOW_Icon), the class should ensure that the provided DiskObject is ready for iconification purposes. If there is a requirement that icons used as appicons must have their coordinates set to ICON_NO_POSITION (as specified by the Workbench Library autodoc - see the comments for the AddAppIcon() function), the class should do the very minimum and ensure that the value is in place.
No, it shouldn't. That's a recommendation, not a requirement. If it is enforced then it breaks sensible software which does provide a way to specify the iconified icon location.
All that is needed is a WINDOW_IconfiedSnapshot tag, which tells window.class to enable the "snapshot" and "unsnapshot" items on the iconfied AppIcon. The values should then be passed back via a WMHI_IconSnapshot message.
Alternatively, window.class could handle all this internally, including creating snapshot icon position configuration files. That's more work, and still needs a tag to enable it, as otherwise the aforementioned software doing it (correctly) the old way will need recompiling.
Hmm, there might be a way to combine the two, so by default window.class enables the options and handles the icon position internally - and only if it has been snapshotted it will overwrite the values provided. Software that wants to handle this itself could specify the tag and get the values back, rather than window.class dealing with it. Old software that behaves sensibly will continue to work, but doing a snapshot on the iconfied application will then override anything the application normally sets (until the user subsequently "unsnapshots" the icon)
As Chris says the window.class should not override anything in the icon, except maybe via WINDOW_IconX WINDOW_IconY tag which should default to leave alone.
A method for passing on tags to the addicon function might be useful, the messages could be listened to in an AppMessageHook.
AppIcons can actually listen to messages from *all* the icon menu items though programmers rarely make use of this. (See my AnimIcon program for an example of extended use).
You're right, it does say "recommended". I also got somewhat misled by what the workbench.h include file says
/* if an icon does not really live anywhere, set its current position
** to here
*/
#define NO_ICON_POSITION (0x80000000)
because one could interpret iconification icons as having no permanent home (that's how I read it at least).
Quote:
sensible software which does provide a way to specify the iconified icon location
Let's be fair here and say that the Window Class autodoc never ever mentioned anything about specifying the icon location. Some programmers will simply not draw a line between BOOPSI windows and Workbench Library appicon features. So the misbehaving, "insensible" software is pretty much the victim of our documentation.
I am not a great fan of over-configurability in software so I'm fine with iconification putting the icon in the first free position on the screen. But I can see your point of course. I'm not enforcing anything, just taking part in discussion.
I'm not enforcing anything, just taking part in discussion.
I'm not enforcing anything either , but if the default behaviour is changed you risk breaking something which was working perfectly before - so it should be avoided. I'm sure you know that even undocumented behaviour is ripe for usage by ingenious programmers. In this case though it's not undocumented, and if it doesn't specify then the expected behaviour would be that the icon will be used "as provided" (because that's the behaviour for every other function and tag throughout the OS)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
.
