DrawerGenie for AOS4?

@geennaam
I think everything will come to the point of patching OpenWindowRagList() by creating our new one, via os4's SetMethod(). Just, need to understand how to not patch any other window, but only workbench's ones.

@sinisrus

PowerWB adds gadgets to window titlebar (and maybe menu options). just like on some porgrams add iconify gadget to intuition windows.

What it will be nice is to SetFunction/Method and add a (toolbar/speedbar) gadget/object to WB windows only (like powerWB) just below the window titlebar.

@kas1e

Hi, not sure, but maybe check WFLG_WBENCHWINDOW flag on all WB windows and ones with such flag are WB ones.

I was trying to find this topic at one night but didn't find it. I thought it was removed by somebody for some reason. :)

>"when you move the window, buttons stays not connected to the window, but leaves on the workbench screen, and after a while moved to the window"

I thought, I didn't know if it's possible to patch WB to get what we want. So I'm using timer.device. I didn't want it to use too much CPU so put the delay to 2 seconds. That makes reacting to window changes that slow. The routine checks for opened and closed WB windows. I thought it's acceptable delay. There's a notification system built into AOS but it reports screen opening closing or depth arrangement but it doesn't report window moving, so not possible to use that approach.

>"have preferences to choose what kind of buttons we want"
That's quite bunch of work to do. Didn't bother.

@kas1e
>"Instead, seems OpenWindowTagList() is used for!"
Thanks, to find out which one of the functions WB uses!

Thanks, for the SetMethod example!

@thread
Workbench offers few hooks for copying and deleting files and text inputting, which you can use for your own implementation. That's how RAWBInfo works. But WB doesn't offer hooks for anything else.

If you guys don't mind flooding the window titlebar with buttons, it's rather easy to add new titlebar buttons to windows. But I don't like that trend. I want to find free place to grab a window with the mouse.

Any this kind of a utility as a dirty hack. It would be the best if Hyperion's AmigaOS developers could improve the Workbench itself!

We can try that patching of window opening routines, if that would give better chances.

@jabirulo

Thanks, for the WFLG_WBENCHWINDOW tip!

@thread
I found and fixed a bug also.

Patching any OpenWindow routines is useless obviously. We can find struct Window memory pointers to WB windows by other means and then add more gadgets to them.

Also I noticed that when you hold the window titlebar Intuition won't refresh the display no matter how you try to update window positions.

@Jabirulo
Quote:

Yeah, tested PowerWB : on os4 it's crap, badly looking, badly centered, low colors, and no toolbar about which we talk about indeed, just a gadgets.

And yeah, what you say is what we talk about : we need tiny simple clean tasty looking aiss based toolbar right below the window titlebar, which is integrated well and fast, without strange issues, so it will feels like it real workbench (which is possible only via patching, just like in dopus5)



@TSK
Quote:

If you want to do everything fast and as best as possible in terms of integration to the OS, without having the source code of workbnech, then the only way is to do patching via SetMethod(). Dopus5 doing exactly this when running in workbenh replacement mode: it patch necessary functions of workbnech itself, as well as OpenWindowTagList() (not pure OpenWindow). And everything were clean and fast even on old classic amigas (no issues with CPU power or anything of that sort, no worry about timer divices, no strange timing issues)

Quote:

Like everyone didn't know it :) Talking obvious is pointless , because we all know the situation. But if we want to update workbench by hacks a bit, then be it. The ones who want can use it. The ones who do not want, can not use it.

Quote:

Right, and meet with the same kind of issues like timing, wrong connection to the window, different problems when themes changed and so on :)

For DrawerGenie, I had planned to use SetFunction() to detect all windows opening with the WFLG_WBENCHWINDOW and open a toolbar for each, but I couldn't get it to work properly in Blitz so I left it out. To get the patch to work, I might just write the patch itself in C and run it from the Blitz parent program to get it going.

