I am switching from Delphi7-BDS2006 on Windows to FPC-Lazarus on Windows with the aim of making cross-platform programs. I also want to make one program run on an embedded ARM board running linux for ARM.

So I have read a lot of the discussions here and asked questions about setting up the environment etc.

One thing that bothers me is that I don't understand the term "widget", which gets mentioned very often when discussion is about screen output and the like....

What is a "widget" and how does it relate to my aim of making a cross-platform program?

Is there a requirement for knowing which graphics card is going to be used on the target machine if that is a Linux operating system? If so how can anyone make a program that can run on any customer's system and still not distribute the source code (which I do not want)? I am assuming here that the graphics card is somehow sensed or similar when the program is compiled on the target system.

Very confused because this has never popped up when I programmed for Windows all these past 16-20 years....

Op 2011-01-05 10:23, Bo Berglund het geskryf:

What is a "widget" and how does it relate to my aim of making a cross-platform program?

widget = component

Widget is a term often used in Linux (and maybe other OSes too) as a "gui component". Delphi calls them components, but then in Delphi how to you differentiate between a GUI component and a non-GUI component? Widgets are used as GUI components only.

Regards,
- Graeme -

It's not so much "widgets" as "widget set", and it refers to whether the intermediate layer between your program is based on Windows, Qt, GTK (1 or 2) etc.

Mark Morgan Lloyd wrote

It's not so much "widgets" as "widget set", and it refers to whether the intermediate layer between your program is based on Windows, Qt, GTK (1 or 2) etc.

"Widget Set" is the more common term, but in Lazarus it's (mostly, e.g. Project -> Options -> Compiler Options) "Widget Type".

While a "Widget Set" usually is a collection of layout (and functionality) instructions for commonly used GUI control elements, in Lazarus it is more than this, definig a large part of the OS API a project is supposed to use, and even is important for projects that don't use a function of TTimer and inter Thread
Messaging is defined in the code for the Widget Set used with the project. Unfortunately this results in some widgets sets that don't allow for using TTimer and inter Thread Messaging.

-Michael

Thanks for the extra detail re. timers etc. So the bottom line is that Bo's Delphi code is currently using the only widget set that the VCL supports, i.e. Windows, and he's probably going to have to move onto something like gtk v2; clearly this means that gtk etc. does have to work on whatever ARM-based board he's chosen.

Op 2011-01-05 13:38, Mark Morgan Lloyd het geskryf:

supports, i.e. Windows, and he's probably going to have to move onto something like gtk v2; clearly this means that gtk etc. does have to work on whatever ARM-based board he's chosen.

[promo hat on]
Obviously he can also move to something lighter, with less dependencies that LCL, resulting in much smaller executables, and easier deployment. One such alternative, for ARM-based boards, is fpGUI Toolkit. ;-) [promo hat off]

Regards,
- Graeme -

Yes, I was going to mention that but at present it's unclear whether it's immediately usable from the Lazarus IDE. If it is not, since Bo is talking about converting an existing Delphi project I don't think that fpgui would be a visible option.

Op 2011-01-05 14:24, Mark Morgan Lloyd het geskryf:

Yes, I was going to mention that but at present it's unclear whether it's immediately usable from the Lazarus IDE.

fpGUI works with any IDE or editor - their are no dependencies to a specific IDE.

If it is not, since Bo is talking about converting an existing Delphi project I don't think that fpgui would be a visible option.

Going from VCL to GTK or GTK2 is bound cause problems too (I know), so it is not as if it is simply going to be a re-compile and be done with it. fpGUI is also quite easy to learn and has other benefits too. I just thought it might be beneficial for the original poster to know all his options available to him (unlike when I moved away from Delphi). Obviously MSEide and MSEgui is another option, but that is very different to VCL (steep learning curve). Though different is not always bad.

Regards,
- Graeme -

Right, so you're saying that it's not integrated with Lazarus to the same extent that the LCL is. If that is the case I'm not sure that it's going to be a painless option for Bo.

Bo, I suggest that you check that your board supports GTK etc. If it doesn't support GTK but it does have basic X graphics then fpGUI might be the least painful option.

Back again so I could read up on this thread...

So basically a widget set is a definition on what kind of graphics environment is used on the target system then?
What about making a program for Linux? Do we have to compile the same program in different versions for different desktop managers on Linux? Like one for Gnome, another for KDE and yet another for X??? Sounds mighty tedious and error prone...

My first project is to make an embedded application but develop it on a Windows host where I also want it to be running for checks etc. This application needs some basic graphics, like using Canvas methods to draw simple geometric forms on an image.
It is similar to a graphing software visualizing acquired data as points (colored circles) connected by lines on a Cartesian coordinate system graph. Nothing fancier than that.

In Delphi I created a very small graphic object TGraphImage, which has methods for scaling the canvas to real values as opposed to pixels, drawing lines, rectangles, circles etc with various simple colors. It can also print text labels on the image.
I would like to use this also in Lazarus and in the embedded environment.

