Hyperion Entertainment Message Boards

Currently it is possible to drag icons from WB to an app (using AppWIndows, AppIcons etc), and sort-of possible to drag things from applications to WB using manual icon dragging creation and WhichWorkbenchObject(). However, it is not possible to drag directly from one application to another.

I would like to see:
* An extension to the current AppWindow/AppMessage interface so an application can send an AppMessage direct to another application, with a file attached. Implementation-wise, this might involve a temporary file unless the application being dragged to is "ExtendedAppMessage-aware".
* Visible icon dragging via an easy icon.library function on any screen - exactly the same as Workbench does it, but accessible from an application by calling a function and passing a DiskObject.
* Ideally, these two things should be tied together, so when the mouse button is released, the OS sees where the icon was dropped, passing it back to the application to then send the appropriate message (ideally through an easy SendAppMessage function - I can see a timing issue here, so if the data is ready to go and the icon dragging function can immediately pass the message, that would probably be better)
* WB itself should support AppWindows and AppMessages for drawers so files can be dragged to WB without the WhichWorkbenchObject kludge.
* This system should also be able to support clipboard text, images and other objects. I can see two ways of doing this - either (a) use a reserved clipboard unit and signal a paste or open from clipboard operation through the ExtendedAppMessage, or (b) treat this data exactly the same as a file, and let the destination application decide whether it needs to be copied directly in, or loaded like a file. I think (b) is probably better, as that is what is done currently with AppWindows.

What might be quite interesting to me would be to discuss specific examples where these would be used.
The reason being that examples then present solutions. So if you can add some examples that would be welcome.

An extension to the current AppWindow/AppMessage interface so an application can send an AppMessage direct to another application, with a file attached.

I should spend a little time familiarising myself with these. I should know what already exists and what it can and can't do.

Implementation-wise, this might involve a temporary file unless the application being dragged to is "ExtendedAppMessage-aware".

Either that or object interfacing might be better.

Visible icon dragging via an easy icon.library function on any screen - exactly the same as Workbench does it, but accessible from an application by calling a function and passing a DiskObject.

Again I think an object approach is better than a function call. It provides much greater flexibility for what is transported.
Using icon.library on "DiskObjects" is great for getting imagery. Thank you also to those people who have created wonderful images for the Amiga.

Ideally, these two things should be tied together, so when the mouse button is released, the OS sees where the icon was dropped, passing it back to the application to then send the appropriate message...

I think a better approach is to allow applications to register an interest in immigration objects that will govern certain types of data.
Then it is a simple case of a sender informing the relevant immigration objects at the commencement of movement which can in turn inform the interested receivers.
Or the receivers can also just check with the immigration objects when something is above them though I prefer for the message cast approach.
This is because I feel that one of the things lacking in OSes at the moment is a way to communicate the opportunities provided by data movement.

ideally through an easy SendAppMessage function - I can see a timing issue here, so if the data is ready to go and the icon dragging function can immediately pass the message, that would probably be better

That would involve blind delivery which is what I am looking to get away from. I want the receivers to be able to show that they are honestly interested and not just possibly.
So, no it can't be immediate in that case (as in as soon as movement begins); but it can be timely (as in by the time you get there the receiver probably already knows).
Using internal mechanisms should prevent any crashes due to orphaned deliveries.

WB itself should support AppWindows and AppMessages for drawers so files can be dragged to WB without the WhichWorkbenchObject kludge.

I'll have to examine these and see what that means. Been awhile for me.

This system should also be able to support clipboard text, images and other objects.

Absolutely. What other objects can you think of? Well, except for using the clipboard. I would prefer to not do that. It serves a specific purpose already I think.

(a) use a reserved clipboard unit and signal a paste or open from clipboard operation through the ExtendedAppMessage

The process I prefer is for the source app to utilise a mover.
It may seem a little strange but you don't want the mover preventing the source app from running. It should still be able to do other things in the meantime.
So an app processed move is less than ideal. It is best to have an independent transport system.
Signalling is at the heart of everything but you can hide this stuff internally so that it just looks as though you are posting and then forgetting about it until a receiver asks for 'translation'.
Callbacks are usually utilised for this though we need to ensure we won't get conflicts. Done right this can be the job of the objects themselves to deal with.
Even with what you suggest there would be a delay between the 'copy' and when the 'drop' is reached requiring a 'paste' to be 'signalled'.
You still need a mechanism in-between to handle the movement.

