'Docking' two windows to each other

Hi all,

I'm trying to 'dock' two windows to each other, i.e. when you move the 'master' window then the 'slave' window moves along with it.

I've done this by trapping WMHI_CHANGEWINDOW on the main window and then calling SetAttrs() for the slave window with the new position.

However, the slave window doesn't move along with the main window while dragging. Instead, when I release the main window then the slave window will follow the track that the main window took. This looks quite funny but certainly isn't right. Am I doing something wrong? Is there some better way to achieve this?

Thanks for your help.

Here's the code:

;/* WindowMoveTest
gcc -o WindowMoveTest WindowMoveTest.c -lauto
quit
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <dos/dos.h>
#include <classes/window.h>
#include <gadgets/button.h>
#include <gadgets/layout.h>

#include <proto/intuition.h>
#include <proto/exec.h>
#include <proto/window.h>
#include <proto/layout.h>
#include <proto/button.h>

enum {
WID_MASTER = 0,
WID_SLAVE,
WID_LAST
};

enum {
OID_MASTER = 0,
OID_SLAVE,
OID_LAST
};

int main() {
ULONG mxpos;
ULONG mypos;

// Make sure class files were loaded.
if ( WindowBase == NULL || LayoutBase == NULL || ButtonBase == NULL) {
return RETURN_FAIL;
}

struct Window *windows[WID_LAST];
Object *objects[OID_LAST];


objects[OID_MASTER] = IIntuition->NewObject(NULL, "window.class",
WA_ScreenTitle, "MasterWin",
WA_Title, "MasterWin",
WA_Activate, TRUE,
WA_DepthGadget, TRUE,
WA_DragBar, TRUE,
WA_CloseGadget, TRUE,
WA_SizeGadget, FALSE,
WA_Left, 100,
WA_Top, 100,
WA_Width, 200,
WA_Height, 100,
TAG_DONE);

objects[OID_SLAVE] = IIntuition->NewObject(NULL, "window.class",
WA_ScreenTitle, "SlaveWin",
WA_Title, "SlaveWin",
WA_Activate, FALSE,
WA_DepthGadget, TRUE,
WA_DragBar, TRUE,
WA_CloseGadget, FALSE,
WA_SizeGadget, FALSE,
WA_Left, 100,
WA_Top, 200,
WA_Width, 200,
WA_Height, 100,
TAG_DONE);

if (objects[OID_MASTER] != NULL && objects[OID_SLAVE] != NULL) {
// Open the windows.
windows[WID_MASTER] = (struct Window *)IIntuition->IDoMethod(objects[OID_MASTER], WM_OPEN);
windows[WID_SLAVE] = (struct Window *)IIntuition->IDoMethod(objects[OID_SLAVE], WM_OPEN);

if (windows[WID_MASTER] != NULL && windows[WID_SLAVE] != NULL) {
// Obtain the master window wait signal mask.

uint32 signal = 0;
IIntuition->GetAttr(WINDOW_SigMask, objects[OID_MASTER], &signal);

// Input Event Loop

BOOL done = FALSE;

while (!done) {
uint32 wait = IExec->Wait(signal | SIGBREAKF_CTRL_C);

if ( wait & SIGBREAKF_CTRL_C ) {
done = TRUE;
break;
}

if ( wait & signal ) {
uint32 result = WMHI_LASTMSG;
int16 code = 0;

while ((result = IIntuition->IDoMethod(objects[OID_MASTER], WM_HANDLEINPUT, &code)) != WMHI_LASTMSG) {
switch (result & WMHI_CLASSMASK) {
case WMHI_CLOSEWINDOW:
windows[WID_MASTER] = NULL;
done = TRUE;
break;

case WMHI_ICONIFY:
IIntuition->IDoMethod(objects[OID_MASTER], WM_ICONIFY);
windows[WID_MASTER] = NULL;
break;

case WMHI_UNICONIFY:
windows[WID_MASTER] = (struct Window *)IIntuition->IDoMethod(objects[OID_MASTER], WM_OPEN);
break;

case WMHI_CHANGEWINDOW:
IIntuition->GetAttrs(objects[OID_MASTER], WA_Left, &mxpos, WA_Top, &mypos, TAG_END);
IIntuition->SetAttrs(objects[OID_SLAVE], WA_Left, mxpos, WA_Top, mypos+100, TAG_END);
break;
}
}
}
}
}

/* Disposing of the window object will also close the window if it is
* already opened, and it will dispose of the layout object attached to it.
*/
IIntuition->DisposeObject(objects[OID_SLAVE]);
IIntuition->DisposeObject(objects[OID_MASTER]);
}

