Drag'n'drop between apps

AmigaOS users can make feature requests in this forum.

Re: Drag'n'drop between apps

Postby trixie » Fri Aug 30, 2013 8:30 am

@gonegahgah

So why don't we just write an rtf based datatype.

Perhaps I'm not getting you right but shouldn't we strive for a generic formatted (rich) text datatype? I.e. one of which rtf / ww / doc / whatever would be subclasses?

How will datatype store rtf in memory when the datatype loads it?

As a piece chain, for example. The entire document would be represented as an Exec list, with individual nodes containing a data structure that carries a pointer to a text buffer plus formatting flags. For instance, this following formatted text

Good luck in Syria, Mr. Obama - you'll need it boss!

would be represented by a list containing the following five nodes (pieces):

1.
Text: "Good luck in "
Flags: normal

2.
Text: "Syria"
Flags: italics

3.
Text: ", Mr. Obama - you'll "
Flags: normal

4.
Text: "need"
Flags: bold

5.
Text: " it boss!"
Flags: normal

From this list representation, an app interested in formatted text would retrieve the particular meta-information by reading the flags, whereas an app only interested in the text itself (i.e. no formatting) will be able to disregards the flags and just extract the text.

There are other methods of course.
Smoke me a kipper, I'll be back for breakfast!

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon R5 230 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
User avatar
trixie
 
Posts: 373
Joined: Thu Jun 30, 2011 3:54 pm
Location: Czech Republic

Re: Drag'n'drop between apps

Postby chris » Fri Aug 30, 2013 4:35 pm

trixie wrote:
So why don't we just write an rtf based datatype.

Perhaps I'm not getting you right but shouldn't we strive for a generic formatted (rich) text datatype? I.e. one of which rtf / ww / doc / whatever would be subclasses?


Well, that's what IFF FTXT is supposed to be.

From this list representation, an app interested in formatted text would retrieve the particular meta-information by reading the flags, whereas an app only interested in the text itself (i.e. no formatting) will be able to disregards the flags and just extract the text.


See also: viewtopic.php?f=26&t=1352&p=16225&hilit=STYL#p16225
chris
 
Posts: 551
Joined: Sat Jun 18, 2011 12:05 pm

Re: Drag'n'drop between apps

Postby gonegahgah » Fri Aug 30, 2013 5:03 pm

chris wrote:If you're loading files than the application can use its usual file loader - if it doesn't normally use DataTypes for that, it shouldn't need to here.

But, only if the file is its native format, or if the app uses its own converters - which is what we want to get away from of course, or accepts a loss of information from a general datatype.
The ideal would be to make this seamless without apps having to roll their own per file type code while minimising information loss.

chris wrote:For forms and other esoteric drags, then I agree DataTypes are probably not the right thing to use.

Cool.

chris wrote:Perhaps it could pass a BOOPSI object - such as a spreadsheet.gadget object, or a sub-class of such with only the relevant data in it?

That's kind of along the lines yes. But, not necessarily the full hog in a single gadget.
Such objects would be nice, and maybe some should be written, but then they are fairly tied to the original file type perhaps.
A spreadsheet is generally more of an app than just a gadget (it has things like settings, macros, etc.) so it leans away from just being a gui element like gadgets are.
It's more about the interfacing utilised than what an object does with the data.
User avatar
gonegahgah
 
Posts: 42
Joined: Fri May 31, 2013 5:22 pm

Re: Drag'n'drop between apps

Postby gonegahgah » Fri Aug 30, 2013 6:09 pm

@trixie

Hi trixie. I've seen some of your tutorials on Reaction. Excellent work.

trixie wrote:Perhaps I'm not getting you right but shouldn't we strive for a generic formatted (rich) text datatype? I.e. one of which rtf / ww / doc / whatever would be subclasses?

I'm thinking not so much in terms of a generic rtf datatype so much as generalising the means for providing the data.
I think the real trick is how to get the data to the app in a way that it understands and can use as much of the data as possible.
At the same time I want to give more options on how the data is delivered.

trixie wrote:As a piece chain, for example. The entire document would be represented as an Exec list, with individual nodes containing a data structure that carries a pointer to a text buffer plus formatting flags. For instance, this following formatted text

Some examples; that's what I like. You provide a wonderful example to talk about.
Here again the important thing - from a datatypes perspective - has been to construct the data in memory in such a way that the app can then read that data.
In the example you provide the app would possibly then convert this standard form to its native in-memory form.