(b) treat this data exactly the same as a file, and let the destination application decide whether it needs to be copied directly in, or loaded like a file.

I have a different take on this but I'll see what I think at the time.

(b) is probably better, as that is what is done currently with AppWindows

Cool, I'll have to refresh myself on this and see how it compares again. I did know more about this stuff at one time. I'm sure it will come back to me.
I'm inclined to think I was wanting things a different way for some reason though I can't remember what that was at the moment.

gonegahgah wrote:What might be quite interesting to me would be to discuss specific examples where these would be used.
The reason being that examples then present solutions. So if you can add some examples that would be welcome.

OK, well the simplest one is an email program like YAM which shows the attachments as icons (as YAM does already). The user should be able to drag these, not only to Workbench (which works already using the WhichWorkbenchObject stuff - but as I say, WB ought to use the same functions as other applications if/when this proposal is implemented), but also direct to another program. So, you could drag an attached image straight into Pagestream, and it would place it on the page as if it had been pasted in from the clipboard (or dragged in from WB). Or you could drag an attached archive over the Unarc icon in AmiDock and AmiDock would load it as if it has come from disk.

Implementation-wise, this might involve a temporary file unless the application being dragged to is "ExtendedAppMessage-aware".

Either that or object interfacing might be better.

I'd like it to be somewhat compatible with the existing AppMessages, even if that's just a fallback. So you could drag an image from a webpage in NetSurf straight into YAM, and it would attach it like a real file (I don't know why you'd want to do that, it's just an example!) even if YAM hasn't been updated to support the new interface.

This system should also be able to support clipboard text, images and other objects.

Absolutely. What other objects can you think of?

Anything that can be stored in a file! Audio, documents, archives, ISOs, etc.

The process I prefer is for the source app to utilise a mover.
It may seem a little strange but you don't want the mover preventing the source app from running. It should still be able to do other things in the meantime.
So an app processed move is less than ideal. It is best to have an independent transport system.
Signalling is at the heart of everything but you can hide this stuff internally so that it just looks as though you are posting and then forgetting about it until a receiver asks for 'translation'.

Yes, that sounds like a good approach, and there's nothing to stop the "mover" process handling the translation itself and dumping the contents into a temporary file, if the receiver isn't "NewAppMessage-aware".

Anything that can be stored in a file! Audio, documents, archives, ISOs, etc.

All things can be stored in a file of course though file formats become an issue.
But certainly these are closely related to some of the things you may want to move around.

The user should be able to drag these, not only to Workbench ..., but also direct to another program.

Just looking at the Workbench/App commands it appears that it was written to provide communication between Workbench and apps but not from app to app.
I'm guessing It would probably need a new framework to try to add the functionality between apps but I could be wrong.
The present framework certainly doesn't provide that. It is a decided communication between a Workbench window and an application.

I'd like it to be somewhat compatible with the existing AppMessages, even if that's just a fallback.

Hmmm, there's two paths to this. One is trying to making it seamless for existing apps. The other is to make it a subsystem of a broader system used by new apps.

The first one is doubtful. The WhichWorkbenchObject() function (though I notice it's discouraged) only provides an app with a file path.
Theoretically Workbench could create a fake file path for an app window which it would then need to manage.
The trick is for the app window. It expects to be told the files it is being passed but they don't exist until the source app creates them.
So Workbench would need to add an interim step of creating the fake file path, and allowing the file(s) to be saved, and then wait for them to be dropped.
If dropped into a Workbench area they would be copied. If dropped into an app window the app would be informed and it would load from the fake.
If not dropped anywhere then they would need to be deleted.

The problem is that the apps will assume the fake path is the path's file name. Workbench would have to leave an alias of some sort hanging around to the fake file.
And opening recent or linked files later could then be a problem.

I'm not sure there is a happy solution for existing apps.

The second one might be possible. That is making it a subsystem of something else.
Though if your having to make changes to your app anyway why not just use a new approach altogether?

...YAM which shows the attachments as icons... The user should be able to drag these ... to another program.
...drag an image from a webpage in NetSurf straight into YAM...
...Audio, documents, archives, ISOs, etc...

Good! And can I add some?
Dragging addresses from an address book into a spreadsheet program or into a text document or mailing list.
Dragging gadgets from an 'Objects' panel into a form.
Dragging spreadsheet cells to another region on the same page or into a different spreadsheet window.
Dragging an animated pale of water over to the thirsty flowers in a game.
More?

...and there's nothing to stop the "mover" process handling the translation itself and dumping the contents into a temporary file...

You're right; there isn't. But, the mover may simply be the agent of transport.
The source app would tell the relevant interpreters that it is sending something they know.
The interpreters would then tell the apps that something they are interested in is being dragged about.
They can then choose to show their interest from afar, or just watch as it travels and maybe respond as it gets closer, or simply ignore it until it hovers.
If they want to be uncommunicative they can just wait until it drops. In that case it may as well be a blind delivery.
However, if they want to show interest then they need only do so if it is something they can truly use; rather than giving the user false hope.

That's how I would do it.

I do agree that a way of preserving state needs to be implemented.
If you drag a complex object from one app to another and it takes a while to move then ideally you want to let the user get back to the source app and start adding changes immediately.
But, you don't want those changes to appear in the recipient. You want the data to move as it was; not with any later changes. Causality I guess.
That's not a matter for the moving system. That is matter for the app itself. I think it should choose how it wishes to best do this.
Objects can make this easier to implement.

gonegahgah wrote:Just looking at the Workbench/App commands it appears that it was written to provide communication between Workbench and apps but not from app to app.

Nor from app to Workbench! It only exists for Workbench to app communication, and only then for real files.

And opening recent or linked files later could then be a problem.

No more so then any other temporary file, or file loaded from the RAM disk.

The second one might be possible. That is making it a subsystem of something else.
Though if your having to make changes to your app anyway why not just use a new approach altogether?

Well, you have to make changes to use the new approach for the "source" application. That's a given. The trouble is there are an awful lot of applications out there - and not forgetting new things written for OS3 which work on OS4 - that support being a "destination" for WB icon drags. These ideally shouldn't need to be updated unless the author wants to use the new functionality (rejecting files before they are dropped, etc), especially as most of the authors are no longer active or have built them for OS3 only. There are challenges but I don't think it is impossible.

...YAM which shows the attachments as icons... The user should be able to drag these ... to another program.
...drag an image from a webpage in NetSurf straight into YAM...
...Audio, documents, archives, ISOs, etc...

Good! And can I add some?
Dragging addresses from an address book into a spreadsheet program or into a text document or mailing list.
Dragging gadgets from an 'Objects' panel into a form.
Dragging spreadsheet cells to another region on the same page or into a different spreadsheet window.
Dragging an animated pale of water over to the thirsty flowers in a game.
More?

There are countless similar examples!

Some of those are internal drags in an application. These can be handled now (although handling it through the same framework as for inter-application drags would be great for both consistency and simplicity). TurboCalc supports dragging spreadsheet cells around, for example. If you handle it through the same framework then I guess the application doesn't need to know or care whether the cells came from the same spreadsheet or a different program entirely - it would just act as both the source and destination for the drag. That sort of thing would need to be catered for, as within an application a drag might be a "move" rather than a "copy", but can probably be handled with the source setting a "userdata" field and then comparing this with any destination drag userdata.

Nor from app to Workbench! It only exists for Workbench to app communication, and only then for real files.

Exactly, though WhichWorkbenchObject() is like the inverse but still app centric and again only provides a path to a drawer or file.

Though I can understand why it is discouraged.
It no doubt involves locking and searching window lists and associating them with workbench.
We can already have ClickToFront, AutoPoint, Intuition itself, and who knows what else, all locking and looking through Intuition lists.
All this locked list searching can begin to impact the input system.
It will be more efficient and less impact if this need only be done once.

No more so then any other temporary file, or file loaded from the RAM disk.

True.

These ideally shouldn't need to be updated unless the author wants to use the new functionality (rejecting files before they are dropped, etc), especially as most of the authors are no longer active or have built them for OS3 only.

It's worth thinking about... Whether it will then be possible or not I'm not sure?
Also, would it be just a solution for legacy receivers or senders with one or the other needing to use a new system?
Or, could some sort of fake path solution be created as well? A problem with this is that it forces a file to be created whether it ends up getting used or not.
Remembering also that they have expectations based upon the existing system. You can't suddenly force them to do anything differently to the way they know to do it.
Also, the applicability of this extra solution remains small in that it is purely for applications that hold files such as YAM.
Or, can you think of many other existing new combinations that would be created?

Some of those are internal drags in an application. These can be handled now...

Dragging and dropping presently has to be fully dealt with by applications themselves - maybe with some help from libraries like icon.library - but they have to go active, follow the mouse with an image maybe or change the pointer, and look at where the mouse was released.
They can only do that within the same window or they can use WhichWorkbenchObject() windows though it is discouraged.
They could also lock and look through the window list themselves for their own windows but again I could imagine this being discouraged.
So most of the drags at the moment seem to be internal and only within the same window.
This is even the case for OS3/4 MUI. It probably provides automation for the drag/drop process - with tightly tied source/destinations - but seems only able to do so within the same window.

although handling it through the same framework as for inter-application drags would be great for both consistency and simplicity

I think so too.

it would just act as both the source and destination for the drag

Yep, though if they are the same app I guess you wouldn't need any translation and could make the move/copy an internal transfer. Worth keeping in mind.
From other apps you would need a translation mechanism.

...but can probably be handled with the source setting a "userdata" field and then comparing this with any destination drag userdata.

Objects are better.

gonegahgah wrote:It's worth thinking about... Whether it will then be possible or not I'm not sure?
Also, would it be just a solution for legacy receivers or senders with one or the other needing to use a new system?

Just receivers. There are very few senders and they have to use WhichWorkbenchObject, so it isn't likely to be possible to update that function and even if it was, the impact would be low.

Or, could some sort of fake path solution be created as well? A problem with this is that it forces a file to be created whether it ends up getting used or not.

I was wondering about that, it could potentially use PIPE:, or if not a new internal handler specially for this.

Some of those are internal drags in an application. These can be handled now...

Dragging and dropping presently has to be fully dealt with by applications themselves - maybe with some help from libraries like icon.library - but they have to go active, follow the mouse with an image maybe or change the pointer, and look at where the mouse was released.[/quote]

Yes, that's a big thing which could be solved here.

They can only do that within the same window or they can use WhichWorkbenchObject() windows though it is discouraged.
They could also lock and look through the window list themselves for their own windows but again I could imagine this being discouraged.
So most of the drags at the moment seem to be internal and only within the same window.
This is even the case for OS3/4 MUI. It probably provides automation for the drag/drop process - with tightly tied source/destinations - but seems only able to do so within the same window.

Hmm, interesting. I implemented this in NetSurf for various things, and it works between windows. The easy one to test is dragging something from the hotlist or history windows into the main browser window, but you can also drag text selections between browser windows.

chris wrote:

gonegahgah wrote:So most of the drags at the moment seem to be internal and only within the same window.
This is even the case for OS3/4 MUI. It probably provides automation for the drag/drop process - with tightly tied source/destinations - but seems only able to do so within the same window.

Hmm, interesting. I implemented this in NetSurf for various things, and it works between windows. The easy one to test is dragging something from the hotlist or history windows into the main browser window, but you can also drag text selections between browser windows.

MUI does seem to provide D&D between windows. At least I know that in YAM I can drag a mail from the Inbox list to the attachment tab of a write window in order to attach the mail.

Best regards,

Niels

Two identical posts. Woohoo! I think I'll delete this one.

There are very few senders and they have to use WhichWorkbenchObject, so it isn't likely to be possible to update that function and even if it was, the impact would be low.

I agree that you could only upgrade any legacy senders by recoding WhichWorkbenchObject().
It would need to be rewritten to provide a FAKE: device and supply this to the sender immediately as though an object were found.
You would probably have to decide when you would do this as well.
If the program is asking for the WBOBJA_Name (to get the icon name) it may not be looking for somewhere to save a file too.
That is unless a drawer counts as an icon also - which it probably does - so that might not be a successful test.
Maybe it is possible to use some combination of requested data to determine what the program was doing; or maybe not?

Personally I can't think of why an app would want to know which file icon is under the pointer?
Just speculating, perhaps an example would be a little window (or docky) to show live information about an icon?
I think most sender apps would generally only be interested in the drawer (or disk/device) path?
Maybe they have to add the drawer's name to the full path if the user drops an object onto a drawer icon instead of into a drawer window? I don't know.

I don't know what existing apps try to use WhichWorkbenchObject().
You know, that might actually be interesting to know just out of curiousity? I don't know how anyone would compile such a list...

As you say, receivers are more common anyway. I wouldn't think there would be very many legacy senders?
If there is no accurate way to know if a legacy app wants just a drawer - to match our situation - then changing WhichWorkbenchObject() might create undesirable results in some app out there?
Also, if the user sees something other than the path they were expecting then they will be confused.
I know we said FAKE: is no different to RAM: but in the users mind there is a difference. Why am I getting FAKE:MyGreatPlan (or APP:) when I dropped it in my email from app XYZ?
Also, app XYZ may consider the file has been saved through this process. If you close app XYZ you may get no "Do you want to save first?" requester and lose your file.

I was wondering about that, it could potentially use PIPE:, or if not a new internal handler specially for this.

If it is only receivers you can get around creating a file.
Instead you could create a virtual file and provide all the file handling routines so the reader could read your virtual file like they would a real one.
If its easier for the app they could just create a real file so they don't have to create a vitual file system (or need one written).

Again, there may be side effects of this process even for senders.
Let's say you want to drag a picture from the web browser (rewritten to support a new drag'n'drop system) into a legacy text document that allows a picture to be dragged into place inside it.
Now it may be that the text program just saves the picture as part of its document. No problem then and the legacy text program would work without fault.
However the text app may also let you specify inclusion by link only so that the picture is separate from the rest of the document.
Now, I agree that if they are dragging the picture from the web browser then this point is moot as the user shouldn't be trying to link to a picture that is not saved.
Not really a problem but the app doesn't know not to let the user have this option. Maybe a little side-effect but still present.
There may or may not be others?

Actually, you made a point previously, which is probably not a point you intended.
Using RAM: would be the same process. So why not just leave the user to drag the file from the source app into RAM: and then drag it from RAM: into their target app.
This achieves exactly the same thing.
Sure it might be nice to somehow automate the process but a process already exists so why bother?

But still, let's think about how you would do it anyway...
Again, the changes would need to be made partly in Workbench itself.
I'm guessing that Workbench alone knows which windows are app windows?

Workbench would need to adopt any new drag'n'drop system itself, if it were to allow the extra facility we are discussing, for its app windows.
That is allowing content to be dragged from newly written apps into legacy receiver apps.
It would just treat the app windows - and app window drop zones - as generalised drop zones.
However, it could only pass on draggable content that is presented to it as file.
So for example text would have to be put into a file first, as would a picture image, or a table of data, or etc.
So again your newly written app is forced to use a virtual file system, or save the file somewhere first (perhaps RAM:?) before it attempts to drag it.

Unfortunately that creates a bit of duplication because an app has to consider that its draggable content may be taken to either a new style app or a legacy app.
So it has to both create a file and provide an object interface.
That's because there is no way to know in advance where the user is going to drag the content.

Again, I'm not sure whether app writers adopting a new system would want to have to do both? Maybe they do to support a particular legacy app?
They would really need to know why they were doing it.
Their content would in most probability not be compatible for all existing legacy receivers so it would have to be worth it.

But, there is the consideration that it would be nice to drag content - such as text from a web page - directly into a Workbench drawer and have it saved.
So, it might just be worthwhile working out a saving means as well.
You certainly don't want Workbench to have to try to work out how to save the content.
Instead it would be better for the apps or the translators or someone else to do this.
Workbench would still need to be modified a little to utilise this but Workbench shouldn't have to concern itself with file formats.

So, after all my problem raising it might be that such a thing is a (hopefully) simple by-product any way?
Interesting discussion. Still, I don't think we want limited files as the only interchange option.

Hmm, interesting. I implemented this in NetSurf for various things, and it works between windows. The easy one to test is dragging something from the hotlist or history windows into the main browser window, but you can also drag text selections between browser windows.

Well done. As I guessed correctly, and as you've now shown, it is possible for an app to set up its own drag'n'drop between its own windows.
The next ideal direction is to make this possible across apps as well.