icon.library 46.4 test versions

[PeterK]

No sorry Carlo, but I don't want to check out any Aros x86 distros and programs.

The BoingIkonbar for OS 3.5 seems not to be available anymore and might work different (or not at all).

I don't know whether Aros x86 also has the "Status" and "Break" commands for the shell. In case that the BoingIkonbar was started from shell and would respond on Ctrl-C, Ctrl-D etc in order to quit, you could try to get the process number with the Status command first (i.e. "Status command=BiongIkonbar" or something similar), and then use this process number for the Break command, maybe something like ... (with a little luck, but not tested) ...

Break `Status command=BoingIkonbar` ALL

[AMIGASYSTEM]

Thanks Peter, meanwhile you gave me some interesting info, then if they don't work pasienza, I learned new things

The version Of BoingIconBar that I use (previously BoingIkonbar) is found in the AROS x86 ISO, and was updated years ago by the good developer Mazze Which improved BoingIconBar and added the Quit (mouse only)

Breack and Status commands exist on AROS x86, now I try to use them, more help is welcome, thanks

Have a nice day

[PeterK]

Just two examples with WBDock and NewMeter.

You have to launch the programs with Run, like "Run >NIL: BiB_Aros"

Then you can check just for info whether they appear under "Status" with a process number in the list. With "Break <process number>" you could send them a Ctrl-C to ask the program to terminate, but not every program supports this. With the option ALL the other signals are send too, usually not required.

In my example I could launch WBDock and NewMeter with Run and then I terminated them successfully again with
Break `Status Command=WBDock` ALL
Break `Status Command=NewMeter`ALL

So, in your case try out
Break `Status Command=BiB_Aros`ALL

[AMIGASYSTEM]

Tried it, I get this error message !

Scout with "Remove" can close BoingIconBar

[PeterK]

Edit: Of course, you have to launch BoingIconbar with Run, maybe from user-startup or another shell script, but not as an icon from WBStartup.

Carlo, did you try just "Status" to get the process number?
... and then use this directly in "Break <number>".

And did you also try "Break" in Scout, not "Remove"?

In my example I'm executing the `Status Command=BoingIconbar` inside of the Break argument string, and this is usually done by enclosing a command with accent grave characters ` (this is not the apostrophe! It's the french accent, which you will get holding down <shift> and pressing the accent key, an then you also need to click onto <space>, because an accent is a "dead key").

This causes that Status is executed first and its result, the process number, is inserted into the Break argument string. Your error messages says that Break didn't get this process number.

[AMIGASYSTEM]

Originally Posted by PeterK

Edit: Of course, you have to launch BoingIconbar with Run, maybe from user-startup or another shell script, but not as an icon from WBStartup.

BoingIconbar is started from the dedicated User-startup, the command I used is WBRun so that they are executed the parameters in the Tooltypes

BoingIconbar does not work with Run not accept parameters from Shell (Command Tooltypes)

Carlo, did you try just "Status" to get the process number?
... and then use this directly in "Break <number>".

No I didn't realize that "Status" was for that (I learned something else), however "Status" Command does not show "BoingIconbar" in the list of processes, If I run the "TaskList" Command instead, "BoingIconbar" is visyualized as process 0

And did you also try "Break" in Scout, not "Remove"?

Yes, but maybe I set the command wrong, what would be the right topic? Scout "Break" does not kill the process

In my example I'm executing the `Status Command=BoingIconbar` inside of the Break argument string, and this is usually done by enclosing a command with accent grave characters ` (this is not the apostrophe! It's the french accent, which you will get holding down <shift> and pressing the accent key, an then you also need to click onto <space>, because an accent is a "dead key").

Here is the only thing I didn't do wrong, I did copy/paste your command

Thanks for the help, I'll see what I can do

[PeterK]

Originally Posted by AMIGASYSTEM

the command I used is WBRun so that they are executed the parameters in the Tooltypes

BoingIconbar does not work with Run not accept parameters from Shell

It's required to start it with Run, not WBRun, because it must create a shell process. Break uses the shell process number, not the task pointer.

... however "Status" Command does not show "BoingIconbar" in the list of processes

That's because you didn't use Run from a shell or shell script.

Scout "Break" does not kill the process

Bad luck , because not every program can be terminated by sending a Ctrl-C signal, the program must support this. So Break will probably never work with BoingIconBar. Another example: I also couldn't terminate VisualPrefs with Break, but WBDock and NewMeter can be killed (see previous screenshot).

[hexaae]

HINT: about Scout, on the AmigaOS 68K don't use latest version 3.6 (or 3.5) if you care about Workbench stability, because it's seriously buggy for the NList handling with Tasks window and its sub-windows.

Use this latest stable version:


Archive: https://sourceforge.net/projects/sco...s/Scout-Amiga/
Scout 3.5+ are mainly maintenance versions with rewritten sources for multi-platform (MOS, AOS4, OS3...) compile anyway.
I've contacted Thore many times about this issue but he didn't care that much unfortunately (he uses AOS4 I guess).

[AMIGASYSTEM]

@PeterK

Unfortunately BoingIconBar does not work with Run, it has to be run from Icon to fuync well, thanks for the help

I also tried these commands with Scout but they did not work:

Usage: ActivateTask task
If task task was frozen, it will be activated, otherwise an error
occured. task is again a task’s name or an address.
‘RemoveTask’

Usage: RemoveTask task
This command removes the task task. It’s lost forever.
‘BreakTask’


@hexaae

The AROS x86 version of Scout is 37.296 Release 3.7 (GCC 6.5.0)

[PeterK]

Originally Posted by hexaae

HINT: about Scout, on the AmigaOS 68K don't use latest version 3.6 (or 3.5) if you care about Workbench stability, because it's seriously buggy for the NList handling with Tasks window and its sub-windows.

No, I can't confirm this. I'm using Scout v37.390 release 3.6 (and used 3.5 for many years before) together with MUI 3.8 and I never noticed any problems with instability, very often even running debugging tools like WinUAEenforcer in the background. But I think that I don't have the latest MUI classes installed, because as you know, you should never change a running system (muimaster.library v19.35, NList.mcc v20.122, NListtree.mcc v18.29, NListview.mcc v19.77).

I have little doubt that Thor uses OS4. No, he once said that he can't understand what the point is to have AmigaOS running on a PPC (the same as my opinion).Sorry, you meant Thore Böckelmann, not Thomas Richter (alias Thor).

[hexaae]

It's a proven bug with new NLists. Only up to 3.4 was not affected. Still not completely clear instead if it's a Scout or NList itself issue (but since I've never seen this kind of issue except with Scout 3.5+...). It's reproducible also on WinUAE with WB3.1 fresh install + MUI3.8 + NList + Scout 3.5+.
Follow the bug-repot on GitHub for the repro-steps...

[daxb]

I tried to reproduce but with the steps you provided I didn't get hits. However, while doing a lot of things with Scout I got the hits. At the moment it is random. If I remember right I seldom noticed hits in the past from Scout but always random hits. This would need more investigation.

[hexaae]

Originally Posted by daxb

I tried to reproduce but with the steps you provided I didn't get hits. However, while doing a lot of things with Scout I got the hits. At the moment it is random. If I remember right I seldom noticed hits in the past from Scout but always random hits. This would need more investigation.

It happens on opening + closing background console tasks single windows.

1. run Scout 3.5+ 68k
2. open Tasks (button), should show CPU usage "in %" at default
3. run Multiview from shell/WB Execute, in other words not by double-clicking Multiview icon but from command line...
4. find the task in the Tasks window of Scout ("Shell Process [SYS:Utilities/Multiview]") and double-click to open properties details
5. close this window and repeat 4-5 'till the Enforcer hits

As I said this has been tested even on WB3.1 fresh install and NOTHING else except MUI3.8 from Aminet + latest NList from Aminet...
It's a problem introduced since Scout 3.5 where the author rearranged sources for multi-platform compile, at least in the 68k executable. Not tested under OS4 or Aros or MorphOS...

Sources of Scout are available but I'm not a programmer unfortunately

[PeterK]

Ok, maybe I will check that Scout issue later ...

Edit: could reproduce this issue now, but won't try to fix it.

[daxb]

Originally Posted by hexaae

It happens on opening + closing background console tasks single windows.

1. run Scout 3.5+ 68k
2. open Tasks (button), should show CPU usage "in %" at default
3. run Multiview from shell/WB Execute, in other words not by double-clicking Multiview icon but from command line...
4. find the task in the Tasks window of Scout ("Shell Process [SYS:Utilities/Multiview]") and double-click to open properties details
5. close this window and repeat 4-5 'till the Enforcer hits

I know because I followed your github bugreport description. I repeated at least 10 times without a hit. The hit(s) came later while doing other stuff in between. Maybe it depends on other things like window size (list entries) or CPU refresh time.

[hexaae]

Use Scout 3.4 in the meanwhile, AFAICS Scout 3.5+ have no important changes

[PeterK]

Icon.library build #564 was removed due to a bug reported here! Please, don't use #564.

[AMIGASYSTEM]

Peter but the TC020 (build #564), does it have any restriction on AfA OS? basically after looking at an icon, your Icon.library self-destructs (deletes itself).

Now I don't know from which of your latest versions of Icon.library, still on AfA OS on old Glow Icons 3.9 I see a background, see screenshot.

I don't know maybe it is my fault that I changed something, I will investigate.

[PeterK]

Thanks for reporting, Carlo.

I've removed the update again and will check it soon. I don't know what went wrong, maybe something done by the assembler?

Use my latest Aminet version again until this bug is fixed. Sorry!

Edit: Concerning the background, this could also be caused by one of the newer rtg.libraries of P96 v3. I had strange colored backgrounds on AfA_OS with a certain rtg.library version, too.

[PeterK]

Update to icon.library build #565 (Bugfixes for TC020, FastWB, HB020, LD020 only):

Enabled the PhxAss code optimization again in #565. My library protection didn't like the #564 code modifications.

On a Hi/TrueColor Workbench the selected icons of bad disks were not displayed correctly. The "Disabled" 2. images appeared with a too small overlay bar-pattern.

On DOpus5 some very tiny ColorIcons with a height of only 1-4 pixels could cause memory trashing, although nobody usually has such small ColorIcons.