Hi Lazarus wizards and magicians,

I'm trying to figure how to face my nonlcl widgetset project. Before tampering with Lazarus code, I tried to gain a better understanding. My scenario:

* a run-time package containing my non lcl widgets. Units are named after Kylix naming scheme, i.e. QForms, QButtons, etc.
* a run-time package containing units lifted from Lazarus LCLBase and LazUtils to provide the required run-time functionalities without pulling in LCL (lresources, fileutils, etc.)

With a minimal patch to lresources, in order to skip properties pulled in by Lazarus and unsupported by my widgets, I can compile an application using my widgets, run and debug it.

If I try to access to a method already present in the lfm from the Object Inspector, I can see the available methods, and jump to the unit code.
But if I attempt to add something, such as an OnClick Event to a button from the Object Inspector, I get the error "Unable to create new method", and the reason given is:

Codetools, Errors:1
unit1.pas Error: unit not found StdCtrls

Of course my package doesn't have a StdCtrls unit, which would clash with Lazarus, but has a QStdCtrls unit.
Now my question is: where does Codetools find the need for a specific unit? I gather that class, property, etc. names are loaded into the global LazarusResources list, but this involves also unit names? In order to support a nonlcl widgetset to what extent one should reinvent Codetools in his Mediator?

Giuliano

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

ok.

Yes. In this case the IDE uses only the names to find the methods.

The IDE searches the declaration of TButton.OnClick. The TButton was registered from the LCL unit StdCtrls. That's why TButton.UnitName is 'stdctrls'. The IDE searches the unit in the project path and cannot find it.

Note: Codetools is a package for searching and editing Free Pascal sources. You don't need to reinvent Codetools. The problem is the IDE (i.e. form editor, designer) that drives Codetools. The IDE needs to be extended to solve the name clashes.

There are at least two possible solutions:

1. The quick and dirty solution:
You use the LCL forms and controls. The IDE is extended with some hooks, so you can redirect from the LCL to your units. Pro: Less work, you get some basic results quickly. Con: The RTTI is wrong. The Object Inspector cannot show your own properties. The property editors will show LCL values (e.g. TColor will show the list of LCL color constants). Icon and bitmap data are read/written in LCL format, which may be unreadable by your units. etc.

2. The clean solution:
You write your own mediator component classes. For example a TButton, TForm, TPanel, TListBox, etc.
Con: the IDE needs to be extended to handle multiple component classes with the same name (only one is active at a time, based on the project). You have to write painting code for the mediator TButton, TPanel, TListBox, etc.
Pro: the RTTI is correct and so the Form/Source relation works, the Object Inspector shows all your properties and only your properties and you have full control. You can write good property and component editors.

Mattias

Il 21/06/2014 17:18, Mattias Gaertner ha scritto:

I'm not too much interested in a quick and dirty solution, unless it can be a first step, just to gain a better understanding of all the internals wizardries.

That's the way I'd like to go. A more general support of non-LCL widgetsets would be a not only a good long term solution for my project, which in my ambitions would be not just to support Kylix legacy but to rewrite step by step all widgets thus getting free of license issues. More important, it could be useful to the Lazarus project as a whole. It could be used to revive the pretty much dead CustomDrawn project, it could provide a better way to support FPGui, etc. It's quite likely that in any widgetset one can conceive, a form will have a TForm class, a button a TButton class, etc.

My problem, right now is: where do I start from? Which units should I start looking at?

Currently, if I understand properly, everything is set up in main.pp. Then, when loading a project, palette visual components without an editor hook are only hidden, but nothing is removed from LazarusResources. It's unclear to me to what extent LCL related resources should be kept there when handling non-lcl widgets. In principle I see many possibilities:
1) Splitting LazarusResources in more pieces: GlobalLazarusResources (from non widgetset related packages), LCLLazarusResources (IDE-required, if any) and WSLazarusResources (specific Widgetset resources).
2) Adding and removing entries from LazarusResources as a function of each individual project package dependency.
3) Adding an extra entry to each resource, to specify to which category it belongs (Global, LCL, nln-LCL).
But without a better knowledge of what is using what it's impossible to make a choice.

Thank for any suggestion.

Giuliano

True.

LazarusResources is only about LCL resources, which is here the lfm format and some utility functions for the dfm format. You don't need to change that.
Other resources must be implemented in your designtime package and registered via the IDEIntf unit UnitResources. That was started by the iphonelaz package, which uses another format.

The IDE uses the TReader/TWriter of the FCL for streaming components. For the IDE there are two types of component classes:

1. Root components are descendants from TForm, TDataModule, TFrame and can hold user methods and variables. They are created completely from scratch. That means a new class is created at runtime and an instance. When the resource is read by TReader the IDE creates methods and child components on the fly. Here the IDE needs to be extended to handle multiple base classes with the same name.
The IDE needs a simple way to decide which TForm to use. A good solution would be the resource file extension.

2. When TReader wants to create a child component 'Button1: TButton' it needs a component class 'TButton'.
All component classes are registered via
RegisterComponents, which is in Classes and that
does not support duplicates. Maybe a RegisterComponents can be added to the TUnitResourcefileFormat.

I have to write an example and check things to tell what exactly needs to be changed.

Mattias

Il 22/06/2014 15:06, Mattias Gaertner ha scritto:
[...]

Meaning that an appropriate IDE extension, and a TReader/TWwriter extension, would one day permit to stream FpGui components which are found not in a separate resource file, but in the source code itself? [...]

I have to write an example and check things to tell what exactly needs to be changed.

It would be great. In the meantime I'll try to get acquainted with that matter which has always been just a black box to me.

Thank for your time,

Giuliano

Yes.

Mattias

Giuliano Colla wrote

I'm trying to figure how to face my nonlcl widgetset project.

I don't understand what you mean by " nonlcl widgetset project".

In fact I already do have a working draft of my "ActiveNoGUI" Widget Type Project.

Here the goal is to provide another "Widget Type", That is the name of the compile Variable that Lazarus uses for telling multiple "interfaces" from each other, and which can be set in the Lazarus Project options.

Lazarus already understands multiple values for this Variable (e.g. gtk, gtk2, qt, win32, wince fpgui, nogio carbon, cocoa, customdrawn, and gtk3).

ActiveNoGUI is supposed to run on Linux and on top of "nogui" provide stuff like TThread.Synchronize, TThread.Queue and TTimer.

As said, a testing project already works (on Linux x86-32), bus supposedly needs some enhancement to be really acceptable.

And after that it of course needs some effort to integrate it with Lazarus in a decent way (decent makeup, have Lazarus set the WigetType variable, have Lazarus create a "New Active NoGUI Application").

Is this somehow related ?

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

For an upcoming ActiveNoGUI Widget Type would it be appropriate (and easy to do) to use such mechanism to allow a user to use the Lazarus GUI designer to place pseudo-visual Objects such as TTimers on a (pseudo-) Form just to free him from creating such things in code ?

-Michael

You mean on a DataModule? I don't really understand the question...

On 06/21/2014 12:43 PM, Giuliano Colla wrote: > I'm trying to figure how to face my nonlcl widgetset project. I don't understand what you mean by " nonlcl widgetset project".

This is definitely one of your worst hijacking.

Mattias

What do you mean with pseudo form?

Mattias

Mattias Gaertner wrote

This is definitely one of your worst hijacking.