return RETURN_OK;
}

Apparently, WMHI_CHANGEWINDOW is only sent when the window actually "sits down" in the new position and the mouse is released. So your slave window cannot follow the master along the way, as no messages are sent during the dragging operation.

If there is another way, I don't know.

@trixie
I'm getting frequent WMHI_CHANGEWINDOW messages while moving the window, at least on my 4.1 Update 6 system.

Ah, that's a different thing then. Could be that Intuition considers your SetAttrs() on the slave window an "intensive operation" that cannot be performed in line with each received WMHI_CHANGEWINDOW message, so it postpones the actual operation until the main window change is done. But it's just guesswork, we'll need to hear from the Intuition guys.

@trixie

I think you're right, otherwise the second window wouldn't follow the exact route of the first.

There is a way to only get move messages after moving is finished, I think (or maybe it was sizing - although that was possible previously with IDCMP_SIZEVERIFY). I saw it in the new SDK whilst I was browsing through - it's an OpenWindow and/or a window.class tag.

Docs are a wonderful thing:
Quote:

This bit

Quote:

and this:
Quote:

My point being that you can never reky on a window move being instant, and that you need to check the move is complete before taking any action based on the new position.

Also intuition / input.device will act to prioritise user input (which in this case is moving the window being dragged).

You would need a specific window option to join two windows together, and I'm not aware of any such option.

Consider certain popup menus can come adrift from theier windows (hard to reproduce as most close when they lose focus) then snap back into position when the master window has finished moveing.

What are you trying to acheive, ie why do you want the child window attached to the parent?

@broadblues
Quote:
Apparently, to mimic the WinAmp behaviour, where child windows (EQ etc.) move along with the main window. (TomSoniq is the developer of AmigaAmp).

@trixie

Exactly that.
Thomas would like all Amigaamp windows to stay stuck to the parent window.

Two options:

1) Handle the dragging of the master window yourself instead of relying on Intuiton (GTYP_WDRAGGING). So MoveWindow() both child and master windows yourself.

2) Use one single window for both master and docked windows. Change the window's shape such that it looks like they were separate windows.

Ah thanks! :)

I was thinking of option #2 but I don't have the time to implement that.

However, option #1 sounds like a good idea. I'll try that.

@tomsoniq

I think you'll be wasting your time trying to implement something that is just a gimmick and not Amiga-like behaviour at all! You better implement proper Application Library support, or start working on an open plugin system so that the range of supported file formats may grow.

@Trixie
Quote:

You indeed think that moving main window, while second one wait, and then, like in cartoon repeat all the moves of main window and sticks to it is "true amiga behaviour and be it like this" ?

Imho its just looks bad, and what Tom tried to do now is pretty right and good. Not because its non-amiga, but because its just prove to be good and right on winamp when you move one window and another one moves together with it. Its just looks and feels better.

I for example will be more than happy to see it implemented, as i lately use only amigaamp, and that strange "move" annoy a bit (the same as opening of directories, which seems still not works right, but that another story)

@kas1e

Quote:
No I don't, the current implementation is silly. Amiga windows normally move one at a time, that's the normal behaviour.

I know how busy Thomas is, I know how long it takes him to implement even small features and produce an update. Therefore, it is beyond me that he should waste time trying to implement a mere gimmick when there are much more important things in the pipeline.

No need to argue :)

The skinned mode is definitely meant to be completely non-Amiga. In fact it's completely non-Windows and non-Linux as well. It's a proprietary GUI style which I tried duplicating and it was fun to do.

Actually I like this GUI. Not in general but for this particular application. I use it on Windows and Gnome Desktop, too.

The only thing I want to do regarding this matter is fix the broken window moving routine.

The coming release will properly register as an application using application.library and send out ringhio messages.

Loading whole directories will only load those files which match the file pattern you've set.

For a true Amiga-like GUI the next release will feature proper ReAction windows for main, playlist and metadata info in non-skinned mode.

But those three are a different story not to be discussed here. :)

@tomsoniq

Quote:

Oh good! Let me know should you run into any problems. The documentation I wrote for the wiki is fairly comprehensive now and should contain everything you need, but just in case.

Quote:

Cool as ice! Make sure you have a look at the AmigaAMP-Prefs source code - I use a smarter way of creating BOOPSI objects than you show here in the first post of this thread

@trixie

The first post was just a copy of the original SDK ReAction window example code. In AmigaAMP I'm using your method which I like better. :)

@tomsoniq

Glad to hear that

I'm not sure what the outcome will be from this thread but i like tomsoniq's intentions. AmigaAmp would be improved a lot if the playlist window followed the player window