@orgin

You were fast, I was about to start a thread on this .

Edit: BTW, for those having hearing problems, smartbutton.docky is not the docky version of the fart button.

@TSK

Quote:

Yes, I'd like to add that feature, would be cool, as well as icons for window.class windows (when I resume working on winbar.docky).


@orgin

Quote:
What a bizarre idea ! No, just joking , yes this can be done but it's not as straightforward as showing it alphabetically sorted.

As for the info about the window, there used to be OwnerOfMem() function in Exec that could have provided an alternative way of obtaining the parent process (maybe...), but it no longer works in OS4.1.
So IMHO the best that can be done is showing a thumbnail of the appicon for ReAction windows.

@salass00

Er... what makes you think I don't want to do an alpha blend ?

I'd like to blend an arbitrary ARGB32 bitmap (A) over another one (B) of which I can't assume anything since it's the render destination of a docky. Here's why :

When compositing is disabled in the GUI prefs, bitmap B is an opaque background, it is simply blitted over the dock (it is a copy of the area behind the dock, that's how fake transparency is achieved in Amidock since OS4).

When compositing is enabled, bitmap B is totally transparent (colour 0 and alpha 0), it is composited over the dock.

So to handle both cases with the same rendering code, CompositeTags() would be a good candidate, but for some reason the color of bitmap B doesn't seem to be premultiplied by its alpha channel, as stated in the autodoc. So the result is e.g. the smooth borders of a png image are blended with the transparent black of bitmap B. Too bad.

@centaurz

*bump*

Hi,

Since there currently seems to be trojan issues with some browsers on Utilitybase, I'm posting my question here :

I'm having weird results when compositing an ARGB32 bitmap over a transparent one (alpha = 0x00), using the following code:

Quote:

The source bitmap RGB colors seem to be blended with the dest one, which should not happen since the alpha of the dest is 0.
Is there some missing tag here to specify that the destination bitmap alpha should be taken into account ? Or maybe the operator is wrong ?

@orgin

Not a clue about your crash, but do you know you can dump the memory console if Intuition crashes and everything is frozen. Use command DumpDebugBuffer (the buffer is resident so it survives to soft reset). All crash logs are written there.

@orgin + TSK
I mentioned the LBM_HITTEST thing because rachy's piechart.gadget has a similar method to identify the slice under the mouse pointer (maybe other Reaction classes do).

@orgin

And use IIntuition->GadgetBox() to check if you're over thelistbrowser.

Edit: As for the listbrowser node, if it isn't selected first with the LMB I doubt that you can identify it. Some kind of LBM_HITTEST method would help here.

@Orgin

BTW, you don't have to reply the Msg provided by the hook, it is handled by window.class.

@orgin

Actually, for window.class instances at least it would be possible to use tag WINDOW_Icon, but I don't know a simple way of detecting if an Intution window is an object of this class.

@orgin

Quote:
Set h_Entry to your hook function, and put whatever you need to access from within the hook function in h_Data.

Quote:
h_SubEntry is here for legacy reasons, AFAIR it used to be the glue code for the 68k C ABI. Leave it to NULL.

Quote:
Use this if you need to put the hook in a list.
Quote:
See #1.

Edit: There's an example of how to use IDCMPHook in the SDK example of the "hidden chooser".

@nubechecorre

This may interest you then
http://openamiga.org/?function=viewproject&projectid=47

(still not ready for beta though)

And there is also quickstarter from TSK on Os4depot.


Edit: It all depends on what you call a start bar. Winbar.docky is meant to manage all opened windows whilst taking as less space as possible to fit it in a dock, but you can put it in its own dock and extend its size to the screen width as well.

@orgin

If you make your Reaction window an appwindow, why don't you use the AppMsgHook feature ? The hook will be called automatically by RA_HandleInput() when an AppMsg is received, so you can use the loop code provided by Chris ?

@orgin

It's a guess based on vague memories and Autodocs reading .
(BTW, use GetProcSegList() to obtain the seglist).

Edit: However, can't find a function to change the seglist (Colin, where are you ? )

@orgin

You could "transfer" the seglist ownership to the process (use NP_SegList tag with CreateNewProc), but you still have to prevent the program from freeing it itself.

@orgin

If you get an ISI exception, the main program probably UnloadSeg()s code the spawned process is still executing.

@abalaban
I had forgotten about this hook... However, like you and Thomas said, unless the hook handle all types of files you want to generate a preview for, each hook will add some more (possibly redundant) file processing in the chain. Would be better if for example Deficons called itself some kind of previewer once the type of the file is known. But it's better than patching the system .

@abalaban

Nice idea
IMHO to avoid patching icon.library for such things, we would need a new plugin system that would allow some kind of "preview generator" to be called (according to the type detected by Deficons) instead of loading the icon imagery, possibly controlled by some tag. Maybe someone will hear us ...

@abalaban

I'm afraid not, since icon modules only deal with real .info files (the icon imagery), and therefore will never be called by icon.library to build a "fake" icon (from what I understood, never did any icon module...).

@Cyborg

No, I was commenting on the fact that the docky bitmap is interpreted differently if compositing is enabled, since the alpha channel is ignored when compositing is off (like in OS4.0 Amidock). And since GUI compositing is a user setting...

For example :

(pngImage is a bitmap.object instance)

Quote:

doesn't produce the same effect with and without compositing if drawing on an opaque background. With compositing on, the background is made transparent when it obviously shoudn't be.

Or perhaps it is an issue with DrawImage() copying the source alpha channel to the dest rastport ?