chris wrote:Incidentally, datatypes.library does this exact thing - if a program provides a memory pointer to create a datatypes object out of, when the datatype subclass receives it it looks exactly like a file...
I'm not 100% conversant with datatypes but looking at http://wiki.amigaos.net/index.php/Datatypes_Library
I don't think that it would work in the context we are speaking about.
Reading the web page, the subclass gets this file pointer from the major type; which is exactly what you have said in your quote.
ie. "The first step that a [sub]class has to perform in order to convert the source data, is to get a handle on the data. This is obtained by passing the DTA_Handle tag to the super-class using the OM_GET method."
"If the source Type is DTF_IFF, then DTA_Handle points to a struct IFFHandle that is already initialized and opened for reading, otherwise the handle points to a BPTR file handle."
It is only a file pointer for the purposes of writing a subclass so the subclass can read from the file of a type that it knows how to translate. The apps are still expected to deal with datatypes through objects; not this file pointer.
The datatype idea is so that an app doesn't have to recognise a file format and instead just use datatypes to create the general type of data in memory. The data must then be obtained or interacted with via an object.
So this doesn't really work as a virtual file system for our purposes.
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.
It shouldn't need to, as any object creation could create the file itself, probably on demand if it is determined that it is needed.
Let's look at the mechanism of getting dropped objects. It is by set up and message receipt.
First we: AddAppWindow(id, userdata, window, msgport, taglist)
This adds the window you specify to Workbench's list of app windows. Workbench will then send a message to 'msgport' if a workbench icon(s) is dropped into our window.
The app receives a list of WBArg structures for each icon in the message.
So to provide dropping files into legacy receiver apps, from newly written senders apps, Workbench needs to be modified in one of three ways:
1. Workbench has to move icons that are submitted from sources other than its own windows, or
2. Workbench provides access to its app window list and icon list (which is not likely), or
3. Modify WhichWorkbenchObject() to also return pointers to app windows (not sure if this is possible due to window closing issues).
With (1) Workbench could be modified to not require the app to provide the file until it has found a drop window or zone. You would probably need to pass your handleinput messages to Workbench?
With (2) control would be turned over to you so you would have to determine if the pointer is dropped over an app window. I assume some sort of locking would be necessary which may be messy.
With (3) this would be the simplest but perhaps can't be done for reasons of window unpredictability; similar to (2). Otherwise you could send your own AppMessages to these Window app message ports.
But with (1) the app would have to madly create a file when a destination were indicated so that Workbench could deliver this virtual file to the legacy receiver. This might bog down Workbench/the input process/something...
So, it would make more sense to create the virtual file before you begin moving it, or in a separate creation thread while the virtual icons are moved.
Any which way a virtual file needs to be created (unless it's an attachment as it already exists; but an image needs to be converted to a file first). At some stage the legacy receiver needs a file path(s).
If icons are being dragged and the file isn't created in time then Workbench will still probably be held up so that the app window doesn't disappear and cause an invalid message to be sent to a non-existent window.
Maybe it could be done or maybe it is just too messy.
I think it would possibly be the only simple solution to generate a virtual file(s) first and ask a modified Workbench to deliver these. ie. AppDeliverVirtualFile()
You would also need to do this either in parallel to a second process for newly written receivers or AppDeliverVirtualFile() would also have to report back if the drop is over a new style receiver that aren't app windows.
You would still have to notify the relevant translators that you are carrying something they can translate - for the new style receivers. Hmmm, sounds like a bit to do...
Again, it may be possible to actually create a class that returns a virtual file of some sort. Probably a worthwhile exercise in itself.
Also, you would probably want to bring Workbench into the game for new style receivers - so that they can receive files too - so maybe(?) these could be cross-incorporated.
chris wrote:The application could flag that a particular drag isn't suitable for legacy applications - eg. spreadsheet cells.
I still tend to think it is probably overall just easier to drag it from the source app into RAM: and then drag it from RAM: into the destination app.
We have to have some changes to the system first to even explore adding this feature for legacy receiver apps.
And sender apps have to be modified to adopt some new system for the whole point of this post to be workable.
I don't think it would be worthwhile to rewrite the existing system purely for the sake of copying files from new senders to legacy receivers.
It's only really worthwhile to write something new if you are adding something that can't presently be done by some means and that is desirable; I feel.
You're suggestion for legacy apps is certainly worthwhile in itself, but it can already presently be done; albeit by a two step process.
chris wrote:A URL dragged from one web browser hotlist should be able to be dropped into the window of a different web browser. That's something else which isn't truly "file compatible".
chris wrote:Incidentally, datatypes.library does this exact thing...
Speaking of datatypes.library it may be worthwhile supporting it as one channel for drag'n'drop.
The major problem I have with it is that you don't get any options on the final product of this solution.
A picture is presented as a complete picture to your app. What if you want to use, as an example, progressive loading?
I would tend towards a different approach. It would be a full 180° on how things seem to be presently done.
That is the app end utilises its own chosen datatypes rather than needing the overly generalised datatype ones we presently have.
I think that that will give us a lot more flexibility.