Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (msteed)

Bottom

(1) 2 3 4 ... 8 »

msteed

Re: Sam460le - new user experience

Posted on: 1/14 6:51 #1

Just popping in

Quote:

Once the snow is put back in storage the site gets a lot lighter CPU-wise

.
Now that snow season is over, opening two Amigans tabs with Odyssey shows 5 - 15% CPU use, according to CPUInfo. Tequila shows less than 5%, and almost all of that is stuff other than Odyssey.

Topic | Forum

msteed

Re: Sam460le - new user experience

Posted on: 1/11 7:19 #2

Just popping in

@nbache

Quote:

...when I then click in the displayed graph, it falls down to where it should be.

Hmm, you're right- I never noticed that before. Though it seems like CPUInfo gets less accurate when you click on it, not more.

Tequila reports that Odyssey itself uses around 40 - 45% CPU when displaying two Amigans tabs with falling snow. Add in the other tasks running, and the total CPU usage is around 45 - 55%, which is the same as what CPUInfo reports before I click on it. After clicking on the CPUInfo graph it shows the total CPU use dropping to around 5 - 15%, while Tequila shows no change.

The effect is so pronounced it's got to be intentional, but I've no idea what it's supposed to be doing (the docs that come with it say nothing about this). Whatever it is, it doesn't seem to accurately reflect total CPU use anymore. And strangely, if I open a third tab in Odyssey CPUInfo goes back to displaying the correct CPU usage, and it remains correct even if I close the third tab again.

I'm getting off topic here, so I'll just note in closing that it seems best to avoid clicking the CPUInfo docky. And indeed, the falling snow does represent a significant CPU load.

Topic | Forum

msteed

Re: Sam460le - new user experience

Posted on: 1/9 3:07 #3

Just popping in

@amiganuts

Quote:

Using Odyessy on my SAM the CPU is pegged at 98-100% constantly and on my X5040 it 70-100% constantly.

The falling snow decoration that's active around Christmas is a real CPU-sucker. I get 45 - 55% CPU use with Odyssey on my X1000 (using CPUInfo). Once the snow is put back in storage the site gets a lot lighter CPU-wise.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/14 8:05 #4

Just popping in

@kas1e

Quote:

And can't those "titles" be changed by GUI/workbench prefs by the way ?

You can change the Workbench screen title, but I don't think you can change the window titles.

Quote:

-- added check on "Amiga+e" window (AsynWB - texinput process)

Remember that AsyncWB is optional, so some users may not be using it.

Quote:

Imho we can keep filler for: 1)dbl-click 2). "Open Volumes" 3). "Open". But for 3 others like "amiga+e / wbrun" , "shell/wbrun" and "filler's open wb folder" - original WB window.

That seems reasonable to me. "Amiga+e/wbrun" and "shell/wbrun" are kind of hardcore and are likely only used by those who have a specific need for a Workbench window and who could just as easily run Filer if that's what they really wanted, and the whole point of Filer's "Workbench folder" is to open a Workbench window in addition to the Filer. The first three are more for day-to-day use and are the ones that someone who runs a utility like WB2Filer would expect to be patched.

BTW, ContextMenus also has "Execute command" and "Open a drawer" options, as well as "Open" for both disks and drawers. Some quick testing with WB2Filer_07 shows that ContextMenus (including "Execute command" with wbrun) works like double-clicking; disks get a Filer, while drawers get a Workbench window.

Just noticed: When WB2Filer is running, switching the Workbench background from a backdrop window to a regular window and then back again causes a crash (a DSI in the OpenWindowTagList() patch). Perhaps because there's no window title?

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/13 7:29 #5

Just popping in

@nbache

Quote:

is that a problem you guys haven't considered yet?

I don't think it will be a problem. We're looking for a task called "Workbench", not a window title or a disk name, so there shouldn't be any confusion.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/13 7:09 #6

Just popping in

@joerg

Quote:

That's no problem since drawers only have the drawer name as window title but disks additionally "x% full, y GB free, z GB in use".

That occurred to me as well shortly after I posted that reply. If the window title doesn't have the extra verbiage then it's a drawer, so just pass it on to Original_OpenWindowTagList() to become a Workbench window. If it does have the extra verbiage then extract the name, append a colon, and pass it to Filer. That's it. No need for the selected icon list or which_icon.

The devil is in the details though, and as you noted it won't be simple to reliably extract the name from the window title in all cases. And it's moot if Workbench doesn't use WA_Title to set the initial window title. So I guess it's over to @kas1e to test that.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/13 3:01 #7

