From ganmax at narod.ru  Sat Jul  1 00:49:11 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Sat, 1 Jul 2023 01:49:11 +0300
Subject: [Lazarus] Lazarus trunk version number
In-Reply-To: <84860fdd-28bc-612a-a592-50d9af6e5bba@fastwebnet.it>
References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de>
 <CAPN1EhB2uX3c90tDO2bX-TY6xp-hUFrtbaTyq9SO690JZbSEUQ@mail.gmail.com>
 <alpine.DEB.2.22.394.2306301242300.746900@home>
 <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de>
 <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru>
 <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
 <alpine.DEB.2.22.394.2306301549590.757499@home>
 <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru>
 <alpine.DEB.2.22.394.2306301613100.757499@home>
 <20230630194037.34b71bc8@limapholos>
 <84860fdd-28bc-612a-a592-50d9af6e5bba@fastwebnet.it>
Message-ID: <54d362cd-4582-c1a4-8b33-11eeb24e24b8@narod.ru>

30.06.2023 22:16, Giuliano Colla via lazarus ?????:
> <RANT>

I promise, this is the last mail from me in this thread. :)

> If the brilliant minds which have elaborated a new numbering scheme had 
> spent their time in something more productive, such as making life a 
> little bit easier to developers, I believe that the Lazarus community 
> would have appreciated much more!

The same holds true for writing rants in mailing lists. ;)

> For instance, there is the bad habit to "deprecate" without considering 
> what happens to developers which must maintain their programs. I found 
> it rather frustrating to replace all occurrences of clDark with 
> clDkGray, just because clDark had been deprecated, instead of simply 
> replacing the definition wit a line in types clDark = clDkGray.

Sigh, what can I say, just some numbers.

1. clDark = TColor(-5), clDkGray  = TColor($808080). These numbers are 
not equal.
2. clDark is deprecated on 23.11.2008 with a bunch of other CLX colors. 
All these colors are NOT present in Delphi. Your code emitted warnings 
at least for 10 years!
3. ClDark et al. were IFDEFed out (define DefineCLXColors), not removed 
(sic!) on 30.09.2018.

> I've been taught that the golden rule to make code reusable is to hide 
> the implementation and expose only the feature. Who cares how a color is 
> implemented, provided that it shows the same? The same holds true for a 
> lot of deprecations, which could be easily hidden without any adverse 
> effect.
> 
> </RANT>

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From giuliano.colla at fastwebnet.it  Sat Jul  1 02:13:45 2023
From: giuliano.colla at fastwebnet.it (Giuliano Colla)
Date: Sat, 1 Jul 2023 02:13:45 +0200
Subject: [Lazarus] Lazarus trunk version number
In-Reply-To: <54d362cd-4582-c1a4-8b33-11eeb24e24b8@narod.ru>
References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de>
 <CAPN1EhB2uX3c90tDO2bX-TY6xp-hUFrtbaTyq9SO690JZbSEUQ@mail.gmail.com>
 <alpine.DEB.2.22.394.2306301242300.746900@home>
 <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de>
 <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru>
 <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
 <alpine.DEB.2.22.394.2306301549590.757499@home>
 <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru>
 <alpine.DEB.2.22.394.2306301613100.757499@home>
 <20230630194037.34b71bc8@limapholos>
 <84860fdd-28bc-612a-a592-50d9af6e5bba@fastwebnet.it>
 <54d362cd-4582-c1a4-8b33-11eeb24e24b8@narod.ru>
Message-ID: <9e1abf3f-2255-fe7a-3470-7138820c664c@fastwebnet.it>

An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230701/7e583895/attachment.htm>

From ganmax at narod.ru  Sat Jul  1 02:18:17 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Sat, 1 Jul 2023 03:18:17 +0300
Subject: [Lazarus] Lazarus trunk version number
In-Reply-To: <9e1abf3f-2255-fe7a-3470-7138820c664c@fastwebnet.it>
References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de>
 <CAPN1EhB2uX3c90tDO2bX-TY6xp-hUFrtbaTyq9SO690JZbSEUQ@mail.gmail.com>
 <alpine.DEB.2.22.394.2306301242300.746900@home>
 <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de>
 <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru>
 <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
 <alpine.DEB.2.22.394.2306301549590.757499@home>
 <21f268e5-6212-0581-67b9-16f8d4c89ba7@narod.ru>
 <alpine.DEB.2.22.394.2306301613100.757499@home>
 <20230630194037.34b71bc8@limapholos>
 <84860fdd-28bc-612a-a592-50d9af6e5bba@fastwebnet.it>
 <54d362cd-4582-c1a4-8b33-11eeb24e24b8@narod.ru>
 <9e1abf3f-2255-fe7a-3470-7138820c664c@fastwebnet.it>
Message-ID: <64fe37e3-8448-7c2a-82e2-ee9b95dd8ce1@narod.ru>

01.07.2023 3:13, Giuliano Colla ?????:
> Il 01/07/23 00:49, Maxim Ganetsky via lazarus ha scritto:
> 
>> 2. clDark is deprecated on 23.11.2008 with a bunch of other CLX 
>> colors. All these colors are NOT present in Delphi. Your code emitted 
>> warnings at least for 10 years!
> 
> Just for clarity, CLX *is* part of Delphi. It is the cross-platform 
> component library which has been alive at least up to Delphi 7. Why 
> force to modify user code, be it 10 years ago or last year, when those 
> colors are just constants which become a number in code?? What's the gain?

No, it is not:
https://en.wikipedia.org/wiki/Component_Library_for_Cross_Platform

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From pascaldragon at googlemail.com  Sat Jul  1 09:59:35 2023
From: pascaldragon at googlemail.com (Sven Barth)
Date: Sat, 1 Jul 2023 09:59:35 +0200
Subject: [Lazarus] Lazarus trunk version number
In-Reply-To: <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de>
 <CAPN1EhB2uX3c90tDO2bX-TY6xp-hUFrtbaTyq9SO690JZbSEUQ@mail.gmail.com>
 <alpine.DEB.2.22.394.2306301242300.746900@home>
 <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de>
 <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru>
 <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
Message-ID: <CAFMUeB81n9dObsZCEFoNV7t_JkFkEo884RXOfDGz01O_8rh2bg@mail.gmail.com>

Maxim Ganetsky via lazarus <lazarus at lists.lazarus-ide.org> schrieb am Fr.,
30. Juni 2023, 15:48:

> 30.06.2023 16:44, Maxim Ganetsky via lazarus ?????:
> > 30.06.2023 14:27, Martin Frb via lazarus ?????:
> >> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote:
> >>>
> >>>
> >>> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote:
> >>>
> >>>> On Friday, June 30, 2023, John Landmesser via lazarus <
> >>>> lazarus at lists.lazarus-ide.org> wrote:
> >>>>
> >>>>> perhaps that should have become 3.00 ?
> >>>>>
> >>>>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2
> >>>>> x86_64-linux-gtk2
> >>>>>
> >>>>> You are looking at trunk, the development version. See :
> >>>> https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer
> >>>
> >>> You might want to add some explanation for this new versioning
> >>> scheme to that page.
> >>
> >> Added.
> >
> > I made some improvements, hope it is even more clear now.
> >
> >>> The graph does not help.
> >>>
> >>> From what is currently there, I don't understand neither the logic
> >>> nor the need of this change.
> >> "Need"... Well, in terms of "because it solved the issue xyz" => then
> >> there is no need.
> >
> > Basically, version numbering is all about "marketing". By always
> > increasing major version we tell to the general audience that major
> > release indeed contains major changes (which is always the case).
> >
> > So we solve/improve "marketing" issues.
> >
> BTW, in my opinion FPC has similar issues and will benefit from such
> approach to versioning too.
>

In FPC the major number *has* a meaning, namely that there have been
significant changes in the code generator. Towards the 2.x series it was
the rewrite of the different backends and for the 3.x series it was the
introduction of the high level code generator.
The minor number is then to signify a new release with many new features on
top of the same base architecture and the release number is then to
differentiate between development and stable.

We don't follow "marketing".

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230701/753409e7/attachment.htm>

From michael at freepascal.org  Sat Jul  1 11:07:13 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Sat, 1 Jul 2023 11:07:13 +0200 (CEST)
Subject: [Lazarus] Lazarus trunk version number
In-Reply-To: <CAFMUeB81n9dObsZCEFoNV7t_JkFkEo884RXOfDGz01O_8rh2bg@mail.gmail.com>
References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de>
 <CAPN1EhB2uX3c90tDO2bX-TY6xp-hUFrtbaTyq9SO690JZbSEUQ@mail.gmail.com>
 <alpine.DEB.2.22.394.2306301242300.746900@home>
 <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de>
 <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru>
 <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
 <CAFMUeB81n9dObsZCEFoNV7t_JkFkEo884RXOfDGz01O_8rh2bg@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2307011105310.812677@home>



On Sat, 1 Jul 2023, Sven Barth via lazarus wrote:

> Maxim Ganetsky via lazarus <lazarus at lists.lazarus-ide.org> schrieb am Fr.,
> 30. Juni 2023, 15:48:
>
>> 30.06.2023 16:44, Maxim Ganetsky via lazarus ?????:
>>> 30.06.2023 14:27, Martin Frb via lazarus ?????:
>>>> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote:
>>>>>
>>>>>
>>>>> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote:
>>>>>
>>>>>> On Friday, June 30, 2023, John Landmesser via lazarus <
>>>>>> lazarus at lists.lazarus-ide.org> wrote:
>>>>>>
>>>>>>> perhaps that should have become 3.00 ?
>>>>>>>
>>>>>>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2
>>>>>>> x86_64-linux-gtk2
>>>>>>>
>>>>>>> You are looking at trunk, the development version. See :
>>>>>> https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer
>>>>>
>>>>> You might want to add some explanation for this new versioning
>>>>> scheme to that page.
>>>>
>>>> Added.
>>>
>>> I made some improvements, hope it is even more clear now.
>>>
>>>>> The graph does not help.
>>>>>
>>>>> From what is currently there, I don't understand neither the logic
>>>>> nor the need of this change.
>>>> "Need"... Well, in terms of "because it solved the issue xyz" => then
>>>> there is no need.
>>>
>>> Basically, version numbering is all about "marketing". By always
>>> increasing major version we tell to the general audience that major
>>> release indeed contains major changes (which is always the case).
>>>
>>> So we solve/improve "marketing" issues.
>>>
>> BTW, in my opinion FPC has similar issues and will benefit from such
>> approach to versioning too.
>>
>
> In FPC the major number *has* a meaning, namely that there have been
> significant changes in the code generator. Towards the 2.x series it was
> the rewrite of the different backends and for the 3.x series it was the
> introduction of the high level code generator.
> The minor number is then to signify a new release with many new features on
> top of the same base architecture and the release number is then to
> differentiate between development and stable.
>
> We don't follow "marketing".

It might be wise to communicate or document this somewhere: either on wiki or website.

I work almost 30 years on FPC, and even I didn't know this.

Michael.

From ganmax at narod.ru  Sat Jul  1 12:19:08 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Sat, 1 Jul 2023 13:19:08 +0300
Subject: [Lazarus] Lazarus trunk version number
In-Reply-To: <CAFMUeB81n9dObsZCEFoNV7t_JkFkEo884RXOfDGz01O_8rh2bg@mail.gmail.com>
References: <34e02499-6e70-6d8c-f5d3-a8efee213d2b@gmx.de>
 <CAPN1EhB2uX3c90tDO2bX-TY6xp-hUFrtbaTyq9SO690JZbSEUQ@mail.gmail.com>
 <alpine.DEB.2.22.394.2306301242300.746900@home>
 <53a2a645-e8c9-6989-8b8d-ff03c28e8a26@mfriebe.de>
 <7e3affdd-5f2c-e0a5-4078-e0b36d0f7c5d@narod.ru>
 <16a0de63-805d-ee60-283d-370222ce23b8@narod.ru>
 <CAFMUeB81n9dObsZCEFoNV7t_JkFkEo884RXOfDGz01O_8rh2bg@mail.gmail.com>