The embedded card is a touch panel from Technologic Systems (http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390#), which runs an embedded version of Debian Linux, I believe. If it supports GTK (what is that?) or not I don't know but I will ask them.

The other thing I want to do is convert an existing application for data analysis to run in Lazarus and crosscompiled for Linux x86 so we have more options for the customers.
The aim here is to get Windows/Linux versions and also to get it compiled for 64 bit so we can use larger data sets. But here is the caveat that the number crunching is done in Fortran generated DLL:s (se other threads)....

I quote from the link you gave ("Software" tab):

"Custom Linux GUI applications can be developed using X Windows (Xorg-Xserver included) or QtEmbedded libraries (available for download)."

So you can use lazarus with the Qt widgetset. You can also use fpgui and MSEide+MSEgui.

Henry

Op 2011-01-05 15:05, Mark Morgan Lloyd het geskryf:

Right, so you're saying that it's not integrated with Lazarus to the same extent that the LCL is. If that is the case I'm not sure that it's going to be a painless option for Bo.

Define integrated? Here I have registered fpGUI project types (via the File > New Project dialog), fpGUI includes a runtime package (*.lpk) so Lazarus IDE can find the sources (no need to recompile the IDE for that or fiddle with path settings), Ctrl+F12 launches the fpGUI UI Designer loading the current file I am editing, closing the UI Designer after designing a form causes Lazarus to auto-reload that changed file in the source editor again, Ctrl+F1 does context sensitive search (via fpGUI's DocView) on Object Pascal syntax and fpGUI framework classes, etc... I'd say it's well integrated. btw: everything I just mentioned works with MSEide too.

At least now Bo should know some of the options available to him, so he can make an educated decision.

@Bo
I would also suggest you look at Paul Breneman's website. He has created various pre-compiled FPC+fpGUI archives (1?3 MB in size) that you simply need to unzip, to have a working development environment for embedded devices (ARM and i386).

http://www.turbocontrol.com/embeddedfreepascal.htm http://www.turbocontrol.com/helloworld.htm
http://www.turbocontrol.com/easyfpgui.htm

Regards,
- Graeme -

I'd say that widget = TWinControl (and others derived from TWinControl of course).

zeljko

No, normally KDE, which is based on Qt, supports running GTK and GTK2 applications as well. Also Gnome (on Ubuntu) might run Qt applications, too (at least if the Qt libraries are installed).

I myself use a Linux laptop without Gnome or KDE, but I can run GTK, GTK2 and Qt applications on it.

There is no pure X widget set in Lazarus, you always need to decide whether you want to run Qt or GTK2 (GTK is deprecated today). You might want to read about the two on Wikipedia:
http://en.wikipedia.org/wiki/Qt_%28framework%29
http://en.wikipedia.org/wiki/GTK+

If you want a Object Pascal GUI framework with as less dependencies as possible (only X), then I'd suggest you - as Graeme did - fpGUI, but you need to keep in mind that this isn't VCL compatible like the LCL is.

Regards,
Sven

On further investigation, it looks like they have images which contain gtk:

ftp://ftp.embeddedarm.com/ts-arm-sbc/ts-7390-linux/distributions/

No, it's one or more libraries installed on the system which contain all the code to draw standard controls- buttons and so on- on the underlying graphics provided by the operating system. There is a handful of widget sets- Windows, Qt and GTK for example- and a smaller number of underlying graphics subsystems- Windows and X as examples.

Note that in that case there is a part of Windows that implements a widget set, and a part that implements low-level graphics. It's possible to have the Qt widget set (and possibly others) on top of Windows's low-level graphics.

What about making a program for Linux? Do we have to compile the same program in different versions for different desktop managers on Linux? Like one for Gnome, another for KDE and yet another for X??? Sounds mighty tedious and error prone...

The LCL provides an interface between your program and the available widget set, all you have to do is set the project options to tell it which to use at which point Lazarus or lazbuild does the work for you. X is a red herring since it's at a lower level than a widget set.

I can't speak for anybody else, but I generally compile for GTK v1, v2, Qt and Windows, depending on the underlying OS. If you set your target file name to something like
myproject-$(TargetCPU)-$(TargetOS)-$(LCLWidgetType) Lazarus/lazbuild will create distinct binaries for all combinations, the only gotcha is that you need to make sure that the libraries implementing the widget set are present on the target system.

My first project is to make an embedded application but develop it on a Windows host where I also want it to be running for checks etc. This application needs some basic graphics, like using Canvas methods to draw simple geometric forms on an image.

No. Your first project is a simple form with one button on it that displays "Hello, World!" in a panel. Trust me.

The embedded card is a touch panel from Technologic Systems (http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390#), which runs an embedded version of Debian Linux, I believe. If it supports GTK (what is that?)

I've told you: it's a widget set. And I've told you what a widget set is as well :-)

or not I don't know but I will ask them.

You don't have to ask them. Run

dpkg --get-selections |grep gtk

and expect to see output something like

libgpod3-nogtk install libgtk1.2 install libgtk1.2-common install libgtk1.2-dev install libgtk2.0-0 install libgtk2.0-common install libgtk2.0-dev install libgtkglext1 install libgtkhtml2-0 install libwxgtk2.6-0 install libwxgtk2.8-0 install pinentry-gtk2 install python-gtk2 install

Note the -dev packages, which contain all the development (header etc.) files. If it's a comparatively recent Debian then it will almost certainly have the GTK v2 libraries, if it's an older one it might only have v1. Lazarus currently defaults to v2 of GTK rather than v1, v1 is deprecated with limited support.

If you don't have the libraries or the development packages then installing them is fairly simple. However as recently discussed that's not strictly the role of this mailing list: I'm sure that everybody in here is happy to help, but what a particular reseller is doing with an unspecified version of a standard distro is ultimately not our responsibility.

Op 2011-01-05 15:23, Bo Berglund het geskryf:

So basically a widget set is a definition on what kind of graphics environment is used on the target system then?

Correct. As standard, Windows only has the WinAPI (GDI etc), and Delphi's VCL is a wrapper for that API. Under Linux you have more choices of GUI toolkits. Linux's GUI is provided via X11 (Xorg-XServer) and the most common library used to talk to X11 server is XLib. This all comes standard with Linux (desktop and most embedded systems). Qt, GTK, fpGUI etc are gui toolkits built on top of that, talking to Xlib (Qt and GTK also talk to Cairo, yet another graphics layer on top of Xlib). Gnome and KDE are "desktop environments" (the desktop you see when you boot Debian or Ubuntu into a gui mode - and their application are based on GTK2 or Qt GUI libraries respectively. LCL is another layer on top of that - a wrapper for GTK2, Qt, Win API etc... This is where LCL's bigger dependency comes from. fpGUI and MSEide talks directly to Xlib (under linux, unix etc) or Windows GDI (under Windows and WinCE).

What about making a program for Linux? Do we have to compile the same program in different versions for different desktop managers on Linux? Like one for Gnome, another for KDE and yet another for X??? Sounds mighty tedious and error prone...

Most linux distos for desktops (not embedded systems) come standard with the various runtime libaries. So even though you use Ubuntu and Gnome as you desktop, you can still run KDE applications under Gnome or Gnome/GTK apps under KDE. If you want improved desktop integration with the desktop environment, then it might be better to compile your apps for that specific gui library (Gnome/KDE).

The embedded card is a touch panel from Technologic Systems (http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390#), which runs an embedded version of Debian Linux, I believe.

As Henry mentioned, that website lists the core X11 server as included, and also mentions that Qt-Embedded runtime library is included. So that leaves you with an Qt-Embedded or Xlib based gui toolkits (GTK1/GTK2 was not listed, but you might be able to install that yourself).

Note though that if you are creating commercial apps with Qt, you need to purchase a license (+-3500 US dollars per developer - last time I checked). fpGUI and MSEide are free, even for commercial apps.

As for doing drawings, graphs etc as you mentioned - that is all possible with Qt-Embedded, fpGUI and MSEide. Just to be clear, the latter two can also be used for desktop apps, they are not limited to embedded devices.

Regards,
- Graeme -

It should not be necessary to use a tailored image, all you need to do is get the development package from the Debian repository which should pull in the libraries as well.

I've got slight reservations about KDE/Qt because my experience is that the libraries required aren't compatible with the current (Stable, "Lenny") Debian, but only with the unreleased next version (SID, "Squeeze"). And SID/Squeeze uses KDE v4, which is pretty alien to anybody used to older versions.

That must have been over a year ago then I guess. Qt is licensed under LGPL, so you can freely use it even for commercial applications. That was also possible before then, but it was GPL so you had to offer all your source code too (depending on how you interpret the GPL terms, but that's even more offtopic now).

I'm pretty sure that Qt-Embedded is a superset of Qt, so it should be possible to reuse the same code. The strong point of Qt-embedded is, that it *doesn't* use the X server but uses the framebuffer and implements an own windowing system. So you are pretty much independent from many other components. Also Qt-embedded (as does Qt) comes with lots of helper libraries (Networking etc.) that really give you a coherent framework for app development.

Best Regards,
Andreas

Hi Graeme,

I would very much like to get MSEide set up that way and into a minimal distro for demonstration purposes. If you have this documented somewhere please share a link! You may already have this and I've overlooked it.

Bo has the same embedded device that I have so he has been aware of those minimal distros for some time.

To be more accurate those minimal distros are mainly handy for initial "hello world" type of tests. And with fpGUI they are much better than just viewing screenshots on a web page. :)

Yesterday I loaded the Win32 fpGUI zip into ReactOS in VMware and it *mostly* worked. ReactOS has some good potential as a free embedded OS but I doubt it will ever be good enough for general desktop use.

For actual development of real projects those minimal distros are limited in that only the minimal amount of FPC units are provided. If you need other capabilities in your program you'll still need a full FPC install to pull compiled units from. And no IDE is included either, but as I wrote I'd like to add MSEide.

Paul

Hi Mark,

You and Bo might be interested in this project:
http://automon.donaloconnor.net/

It is the same embedded device that Bo and I have. He is using QT. It would be interesting to see how well that could be done using Lazarus and QT. The device is a bit underpowered but using framebuffer rather than X probably helps.

Paul

Paul Breneman wrote

Yesterday I loaded the Win32 fpGUI zip into ReactOS in VMware and it *mostly* worked. ReactOS has some good potential as a free embedded OS but I doubt it will ever be good enough for general desktop use.

I know this is getting off topic, but how much did it work? What failed? Might you be able to post a bug report for ReactOS?

Regards,
Sven

Hi Paul,

Paul Breneman wrote

I would very much like to get MSEide set up that way and into a minimal distro for demonstration purposes. ?If you have this documented somewhere please share a link! ?You may already have this and I've overlooked it.

Have a look at:
<fpgui>/extras/mseide_templates/readme.txt

I'll had more detailed instructions in the usual
<fpgui>/docs/INSTALL.txt file too.

Paul Breneman wrote

would be interesting to see how well that could be done using Lazarus and QT. ?The device is a bit underpowered but using framebuffer rather than X probably helps.

Adding a Linux framebuffer backend to fpGUI is already on my todo list. I hope to get it done this year, so then fpGUI can compete on that level too. :)

Mark Morgan Lloyd wrote

It should not be necessary to use a tailored image, all you need to do is get the development package from the Debian repository which should pull in the libraries as well.

I'd usually expect embedded vendors to build packages specifically targeted for their processor, as there are many ARM configurations, and Debian only targets the ARMv4T architecture with no hardfloat, which wouldn't make much sense to run on more modern processors. But this specific board does have an ARM920T, so maybe they just connect to the Debian repositories.

Henry

I compiled and ran the fpGUI uidesigner program. The graphics didn't work right. The combobox dropdown list appeared somewhere else on the screen. The black dots around controls when you selected them didn't appear. I didn't do a lot of testing but apparently the GDI layer isn't quite done. I would guess that if you ran a Delphi or Lazarus program that used Win32 widgets they would work better.

FWIW and from what i've learned, this is accurate... more accurate than what other stuff i've seen and it pertains directly to Lazarus' usage...

it may also be stated as

widget = TWinControl and descendants

;)

That's OK in the context of FPC and Lazarus, but "Widget" and "widget set" are generally-understood terms in the overall-context of unix-like operating systems.

If Bo goes to his system supplier and asks which widget set is installed and they ask what he means, he isn't going to get very far by starting to talk about TWinControl etc. Instead he needs to say something along the lines of "what's on there- GTK or Qt, and what version?".

Mark Morgan Lloyd wrote

That's OK in the context of FPC and Lazarus, but "Widget" and "widget set" are generally-understood terms in the overall-context of unix-like operating systems.

That's ok in any context. Widget = Visual control in any gui library (at least under unix), so under qt widget = QWidget and descendants, under gtk widget = GtkWidget and descendants, under lazarus Widget = TWinControl and descendants. What's unclear here ? That we have TWinControl instead of TWidget ?

Yes, WidgetSet is not TWinControl (so no need to explain what's TWinControl etc) , but gui library which provide native widgets, so correct answer to such question could be qt,gtk,win32,carbon,fpgui etc.

zeljko

zeljko wrote

I'd say that widget = TWinControl (and others derived from TWinControl of course).

OK, but rater irrelevant regarding Lazarus.

Here "*Widget Type* = TWinControl + all handling of External Events".

Handling of External (Main Thread) Events means: allowing the main thread to do non busy waiting for something and being waked if something happens and execute the appropriate event handler.

Background:

If the program is not a command line tool, the main thread needs to be waiting nearly always and needs to be waked whenever something happens that needs attention.

Theses "external events" are scheduled by the GUI (key and mouse triggered events), inter-process or inter-thread communication, Timers, etc, you name it. They need to be queued, so that the main thread can handle them one after the other (see "TApplication.ProcessMessages").

As the GUI events is the by far most complex class of external events, and the GUI stuff is handled in the Widget Set code in the LCL, the other external events are dealt with, in theses files as well. (unfortunately) there is no common implementation of non-GUI external events that is used by multiple Widget sets. This makes the creation of Widget sets that are independent of an external widget set (such as Windows, GTK, or QT) a lot more difficult and less "compatible".

OTOH, FPGUI seems to succeed on this behalf.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110106/e1b8791b/attachment.html>

Bo Berglund wrote

What about making a program for Linux? Do we have to compile the same program in different versions for different desktop managers on Linux?

That depends on what you want to accomplish.

AFAIK, if you use the GTK or QT "widget type", The program will auto-adopt to the appropriate "Look and fell" of the *external* widget set used, including adhering to global design settings made to same and future updates.

AFAIK, the FPGUI Widget Type does not use an external widget set, but directly accesses the X server and thus the program will look the same everywhere and always.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110106/b336f33a/attachment.html>

Graeme Geldenhuys wrote

Adding a Linux framebuffer backend to fpGUI is already on my todo list. I hope to get it done this year, so then fpGUI can compete on that level too. :)

Did you consider Nano-X, too ? ( see http://microwindows.org/, download: ftp://microwindows.org/pub/microwindows/microwindows-full-0.92.tar.gz, mailing List )

Maybe you can use this instead of your own Framebuffer, as they provide a framebuffer-implementation in their software.

-Michael

Op 2011-01-06 13:15, Michael Schnell het geskryf:

I remember reading about Nano-X years ago. I'll take another look. For the framebuffer backend, I was considering using DirectFB, which already has the notion of "windows and events". The other idea was using SDL, which I believe also works with Linux Framebuffer. The benefit of SDL is that it will automatically work on other platforms too (eg: OS/2, Haiku, etc... any platform that supports SDL). The downside means one extra requirement, installing SDL, though I think SDL is quite standard nowadays and included in most distros.

I'll research the subject more before I write any code.

Regards,
- Graeme -

What is a "widget" and how does it relate to my aim of making a cross-platform program?

IMO widgets are visual components, provided and managed by a "widgetset" library. Many OS (except Linux/Unix) have native widgetsets, and allow for user installable widgetsets as well (Qt, gtk...). The LCL tries to provide an interface that works with arbitrary widgetsets - as far as a concrete widgetset is compatible with that interface. All LCL widgets inherit from TWinControl.

There exist other widgetsets that are pure FPC/LCL (fpgui, msegui).

Forms are special widgets, usually managed by a window manager. The window manager is platform specific and can not be replaced. The *appearance* of forms (and other widgets) can be configured by themes, so that most users don't recognize the existence of an window manager. Nonetheless the window manager dictates the behaviour of forms, and implements a taskbar (if available), and a notification system for events (mouse clicks...).

So we have a hierarchy of managers (or libraries):

graphics library (all drawing, fonts, themes)
window manager (screen management, standard dialogs, taskbar, menus) widgetset (provides and manages widgets = TWinControl) LCL (also provides unmanaged controls = TGraphicControl)

IOW the frame of every window/form (non-client area) is managed by the window manager, while its content (client area) is under control of the application. An application can paint the client area itself, and/or it can use widgets or other controls for content presentation, as e.g. provided by the LCL, VCL, CLX...

DoDi

If you not use it, would you please make it as an option (new Platform).

2011/1/9 Zaher Dirkey :

If you not use it, would you please make it as an option (new Platform).

Yes, it will definitely be a new "platform". fpGUI would then have eg: GDI, X11, SDL etc. as backends.

I think it makes more sense to skip SDL and directly use the linux framebuffer. Eliminate a layer. You already have direct support for all other 'platforms' that SDL supports, so why add another (changing) dependency/point of failure? It may be initially harder, but will prove easier to maintain in the long run.

Michael.

On Sun, Jan 9, 2011 at 12:44 PM, Michael Van Canneyt <

It is for games, like The Mana
World<http://sourceforge.net/projects/themanaworld>, have dialogs for options and login, we can use both SDL and show some forms.

This is also the reason why I started on a GLut/OpenGL backend for fpGUI. In the last weeks it has reached a point that some examples already work perfectly. Also I have done some preliminary tests on Mac and Linux (primary developing on Win32) which indicate it should run there without any issues. What still needs to be done it to analyze why certain widgets are not drawn correctly (fixing the backend and some subtle bugs in the core lib), fixing font drawing (which seems to have some major issues) and finally cleaning everything up.

I'm doing the development work on: svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/

Regards, Darius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110109/cd36556f/attachment.html>

Michael Van Canneyt wrote

I think it makes more sense to skip SDL and directly use the linux framebuffer.

The reasoning behind wanting to use SDL is so that I can target multiple platforms with one backend. Maybe not ideal, but a quick fix in supporting many platforms. Two platforms I am very interested in is Linux Framebuffer (so as to bypass the horrible X11) and Haiku (pretty amazing features and very fast).

Closer to the time, I'll take a deeper look into each platforms API. As you said, writing for the platform directly and bypassing a extra layer/dependency might be the better approach in the long run.

That's why we would need a common context library to be added to fpGUI in the long term.

Darius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110109/67df686b/attachment.html>

2011/1/9 Darius Blaszyk :

I'm doing the development work on: svn://scandraid.svn.sourceforge.net/svnroot/scandraid/src/branches/fpgui/

I checked out that branch and tried to compile the fpgui_toolkit.lpk package in the 'gl' directory. Where do I find the "freeglut" unit which the compiler complains about. I'm using Ubuntu 8.04.4 and have installed all the glit and freeglut related packages and their *-dev packages.

I'm using FPC 2.4.3

2011/1/9 Darius Blaszyk :

That's why we would need a common context library to be added to fpGUI in the long term.

True. I guess if fpGUI still used a "single handle per form" design, things would have been a bit easier in this regard, but that would again make other things more difficult (drag-n-drop, docking etc comes to mind). On a side note: I still have no clue how Qt managed to make a smooth transition from "one handle per widget" to "single handle per form" design.

Who said it was smooth ? =-)

It's not because the application developer doesn't notice, that they didn't have problems with it's implementation...

I suspect that their experience with Qt embedded (working on the framebuffer) would have helped.

Michael.

Michael Van Canneyt wrote

Who said it was smooth ? =-)

By smooth, I meant the end-users (developers using Qt) did not notice anything different from there perspective. Re-reading the Qt blog on the subject, they do mention there was some "black magic" involved from their side - but again ensuring the end-user wouldn't notice anything different.

http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

Looking at their first video clip though, I still have questions about why those widgets moved so much or momentarily disappear. I have never seen such bad "flicker" in fpGUI. Though X11's resizing performance (with or without compiz) is atrocious. The worst I've seen on any platform ever.

Some days I still have mixed feeling about the move I made from "single window handle per form" to "window handle per widget". At the time I was very new to X11 and GDI, and the original fpGUI code. Oh well, what's done is done. :)

I suspect that their experience with Qt embedded (working on the framebuffer) would have helped.

Probably so, because there they would have had to introduce the whole window handling and event system themselves.

I warned you. ;-)

Martin

Martin Schreiber wrote

I warned you. ;-)