This isn't what I want to do and this is where I talk about taking a 180° approach.
Normally we think of a program accessing a file and loading it in (or saving it out).
This is pretty much the approach the datatypes continue to follow even though they put the data in memory. My approach is to reverse that.
To give an idea you might perhaps think of the app as the 'file' and the job of the fileclass type is to send their data to our app.
We don't load the data; the data is loaded into us; but via the receiver we provide.
Then it comes down to the interfaces for doing this rather than the format.

Taking your example the fileclass type could send your app receiver a text format indicator then some text, then the next text format indicator, then some more text, etc.
But, the important thing is that it hasn't told you how to store that information and hasn't done its own interim time consuming approximation.

gonegahgah wrote:I've seen some of your tutorials on Reaction.

I'm presently just working Reaction into my early code.

Initially, long ago, I thought it was incompatible with what I had been doing, but it was nice to see that it isn't.
I see that there have been some changes to Reaction along the way but I wouldn't know if the newer changes have helped this to be?

Presently all I've done is add the text pointer subclass to the Reaction string.gadget and made the button.gadget highlight when the mouse is over them (window active or not).
Sadly, due to pointers being tied to the active window, the mouse pointer only changes when over a zone in a window that is active.
Hopefully one day the zones can be incorporated with a slightly modified Intuition to utilise a global mouse pointer (on when set; ActiveWindow's mouse when NULL) so that it works even when the window is inactive.
It's nice for the mouse to always reflect what is going to happen when you click on the gadget; even when the window is currently inactive.

I imagine that normally the app has to take more active involvement to achieve either of these two things in Reaction so I wanted to make this process much simpler.
All the Amiga OS4 prefs use Reaction so it would be nice for them to be able to add these touches without doing very much at all.

I have discovered one conundrum which I'd like to look more into (apart from the mouse pointer tied to the active window).
I was having a crash - which I've resolved now - which had to do with my disposing objects that the window object had disposed of first.
As I say, I've fixed this in my code, but it does appear to raise some considerations. It might be worth exploring this more?
User avatar
gonegahgah
 
Posts: 42
Joined: Fri May 31, 2013 5:22 pm

Re: Drag'n'drop between apps

Postby chris » Sat Sep 07, 2013 12:49 pm

Another example:
It should be possible to drag files from Find straight into applications (or over icons in AmiDock, or whatever)

This is a bit different, as it probably doesn't need to serve the file contents - just passing the existing path/filename through the old API would be sufficient. It would need to have the drag icon stuff, know where the icons have been dropped and be able to send a message to that application.
chris
 
Posts: 551
Joined: Sat Jun 18, 2011 12:05 pm

Re: Drag'n'drop between apps

Postby gonegahgah » Sun Sep 08, 2013 3:11 am

chris wrote:Another example:
It should be possible to drag files from Find straight into applications (or over icons in AmiDock, or whatever)

This is a bit different, as it probably doesn't need to serve the file contents - just passing the existing path/filename through the old API would be sufficient. It would need to have the drag icon stuff, know where the icons have been dropped and be able to send a message to that application.

Funnily, Chris, I came across this myself today. I did a search and tried to drag the listed file I was wanting into the Storm Editor.
That didn't work of course but it is something that would be nice to have.

Double clicking opens the file into MultiView which isn't what I always want. You do have the options to: put the filename to clipboard, open the drawer it's in, or bring up the information window.

It still might be nice though if the destination application knew whether it could deal with the file referred to by the filename.
Similar to what I've described it could show interest during the drag or do nothing if its not going to be able to do anything.

Talking about overall implementation, the approach I think we could most beneficially follow is to separate the drag from the actual process of recognition.
User avatar
gonegahgah
 
Posts: 42
Joined: Fri May 31, 2013 5:22 pm

Re: Drag'n'drop between apps

Postby Srtest » Mon Jan 26, 2015 11:49 pm

chris wrote:
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.


chris wrote: 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.


What important is being able to drag stuff from an archive to whatever place ala 7zip but the UnArc utility has also limted interactivity all around.
User avatar
Srtest
 
Posts: 240
Joined: Wed Jun 11, 2014 6:06 pm

Previous

Return to AmigaOS Feature Requests

Who is online

Users browsing this forum: No registered users and 5 guests