Message-ID: <173142cb-28c4-e5fb-b7d6-3fdcb3f402f5@narod.ru>

01.07.2023 10:59, Sven Barth via lazarus ?????:
> Maxim Ganetsky via lazarus <lazarus at lists.lazarus-ide.org> schrieb am 
> Fr., 30. Juni 2023, 15:48:
>
>     30.06.2023 16:44, Maxim Ganetsky via lazarus ?????:
>     > 30.06.2023 14:27, Martin Frb via lazarus ?????:
>     >> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote:
>     >>>
>     >>>
>     >>> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote:
>     >>>
>     >>>> On Friday, June 30, 2023, John Landmesser via lazarus <
>     >>>> lazarus at lists.lazarus-ide.org> wrote:
>     >>>>
>     >>>>> perhaps that should have become 3.00 ?
>     >>>>>
>     >>>>> Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2
>     >>>>> x86_64-linux-gtk2
>     >>>>>
>     >>>>> You are looking at trunk, the development version. See :
>     >>>>
>     https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer
>     >>>
>     >>> You might want to add some explanation for this new versioning
>     >>> scheme to that page.
>     >>
>     >> Added.
>     >
>     > I made some improvements, hope it is even more clear now.
>     >
>     >>> The graph does not help.
>     >>>
>     >>> From what is currently there, I don't understand neither the
>     logic
>     >>> nor the need of this change.
>     >> "Need"... Well, in terms of "because it solved the issue xyz"
>     => then
>     >> there is no need.
>     >
>     > Basically, version numbering is all about "marketing". By always
>     > increasing major version we tell to the general audience that major
>     > release indeed contains major changes (which is always the case).
>     >
>     > So we solve/improve "marketing" issues.
>     >
>     BTW, in my opinion FPC has similar issues and will benefit from such
>     approach to versioning too.
>
>
> In FPC the major number *has* a meaning, namely that there have been 
> significant changes in the code generator. Towards the 2.x series it 
> was the rewrite of the different backends and for the 3.x series it 
> was the introduction of the high level code generator.
> The minor number is then to signify a new release with many new 
> features on top of the same base architecture and the release number 
> is then to differentiate between development and stable.
Wow, I did not know this. Thanks for clarification. But see below.
> We don't follow "marketing".

The main motivation behind our change was the following: versioning 
should reflect development workflow. We didn't have concrete criteria 
for differentiating between major/minor version increase.

Everything else is basically a side-effect of versioning scheme 
simplification.

Still, I have a feeling that "marketing" issues (and yes, versioning is 
very small fragment in this picture) are grossly underestimated.

I know for sure:

1. News about major Lazarus releases felt into "mini-news" section on 
some news websites.

2. Users were confused about Lazarus versions (you can not believe it, 
but still).

3. People (general audience not following development process) simply 
don't understand when major version is not increased for prolonged 
periods (in case of FPC it is like 10 years?) and tend to think that the 
project is stagnating.

-- 
Best regards,
  Maxim Ganetskymailto:ganmax at narod.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230701/7ec5dbab/attachment.htm>

From nc-gaertnma at netcologne.de  Mon Jul  3 13:33:50 2023
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Mon, 3 Jul 2023 13:33:50 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
Message-ID: <20230703133350.6a3504bd@limapholos>

The Lazarus team is glad to announce the first release candidate of
Lazarus 3.0.

This release was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 3.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 3.0RC1" directory.

Checksums for the SourceForge files:
https://www.lazarus-ide.org/index.php?page=checksums#3_0RC1

Minimum requirements:

Windows:
   2k, 32 or 64bit.

FreeBSD/Linux:
   gtk 2.24 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.

Mac OS X:
   Cocoa (64bit) 10.12, Carbon (32bit) 10.5 to 10.14, qt and
   qt5 (32 or 64bit).

The gitlab page:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/lazarus_3_0_RC1

For people who are blocked by SF, the Lazarus releases from SourceForge
are mirrored at:ftp://ftp.freepascal.org/pub/lazarus/releases/

== Why should everybody (including you) test the release candidate? ==

In the past weeks the Lazarus team has stabilized the 3.0 fixes branch.
The resulting 3.0RC1 is now stable enough to be used by any one for
test purposes.

However many of the fixes and new features that were committed since
the release of 2.2.6 required changes to the code of existing features
too. While we have tested those ourselves, there may still be problems
that only occur with very specific configurations or one project in a
million.

Yes, it may be that you are the only person with a project, that will
not work in the new IDE. So if you do not test, we can not fix it.

Please do not wait for the final release, in order to test. It may be
too late. Once the release is out we will have to be more selective
about which fixes can be merged for further 3.x releases. So it may be,
that we can not merge the fix you require. And then you will miss out
on all the new features.

== How to test ==

Download and install the 3.0 RC1.
- On Windows you can install as a 2ndary install, that will not affect
  your current install:
  http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus
- On other platforms, if you install to a new location you need to use
--primary-config-path

In either case you should make backups. (including your primary config)

Open your project in the current Lazarus (3.0), and use "Publish
Project" from the project menu. This creates a clean copy of your
project.

You can then open that copy in the RC1. Please test:
- If you can edit forms in the designer
   - rename components / change properties in Object inspector / Add
     new events
   - Add components to form / Move components on form
   - Frames, if you use them
- If you can navigate the source code (e.g. jump to implementation)
- Auto completion in source code
- Compile, debug and run
- Anything else you use in your daily work


Mattias

From ganmax at narod.ru  Mon Jul  3 15:34:25 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Mon, 3 Jul 2023 16:34:25 +0300
Subject: [Lazarus] Call for translations updates for 3.0 release
Message-ID: <a27e3224-a265-f486-0b2a-76b7827644fc@narod.ru>

Hello.

Now that Lazarus 3.0 branch has been created, it is time for translators
to review and update their translations.

Check out fixes branch
(https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0 
), review and
update your translations and post updates to our issue tracker. See
<lazarus_dir>\languages\README.md for details.

Mark your reports with Lazarus version clearly in order to avoid confusion.

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From acardenas at bsd-peru.org  Sun Jul  9 08:50:16 2023
From: acardenas at bsd-peru.org (=?UTF-8?Q?Alonso_C=C3=A1rdenas_M=C3=A1rquez?=)
Date: Sun, 09 Jul 2023 02:50:16 -0400
Subject: [Lazarus] Call for translations updates for 3.0 release
In-Reply-To: <a27e3224-a265-f486-0b2a-76b7827644fc@narod.ru>
References: <a27e3224-a265-f486-0b2a-76b7827644fc@narod.ru>
Message-ID: <189396a53b4.11b59e8762032583.4017733699618180176@bsd-peru.org>

---- El lun, 03 jul 2023 09:34:25 -0400, Maxim Ganetsky via lazarus <mailto:lazarus at lists.lazarus-ide.org> escribi? ----



Hello. 
 
Now that Lazarus 3.0 branch has been created, it is time for translators 
to review and update their translations. 
 
Check out fixes branch 
(https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0 
), review and 
update your translations and post updates to our issue tracker. See 
<lazarus_dir>\languages\README.md for details. 
 
Mark your reports with Lazarus version clearly in order to avoid confusion. 
 
-- 
Best regards, 
 Maxim Ganetsky                  mailto:mailto:ganmax at narod.ru 
 
-- 
_______________________________________________ 
lazarus mailing list 
mailto:lazarus at lists.lazarus-ide.org 
https://lists.lazarus-ide.org/listinfo/lazarus 



------------------------------------------------------

Hello

I have submit a spanish translation update. Take a look at https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40370

Greetings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230709/45ee22ce/attachment.htm>

From zeljko at holobit.hr  Mon Jul 10 10:58:56 2023
From: zeljko at holobit.hr (zeljko)
Date: Mon, 10 Jul 2023 10:58:56 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <20230703133350.6a3504bd@limapholos>
References: <20230703133350.6a3504bd@limapholos>
Message-ID: <24f6b8ca-1526-3ece-31ab-fc9f6bdaf84b@holobit.hr>



On 03. 07. 2023. 13:33, Mattias Gaertner via lazarus wrote:
> The Lazarus team is glad to announce the first release candidate of
> Lazarus 3.0.
> 
> This release was built with FPC 3.2.2.
> 
> Here is the list of changes for Lazarus and Free Pascal:
> http://wiki.lazarus.freepascal.org/Lazarus_3.0_release_notes
> http://wiki.lazarus.freepascal.org/User_Changes_3.2.2
> 
> Here is the list of fixes for Lazarus 3.x:
> https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_3_0/
> 
> The release is available for download on SourceForge:
> http://sourceforge.net/projects/lazarus/files/
> 
> Choose your CPU, OS, distro and then the "Lazarus 3.0RC1" directory.
> 
> Checksums for the SourceForge files:
> https://www.lazarus-ide.org/index.php?page=checksums#3_0RC1
> 
> Minimum requirements:
> 
> Windows:
>     2k, 32 or 64bit.
> 
> FreeBSD/Linux:
>     gtk 2.24 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.
> 
> Mac OS X:
>     Cocoa (64bit) 10.12, Carbon (32bit) 10.5 to 10.14, qt and
>     qt5 (32 or 64bit).

Sorry for late response, Qt6 is missing.
Windows: Qt, Qt5, Qt6 (64bit only)
FreeBSD/Linux: Add Qt6.2 for qt6
MacOS: Add Qt6 (64bit only).

zeljko


From marc at dommelstein.nl  Mon Jul 10 12:31:51 2023
From: marc at dommelstein.nl (Marc Weustink)
Date: Mon, 10 Jul 2023 12:31:51 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <20230703133350.6a3504bd@limapholos>
References: <20230703133350.6a3504bd@limapholos>
Message-ID: <cdab1cf8-2188-55f7-6df3-4427a6b7ba6e@dommelstein.nl>

...

> == How to test ==
> 
> Download and install the 3.0 RC1.
> - On Windows you can install as a 2ndary install, that will not affect
>    your current install:
>    http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus
> - On other platforms, if you install to a new location you need to use
> --primary-config-path
> 
> In either case you should make backups. (including your primary config)
> 
> Open your project in the current Lazarus (3.0), and use "Publish
> Project" from the project menu. This creates a clean copy of your
> project.

Is 3.0 meant here as current version to publish your project, or should 
this be done in the current 2.x version ?

Marc


From alexander.hofmann at new-h.de  Fri Jul 14 16:00:29 2023
From: alexander.hofmann at new-h.de (Alexander Hofmann)
Date: Fri, 14 Jul 2023 16:00:29 +0200
Subject: [Lazarus] Transparent glphys with size constraints
Message-ID: <0e9c88d5-679f-301e-0f99-e317a8475ff6@new-h.de>

Dear all,

I've been trying to find out why some of my (speed/bit)button's glyphs 
don't show when I run my application, or after re-loading the project in 
the IDE.

Turns out, all those that don't display are 22x22 pixels in size and 32 
bpp (with transparency). I checked a few other image dimensions, and 
everything between 19x19 and 23x23 pixels shows the following symptoms:

- when loading the image into the "Glyph" property in the designer using 
the property editor, the image displays nicely (in the editor as well as 
on the form)

