@All And i think we need to patch one more function : the one, which check if the workbench window is already opened or not.
Because as of now, we can be in this situation:
-- spawn original wb window by anything (wbrun from shell are ok), like for the RAM: -- now select on desktop RAM and second disk icon (work or whatever you have under the RAM one). -- dbl-click on any of them while both seelted.
Now, instead of opening just another disk by filer, it's instead open the same one we already opened and with keeping selected the selected icons do nothing, so i need to click another time, and then second disk opens and icons deselects.
I think issue there is that checking on the "if clicked disk already opened on screen or not" happens without involving of OpenWindowTagList(), so we just in mess a bit with our which_icon global flag : because it's 2 icons selected, but OpenWinowTagList() will be used just one time as the check on the "if window opened already" done not from OpenWindowTagList().
Have anyone an idea how to bypass this moment ?
ps. 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.
That what i have returned when dbl-click on RAM disk on Workbench Desktop:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench
That when i in the shell hit "tab" (for command competition window to spawn):
Quote:
Caller->tc_Node.ln_Name is CON/con-handler 53.82 NW is NULL
That, what i have when type in the shell "wbrun ram:":
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = WinFrame 1 Process
That what i have when run Filer from AmiDock, and do "Open in workbench folder" from it:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Background CLI
That what happens when i hit "amiga+e" for command line window to spawn in the center of screen:
Quote:
Caller->tc_Node.ln_Name is AsyncWB - textinput process NW is NULL
That what happens if i use "Open Volume" from the workbench:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench
That what we have when select an Icon and choose "Open" from workbench:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench
That what happens if i select RAM:, and in the shell type "wbrun work:" while RAM: keep selected:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = WinFrame 1 Process
So, firstly good thing: this "UserPort->mp_SigTask" for sure good one!
Then, the thing i don't understand : So far, i didn't see anywhere at all that WFLG_BACKDROP is in place. Not when i click on Desktop's icons, not when i open any Workbench window. While all workbench windows have WBENCHWINDOW, but none of them have WFLG_BACKDROP.
Maybe simple WFLG_BACKDROP is not work for OpenWindowTagList() and this is wrong to check like this, and should be used WA_Backdrop instead ? At least in the Wiki i find this:
Quote:
Backdrop windows are created by specifying the WFLG_BACKDROP flag or the WA_Backdrop tag in the OpenWindowTagList() call.
And if i use WA_Backdrop instead, then, for every opened workbench window i do have together with WBENCHWINDOW and BACKDROP printf too, but there again no differences in this terms : all windows which have WFLG_WBENCHWINDOW also have WA_Backdrop
@All Well, the check on the ActiveWindow LeftEdge + BorderTop are ok, but then, if i hit "amiga+e" and type "wbrun ram:", while "ram" selected on workbench, then it again run Filer instead of plain wb window because when we do it like this we have no window from which we run it...
Dunno if we need to do something about, or better to just wrote it to corner cases ?
And interesting issue with which_icon seems so still present : when we have opened on the workbench pure WB window for let's say "RAM:", and then multiselected RAM: and let's say WORK: and dbl-click on it, then, Workbench check that RAM: is already opened, and didn't open a Filer on (that ok), but then, it opens another disk you select also as pure WB one :)
In other words, when original WB window opened on some disk, and you tried to open that disk and some other one at the same time, then, then WB check if window already opened, and returned to the way which broke patch's logic
Yesterday i fixed the issue with black screen and also fixed the white border. I also added 3x and 4x scaling + scanlines and some more things. ... Going to do a complete backup now
Were you able to save the sources ? If not, maybe you can share the fix about white border ?:) Or if sources saved, maybe you can send latest version to Steffen ?
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.
As far as i test, and Filer and shell window both have same WFLG_WBENCHWINDOW and WFLG_BACKDROP flags. And btw this WFLG_BACKDROP is misleading by name : like, it's desktop's backdrop, but it's not:
Quote:
Backdrop Window Type Backdrop windows open behind all other non-backdrop windows, but in front of other backdrop windows that might already be open. Depth arrangement of a backdrop window affects the order of the window relative to other backdrop windows, but backdrop windows always stay behind all non-backdrop windows. No amount of depth arrangement will ever move a non-backdrop window behind a backdrop window.
The only system gadget that can be attached to a backdrop window is the closewindow gadget. Application gadgets are not restricted in backdrop windows.
Backdrop windows may often be used in place of drawing directly into the display memory of a custom screen. Such a technique is preferred, as backdrop windows are compatible with the Intuition windowing system. Using a backdrop window eliminates the danger of writing to the screen memory at a "bad" time or at the wrong position and overwriting data in a window.
To provide a full screen display area that is compatible with the windowing system, create a full sized, borderless, backdrop window with no system gadgets. Use the ShowTitle() call to hide or reveal the screen's title bar, as appropriate. See the SDK for a complete list of arguments for ShowTitle().
Backdrop windows are created by specifying the WFLG_BACKDROP flag or the WA_Backdrop tag in the OpenWindowTagList() call.
Quote:
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.
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.
But i think i find the way to reproduce what you mean, just a bit different:
-- open RAM: via "wbrun" (or from Filer) -- now, while it casual wb window, just select 2 icons on desktop : RAM one, and any other one -- dbl-click on them, and while first window will not opens (that clear, as RAM already opened) it will open in the same casual window a next disk, and not in Filer's mode.
Some more check need it seems so ?
@Joerg
Yeah, thanks! ActiveWindow->BorderTop is surely better. All active windows i test so far always have in my case BorderTop = 25, and only when Workbench Desktop window active it says 0.
But then, it also says 0 for BorderTop too, so maybe something like:
ULONG lock = IIntuition->LockIBase(0);
int BorderTop = ((struct IntuitionBase *)IntuitionBase)->ActiveWindow->BorderTop;
int LeftEdge = ((struct IntuitionBase *)IntuitionBase)->ActiveWindow->LeftEdge;
IIntuition->UnlockIBase(lock);
@All Through i am not sure about if it enough to just check LeftEdge of ActiveWindow != 0 to distinguish between main desktop and other windows , but at least 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. Probably will not happen, or so rare, that can be left as it ?
Of course, i can get the size of the workbench desktop, and compare with another Edge, but then, it will add unnecessary complexity IMHO. And actually situation when someone will select more than one icon, but not clicking on, and then running shell or filer, and specially move it to the edge 0 of desktop (while keep icons on selected), probably will be never happens. 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.
Can filer itself be made resident? There is an annoying delay the first time you open it.
On what hardware you have delay ? On all my real amigas i have no delay when run it (peg2, sam460, x1000 or x5000). Through there are a bit of micro-delay because it throws on sereal for every run that:
ListBrowserBase(HAS_NEWCOLUMNS): Test: 53.38 Has: 53.79 <- AVAILABLE
LayoutBase(HAS_NEWLAYOUT): Test: 53.0 Has: 54.10 <- AVAILABLE
BitMapBase(HAS_ALPHABITMAP): Test: 53.6 Has: 53.9 <- AVAILABLE
GraphicsBase(HAS_COMPOSITION): Test: 53.0 Has: 54.252 <- AVAILABLE
InitColors
But that happens for every run. Seems when Orgin upload latest version forget to disable debug output, but that anyway give a very little micros-pause, dunno why you have noticeable delay ..
@msteed Do some tests, and manually checked the caller of the shell and of Filer's "workbench folder", and it is the same Workbench in each case indeed. Also, all the windows (and our workbench one, and shell one, and Filer's one) are of WFLG_WBENCHWINDOW type and of not of WFLG_BACKDROP. That why check is passed even when we run from shell or filer.
So or we need to find a flag which only workbench use and no other windowss (then it will be easy right after mass selection happens and stays as it, to check if it anything than wb, and if yes, then skip it and open original window instead with return).
Or, we can go another way which i checked now : we can take AtiveWindow, and check if LeftEdge, etc are more than 0 (as WB is 0 by left Edge) then it's other windows. I checked this way now, and it works fine : even if you select icons on desktop, if you run from any other window call to OpenWindowTagList, it will open original wb window, which is what we need. And even no "unselection" happens after, which is good too.
// a bit of error checking to avoid unexpected crashes if no icons are selected.
...
But this need to think about careful, add more Edges to check, etc. Or maybe find a Flag which only desktop window have.
Alternatively, we can on the first ever run of OpenWindwoTagList(), find the first window in the whole list of windows (which is workbench one), save the address globally, and then compare each time when mass selection happens if this one is active one or not.
Edited by kas1e on 2023/12/10 13:41:03 Edited by kas1e on 2023/12/11 2:33:55
@msteed The more easy way to reproduce this issue with "open one by one", is by doing this:
1. after running the patch, just select RAM icon (just one enough). 2. open shell, and type "wbrun work:"
Instead of open the "work" in usual wb window, it will open for us Ram disk in Filer, because icon is selected :) Then it unselects automatically, and next "wbrun work:" open work in usual wb window as expected.
IMHO, we need to find a proper way to somehow dirreference between actual running of OpneWindwoTagList() even more than just WB/WBBACKDROP/etc. Maybe something about "active/non active" windows ? Like:
-- is "wb backdrop window active when we do selectlist ? -- if yes, do all as before -- if no, then it mean we tried from Filer or from Shell with wbrun, so then deselect them firstly.
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.
Almost :) At least now after this steps:
1. dbl-click icon, filer opens 2. select 2 icons on desktop, in filer hit "workbench folder" 3. close filers, deselect icons. 4. click on any icon on desktop
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.
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.
Right, so that what we kind of expect then and can keep it as it, right ?
But this one:
Quote:
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.
While not crashes anymore, it still produces a strange side effect : after this combo, every click on disk icons on workbench runs in original window mode _always_ :) like it trash something somewhere and patch stop working correctly.
I.e. i just do this:
1. dbl-click icon, filer opens 2. select 2 icons on desktop, in filer hit "workbench folder" 3. close filers, deselect icons. 4. click on any icon on desktop => always original WB window.
And the more complex you get inside a seriously critical function like OpenWindowTagList(), the worse the experience for the user.
I think you are right, need to fix remain bugs and leave it as it.
@khayoz Quote:
WB2Filer is standard in my setup now, I run it from User-Startup. Thank you! And of course big thanks to Björn Hagström for Filer!
Yeah, Filer good for sure.
@balaton, msteed
Thanks for all the suggestions/notes : deal with everything, but struggling with some issue left which i can't understand why it happens now. That what happens:
1. dbl-click on icon , filler runs. 2. select 2 icons on desktop 3. in the filer (while icons selected), hit "Workbench folder".
Now, we have only open one of the disks. While selected 2 of them, and i expected 2 of them to be opened. If i printf "which_icon" count right after SystemTagList(), then for this case i do have "which_icon = 0". Like, selection didn't happen correctly by some reasons when i hit in Filer "workbench folder". But hitting by dbl-click on those 2 selected icons, works fine, and open 2 of them.
There is just current source, check this out, maybe you will spot an obvious issue:
-- get rid of WhichWorkbenchObject() in favor of WorkbenchControl()/WBCTRLA_* usage (allow more control) -- handled correctly selecting of more than one icon at the same time. Thanks to msteed and Javier! -- added unselecting of icons after Filer is running (to gain flexibility of different Open WB windows cases) -- updated/restructured code: more error checking, more comments, more different cases handled -- added icons from Mason (yeah!) -- readme rewritten
This one is the one i want to upload on os4depot once those who in interest can test it a little more, there is:
This small hack were a bit modified and restructured, so if one can spot in sources mistakes/bad style coding/logical issues/etc, please speak so, thanks!
@msteed Quote:
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.
Thanks to Javier and his "UnSelect" idea, i implement it in a small as possible way : so when we run Filer, we unselect all selected Icons automatically by patch. Yes, it not like original WB do (original WB do keep it selected even after you click on it), but so far output is quite good as i can tell : everything works in all cases, be it WBRUN or Filer's "Open in Workbench Window", be it "Open" of workbench menu clicked when cursor over icon, or when it out of icon (from top bar), or be it simple opening of pure directories.
At least even if i hate much my own coding, i put this hack into my user-startup for now :)
Quote:
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.
Yeah, we kind of going to the way of increasing complexity of small hack-patch , and somewhere it should stop, but so far i really want to add something of that sort before giving it a rest (of course, that not mandatory, but will be nice):
-- commoditie -- tooltype support -- when open more than one Filers, need to make them to be opened not on the same position -- when dbl-click on a partition with already opened filer, instead of opening Filer again, we need to make an opened Filer to be active instead -- some qualifier which once held down together with click on disk icon, open an original WB. Yes it possible to just click, and in Filer do "Open in WB window", but just to be more complex hack :)
All in all "complexity" is happens only when we have just a "DISK" icons opened, for all the others windows i immediately return original OpenWindwoTagList code, and for Workbench ones (but not ones which DISKs) just a little check before same original return.
@all Together with the latest issue i pointed out about in previous post, i think we also need to deal with "don't run second time if already opened this device".
I think we can go WBCTRLA_GetOpenDrawerList way firstly i.e. in the patched OpenWindowTag, once we have our scanning code checking entries, run the WBCTRLA_GetOpenDrawerList before, to have a list of already opened drawers. And then compare with the list we had form scanning of selected icons, and the ones already opened can be skipped, but then, Filer's window is not Workbench's window sadly .. If only we can add some "flag" somehow to the running Filer saying that this is WB-window, then it may work ..
Edited by kas1e on 2023/12/5 12:04:43 Edited by kas1e on 2023/12/5 12:05:23 Edited by kas1e on 2023/12/5 13:13:47
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().
Right, that one works. But then, we in some situation now:
If we use new WorkbenchControl()/WBCTRLA_GetSelectedIconList way, then
-- dbl-click works -- selection of many icons works -- open from WB works does not matter where mouse cursor are
BUT! if you do:
1). select an icon 2). dbl-click on it (it run filer, all ok) 3). then, in Filer, do "Workbench Folder", and it will open Filer again : that because our icon is still selected on WB.
Or the same if you do:
1). run a shell 2). select an icon 3). dbl-click on it (so it gets selected even after Filer runs) 4). click on shell , and type "wbrun anything" -> it will open in Filer, because icon is still selected.
So, or we use WhichWorkbenchObject() + WBDISK type checking, and all works, but then "Open" from workbench will not work, once you move mouse away from the icon, because WhichWorkbenchObject() uses MouseX/MouseY position.
Or, we do use new way with WorkbenchControl()/WBCTRLA_GetSelectedIconList, but then, while icon is still selected (and after operation with it it still stays selected), wbrun and Filer's "workbench folder" didn't works as expected to open old WB window, but instead Filers.
So far it looks like that the way to deal with, is to use our new way + as Javier says made hardcore "UnSelection" after run, but then, it change the way how workbench works by default..
Dunno how else we can handle all cases ? Because or we check via MouseX/Y, then Open from WB not works when mouse is not exactly over the icon, but all other works, or we check Selection, but then it will work when we not need it as well and we need hardcore unselection after we run a Filer.
if (Caller == NULL ) {
return Original_OpenWindowTagList(Self,nw, tagList);
}
// checking if this is WB window which we need to patch
if (nw && !stricmp(Caller->tc_Node.ln_Name, "Workbench") && (nw->Flags & WFLG_WBENCHWINDOW) && !(nw->Flags & WFLG_BACKDROP))
{
struct List *selList = NULL;
But then, when i run "wbrun work:" or "wbrun system:utilities", i simple crashes. Because before, i just did this:
// we hijack only WBDISK types, so commands like "wbrun" and Filer's "Workbench Folder" works as before
if (type != WBDISK) {
return Original_OpenWindowTagList(Self,nw, tagList);
};
So i had to put this one also back. And then wbrun works too, but then again, while "multiply selected icons" handled properly now, i back to the same issue , when i select an icon on workbench, and hit "open" , and mouse cursor are a bit "out" of the icon, and it open old workbench window.
Can we somehow get the type of selected icon, without relying on the mouse cursor position (so, if icon selected, then any kind of open from any move , will check exactly selected icons on WBDISK) ?
Edited by kas1e on 2023/12/4 13:23:38 Edited by kas1e on 2023/12/4 14:00:44 Edited by kas1e on 2023/12/4 14:37:44
@Javier Nah, hardcore deselecting is kind of broken the visuals, as they keep selected even after you run them.
Need to find a way how to not handle the whole list many times in one OpenWindowTagList(), but only one time for each entry in node.
@All Anyone have an ideas how to made it in clean and better way ?:) I also think that maybe need to check, if we hit one time "dbl-click", then only do getsellist one time.. But that kind of not clean too..
Doesn't look trivial thing, 'cos WB “does” an OpenWin() call for every icon (on multiple icons start), so seems not easy to find out a solution.
Yep... We need somehow to detect that it was "selected and one time dbl-clicked", so while continue to do all the opening as before for every icon, do have some sort of flag or check which will mean "check list of selected icons one time".
Or, maybe we need to "compare" the returned list : i.e. it will be done as many times as many icons selected, so, we save first output, and then for each other compare : if it the same, then do nothing. So only first one will be taken. Of course, it will waste compare-loops, but at least better that nothing for a start..
something like (pseudo-code of course, not exactly secList to compare, maybe nodes, etc):
.
struct List *selList = NULL;
struct List *selList_prev = NULL;
if ((IWorkbench->WorkbenchControl(NULL, WBCTRLA_GetSelectedIconList, &selList, TAG_DONE)) == TRUE)
{
Now, when i click just on one icon, it return me path for one icon, one time all ok. If i select 2 icons, and click on any of them, it return me paths for 2 icons twice (!). I.e. if i choose Ram: and SFS2: partitions, i do have in output:
'RAM Disk:' 'sfs2:' 'RAM Disk:' 'sfs2:'
Same with your test case you send me, also ok when one icon, and twice when 2 icons. If i select 3 icons at once, and click on one of them , i have then repeat 3 times output. Like, depends on how many icons selected, it will the same many times print out all of them :)
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
