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.

Currently there are several component name clashes in the pas2js and FPC class trees.

2. Similarly, it should be possible somehow to say 'this component is only for environment X' where X can be defined by the user.

When I am working on a webserver application or a service application, it makes no sense to show all visual controls.

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 :)

Michael.

Michael Van Canneyt via lazarus schrieb am
Mi., 6. Apr. 2022, 12:56:

The streaming system can't differentiate by unit name, so this simply isn't possible.

3. Please add a search edit in the component palette, as delphi has it:

Why don't you use the component list instead of the palette then? This already provides a search.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220406/563e72de/attachment.htm>

I know that.

We simply need to adapt the streaming system so it can, I already studied that, it's fairly trivial:

* When writing: write UnitName.ComponentName instead of ComponentName. A trivial change, which can be done in a backward compatible manner.

* When reading, there are 2 lines that must be changed: One in GetClass and one in TReader.FindComponentClass.

* To handle the text format, 2 lines need changing.

So this is not exactly lots of work.

If you read my message correctly, you'll see that I know this. Additionally my last sentence tells you why I don't use it...

Michael.

Michael Van Canneyt via lazarus schrieb am
Mi., 6. Apr. 2022, 14:47:

But then this needs to be in FPC first and there it will only be officially available once 3.4.0 is released. And since Lazarus supports the last two releases it would need to be handled in a way that allows the user to cater to older FPC versions as well.

Gotta admit that I had only skimmed the last sentence ^^'

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220406/0bf56c77/attachment.htm>

Sorry what do you mean with "component window"? There's one in menu "View" > "Components" (this is not the one which opens by clicking the down-arrow at the right of the component palette), and this seems to do exactly what you? require after checking "Keep open".

Yes. Hence the 'backwards compatible' writing.
A global flag to set a default in the writer should suffice.

I'm just proposing things to move forward, hoping to get feedback, being informed of possible pitfalls.

That the "unit scoped identifier names" part will not be ready tomorrow was clear to me before I asked the question. But the first step is asking :-)

Michael.

As I replied to Sven: I know.
I am indeed talking about that window, and I consider this window simply not usable in SDI mode (which is the mode I work in).

The component palette is what I use, so it is natural to ask to improve that.

and I suspect I am not alone in my preference:
it's not for no reason that Embarcadero reinstated the component palette after trying to get rid of it in a couple of Delphi versions.

Michael.

Michael Van Canneyt wrote

* When writing: write UnitName.ComponentName instead of ComponentName. ? A trivial change, which can be done in a backward compatible manner.

It only will break compatibility with Delphi needlessly.?? This will complicate making e.g. demoes for shared library packages.

If component names have units,? and units have a package (vcl. etc) prefix, maybe it is simply enough to register the prefix in the reader library and then disambiguate between the various units based on the package prefix.

The default would remain VCL (or LCL, depending on what is chosen) to remain backwards compatible. This way the incompatibility is on a single point rather than in every streamed component.

I must still see these demos that can be compiled with Delphi and Lazarus. The property names of components and controls in LCL/VCL are already different, so your intended scenario is simply imaginary and non-existent.

Every package which works for Delphi and Lazarus that I've seen has separate demos for Lazarus and Delphi for this reason.

So it's not like this new feature would worsen the situation.

Units are already packages (or namespaces) by themselves. That is why they were invented. No need to add a second layer.

And as said, I would introduce a flag to make the behaviour backwards compatible. Only writing is affected. People that need to write 100% delphi compatible streams just need to set the flag. Done.

Michael.

Only if you want to support reading different TButton in one application.
The IDE sets the TReader events and controls what component classes are found.

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.

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.

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.

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.

Mattias

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.

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.

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.

Even if there are one or two property names different, a simple opening of the form fixes that.? A different streaming system won't fix that.

The duplications are within sets of units with similar names for different component packages. It is only logical to also use that. There is no need to force the unit as disambiguator.

Or reverse it. Make that flag default, and the few people that use register both VCL and web components within one project reverse it.

I want to be able to use the unit as disambiguator.

That's the whole point of the exercise.

But given that we will offer the backwards compatibility flag, it is not 'forcing'.

Michael.

That is clear. What isn't clear is why this is needed in a way that forces changes (and incompatibilities) on users apps to solve IDE problems.

IOW in which cases is disambiguation in the class registration of the generated app needed?

Sure, the IDE is also a FPC/Lazarus app, but it has more leeway for solutions that doesn't require changes to the way EVERY APP streams its forms.

This is a nonsense argument to make discussion go away. Enough such flags that an user only finds out when he is actually having problems is enough to turn them away from Lazarus permanently.

In the first place, the IDE is not the problem.
The streaming is, see my reply to Mattias.
The IDE just follows the streaming mechanisms available.

I don't understand why do you say it forces changes and incompatibilities ? Because it does not. Whatever worked will continue to work.

The streaming currently has a header: TPF0. (as Delphi has)

If we change the header to TPF1 for streams with scoped identifiers, all will work as-is as we can detect in the reader what to expect, set flags accordingly. The text format may also need a similar change, I didn't check this yet with 100% certainty.

The only change needed is to tell the writer that you want scoped names. That is entirely optional. The IDE can decide to use it - or not: it can perfectly detect whether they are needed.

The IDE of course needs to know that the namespaces can be there and prepare for it: allow scoped identifiers. Hence my mail.