a speed-button with a red dot as image, transparent "edges"

- when starting the application, the glyph is not visible on the button

a speed button without a glyph

- after closing and re-loading the project in the IDE, the image is not 
shown on the button, and looks distorted in the property editor

speed button shown in the form designer, no glyph visible vs.

I tested dimensions of AxA with A in [15...25], and everything between 
19 and 23 shows that problem (as does 22x15 :-)). Also, the problem 
exists on Linux x64, Trunk with GTK2 interface. Qt5 and Qt6 show the 
image on the Form (Designer and App) but not in the property editor 
(distorted). GTK3 doesn't show the image on the form, but when being run 
(though in the wrong size). Windows x64 is fine as far as I can see, I 
currently cannot test Mac.

Note that images without transparency work, but as soon as it contains 
some transparency I get the error.

24 bit, no transparency, white background; in the designer:

speed button in the form designer, with a red dot and white background

when being run:

speed button, with a red dot and white background


For now, I'll just use different sized image with more transparency 
around them, or convert them to "use a single color as transparent 
color" mode, but it's somehow interesting what the cause might be...

I attached a small test project with some test images. The project was 
created on a HiDPI monitor, but I also saw that problem on "normal" 
screens, so I don't that should make a difference; but I currently 
cannot test that as well...

Best regards,

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VBy23zMgWLT206pf.png
Type: image/png
Size: 1314 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WQzBr2UhHZMZqY7L.png
Type: image/png
Size: 415 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EI0X5F8u5ni9c7uF.png
Type: image/png
Size: 556 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1AmaHuKoAx8ynHRG.png
Type: image/png
Size: 1036 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HjlMqHaAWSGdX5tk.png
Type: image/png
Size: 1031 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rqLO0a0KVU8ZLVYV.png
Type: image/png
Size: 938 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glyphs.zip
Type: application/zip
Size: 24155 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230714/c0c1eead/attachment-0001.zip>

From luca at wetron.es  Mon Jul 17 19:01:59 2023
From: luca at wetron.es (Luca Olivetti)
Date: Mon, 17 Jul 2023 19:01:59 +0200
Subject: [Lazarus] TThread.Queue vs Application.QueueAsyncCall
Message-ID: <792f3030-229a-f8ac-8207-80de5c08b8bd@wetron.es>

Hello,

TThread.Queue and Application.QueueAsyncCall more or less do the same 
thing (even if they use two different queues that are managed at 
different times in the main thread).

When it's better to use one or the other?

When you're not using Lazarus' TApplication obviously you cannot use 
QueueAsyncCall, but for a gui application which one is preferable?

Just curious, after having used "Synchronize" forever (the only option 
when I began using delphi, apart from PostMessage), I recently switched 
to QueueAsyncCall so that a thread can go on without waiting and now I 
discovered TThread.Queue.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

From nc-gaertnma at netcologne.de  Tue Jul 18 13:50:23 2023
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Tue, 18 Jul 2023 13:50:23 +0200
Subject: [Lazarus] TThread.Queue vs Application.QueueAsyncCall
In-Reply-To: <792f3030-229a-f8ac-8207-80de5c08b8bd@wetron.es>
References: <792f3030-229a-f8ac-8207-80de5c08b8bd@wetron.es>
Message-ID: <3d77340f-0972-5db7-3ba2-51a639ecded8@netcologne.de>



On 17.07.23 19:01, Luca Olivetti via lazarus wrote:
> Hello,
> 
> TThread.Queue and Application.QueueAsyncCall more or less do the same 
> thing (even if they use two different queues that are managed at 
> different times in the main thread).
> 
> When it's better to use one or the other?

Application.QueueAsyncCall has a Data: PtrInt parameter to pass some 
context and it is always called later, so this is useful for doing 
something after the current LCL event.
TThread.Queue has aThread parameter, so the call is removed when the 
thread is freed, and when you call it from the main thread it will 
execute immediately, so this is for worker threads to asynchronously do 
something in the main thread.


Mattias


From luca at wetron.es  Tue Jul 18 14:23:08 2023
From: luca at wetron.es (Luca Olivetti)
Date: Tue, 18 Jul 2023 14:23:08 +0200
Subject: [Lazarus] TThread.Queue vs Application.QueueAsyncCall
In-Reply-To: <3d77340f-0972-5db7-3ba2-51a639ecded8@netcologne.de>
References: <792f3030-229a-f8ac-8207-80de5c08b8bd@wetron.es>
 <3d77340f-0972-5db7-3ba2-51a639ecded8@netcologne.de>
Message-ID: <1a4c6877-2980-0a84-47e9-acc77d6acb74@wetron.es>

El 18/7/23 a les 13:50, Mattias Gaertner via lazarus ha escrit:
> 
> 
> On 17.07.23 19:01, Luca Olivetti via lazarus wrote:
>> Hello,
>>
>> TThread.Queue and Application.QueueAsyncCall more or less do the same 
>> thing (even if they use two different queues that are managed at 
>> different times in the main thread).
>>
>> When it's better to use one or the other?
> 
> Application.QueueAsyncCall has a Data: PtrInt parameter to pass some 
> context and it is always called later, so this is useful for doing 
> something after the current LCL event.
> TThread.Queue has aThread parameter, so the call is removed when the 
> thread is freed, and when you call it from the main thread it will 
> execute immediately, so this is for worker threads to asynchronously do 
> something in the main thread.

Yes, but they both allow the thread to run something asynchronously in 
the main thread (at different times but that's not really a concern).
Both put the method in a list and try to wake the main thread (if possible).
The main difference I see is that passing volatile data(*) is a little 
more convoluted with TThread.Queue(**) than with 
Application.QueueAsyncCall, but apart from that I see no big 
differences, that's why I'm asking when it's better to use one or the 
other (or if it doesn't really matter).

(*)  i.e. data that the thread can potentially modify *before* the main 
thread executes the method, but you want the main thread to see the data 
as it was when it was queued, like the example here 
https://wiki.freepascal.org/Asynchronous_Calls#Record_passed_to_async_function

(**) you need to create a class instance that stores the data and frees 
itself after executing the method.Maybe, due to the overhead of doing 
that, it's better to use QueueAsyncCall in these cases.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From steveg at nevets.com.au  Sun Jul 23 10:35:05 2023
From: steveg at nevets.com.au (Steve Gatenby)
Date: Sun, 23 Jul 2023 18:35:05 +1000
Subject: [Lazarus] MJPEG streamer
Message-ID: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>

Would anybody know if there is a component / code to enable reading an 
mjpeg stream from a http camera to a Lazarus form/panel (or anything really)

Dont mind installing libraries etc -

Looking to suit Linux specifically though

Thanks - SteveG


From lazarus at kluug.net  Sun Jul 23 10:48:40 2023
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Sun, 23 Jul 2023 10:48:40 +0200
Subject: [Lazarus] MJPEG streamer
In-Reply-To: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
Message-ID: <a2224d10-9654-d29a-74cb-d8abe83a3d45@kluug.net>

On 23.07.2023 10:35, Steve Gatenby via lazarus wrote:
> Would anybody know if there is a component / code to enable reading an 
> mjpeg stream from a http camera to a Lazarus form/panel (or anything 
> really)
>
> Dont mind installing libraries etc -
>
> Looking to suit Linux specifically though

I would try the VLC player component:
https://wiki.freepascal.org/Video_Playback_Libraries
http://lazplanet.blogspot.com/2018/01/how-to-make-simple-video-player-in.html

VLC can open a video stream from a RTSP camera.

Ondrej


From michael at freepascal.org  Sun Jul 23 10:48:52 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Sun, 23 Jul 2023 10:48:52 +0200 (CEST)
Subject: [Lazarus] MJPEG streamer
In-Reply-To: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
Message-ID: <alpine.DEB.2.22.394.2307231044180.1587022@home>



On Sun, 23 Jul 2023, Steve Gatenby via lazarus wrote:

> Would anybody know if there is a component / code to enable reading an mjpeg 
> stream from a http camera to a Lazarus form/panel (or anything really)
>
> Dont mind installing libraries etc -
>
> Looking to suit Linux specifically though

vlc can play media streams, so I think Libvlc can be used for this. 
The lazvlc.lpk contains a component that encapsulates vlc, it's just a
matter of feeding it the correct url.

Michael.

From bo.berglund at gmail.com  Sun Jul 23 21:44:47 2023
From: bo.berglund at gmail.com (Bo Berglund)
Date: Sun, 23 Jul 2023 21:44:47 +0200
Subject: [Lazarus] MJPEG streamer
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
Message-ID: <0h0rbi9mltdrldkioq7qu1189jai3cdliq@4ax.com>

On Sun, 23 Jul 2023 18:35:05 +1000, Steve Gatenby via lazarus
<lazarus at lists.lazarus-ide.org> wrote:

>Would anybody know if there is a component / code to enable reading an 
>mjpeg stream from a http camera to a Lazarus form/panel (or anything really)
>
>Dont mind installing libraries etc -
>
>Looking to suit Linux specifically though
>
>Thanks - SteveG

I have been using PasLibVlc from here:
https://prog.olsztyn.pl/paslibvlc/

in order to read/display/navigate mp4 video files in an editing application I
wrote a number of years ago.
It works very well on both Windows and Linux (Ubuntu and RaspberryPiOS).
The only requirement I am aware of is that VLC must be installed on the
development (and host) machines.

It is a bit old now (last update from 2020-07-05), but works just fine for me.


-- 
Bo Berglund
Developer in Sweden


From steveg at nevets.com.au  Mon Jul 24 01:35:01 2023
From: steveg at nevets.com.au (Steve Gatenby)
Date: Mon, 24 Jul 2023 09:35:01 +1000
Subject: [Lazarus] MJPEG streamer
In-Reply-To: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
Message-ID: <5d75773b-e5e3-616f-11f4-ff102396f3dd@nevets.com.au>


On 23/7/23 18:35, Steve Gatenby via lazarus wrote:
> Would anybody know if there is a component / code to enable reading an 
> mjpeg stream from a http camera to a Lazarus form/panel (or anything 
> really)
>
> Dont mind installing libraries etc -
>
> Looking to suit Linux specifically though
>
> Thanks - SteveG
>

Thank you all -

exactly what I was hoping for - possibilities to follow :)

I will post if / once I get it figured as may be useful to others



From michael at freepascal.org  Mon Jul 24 21:49:39 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Mon, 24 Jul 2023 21:49:39 +0200 (CEST)
Subject: [Lazarus] Unicode RTL
Message-ID: <alpine.DEB.2.22.394.2307242126210.1727809@home>


Hello,

I have just completed phase one of the "Unicode RTL" effort.

The 'Unicode RTL' is an effort to be more Delphi compatible:
- Char = Unicode Char and String = UnicodeString
- Provide dotted filenames.
Basically closer to the RTL as it exists in more recent versions of Delphi 
(essentially post - Delphi 2009)

This RTL will co-exist with the current RTL (single-byte char, no dotted
names), but will share the same codebase.

More explanations can be found here:

https://wiki.freepascal.org/FPC_Unicode_RTL

This coexistence of 2 RTLs is accomplished with 'Subtarget support'.

Subtarget support is a means to consistently apply a set of Free Pascal
compiler settings to everything that you compile.

Subtarget support is explained in more detail here:
https://wiki.freepascal.org/FPC_Subtarget_Support

While it is now used to create a unicode rtl, it could also be used to

* create a llvm-compiled RTL.
* create an rtl with debug info and one without. 
* compile the various Lazarus widgetsets into different directories
* ... any other things you may think of ...

all with a single installation of FPC.

For the second part of the effort, 'provide dotted filenames', the actual
work is finished, but still needs merging to trunk.

This second part is expected to be merged in the next days/weeks.

But today, using FPC trunk, you can now recompile the Free Pascal RTL, 
Packages and Utils (but not the compiler itself!) into a set of units where

Char = UnicodeChar
String = UnicodeString

To compile (and install) the unicode rtl, all you need to do is follow the
steps outlined in

https://wiki.freepascal.org/FPC_Unicode_RTL

Basically, this means creating a 2-line configuration file for the unicodertl
subtarget, and compiling the RTL, packages and utils with

make SUB_TARGET=unicodertl

For those that need/want more delphi-compatible code, I would love to hear
of your experience with the unicode rtl. I have done extensive testing, but
as practice shows, there will always be cases which defy ordinary test
cases...

If the 2 wiki pages need more explanations, please let me know and I will do
my best to improve the explanations.

Hopefully, in the near future the compiler settings dialog in Lazarus will also 
allow you to specify a subtarget.

Michael.

From michael at freepascal.org  Mon Jul 24 23:20:35 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Mon, 24 Jul 2023 23:20:35 +0200 (CEST)
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <20230724210508.37900105@BunnyMaster>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <20230724210508.37900105@BunnyMaster>
Message-ID: <alpine.DEB.2.22.394.2307242312170.1735101@home>



On Mon, 24 Jul 2023, Kirinn via fpc-devel wrote:

> Hi,
>
> A "unicode" RTL is of course great for targeting legacy Windows platforms,
> but for those of us on Linux, UTF-8 is the way.

It is not only for legacy windows platforms.
The target platform is secondary.

What to use depends more on your codebase than on your target platform.
There is a lot of Delphi code out there that assumes that string=unicodestring.

If, like my current company, you have a large Delphi application that you wish
to run on linux, then you may be better off with a unicode RTL.

> To this end, it would be
> helpful to add a paragraph on the wiki page underlining how to retain the
> single-byte RTL; or, if no user action is necessary, mention that, to set
> minds at ease. Thank you for this hard work!

No user action is necessary.

But your advice is good: I have added this to the page, and made clear
that the RTL as it currently exists, is still the default RTL.

Michael.

From luca at wetron.es  Tue Jul 25 09:08:20 2023
From: luca at wetron.es (Luca Olivetti)
Date: Tue, 25 Jul 2023 09:08:20 +0200
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307242312170.1735101@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <20230724210508.37900105@BunnyMaster>
 <alpine.DEB.2.22.394.2307242312170.1735101@home>
Message-ID: <bdae4452-f9e8-8e29-a32b-e7a138cd41b2@wetron.es>

El 24/7/23 a les 23:20, Michael Van Canneyt via lazarus ha escrit:

> 
>> To this end, it would be
>> helpful to add a paragraph on the wiki page underlining how to retain the
>> single-byte RTL; or, if no user action is necessary, mention that, to set
>> minds at ease. Thank you for this hard work!
> 
> No user action is necessary.
> 
> But your advice is good: I have added this to the page, and made clear
> that the RTL as it currently exists, is still the default RTL.

So those of us that don't need delphi compatibility can be sure that 
nothing will break?

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From michael at freepascal.org  Tue Jul 25 09:47:52 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Tue, 25 Jul 2023 09:47:52 +0200 (CEST)
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <bdae4452-f9e8-8e29-a32b-e7a138cd41b2@wetron.es>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <20230724210508.37900105@BunnyMaster>
 <alpine.DEB.2.22.394.2307242312170.1735101@home>
 <bdae4452-f9e8-8e29-a32b-e7a138cd41b2@wetron.es>
Message-ID: <alpine.DEB.2.22.394.2307250943460.1762884@home>



On Tue, 25 Jul 2023, Luca Olivetti via lazarus wrote:

> El 24/7/23 a les 23:20, Michael Van Canneyt via lazarus ha escrit:
>
>> 
>>> To this end, it would be
>>> helpful to add a paragraph on the wiki page underlining how to retain the
>>> single-byte RTL; or, if no user action is necessary, mention that, to set
>>> minds at ease. Thank you for this hard work!
>> 
>> No user action is necessary.
>> 
>> But your advice is good: I have added this to the page, and made clear
>> that the RTL as it currently exists, is still the default RTL.
>
> So those of us that don't need delphi compatibility can be sure that nothing 
> will break?

Unless I unwittingly introduced a bug somewhere (gods forbid ;)), nothing will break.