Just popping in

@kas1e

Quote:

Btw, if we can find how Workbench checking on "if disk already opened on screen", we can then just avoid re-run of filer, and making it active instead.

I imagine Workbench has internal data that it uses to keep track of what windows it's opened, so if you try to open the same window again it just activates the existng window. We don't have access to that data, so there's no easy way for us to duplicate that functionality.

Of course, if we open a Filer instead and pass NULL back to Workbench then it thinks there is no window open for that disk, so it will try to open it again if you ask it to.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/13 2:51 #8

Just popping in

@kas1e

Quote:

So, firstly good thing: this "UserPort->mp_SigTask" for sure good one!

Yes, it looks like we can pretty reliably detect whether we want to hijack the OpenWindowTagList() call and open a Filer instead, or whether we want to let the window open normally.

The problem is still in knowing which disk we want Filer to open. We still have to assume that the window is being opened for one of the selected icons, and we know that's not always the case. What we really need is a way to know what disk or drawer Workbench is trying to open the window for, and we don't have any good way to learn that.

Some clues might come from the WA_Title tag of the window to be opened, if Workbench sets the title that way and doesn't wait until the window is already open to set the title. But even if the tag is present, the window's title has a number of obstructions to easy use:

- There's bunch of other stuff in the title besides the name
- The trailing colon is removed from the name, so we can't readily tell disks apart from drawers (someone could have a drawer named "Work")
- If it is a disk, the name is that of the volume and not the device ("RAM Disk" and not "RAM:"), and the volume name can be set to anything by the user
- The path is stripped from the name; you could have more than one drawer with the same name that differ only in the path, and we can't tell them apart

The last one wouldn't matter if we could reliably tell disks apart from drawers, since we don't want to hijack drawer windows. But it's certainly possible that someone could have a drawer named "RAM Disk" somewhere, and based on the window title we couldn't tell that apart from the actual RAM disk.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/12 7:07 #9

Just popping in

@joerg

Quote:

Additional things you could check in Scout and if it's usable add the check(s) to wb2filer:

Thanks for the ideas. The title of the Workbench backdrop window is unset, so no joy there.

However, the window's UserPort's mp_SigTask is indeed the Workbench task. So perhaps that's the way to go- if the active window's UserPort->mp_SigTask is the Workbench task (ln_Name is "Workbench") then the new Workbench window is likely being opened due to some user interaction with Workbench, and not because of some other program asking Workbench to open the window.

That doesn't solve all the problems -- we're still assuming that the window being opened is for one of the currently selected icons, and that's not always the case -- but it's one more thing that can be checked in an attempt to determine what's going on.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/12 4:29 #10

Just popping in

@kas1e

Quote:

As far as i test, and Filer and shell window both have same WFLG_WBENCHWINDOW and WFLG_BACKDROP flags.

Are you sure? When I use Scout to look at the flags for both Filer and Shell windows they both have WFLG_WORKBENCH set, but neither has WFLG_BACKDROP set.

Quote:

And btw this WFLG_BACKDROP is misleading by name : like, it's desktop's backdrop, but it's not:

True. But Workbench uses that mode for its background window, and it would be rare for any other program to open a backdrop window on the Workbench screen. So finding a window with those two flags set means it's most likely the Workbench background window.

Quote:

For me when i hit on the border of the window with opened WB drawer , it start to be active, and the selection from Workbench one unselects.

To be clear, I was saying that clicking the window border for an open drawer (not disk) window does not deselect any icons on the Workbench. The result is that the currently active window is not the Workbench background window, but there are still selected disk icons. So if you select "Open" from the menu those icons will be opened and any test that looks for the backdrop window to be the currently active one will fail.

Also, checking for WFLG_BACKDROP and checking ActiveWindow->BorderTop (or looking for WFLG_BORDERLESS) both fail if the Workbench background window is a regular window because the 'backdrop' option has been turned off. Scout reveals that the AmiDock window is borderless too, and so also has a BorderTop of zero.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/12 4:03 #11

Just popping in

@joerg
@nbache

Quote:

It is still there where it has always been.

Right you are. I was looking for a preferences setting, and completely missed the Workbench menu. Duh. Shows how much I actually use that menu.

@kas1e

Speaking of unused menus, the Workbench menu also has "Open Volume", which provides yet another way to open a Workbench window without selecting any icons.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/11 8:02 #12

Just popping in

@joerg