I did say "mixed feelings", not "regret". ;)
I still think both methods have their pros and cons - depending on what you want to accomplish.

Oops, you'll need some stuff from another branch as well. I will update SVN and will let you know.

My branch uses fcl-image and opengl from FPC 2.5.1 and some local modifications (mainly on freetype support). These will hopefully be merged bach to trunk once I finish and cleanup.

Regards, Darius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110109/31d2d87a/attachment.html>

On a side note: I still have no clue how Qt managed to make a smooth transition from "one handle per widget" to "single handle per form" design.

Where do you see problems?

The OS has to track some global notification "targets", for e.g. keyboard input or mouse capture. These targets are processes (or threads) in the first place. With no such global target (e.g. on an uncaptured mouse click) the screen/window manager can determine the target process from the information, stored with every window. That's why forms/windows always have a handle, assigned and used by the window manager of a platform.

The determination of a closer target (e.g. control) is up to the application or library, that manages the layout of a window. Every application or library can freely define their own "handles" for every possible notification target, as appropriate to dispatch incoming notifications. The "natural" handle of every such target is the address of the data structure, that describes the target. The LCL can use the addresses of TComponent objects for its handles, while a widgetset can use the addresses of its equivalent data objects.

Handles in general can be seen as pointers to data structures, or as indices into according pointer tables, that make sense only to the owner of those structures, within its own address space. E.g. GDI handles look much like indices into some (sparse) pointer array, consisting of areas for system wide objects (fonts...), and application or device context specific objects.