Sorry this was not my intention (but just trying to be helpful). :-(

Am I wrong understanding that this thread is about creating a new Widget Type (or something with a similar target) for Lazarus that does not use most of the Widgets the LCL provides (and hence a similar issue), even though the OP does not seem to know the term and the working of the LCL Widget Type setting ?

-Michael

Reinier Olislagers wrote

You mean on a DataModule? I don't really understand the question...

(@Mattias: sorry if this is off-topic here.)

Imagine a new Widget Type (and "Application") that does not provide any GUI but (other than the current not GUI based Lazarus Application types) allows for TTimer (and other Event Queue based stuff).

When doing "New Application", the Lazarus IDE automatically creates code that provides a main Form (TForm sibling) for the user code, and the GUI designer allows to place visual components, that behave appropriately as well in the GUI designer as in the running application.

When the user wants to use a TTimer, he usually simply "drops" one on this Form.

Of course a running "Active NoGui" application does not show any Form (and does not have runtime code to do so).

Nonetheless it could be doable to have it provide the design-Time functionality to allow for showing some kind of "Main Form" in the IDE and allow for placing (e.g.) TTimers there. The (non visual) properties of these components would need to be streamed from the Resource as usual when the program starts. Otherwise the user needs to "manually" create such timers e.g. in "TForm0.DoCreate" - this is how my current testing state works.

-Michael

Yes, what about a DataModule? Or, for that matter, a regular form. Just make sure your widgetset does not try to create a graphical form on the screen. I suppose that is how the current NoGUI widgetset does it?

On 06/23/2014 10:48 AM, Mattias Gaertner wrote: > This is definitely one of your worst hijacking. Sorry this was not my intention (but just trying to be helpful). :-(

You replied to a mail, in which Giuliano clearly explained, that he works on a LCL incompatible GUI. You instead promoted a LCL compatible non GUI. That is stupid, ignorant and offending.

Mattias

[...] Imagine a new Widget Type (and "Application") that does not provide any GUI but (other than the current not GUI based Lazarus Application types) allows for TTimer (and other Event Queue based stuff).

Why not put this in the existing nogui widgetset? What is the overhead?

Mattias

Yes.
You can use TDataModule with nogui widgetset.
You can put TTimer on a DataModule, but TTimer is not implemented in nogui.
If you implement the TTimer backend, then it will work.

Mattias

Il 23/06/2014 10:56, Michael Schnell ha scritto:

No, this is about creating new Widget Types which don't use *any* of the widgets LCL provides.
In short, LCL philosophy is to have a High Level WS, (LCL) whose implementation part is demanded to some third party Widgetset (such as gtk, qt, Windows, etc.), via an Interfaces unit.
This is not compatible with other implementations, such as Kylix and fgGui, just to mention two.

Giuliano

Reinier Olislagers wrote

Yes, what about a DataModule?

Of course a DataModule would do. But here I would need to make the IDE automatically create a DataMoule as a would-be "MainForm". No Idea if this is possible/sensible/appropriate.

I suppose that is how the current NoGUI widgetset does it?

I'll take a look.

-Michael

Mattias Gaertner wrote

If you implement the TTimer backend, then it will work.

I suppose additionally to the run-time code for TTimer I would need some design-time code (or at lease "parameters") and appropriate streaming code for my new TTimer class.

-Michael

You can register a new project type that does that.

Mattias

Resources are stored by the compiler, streaming is implemented in the unit Classes and the LCL TDataModule. So your nogui widgetset has that already.

Mattias

Mattias Gaertner wrote

Why not put this in the existing nogui widgetset?

Maybe his in fact is a good idea.

I did not dare to suggest this, because I always in great fear to break something, as I am not at all an expert with the Lazarus / LCL internals.

What is the overhead?

- it forces to link in part of the TTimer code and part of EpikTimer, and the EventQueue code (CheckSynchronize and friends) provided by the fpc RTL
- at program start it initializes the TTimer infrastructure (using part of a modified implementation of EpikTimer, e.g. calculating the TimeBase clock frequency)
- at runtime, in "Application.Run", it reeds hardware ticks, checks if any timers are expired and calls CheckSynchronize (from the fpc rtl).

-Michael

Mattias Gaertner wrote

What do you mean with pseudo form?

A thingy supposedly working like TDataModule, that the IDE is able to use as MainForm.

-Michael

Mattias Gaertner wrote

So your nogui widgetset has that already.

I'll take a look...

-Michael

Mattias Gaertner wrote

You can register a new project type that does that.

I'll try to fond out how to do that.

(That means that the "Widget Type" (i.e. the code that is $ifdef'ed by the appropriate setting of the WidgetType variable) and the IDE code itself does not need to know details about this ?)

-Michael

Mattias Gaertner wrote

You instead promoted a LCL compatible non GUI.

I did not want to promote anything, but just to check if something I already have could help or if I might benefit from something that might be the outcome of this project.

-Michael

On 06/23/2014 10:54 AM, Mattias Gaertner wrote: > What do you mean with pseudo form? A thingy supposedly working like TDataModule, that the IDE is able to use as MainForm.

The MainForm must be a TForm.
Why does a program without GUI need a form?

The purpose of the nogui widgetset is to easily run an existing GUI application without GUI. If you start a new project, you should not use it. You blow up your program without need.

Mattias

[...] - it forces to link in part of the TTimer code and part of EpikTimer, and the EventQueue code (CheckSynchronize and friends) provided by the fpc RTL

The nogui widgetset already calls CheckSynchronize.

Are you sure you need Epiktimer and hardware ticks for TTimer? That sounds like overkill.

Mattias

Giuliano Colla wrote

No, this is about creating new Widget Types which don't use *any* of the widgets LCL provides.

This is rather exactly the same with my current project (only that there will not be any widgets in runtime at all either).

I understand that "customdrawn" is on a similar trail (regarding runtime, Kylix and fpGUI provide their own GUI designer tools, though). [ To me customdrawn seems the most promising of the three mentioned. ]

Does you project already have a working (runtime) implementation of an Event Queue and of TTimer ?

-Michael

Streaming TComponents is independent of GUI and works with the FCL alone.
The LCLBase provides some utility functions and an UTF-8 format (lfm) with nicer error handling. That is all independent of the widgettype.

Mattias

Mattias Gaertner wrote

Why does a program without GUI need a form?

Just as a curtsey to the users.

Of course at runtime it does not need a form.

But at design time Lazarus Users are accustomed to place TTimers on a (would-be) Form instead of creating them in code.

-Michael

Mattias Gaertner wrote

The LCLBase provides some utility functions and an UTF-8 format (lfm) with nicer error handling. That is all independent of the widgettype.

Sounds great.

-Michael

Il 23/06/2014 12:43, Michael Schnell ha scritto:
[...]

Customdrawn is LCL based. Meaning that even using low level drawing (X11 and Windows) it must mimic the full fledged widgeset behaviors, just as if it were a gtk or qt widgetset. It turned out to be too slow to be of practical interest.

Does you project already have a working (runtime) implementation of an Event Queue and of TTimer ?

Currently my project is just a port of Kylix, and therefore has a working implementation both of Event Queue and TTimer, but it uses Qt for both, and moreover it takes advantage of Borland's copyrighted code. Some code is in a doubtful condition, being declared Open Source, some parts are proprietary. Therefore it can't be shared as it is. My plans are to rewrite the code, in future, starting from the surely proprietary parts, but it'll take a lot of time.

Giuliano

Mattias Gaertner wrote

Are you sure you need Epiktimer and hardware ticks for TTimer? That sounds like overkill.

Using a hardware timer in user-space yields the lowest possible overhead (preventing unnecessary user-space/system-space mode-switches).

If user space access to a hardware timer is not available in an arch, of course a fallback to system calls is implemented.

Happily (a Linux aware version of) EpikTimer does exactly this and hence a common source code (improvement of EpikTimer and Usability in NoGUI would be commonly manageable) seems appropriate.

In fact I hoped that vDSO could provide an arch independent interface to such timing source, but seemingly vDSO will not reach an appropriate state in foreseeable future :-( .

-Michael

Giuliano Colla wrote

My plans are to rewrite the code,

Both the runtime code and a ind of GUI designer ?

-Michael

Il 23/06/2014 13:33, Michael Schnell ha scritto:

The first step will be to take care of GUI design. Runtime code will come later on.

Giuliano

A TTimer does not need the "lowest possible overhead". The TTimer in GUI has to fight with a lot more overhead. No one expects TTimer to be millisecond exact.
Therefore the nogui widget only needs a decent TTimer, preferably with no extra dependencies like EpikTimer and no calibration.

Mattias

Giuliano Colla wrote

The first step will be to take care of GUI design. Runtime code will come later on.

OK.

What is the benefit of providing an alternate GUI designer vs. using the one that Lazarus offers ?

-Michael

Mattias Gaertner wrote

preferably with no extra dependencies like EpikTimer and no calibration.

I of course do see your point.

With my first test I just wanted to try to find the optimum (lowest possible overhead, not arch depending) way to do it and came across EpikTimer that obviously offers an example and found that EpikTimer would benefit from finding a more manageable and more arch - independent implementation.

That is why I did some research and looked whether vDSO might be a way to go (which it is not for the time being.)

-Michael

Il 23/06/2014 15:07, Michael Schnell ha scritto:

If you just read the beginning of this thread you get your answers.

In a few words:

Lazarus designer, as it is, is an LCL designer, aware only of LCL units, classes and properties.

In order to use it with a non LCL widgetset one must add a Mediator, aware of the new widgetset units, etc. But currently duplicates aren't allowed. Meaning that a different widgetset cannot contain units or classes with the same name of an LCL counterpart. Therefore an extension is required, to allow duplicates, and to decide which one to use and when.

Moreover widgets must be designer aware: you increase the width property, and the widget must become wider. LCL widgets already are, others must be adapted to take advantage of Lazarus Mediator, Designer etc.

Of course a lot of the current Designer code will be reused, because it's stupid to reinvent the wheel, but a lot of adaptation is also required.

Giuliano

units yes.
classes no. classes are the problem. I have some idea how to solve this, but I'm not sure if this is sufficient.

Mattias

Il 23/06/2014 19:09, Mattias Gaertner ha scritto:

My faith in your resources knows no limits :-)

Giuliano

As you never mention this term I am not sure if you are aware of the Lazarus concept of Widget Types. I understand, at compile time the define variable WidgetType is used to (e.g.) select include files that define the behavior of all related objects. I understand that this is provided to allow for things similar to "different widgetset contained in units or classes with the same name", by moving the relevant source code to include files..

I understand that you can add new widgets to the Lazarus GUI designer by installing packets (and then recompiling the ide)

Why not add the Widgets you are missing using a packet ? (If you want to re-use existing code, maybe you can activate macro-processing for compiling these units (I seem to remember that fpc somehow allows for this) and by that e.g. rename the "duplicate" classes, or write your own preprocessor doing this. )

-Michael

Il 24/06/2014 09:14, Michael Schnell ha scritto:

Widget Types are LCL related. It's the part which actually implements virtual abstract methods in the Interfaces unit.

I'm already using packages, but they're run time only packages. They can't be installed into the IDE, because of class names conflict, and therefore they can't take advantage of the IDE Designer facilities. Solving this problem is the subject of this thread.

Giuliano

Giuliano Colla wrote

Widget Types are LCL related. It's the part which actually implements virtual abstract methods in the Interfaces unit.

Yep.
So it seems perfectly suitable to individually define the functionality of classes that share a common name.

I'm already using packages, but they're run time only packages.

????
Lazarus does not (yet) support runtime-packages (that with Delphi are a special kind of dlls).

Solving this problem is the subject of this thread.

Of course I do understand that.
Supposedly the concept of the said "runtime-packages" needs to be revised.

-Michael

Mattias Gaertner wrote

. Therefore the nogui widget only needs a decent TTimer, preferably with no extra dependencies like EpikTimer and no calibration.

I added some {$ifdefs} so that my code does not depend on any EpikTimer related stuff.

Instead it then uses TThread.GetTickCount64. Do you think that is appropriate at this point in time ?

What do you suggest how I should proceed ?

-Michael

You mean packages as dynamic libraries with shared classes and mem manager.

'Runtime-packages' means something different:

http://wiki.freepascal.org/Lazarus_Packages#Design_Time_vs_Run_Time_package

Mattias

:)

Instead it then uses TThread.GetTickCount64. Do you think that is appropriate at this point in time ?

Yes.

What do you suggest how I should proceed ?

What are the differences between your widgetset and the nogui widgetset? How do you support multiple timer? What scheduler do you use?

Mattias

I see.
Thanks for the Clarification.

I seem to remember that with Delphi the Term RuntimPackage had been used the way I did and was not aware that with Lazarus this is different.

-Michael

Both Delphi designtime and runtime packages are dynamic libs.

Mattias

Mattias Gaertner wrote

> Instead it then uses TThread.GetTickCount64. Do you think that is > appropriate at this point in time ? Yes.

I just checked and found that with fpc vertsion 2.6.0-9, which is the version I installed as a Debian Package for X86-64) TThread does not have CurrentThread,
Queue, and
GetTickCount64

I do call thees three in my "interface" unit.

(To do a test with 64 Bit, I hence would need to install and compile the svn version.)

What are the differences between your widgetset and the nogui widgetset?

I'll take a look.

How do you support multiple timer?

I create a pool of timers. (My TTimer class has a class variable holding all Timers created in a dynamic array.)
When a timer tick occurs (or when CheckSynchronize returns because of a queued Event), the tick count for the next tick of any timer in the pool is calculated. The resulting period is used as the Timeout parameter for CheckSynchronize().

What scheduler do you use?

In fact none. CheckSynchronize performs the waiting in the main thread and any time base that can read a current tick count (arbitrary frequency) can be used as a timebase.

This Seems like requiring the lowest possible overhead (you know that this is a goal of mine).

To reduce the overhead even more, my TTimer has a class property "Granularity" that allows to define the accuracy of the Timers (in msecs) so that with lower necessary accuracy, events of multiple TTimers will occur at the same time with no system calls in between.

-Michael

version I installed as a Debian Package for X86-64) TThread does not have

The TThread extensions are only part of FPC 2.7.1.

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

Is it "decent" do base a Lazarus extension on same ?

-Michael

AFAIK they came with 2.6.1.

I do call thees three in my "interface" unit.

No problem for for the nogui widgetset.

(To do a test with 64 Bit, I hence would need to install and compile the svn version.)

Or use the 64bit Debian packages from Lazarus at Sourceforge.

ok

Nice.

Mattias

ok, then it needs ifdefs in nogui.

Mattias

If you rely on the new TThread functionality you'd need to at least put in guards against compiling with a pre-2.7.1 compiler. Better would be to write the code in a way that it works with 2.6.x as well.

Regards,
Sven

Sven Barth wrote

If you rely on the new TThread functionality you'd need to at least put in guards against compiling with a pre-2.7.1 compiler.

Can I do this by a {$ifdef ... } ?

Better would be to write the code in a way that it works with 2.6.x as well.

I can try to do this:

- TThread.CurrentThread:
This is only necessary for perfectly calling TThread.Queue, as same is not a class functions (even though I suppose it could be)

- TThread.Queue,:
I use this to implement Application.QueuAsyncCall. I can try to do the (supposedly minimal) code that in TThread.Queue forwards the procedure of object to the Event queue, native in the implementation of my TApplication class.

- TThread.GetTickCount64:
I can try to do the (supposedly minimal) code that in TThread.GetTickCount64 does a system call and some calculations, native in the implementation of my TApplication class.

-Michael

Mattias Gaertner wrote

ok, then it needs ifdefs in nogui.

Yep.

How does such an ifdef exactly look like ?

(see my answer to Sven..)

-Michael

{$IF FPC_FULLVERSION >= 20701}

Mattias

Application.QueueAsyncCall works in nogui if you call Application.ProcessMessages.
Why use TThread.Queue?

Mattias

Mattias Gaertner wrote

Application.QueueAsyncCall works in nogui if you call Application.ProcessMessages.

I am just doing the implementation of TApplication. And the point with _active_ Applications is that the events are called without the user needing to do a main loop.

Why use TThread.Queue?

To implement Application.QueueAsyncCall. :-)