Integrating fully into the actual fabric of the Workbench window (as opposed to window border buttons) would be a massive patch, and I've tried to avoid that wherever possible. Instead, it remembers the struct of each relevant window and polls them to check if they've moved. It's not ideal, but it works reasonably well, and while it lags the windows, it's fast enough for classic use. It also respects window border widths so as to align neatly with the border.

I haven't had the time to do any debugging on OS4 yet, but from the description I suspect it's simply a problem with the GTGZZ positioning flag that means the gadgets end up beyond the visible window borders. Odd that it happens like that, but I can detect OS4 and compensate easily.

@All
Cooking up this for now:



Patch installs fine, when i click on disk icon and open wb window, i do have on serial "OpenWindwoTagList() patched" words, no crashes after, window opens fine, but then it can't detect if it WB window or not, i just had always "Non WB window" on serial.

Can anyone spot some obvious mistake in this simple test case ?

@kas1e
Quote:Current software usually doesn't use the ancient AmigaOS 1.x struct NewWindow, incl. NewWindow->Flags, but since AmigaOS 2.0 already tags instead. NewWindow may even be NULL in OpenWindowTag(s|List)() making your code crash.
Search in the Taglist for WA_WBenchWindow, TRUE, for example using IUtility->FindTagItem(WA_WBenchWindow, Taglist).

Additionally your program should crash since it exits, is unloaded and the newFunc() code no longer exists. Add IExec->Wait(0) after IExec->Permit() to make sure it wont exit and it's code isn't unloaded.

@joerg

Offtopic: It's such a shame that you don't code for os4 anymore. You obviously know a lot about os4 and its internals.

@kas1e

Tried the same, but no idea what flags do use WB windows.

Anyway try this one (source included), little test I didi it only shows (serial output) WB windows, other program/notify are skipped:

http://jabirulo.byethost13.com/temp/testSetMethod.7z

@Javier
I see you use almost the way how Joerg suggest: utility's TagItems functions (just in your case its NextTagItem(), and Joerg suggest just FindTagItem). And i see you have tried 2 ways:
check on WA_WBenchWindow, TRUE and check on WFLG_WBENCHWINDOW, but both seems not works ? I.e. patching of OpenWindwoTagList surely works, just not detection of the WB window ?

Quote:
That only because workbench's opening of dirs use OpenWindowTagList() while most of current app do not, so, you see it only in WB windowses opening, but it just for all OpenWindowTagList().. At least i checked to uncomment both parts in your source to check on both ways, and they both show no printfs about wb windowses being detected.


@Joerg

Thanks! Modified code, but it still return "non wb window" for wb window, see:



Javier also tried to check on WFLG_WBENCHWINDOW, this also fail..

Since I never got that far, I can't be sure... But is it possible that that tag is only set *after* the window is opened?

@kas1e

yes, but did you notice that only WB windows show a (new)window pointer?
If you open other program it doesn't trigger (New)Window pointer.
So maybe there is some "way" to AddGadget to such (new)window, after last gadget of such window:




example opening WB RAM Disk:
[NEW]OpenWindowTagList(): win=0x600668d0
L= 50 T= 50
W= 481 H= 292
Flags = 0x0200107f
0x02000000 (WFLG_WBENCHWINDOW)
Gad_#01 = 0x6006691e
Gad_#02 = 0x6006694a
Gad_#03 = 0x60066976
Gad_#04 = 0x600669a2
Gad_#05 = 0x600669ce
Gad_#06 = 0x600669fa
ti_Tag = 0x8000007f -> WA_BackFill : 0x5fed9588
ti_Tag = 0x80000098 -> WA_PointerDelay : 0x00000001
ti_Tag = 0x8000006f -> WA_ScreenTitle : 0x6ff2233f
ti_Tag = 0x80000093 -> WA_NewLookMenus : 0x00000001
ti_Tag = 0x80000090 -> WA_AutoAdjust : 0x00000001
ti_Tag = 0x80000092 -> WA_MenuHelp : 0x00000001
ti_Tag = 0x800000ab -> WA_AlphaClips : 0x00000018
ti_Tag = 0x800000a6 -> WA_GrabFocus : 0x00000001