DoDi

I have added everything under a folder named "external". Just add the two folders to the unit search path and it should compile.

Regards, Darius

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110109/8cc79e7d/attachment.html>

For what it's worth, I agree. If fpGUI goes directly to the framebuffer it will be usable with almost all Linux systems, while if it requires SDL there might turn out to be version requirements which prevent it from working in some cases.

FPC and Lazarus are, by and large, pretty simple to build. Middleware such as SDL can be far more difficult because it can turn out to have a cascade of requirements, and in the past I've found things like TrueType to be particularly painful.

FPC and Lazarus are, by and large, pretty simple to build. Middleware such as SDL can be far more difficult because it can turn out to have a cascade of requirements, and in the past I've found things like TrueType to be particularly painful.

Hi Mark,

Can you explain what your problems were with truetype? I'm using freetype for font rendering in the opengl backend but so far there were no main issues with the freetype bindings, apart from some issues (bugs?) in the fontmanager.

Regards, Darius

Hi Graeme and all,

Subject edited. Cross posted to Lazarus and Free Pascal lists.

Can fpGUI *currently* be used with (JEDI-)SDL?

Also, what the sources of the latest SDL libraries and demos for Lazarus? I could only find (and download) JEDI-SDLv1.0.zip, which is for Delphi and someone else here (on the Lazarus list) offered to send me the latest version.

