Now we have the LCLWidgetType CustomDrawn.
Can anybody tell me the differences vs the LCLWidgetType fpGUI ?

Why do we have a new LCLWidgetType that on the first sight seem to target the same result as the existing one ?

(BTW. Right now I can't compile my testing project with either of same.)

Custom drawn:
/home/mschnell/Downloads/svn/lazarus/trunk/lcl/interfaces/customdrawn/customdrawnproc.pas(160,37) Error: identifier idents no member "HasNoImage"

fpGUI:
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/bin/ld:
/home/mschnell/Downloads/svn/lazarus/trunk/lcl/units/i386-linux/fpgui/fpg_x11.o: undefined reference to symbol 'FcFontSetDestroy'
/usr/bin/ld: note: 'FcFontSetDestroy' is defined in DSO /usr/lib/libfontconfig.so.1 so try adding it to the linker command line /usr/lib/libfontconfig.so.1: could not read symbols: Invalid operation eventtest.lpr(20,1) Error: Error while linking

-Michael

Michael Schnell wrote

Can anybody tell me the differences vs the LCLWidgetType fpGUI ? Why do we have a new LCLWidgetType that on the first sight seem to target the same result as the existing one ?

http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface#Comparison_of_LCL-CustomDrawn_and_LCL-fpGUI

Custom drawn: /home/mschnell/Downloads/svn/lazarus/trunk/lcl/interfaces/customdrawn/customdrawnproc.pas(160,37) Error: identifier idents no member "HasNoImage"

Try again in rev 33888

Felipe Monteiro de Carvalho wrote

http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface#Comparison_of_LCL-CustomDrawn_and_LCL-fpGUI

I see. Thanks for the pointer.

Try again in rev 33888

Now it does compile.

When running my testing project I get a SigSegV when in customdrawnwsforms_x11.inc line 7644 "createHandle" is called the fourth time.

-Michel

Felipe Monteiro de Carvalho wrote

http://wiki.lazarus.freepascal.org/Custom_Drawn_Interface#Comparison_of_LCL-CustomDrawn_and_LCL-fpGUI

The main Build Mode variable setting seems to be "LCLWidgetType = customdrawn".

(Why) Can't I select a "CustomDrawnPlatform" (or "CustomDrwanBackend) Build Mode variable to denote which of the available Backends the application is to be built for ?

In my test on an Linux PC it seems to be built for X11 (regarding the name of the inc files the code reaches when singlestepping).

-Michael

Michael Schnell wrote

When running my testing project I get a SigSegV when in customdrawnwsforms_x11.inc line 7644 "createHandle" is called the fourth time.

Does your test project use only already implemented widgets? See:

http://wiki.lazarus.freepascal.org/Roadmap#Status_of_native_controls_on_each_widgetset

At the moment this means only TButton, TArrow and TProgressBar

As I am myself I obviously need to ask these questions:

- To me it looks like "CustomDrwan" can't be sure that any back ent it is made for provides an event queue. So it supposedly needs to create an event queue in the LCL code. Here of course the main thread needs do so a non-busy wait for incoming events using the underlying OS API. Correct ?

- As the purpose of CustomDrawn seems to be an interface between the normal LCL stuff and the Backend-depending functions that is as simple as possible so that new Backends can easily be attached, I suppose it would be very viable to create Backends like:
- "noGUI" (the drawing functions are strictly dummy doing nothing)
- "ifi" (the backend is attached via a bidirectional byte stream such as a pipe, a socket or an asynchronous port.
- http (the backend is done in java script and runs in a browser, the connection is done using the http protocol <see ExtPascal / ExtJS>)

-Michael

Michael Schnell wrote

?- To me it looks like "CustomDrwan" can't be sure that any back ent it is made for provides an event queue. So it supposedly needs to create an event queue in the LCL code. Here of course the main thread needs do so a non-busy wait for incoming events using the underlying OS API. Correct ?

I think that the 5 or so APIs from the LCL that deal with lower level events (PostMessage, QueueAssyncCall, SendMessage, etc) could be implement with a timer and an event queue.

The rest of the LCL does not require direct interaction with an event queue, it can also work through direct events from the OS.

?- "ifi" (the backend is attached via a bidirectional byte stream such as a pipe, a socket or an asynchronous port.

LCL-Android worked like that, attached via pipes to the Java side. It actually worked OK.

?- http (the backend is done in java script and runs in a browser, the connection is done using the http protocol <see ExtPascal / ExtJS>)

I think that it would work badly due to latency and it would load a lot the server. LCL-CustomDrawn is based on sending the entire image of the application. If such a thing was really viable I think there would be a lot of people doing that way, but I don't know anyone which went for that solution.

A specialized LCL interface written for web apps (not based on LCL-CustomDrawn) could work for normal GUIs with simple buttons and other controls without fast animations, but the biggest web app that I am developing is a game with animations, so here to me it seams that there was no really good way of integrating the LCL into the web app so I just gave up on that and went for fcl-web with CGI.

I don't think that this needs to be be implemented "on top" of TTimer. But in fact (if the "GUI-backend" does not provide this function) TTimer does need a queue that uses OS-based non-busy waiting at the output of the queue and an OS-based way to generate the time-based (thus asynchronous) events as an input into the queue. The asynchronous Mainthread Signaling features need the same stuff, only that the input into the queue is generated by a thread. (In fact TTimer can be implemented using a thread that performs an OS-API "sleep" and when woken generates an input into the queue and goes back to sleep again.)

This is rather easy to do. The tricky thing is merging the events that are generated by the GUI background with those that are generated by threads (or other directly OS-API based function).

> - "ifi" (the backend is attached via a bidirectional byte stream such as a > pipe, a socket or an asynchronous port. LCL-Android worked like that, attached via pipes to the Java side. It actually worked OK.

Great !

So I vote for doing an class-inheritance based or otherwise flexible implementation that allows for switching the actual transport when adding new backend variants (such as "none" "pipe", "IP-socket" or "asynchronous".

> - http (the backend is done in java script and runs in a browser, the > connection is done using the http protocol<see ExtPascal / ExtJS>) I think that it would work badly due to latency and it would load a lot the server.

Of course you are right that this is a performance hog. "FastCGI" and (on Microsoft IIS) ISAPI will need to be used. "Comet" could reduce the polling overhead (for server->Browser events) but I heard that it is not very reliable. OTHO AFAIK there are several working (non Pascal) projects using EXTJS. So I suppose this should be doable. Obviously this is a lot of work and the look and feel will be very different vs a standard LCL GUI. But in the past, here, there have been a lot requests for CGI programs with an LCL based GUI in the Browser.

-Michael

Out of curiosity: Is there a specific reason why you use past tense?

Regards,
Sven

Sven Barth wrote

Out of curiosity: Is there a specific reason why you use past tense?

http://www.lazarus.freepascal.org/index.php/topic,15392.html

Ah, ok. Thank you.

Regards,
Sven