chekcing with ranger such gadgets are Bool/Prop-gadgets.

Even if you guys manage to add your own gadgets to a window, remember that any input events will then go to Workbench and not your program. You'll have to find the used msg port and read events for your gadgets from there without removing any messages because WB needs to get its messages to function correctly.

I found in my tests that even Notepad had the WFLG_WBENCHWINDOW set.

I tried to read tag list in the patched OpenWindow... but found bogus tags only.

Also if you'll do anything in your patched OpenWindow... before calling the original function, Workbench will crash eventually and at random for a reason or another. You'll have to call the original function immediately in the beginning of your function to prevent WB crashing.

@kas1e
Restore the original function pointer to Intuition before quitting your program. Otherwise Intuition will stay broken. Or was the idea that your program won't ever quit.

@jabirulo
It's interesting to see the tag list you found.

@thread
We have many features in context menus already so is this WB toolbar really that much necessary ?

@Javier
Quote:

All i have when open let's say RAM DISK is:



So far if i understand code correctly, you show all the flags which set for given window, and there are nothing about workbench..

I checked via Ranger and Sysmon, and yes, Width/Height/Left/Top is surely for Ram Disk's window, same values i have in both Ranger and Sysmon as in our output on Serial.

Through, i can't see if the Tags we got, are the same Tags of ram disk..

Do we have any system-utility which printf for us a flags/tags/etc of a given window ? (so we can compare to know what flags have said RamDisk window when opened).


As for exactly new window pointer: what you mean ? that the original pointer is different, and then we have another one ? (i just didn't see on serial values about older pointer). Or you mean that we have at all the output ? But then, it's seems that only workbench still use OpenWindowTagList(), and no other current programs which open windowses use it (that can be reason why we didn't see from other windowses such an output).

And i don't get from where you got this:



Probably you update your code a bit already ? But then, what this "0x02000000 (WFLG_WBENCHWINDOW)" mean ? That you can find this flag on WB windowses, just not via FindTags/NexTags ?


I also tried this simple test case:



And strange, but when i run your test-case patching program, and then this one, i didn't see output from serial about patched function... why ?:) Don't we patch OpenWindwoTagList() globally ? Or you add some check which prevent output from any other OpenWindowTagList() calls somehow ?

Because when i run this my test case i post above, i can see that i have patched all OpenWindowTagList() globally, and this openwindowtaglist() binary do printf on serial about too.

@TKS
Quote:
This test case is for tests, to find the Wb windowses only, nothing else for now

Quote:
Not for you seems so, but for some of us who love to see not empty workbench window, but to have the ability to _choose_ what we want and what we don't :)

Just a thought: Since the patch is presumably called in the context of whatever task/process is opening the window, could you just call FindTask(NULL) and then check the task's name to see if it's the Workbench?

Of course, Workbench opens other kinds of windows too, such as the About window and various requesters. But those don't seem to have WFLG_WBENCHWINDOW set.

Quote:
So does UnArc. And MultiView. And the AmiDock window. And some others I tried. Clearly this flag alone isn't sufficient for determining if a window belongs to the Workbench or not. But maybe the flag and also checking for the Workbench task would work.

(On the other hand, it looks like the Workbench backdrop window also has WFLG_WBENCHWINDOW set, and it presumably is opened by Workbench.)

Quote:
I had that thought too, but if others feel differently, I support their enthusiasm for figuring out another way of doing things. And if a technique for adding a file manager toolbar to a Workbench window can be worked out, the same technique might be used to add other functionality as well.

@mr2

Sorry I don’t get it, why not simply use Opus5 instead.

@kas1e

Quote:
Scout can do that.