Backwards compatibility is and remains important.

Michael.

From nc-gaertnma at netcologne.de  Tue Jul 25 11:08:03 2023
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Tue, 25 Jul 2023 10:08:03 +0100
Subject: [Lazarus] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307242126210.1727809@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
Message-ID: <47f7e536-9533-fa4c-6d51-f0ef2d43f8c9@netcologne.de>

On 24.07.23 21:49, Michael Van Canneyt via lazarus wrote:
> [...]Hopefully, in the near future the compiler settings dialog in 
> Lazarus will also allow you to specify a subtarget. 

I will add it.


Mattias


From luca at wetron.es  Wed Jul 26 16:05:50 2023
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 26 Jul 2023 16:05:50 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <20230703133350.6a3504bd@limapholos>
References: <20230703133350.6a3504bd@limapholos>
Message-ID: <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>

El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:

> - Compile, debug and run

I don't remember the exact wording but, when converting the settings 
from lazarus 2.2 (which I copied in a different directory), it offered 
to use the fpdebug backend.

Then, when compiling a *existing* project, it tells me to use a suitable 
debugging format (with -gw3 selected, previously I used gdb with -g).
I accept but the breakpoints don't work.
I tried the other two options with the same result.
With gdb backend and -g the breakpoints work.

With a *new* project the breakpoints work even with the fpdebug backend.

This is under win32, under linux (64 bits), the breakpoints work even in 
the old project (the same one I used to test under win32).

In both cases (win/linux) I got lazarus' sources with git checking out 
the tag lazarus_3_0_RC1, "make bigide" then (not without problems) I 
rebuilt  it with my set of packages.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From ganmax at narod.ru  Wed Jul 26 16:36:59 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Wed, 26 Jul 2023 17:36:59 +0300
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
Message-ID: <e5cf6e03-525c-73c4-d604-3f59135bc031@narod.ru>

26.07.2023 17:05, Luca Olivetti via lazarus ?????:
> El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:
>
>> - Compile, debug and run
>
> I don't remember the exact wording but, when converting the settings 
> from lazarus 2.2 (which I copied in a different directory), it offered 
> to use the fpdebug backend.
>
> Then, when compiling a *existing* project, it tells me to use a 
> suitable debugging format (with -gw3 selected, previously I used gdb 
> with -g).
> I accept but the breakpoints don't work.
> I tried the other two options with the same result.
> With gdb backend and -g the breakpoints work.
>
> With a *new* project the breakpoints work even with the fpdebug backend.
>
> This is under win32, under linux (64 bits), the breakpoints work even 
> in the old project (the same one I used to test under win32).
>
> In both cases (win/linux) I got lazarus' sources with git checking out 
> the tag lazarus_3_0_RC1, "make bigide" then (not without problems) I 
> rebuilt? it with my set of packages.

I would recommend to checkout not the tag, but the tip of `fixes_3_0` 
branch. It already contains a number of important fixes.

If it can still be reproduced with it, please create an issue.

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From lazarus at mfriebe.de  Wed Jul 26 16:50:47 2023
From: lazarus at mfriebe.de (Martin Frb)
Date: Wed, 26 Jul 2023 16:50:47 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
Message-ID: <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>

On 26/07/2023 16:05, Luca Olivetti via lazarus wrote:
> El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:
>
>> - Compile, debug and run
>
> I don't remember the exact wording but, when converting the settings 
> from lazarus 2.2 (which I copied in a different directory), it offered 
> to use the fpdebug backend.
>
> Then, when compiling a *existing* project, it tells me to use a 
> suitable debugging format (with -gw3 selected, previously I used gdb 
> with -g).
> I accept but the breakpoints don't work.
> I tried the other two options with the same result.
> With gdb backend and -g the breakpoints work.
>
> With a *new* project the breakpoints work even with the fpdebug backend.
>
> This is under win32, under linux (64 bits), the breakpoints work even 
> in the old project (the same one I used to test under win32).

What happens to the breakpoint icon when you start the debugger?

Before you start the debugger, it should have a "?".
When you start it, what happens.
You can also check in the breakpoint-windows, if you make the first 
column wide enough there is some text.

----------
If you remove the breakpoint (can be done while the app is running / 
after you checked the above), is there a "small blue dot" in the gutter? 
On the very same line as the breakpoint had been?

Gdb would accept breakpoints at non-code lines.
FpDebug needs the breakpoint on a code line.

Note that
 ?? if condition then
 ???? exit;? /// this exit is only a codeline in -O- // with -O1 its 
optimized away

----------
Are there ways to reproduce it ?
Could sources be shared?

Otherwise I'll send instructions to produce log files.

From luca at wetron.es  Wed Jul 26 17:07:53 2023
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 26 Jul 2023 17:07:53 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <e5cf6e03-525c-73c4-d604-3f59135bc031@narod.ru>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <e5cf6e03-525c-73c4-d604-3f59135bc031@narod.ru>
Message-ID: <5c5e3278-eacc-d499-d82e-d769ae3408f3@wetron.es>

El 26/7/23 a les 16:36, Maxim Ganetsky via lazarus ha escrit:

> I would recommend to checkout not the tag, but the tip of `fixes_3_0` 
> branch. It already contains a number of important fixes.
> 
> If it can still be reproduced with it, please create an issue.

OK, I did a "git checkout fixes_3_0" then rebuilt the "ide with 
packages" (from within the old one) with the "clean all" option.

Same problem: the breakpoints don't work in an existing project using 
the fpdebug backend.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From luca at wetron.es  Wed Jul 26 17:18:00 2023
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 26 Jul 2023 17:18:00 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
Message-ID: <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>

El 26/7/23 a les 16:50, Martin Frb via lazarus ha escrit:

> What happens to the breakpoint icon when you start the debugger?
> 
> Before you start the debugger, it should have a "?".

Yes, state "?(On)"

> When you start it, what happens.

A pause simbol (two vertical white bars in a red circle), state "Pending 
(On)" (under linux the state is just "Enabled").

> You can also check in the breakpoint-windows, if you make the first 
> column wide enough there is some text.

That's what I reported as "state" above
> 
> ----------
> If you remove the breakpoint (can be done while the app is running / 
> after you checked the above), is there a "small blue dot" in the gutter? 
> On the very same line as the breakpoint had been?

No, not even under linux

> 
> Gdb would accept breakpoints at non-code lines.
> FpDebug needs the breakpoint on a code line.

It's on a code line, not a blank line nor a comment.

> 
> Note that
>  ?? if condition then
>  ???? exit;? /// this exit is only a codeline in -O- // with -O1 its 
> optimized away

Both breakpoints I tested are on an assignment that cannot be optimized away

> 
> ----------
> Are there ways to reproduce it ?
> Could sources be shared?

The projects I tested no, I'll see if I can find a simpler project with 
the same issue.


> Otherwise I'll send instructions to produce log files.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From luca at wetron.es  Wed Jul 26 17:26:17 2023
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 26 Jul 2023 17:26:17 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
 <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
Message-ID: <f7acb16c-0052-5716-5867-b6de03647592@wetron.es>

El 26/7/23 a les 17:18, Luca Olivetti via lazarus ha escrit:

>> Are there ways to reproduce it ?
>> Could sources be shared?
> 
> The projects I tested no, I'll see if I can find a simpler project with 
> the same issue.

I found a simple project that I can share but I'm not sure it's a good 
idea to send it here (the zip file is 143K).

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From luca at wetron.es  Wed Jul 26 17:39:28 2023
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 26 Jul 2023 17:39:28 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <f7acb16c-0052-5716-5867-b6de03647592@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
 <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
 <f7acb16c-0052-5716-5867-b6de03647592@wetron.es>
Message-ID: <cf41c3c5-eca9-73ba-14dd-f98f62ca3dbd@wetron.es>

El 26/7/23 a les 17:26, Luca Olivetti via lazarus ha escrit:
> El 26/7/23 a les 17:18, Luca Olivetti via lazarus ha escrit:
> 
>>> Are there ways to reproduce it ?
>>> Could sources be shared?
>>
>> The projects I tested no, I'll see if I can find a simpler project 
>> with the same issue.
> 
> I found a simple project that I can share but I'm not sure it's a good 
> idea to send it here (the zip file is 143K).

I can reproduce the issue with a lazarus build with "make clean ; make 
bigide" and a fresh pcp.

Bye

-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From lazarus at mfriebe.de  Wed Jul 26 17:42:06 2023
From: lazarus at mfriebe.de (Martin Frb)
Date: Wed, 26 Jul 2023 17:42:06 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
 <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
Message-ID: <c0834cd9-b8b9-1312-c27e-ec1da34ec2e7@mfriebe.de>

On 26/07/2023 17:18, Luca Olivetti via lazarus wrote:
> El 26/7/23 a les 16:50, Martin Frb via lazarus ha escrit:
>
>> What happens to the breakpoint icon when you start the debugger?
>>
>> Before you start the debugger, it should have a "?".
>
> Yes, state "?(On)"
>
>> When you start it, what happens.
>
> A pause simbol (two vertical white bars in a red circle), state 
> "Pending (On)" (under linux the state is just "Enabled").

So FpDebug did not find the source file.

The pause is used, because this can happen with DLL. And then the break 
may get set when the dll is loaded.
I assume that is not the case?

Anything about the filename? special chars? sym links?


>
>>
>> ----------
>> If you remove the breakpoint (can be done while the app is running / 
>> after you checked the above), is there a "small blue dot" in the 
>> gutter? On the very same line as the breakpoint had been?
>
> No, not even under linux
Then there are probably 2 files with that name => and the breakpoint is 
in the other file.

Could that be?

Or could the IDE know the file with a different directory than FPC does 
? (though that should still work)


From lazarus at mfriebe.de  Wed Jul 26 17:43:20 2023
From: lazarus at mfriebe.de (Martin Frb)
Date: Wed, 26 Jul 2023 17:43:20 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <f7acb16c-0052-5716-5867-b6de03647592@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
 <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
 <f7acb16c-0052-5716-5867-b6de03647592@wetron.es>
Message-ID: <b112a29e-6f2a-78d8-4a8c-627cfacc6bd8@mfriebe.de>

On 26/07/2023 17:26, Luca Olivetti via lazarus wrote:
> El 26/7/23 a les 17:18, Luca Olivetti via lazarus ha escrit:
>
>>> Are there ways to reproduce it ?
>>> Could sources be shared?
>>
>> The projects I tested no, I'll see if I can find a simpler project 
>> with the same issue.
>
> I found a simple project that I can share but I'm not sure it's a good 
> idea to send it here (the zip file is 143K).
>

You can send it directly to my mail? lazarus as name, and the 2nd part 
is mfriebe.de


From luca at wetron.es  Wed Jul 26 17:58:57 2023
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 26 Jul 2023 17:58:57 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <c0834cd9-b8b9-1312-c27e-ec1da34ec2e7@mfriebe.de>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
 <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
 <c0834cd9-b8b9-1312-c27e-ec1da34ec2e7@mfriebe.de>
Message-ID: <03ef149b-d7c8-80a6-a7f7-3315bdca50a8@wetron.es>

El 26/7/23 a les 17:42, Martin Frb via lazarus ha escrit:

> So FpDebug did not find the source file.
I found the issue: it's the -Xg (use external debug symbols file) option.
I wonder why it doesn't work under windows but it does under linux.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From lazarus at mfriebe.de  Wed Jul 26 18:03:15 2023
From: lazarus at mfriebe.de (Martin Frb)
Date: Wed, 26 Jul 2023 18:03:15 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <03ef149b-d7c8-80a6-a7f7-3315bdca50a8@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <23cf839e-0465-a3fb-d848-807f4c027a04@wetron.es>
 <6b0709ee-5ae5-a084-0104-73f404889ab4@mfriebe.de>
 <bd1a4105-7984-2f5e-5c3f-62227ca768f2@wetron.es>
 <c0834cd9-b8b9-1312-c27e-ec1da34ec2e7@mfriebe.de>
 <03ef149b-d7c8-80a6-a7f7-3315bdca50a8@wetron.es>
Message-ID: <dd229419-a33f-a7d8-855b-c95c22736301@mfriebe.de>

On 26/07/2023 17:58, Luca Olivetti via lazarus wrote:
> El 26/7/23 a les 17:42, Martin Frb via lazarus ha escrit:
>
>> So FpDebug did not find the source file.
> I found the issue: it's the -Xg (use external debug symbols file) option.
> I wonder why it doesn't work under windows but it does under linux.

I would still like to see that sample project, if possible. Maybe there 
is an easy fix.

From michael at freepascal.org  Thu Jul 27 11:43:47 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Thu, 27 Jul 2023 11:43:47 +0200 (CEST)
Subject: [Lazarus] FPC compiler error messages file update
Message-ID: <alpine.DEB.2.22.394.2307271040010.1959867@home>


Hello,

We're preparing FPC fixes release 3.2.4.

There are some new error messages in the compiler/msg/errore.msg file,
they need to be translated to other available languages:

errorct.msg (Catalan)
errorda.msg (Danish)
errord.msg  (German, CP 850)
errordu.msg (German, UTF8)
errores.msg (Spanish)
errorfi.msg (Finish)
errorf.msg  (French)
errorhe.msg (Hebrew CP 1255)
errorheu.msg (Hebrew UTF8)
errorid.msg (Indonesian CP 20127)
erroriu.msg (Italian)
errorn.msg  (Dutch)
errorpli.msg (Polish CP 8859-2)
errorpl.msg (Polish CP 852)
errorpt.msg (Portugese CP 850)
errorptu.msg (Portugese UTF8)
errorr.msg (Russian CP 866)
errorru.msg (Russian UTF8)
errorues.msg (Spanish UTF8)

The tool compiler/utils/msgdif can be used to compare the language-specific
file with the original file, and will write a new.msg file.

so after compiling msgdif, if you execute the following command 
in the compiler/msg directory (I'm taking dutch as an example, you should
obviously use your language file):

msgdif errore.msg errorn.msg

it will result in a file new.msg which has all original messages from errorn.msg 
and all new messages: this 'new.msg' file needs to be corrected/updated.

I have not updated the various files myself using this method, since I am not
capable of interpreting the resulting new.msg since I don't read all these
languages, and would possibly commit wrong files as a result.

If you speak one of these languages, please consider updating the
corresponding language file and uploading a patch to the issue tracker, 
or you can send a diff to me and I will apply it.

If creating the msgdif tool and the new.msg file is too difficult for you, 
feel free to mail me and I will gladly do it for you.

Thanks in advance,

Michael.

From luca at wetron.es  Thu Jul 27 17:02:12 2023
From: luca at wetron.es (Luca Olivetti)
Date: Thu, 27 Jul 2023 17:02:12 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <20230703133350.6a3504bd@limapholos>
References: <20230703133350.6a3504bd@limapholos>
Message-ID: <2b438a45-689a-d61a-b0d7-fbdea0fc902b@wetron.es>

El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:

> You can then open that copy in the RC1. Please test:

Now that, with Martin, I found the casue of the problem with the 
fpbebugger, now I have a different problem: the TSpeedButtons cut the 
text that previously fit.

See this picture:


https://postimg.cc/k61b0wCx

the upper toolbar is in lazarus 2.6, the lower one with 3.0 RC1.

The rest of the layout of the form seems OK.

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From ganmax at narod.ru  Thu Jul 27 17:16:59 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Thu, 27 Jul 2023 18:16:59 +0300
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <2b438a45-689a-d61a-b0d7-fbdea0fc902b@wetron.es>
References: <20230703133350.6a3504bd@limapholos>
 <2b438a45-689a-d61a-b0d7-fbdea0fc902b@wetron.es>
Message-ID: <b3a7f7cd-9f26-7d67-1fd9-9795b19970c2@narod.ru>

27.07.2023 18:02, Luca Olivetti via lazarus ?????:
> El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:
>
>> You can then open that copy in the RC1. Please test:
>
> Now that, with Martin, I found the casue of the problem with the 
> fpbebugger, now I have a different problem: the TSpeedButtons cut the 
> text that previously fit.
>
> See this picture:
>
>
> https://postimg.cc/k61b0wCx
>
> the upper toolbar is in lazarus 2.6, the lower one with 3.0 RC1.
>
> The rest of the layout of the form seems OK.
Please create an issue and attach a test project there.

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From luca at wetron.es  Thu Jul 27 19:21:04 2023
From: luca at wetron.es (Luca Olivetti)
Date: Thu, 27 Jul 2023 19:21:04 +0200
Subject: [Lazarus] Lazarus Release Candidate 1 of 3.0
In-Reply-To: <b3a7f7cd-9f26-7d67-1fd9-9795b19970c2@narod.ru>
References: <20230703133350.6a3504bd@limapholos>
 <2b438a45-689a-d61a-b0d7-fbdea0fc902b@wetron.es>
 <b3a7f7cd-9f26-7d67-1fd9-9795b19970c2@narod.ru>
Message-ID: <3bb4db43-7dbf-1d50-f95d-ff32dac3fc35@wetron.es>

El 27/7/23 a les 17:16, Maxim Ganetsky via lazarus ha escrit:
> 27.07.2023 18:02, Luca Olivetti via lazarus ?????:
>> El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:
>>
>>> You can then open that copy in the RC1. Please test:
>>
>> Now that, with Martin, I found the casue of the problem with the 
>> fpbebugger, now I have a different problem: the TSpeedButtons cut the 
>> text that previously fit.
>>
>> See this picture:
>>
>>
>> https://postimg.cc/k61b0wCx
>>
>> the upper toolbar is in lazarus 2.6, the lower one with 3.0 RC1.
>>
>> The rest of the layout of the form seems OK.
> Please create an issue and attach a test project there.

Done

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40410

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From steveg at nevets.com.au  Fri Jul 28 03:40:48 2023
From: steveg at nevets.com.au (Steve Gatenby)
Date: Fri, 28 Jul 2023 11:40:48 +1000
Subject: [Lazarus] MJPEG streamer
In-Reply-To: <5d75773b-e5e3-616f-11f4-ff102396f3dd@nevets.com.au>
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
 <5d75773b-e5e3-616f-11f4-ff102396f3dd@nevets.com.au>
Message-ID: <235520e0-2a2d-e690-23ab-a73633da2857@nevets.com.au>


On 24/7/23 09:35, Steve Gatenby via lazarus wrote:
>
> On 23/7/23 18:35, Steve Gatenby via lazarus wrote:
>> Would anybody know if there is a component / code to enable reading 
>> an mjpeg stream from a http camera to a Lazarus form/panel (or 
>> anything really)
>>
>> Dont mind installing libraries etc -
>>
>> Looking to suit Linux specifically though
>>
>> Thanks - SteveG
>>
>
> Thank you all -
>
> exactly what I was hoping for - possibilities to follow :)
>
> I will post if / once I get it figured as may be useful to others
>
>
I have written a (very) small unit to capture stream from esp32-cam 
(currently) and display in standard Lazarus TImage. First draft allows 
multiple cams / images.

