Re: [Lazarus] Generalized DragDrop
Op 2011-01-23 22:09, Hans-Peter Diettrich het geskryf: Either different applications have to agree about exchangable data formats, What's wrong with that? That is exactly what *all* DND implementation do! The Source of the DND action supplies a list of data types they support, the target goes through the list and if they don't understand any of the data types then DND (data exchange) cannot happen. Dragging selected text from Wordpad to Notepad (on my Win2000 system) is not possible (yet dragging a text file is). So clearly Notepad limits what it will accept, looking for a very specific data format, and not even supporting CF_TEXT data. or a single application needs only private types, for strictly private use. correct again. If I want to limit what data my apps or components must accept, then I'll add some application specific mime-type which only my other apps will probably support. This is pretty normal DND functionality on any platform. Saying that, most apps at least allow some form of plain text data too - as a fallback. But that is not a giving rule in DND. Se my earlier paragraph of Notepad. Every data type must be associated with a class (or component), It's not possible between applications. Why would WordPad know what a TMemo or TEdit is? So you MUST supply the data in some byte array (this depends on the platform), or simply supply the URI in case of a file(s), so the target can read that file directly if they wanted. Did you realize that URI lists are meaningful only to applications, that can handle the referenced resources - in their specific data format, that is not part of the URI. Otherwise the only use of such information is textual display of the URIs themselves, that does not require any special conversion. I'm not sure I understand the point your are trying to make. I can say that 'text/uri-list' could simply be a fallback data type. Normally the source of DND has a list of data formats, and normally they are in most specific to least specific order. Take Gnome's Nautilus (file manager) as an example. It supplies 8 data formats when dragging files. The first being something I guess only Gnome applications will understand. Then the format list becomes less and less specific, 'text/uri-list' being the second choice of data types. See attached screenshot. Okay, Firefox works - but why then do you not simply show the CF_TEXT or CF_UNICODETEXT format? It does. See the 'firefox_dnd.png' attachment. And as you can see, it is also not the preferred format for Firefox, as CF_TEXT is listed number 6 only. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ attachment: nautilus_dnd.pngattachment: firefox_dnd.png-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Sun, 23 Jan 2011, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. Simply start the demo app twice, then drag... I was thinking about something non-trivial, of course. Please specify what non-trivial use you have in mind, and what results you expect to see in this very early implementation stage (proof of concetpt). Drop a piece of text from wordpad on a TMemo. The text should be inserted at the drop point. I'd leave all that to the concrete implementations, and provide specialized handlers in the target controls. Currently TControl.DoDragMsg dispatches the messages to the Drop and Dock methods, based on the DragObject class type. More handlers can be added, and dispatch may be rebased on a drag type (enum) property. I don't think more handlers should be added. There are too many handlers already. That is why you can put the extra information in objects which descend from TDragObject. Not only information, but also functionality! That is what it is for, and it is also the recommended practice in Delphi: creating a descendant of TDragObject for specific purposes. Right, and every such Delphi class reacts on dragging events, in its ProcessMessages method. The base class (TDragObject) only must declare the extended API, including common properties. No, that is IMHO a totally wrong design, which will make the base object unnecessarily heavy. This is exactly the reason why the API allows you to create your custom drag object when a drag operation starts: to avoid putting everything in the base object. You miss the really essential point: the interface between the drag manager and the drag object. I am not missing anything, I am just saying that putting everyting in the base drag object is not a good decision. I'm not interested in the implementation details such as dragperformer and whatnot. I'm interested in how the end-user (the application programmer) sees DnD. Namely: he can re-use his existing knowledge, there are simply some extra descendants of TDragObject that implement external file DND and Inter-application DND, all the rest goes through the same events/methods that exist now. How this is accomplished in the background is not so relevant to me; I'm sure that the people involved will solve it in any way they see fit. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Op 2011-01-24 10:32, michael.vancann...@wisa.be het geskryf: Drop a piece of text from wordpad on a TMemo. The text should be inserted at the drop point. From the discussion, I assume you are still referring to fpGUI functionality (or the lack thereof). This is all on my todo list. As I mentioned, I had to implement the basic workings of DND in a cross-platform way in very short time (a rather tough task in it's own). The full DND integration [as you described] with the remainder of fpGUI widgets will follow soon. It's all about time management. ;-) Further, I fully agree with the rest of your comments. From the end-user (developer) point of view, DND functionality should be as easy as possible, and with a consistent interface across all supported platforms. No IFDEF's or OS API calls should be required from the end-user/developer. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Mon, 24 Jan 2011, Graeme Geldenhuys wrote: Op 2011-01-24 10:32, michael.vancann...@wisa.be het geskryf: Drop a piece of text from wordpad on a TMemo. The text should be inserted at the drop point. From the discussion, I assume you are still referring to fpGUI functionality (or the lack thereof). This is all on my todo list. As I mentioned, I had to implement the basic workings of DND in a cross-platform way in very short time (a rather tough task in it's own). The full DND integration [as you described] with the remainder of fpGUI widgets will follow soon. It's all about time management. ;-) I didn't intend a comment on fpGUI. I just wanted to give an example of what I consider non-trivial DND. Whether or not the widgetset should behave like this by default is another matter - both in the LCL or fpGUI. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Graeme Geldenhuys schrieb: whether the fpGUI approach may be added to the LCL as well, or what should work differently there. I'm afraid you will probably get the response that it's not Delphi compatible. ;) Of course your approach is not yet Delphi compatible, but it *can* be merged perfectly into the Delphi dragging model. The DragObjects receive (somehow) the mouse moves etc., and invoke the event handlers in the involved controls, or in the DockManager. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Graeme Geldenhuys schrieb: Op 2011-01-23 22:09, Hans-Peter Diettrich het geskryf: Either different applications have to agree about exchangable data formats, What's wrong with that? That is exactly what *all* DND implementation do! The Source of the DND action supplies a list of data types they support, the target goes through the list and if they don't understand any of the data types then DND (data exchange) cannot happen. The Delphi dragging model is strictly internal, independent from global conventions. Dragging selected text from Wordpad to Notepad (on my Win2000 system) is not possible (yet dragging a text file is). So clearly Notepad limits what it will accept, looking for a very specific data format, and not even supporting CF_TEXT data. We should make *something* work first, then look into special cases. The reaction of applications is widely application specific, and implies no rule how other applications should handle various kinds of dropped items. or a single application needs only private types, for strictly private use. correct again. If I want to limit what data my apps or components must accept, then I'll add some application specific mime-type which only my other apps will probably support. This is pretty normal DND functionality on any platform. It depends on the control type *and* its role in an application, what it should accept. An editor control can accept all kinds of text, and possibly graphics, while a file list will only accept file references. It's up to the control's drag handlers to check the dragged item(s), and to react accordingly. Saying that, most apps at least allow some form of plain text data too - as a fallback. But that is not a giving rule in DND. Se my earlier paragraph of Notepad. Plain text is a standard case, that should be supported by the component library. But no control is obliged to accept text at all. Every data type must be associated with a class (or component), It's not possible between applications. Why would WordPad know what a TMemo or TEdit is? So you MUST supply the data in some byte array (this depends on the platform), or simply supply the URI in case of a file(s), so the target can read that file directly if they wanted. I didn't mention specific control types, but only classes that implement support for specific data formats, like HTML, XML, JPEG... Did you realize that URI lists are meaningful only to applications, that can handle the referenced resources - in their specific data format, that is not part of the URI. Otherwise the only use of such information is textual display of the URIs themselves, that does not require any special conversion. I'm not sure I understand the point your are trying to make. I can say that 'text/uri-list' could simply be a fallback data type. Normally the source of DND has a list of data formats, and normally they are in most specific to least specific order. Take Gnome's Nautilus (file manager) as an example. It supplies 8 data formats when dragging files. The first being something I guess only Gnome applications will understand. Then the format list becomes less and less specific, 'text/uri-list' being the second choice of data types. It's up to the drop target to select whatever data format is appropriate for its operation, in a specific application. See attached screenshot. Okay, Firefox works - but why then do you not simply show the CF_TEXT or CF_UNICODETEXT format? It does. See the 'firefox_dnd.png' attachment. And as you can see, it is also not the preferred format for Firefox, as CF_TEXT is listed number 6 only. The preferences of Firefox are quite unimportant to a target in a different application. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
michael.vancann...@wisa.be schrieb: I was thinking about something non-trivial, of course. Please specify what non-trivial use you have in mind, and what results you expect to see in this very early implementation stage (proof of concetpt). Drop a piece of text from wordpad on a TMemo. The text should be inserted at the drop point. You know that a TMemo is a platform specific control, with accordingly platform specific behaviour? If you want the described behaviour implemented in code, a label or panel could be used as well. If you want a TMemo or other standard widget react as designed, then okay, this should be made work in the LCL. You miss the really essential point: the interface between the drag manager and the drag object. I am not missing anything, I am just saying that putting everyting in the base drag object is not a good decision. I'm not interested in the implementation details such as dragperformer and whatnot. Me2 ;-) I only wanted to point out that the *current* LCL implementation is not the best one, and that putting the current performer code into the basic drag object types will allow to add any kind of drag sources (e.g. external ones). We already have dedicated DragObject classes for local drag-drop and drag-dock, and inter-application dragging can be handled in another class. I'm interested in how the end-user (the application programmer) sees DnD. Namely: he can re-use his existing knowledge, there are simply some extra descendants of TDragObject that implement external file DND and Inter-application DND, all the rest goes through the same events/methods that exist now. The DragObjects will invoke the appropriate methods of the involved controls, e.g. DragOver and DragDrop for a drop source, and DockOver and DockDrop for a dock source. How this is accomplished in the background is not so relevant to me; I'm sure that the people involved will solve it in any way they see fit. Yes, of course, and that's why we currently discuss how to extend dragging in the best (transparent) way. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
waldo kitty schrieb: i'm late to the party (again) but reading this, i had these questions... 1. what GUI environments are there that do not have clipboards? Dunno. Most will have such a feature, but the implementation can vary. 2. are there any that do /not/ use the clipboard for DnD operations? The clipboard should not be affected by DnD at all. It's only the mechanism, how data formats are managed by the clipboard, that suggests to use the same model to describe and handle DnD data as well. 3. is #2 is yes, what do they use and how? DnD uses data containers, which may be accessed like the clipboard (same API). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On 23 January 2011 02:21, Hans-Peter Diettrich DrDiettrich1@ wrote: On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. I think that Graeme can answer this question... I use OLE under Windows and translate mime-types to Windows CF_xxx clipboard format. If it's a fpGUI app to fpGUI app, you can simply use the mime-types. Under Linux I use the XDND protocol, which already uses mime-types as standard, so no translation necessary. I did a quick google search, and it seems under Mac OS X you can use the Carbon Drag Manager. fpGUI doesn't officially support OS X yet, so I don't know further details. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On 23 January 2011 03:16, Hans-Peter Diettrich DrDiettrich1@a* wrote: Clipboard formats (CF_...) may be usable on all platforms with a comparable/compatible clipboard functionality. But what about all the other platforms? As I mentioned, fpGUI uses mime-types. More and more platforms are starting to use mime-types too - a natural evolution (considering the success in emails). fpGUI will register the mime-types, and if a similar platform specific type exists, fpGUI will automatically register that format too (eg: mime-type 'text/plain' under Windows will automatically also have the CF_TEXT type registered). For each platform fpGUI supports, I simply need to override and implement platform specific DND/Clipboard types too (not replacing the mime-types though). Your current implementation is restricted to purely textual information, Simply because I was in a rush to implement the basic workings of DND for a new project of ours. Textual information was good enough to get that app's DND going. The DND does does lend itself to other data types too. Any binary data will simple be transfered via bytes, and internal component-to-component DND could possible also support TStream data. This is one of the optimizations that can be implemented for internal app DND. I'm not sure whether your implementation of rich (html...) text will match the platform standards - with possibly different standards on every single platform :-( Once I'm done with the complete DND implementation in fpGUI, the developer can register for example HTML data via 'text/html', but can retrieve 'text/plain' data (all HTML tags stripped) without any extra effort. fpGUI will automatically do translations between various popular formats. Question remains: which mime type should be associated with e.g. dragging files, or forms? If it's between your own applications, you can use whatever mime-type makes sense to you. But between applications, the most common mine type would be 'text/uri-list'. URI lists are even good enough for DND between computers (Gnome took shortcuts here and doesn't support this). An example of the latter, is executing a X11 app or a remote server, while the display of that app is on your system. So dragging from that remote app to your local apps, the URI should contain the system name (or IP) too. How comes that I cannot drop anything from outside the demo app I can drag text from a web page displayed in Firefox (data type is 'text/html' and a few others). I can also drag the URL of the website to the demo app, without problems. , and no other app accepts the Drag Me!? The demo registers 'text/plain' and 'text/html' mime-types, so only apps that accept that (or under Windows, the CF_TEXT format too) will receive data. I can drag the Drag Me! green label for example into gEdit and indeed I see the text data My name is Earl appear in gEdit. What system are you using to run that demo? -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Your current implementation is restricted to purely textual information, Simply because I was in a rush to implement the basic workings of DND for a new project of ours. Textual information was good enough to get that app's DND going. The DND does does lend itself to other data types too. Any binary data will simple be transfered via bytes, and internal component-to-component DND could possible also support TStream data. This is one of the optimizations that can be implemented for internal app DND. Just to be clear, the current textual data restriction in fpGUI's DND is simply because I haven't had time to implement the binary data support yet. So far, I have only implemented what was needed for our new project. In the near future, I'll complete the whole DND implementation (binary data, byte arrays, TStream and more auto-type conversions between mime and each OS specific formats). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Sun, 23 Jan 2011, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: In fpGUI Graeme implemented an interface for inter-process dragging. It would be nice to have a similar interace in the LCL, that extends the current intra-process dragging. While it is correct that Graeme did this, I still have not seen in action. i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. Simply start the demo app twice, then drag... I was thinking about something non-trivial, of course. I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. I think that Graeme can answer this question... But your suggestion is at least a step in the right direction. I would implement support in 2 objects: TFileDragObject (external files, as dropped by file managers) TExternalDragObject (external app DnD) Both are created whenever an external DnD is found. I'd leave all that to the concrete implementations, and provide specialized handlers in the target controls. Currently TControl.DoDragMsg dispatches the messages to the Drop and Dock methods, based on the DragObject class type. More handlers can be added, and dispatch may be rebased on a drag type (enum) property. I don't think more handlers should be added. There are too many handlers already. That is why you can put the extra information in objects which descend from TDragObject. That is what it is for, and it is also the recommended practice in Delphi: creating a descendant of TDragObject for specific purposes. Putting everything in the base class is IMHO not necessary, and only complicates things. The base class (TDragObject) only must declare the extended API, including common properties. No, that is IMHO a totally wrong design, which will make the base object unnecessarily heavy. This is exactly the reason why the API allows you to create your custom drag object when a drag operation starts: to avoid putting everything in the base object. The API is there. It is extensible - all we need to do is use the already-provided mechanisms. It will require no changes to the code as it is, and the user need not know any extra handlers. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Graeme Geldenhuys schrieb: On 23 January 2011 03:16, Hans-Peter Diettrich DrDiettrich1@a* wrote: Clipboard formats (CF_...) may be usable on all platforms with a comparable/compatible clipboard functionality. But what about all the other platforms? As I mentioned, fpGUI uses mime-types. More and more platforms are starting to use mime-types too - a natural evolution (considering the success in emails). That's okay for data files, but not necessarily sufficient for draggable objects in general. fpGUI will register the mime-types, and if a similar platform specific type exists, fpGUI will automatically register that format too (eg: mime-type 'text/plain' under Windows will automatically also have the CF_TEXT type registered). For each platform fpGUI supports, I simply need to override and implement platform specific DND/Clipboard types too (not replacing the mime-types though). Such a *definition* of types doesn't make any sense to me, in DND or clipboard context. Either different applications have to agree about exchangable data formats, or a single application needs only private types, for strictly private use. Your current implementation is restricted to purely textual information, Simply because I was in a rush to implement the basic workings of DND for a new project of ours. Textual information was good enough to get that app's DND going. The DND does does lend itself to other data types too. Any binary data will simple be transfered via bytes, and internal component-to-component DND could possible also support TStream data. This is one of the optimizations that can be implemented for internal app DND. This is not a matter of optimization, it's a matter of specialization. Every data type must be associated with a class (or component), that *interprets* the data in the intended way. All you need is a *registration* system for such classes. I'm not sure whether your implementation of rich (html...) text will match the platform standards - with possibly different standards on every single platform :-( Once I'm done with the complete DND implementation in fpGUI, the developer can register for example HTML data via 'text/html', but can retrieve 'text/plain' data (all HTML tags stripped) without any extra effort. fpGUI will automatically do translations between various popular formats. This is a matter of extensions as well. Nice to have, but IMO subject to according libraries. Windows leaves it to the clipboard owner, to provide its data in any supported format, and only when requested by a clipboard viewer. Only very basic conversions (text encoding) are supplied by the OS, or may be supplied by e.g. fpGUI. Further filters or converters can be taken from e.g. syntax highlighters or other components, which can register themselves (see above). Question remains: which mime type should be associated with e.g. dragging files, or forms? If it's between your own applications, you can use whatever mime-type makes sense to you. But between applications, the most common mine type would be 'text/uri-list'. URI lists are even good enough for DND between computers (Gnome took shortcuts here and doesn't support this). An example of the latter, is executing a X11 app or a remote server, while the display of that app is on your system. So dragging from that remote app to your local apps, the URI should contain the system name (or IP) too. Did you realize that URI lists are meaningful only to applications, that can handle the referenced resources - in their specific data format, that is not part of the URI. Otherwise the only use of such information is textual display of the URIs themselves, that does not require any special conversion. How comes that I cannot drop anything from outside the demo app I can drag text from a web page displayed in Firefox (data type is 'text/html' and a few others). I can also drag the URL of the website to the demo app, without problems. Okay, Firefox works - but why then do you not simply show the CF_TEXT or CF_UNICODETEXT format? Now that I have a source application, I can play a bit with the missing display features of the demo app... , and no other app accepts the Drag Me!? The demo registers 'text/plain' and 'text/html' mime-types, so only apps that accept that (or under Windows, the CF_TEXT format too) will receive data. I can drag the Drag Me! green label for example into gEdit and indeed I see the text data My name is Earl appear in gEdit. What system are you using to run that demo? I'm using Win7, and none of the standard applications (notepad...) seems to even take notice of an drag from the demo app, while it reacts and accepts drops from other sources. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Graeme Geldenhuys schrieb: Just to be clear, the current textual data restriction in fpGUI's DND is simply because I haven't had time to implement the binary data support yet. So far, I have only implemented what was needed for our new project. In the near future, I'll complete the whole DND implementation (binary data, byte arrays, TStream and more auto-type conversions between mime and each OS specific formats). It will be sufficient if you make dragging simple text work, with other applications. Once this works, somebody else (e.g. me) can add further support for data types. On Windows I'd expect that an fpGUI app accepts everything what notepad accepts, e.g. drags from Explorer, desktop icons... BTW, I'd like comments from others, whether this discussion is of interest to future dragging support in Lazarus as well. E.g. whether the fpGUI approach may be added to the LCL as well, or what should work differently there. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Michael Van Canneyt schrieb: i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. Simply start the demo app twice, then drag... I was thinking about something non-trivial, of course. Please specify what non-trivial use you have in mind, and what results you expect to see in this very early implementation stage (proof of concetpt). I'd leave all that to the concrete implementations, and provide specialized handlers in the target controls. Currently TControl.DoDragMsg dispatches the messages to the Drop and Dock methods, based on the DragObject class type. More handlers can be added, and dispatch may be rebased on a drag type (enum) property. I don't think more handlers should be added. There are too many handlers already. That is why you can put the extra information in objects which descend from TDragObject. Not only information, but also functionality! That is what it is for, and it is also the recommended practice in Delphi: creating a descendant of TDragObject for specific purposes. Right, and every such Delphi class reacts on dragging events, in its ProcessMessages method. The base class (TDragObject) only must declare the extended API, including common properties. No, that is IMHO a totally wrong design, which will make the base object unnecessarily heavy. This is exactly the reason why the API allows you to create your custom drag object when a drag operation starts: to avoid putting everything in the base object. You miss the really essential point: the interface between the drag manager and the drag object. The LCL implementation has *added* a dragmanager object, that is *restricted* to internal dragging. Why that bloat? The LCL implementation has *removed* message processing from TDragObject, and instead has *added* sealed DragPerformers. Why that bloat? This castration disallows to implement further dragging models in TDragObject descendants. How else should this be done, then??? This is what I call totally wrong design :-( The API is there. It is extensible - all we need to do is use the already-provided mechanisms. So you agree to add the removed methods to TDragObject again? ;-) DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On 1/22/2011 20:16, Hans-Peter Diettrich wrote: Graeme Geldenhuys schrieb: [...] I not sure if I understand the original statement, but in fpGUI I use the mime types to register the data that must be transfered via DND. Under Windows, I also register common mime-types that have easy mappings to Windows weird CF_xxx types. So if you register 'text/plain' data in fpGUI, then under Windows, it will also register CF_TEXT for example. Clipboard formats (CF_...) may be usable on all platforms with a comparable/compatible clipboard functionality. But what about all the other platforms? i'm late to the party (again) but reading this, i had these questions... 1. what GUI environments are there that do not have clipboards? 2. are there any that do /not/ use the clipboard for DnD operations? 3. is #2 is yes, what do they use and how? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Op 2011-01-23 22:24, Hans-Peter Diettrich het geskryf: whether the fpGUI approach may be added to the LCL as well, or what should work differently there. I'm afraid you will probably get the response that it's not Delphi compatible. ;) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Op 2011-01-23 22:24, Hans-Peter Diettrich het geskryf: On Windows I'd expect that an fpGUI app accepts everything what notepad accepts, e.g. drags from Explorer, desktop icons... On a side note: I would not test any DND with Notepad, it is useless and can't even accept selected text drag as the target or source. I would rather use WordPad for testing DND instead. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Generalized DragDrop
In fpGUI Graeme implemented an interface for inter-process dragging. It would be nice to have a similar interace in the LCL, that extends the current intra-process dragging. Why that? - A more general approach could solve the known problem with docking forms, by including dragging by the window manager. - Drag-drop of files or other objects as an alternative to an OpenDialog. - Embedding of shared objects (COM, CORBA...) What's required? - A generalization of the DragManager, so that visual (DragImage...) and application feedback (events) are not restricted to application-internal drag sources and implementations. This is not hard to do, all that can be handled in the already existing or added specialized DragObjects, instead of the (superfluous) DragPerformers. - A DragObject should include a SourceType property, so that the targets can handle more source types, e.g. filenames or COM/CORBA objects, in addition to controls. Mime types (strings or enum) can be used for that purpose. Further information for inter-process dragging can be added (source PID, HWND...), so that an application can distinguish internal references (to controls...) from references to objects in other processes. - The event handlers must have access to the extended source information. This is also no problem, since only one drag operation can be active at any time, so that a global DragObject reference can be used everywhere. A predefined DragObject can be used whenever an external object is being dragged over an application form. - More drag and drop types should be defined, in addition to drop and dock, e.g. open files, link or embed. Eventually specialized drag targets must register themselves, for e.g. accepting files or embedding objects, in addition do DockSite registration. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Sat, 22 Jan 2011, Hans-Peter Diettrich wrote: In fpGUI Graeme implemented an interface for inter-process dragging. It would be nice to have a similar interace in the LCL, that extends the current intra-process dragging. While it is correct that Graeme did this, I still have not seen in action. i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. Why that? - A more general approach could solve the known problem with docking forms, by including dragging by the window manager. - Drag-drop of files or other objects as an alternative to an OpenDialog. - Embedding of shared objects (COM, CORBA...) What's required? - A generalization of the DragManager, so that visual (DragImage...) and application feedback (events) are not restricted to application-internal drag sources and implementations. This is not hard to do, all that can be handled in the already existing or added specialized DragObjects, instead of the (superfluous) DragPerformers. - A DragObject should include a SourceType property, so that the targets can handle more source types, e.g. filenames or COM/CORBA objects, in addition to controls. Mime types (strings or enum) can be used for that purpose. Further information for inter-process dragging can be added (source PID, HWND...), so that an application can distinguish internal references (to controls...) from references to objects in other processes. - The event handlers must have access to the extended source information. This is also no problem, since only one drag operation can be active at any time, so that a global DragObject reference can be used everywhere. A predefined DragObject can be used whenever an external object is being dragged over an application form. - More drag and drop types should be defined, in addition to drop and dock, e.g. open files, link or embed. Eventually specialized drag targets must register themselves, for e.g. accepting files or embedding objects, in addition do DockSite registration. I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. But your suggestion is at least a step in the right direction. I would implement support in 2 objects: TFileDragObject (external files, as dropped by file managers) TExternalDragObject (external app DnD) Both are created whenever an external DnD is found. I don't like the idea of SourceType as a general property. I would make it an enumerated (stInternal,stFiles,stExternal) and the TExternalDragObject object can have a MimeTypes property. The TFileDragObject can have a 'FileNames' property of type TStrings; it's all it needs. Putting everything in the base class is IMHO not necessary, and only complicates things. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Saturday 22 of January 2011 16:04:34 Michael Van Canneyt wrote: On Sat, 22 Jan 2011, Hans-Peter Diettrich wrote: In fpGUI Graeme implemented an interface for inter-process dragging. It would be nice to have a similar interace in the LCL, that extends the current intra-process dragging. While it is correct that Graeme did this, I still have not seen in action. i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. Why that? - A more general approach could solve the known problem with docking forms, by including dragging by the window manager. - Drag-drop of files or other objects as an alternative to an OpenDialog. - Embedding of shared objects (COM, CORBA...) What's required? - A generalization of the DragManager, so that visual (DragImage...) and application feedback (events) are not restricted to application-internal drag sources and implementations. This is not hard to do, all that can be handled in the already existing or added specialized DragObjects, instead of the (superfluous) DragPerformers. - A DragObject should include a SourceType property, so that the targets can handle more source types, e.g. filenames or COM/CORBA objects, in addition to controls. Mime types (strings or enum) can be used for that purpose. Further information for inter-process dragging can be added (source PID, HWND...), so that an application can distinguish internal references (to controls...) from references to objects in other processes. - The event handlers must have access to the extended source information. This is also no problem, since only one drag operation can be active at any time, so that a global DragObject reference can be used everywhere. A predefined DragObject can be used whenever an external object is being dragged over an application form. - More drag and drop types should be defined, in addition to drop and dock, e.g. open files, link or embed. Eventually specialized drag targets must register themselves, for e.g. accepting files or embedding objects, in addition do DockSite registration. I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. But your suggestion is at least a step in the right direction. I would implement support in 2 objects: TFileDragObject (external files, as dropped by file managers) TExternalDragObject (external app DnD) Both are created whenever an external DnD is found. Files dropping is already implemented, and I'm pretty sure that Qt supports DnD across different apps on all platforms. Haven't studied gtk2 in this case, but your suggestion looks good. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Sat, 22 Jan 2011, zeljko wrote: I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. But your suggestion is at least a step in the right direction. I would implement support in 2 objects: TFileDragObject (external files, as dropped by file managers) TExternalDragObject (external app DnD) Both are created whenever an external DnD is found. Files dropping is already implemented, and I'm pretty sure that Qt supports DnD across different apps on all platforms. Haven't studied gtk2 in this case, but your suggestion looks good. I know about the File DND, but as far as I know, it's only on form level, it could be extended to any control (TFileNameEdit jumps to mind). Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Saturday 22 of January 2011 17:27:43 Michael Van Canneyt wrote: On Sat, 22 Jan 2011, zeljko wrote: I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. But your suggestion is at least a step in the right direction. I would implement support in 2 objects: TFileDragObject (external files, as dropped by file managers) TExternalDragObject (external app DnD) Both are created whenever an external DnD is found. Files dropping is already implemented, and I'm pretty sure that Qt supports DnD across different apps on all platforms. Haven't studied gtk2 in this case, but your suggestion looks good. I know about the File DND, but as far as I know, it's only on form level, it could be extended to any control (TFileNameEdit jumps to mind). Why not, I'm already missing some things like dragging/dropping selected text eg. from/to openoffice doc. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On 22 January 2011 17:04, Michael Van Canneyt michael@*** wrote: On Sat, 22 Jan 2011, Hans-Peter Diettrich wrote: In fpGUI Graeme implemented an interface for inter-process dragging. It would be nice to have a similar interace in the LCL, that extends the current intra-process dragging. While it is correct that Graeme did this, I still have not seen in action. i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. That's the beauty of that design internal component-to-component or external app-to-app DND is handled exactly the same - from the developers perspective. That was the whole point of that implementation - so you application is single source, no matter the platform (and importantly, no IFDEF's). Internally the fpGUI frame can optimize for internal component-to-component DND without needing to speak to the OS or window manager. I have also note that the fpGUI DND implementation is not 100% complete yet. Currently I still need to implement the non-text data transmission. Not hard to implement, because the internal workings are already implement in fpGUI. I just need to find some time, to complete the alternative data types handling. - More drag and drop types should be defined, in addition to drop and dock, e.g. open files, link or embed. Eventually specialized drag targets must register themselves, for e.g. accepting files or embedding objects, in addition do DockSite registration. I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. I not sure if I understand the original statement, but in fpGUI I use the mime types to register the data that must be transfered via DND. Under Windows, I also register common mime-types that have easy mappings to Windows weird CF_xxx types. So if you register 'text/plain' data in fpGUI, then under Windows, it will also register CF_TEXT for example. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). Correct, under Windows I use OLE DND, and under Linux I use the XDND protocol which uses mime-types. The XDND protocol has support for any data types that you can describe with mime. I don't know how it is done in Mac. I have to clue about Mac either. :) -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On 22 January 2011 18:27, Michael Van Canneyt michael@fre* wrote: I know about the File DND, but as far as I know, it's only on form level, it could be extended to any control (TFileNameEdit jumps to mind). I was just about to mention that. File DND in Lazarus is very limited, and when I played with DND from other platforms like LCL, that was exactly what I tried, using TFileNameEdit didn't accept files at all - a rather large omission in LCL considering what that component does. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Michael Van Canneyt schrieb: In fpGUI Graeme implemented an interface for inter-process dragging. It would be nice to have a similar interace in the LCL, that extends the current intra-process dragging. While it is correct that Graeme did this, I still have not seen in action. i.e. I have used the application-specific DnD, but I wouldn't know how to handle the intra-app DnD. Simply start the demo app twice, then drag... I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. I think that Graeme can answer this question... But your suggestion is at least a step in the right direction. I would implement support in 2 objects: TFileDragObject (external files, as dropped by file managers) TExternalDragObject (external app DnD) Both are created whenever an external DnD is found. I'd leave all that to the concrete implementations, and provide specialized handlers in the target controls. Currently TControl.DoDragMsg dispatches the messages to the Drop and Dock methods, based on the DragObject class type. More handlers can be added, and dispatch may be rebased on a drag type (enum) property. Putting everything in the base class is IMHO not necessary, and only complicates things. The base class (TDragObject) only must declare the extended API, including common properties. It also will introduce the virtual methods, required at the begin, during dragging, and on an drop. Actually the drag performer API can be moved from TDragDockCommon into TDragObject, and its implementation (of internal dragging) into TDragControlObject and TDragDockObject. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Michael Van Canneyt schrieb: I know about the File DND, but as far as I know, it's only on form level, it could be extended to any control (TFileNameEdit jumps to mind). Windows platform requires a HWND for a file DND, that can be supplied by any TWinControl. Other platforms can have different requirements, and we should implement only what's possible on all platforms. When a DragObject is used in such dragging, it contains the concrete target control at the time of the drop. Then it's only a matter of a LCL convention, which controls qualify as dropfiles targets, e.g. when they have an OnDropFiles handler installed. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
Graeme Geldenhuys schrieb: That's the beauty of that design internal component-to-component or external app-to-app DND is handled exactly the same - from the developers perspective. That was the whole point of that implementation - so you application is single source, no matter the platform (and importantly, no IFDEF's). Very nice, so far. Internally the fpGUI frame can optimize for internal component-to-component DND without needing to speak to the OS or window manager. This is what may pollute the current design. I have also note that the fpGUI DND implementation is not 100% complete yet. Currently I still need to implement the non-text data transmission. Not hard to implement, because the internal workings are already implement in fpGUI. I just need to find some time, to complete the alternative data types handling. I feel that there remains much more to do. It starts with the assignment and handling of the existing and possibly added mime types, adding process information (and more) to the drag info... - More drag and drop types should be defined, in addition to drop and dock, e.g. open files, link or embed. Eventually specialized drag targets must register themselves, for e.g. accepting files or embedding objects, in addition do DockSite registration. I'm all for it. Although I'm not sure that this can be implemented in a cross-platform way. I not sure if I understand the original statement, but in fpGUI I use the mime types to register the data that must be transfered via DND. Under Windows, I also register common mime-types that have easy mappings to Windows weird CF_xxx types. So if you register 'text/plain' data in fpGUI, then under Windows, it will also register CF_TEXT for example. Clipboard formats (CF_...) may be usable on all platforms with a comparable/compatible clipboard functionality. But what about all the other platforms? On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). Correct, under Windows I use OLE DND, and under Linux I use the XDND protocol which uses mime-types. The XDND protocol has support for any data types that you can describe with mime. Your current implementation is restricted to purely textual information, and I'm not sure whether your implementation of rich (html...) text will match the platform standards - with possibly different standards on every single platform :-( Question remains: which mime type should be associated with e.g. dragging files, or forms? How comes that I cannot drop anything from outside the demo app, and no other app accepts the Drag Me!? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Generalized DragDrop
On Sat, Jan 22, 2011 at 10:04 AM, Michael Van Canneyt mich...@freepascal.org wrote: On Windows, the intra-app drag/drop is handled using OLE/DDE. On Linux, there is no such thing, and I think it depends on the used desktop software (KDE vs Gnome). I don't know how it is done in Mac. In Carbon it's based on events queue (the similar to windows message) queue. Really nice and easy. Data formats for DND is just the same as Clipboard formats. I'm not sure, but I guess it's similar for Cocoa. thanks, dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