Quote:

Doesn't work if someone changes the workbench root window from backdrop/borderless to a normal window...

Can you still do that under OS4? I know you used to be able to under 68K OSes, but I don't seem to find a Preferences setting to do that for OS4.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/11 7:55 #13

Just popping in

@kas1e

Quote:

I have one time original WB window, all other clicks are working now. Seems resetting should be done early somehow as well. But i fear it also because of "filer run it once", and which icon counter mess a bit.

I'd have to study the code a bit to be certain, but which_icon should probably be set to zero any time that Original_OpenWindowTagList() is called.

Quote:

the only situation when it will not work, is when user will move the window exactly on the 0 and somehow keep selected some icons.

As you noted, checking the left edge of the active window will fail if the Filer window or the shell window where you're running WBRun is at the left edge of the screen. Unlikely, but possible.

Would it be sufficient to just check the active window for WFLG_WBENCHWINDOW and WFLG_BACKDROP? The Workbench backdrop window should be the only one that has both those flags set. And that's the only window where disk icons will be found.

Though as I think about it, there is a actually a way to make both those methods fail: Open a non-disk icon, which will result in a normal Workbench drawer window. Now single-click a disk icon on the backdrop window to select it and make the backdrop window the active window. Click the border of the drawer window to make it the active window instead, without deselecting the icon. Now use the Workbench "Open" menu to open the selected icon. It will open as a regular Workbench window instead of as a Filer, since the active window is neither a backdrop window nor is at the left edge of the screen.

Quote:

At least it surely better to have it as very rare corner case (and note in readme about) in compare with adding more complexity and have other bugs with.

Agreed. It's probably not possible to make it work perfectly every time no matter what; we'll always be able to come up with some unlikely but possible way to make it misbehave. If it works properly for the way that most people will use it, and doesn't crash no matter what, that's probably as good as it's going to get.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/10 4:07 #14

Just popping in

@kas1e

Quote:

Right, so that what we kind of expect then and can keep it as it, right ?

I'm not sure what we can do about it, so I guess we'll have to live with it. You'll just need to document the limitations in the ReadMe, so users understand that there will be some cases where the wrong thing happens. It's just a hack, after all.

Quote:

While not crashes anymore, it still produces a strange side effect

I noticed that with the previous version too, when I told the Grim Reaper to ignore the crash. Try resetting which_icon to zero when GetSucc() returns NULL; it may just be getting stuck at some non-zero value, which causes opening of a single icon to always fail.

Topic | Forum

msteed

Re: wb2filer v0.6

Posted on: 12/10 3:26 #15

Just popping in

@kas1e

Quote:

Now, we have only open one of the disks. While selected 2 of them, and i expected 2 of them to be opened.

That's because Filer only calls OpenWindowTagList() once*, since it's only opening a single Workbench window. If you do "Workbench folder" a second time you'll get the second disk opened. The "which_icon" method assumes that OpenWindowTagList() will be called once for each selected icon, which is true for Workbench, but not for Filer. Just one of those "assumption = always wrong some of the time" things.

* Technically, Filer doesn't call OpenWindowTagList() itself, it asks Workbench to open the window and then Workbench calls OpenWindowTagList(). But still only once, since Filer only asked it to open one window.

Topic | Forum

msteed

Re: wb2filer v0.5

Posted on: 12/8 5:05 #16

Just popping in

@balaton

Quote:

So not checking for the source of call and just supress the next beep as it does now might still work unless there's some big delay between calls.

That's what I concluded, and why I didn't press further for checking the caller.

Quote:

Or does WB return different selList each time

My assumption is that that's the case, or at least could be the case. I imagine the contents of the list (the path names) are the same each time, as long as the selected icons remain the same, but the addresses of the list nodes are likely different.

Quote:

I'm not sure this which_icon counting is fail safe

There'a always a chance the selected icons could change or increase or decrease between one call to OpenWindowTagList() and another, causing the counting to go awry. That's why you need to check the return from GetSucc() in the counting loop to make sure it's not NULL, even though you already did that the last time the patch ran. But in practice I think it's very unlikely that Workbench is going to change its mind about which icons are selected right in the middle of opening the windows. (That said, the crash bug I noted in my reply to @kas1e is an example of exactly that, though only under unusual circumstances.)

We're also assuming the order of the selected icons in the list is the same every time, so we can pick the next one in the list each time the patch is called. That seems to be the case, since the patch works.

Topic | Forum

msteed

Re: wb2filer v0.5