What is the accepted way of supplying for use by others ? - do we have a 
central place for snippets / units for Pascal / Lazarus.

I know about CCR etc, but this is a bit small for that :) - so not sure 
what to do with it.

Have considered github, but seems overkill for such a small offering 
(and no guarantees it would always exist)

Regard - SteveG



From michael at freepascal.org  Fri Jul 28 11:37:32 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 28 Jul 2023 11:37:32 +0200 (CEST)
Subject: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
Message-ID: <alpine.DEB.2.22.394.2307281128140.2043943@home>


Hi,

I updated my lazarus today, and the following fails:

procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: Boolean);
begin
   PolygonNonZeroWindingRule := Winding;
   inherited Polygon(Points);
end;

it does not know PolygonNonZeroWindingRule.

I removed that line, and all compiles, but I suppose this is not the correct
fix ?

Michael.

From lazarus at kluug.net  Fri Jul 28 11:50:47 2023
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Fri, 28 Jul 2023 11:50:47 +0200
Subject: [Lazarus] MJPEG streamer
In-Reply-To: <235520e0-2a2d-e690-23ab-a73633da2857@nevets.com.au>
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
 <5d75773b-e5e3-616f-11f4-ff102396f3dd@nevets.com.au>
 <235520e0-2a2d-e690-23ab-a73633da2857@nevets.com.au>
Message-ID: <0987b0a6-96aa-43b5-0342-a76683d2d0f5@kluug.net>

On 28.07.2023 03:40, Steve Gatenby via lazarus wrote:
>
> On 24/7/23 09:35, Steve Gatenby via lazarus wrote:
>>
>> On 23/7/23 18:35, Steve Gatenby via lazarus wrote:
>>> Would anybody know if there is a component / code to enable reading 
>>> an mjpeg stream from a http camera to a Lazarus form/panel (or 
>>> anything really)
>>>
>>> Dont mind installing libraries etc -
>>>
>>> Looking to suit Linux specifically though
>>>
>>> Thanks - SteveG
>>>
>>
>> Thank you all -
>>
>> exactly what I was hoping for - possibilities to follow :)
>>
>> I will post if / once I get it figured as may be useful to others
>>
>>
> I have written a (very) small unit to capture stream from esp32-cam 
> (currently) and display in standard Lazarus TImage. First draft allows 
> multiple cams / images.
>
> What is the accepted way of supplying for use by others ? - do we have 
> a central place for snippets / units for Pascal / Lazarus.
>
> I know about CCR etc, but this is a bit small for that :) - so not 
> sure what to do with it.
>
> Have considered github, but seems overkill for such a small offering 
> (and no guarantees it would always exist)

I am interested in your solution.

If the unit uses the Lazarus-included lazvlc.lpk (or any other solution 
included in FPC/Lazarus), I would store it in the examples folder within 
Lazarus main: 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/examples

Please either create an issue in Lazarus gitlab and send the code there 
or send me the example as zipped file and I will upload it to examples.

Thanks,
Ondrej


From lazarus at kluug.net  Fri Jul 28 11:53:40 2023
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Fri, 28 Jul 2023 11:53:40 +0200
Subject: [Lazarus] MJPEG streamer
In-Reply-To: <0987b0a6-96aa-43b5-0342-a76683d2d0f5@kluug.net>
References: <4f5c378f-6b5d-9dd4-13c8-2614a50cbcc4@nevets.com.au>
 <5d75773b-e5e3-616f-11f4-ff102396f3dd@nevets.com.au>
 <235520e0-2a2d-e690-23ab-a73633da2857@nevets.com.au>
 <0987b0a6-96aa-43b5-0342-a76683d2d0f5@kluug.net>
Message-ID: <f90610c8-de0b-8107-7353-89ca1325e7e3@kluug.net>

Just to make sure: do you show a real-time video stream in TImage or do 
you just extract a single frame from the camera one by one?

Ondrej


From michael at freepascal.org  Fri Jul 28 12:07:39 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 28 Jul 2023 12:07:39 +0200 (CEST)
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <64C38671.3060002@adriaan.biz>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
Message-ID: <alpine.DEB.2.22.394.2307281205570.2045758@home>



On Fri, 28 Jul 2023, Adriaan van Os via fpc-devel wrote:

> Michael Van Canneyt via fpc-devel wrote:
>> 
>> Hello,
>> 
>> I have just completed phase one of the "Unicode RTL" effort.
>
> I object to the name "Unicode" RTL. Where people talk about what they call 
> "Unicode" they usually mean UCS-16 or UTF-16 or UTF-16-mishandled-as-UCS16.

Objection duly noted.

Michael.

From support at uvviewsoft.com  Fri Jul 28 13:30:12 2023
From: support at uvviewsoft.com (Alexey Torgashin)
Date: Fri, 28 Jul 2023 14:30:12 +0300
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307281205570.2045758@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
Message-ID: <0451fc37435703acae2a53d707469043@uvviewsoft.com>


> Objection duly noted.

Yes, 'Unicode RTL' sounds very bad. Before it was Unicode too. So, 
"UTF16 RTL", "WideChar RTL" or so.

Alex

From michael at freepascal.org  Fri Jul 28 13:42:48 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 28 Jul 2023 13:42:48 +0200 (CEST)
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <0451fc37435703acae2a53d707469043@uvviewsoft.com>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
Message-ID: <alpine.DEB.2.22.394.2307281331230.2057658@home>



On Fri, 28 Jul 2023, Alexey Torgashin via lazarus wrote:

>
>> Objection duly noted.
>
> Yes, 'Unicode RTL' sounds very bad. Before it was Unicode too. So, "UTF16 
> RTL", "WideChar RTL" or so.

The "Unicode" refers to String = UnicodeString.

The latter has been in use for what, 15-20 years ?

The name is chosen to remain consistent with existing terminology.

Assuming you guys are consistent, I guess you people are also not 
comfortable with the term 'UnicodeString' ?

Working with FPC must be a really annoying experience then...

Michael.

From werner.pamler at freenet.de  Fri Jul 28 14:59:13 2023
From: werner.pamler at freenet.de (Werner Pamler)
Date: Fri, 28 Jul 2023 14:59:13 +0200
Subject: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
In-Reply-To: <alpine.DEB.2.22.394.2307281128140.2043943@home>
References: <alpine.DEB.2.22.394.2307281128140.2043943@home>
Message-ID: <a5c81dfd-77e5-fd4e-2852-f22e2e3b1888@freenet.de>

Am 28.07.2023 um 11:37 schrieb Michael Van Canneyt via lazarus:
> I updated my lazarus today, and the following fails:
>
> procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: 
> Boolean);
> begin
> ? PolygonNonZeroWindingRule := Winding;
> ? inherited Polygon(Points);
> end;
>
> it does not know PolygonNonZeroWindingRule.
>
> I removed that line, and all compiles, but I suppose this is not the 
> correct
> fix ?
Last time there was a complaint about this I checked all combinations I 
have access to, and it was working. You are talking of Laz/main? In 
combination with which FPC? And on which OS? Did you try a *clean 
*rebuild of the Lazarus IDE?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230728/68d105ec/attachment.htm>

From michael at freepascal.org  Fri Jul 28 15:10:29 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 28 Jul 2023 15:10:29 +0200 (CEST)
Subject: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
In-Reply-To: <a5c81dfd-77e5-fd4e-2852-f22e2e3b1888@freenet.de>
References: <alpine.DEB.2.22.394.2307281128140.2043943@home>
 <a5c81dfd-77e5-fd4e-2852-f22e2e3b1888@freenet.de>
Message-ID: <alpine.DEB.2.22.394.2307281508360.2063942@home>



On Fri, 28 Jul 2023, Werner Pamler via lazarus wrote:

> Am 28.07.2023 um 11:37 schrieb Michael Van Canneyt via lazarus:
>> I updated my lazarus today, and the following fails:
>> 
>> procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: 
>> Boolean);
>> begin
>> ? PolygonNonZeroWindingRule := Winding;
>> ? inherited Polygon(Points);
>> end;
>> 
>> it does not know PolygonNonZeroWindingRule.
>> 
>> I removed that line, and all compiles, but I suppose this is not the 
>> correct
>> fix ?
> Last time there was a complaint about this I checked all combinations I have 
> access to, and it was working. You are talking of Laz/main? In combination 
> with which FPC? And on which OS? Did you try a *clean *rebuild of the Lazarus 
> IDE?

It is Laz/Main (updated today), FPC 3.2.2 and clean rebuild 
(I have the option 'clean always' set in the lazarus build config).

Where is this PolygonNonZeroWindingRule supposed to be defined ?

Michael.

From ganmax at narod.ru  Fri Jul 28 15:46:18 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Fri, 28 Jul 2023 16:46:18 +0300
Subject: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
In-Reply-To: <alpine.DEB.2.22.394.2307281508360.2063942@home>
References: <alpine.DEB.2.22.394.2307281128140.2043943@home>
 <a5c81dfd-77e5-fd4e-2852-f22e2e3b1888@freenet.de>
 <alpine.DEB.2.22.394.2307281508360.2063942@home>
Message-ID: <f5ce3289-acd2-f78a-02d5-e48460df8f58@narod.ru>

28.07.2023 16:10, Michael Van Canneyt via lazarus ?????:
>
>
> On Fri, 28 Jul 2023, Werner Pamler via lazarus wrote:
>
>> Am 28.07.2023 um 11:37 schrieb Michael Van Canneyt via lazarus:
>>> I updated my lazarus today, and the following fails:
>>>
>>> procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: 
>>> Boolean);
>>> begin
>>> ? PolygonNonZeroWindingRule := Winding;
>>> ? inherited Polygon(Points);
>>> end;
>>>
>>> it does not know PolygonNonZeroWindingRule.
>>>
>>> I removed that line, and all compiles, but I suppose this is not the 
>>> correct
>>> fix ?
>> Last time there was a complaint about this I checked all combinations 
>> I have access to, and it was working. You are talking of Laz/main? In 
>> combination with which FPC? And on which OS? Did you try a *clean 
>> *rebuild of the Lazarus IDE?
>
> It is Laz/Main (updated today), FPC 3.2.2 and clean rebuild (I have 
> the option 'clean always' set in the lazarus build config).

Lazarus can be built with FPC 3.2.2 just fine. Our CI ensures this (and 
it does exactly clean builds which include TLazCanvas too).

Judging from your description, it looks like you use by accident some 
outdated revision of FPC 3.2.3 or 3.3.1.

> Where is this PolygonNonZeroWindingRule supposed to be defined ?

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From michael at freepascal.org  Fri Jul 28 16:09:43 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 28 Jul 2023 16:09:43 +0200 (CEST)
Subject: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
In-Reply-To: <f5ce3289-acd2-f78a-02d5-e48460df8f58@narod.ru>
References: <alpine.DEB.2.22.394.2307281128140.2043943@home>
 <a5c81dfd-77e5-fd4e-2852-f22e2e3b1888@freenet.de>
 <alpine.DEB.2.22.394.2307281508360.2063942@home>
 <f5ce3289-acd2-f78a-02d5-e48460df8f58@narod.ru>
Message-ID: <alpine.DEB.2.22.394.2307281602170.2067814@home>