-Michael

This version of the compiler even does not have "HAVECLOCKGETTIME" -> clock_gettime() and hence I need to fall back to fpgettimeofday() which is not very appropriate in this context. :-(

-Michael

Ok.
That's incompatible to the LCL QueueAsyncCalls, which executes the calls in the main thread.

Mattias

Mattias Gaertner wrote

Ok. That's incompatible to the LCL QueueAsyncCalls, which executes the calls in the main thread.

Not task of TThread.Queue is scheduling a Main thread Event !

Of course I did the implementation of TApplication in a way that the Async call is queued and done in the main thread and is provided with the parameter given in QueueAsyncCalls.

The problem is, that I in fact do need TThread.Queue, because I can't re-implement the code in TThread.Queue as same uses stuff that is defined as private in TThread.

So I in fact do need the more recent compiler / RTL version.

(There was a reason why I restarted my long sleeping project to do an ActiveNoGUI Widget type not before TThread.Queue has been implemented by the fpc team !!! )

-Michael

On 06/26/2014 12:25 PM, Mattias Gaertner wrote: > Ok. That's incompatible to the LCL QueueAsyncCalls, which executes the > calls in the main thread. Not ?

I can rephrase it:
The LCL Application.QueueAsyncCalls can be called by any thread, and executes the calls, when the main thread calls
Application.ProcessMessages. Therefore the calls are executed by the main thread.

You don't need TThread.Queue for that.

For example lazbuild uses the nogui widgetset and uses QueueAsyncCalls.

Mattias

Of course I do know this. But my goal is that these Events are executed without the user needing to call Application.ProcessMessages. (IMHO this is how decent Object Pascal Applications are supposed to work.)

I implemented it in My TApplication class and it does work perfectly (using the svn-version of the fpc rtl).

You don't need TThread.Queue for that.

To do an _active_ application you need an event queue for that purpose. The GUI based Widget Types use their own Event Queue implementations in the LCL for this. (AFAIK) NoGUI does not have an Event Queue in the LCL (and I don't want to add one). Hence it can't "automatically" (without a main loop visible to the user) do Main Thread Events (such as fired by TTimer and QueueAsyncCall().

So the only EventQueue I (want to) have in my ActiveNoGUI Application is the one provided by the fpc RTL. And same is integrated with the TThread implementation I need to (and am happy to) use same. But this is only possible since the appearance of TThread.Queue (which is compatible even to rather old Delphi versions and some time ago has been done due to my request) .

-Michael

in guards against compiling with a pre-2.7.1 compiler.

Can I do this by a {$ifdef ... } ?

{$IF FPC_FULLVERSION < 20701}
{$MESSAGE fatal 'You need at least FPC 2.7.1'}
{$ENDIF}

Untested. I haven't used $message in quite some time...

> Better would be to write the code in a way that it works with 2.6.x as

well.

not a class functions (even though I suppose it could be)

Did you even look at the interface of TThread? There's a protected instance function that calls a public class function with Self as first parameter. If you use the second one and pass Nil as first parameter it automatically uses the current thread.

- TThread.Queue,: I use this to implement Application.QueuAsyncCall. I can try to do the (supposedly minimal) code that in TThread.Queue

forwards the procedure of object to the Event queue, native in the implementation of my TApplication class.

A little sidenote: the current implementation immediately executes events queued by the main thread. This is Delphi compatible.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140626/1583542d/attachment.html>

[...] Of course I do know this.

Make up your mind. Either I'm "Not true at all" or I wrote something right.

But my goal is that these Events are executed without the user needing to call Application.ProcessMessages. (IMHO this is how decent Object Pascal Applications are supposed to work.)

If your main thread does not call Application.ProcessMessages, what does it call to give time to the async calls?

Stating the obvious:
If you implement a LCL function in the nogui widgetset, you have to implement it compatible. Your goals and opinions are no excuses for incompatibility.

Mattias

You are obviously right But this is not at all my Problem. If I do have TThread.Queue I will be able to use it. (Possible optimizations will be done, of course.)

A little sidenote: the current implementation immediately executes events queued by the main thread. This is Delphi compatible.

I see.
I suppose this is not a problem.

Maybe this is not fully compatible with Application.QueueAsyncCall (if same is called in the main thread), which I did implement using TThread.Queue.

Do you think this is a problem ? If yes I would need to take another look.

-Michael

[...] {$IF FPC_FULLVERSION < 20701} {$MESSAGE fatal 'You need at least FPC 2.7.1'}

{$ERROR 'You need at least FPC 2.7.1'}

But the Lazarus code must work with 2.6.4, so there must not be an error.

Then this cannot be used to implement the LCL
TApplication.QueueAsyncCall as it must execute *after* the current event/function.

Mattias

"Not true" was, that my implementation of Application.QueuAsyncCall using TThread.Queue would not perform the calls in the main thread. (This in fact already does work perfectly.)

But maybe it really is not perfectly compatible, as, _when_called_in_the_main_thread_, TThread.Queue perhaps does a direct call instead of a queued schedule, which might not be true with Application.QueueAsyncCall. I need to take a look at this.

If your main thread does not call Application.ProcessMessages, what does it call to give time to the async calls?

See the my messages above in this thread:
checksynchronize()

"Events are executed without the user needing to call Application.ProcessMessages" is how all "decent" LCL WidgetTypes work (but supposedly not NoGUI). Hence this is perfectly "compatible".

My initial intention was a new WidgetType called "ActiveNoGUI". But here, I was presented with the suggestion to instead enhance the current "NoGUI" WidgetType. This might or might not (for compatibility issues) be desirable.

Of course, my primary goal is compatibility, of course, secondary is low overhead.

-Michael

Application.ProcessMessages calls CheckSynchronize and calls the queued async calls. Under nogui that's all. Other widgetsets process the widgetsets events as well.

Not true. A LCL program calls Application.Run, which is a loop calling Application.ProcessMessages. You can create sub loops. A common example is TForm.ShowModal, which also calls Application.ProcessMessages. Or you can do your own loop, in which case you have to call it yourself.

If you call CheckSynchronize instead of Application.ProcessMessages you simply omit the widgetsets and queued async calls. Why do you think this is a feature?

My initial intention was a new WidgetType called "ActiveNoGUI". But here, I was presented with the suggestion to instead enhance the current "NoGUI" WidgetType. This might or might not (for compatibility issues) be desirable.

Mattias

Il 25/06/2014 15:16, Michael Schnell ha scritto:

[...]
Only if you implement a widgeset using the same mechanism of virtual abstact methods, and all properties and methods are identical to those supported by LCL, which isn't true in general. At least not for Kylix and FpGui.

Just a trivial example: Kylix TForm has a Bitmap property to provide a background image to the form. LCL doesn't. Either you add this property to LCL, implement it in each widgetset, making unhappy the supporters of "native look", or you drop this property, and do not support a feature which is used in hundreds of applications, to provide users an easy visual feedback.
LCL is but one way to go. It has pros and cons. But it's not the only one.

Giuliano

Mattias Gaertner wrote

Application.ProcessMessages calls CheckSynchronize and calls the queued async calls. Under nogui that's all.

Here the waiting and sleeping mechanism is lacking.

Application.ProcessMessages supposedly calls CheckSynchronize with the Timeout set to 0.

The timeout is critical for me, as it is used to implement TTimer.

In my Application CheckSynchronize always is called with the Timeout set to a non zero Value.

TThread.Queue in the end calls WakeMainThread() to wake the main thread (i.e. terminate the CheckSynchronize call waiting for a timeout).

I did not yet find any lower level non private queue-feed functionality usable instead of TThread.Queue.

Other widgetsets process the widgetsets events as well.

They implement a second queue besides the one the RTL implements for TThread.

Other "active" LCL Widget Types call CheckSynchronize with Timeout set to Zero and implement their own arch depending waiting mechanism, as they are greatly arch depending anyway. My tiny Application not inherently arch depending implementation just uses CheckSynchronize to do the waiting (e.g. for TTimer) and hence does not an arch depending implementation for this.

-Michael

At the beginning Michael sounded more like he wants to implement a new widgetset that's only relying on TThread functionality and thus would require 2.7.1. For the case of extending NoGui you are of course right.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140626/5e88510b/attachment.html>

On 06/26/2014 03:54 PM, Mattias Gaertner wrote: > Application.ProcessMessages calls CheckSynchronize and calls the > queued async calls. Under nogui that's all. Here the waiting and sleeping mechanism is lacking.

If you mean for TTimer: Yes, I'm waiting for your patch.

Application.ProcessMessages supposedly calls CheckSynchronize with the Timeout set to 0.

Yes.

So? Program a queue.

> Other widgetsets process > the widgetsets events as well. They implement a second queue besides the one the RTL implements for TThread.

Probably they have several.

Ok. You have the tools, you have a proof of concept, now program it and create a patch.

Mattias

TThread.Queue in the end calls WakeMainThread() to wake the main thread (i.e. terminate the CheckSynchronize call waiting for a timeout).

In Simula a single time base is used to trigger events at a known time. Each event, to occur after a given delay, is enterd into a queue, sorted by the absolute time of the event. Every clock tick increments the internal clock, and triggers all events waiting for the time just reached. For periodic events the event handler enters itself into the queue again, for the next event time. When the next time is calculated from the time of the previous event, incremented by the time period, jitter or delays in event processing are eliminated.

Event handlers in the main loop can be invoked immediately, for handlers in other threads the thread is suspended when it waits for an event, and is resumed when the time has been reached. This way a thread also can wait for multiple events, it only has to fork to the handler associated with the just signaled event.

DoDi

Mattias Gaertner wrote

If you mean for TTimer: Yes, I'm waiting for your patch.

Meaning what ?

I can send you a testing application (that does nit use the LCL but just fpc) if you just want to see it working.

For doing a "Patch" to the LCL, some more prerequisites are needed:
- do we want something at all if it is not usable with the "released" version of fpc (see discussion in fpc-devel)
- can we do an extension to the current "noGUI" Widget Type . - here: do we want to add a "sub-WidgetType) similar to "fpGUIPlatform") to allow for selecting old and the new behavior so that no incompatibility problems can come up.
- or do we need a completely new Widget Type "AciveNoGUI", preventing any incompatibility problems for current noGUI users. . - here the IDE somehow needs to know about this I have no Idea how to implement this.

So? Program a queue.

IMHO this is not appropriate.

There already is a queue in the RTL that needs to be handled, as same is fed by TThread.Synchonize (and TThread.Queue) user accessible functions. Hence an additional queue would need merging the queue outputs and handling the waiting and waking for both Queues simultaneously. This (waiting and waking regarding the additional queue) needs arch depending code (as done in the GUI based Widget Types). But the NoGUI Widget Type is done for small embedded projects. here arch-independence, low latency and low processor demand is critical.

> They implement a second queue besides the one the RTL implements for > TThread. Probably they have several.

IMHO it is not a very nice concept to merge queue outputs. This of course has historical reasons with the existing GUI based widgets sets.

IMHO it would be better top merge the queue inputs and hence waiting and waking is central.

(A concept to do this would be a central Event Queue implementation in the RTL that always is used by the LCL Widget sets. Of course with the Windows widget set this technically can't be done, as you need to use the OS Message Queue. To provide for this, the RTL's Queue would need to allow for overriding the appropriate input and output functions to allow for using a (single) external queue such as the Windows message queue.

Ok. You have the tools, you have a proof of concept, now program it and create a patch.

Of course I am happily up to do that :-) .

-Michael

Hans-Peter Diettrich wrote

Every clock tick increments the internal clock, and triggers all events...

This is exactly what I want to avoid.

Each active clock tick needs a system-mode / user-mode and back transition. But the NoGUI Widget Type is done for small embedded projects. here arch-independence, low latency and low processor demand is critical. Hence I want to avoid any unnecessary system calls (that do not result in calling any user-code event).

-Michael

Yep.

As discussed in fpc-devel, I could use $IFs that just switch of the functionality (and issue some kind of error indicator) when compiled against an older fpc rtl.

-Michael

Yes, please.

For doing a "Patch" to the LCL, some more prerequisites are needed: - do we want something at all if it is not usable with the "released" version of fpc (see discussion in fpc-devel)

Yes. Many features started with $IFs. You just have to document the requirements. For example on the wiki page for the nogui widgetset.

Small differences are done with IFDEF EnableSomeFeature or IFNDEF DisableSomeFeature.

. - here the IDE somehow needs to know about this I have no Idea how to implement this.

It is possible to register flags, but normally we only document them and programmers use them when needed. Most flags are for special cases, which would confuse the majority of users.

Mattias

Giuliano Colla wrote

implementation part is demanded to some third party Widgetset (such as gtk, qt, Windows, etc.), via an Interfaces unit. This is not compatible with other implementations, such as Kylix and fgGui, just to mention two.

It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?

Well, the only reason to deliver the runtime stuff in package form is if you really support building the end application with packages. (which is sometimes further complicated by letting the designtime package depend on the runtime one) Otherwise DCU's are simply put in the path.

Strictly speaking a Delphi package is not always dynamic (.dcp, see http://wiki.freepascal.org/packages). Comparable with a .a and an archive of .ppu's for FPC I guess.

Mattias Gaertner wrote

Yes, please.

I'll do some cleaning up and send you the source code.

-Michael

That's not arch dependent, but library dependent.
In case of nogui there is no library, so you have the full control.

But the NoGUI Widget Type is done for small embedded projects.

Not quiet. The nogui widgettype is for LCL applications running without GUI. This can be a daemon or console tool.
Because the LCLBase is not optimized for smart linking it pulls in a lot of stuff and it is not good for small embedded projects.

here arch-independence, low latency and low processor demand is critical.

Have you actual numbers of the overhead that you fear so much?

Same for the other widgetsets. Except for nogui.

Mattias

He meant, you cannot use CLX and LCL in an application at the same time. Same with fpgui.

You can either port your CLX application to the LCL or you can extend the IDE designer to support CLX applications. And when the IDE can support CLX, then it is a small step to support fpgui as well. Maybe msegui too, but that uses a different FCL, so maybe that needs some more support.

Mattias

Il 27/06/2014 11:09, Marco van de Voort ha scritto:

You're right, in Kylix CLX Qt is hardcoded. Therefore it's different from LCL scheme virtual/abstract - interface.
This makes it impossible to use the features of IDE Designer as it is for a Kylix project.
LCL scheme makes it possible to use different widgetsets at design time and at run time, but requires that all of them follow the same rule of virtual/abstract+Interface. Moreover IDE designer defaults to LCL classes properties and methods, and doesn't allow duplicates.If a Kylix class has the same name of an LCL class, you'll be unable to design. TForm is the first one!

If, with some kludges, you manage to use the IDE designer as it is, for a Kylix project, it will only be aware of LCL methods and properties, and you'll end up both with Kylix unsupported methods and properties, and with Kylix required methods and properties dropped because unsupported by LCL.

This sums up in being incompatible.

Giuliano

Mattias Gaertner wrote

In case of nogui there is no library, so you have the full control.

I need to do a system call to have the program wait and do another system call to wake it. I understand that this is "library dependent".

Not quiet.

OK. Not _necessarily_. But this is a decent use of it.

Have you actual numbers of the overhead that you fear so much?

In any case, it's better to avoid if, if possible.

Same for the other widgetsets. Except for nogui.

In fact the GUI enabled, non-Windows Widget Types do implement an event Queue in pascal code.AFAIK, this is necessary because the external Widget Sets do callbacks that need to be queued until the program is able to handle them (while in Windows the messages are queued anyway).

Hence there it would be "nice" (and IMHO possible) not to have a dual queue (one in the RTL, one in the LCL), but a central one..

But of course I do not really vote for taking the huge effort to modify the current status quo.

-Michael

Any time source is applicable with this model. The ticks (or even longer intervals) can be deliverd by callbacks, messages...

DoDi

I checked the code of TThread.Queue and in fact it does not queue the call if TThread.Queue is executed from the main thread, but performs the call right away.

This supposedly is not compatible with how Application.QueueAsyncCall works in other WidgetTypes.

Unfortunately the svn-version of the rtl does not provide a means to prevent this (queer, Delphi compatible) behavior.

So for full compatibility we would need an enhancement in the fpc-rtl.

(I'm going to post this in fpc-develop, as well.)

-Michael

Addition:
- we can't create full compatibility to how Application.QueuAsnyCall works with other Widget Types, as TThread.Queue, when called from the main Thread, does not queue the call but preforms the call right away.

Unfortunately this is even true if you do TThread.Queue with a fake self pointer, as it internally checks using GetCurrentThread.

Hence we would need a modification to the RTL for full compatibility.

-Michael

Hans-Peter Diettrich wrote

Any time source is applicable with this model. The ticks (or even longer intervals) can be deliverd by callbacks, messages...

We have multiple TTimers that need to be driven by a singe Time source. Hence the necessary userspace / syrtemspace are not equidistant in time.

-Michael

It's the same in the fact that you can't reappropiate the designer to non built-in <x>CL(X) libraries.

You can only use the designer with the built-in library, at best with a different backend wacked under it.

But it is clear, this is about customized designer support. The "widget" stuff talk put me of course (I actually realised a bit later)

This makes it impossible to use the features of IDE Designer as it is for a Kylix project.

True, but the incompatible threw me off, and the perspective on what incompatible with Kylix means.

I never considered loading unmodified CLX projects a Lazarus designgoal. More so because the last Kylix is already a decade old.

OTOH I have nothing against it. (I'm a bit careful with dragging fpgui in it, since contrary to CLX, its persistence mechanisms and principles might be different)

True.

This sums up in being incompatible.

That is IMHO an unfortunate choice of words. It is not a general purpose designer. It is not incompatible because it never strove to be.

Anyway, all is clear now. At least it made me realize you meant reusing the current designer for CLX and not add a different one. That might indeed be doable since CLX inherits many of VCL/LCL's traits.

... or simply do it without TThread.Queue, which is not complicated, is LCL compatible and works with fpc 2.6.2+.
Only argument: You fear it is more overhead. The only overhead I see is an extra critical section, which is negligible when your granularity is milliseconds.

Mattias

As I already pointed out this would include creating an second event queue and take care of OS-based waiting and waking the main thread for both queues, as with this I can't use the timeout parameter of ChechSynchronize().

-Michael

Il 27/06/2014 14:44, Marco van de Voort ha scritto:

On Fri, Jun 27, 2014 at 11:50:18AM +0200, Giuliano Colla wrote:

[...]

Sorry for the misunderstanding. I did consider this possibility because we have hundreds of Kylix projects which are still alive, and need maintenance. Kylix IDE can only be used on old platforms/virtual machines but the compiler and the applications still run in the most recent ones.
Until recently I wasn't aware of the possibility of extending the IDE designer via a Mediator. But given this possibility, I find much more interesting and stimulating the attempt to take advantage of this feature, than the boring task of converting hundreds of Kylix applications to LCL!

Giuliano

Giuliano Colla wrote

But given this possibility, I find much more interesting and stimulating the attempt to take advantage of this feature, than the boring task of converting hundreds of Kylix applications to LCL!

Is it a boring task? It could be relatively easy because there are not many 3rd party libs for Kylix and the code does not call WinAPI extensively. The converter in Lazarus is tested mostly with Delphi code, I would be interested in your experiences with Kylix code.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140627/154885fc/attachment.html>

Can they also bind to recent QT versions? I doubt. My opinion is that you are heading to a dead end. You must work hard before the design mediator works, and then you can support a dead environment.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140627/26234d1d/attachment-0001.html>

Il 27/06/2014 19:08, Juha Manninen ha scritto:

My experience of migrating Kylix code to Lazarus has been quite frustrating. My applications aren't classical database applications, where once you have a working DBGrid you're done.
They provide a human interface to complex machinery, which take largely advantage of visual features, to provide a comfortable visual feedback, visibility from distance, touch screen operation etc. You need tons of workarounds to make them work under Lazarus, and to comply with native widgesets features and bugs. Just to mention a few:

*

I must provide forms with a background image, which can't be solid color for better readability, and this feature is missing from LCL. Painting the background of a form, and keeping it updated, without losing a lifetime, is quite a challenge, and what works with Lazarus 0.9.29 doesn't work anymore with Lazarus 0.9.31, because of some changes somewhere, which don't affect DBGrids.

*

Whenever you need a form to "stay on top" you never know if it'll work or not. For Gtk2, it did work on Lazarus 1.0.8, but it stopped working since Lazarus 1.1. This means that a user may lose an alarm which pops up, because he inadvertently touched the larger form.

*

A lot of components are built run-time, and this again is a sort of nightmare. The interaction between LCL and widgetset makes that LCL properties are out of synch with actual widget at creation time. If two components are created at run time and must have a position or a size relative one to the other, it's again a fight, where frequently you end up as a loser.

The list might go on for pages, but that's the general idea. Basically for each visual component I must find a work-around, and this is long, frustrating and boring.

All of that is not because Lazarus developers are incompetent. They pay attention to what the majority of users requests, and they're always working on quicksand, because of always changing Gtk or Qt whims, they can't control, but must only obey to.
As a result I can use Lazarus for some applications which aren't too much demanding in terms of visual features, but not for hundreds of Kylix applications.

Giuliano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140627/b5924963/attachment.html>

Il 27/06/2014 19:16, Juha Manninen ha scritto:

Why should I care about a recent Qt version? They bind to their libborqt.so which provides what required.

My opinion is that you are heading to a dead end. You must work hard before the design mediator works, and then you can support a dead environment.

I don't care too much about being "modern". I claim that the best solution is always the most appropriate, not the "newest". Tombstones are still made of stone. It's stone age technology, but it's the most appropriate up to now. Only if someone comes out with something better they will be finally dropped.
When I'll find something more appropriate for my applications, I'll drop Kylix with no regrets.

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140627/59b0b3eb/attachment.html>

You seem to have unusual GUIs. Still, I have a feeling you do something wrong when creating controls in code.
Setting the position, size or anchors at runtime work well. Gtk2 may have some Z-order issues, QT is better.
I did not use a background bitmap but it should be doable, too.

If you ask specific questions in a new mail thread with example code snippets, I am sure people here will find solutions.

Juha

P.S. I don't have anything against your design mediator. It only requires a lot of work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140628/a77a18cd/attachment-0001.html>

Il 27/06/2014 23:34, Juha Manninen ha scritto:

You seem to have unusual GUIs. Still, I have a feeling you do something wrong when creating controls in code. Setting the position, size or anchors at runtime work well. Gtk2 may have some Z-order issues, QT is better.

Well, I may give you a small example. Two buttons, side by side. The first one has AutoSize set, to fit a text which must be determined at creation time. The next should go some ten pixels from the right edge of the first, and stay there even if the first is made invisible.

Kylix code:
Create the first button, then create the second. Set its Left property to Left_of_the_first+Width_of_the_first+required spacing. You're done, it works.

Lazarus code:
Just take Kylix code. The second button is partly over the first one. You mumble a bit and understand that the Width you get isn't the actual Width of the button after AutoSizing, but just the default Button Width. Then you add some code, i.e. you calculate the TextExtent on the canvas of the first Button to evaluate the actual Width, add the few extra pixels for the button border, use this value, and finally it works. (I can't anchor the second Button to the first, because if the first becomes invisible, the second is moved from his position, which is not acceptable).

I did not use a background bitmap but it should be doable, too.

Of course is doable. But how many kludges are required to ensure that at each repaint the Z-Order is properly respected, and that you don't have controls below the bitmap, or empty bitmap areas? I've done it once, and when I got tired of fighting there were still some detail which should have been adjusted.

If you ask specific questions in a new mail thread with example code snippets, I am sure people here will find solutions.

I don't share your confidence. Many problems are related to the way the widgetset send signals back: if signals are missing or wrong, there's little that developers can do. The intricacies of Interfaces make it very difficult to debug, or simply to locate the problem.

I have raised a problem quite some time ago: (as of Lazarus 1.0.8): If you move another window over a Group Box, not all controls are repainted properly when they're uncovered: the Group Box Title, Speed Buttons and Labels aren't repainted, or just partly repainted. Buttons and BitButtons are unaffected.
As of Lazarus 1.3 rev 45619 the problem is still there. I still compile an application where this problem is an issue because the affecting window is just the dropdown of a ComboBox, with a legacy Lazarus 0.9.28 (or something around) which doesn't show the problem.

But a new similar problem which wasn't in 1.0.8 has popped up in the meantime: if you have a SpeedButton on a Panel, when you pass the mouse over it, and the control is highlighted, some surrounding controls are partly erased. e.g. TLabel is affected, TStaticText is not. You must add an OnMouseEnter and OnMouseLeave event to your SpeedButton, which triggers a repaint of the Panel to restore all controls.

Graeme Geldenhuys who had problems of the same sort ended up designing his own widgetset. I'm more modest, and I look to a design mediator.

Giuliano

Giuliano Colla wrote

(I can't anchor the second Button to the first, because if the first becomes invisible, the second is moved from his position, which is not acceptable).

True, hiding the control ruins the plan of using anchors here. A more standard way would be to disable it instead of hiding.

Graeme Geldenhuys who had problems of the same sort ended up designing his own widgetset. I'm more modest, and I look to a design mediator.

Some sort of custom widgets could be a solution. There are component libraries which can live side by side with LCL components. I don't have any installed now but I remember testing some. I think I will study them more if I need to make a fancy GUI.

Juha

I just got some information about this issue, when I encounterd z-order problems with a Delphi XE application. Here's what Peter Below wrote, most LCL developers will be able to read this:

>

In D7 war das Application-Window (nicht sichtbar) der API-Parent f?r alle Forms, d. h. sie waren alle "Geschwister" in der Fenster-Hierarchie. Das Taskbar-Button der Anwendung geh?rte dem Application-Window.
Der API-Parent bestimmt die Z-Ordnung der Fenster und Windows sorgt daf?r, dass ein Fenster immer ?ber seinem API-Parent in der Z-Ordnung liegt.

Seit D2009 ist das Mainform standardm??ig der API-Parent f?r alle anderen Forms und der Taskbar-Button geh?rt zum Mainform. Das war notwendig, um Anzeigeprobleme auf dem Vista Aero-Desktop zu vermeiden. Damit liegen aber auch alle anderen Fenster in der Z-Ordnung ?ber dem Mainform.
Application.MainformOntaskbar := false geht zum Verhalten von D7 zur?ck, mit den damit verbundenen Problemen auf dem Aero-Desktop (betrifft wohl diese Mini-Fensteransicht, die man kriegt, wenn die Maus ?ber einem Taskbar-Button schwebt).

Es gibt eine Alternative: wenn man ein spezielles Form aus dieser Z-Ordung l?sen will kann man seine CreateParams-Methode ?berschreiben.

   inherited;
   params.WndParent := 0;

Damit bekommt man ein Fenster ohne API-Parent, das also in der Z-Ordnung von den anderen Fenstern der Anwendung losgel?st ist. Wenn man statt 0 Application.Handle verwendet sollte das Fenster auf der gleichen Ebene der Fensterhierarchie landen wie das Mainform. In beiden F?llen kann es sinnvoll sein, dem Fenster einen eigenen Taskbar-Button zu verschaffen. Dazu kommt folgende Zeile in die ?berschriebene CreateParams-Methode:

   params.ExStyle := params.ExStyle  or WS_EX_APPWINDOW;

-- Peter Below
<<

It seems to me that MSEide+MSEgui has been developed with exactly your requirements in mind. I actually have the same requirements. :-)

Martin

Il 28/06/2014 09:16, Hans-Peter Diettrich ha scritto:

[...]
It's no wonder that changing the hierarchy something may go wrong. LCL developers may look into that.

But what I see, as a user, is that 10 year old libraries (those of Kylix), survive to all Linux, libc, X11, and Desktop evolutions, and what was running under a 2.4 kernel and KDE 2, still runs (keeping the correct Z-order, among all other things) under a 3.x kernel, KDE 4 etc.

Maybe a more conservative approach, i.e. avoiding to take advantage of all the fancy new features of widgetsets, libraries, etc. and relying only on basic functions, which are much less likely to change in time, could save a lot of headaches.

Giuliano

problems with a Delphi XE application. Here's what Peter Below wrote, most LCL developers will be able to read this:

>>

[snip]

The problem is that Win32 GTK2 Qt. What might be true for the one might not be for the others. And Giuliano explicitly mentioned GTK2.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140628/3d2e6360/attachment.html>

problems with a Delphi XE application. Here's what Peter Below wrote, most LCL developers will be able to read this:

> [...] It's no wonder that changing the hierarchy something may go wrong. LCL

developers may look into that.

But what I see, as a user, is that 10 year old libraries (those of

Kylix), survive to all Linux, libc, X11, and Desktop evolutions, and what was running under a 2.4 kernel and KDE 2, still runs (keeping the correct Z-order, among all other things) under a 3.x kernel, KDE 4 etc.

That's simple when the widgetset library itself never changes. As you said Kylix links to libborqt, while Lazarus uses the normal Qt libraries of which the development hasn't stopped. Same for GTK. Bugs get fixed there so maybe workarounds used by the LCL don't work anymore. Additionally I'd say that Lazarus has a rather large userbase compared to Kylix so that bugs are exposed to more users. Perhaps Kylix might work for yourself without big problems, but maybe it wouldn't work as well for other users which have different requirements.

Maybe a more conservative approach, i.e. avoiding to take advantage of

all the fancy new features of widgetsets, libraries, etc. and relying only on basic functions, which are much less likely to change in time, could save a lot of headaches.

The problem is less taking advantage of new features it's more that it's a hassle to get a component library like the LCL to behave the same on different widgetsets which have different paradigms.

And then there are of course users that *want* to take advantage of new features. Preview thumbnails on Windows Vista+? Check. Retina rendering on Mac OS X? Check. And so on. Basic functionality is often not enough when you want an application to behave like it belongs on the system (that's why GTK and Qt applications always give me the runs on Windows; they nearly always don't integrate good enough).

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

Giuliano Colla wrote

You need tons of workarounds to make them work under Lazarus, and to comply with native widgesets features and bugs. Just to mention a few:

That is a very similar experience I had with LCL. My applications required a lot of visual customisation, and LCL simply wasn't up to the task. And like you said, things break often between versions. Also the inconsistency between LCL widgetsets was a real nightmare.

CLX was definitely more consistent between Windows and Linux. I guess LCL-Qt is probably the closest equivalent to CLX. But do people actually use LCL-Qt under Windows?

Regards,
- Graeme -

Juha Manninen wrote

Can they also bind to recent QT versions? I doubt.

No need, because Kylix comes with its own Qt library - hence the applications still run perfectly on today's systems.

Regards,
- Graeme -

Il 28/06/2014 01:18, Juha Manninen ha scritto:

It's true only if you're dealing with sophisticated users. A plain user will fail to grasp the difference between a grayed button and another, and you'll get a phone call in the middle of the night from Hong Kong or from Santiago, claiming that the touch screen is broken, because touching a button doesn't provide any action! (Usually those things occur in places where the time zone makes them work when you're asleep :-( ) If you notice, all visual applications meant for plain users (cash dispensers, buying machines, self check-in, info terminals, restaurant and hotel management, etc.) show only active controls, and hide all the rest.

Giuliano

Giuliano Colla wrote

Graeme Geldenhuys who had problems of the same sort ended up designing his own widgetset. I'm more modest, and I look to a design mediator.

If there is something missing from fpGUI to help you migrate your projects off Kylix, we can discuss this in private or on the fpGUI newsgroup.

I have done my fair share of project migrations (VCL->CLX->LCL->fpGUI), and porting VCL/CLX/LCL widgets, so I understand the amount of work that is involved. Not all such work is viable, but it would still be interesting hearing your thoughts.

Regards,
- Graeme -

Il 28/06/2014 14:47, Graeme Geldenhuys ha scritto:

My current main problem is to provide support to hundreds of installed applications, providing updates, enhancements etc. Therefore migrating to a different project frame is a possible option, but not the first one. My current goal, i.e. extending Lazarus IDE to provide a full support to non LCL WS, has Kylix as a primary target for that reason, but I also had fpGUI in mind, because I share the philosophy behind it. Once verified if and how the primary goal can be reached, all the rest may come.
It would be a pleasure for me to take advantage from, and possibly contribute to, a project which I like.

Giuliano

Giuliano Colla wrote

My current main problem is to provide support to hundreds of installed applications, providing updates, enhancements etc. Therefore migrating to a different project frame is a possible option, but not the first one.

I fully understand that.

Regards,
- Graeme -

I assume they are patched?

Fun as it may be, it is probably only postponing the inevitable. Still it can be worth the effort to avoid converting all of them.

That being said, I wonder if it really belongs to Lazarus. It never was styled as a general purpose IDE. OTOH, if this work adds some flexibility to the designer, that would be a good thing.

Il 28/06/2014 20:30, Marco van de Voort ha scritto:

Nope. A Kilyx binary compiled under a RedHat 9 (Kernel 2.4.27 or so) runs under CentoOs 6 as it is. You only need to provide the Borland supplied Qt library (libborqt.so) in the loader search path. It also runs under a Linux From Scratch, with the latest 3.x kernel. But I prefer to recompile under the new platform, to make sure there are no libc incompatibilities which might pop up unexpectedly in the long run. However the sources are left untouched. I believe this be a sign of good design, from the Borland's good old times...

Lazarus provides a wonderful IDE, and supports already quite a number of widgetsets. The added capability of supporting non-LCL widgetsets, opens quite a number of interesting evolutions, where non-LCL can take advantage of a large existing codebase, and LCL may take advantage from the comparison with different approaches.

Giuliano

under CentoOs 6 as it is. You only need to provide the Borland supplied Qt library (libborqt.so) in the loader search path. It also runs under a Linux

From Scratch, with the latest 3.x kernel. But I prefer to recompile under

the new platform, to make sure there are no libc incompatibilities which might pop up unexpectedly in the long run. However the sources are left untouched. I believe this be a sign of good design, from the Borland's good old times...

As I said I don't think that's necessarily a sign of good design, but more a sign of the Borland Qt library not being developed any further (and the X11 core protocol has been stable for decades so no breakage expected here either). I'm sure it would be different if they had continued to work on Kylix till today, because then they'd tried to incorporate new functionality like is done with Delphi or Lazarus.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140629/c166900d/attachment-0001.html>

Il 29/06/2014 09:40, Sven Barth ha scritto:
[...]

IMHO opinion good design means:
1) when you conceive something take into account from the beginning that enhancements and new functionalities will be added in future.
2) When incorporating new functionalities avoid to break existing ones.

Related to the good old times of Borland, the evolution from Kylix 1 up to Kylix 3 added quite a number of functionalities, but didn't affect existing code. The same holds true for a long part of Delphi's history. Until they lost some basic notions of good design, and began taking shortcuts.
Speaking about X11, you may notice that a protocol conceived decades ago is still capable to support the fancy effects of today desktops. Of course implementation has been rewritten a remarkable number of times, but without affecting existing applications. Again, good design.

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140629/48cced6a/attachment.html>

Giuliano Colla wrote

...

Seems like you describe shortcomings in the LCL that are doubtlessly worse than it could be.

Hence the decent way of handling things would be to improve the LCL, rather than to try to do "normal-purpose" FPC based GUI enabled projects that avoid using the LCL.

-Michael

Michael Schnell wrote

than avoid using the LCL.

OK using another _existing_ GUI framework (like mseGUI) might make sense, as well.

-Michael

Michael Schnell wrote

Unfortunately this is even true if you do TThread.Queue with a fake thread pointer, as it internally checks using GetCurrentThread.

In fact the first parameter (Thread) in the class procedure TThread.Queue is just use to mark the event, so that it can be removed by the procedure TThread.RemoveQueuedEvents(aThread: TThread;...

Anyway, for me, the lacking full compatibly with the other Widget Types' "Application.QueuAsyncCall" in case this function is called in the main thread will not make me do a completely different (i.e double-Queue-based) design for the TTimers in this NoGUI Widget Type.

IMHO a decent way would be to remove the feature from TThread.Queue that a simple call is done when used in the Main thread.

If Course I would also happily use a different TThread class function instead of Queue, if provided if the fpc team decides that TThread.Queue really needs this Delphi compatible quirk (while I can't see any use of calling TThread.Queue in the main thread, and even here would not have a dangerous incompatibility it the call is delayed).

-Michael

Michael Schnell wrote

Hence the decent way of handling things would be to improve the LCL,

In the past I have done just that. But due to the design goals of LCL (being as native as possible), some changes simply ain't possible, or only possible in some backend toolkits (eg: QT), but not possible in others (eg: Win32). This inconsistency of LCL and incompatibility of backend toolkits is what Giuliano and myself have fought with. In hobby projects that might be fine, but in commercial multi-platform apps that is unacceptable.

Years back I've made my peace with LCL, and then started fpGUI to solve our company's development needs. It worked out very well. I still use Lazarus IDE though - it is an excellent tool to write code in.

Regards,
- Graeme -

Graeme Geldenhuys wrote

In hobby projects that might be fine, but in commercial multi-platform apps that is unacceptable.

I see.

Regarding myself, I in fact don't like taking the enhanced effort of beatifying the GUI (and Delphi-introduced Windows Widget Set compatibility) in consideration too much. For me GUI is just a necessary must to allow for user interaction and should be as restricted and efficient as possible. Hence even the offering of the LCL seems bloated to me and I would not mind restricting it to commonly usable widgets.

Of course packages that enhance the standard set (in additional groups) always are welcome and should be decently documented regarding the supported external widget set(s).

Regarding the IDE, I think it would be great, if the Widget selection offered in the could be GUI Designer could be project-depending: i.e. reduced / modified / enhanced) if in a project I select a certain WidgetType setting. (Or is something like this already in place ? )

-Michael

You obviously don't often get in contact with clients and marketeers.

While I agree with your concept, in practice, the UI must be as bloated as possible, showing as much as possible info, and preferably as 'hip' as possible (whatever hip means on that particular instant and place).

Michael.

Michael Van Canneyt wrote

You obviously don't often get in contact with clients and marketeers.

I Do. But we do embedded stuff and not (very often) Software that runs visibly on PC screens.

So this obviously is a different market ;-) .

-Michael