Posted on: 12/8 4:50 #17

Just popping in

@kas1e

Quote:

All in all "complexity" is happens only when we have just a "DISK" icons opened

True, the patch has minimal impact for anything other than Workbench windows.

Quote:

if one can spot in sources mistakes/bad style coding/logical issues/etc, please speak so

- For the comment "// a bit of error checking to avoid unexpected crashes" I'd add "if no icons are selected"

- In the loop where GetSucc() is called 'which_icon' times, you should check for it returning NULL each time and if so call Original_OpenWindowTagList(), just in case the number of selected icons changed unexpectedly.

- Any time you call Original_OpenWindowTagList() and return after obtaining the selected icon list you need to free the list first, otherwise you leak memory.

Quote:

once those who in interest can test it a little more

- Double-clicking the WB2Filer icon doesn't work, because there's no way to enter the path to Filer. Adding a tooltype to hold the path to Filer will fix that, but until then the icon should be set to run the program from the shell and not from Workbench.

- Incidentally, if you've run Filer previously the path to Filer can be as simple as APPDIR:Filer, or just Filer if APPDIR: is in your shell path. In fact, you might make that the default if no path to Filer is entered.

- The icon for WB2Filer.c has Multiviewer:Multiviewer as the default tool, so those without Enhancer installed will get an error when they double-click it.

Quote:

but so far output is quite good as i can tell : everything works in all cases

Double-click a disk icon to open a Filer window for that disk. Now shift-single-click several other disk icons to select them all. Select the Filer window, then Lister->Workbench Folder. Another Filer is opened for the first of the icons you selected, and all the icons remain selected. Select Lister->Workbench Folder again, and another Filer is opened for the second icon you selected. You can repeat this for as many icons as you selected. Only when there is a Filer for every selected icon do the icons become unselected.

This is also a place where not checking for NULL in the GetSucc() loop can cause a crash. Double click a disk icon to open a Filer. Now shift-single-click two disk icons to select them. Use Lister->Workbench Folder from Filer to open a Filer for the first of the two selected icons. which_icon is now set to 1, to process the second icon in the list next time. Now click the Workbench backdrop to deselect all the icons, then single-click to select only one icon. Use Lister->Workbench Folder again. Boom. Or at least, sometimes boom. Sometimes the patch just stops working.

Topic | Forum

msteed

Re: wb2filer v0.5

Posted on: 12/8 4:35 #18

Just popping in

@geennaam

Quote:

> There's even less information available about what Filer is doing than there is about Workbench.

Filer is open source

Sorry, I meant information available to a running program about what an open Filer window is currently doing.

Topic | Forum

msteed

Re: wb2filer v0.5

Posted on: 12/7 7:57 #19

Just popping in

@kas1e

Quote:

then, in Filer, do "Workbench Folder", and it will open Filer again : that because our icon is still selected on WB.
...
click on shell , and type "wbrun anything" -> it will open in Filer, because icon is still selected.

Yea, I anticipated that would be the next problem encountered, and was going to point it out if you hadn't discovered it. I'm not sure what we can do about it, though. I think we've about reached the limit of what a simple patch can do.

The problem is that there are two different scenarios for Workbench opening windows, one that involves opening icons that are selected, and one that doesn't. Workbench doesn't make that information available, so the patch has no way of knowing which one is in use, and has to make an assumption. Which means it's always going to be wrong part of the time.

We can try to add increasingly complex patches and hacks to try to track or deduce what Workbench is up to, but we're getting to the point of diminishing returns. And all this is running inside a call to OpenWindowTagList(), so a lot of complex manipulation is probably not a good idea.

Quote:

Filer's window is not Workbench's window sadly

There's even less information available about what Filer is doing than there is about Workbench. And unlike Workbench windows, Filer windows can be changed to point to a different location than what was originally opened, which could make tracking them even harder.

Topic | Forum

msteed

Re: wb2filer v0.5

Posted on: 12/5 2:27 #20

Just popping in

@kas1e

Quote:

But then, when i run "wbrun work:" or "wbrun system:utilities", i simple crashes

That's probably because when you use wbrun there are no selected icons, so the selected icon list is empty and GetHead() returns NULL. When you try to feed that to GetSucc() or to reference the ln->Name it of course doesn't like that. You need to add a bit of the error handling I mentioned- in this case, if GetHead() returns NULL just call Original_OpenWindowTagList().

Topic | Forum

Top

(1) 2 3 4 ... 8 »