Kostas Michalopoulos wrote 5 lines
On 10/10/25 9:50 PM, Michael Van Canneyt via lazarus wrote:
> Ideally the user needs only 1 component, which is why I chose the current
> approach.
Why is this desirable though?
Because IMO it makes it more easy to use.
Especially in code:
In your approach the developer needs to create 2 classes. In my approach he needs to create only 1 class and set one or more properties.
Show quoted text 8 lines
Lazarus already has components that you use with other components to provide
flexibility, such as the database components, so having this separation
between the "front end" and "back ends" as different components is already an
established practice - and does take advantage of using Lazarus' visual
tools.
And if anything, TLLMClient and TLLMProtocol feel a lot like TDataSource and
the various TDataSet descendants.
I felt it is more like a database connection and drivers for a particular database.
I exactly wanted to get away from the various TSQLConnection descendants we have now and move more to a TSQLConnector kind of approach.
Show quoted text 7 lines
The current approach is also quite fragile and has hidden and unnecessary
complications. For example if you install the package in Lazarus, the
package's uses clause will include all the individual LLM protocol units
which will auto-register themselves and then they will appear in
TLLMProtocol's settings drop-down menu. However if you select one without
including it manually in the code, starting your application will throw an
exception about an unknown protocol.
See below.
Show quoted text 7 lines
And considering that you *do* need to manually include the protocol units
anyway, this doesn't really save the user anything by only requiring them to
drop a single component in the form - you are replacing the need to drop a
second component by having them manually go and include the llm protocol unit
(something that Lazarus would do automatically if you dropped the protocol as
a component in the form).
No worries there, I am going to have this added automatically when you select the protocol.
Show quoted text 16 lines
> But having more detailed configuration can be achieved while maintaining
> the
> single-component approach. Simply by having a TModelConfiguration sub-
> component in TLLMClient, which is created automatically using a correct
> class when you set the protocol.
>
> Then it will visually be part of TLLMClient in the object inspector,
> and can still contain any number of additional properties (and events) to
> fit
> a particular model.
Perhaps this particular will work but TBH i think the whole global
registration thing is more limiting, fragile and more complicated than it
needs to be (there is a lot of code in there that only exists just to handle
that global list), considering Lazarus already provides means for doing
exactly that sort of thing (with established use).
This code is under the hood. Only the component developer sees it, and he only needs to add one line to register his 'protocol'. Not exactly the end of the world in terms of code.
The end user (the main target of this all) only sees one component and some properties he can set.
But I'll think about your suggestion.
As a sidenote, i'd suggest placing the LLM and MCP components under the same
component category (something like "AI" or "ML" or "Machine Learning" or
something like that), as it is annoying to have a single tab in Lazarus take
all the space for itself just for 1-2 icons inside.
Good suggestion, done.
Thanks for pointing it out, fixed.
Michael.
