On Fri, 8 Apr 2022, Mattias Gaertner via lazarus wrote:
On Wed, 6 Apr 2022 12:56:17 +0200 (CEST)
Michael Van Canneyt via lazarus <lazarus@lists.lazarus-ide.org> wrote:
Hello,
I'm probably kicking in an open door when I'm saying that lazarus
evolves and grows. This is good news, obviously.
But I have now more tabs on the component palette than can fit on the
screen. There is a dropdown with the tabs, but that's hardly usable
to quickly locate a component.
I have therefore 3 propositions/requests:
1. Currently a component is identified by its class name.
This should be enhanced: a component must be identified with
UnitName.Name. a unit name is a "namespace" and so MyControls.TButton
<> StdCtrls.TButton.
Only if you want to support reading different TButton in one
application.
But that is exactly what I want to support ?
If I want to implement my own button, descendent of the standard TButton or not:
Except for the restriction during streaming, I see no reason why I would
have to name my own button TMyButton, since the 'my' is implicit in the fact
that it is implemented in unit MyControls.
In code, you can perfectly distinguish the 2 buttons by prefixing the class name
with the unit name in case you are using the 2 units with a TButton.
You currently cannot do the same when streaming. I propose to fix this.
Units are namespaces, they're simply not being used correctly:
Borland simply didn't think it through completely when they implemented the
streaming.
And unfortunately they failed to address it when they implemented FMX and dotted units,
that was the time when they should have fixed the problem...
This problem has been on my mind since a long time, but it simply becomes
more acute now with the designer support for pas2js.
(You may remember that I mentioned it during one of our meetings with the
editor of Blaise pascal, some years back)
The IDE sets the TReader events and controls what component classes are
found.
Why do you need to implement custom handling ?
The standard mechanism is not sufficient ?
I can only think of the JIT form but all other things should work as-is ?
Currently there are several component name clashes in the pas2js
and FPC class trees.
The component clashes can be solved by solving problem point 2.
Not the case above.
2. Similarly, it should be possible somehow to say
'this component is only for environment X' where X can be defined
by the user.
RegisterComponents has the "Page".
Maybe it is sufficient to apply these environment tags to pages,
instead of per component.
That is fine for me, but does not solve the above problem.
They are different problems:
- one is to limit the number of components to a list that is known to be
usable for the kind of application you are making
- The other is to support components that have the same name, but are
implemented in a different unit. (i.e. actually use the namespaces)
When I am working on a webserver application or a service
application, it makes no sense to show all visual controls.
Project/package needs a field to select the component environment.
Yes.
Likewise, some components only make sense for a pas2js
application.
I am aware of the 'restrictions' on the object inspector,
and in a sense my proposal is to extend/generalize this.
3. Please add a search edit in the component palette, as delphi has
it: typing in that edit should reduce the visible tabs to show only
tabs that have a component with the typed text in the classname, just
like the one on the component window... (the component window is IMO
not really usable if you are not using a docked IDE)
I would think all proposals are feasible, but I can of course be too
optimistic :)
There will be some problems when the user opens a form from a different
environment, e.g. while a lcl project is open and user opens a web
unit+form.
That can't be helped. But this is currently also the case if you open a form
for which some of the components are not installed.
Probably the form should also have an indicator of the 'environment' it uses,
so the IDE can warn. It could be streamed with the DefineProperties() so the
user is unaware.
Michael.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