Who is the administrator for the JEDI-SDL official releases? Are you doing your job, or voluntary role? :-) If you say "Yes" then why is the latest version of JEDI-SDL not currently available for download by the public?

Is the latest Lazarus & Free Pascal version of JEDI-SDL only available via the peer group of it's users? :-( If that is true then it is time that a new official version is published on Source Forge (currently at v1.0) for Delphi only.

What is the difference between using fpGUI with SDL and Lazarus with SDL?

Does the fpGUI + SDL create smaller binaries (on linux) versus Lazarus + SDL? Or are the other pros and cons?

I have a Lazarus and SDL game application and I was not aware of the option of using fpGUI + SDL. Advantages and disadvantages, please?

pew

Hi,

Can fpGUI *currently* be used with (JEDI-)SDL?

You can use pretty much any library with fpGUI, just like you can with any FPC based application. What the fpGUI+SDL discussion was about, is the various backends fpGUI supports for drawing its widgets. Currently fpGUI talks to X11 (under Linux/*BSD) and GDI (under Windows/WinCE) to get window management and painting API's. The SDL discussion was about extending the fpGUI code with a new SDL backend - where SDL does the painting of widgets, forms etc.

I believe what you are referring to is the following: fpGUI, just like LCL, can also supply a painting canvas to libraries like Cairo, OpenGL, SDL etc to draw onto. This is currently possible without difficulty. In fact, I have already seen a few fpGUI apps using Cairo and SDL canvas's to do some painting - the main app is standard fpGUI widgets using X11 or GDI, and then some window or widget contains the Cairo or SDL painting output.

What is the difference between using fpGUI with SDL and Lazarus with SDL?

No difference.

Does the fpGUI + SDL create smaller binaries (on linux) versus Lazarus + SDL? Or are the other pros and cons?

Overall fpGUI application do have smaller binaries than Lazarus apps, irrespective if they use SDL or not.

Regards,
- Graeme -

I'm working from memory here, and it was a few years ago so I guess I knew even less than I do now :-)

The problem was that I was having to graft something onto a stable server with a slightly-older version of kernel, libraries and so on than the app's developers had used. ./configure failed and I ended up having to install some graphical middleware (I forget the exact detail) which then announced it didn't like the version of TrueType on the system. I installed a private TrueType specifically for that app, and that expressed a strong preference for some fundamental library upgrades.

I've had comparable problems when trying to build Mozilla derivatives (e.g. SeaMonkey): fortunately this wasn't critical but I got the impression that the only way to do it was to start off with the same distro and version that the developers were using, at least as a reference system.

All of that is something which a developer familiar with the platform and libraries should be able to work around fairly easily. But in my opinion if part of the idea of fpGUI is to have a version of the LCL which will run on almost anything without preconditions then eliminating as much "middleware" as possible would be a worthwhile exercise.

After all, the purpose of installing Lazarus is to be able to use it to write application programs, not as an exercise in tweaking low-level libraries and symlinks.

Michael Van Canneyt wrote

I think it makes more sense to skip SDL and directly use the linux framebuffer.

Someone might want to use SDL controls together with Lazarus generated controls.

A friend of mine did this (using Delphi and later - as he did not get it working with Lazarus for Linux) with Python. to create a graphical editor that does graphic-card processor supported zoom and pan.

-Michael

No. I think you misunderstand what Darius has done.

Michael.

Darius Blaszyk wrote

This is also the reason why I started on a GLut/OpenGL backend for fpGUI. In the last weeks it has reached a point that some examples already work perfectly.

So can we expect to - finally - see a lot new and fully functional (form designer and support for TTimer, inter-Thread messages, etc) "Widget.-Types" in Lazarus (hopefully with support for all platforms (OS and CPU) ) such as fpGUI, GLut/OpenGL, "active NoGui", etc (and dreaming of remote GUIs such as HTTP/HTML (e.g. ExtJS based ("Ext-Pascal improvement") or with a dedicated TCP/IP connected "Lazarus Remote Control" program) ?

Does the current "Widget Set" code infrastructure really allow for this without a major overhaul ?

-Michael

I added a new backend to fpGUI not to lazarus.

Darius Blaszyk wrote

I added a new backend to fpGUI not to lazarus.

I see. Thanks for the clarification. Unfortunately a full integration for fpGUI into Lazarus seems like a not easy task, so the other possible "Widget types" I mentioned can't benefit from this :( .

-Michael

Is that so? I always thought it was a matter of resources.

D

At which point presumably his code was- eventually- using something like Linux DRI/DRM, which is only implemented for a comparatively small number of graphics processors and which typically has additional restrictions e.g. some minimum amount of on-card RAM. This is getting a very long way from something which is guaranteed to run on almost any system with minimal prerequisites.

Darius Blaszyk wrote

Is that so? I always thought it was a matter of resources.

Yep. I feel that a major consolidation of the many incarnations of the Widget Type code is essential to enable the (then hopefully a lot easier) creation of more Widget Types like fully integrated FPGUI (including different Widget Types for it regarding the different possible low level interfaces) and the other ones I mentioned.

This of course is a major problem of human resources, as the quite complex work not only needs to be done, but a lot of testing is necessary to ensure that this does not introduce new bugs in currently quite nicely working functions.

-Michael

Nope, he used standard (JEDI-) SDL functions lite stretchblit() os similar. Same should always be available and executed by the hardware if available (supposedly always with PC-graphic cards) or implemented somewhere in the driver code if not supported by the hardware.

-Michael

Op 2011-01-10 13:12, Michael Schnell het geskryf:

I see. Thanks for the clarification. Unfortunately a full integration for fpGUI into Lazarus seems like a not easy task,

On the contrary, I think implementing LCL-fpGUI widgetset in Lazarus would be the easiest widgetset from the lot (WinAPI, GTK, Qt, Carbon etc). Simply because fpGUI is written in Object Pascal too, so you have the same types, RTL classes, streaming system etc... Plus, bugfixes can be applied to both projects (fpGUI and LCL) at the same time, and instantly have the fixes available in LCL-fpGUI at the next time you compile your project.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I think implementing LCL-fpGUI widgetset in Lazarus would be the easiest widgetset from the lot

Yep, but the API between the no-Widget-Type depending LCL parts and the Widget set seems quite complex (using some kind of registration for the available classes of controls etc) and the parts that are necessary to be implemented for all Widget types (i. e the event queue and the interface to same for non-widget-set depending stuff (TTimer, inter Process Messaging, you name it) ) is currently not centralized, but needs to be re-implemented with each new widget type.

The form designer supposedly would need to use the "design mediator" API.

-Michael

I'll repeat that again:
The "design mediator" API is only needed when one wants to design pure non-LCL fpGUI applications. For LCL-fpGUI the "normal" LCL designer is used.

Regards,
Sven

Op 2011-01-10 13:57, Michael Schnell het geskryf:

Yep, but the API between the no-Widget-Type depending LCL parts and the Widget set seems quite complex

Well that is all LCL internal design stuff and nothing related to fpGUI. But yes, the LCL internals are rather daunting when you haven't worked on it before. What is annoying though is the Windows-ism design in the LCL. LCL works on many platforms, but it is clearly biased towards Windows design. This is quite odd, seeing that Windows wasn't even the first widgetset LCL supported (I believe it was GTK1 first).

The form designer supposedly would need to use the "design mediator" API.

No, that is incorrect. If your application is LCL-fpGUI based (meaning any one of the widgetsets included with LCL), the Lazarus form designer works as-is, no matter which LCL widgetset you use.

Regards,
- Graeme -

2011/1/10 Graeme Geldenhuys :

It is not so odd, if you remember that the LCL was modeled after the VCL, which has even more 'Windows-ism's.

Vincent

Getting some controls to a more or less working condition will not be difficult. But going the full 100%, this is another task.

And I believe the latter is precisely the reason you abandoned LCL to start on fpGUI: the fact that each widgetset is never 100% on par with the others.

When making LCL-fpgui widgets, we'll then be full circle, back on square 1, with another LCL widgetset almost-but-not-quite finished.

Michael.

Op 2011-01-10 14:30, Vincent Snijders het geskryf:

It is not so odd, if you remember that the LCL was modeled after the VCL, which has even more 'Windows-ism's.

Yes I understand the attraction towards VCL, but having the Windows API (as an example) cloned for every widgetset of every platform is a bit overboard I think. Just take a look at the <widgetset>winapih.inc files to see what I mean. Windows API methods, Windows types used etc. must now all be converted to individual widgetset or cross-platform types for EVERY widgetset LCL supports. Even the name of that unit says it all. Why must LCL's GTK, Qt, fpGUI, Carbon widget sets know what ReleaseDC() method means or know about types like HGDIObj or HWND etc? I'm sorry, but speaking as somebody that has cross-platform widgetset experience, LCL uses a terrible design.

If somebody wants to implement a "true" cross-platform application (and seeing that that is what LCL was designed for), developers should fix their source code by not calling a specific platforms API. Instead they should use some cross-platform alternatives, implemented by the LCL.

Regards,
- Graeme -

Op 2011-01-10 14:34, michael het geskryf:

Getting some controls to a more or less working condition will not be difficult.

This is the point I was trying to make.

But going the full 100%, this is another task. And I believe the latter is precisely the reason you abandoned LCL

Exactly. But seeing that currently there are no two widgetsets in LCL (after 10+ years) that are 100% compatible with each other, why try and make LCL-fpGUI live up to that "impossible to reach" goal?

It seems everybody here settled on the "more or less compatible" as being good enough. And that goal should be easier to reach (more so that the existing widgetsets) with LCL-fpGUI.

Regards,
- Graeme -

Of course; but is this not what is needed to have an fpGUI widget Type fully integrated in Lazarus, working at design time in the same way as e.g. the gtk2 Widget Type works ?

-Michael

Graeme Geldenhuys wrote

No, that is incorrect.

Sorry for bothering you. I hope I can discuss on a more competent level when I am able to try things out before chatting.

-Michael

This is not correct. People do strive to "100% the same everywhere". But the "100% the same working on all platforms" is hard to reach, and takes time, it is an ambitious target. Rome also wasn't built on a day.

Just like fpGUI is an ambitious target in it's own right, which by itself is also far from finished.

Michael.

On 01/10/2011 01:59 PM, Graeme Geldenhuys wrote:having the Windows API

(as an example) cloned for every widgetset of every platform is a bit overboard I think.

Building a propriety, commonly agreed, and decently documented "Object Pascal" layer in between would be a much more "professional" design. Same would offer the appropriate APIs (GUI and non-GUI stuff) to the application program and use APIs of "Widget Type" implementations (done in a structured way: commonly usable functions done in central places) and (maybe separately implemented, but supposedly necessarily cross-linked) "NonGuiStuff" implementations (such as Event Queues for Timers and InterThread Communication).

But this is just a dream, I don't thinks anybody will feel like starting this huge and dangerous redesign work.

-Michael

Op 2011-01-10 15:18, Michael Schnell het geskryf:

Of course; but is this not what is needed to have an fpGUI widget Type fully integrated in Lazarus, working at design time in the same way as e.g. the gtk2 Widget Type works ?

No, it's not needed - just like there are no "design mediator API" implementation for any of the other LCL widgetsets either. The form designer built into Lazarus IDE is fully implemented in the IDE itself using common LCL code.

Regards,
- Graeme -

Op 2011-01-10 15:20, het geskryf:

Rome also wasn't built on a day.

Do we know this for certain? I'm pretty sure aliens built the pyramids in one day using that "beam me up Scotty" technology, so they might have done the same for Rome. ;-)

Back to the point - I understand what you mean: It's almost there, but never really there.

Regards,
- Graeme -

Graeme Geldenhuys wrote

No, it's not needed - just like there are no "design mediator API" implementation for any of the other LCL widgetsets either.

Of course, This was my first idea, but I felt, that doing a full completely "compatible" Widget Type" that allows for the "standard" GUI designer to work for fpGUI applications would be a too complex task.

-Michael

I don't think that "100% the same everywhere" is possible or even desirable. Take a look at Java SWT. It certainly has a much much bigger amount of contributors than Lazarus, being THE backend behind Eclipse. Yet it doesn't have half of the features the LCL has (hell, it's really a pain doing a serious GUI with it). But even though they limit the available widgets, it is STILL not completely identical across all the three supported platforms.

Another point being: is it really THAT important to have it 100% the same? A UI that is great on Windows will probably suck in MacOS X. Why? Because they have other design guidelines. Sure, it's easier to ship out one and the same for all, but I think serious UIs are better designed for a specific market, and not run-of-the-mill. That of course also depends on the use case. So I think it's fine that there is a choice: specialized GUI (frameworks) on the one side, fpGUI on the other side, and the LCL in between.

Raving on...

IMHO, in a perfect world the API between the GUI-generating part of the said "Object Pascal" layer (bad name ;-) ) and the Widget Set depending part of the "Widget Type" code, would be a just bi-directional stream of propriety codes (see Martin's "ifi" project). This would make remoting the GUI very easy and would allow for doing the Widget Set depending code in a different language (e.g. in Java to do the GUI in a browser or for Android) or in CIL-Pascal (Delphi-Prism) to reuse some of the Lazarus code doing the GUI in a browser via Silverlight/Moonlight).

Maybe this might cost some performance (but OTOH, the transaction count on this interface is not that high), but I feel it's worth considering to make Lazarus a lot more usable for a wide range of applications.

-Michael

On 01/05/2011 11:39 PM, Graeme Geldenhuys wrote:In addition to nano-X you might want to take a look at Wayland, too:
http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29

-Michael

Op 2011-01-11 12:19, Michael Schnell het geskryf:

On 01/05/2011 11:39 PM, Graeme Geldenhuys wrote: In addition to nano-X you might want to take a look at Wayland, too: http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29

I'm looking forward to testing Wayland (apparently Ubuntu might switch to it in a few years). I have high hopes for it - like real performance improvements to bring the graphics system on par with everybody else, like Mac and Windows systems (even a small OS like Haiku has better GUI performance than Linux). As far as I'm concerned, Linux GUI is still stuck in 1980's, as far as graphics goes. Wayland might just be the push that Linux needs.

Regards,
- Graeme -

Graeme Geldenhuys wrote

... like Mac ...

Interesting ! Does Mac not use X ? What do they use ?

Android does not use X, but (what ???)

-Michael

Op 2011-01-11 13:41, Michael Schnell het geskryf:

On 01/11/2011 12:23 PM, Graeme Geldenhuys wrote: > ... like Mac ... Interesting ! Does Mac not use X ? What do they use ?

They have their own proprietary windowing server called Quartz or something like that. OS X does ship with X11 support though, so you can run X11 apps (like fpGUI ones) on it.

Android does not use X, but (what ???)

I don't know the Android ,
- Graeme -

Graeme Geldenhuys wrote

> Android does not use X, but (what ???) I don't know the Android platform at all.

It seems to be called "SurfaceFinger"

-Michael

Op 2011-01-09 20:24, Hans-Peter Diettrich het geskryf:

Where do you see problems?

....

The determination of a closer target (e.g. control) is up to the application or library, that manages the layout of a window. Every application or library can freely define their own "handles" for every

Try and implement your own GUI toolkit, and we talk again.

Just some (not all) of the problems Qt had to overcome are as follows:

* XDND protocol requires mouse enter, exit and window properties to correctly get a source or target of a drag action. X11 Window handles are required for this.

* Windows OLE drag-n-drop protocol requires window handles for each window or widget that can do DND.

* Window clipping must now be handled by Qt itself.

* Window clipping between non-handle windows and handle-windows. eg: The form has a handle, but all normal widgets on that form have no handles. Now through in a OpenGL widget which must have a window handle. Now you have widgets on the form that has handles, and some that don't. Now apply all the previous items listed to the mix.

Qt managed to do all this and more, without breaking existing applications and code! That is pretty incredible.

So from a Qt end-users point of view, it is business as normal. But internally, Qt has changed dramatically from a design where you had a window handle per widget, to a single window handle per Form. Hats off to them for pulling it off without a hitch. And they didn't even bump up the major version for this change, they simply went from 4.3 to 4.4 [those cocky bastards :-)]

Regards,
- Graeme -

What tools do you have in mind? One of my first GUI libraries implemented Windows-compatible widgets on the Atari ST, during the beta test of Turbo-C for ST.

Just some (not all) of the problems Qt had to overcome are as follows:

Can you be a bit more specific with your examples? IMO you confuse inter-process and cross-process operations.

As mentioned above, *every* dragmanager must have handles for all involved components. An OS-wide dragmanager can only use OS-wide handles, e.g. those of the OS-wide window manager.

Dunno about XDND, but sounds to be out-of-process as well.

* Window clipping must now be handled by Qt itself.

In which context? During painting it depends on the screen graphics library, whether the canvas implements some clipping, or allows to write on the entire screen.

I don't see the consequences. Controls with an OS-wide window handle are known to the window manager, others are not.

DoDi

Lets take Windows OLE drag-n-drop protocol as an example. It needs the window handle of the component (eg: TEdit) that can accept a drop. Irrespective if it is a drag-from-component-to-component-inside-same-app or a drag and drop from one app to another. In Qt 4.4 and later, such an Edit component doesn't have a windows handle any more, so OLE can't talk to that Edit component. The only OS window handle is the top-level form. Trolltech had to implement some serious black magic in Qt to still work with OLE DND - yet no difference to the end-user. This is what I'm so impressed with, and have no real clue how they accomplished that (yet).

XDND protocol works very different to Windows OLE DND, but still X11 window handles are required for the component which is the source or target of a drag-n-drop action, including the top-level window handle so as to communicate with the other app or component.

And when I say drag-n-drop, I mean full DND support. In app drag-and-drop (component to component in same app) and application to application. XDND even allows computer-to-computer DND.

The DND support Delphi has in the VCL is a joke, and hardly what I would call real drag-n-drop. It's just one component inside the same app sending a message (or executing an event) on another component in that same app. Any app-to-app DND, and you are on your own (outside the scope of the VCL), and you have to resort to Win API calls or implement your own full OLE DND implementation.

In which context? During painting it depends on the screen graphics library, whether the canvas implements some clipping, or allows to write on the entire screen.

Please reread the blog posting on Nokia's site. They explain it there. I posted the URL earlier.

So what? If somebody *wants* to allow OLE drag-drop for a component, he must choose an appropriate one (here one with a HWND, or some other OLE/COM object).

If you want such dragging for a single pixel, you must wrap that pixel into an container that supports dragging. Drag-drop does not come at zero cost.

I cannot see any black magic here, even if it may sound like that to marketing people. When the OLE dragmanager needs a HWND, for sending messages to a source or target, any such HWND is sufficient. The receiver of the message can determine a more specific source or target at will, i.e. allow for an drop inside a window only, when the coordinates match a specific control inside that window. The Lazarus dragmanager does this already.

If nothing helps, the application can create a temporary invisible window, or any other applicable OLE object, on top of the target control. This object then can be moved to every possible target control, that resides at the current mouse position. But this is not a necessary requirement at all, when the screen position of the target area is explicitly stored in the OLE object. There exist more components, like timers, that have no visual representation at all, but have a HWND for communication purposes.

XDND protocol works very different to Windows OLE DND, but still X11 window handles are required for the component which is the source or target of a drag-n-drop action, including the top-level window handle so as to communicate with the other app or component.

So that's not really different from any other (Windows...) d&d.

And when I say drag-n-drop, I mean full DND support. In app drag-and-drop (component to component in same app) and application to application. XDND even allows computer-to-computer DND.

What does dropping mean other than a notification (message...) to the target (handle), that a source (handle) has been dropped onto it?

The DND support Delphi has in the VCL is a joke, and hardly what I would call real drag-n-drop. It's just one component inside the same app sending a message (or executing an event) on another component in that same app.

Sorry, that's nonsense :-(

You should understand VCL/LCL dragging first, before you make wrong assumptions about different operation and requirements of other drag managers.

It were no problem to extend the LCL dragmanager to inter-process dragging. But since there must exist conventions, how a target window of *any* application will signal acceptance of an possible drop, and will handle the drop, and will handle the dropped source (residing in another process), it's a much better idea to use the existing OLE d&d conventions for *that* purpose.

You also should understand that Delphi d&d is not limited to source controls (Lazarus missed that aspect a bit), so that the TDragObject is equivalent to an OLEDragObject, only with an different set of methods and properties.

Any app-to-app DND, and you are on your own (outside the scope of the VCL), and you have to resort to Win API calls or implement your own full OLE DND implementation.

Right, because a process needs some OS support, for communication with other processes. That's nothing new, isn't it?

And when OLE d&d requires HWNDs, that's a justficiation for another LCL d&d, that comes without such heavy requirements.

DoDi

Lets agree to disagree, otherwise this back-and-forth messaging will go on forever.

Regards,
- Graeme -