On Fri, 28 Jul 2023, Maxim Ganetsky via lazarus wrote:

> 28.07.2023 16:10, Michael Van Canneyt via lazarus ?????:
>>
>>
>> On Fri, 28 Jul 2023, Werner Pamler via lazarus wrote:
>>
>>> Am 28.07.2023 um 11:37 schrieb Michael Van Canneyt via lazarus:
>>>> I updated my lazarus today, and the following fails:
>>>>
>>>> procedure TLazCanvas.Polygon(const Points: array of TPoint; Winding: 
>>>> Boolean);
>>>> begin
>>>> ? PolygonNonZeroWindingRule := Winding;
>>>> ? inherited Polygon(Points);
>>>> end;
>>>>
>>>> it does not know PolygonNonZeroWindingRule.
>>>>
>>>> I removed that line, and all compiles, but I suppose this is not the 
>>>> correct
>>>> fix ?
>>> Last time there was a complaint about this I checked all combinations 
>>> I have access to, and it was working. You are talking of Laz/main? In 
>>> combination with which FPC? And on which OS? Did you try a *clean 
>>> *rebuild of the Lazarus IDE?
>>
>> It is Laz/Main (updated today), FPC 3.2.2 and clean rebuild (I have 
>> the option 'clean always' set in the lazarus build config).
>
> Lazarus can be built with FPC 3.2.2 just fine. Our CI ensures this (and 
> it does exactly clean builds which include TLazCanvas too).

That is why I was so surprised to see the failure...

After some searching, it seems I was using a fixes compiler and didn't
notice. Seems my mind wanted to read 3.2.2 instead of the actual 3.2.3 :/

Apologies for the noise.

Michael.

From nc-gaertnma at netcologne.de  Fri Jul 28 16:13:29 2023
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Fri, 28 Jul 2023 15:13:29 +0100
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307281331230.2057658@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
Message-ID: <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>

On 28.07.23 13:42, Michael Van Canneyt via lazarus wrote:
>
>
> On Fri, 28 Jul 2023, Alexey Torgashin via lazarus wrote:
>
>>
>>> Objection duly noted.
>>
>> Yes, 'Unicode RTL' sounds very bad. Before it was Unicode too. So, 
>> "UTF16 RTL", "WideChar RTL" or so.
>
> The "Unicode" refers to String = UnicodeString.
>
> The latter has been in use for what, 15-20 years ?

...wrong for 20 years.


>
> The name is chosen to remain consistent with existing terminology.

It seems, it was chosen because it is easier to pronounce than UTF16 RTL.

Naming something Unicode without adding any new Unicode feature can 
hardly be called consistent.


>
> Assuming you guys are consistent, I guess you people are also not 
> comfortable with the term 'UnicodeString' ?

Of course not.


>
> Working with FPC must be a really annoying experience then... 

;)


Mattias



From werner.pamler at freenet.de  Fri Jul 28 16:17:24 2023
From: werner.pamler at freenet.de (Werner Pamler)
Date: Fri, 28 Jul 2023 16:17:24 +0200
Subject: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
In-Reply-To: <alpine.DEB.2.22.394.2307281508360.2063942@home>
References: <alpine.DEB.2.22.394.2307281128140.2043943@home>
 <a5c81dfd-77e5-fd4e-2852-f22e2e3b1888@freenet.de>
 <alpine.DEB.2.22.394.2307281508360.2063942@home>
Message-ID: <7790905a-641e-b8d0-dd40-83c255838b66@freenet.de>

Am 28.07.2023 um 15:10 schrieb Michael Van Canneyt via lazarus:
> It is Laz/Main (updated today), FPC 3.2.2 and clean rebuild (I have 
> the option 'clean always' set in the lazarus build config).
This is my standard development system. No problem with it.

> Where is this PolygonNonZeroWindingRule supposed to be defined ?

For some time this was an addition to TLazCanvas.Polygon in Laz/2.3 and 
it had a different name which I cannot remember. Then I sent a patch for 
Polygon fill routines for TFpPixelCanvas which introduced the 
PolygonNonZeroWindingRule to FP/main (you committed it, 
https://gitlab.com/freepascal.org/fpc/source/-/issues/40286). I reworked 
TLazCanvas and removed the no-longer needed, old polygon fill of 
TLazCanvas in case of too-old FPC. So, there may be some combinations in 
the history of the Laz and FPC projects where there is a conflict, but 
there is definitely no conflict within Laz/main/fixes and 
FPC/main/fixes/3.2.2


From michael at freepascal.org  Fri Jul 28 16:35:35 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 28 Jul 2023 16:35:35 +0200 (CEST)
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
Message-ID: <alpine.DEB.2.22.394.2307281620490.2068652@home>



On Fri, 28 Jul 2023, Mattias Gaertner via lazarus wrote:

> On 28.07.23 13:42, Michael Van Canneyt via lazarus wrote:
>> 
>> 
>> On Fri, 28 Jul 2023, Alexey Torgashin via lazarus wrote:
>> 
>>> 
>>>> Objection duly noted.
>>> 
>>> Yes, 'Unicode RTL' sounds very bad. Before it was Unicode too. So, "UTF16 
>>> RTL", "WideChar RTL" or so.
>> 
>> The "Unicode" refers to String = UnicodeString.
>> 
>> The latter has been in use for what, 15-20 years ?
>
> ...wrong for 20 years.
>
>
>> 
>> The name is chosen to remain consistent with existing terminology.
>
> It seems, it was chosen because it is easier to pronounce than UTF16 RTL.

No, see below (or above).

>
> Naming something Unicode without adding any new Unicode feature can hardly be 
> called consistent.

As I wrote, the "Unicode" refers to String = UnicodeString. 
In that sense it is 'consistent with existent terminology'

That the original terminology "unicodestring" is badly chosen,
see first line in the feature list:

https://delphi.embarcadero.com/project/delphi-2009/

So complaints to CodeGear, please.

But if all these terribly unhappy and depressed users have a better name, I'm all ears.

So far, nothing catchy has been offered.

We'll attribute this lack of creativity to the state of depression due to
having to use such awful and horrifying terminology for ~15 years ;-)

Michael.

From luca at wetron.es  Fri Jul 28 16:50:26 2023
From: luca at wetron.es (Luca Olivetti)
Date: Fri, 28 Jul 2023 16:50:26 +0200
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307281620490.2068652@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
 <alpine.DEB.2.22.394.2307281620490.2068652@home>
Message-ID: <7597e5c2-c09b-8654-e12f-b5e6f63731c2@wetron.es>

El 28/7/23 a les 16:35, Michael Van Canneyt via lazarus ha escrit:
> But if all these terribly unhappy and depressed users have a better 
> name, I'm all ears.
> 
> So far, nothing catchy has been offered.

What about "Futura RTL"?
Short, catchy and...completely meaningless in this context :-D

Great song, though
https://www.youtube.com/watch?v=RXjE4q3Hyd4

Bye
-- 
Luca Olivetti
Wetron Automation Technology https://wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From nc-gaertnma at netcologne.de  Fri Jul 28 18:45:12 2023
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Fri, 28 Jul 2023 17:45:12 +0100
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307281620490.2068652@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
 <alpine.DEB.2.22.394.2307281620490.2068652@home>
Message-ID: <88e5945b-91d8-f00b-4cd6-af2c3ce9a644@netcologne.de>

On 28.07.23 16:35, Michael Van Canneyt via lazarus wrote:
> [...]
>> Naming something Unicode without adding any new Unicode feature can 
>> hardly be called consistent.
>
> As I wrote, the "Unicode" refers to String = UnicodeString. In that 
> sense it is 'consistent with existent terminology'

Yes, but you didn't name it "UnicodeString RTL", you named it "Unicode 
RTL". You can't blame CodeGear for that choice.

The new RTL has dotted units, so "Namespaced RTL" or "Dotted RTL" would 
fit too - also no catchy.


> So far, nothing catchy has been offered.

If you want something catchy, don't use a descriptive name.

Since the cheetah is a dotted (spotted) animal and it is the fpc mascot, 
maybe Cheetah RTL?


Mattias




From serbod at gmail.com  Fri Jul 28 18:51:50 2023
From: serbod at gmail.com (Sergey Bodrov)
Date: Fri, 28 Jul 2023 19:51:50 +0300
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <alpine.DEB.2.22.394.2307281620490.2068652@home>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
 <alpine.DEB.2.22.394.2307281620490.2068652@home>
Message-ID: <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>

>
>
> So far, nothing catchy has been offered.
>

WideChar RTL

Note, that WinAPI says:
* A Windows code page version with the letter "A" used to indicate "ANSI"
* A Unicode version with the letter "W" used to indicate "wide".
so, it perfectly matches AnsiString and WideString. And UnicodeString is
just alias for WideString

Also, what about "Delphi RTL"? Especially for Delphi compatibility.

-- 
*Bodrov Sergey*
software development, IT consulting
http://www.serbod.com
*Phone (Belarus):* +375(25)794-21-58
*Skype:* sergey.bodrov1
*e-mail:* serbod at gmail.com, oxotnuk at yandex.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230728/bb8fff82/attachment.htm>

From doug at moosemail.net  Fri Jul 28 19:00:51 2023
From: doug at moosemail.net (DougC)
Date: Fri, 28 Jul 2023 13:00:51 -0400
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
 <alpine.DEB.2.22.394.2307281620490.2068652@home>
 <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>
Message-ID: <1899d7228c4.bcbf121127360.2788817734150564656@moosemail.net>

I like WideChar RTL over Unicode RTL!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230728/c85f14df/attachment.htm>

From jesusrmx at gmail.com  Sat Jul 29 09:13:19 2023
From: jesusrmx at gmail.com (Jesus Reyes A.)
Date: Sat, 29 Jul 2023 01:13:19 -0600
Subject: [Lazarus] LazGitGui a git tool.
Message-ID: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>

Hi all,

Probably by now everyone already has their favorite git tool, I had it 
too, but anyway looking for a way to have basic repository information 
and show it through some add-on or plugin in Lazarus (and that it will 
work everywhere) I started this tool.