For the user I think this is all transparent.
Those that use streaming outside the LCL can use the flag to disable scoped writing (or we leave unscoped the default).

I have not heard any technical arguments to the contrary.

Michael.

Have a virtual method in tpersistent that is used for the streaming identifier. Default it returns the classname (and everything remains the same for existing classes), and you can override it to also return the unitname.

I understand a lcl controls.TButton and a web controls.TButton, but that would not clash in one application.

So the situation is that - for whatever reasons - you ended up with two TButton in one app and you are not allowed to rename them. Worse, you want to drop the two TButton on the same form.

Correct?

Error handling, jit stuff, visual form inheritance. The standard mechanism is for apps, the events are for the IDE.

[...] 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.

Yes. Note that the environment and the unitname extensions are independent features with different side effects. To avoid confusion, let's discuss each in separate threads.

Mattias

You're even farther from home with this solution, because then you depend on the user: 2 classes can return the same name.

Classname and unit name are a unique identifier, guaranteed to be unique (in your project) by the compiler itself.

Michael.

Marco van de Voort via lazarus schrieb am
Fr., 8. Apr. 2022, 11:58:

The use case that Michael has in mind is that inside an app you have a StdCtrls.TButton and a MyControls.TButton. Right now one *must* rename ones own even though the full name including unit name is unique.

Solving this would at the same time allow the IDE to have a TButton for both the LCL and e.g. Web Components Library. Right now they need to be named differently like WebCtrls.TWButton.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220408/85824f72/attachment.htm>

Exactly so. I can't explain it clearer than this.

Streaming destroys the namespaces that units offer.

And while I've been aware of this issue for a long time and have studied the solution, the second problem is now becoming acute: I have 2 TJSONDatasets and 2 TRESTDatasets... (and more will follow)

The solution (activate unit scoped identifiers for streaming) is just taking existing concepts to their logical conclusion.

It's simply a pity Borland didn't go all the way when they designed the streaming; All I am proposing is to complete the work.

(in a backwards compatible manner, to boot)

Michael.

But that doesn't make it necessary to rename TButton to Stdctrls.TButton. It only means MyControls.TButton must always be qualified. (See the subthread with Mattias).

We shouldn't fix every minor issue with a breaking change and pray the users that are hit by this will find the umpteenth boolean switch to fix it (and can change it early enough, e.g. what about class registration in initialization sections?).

[...] Solving this would at the same time allow the IDE to have a TButton for both the LCL and e.g. Web Components Library. Right now they need to be named differently like WebCtrls.TWButton.

Note that if you just want to support two TButton, then you don't need to extend Classes. You can use TReader.OnFindComponentClass. Only if you want two different TButton on the same form you need the unitname.tbutton.

I will try to summarize:

a) Extend lfm to support unitname.classname and extend IDE to allow registering classnames twice.

Pro: Allows two TButton in the same app, even on the same form.

Con: Require changes in Classes (FPC release)

Con: old and new lfm file troubles (old/new FPC, old/new IDE)

b) Extend IDE with environment tags for pages and allow registering classnames twice for different environments.

Pro: IDE could show context sensitive component palette

Pro: allows two TButton in IDE

Con: does not support two TButton in one app, unless app sets TReader.OnFindComponentClass

Con: troubles with old IDE

Note that a) and b) are not xor - both can be implemented.

Mattias

To support 2 different TButtons at runtime, no hook is needed if you don't drop them on the same form. The entry in field classtable will automatically point to the correct one.

It's only needed if there is no field, then you will need a hook (as in the IDE which - if I am correctly informed - uses a JIT form).

Exactly.

a/ I don't think that requiring a special hook to accomodate something that is baked into the language is a correct approach. The language provides scoped names, so the streaming should support this correctly without resorting to "hacks". It should have been so since day 1.

b/ This can be done today already without waiting for a/ and thereby make using similarly named components possible for pas2js and native apps.

You may want to enable setting multiple environments for a page: e.g. TTimer is usable in a service and in GUI app. Same for data access. (but it should not be available for pas2js) While I am not against doing it for a page, I think doing it at the component level is in the end the more powerful choice. (Delphi does it that way)

Michael.

I have used the "Components" window in a non-docked environment with no problems. I removed the component palette altogether. IMO the point is to use it as a dialog, not as a constantly open IDE window.

My workflow is: open the Components window with a keyboard shortcut, find the component by typing, place the component where wanted with a mouse-click, close the window.

That brings me to the 2 issues I found:

1.) I used to open the Components window with Ctrl+Alt+P. I have a short-cut associated with it (see the attachment). But the shortcut is not recognized (I press Ctrl+Alt+P and it does nothing). It looks like an application-wide problem. The shortcut is not recognized in the "Choose a key..." dialog in IDE Options -> Key Mappings either.

Strange is that Ctrl+Alt+D (show desktops) works fine. Maybe it is just my PC that eats the Ctrl+Alt+P shortcut? Can anybody confirm? I am on Windows 10.

2.) When the "Keep open" checkbox is unchecked and I single-click on a component to select it and place it with a mouse click on the form (no double-click), the Components window is not closed.

Is it wanted? Shouldn't be the window closed?

Thanks
Ondrej

-------------- next part --------------
A non-text attachment was scrubbed...
Name: components-window.png
Type: image/png
Size: 43167 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220412/fb40cf92/attachment-0001.png>