Did the Enhancer 1.5 update yesterday, after seeing a couple comments about Mixer no longer working, I tried it out a few minutes ago..., it loads & works fine on my X1000.
So i found a bunch of issues and glitches in Notification today while writing a script to automate BackUps. I will add the (important parts of the) arexx script to the bottom that shows off all the different issues.
1) ICON image sent to oblivion? The readme says: Quote:
REGISTERAPP APP/K, AREXXPORT/K, ICON/K, TEXT/F - This command register a new application with the server
APP/K = application name (mandatory) AREXXPORT = application AREXX port to be used in case of "back" message (optional) ICON = full path to the application icon, without the ".info" appendix, to be used in the preference editor (optional) TEXT = a short message describing the application purpose
Where in the Preference Editor is this icon used? I haven't found a single icon connected to any of the (Notification) Prefs entries. Maybe i'm looking at the wrong place?
2) PERCENTAGE switch While PERCENTAGE is a cool feature it completely kills the UPDATE switch in regards of image and Notification window size changes, because once PERCENTAGE is in place the icon already used stays the same with every new UPDTAEd Notification, only the UPDATEd message text will be changed.
3) PERCENTAGE switch again Once PERCENTAGE is in place and displayed ONCE, all following UPDATEd Notification windows on the same APP are locked to the first size of the window, making every followup text be drawn underneath the PERCENTAGE bar and as thus unreadable.
4) PERCENTAGE switch once more If you have set the Prefs to replay a sound (Global Sound in the Popup settings) once a Notification message comes up, this sound will also be eaten if PERCENTAGE is in place.
So, to sum it up...if PERCENTAGE is in place ONLY the message text will be UPDATEd while all other UPDATEs will be skipped!
5) Drawing issue If you keep your mouse cursor over the "X" button of the Notification window and an UPDATEd Notification comes up, the "X" button will get cut by 1 pixel on it's bottom. Drawn over by the text field that gets updated i guess?
ADDRESS RINGHIO
'RINGHIO APP=System_BackUp UPDATE PRI=10 IMG=Tools:System/Scripts/data/BackUp.png
PERCENTAGE=10 IMGVALIGN=0 NOLOG TITLE="BackUp" Working on System: partition...'
ADDRESS COMMAND 'Wait 5'
'RINGHIO APP=System_BackUp UPDATE PRI=10 IMG=Tools:System/Scripts/data/Tools.png
PERCENTAGE=20 IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Tools: partition...'
ADDRESS COMMAND 'Wait 5'
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=5 PRI=10 IMG=Tools:System/Scripts/data/Development.png
PERCENTAGE=30 IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Development: partition...'
ADDRESS COMMAND 'Wait 5'
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=55 PRI=10 IMG=Tools:System/Scripts/data/Games.png
PERCENTAGE=60 IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Games: partition...'
ADDRESS COMMAND 'Wait 5'
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=75 PRI=10 IMG=Tools:System/Scripts/data/Storage.png
PERCENTAGE=90 IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Storage: partition...'
ADDRESS COMMAND 'Wait 5'
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=95 PRI=10 IMG=Tools:System/Scripts/data/Cache.png
PERCENTAGE=100 IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Cache: partition...'
ADDRESS COMMAND 'Wait 5'
/*
Saving stop time
*/
stop=TIME(S)
/*
Computing passed time
*/
seconds=(stop-start)/60
seconds=TRUNC(seconds,2)
time_passed=STRIP(seconds,'T','0')
time_passed=STRIP(time_passed,'T','.')
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=100 PRI=10 IMG=Tools:System/Scripts/data/BackUp.png
IMGVALIGN=0 NOLOG TITLE="BackUp" System-wide backup finished... It took 'time_passed' minute(s) to complete.'
Explanation: The first two Notification windows work like they should. The change size and icon. The third one and all following will stay at the size of the second window, not change it's icon and not change it's size with the last window having the PERCENTAGE bar overdraw the text.
edit: Update and wording
Edited by Raziel on 2019/7/7 13:18:04 Edited by Raziel on 2019/7/16 17:41:10 Edited by Raziel on 2019/7/16 17:46:34
1. There currently is no application library prefs program so that feature is "future proofing" . I say applications prefs here as you are registering the application not sending a notification.
2. to 4. Don't use PERCENTAGE and UPDATE at the same time... they are clearly incompatable.
5 don't go hovering your mouse over the close gadget
UPDATE does not update the current notification, rather it clears all existing notificatins and adds a new one, this is "clearly" described in the docs.
When PERCENTAGE is used it does actually appear to update the existing wincow, which is why the window doesn't change size. UPDATE is being ignored in this context , maybe the ARexx should throw an error if both are present not sure.
UPDATE does not update the current notification, rather it clears all existing notificatins and adds a new one
Clearly a joke from the developer then, giving a switch a name that does not imply it's purpose...why not call it CLEAR or REPLACE then?
Hopefully the BREAK paddle in my car has been given a saner name
Quote:
When PERCENTAGE is used it does actually appear to update the existing wincow, which is why the window doesn't change size
But, as i understand it, the fact that it doesn't resize or rather adapt the window size to the new text/entries completely defies the purpose of the whole "updating the window"...if the user end up with non-readable, "hidden underneath the percentage bar" text.
Plus, only the text/entries get updated, not the icon that is sent with the Notification, so it's rather a "partly update".
UPDATE does not update the current notification, rather it clears all existing notificatins and adds a new one
Clearly a joke from the developer then, giving a switch a name that does not imply it's purpose...why not call it CLEAR or REPLACE then?
I think the idea is to update the user removing previouly invalid information.
Imagine:
Updates from a new s app.
Early warning system detect missile lauch!
Global Nuclear war!
Low flying penguin triggers early warnings system nuclear forces stand dowm
The last 'update' invalidates the first two so they are removed.
Quote:
Hopefully the BREAK paddle in my car has been given a saner name
I hope so too lol.
Quote:
Quote:
When PERCENTAGE is used it does actually appear to update the existing wincow, which is why the window doesn't change size
But, as i understand it, the fact that it doesn't resize or rather adapt the window size to the new text/entries completely defies the purpose of the whole "updating the window"...if the user end up with non-readable, "hidden underneath the percentage bar" text.
One issue is that once a notification is queued it's size is somewhat fixed by it's positions in the vertical stack of notifications, yours may not be the only app issueing them.
So far as I can tell there can be only one 'percentage' notification for any given app, as there is no way to specify which notification to modify the percentage of, so it might make sense to fix the title text and image ignoring those tags for a notification with updating prgress bar.
I think the original usage concept was someting like a fixed title saying "Downloading foo" and then to display a progress of that, not to be varying the text as well. That's starting to get into therealsm where an app should handking it's own windows with dedicated code.
Quote:
Plus, only the text/entries get updated, not the icon that is sent with the Notification, so it's rather a "partly update".
I haven't worked my way through the code yet, perhaps the issue is that the text is *not* being corectly ignored whereas the image is!
And it might be that UPDATE is being handled after PERCENTAGE so the progress notificatin doesn't get closed, but the others do. (You first notifications do disappear when the percentage window starts up). Instead if UPDATE is added to args the progress wincdow should close and new one be started.
So far as I can tell there can be only one 'percentage' notification for any given app, as there is no way to specify which notification to modify the percentage of, so it might make sense to fix the title text and image ignoring those tags for a notification with updating prgress bar.
I don't know the inner workings of Notification or it's PERCENTAGE handling, but the bold quote is not true imho. You can clearly se (and test) that EVERY PERCENTAGE bar gets addressed seperately, even with it's unique percentage number
Quote:
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=5 PRI=10 IMG=Tools:System/Scripts/data/Development.png IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Development: partition...' ADDRESS COMMAND 'Wait 5'
'RINGHIO APP=System_BackUp UPDATE PERCENTAGE=55 PRI=10 IMG=Tools:System/Scripts/data/Games.png IMGVALIGN=0 NOLOG TITLE="BackUp" Working on Games: partition...' ADDRESS COMMAND 'Wait 5'
I figured it works just like the progress "bar" of AmigaOS' installer, the user has to explicitely give the percentage number to the install script to make it display that explicit number.
So, why not simply detach the PERCENTAGE bar from a given app's Notification and instead force it to be drawn (and released) completely on every Notification command/instance? That would also make the fact much more logical that the PERCENTAGE switch has to be set on every PERCENTAGE bar update (...or so i understand it's working...)
Because the PERCENTAGE switch used without any number will simply draw a PERCENTAGE bar with "0%", so there is not even some "automagically" progress thats calculated in the background. It needs to be told everything it should display. I'd say treat PERCENTAGE the same as the IMG switch, let it get updated by UPDATE and draw it completely new on every Notification event.
Also, since i believe i.e. Updater uses the new Enhancer class (i think it's called "ProgressBar.gadget") to display a "true" interactive ProgressBar inside a Notification window, the PERCENTAGE switch should probably stay what it is, a switch that has to be called everytime a Notification is sent.
Firstly could you edit you script so that the really long lines are manualy word wrapped? It'smake the forum unsuably wide to the point that is pushing the width of OWB past the compositing limit on my SAM!
Secondly I'm not sure what you mjean by
Quote:
I don't know the inner workings of Notification or it's PERCENTAGE handling, but the bold quote is not true imho. You can clearly se (and test) that EVERY PERCENTAGE bar gets addressed seperately, even with it's unique percentage number
There is only one notification width with a progress bar in the notification in your script. There *is* no way to indentify seprate prgress notifications except by using a different Appname so as I said there *is only one per application*. A script may have more than one application in if you need to (so can a binary app for that matter).
Quote:
So, why not simply detach the PERCENTAGE bar from a given app's Notification and instead force it to be drawn (and released) completely on every Notification command/instance? That would also make the fact much more logical that the PERCENTAGE switch has to be set on every PERCENTAGE bar update (...or so i understand it's working...)
And what if there is more than one application? Should YAMs email notificationjs get your percentage bar? You are not thinking straight or not saying what you mean.
Quote:
Also, since i believe i.e. Updater uses the new Enhancer class (i think it's called "ProgressBar.gadget") to display a "true" interactive ProgressBar inside a Notification window, the PERCENTAGE switch should probably stay what it is, a switch that has to be called everytime a Notification is sent.
Updater can use a notification if RinHIO is running yes, (otherwise it uses a requester which is more sensible IMHO) but it is exactly the same one you are using from your script.
PERCENTGE is not a 'switch' as such as it has varying values, but it does need to be set for each notification that pertains t the progress notification other wise you will get completely new notifications.
Firstly could you edit you script so that the really long lines are manualy word wrapped? It'smake the forum unsuably wide to the point that is pushing the width of OWB past the compositing limit on my SAM!
Yes, too bad XOOPS doesn't do that by default, or at least hide the rest of the code horizontally (like it's done vertically through sliders)
I fixed the length and added the PERCENTAGE switch back in.
Quote:
Secondly I'm not sure what you mjean by Quote:
I don't know the inner workings of Notification or it's PERCENTAGE handling, but the bold quote is not true imho. You can clearly se (and test) that EVERY PERCENTAGE bar gets addressed seperately, even with it's unique percentage number
There is only one notification width with a progress bar in the notification in your script. There *is* no way to indentify seprate prgress notifications except by using a different Appname so as I said there *is only one per application*. A script may have more than one application in if you need to (so can a binary app for that matter).
Ok, lets see if i can rephrase my thoughts.
IF i (like done in the script) open a notification for the "BackUp" app and do not add the PERCENTAGE switch, then no PERCENTAGE bar will show up (even if the PERCENTAGE bar was drawn on an earlier occasion, it will just completely vanish).
So, i do need to give the PERCENTAGE switch on every notification i send out and want it to be drawn, otherwise either 1) the bar would be drawn empty/showing 0% (PERCENTAGE used solely, without a number attached to it, i.e. PERCENTAGE=xx) or 2) the bar would not be drawn at all (by leaving out the PERCENTAGE switch completely)
As you can see in the very last notification line in the script there is no PERCENTAGE swtich and the bar is removed from that notification just fine.
Quote:
So, why not simply detach the PERCENTAGE bar from a given app's Notification and instead force it to be drawn (and released) completely on every Notification command/instance? That would also make the fact much more logical that the PERCENTAGE switch has to be set on every PERCENTAGE bar update (...or so i understand it's working...) Quote:
And what if there is more than one application? Should YAMs email notificationjs get your percentage bar? You are not thinking straight or not saying what you mean.
No, of course not. The PERCENTAGE bar should only be drawn to a notification by an app explicitely demanding it by using the PERCENTAGE=x switch. That is already how it works "generally" now. But with the drawback that it doesn't care about the UPDATE switch and as such will not be "added/updated" to a "new" notification (by i.e. obeying a changed window size due to UPDATEd longer text) but rather using the last window size and overdrawing everything that is new.
Quote:
Also, since i believe i.e. Updater uses the new Enhancer class (i think it's called "ProgressBar.gadget") to display a "true" interactive ProgressBar inside a Notification window, the PERCENTAGE switch should probably stay what it is, a switch that has to be called everytime a Notification is sent. Quote:
Updater can use a notification if RinHIO is running yes, (otherwise it uses a requester which is more sensible IMHO) but it is exactly the same one you are using from your script.
PERCENTGE is not a 'switch' as such as it has varying values, but it does need to be set for each notification that pertains t the progress notification other wise you will get completely new notifications.
Well, if i leave out the UPDATE switch i get a new notification window every time the notification is called, UPDATE otoh uses any already still open notification windows addressed to the same app.
I will add a new script which showcases the problems, maybe that will make it easier to understand what i'm trying to explain...
If you add UPDATE all previous notifications are closed, it does not update the existing one. It might look like that as you only have 1 open at atime.
If you add PERCENTAGE by itself then the first time a new notification is created, after that the existing notification with the progress bar is updated ( I think the text chnaging in this case is bug).
Where there is concept class is if you add both UPDATE and PERCENTAGE, update only removes the notificatins without percentage bar, your not seeing that as again you only have one open at atime, I think it should also close the percentage notifiction and open a new percentage notification as it would with a normal notification. This would solve the imege update and text layout issues and not mess up the layouts for other apps notifications.
I'll write a script to demo this better later, and see if I can track the offending code down later still
/*
First we open a nice and clean notification window, which will stay forever,
until closed manually.
*/
'RINGHIO APP=Test_APP PRI=10 IMG=image1 IMGVALIGN=0 NOLOG TITLE="Test_APP" This is our Test_APP...'
ADDRESS COMMAND 'Wait 5'
/*
Now we add the UPDATE switch to be able to change the icon displayed and stay with
the same ntoification window without the need of having another one opened.
*/
'RINGHIO APP=Test_APP PRI=10 IMG=image2 IMGVALIGN=0 NOLOG TITLE="Test_APP"
Image should have changed, text is longer too, the whole window grew in size. But due to the
missing UPDATE switch it will open a new notification window'
ADDRESS COMMAND 'Wait 5'
/*
Back to the clean one with short text, but this time with UPDATE and PERCENTAGE
both in place. We also try to change the displayed image back (which won't
work, due to PERCENTAGE permitting it).
*/
'RINGHIO APP=Test_APP PRI=10 PERCENTAGE=50 UPDATE IMG=image1 IMGVALIGN=0 NOLOG
TITLE="Test_APP" Back to our Test_APP...still no new image.'
ADDRESS COMMAND 'Wait 5'
/*
This will be a little demonstration of PERCENTAGE without a number attached to
it. It will draw the bar, but with "0%".
*/
/*
The PERCENTAGE bar was now in place with the last two notifications, now comes
the third and final one which will demonstrate the broken drawing if new (and
longer) text is added.
*/
'RINGHIO APP=Test_APP PRI=10 PERCENTAGE=66 UPDATE IMG=image2 IMGVALIGN=0 NOLOG
TITLE="Test_APP" If this was a really important message, one could probably not read the whole of it,
due to the PERCENTAGE "bug"...'
ADDRESS COMMAND 'Wait 5'
/*
Wrapping everything up again
*/
'RINGHIO APP=Test_APP UPDATE PRI=10 IMG=image1 IMGVALIGN=0 NOLOG
TITLE="Test_APP" ...and everythings back to "normal, icon changed and long text is
readable without being obstructed.'
EXIT 0
Thank you for taking a look.
And while i'm at it, would it be possible to add (or rather merge) a new Setting option for Notification windows?
In Preferences/Pop-up Message Preferences/Effect i'd love to have a combination of "Rounded corners" and "Drop Shadow".
"Drop Shadow" for itself only works with straight rectangular windows (which look ugly on the default WB theme, imho) and "Rounded corners" for itself look totally off due to not featuring a shadow.
I can make data types crash followed by notification server with constantly sending notifications which play a sound, without delay.
E.g. set the notification to play a sound and then create a loop that sends notification over and over (crashes with five notifications, probably less).
I'm not on my amiga anymore but will provide a test script and crash log when I'm back. Or you can test yourself...
It actually depends on the size/length of the used sound file to make it crash earlier/with fewer loops. Looks like a buffer overrun (but i'm just parroting stuff i heard before)
/*
Crashing datatypes (sound.dataype, wav.datatype) and Notification Server
Steps to reproduce:
1) Open Notifications Preferences
2) Go to tab Preferences
3) Add a default sound
i.e. System:Prefs/Presets/Clock/Sounds/Hour.wav
4) Save
5) Start the script
*/
DO WHILE z<30
'RINGHIO APP=Test_APP PRI=10 UPDATE IMG=image1 IMGVALIGN=0 NOLOG TITLE="Test_APP" Backing up' oSource' to ' Target '...'
z=z+1
END
Grim Reaper crash log
Crash log for task "NotificationServer"
Generated by GrimReaper 53.19
Crash occured in module kernel at address 0x0201A400
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
I can make it crash too, but i don't think that the datatypes are crashing, since it plays back the sound one after the other just fine. I can make it freeze when i loop it 60 times, but then the ram gets filled up in the process until it freezes because of that.
THis is not my area and I'm not sure if the sound datatype guy will reading this thread so can you write this up on the Mantis? He should see then and if not straight away at least it wont get lost.
It actually depends on the size/length of the used sound file to make it crash earlier/with fewer loops. Looks like a buffer overrun (but i'm just parroting stuff i heard before)
I wouldn't think it would be buffer overrun that would strike at random and so might crash with just one sample, unpredictably.
One possibilty is that the number of concurrent sounds excedes a certain limit and that is not being handled properly, longer samples might overlap more and thus excede that limit sooner.