The more functions I added, the more I got away form the original goal 
(or closer I don't know).

Meanwhile I thought it could be useful for someone else and so if 
someone wants to try it, it is available in a gitlab repository at 
https://gitlab.com/jramx/lazgitgui

Git has so many great features and it is both tempting and challenging 
to continue adding them to this tool, anyway, this is what is available 
at the moment (what I think is the most basic functionality). I know I 
suck at writing documentation, but there is some in the docs directory 
to get you started.

Please try it and let me know how it works for you.

Regards.

Jesus Reyes A.


From juha.manninen62 at gmail.com  Sat Jul 29 11:28:52 2023
From: juha.manninen62 at gmail.com (Juha Manninen)
Date: Sat, 29 Jul 2023 04:28:52 -0500
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
Message-ID: <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>

I tested it. Quite nice!

One issue: lazgitgui requires a filename as a cmd line parameter but does
not use it. You should be able to run it without parameters just like "git
gui".

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

From juha.manninen62 at gmail.com  Sat Jul 29 12:55:56 2023
From: juha.manninen62 at gmail.com (Juha Manninen)
Date: Sat, 29 Jul 2023 05:55:56 -0500
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
 <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
Message-ID: <CAPN1EhCu8zAMXXMTtAodjrQTNC+LUusDX9gtnN96DhLGMB27KQ@mail.gmail.com>

Same with logcache. I am in Git Lazarus source directory but it asks for a
parameter.

[juha at juha-fp30 lazarus]$ ../lazgitgui/logcache
a file or directory of a git repository is needed
[juha at juha-fp30 lazarus]$

These are standalone applications.
An idea for future development :
An IDE plugin that runs "git blame" for an active editor source file and
shows a HashID for each line. The associated commit is shown in another
window when the HashID is clicked. All that using a local Git repo history,
no network access is needed.

That kind of IDE integration would make sense. I never understood the
traditional revision control plugins that allow commits from the IDE. What
is the benefit? I have anyways saved and tested all my changes when I want
to commit. I can as well start a proper commit tool from outside the IDE.
There is no true integration, the IDE plugin is only started from a
different place.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230729/0282ad45/attachment.htm>

From michael at freepascal.org  Sat Jul 29 15:04:41 2023
From: michael at freepascal.org (Michael Van Canneyt)
Date: Sat, 29 Jul 2023 15:04:41 +0200 (CEST)
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
 <alpine.DEB.2.22.394.2307281620490.2068652@home>
 <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2307291435580.2130305@home>



On Fri, 28 Jul 2023, Sergey Bodrov wrote:

>>
>>
>> So far, nothing catchy has been offered.
>>
>
> WideChar RTL
>
> Note, that WinAPI says:
> * A Windows code page version with the letter "A" used to indicate "ANSI"
> * A Unicode version with the letter "W" used to indicate "wide".
> so, it perfectly matches AnsiString and WideString. And UnicodeString is
> just alias for WideString
>
> Also, what about "Delphi RTL"? Especially for Delphi compatibility.

No, we discussed this in the core team, we don't want a reference to Delphi.

Michael.

From ganmax at narod.ru  Sat Jul 29 15:46:34 2023
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Sat, 29 Jul 2023 16:46:34 +0300
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
Message-ID: <4b6d783f-8100-be45-1b65-12079cce6b83@narod.ru>

29.07.2023 10:13, Jesus Reyes A. via lazarus ?????:
> Hi all,
>
> Probably by now everyone already has their favorite git tool, I had it 
> too, but anyway looking for a way to have basic repository information 
> and show it through some add-on or plugin in Lazarus (and that it will 
> work everywhere) I started this tool.
>
I think, an interesting idea would be to make TortoiseGit-like plugin 
for Double Commander. IMHO such tool in combination with powerful file 
manager will be one of the best cross-patform GUIs for Git.

> The more functions I added, the more I got away form the original goal 
> (or closer I don't know).
>
> Meanwhile I thought it could be useful for someone else and so if 
> someone wants to try it, it is available in a gitlab repository at 
> https://gitlab.com/jramx/lazgitgui
>
> Git has so many great features and it is both tempting and challenging 
> to continue adding them to this tool, anyway, this is what is 
> available at the moment (what I think is the most basic 
> functionality). I know I suck at writing documentation, but there is 
> some in the docs directory to get you started.
>
> Please try it and let me know how it works for you.

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru


From lazarus at mfriebe.de  Sat Jul 29 16:42:17 2023
From: lazarus at mfriebe.de (Martin Frb)
Date: Sat, 29 Jul 2023 16:42:17 +0200
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <CAPN1EhCu8zAMXXMTtAodjrQTNC+LUusDX9gtnN96DhLGMB27KQ@mail.gmail.com>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
 <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
 <CAPN1EhCu8zAMXXMTtAodjrQTNC+LUusDX9gtnN96DhLGMB27KQ@mail.gmail.com>
Message-ID: <5b5f83a1-9d2b-2705-d5d4-58264dbfa88f@mfriebe.de>


On 29/07/2023 12:55, Juha Manninen via lazarus wrote:
> An IDE plugin that runs "git blame" for an active editor source file 
> and shows a HashID for each line. The associated commit is shown in 
> another window when the HashID is clicked. All that using a local Git 
> repo history, no network access is needed.
>
> That kind of IDE integration would make sense. I never understood the 
> traditional revision control plugins that allow commits from the IDE. 
> What is the benefit? I have anyways saved and tested all my changes 
> when I want to commit. I can as well start a proper commit tool from 
> outside the IDE. There is no true integration, the IDE plugin is only 
> started from a different place.
>

Well, log for the current file would be useful too, and easier.


But what I really fancy is an integrated "git diff" => where the 
SourceEditor/SynEdit shows chages inline.

Could be different detail levels

- just line markers /like the current changed/save marker (yellow/green)

- diff show at bottom (like winmerge)

- maybe side by side split editor (though external tools to that well)

- inline markup, like MS-word capturing changes: red/strikethrough for 
stuff deleted by current diff, green for stuff added.

This could work, as you type.


It would work without gif, against the saved file, or a backup.

With git, against HEAD or index (or both / 3 color)



From pascaldragon at googlemail.com  Sat Jul 29 17:39:49 2023
From: pascaldragon at googlemail.com (Sven Barth)
Date: Sat, 29 Jul 2023 17:39:49 +0200
Subject: [Lazarus] [fpc-devel] Unicode RTL
In-Reply-To: <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>
References: <alpine.DEB.2.22.394.2307242126210.1727809@home>
 <64C38671.3060002@adriaan.biz>
 <alpine.DEB.2.22.394.2307281205570.2045758@home>
 <0451fc37435703acae2a53d707469043@uvviewsoft.com>
 <alpine.DEB.2.22.394.2307281331230.2057658@home>
 <bfa341d9-c060-879e-9c28-9ac6f0db0b2a@netcologne.de>
 <alpine.DEB.2.22.394.2307281620490.2068652@home>
 <CAEnbvREy0oJdPQa3FJYsOo4ci1L8bpid-DfLH2xO4SUOgG2eVw@mail.gmail.com>
Message-ID: <CAFMUeB9a8G2q7-VzuQapfZYaZ0gfEfLQa+upy_vv5Dn0GvDSAg@mail.gmail.com>

Sergey Bodrov via lazarus <lazarus at lists.lazarus-ide.org> schrieb am Fr.,
28. Juli 2023, 18:52:

> And UnicodeString is just alias for WideString
>

On Windows UnicodeString is *not* an alias to WideString. There they are
two completely different types that happen to both handle string with a
element width of 2 and UTF-16 encoding.

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230729/4ad3a77f/attachment.htm>

From jesusrmx at gmail.com  Sat Jul 29 19:04:21 2023
From: jesusrmx at gmail.com (Jesus Reyes A.)
Date: Sat, 29 Jul 2023 11:04:21 -0600
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
 <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
Message-ID: <792448a0-abea-c9b5-c193-64fde368500a@gmail.com>

On 29-jul-23 3:28 a.?m., Juha Manninen via lazarus wrote:

> I tested it. Quite nice!

I'm glad you liked.

> One issue: lazgitgui requires a filename as a cmd line parameter but does not use it. You should be able to run it without parameters just like "git gui".
> Juha

This can be worked out, if no file or dir is passed on it could use the 
current working directory. I will added to the list. Jesus Reyes A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230729/f9a31fc7/attachment.htm>

From jesusrmx at gmail.com  Sat Jul 29 20:31:28 2023
From: jesusrmx at gmail.com (Jesus Reyes A.)
Date: Sat, 29 Jul 2023 12:31:28 -0600
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <CAPN1EhCu8zAMXXMTtAodjrQTNC+LUusDX9gtnN96DhLGMB27KQ@mail.gmail.com>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
 <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
 <CAPN1EhCu8zAMXXMTtAodjrQTNC+LUusDX9gtnN96DhLGMB27KQ@mail.gmail.com>
Message-ID: <3c88956c-7e27-d1f2-eb5e-d53e9bd69254@gmail.com>

On 29-jul-23 4:55 a.?m., Juha Manninen via lazarus wrote:

> Same with logcache. I am in Git?Lazarus source directory but it asks for a parameter.
> [juha at juha-fp30 lazarus]$ ../lazgitgui/logcache
> a file or directory of a git repository is needed
> [juha at juha-fp30 lazarus]$

Indeed, logcache is supposed to work like LazGitGui, but it need only to locate the .git directory,
while LazGitGui could implement using the specified dir or file to limit working on that path and
not in the whole repository.

But logcache program is only a way to test the structure of the log cache, not really needed for LazGitGui

> These are standalone applications.
> An idea for future development :
> An IDE plugin that runs "git blame" for an active editor source file and shows a HashID for each line.

Blaming is something I would like to add, but more the way it works in TortoiseGit and less
than 'git gui'/gitk where it is a mess (IMO) in the mean time, this functionality is somewhat
supplied by the File History feature found in the yet to document log window where you can view
the commit changes as a diff, or look how was the work tree at that particular moment, clicking
any file in those views will enable the [FH] button that shows the selected file history. In gitk
you have to invoke it from the command line and the same in TortoiseGit although it's done in
a through the file browser interface

> I never understood the traditional revision control plugins that allow commits from the IDE. What is the benefit? I have anyways saved and tested all my changes when I want to commit. I can as well start a proper commit tool from outside the IDE. There is no true integration, the IDE plugin is only started from a different place.

I think it promotes a workflow where you commit often and short commits, but it is true that almost
always you have to someway find the window where you pick your changes and actually do it which is
not too different to invoke an external tool.

> Juha

Jesus Reyes A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230729/9e1c1a5b/attachment-0001.htm>

From jesusrmx at gmail.com  Sat Jul 29 20:40:07 2023
From: jesusrmx at gmail.com (Jesus Reyes A.)
Date: Sat, 29 Jul 2023 12:40:07 -0600
Subject: [Lazarus] LazGitGui a git tool.
In-Reply-To: <5b5f83a1-9d2b-2705-d5d4-58264dbfa88f@mfriebe.de>
References: <d7f4e4b7-7d1f-b9a3-bd6e-39f6fb16ae65@gmail.com>
 <CAPN1EhBwMUEwQB7zX9q_jUQRdx9tMsm973SzuCOmYRCbmJev_Q@mail.gmail.com>
 <CAPN1EhCu8zAMXXMTtAodjrQTNC+LUusDX9gtnN96DhLGMB27KQ@mail.gmail.com>
 <5b5f83a1-9d2b-2705-d5d4-58264dbfa88f@mfriebe.de>
Message-ID: <0421a9bb-3d8e-f315-147d-e568927d2afa@gmail.com>


On 29-jul-23 8:42 a.?m., Martin Frb via lazarus wrote:

> On 29/07/2023 12:55, Juha Manninen via lazarus wrote:
>> An IDE plugin that runs "git blame" for an active editor source file
>> and shows a HashID for each line. The associated commit is shown in
>> another window when the HashID is clicked. All that using a local Git
>> repo history, no network access is needed.
>> That kind of IDE integration would make sense. I never understood the
>> traditional revision control plugins that allow commits from the IDE.
>> What is the benefit? I have anyways saved and tested all my changes
>> when I want to commit. I can as well start a proper commit tool from
>> outside the IDE. There is no true integration, the IDE plugin is only
>> started from a different place.
> Well, log for the current file would be useful too, and easier.

yeah, file history is currently available in LazGitGit

> But what I really fancy is an integrated "git diff" => where the
> SourceEditor/SynEdit shows chages inline.
> Could be different detail levels
> - just line markers /like the current changed/save marker (yellow/green)
> - diff show at bottom (like winmerge)
> - maybe side by side split editor (though external tools to that well)
> - inline markup, like MS-word capturing changes: red/strikethrough for
> stuff deleted by current diff, green for stuff added.
> This could work, as you type.
> It would work without gif, against the saved file, or a backup.
> With git, against HEAD or index (or both / 3 color)

By itself, it could be a great tool.

For the moment I could use a full source diff tool, like the one that comes
with TortoiseGit, winmerge, meld, etc. :)

Jesus Reyes A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20230729/a5c4a27f/attachment.htm>