From coppolastudio at gmail.com  Thu Mar  3 21:46:20 2022
From: coppolastudio at gmail.com (Salvatore Coppola)
Date: Thu, 3 Mar 2022 21:46:20 +0100
Subject: [Lazarus] Patch for improvement of the StringGrid Editor
Message-ID: <CAMhKuRseR9bi1-tyniCk6KAoX61mGqLKte0YSzwKe7y4xApxkQ@mail.gmail.com>

Hi, particularly to the list moderators,
have you taken a look at the patch (oversize 104 kb) sent to this list on
February 26th?
ciao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220303/7ce0f48f/attachment.htm>

From juha.manninen62 at gmail.com  Sun Mar  6 12:12:35 2022
From: juha.manninen62 at gmail.com (Juha Manninen)
Date: Sun, 6 Mar 2022 13:12:35 +0200
Subject: [Lazarus] Improved Editor Macro Viever
Message-ID: <CAPN1EhDwGh2FTJG8u-Jy=Vc96JZVL5Kdv3RtZduT-MnhyAfqeg@mail.gmail.com>

In 06352700aa7c I improved the GUI for managing editor macros, View ->
Editor Macros ...
Please test.
Earlier in 7485ac827a the IDE toolbar button for macros got a dropdown list.

The editor statusbar seems to have a button to stop recording a macro. It
is not synchronized with the Editor Macros window buttons.
Maybe the statusbar should also have a button to start recording.
Things can be improved. Maybe I missed something important in the macro GUI
rework, too.
Comments?

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220306/426ee915/attachment.htm>

From flavio.etrusco at gmail.com  Thu Mar 10 22:29:42 2022
From: flavio.etrusco at gmail.com (=?UTF-8?Q?Fl=C3=A1vio_Etrusco?=)
Date: Thu, 10 Mar 2022 18:29:42 -0300
Subject: [Lazarus] Patch for improvement of the StringGrid Editor
In-Reply-To: <CAMhKuRseR9bi1-tyniCk6KAoX61mGqLKte0YSzwKe7y4xApxkQ@mail.gmail.com>
References: <CAMhKuRseR9bi1-tyniCk6KAoX61mGqLKte0YSzwKe7y4xApxkQ@mail.gmail.com>
Message-ID: <CAJvBmOZ1rct3D0X4uDnmwV0uh_KG4zvqyGkTNHL+yfzs9__Dsw@mail.gmail.com>

Hello Salvatore,
Maybe you could open a ticket at
https://gitlab.com/freepascal.org/lazarus/lazarus?

Best regards,
Fl?vio

Em qui., 3 de mar. de 2022 ?s 17:47, Salvatore Coppola via lazarus
<lazarus at lists.lazarus-ide.org> escreveu:
>
> Hi, particularly to the list moderators,
> have you taken a look at the patch (oversize 104 kb) sent to this list on February 26th?
> ciao
> --
> _______________________________________________
> lazarus mailing list
> lazarus at lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus

From larrydalton71 at gmail.com  Fri Mar 11 21:51:22 2022
From: larrydalton71 at gmail.com (Larry Dalton)
Date: Fri, 11 Mar 2022 15:51:22 -0500
Subject: [Lazarus] ODBC configurations for Excel on Lazarus
Message-ID: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>

I?m trying to access an Excel spreadsheet named ?und30.xlsx? in a directory ?c:\inventorydata? using ODBC Data Source Administrator (64-bit). The DSN is ?und30?. I am trying to use TODBCConnection named under30conn. How do I configure under30conn?

Sent from my iPhone

From michael at freepascal.org  Fri Mar 11 23:03:22 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 11 Mar 2022 23:03:22 +0100 (CET)
Subject: [Lazarus] ODBC configurations for Excel on Lazarus
In-Reply-To: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>
References: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>
Message-ID: <alpine.DEB.2.22.394.2203112302260.1133508@home>



On Fri, 11 Mar 2022, Larry Dalton via lazarus wrote:

> I?m trying to access an Excel spreadsheet named ?und30.xlsx? in a directory ?c:\inventorydata? using ODBC Data Source Administrator (64-bit). The DSN is ?und30?. I am trying to use TODBCConnection named under30conn. How do I configure under30conn?

Would it not be easier to use fpspreadsheet ?

Accessing excel through odbc seems a rather roundabout way.

Michael.

From werner.pamler at freenet.de  Fri Mar 11 23:18:09 2022
From: werner.pamler at freenet.de (Werner Pamler)
Date: Fri, 11 Mar 2022 23:18:09 +0100
Subject: [Lazarus] ODBC configurations for Excel on Lazarus
In-Reply-To: <alpine.DEB.2.22.394.2203112302260.1133508@home>
References: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>
 <alpine.DEB.2.22.394.2203112302260.1133508@home>
Message-ID: <e3f267bc-b94c-4e87-b06d-f05b94e190bd@freenet.de>

Am 11.03.2022 um 23:03 schrieb Michael Van Canneyt via lazarus:
> Would it not be easier to use fpspreadsheet ?
>
> Accessing excel through odbc seems a rather roundabout way.

Yes, definitely (https://wiki.lazarus.freepascal.org/FPSpreadsheet). In 
the most recent release there is even a TsWorksheetDataset which allows 
to access the spreadsheet in a database way.


From michael at freepascal.org  Fri Mar 11 23:43:07 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 11 Mar 2022 23:43:07 +0100 (CET)
Subject: [Lazarus] ODBC configurations for Excel on Lazarus
In-Reply-To: <e3f267bc-b94c-4e87-b06d-f05b94e190bd@freenet.de>
References: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>
 <alpine.DEB.2.22.394.2203112302260.1133508@home>
 <e3f267bc-b94c-4e87-b06d-f05b94e190bd@freenet.de>
Message-ID: <alpine.DEB.2.22.394.2203112340090.1133508@home>



On Fri, 11 Mar 2022, Werner Pamler via lazarus wrote:

> Am 11.03.2022 um 23:03 schrieb Michael Van Canneyt via lazarus:
>> Would it not be easier to use fpspreadsheet ?
>> 
>> Accessing excel through odbc seems a rather roundabout way.
>
> Yes, definitely (https://wiki.lazarus.freepascal.org/FPSpreadsheet). In the 
> most recent release there is even a TsWorksheetDataset which allows to access 
> the spreadsheet in a database way.

Cool, I didn't know that one yet ! :-)

Is there an example for it's use ? 
Given the way companies often rape excel sheets, 
this component will make life a lot easier for many things :-)

Michael.

From werner.pamler at freenet.de  Sat Mar 12 13:34:16 2022
From: werner.pamler at freenet.de (Werner Pamler)
Date: Sat, 12 Mar 2022 13:34:16 +0100
Subject: [Lazarus] ODBC configurations for Excel on Lazarus
In-Reply-To: <alpine.DEB.2.22.394.2203112340090.1133508@home>
References: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>
 <alpine.DEB.2.22.394.2203112302260.1133508@home>
 <e3f267bc-b94c-4e87-b06d-f05b94e190bd@freenet.de>
 <alpine.DEB.2.22.394.2203112340090.1133508@home>
Message-ID: <0ce4d52c-a4a6-41b0-94bb-2b540eac4983@freenet.de>

Am 11.03.2022 um 23:43 schrieb Michael Van Canneyt via lazarus:
> Cool, I didn't know that one yet ! :-)
>
> Is there an example for it's use ? Given the way companies often rape 
> excel sheets, this component will make life a lot easier for many 
> things :-)
There are two examples in folder examples/dataset of the fpspreadsheet 
installation. Note that it was not intended to carry database technology 
into the main laz_fpspreadsheet package, therefore, the dataset was put 
into a separate package, laz_fpspreadsheet_dataset, which must be 
installed to test the two demo projects.

From michael at freepascal.org  Sat Mar 12 14:05:13 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Sat, 12 Mar 2022 14:05:13 +0100 (CET)
Subject: [Lazarus] ODBC configurations for Excel on Lazarus
In-Reply-To: <0ce4d52c-a4a6-41b0-94bb-2b540eac4983@freenet.de>
References: <5B7376CA-9A13-4CC5-BD40-717DD1C29C03@gmail.com>
 <alpine.DEB.2.22.394.2203112302260.1133508@home>
 <e3f267bc-b94c-4e87-b06d-f05b94e190bd@freenet.de>
 <alpine.DEB.2.22.394.2203112340090.1133508@home>
 <0ce4d52c-a4a6-41b0-94bb-2b540eac4983@freenet.de>
Message-ID: <alpine.DEB.2.22.394.2203121353110.1160049@home>



On Sat, 12 Mar 2022, Werner Pamler via lazarus wrote:

> Am 11.03.2022 um 23:43 schrieb Michael Van Canneyt via lazarus:
>> Cool, I didn't know that one yet ! :-)
>> 
>> Is there an example for it's use ? Given the way companies often rape excel 
>> sheets, this component will make life a lot easier for many things :-)
> There are two examples in folder examples/dataset of the fpspreadsheet 
> installation. Note that it was not intended to carry database technology into 
> the main laz_fpspreadsheet package, therefore, the dataset was put into a 
> separate package, laz_fpspreadsheet_dataset, which must be installed to test 
> the two demo projects.

Thanks. I had a look, this looks good indeed !

Michael.

From jmlandmesser at gmx.de  Mon Mar 14 18:15:01 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Mon, 14 Mar 2022 18:15:01 +0100
Subject: [Lazarus] IDE qt5 compile error
Message-ID: <004265af-8e09-cf55-3287-317e5a8e74e0@gmx.de>

I can't compile lazarus IDE anymore:

Lazarus 2.3.0 (rev main-2_3-991-ge2ad6b3d8d) FPC 3.2.2 x86_64-linux-gtk2

error:

Error: /home/john1/lazarus/lcl/interfaces//qt5/qtobject.inc:42:
undefined reference to `QGuiApplication_setFallbackSessionManagementEnabled'

I am on Manjaro Linux stable branch:

System:
 ? Host: manjaro Kernel: 5.15.28-1-MANJARO x86_64 bits: 64
 ??? Desktop: Xfce 4.16.0 Distro: Manjaro Linux

The package qt5pas was updated 14,03,2022 the packager tells as source:

https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/lcl/interfaces/qt5/cbindings

Because i think freepascal changed something i post this here.

Manjaro tells me to the last update:

Qt5 got an official update after one year and is now at 5.15.3 6
including the regular KDE patch-sets. Be sure you rebuild any AUR Qt
package against this one.

What to do?





From support at uvviewsoft.com  Mon Mar 14 18:54:40 2022
From: support at uvviewsoft.com (support at uvviewsoft.com)
Date: Mon, 14 Mar 2022 20:54:40 +0300
Subject: [Lazarus] IDE qt5 compile error
In-Reply-To: <004265af-8e09-cf55-3287-317e5a8e74e0@gmx.de>
References: <004265af-8e09-cf55-3287-317e5a8e74e0@gmx.de>
Message-ID: <191e6da604c8f3ca0a45e06fdbce86d7@uvviewsoft.com>

> 
> Error: /home/john1/lazarus/lcl/interfaces//qt5/qtobject.inc:42:
> undefined reference to 
> `QGuiApplication_setFallbackSessionManagementEnabled'

Do not use Lazarus 'latest', but return to the revision before THAT qt5 
patch.
My linux terminal shows me which revision I use now:

user at PC:~/lazarus$ git status
HEAD detached at 23b2324f9f


I used Git to return to that revision.
Alexey

From jmlandmesser at gmx.de  Mon Mar 14 19:13:18 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Mon, 14 Mar 2022 19:13:18 +0100
Subject: [Lazarus] IDE qt5 compile error
In-Reply-To: <191e6da604c8f3ca0a45e06fdbce86d7@uvviewsoft.com>
References: <004265af-8e09-cf55-3287-317e5a8e74e0@gmx.de>
 <191e6da604c8f3ca0a45e06fdbce86d7@uvviewsoft.com>
Message-ID: <30ea636f-e013-4114-7347-25dd9cf3f53c@gmx.de>

Am 14.03.22 um 18:54 schrieb Alexey Torgashin via lazarus:
>>
>> Error: /home/john1/lazarus/lcl/interfaces//qt5/qtobject.inc:42:
>> undefined reference to
>> `QGuiApplication_setFallbackSessionManagementEnabled'
>
> Do not use Lazarus 'latest', but return to the revision before THAT
> qt5 patch.
> My linux terminal shows me which revision I use now:
>
> user at PC:~/lazarus$ git status
> HEAD detached at 23b2324f9f
>
>
> I used Git to return to that revision.
> Alexey

Thanks for that tip!


I don't use Lazarus qt5 any more. I have just one little app and for
this i have a workaround so i don't need qt5pas any more.

> LAZUSEAPPIND=NO /run/media/john1/ntfs1/PROJEKTE/Lazarus/Sanduhr/Sanduhr
Doing this trayicon.hint works again and without qt5pas installed :-)


From steveg at nevets.com.au  Tue Mar 15 03:10:53 2022
From: steveg at nevets.com.au (Steve Gatenby)
Date: Tue, 15 Mar 2022 12:10:53 +1000
Subject: [Lazarus] Love the IDE
Message-ID: <ad8b65fb-dae8-aea4-74c6-9cfa74d5c27e@nevets.com.au>

have been using both Atom and VsCode for a couple of weeks now (ESP coding)

Just like to note ( hopefully without bashing the above )

really love the Lazarus IDE :) - it is miles above in usability




From christo.crause at gmail.com  Tue Mar 15 06:58:51 2022
From: christo.crause at gmail.com (Christo Crause)
Date: Tue, 15 Mar 2022 07:58:51 +0200
Subject: [Lazarus] Love the IDE
In-Reply-To: <ad8b65fb-dae8-aea4-74c6-9cfa74d5c27e@nevets.com.au>
References: <ad8b65fb-dae8-aea4-74c6-9cfa74d5c27e@nevets.com.au>
Message-ID: <CAGOmfbGHBV1Wtwj=SmPctaXfAmJ=1vwy7Ly30vJnmLXzbxwmuw@mail.gmail.com>

On Tue, 15 Mar 2022, 04:11 Steve Gatenby via lazarus, <
lazarus at lists.lazarus-ide.org> wrote:

> have been using both Atom and VsCode for a couple of weeks now (ESP coding)
>
> Just like to note ( hopefully without bashing the above )
>
> really love the Lazarus IDE :) - it is miles above in usability
>

At least you are not stuck with the Arduino IDE...

You can use Lazarus and FPC (trunk) to write code for Esp8266 & Esp32:
https://wiki.lazarus.freepascal.org/Xtensa

Some bindings to the respective IDF SDKs :
https://github.com/ccrause/fpc-esp-freertos

Not yet fully supporting all the GCC features, but getting there. Obviously
also not as many 3rd party libraries.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220315/2254b4fa/attachment.htm>

From gejimenez at gmail.com  Tue Mar 15 13:42:03 2022
From: gejimenez at gmail.com (Gustavo Enrique Jimenez)
Date: Tue, 15 Mar 2022 09:42:03 -0300
Subject: [Lazarus] Love the IDE
In-Reply-To: <CAGOmfbGHBV1Wtwj=SmPctaXfAmJ=1vwy7Ly30vJnmLXzbxwmuw@mail.gmail.com>
References: <ad8b65fb-dae8-aea4-74c6-9cfa74d5c27e@nevets.com.au>
 <CAGOmfbGHBV1Wtwj=SmPctaXfAmJ=1vwy7Ly30vJnmLXzbxwmuw@mail.gmail.com>
Message-ID: <CADiB+22=WiBi65nv5=Ev82kk8gDeP4zj+sPKFQUvio3-R-tT-g@mail.gmail.com>

El mar, 15 mar 2022 a las 2:59, Christo Crause via lazarus
(<lazarus at lists.lazarus-ide.org>) escribi?:
>
>
> On Tue, 15 Mar 2022, 04:11 Steve Gatenby via lazarus, <lazarus at lists.lazarus-ide.org> wrote:
>>
>> have been using both Atom and VsCode for a couple of weeks now (ESP coding)
>>
>> Just like to note ( hopefully without bashing the above )
>>
>> really love the Lazarus IDE :) - it is miles above in usability
>
>
> At least you are not stuck with the Arduino IDE...
>
> You can use Lazarus and FPC (trunk) to write code for Esp8266 & Esp32: https://wiki.lazarus.freepascal.org/Xtensa
>
> Some bindings to the respective IDF SDKs : https://github.com/ccrause/fpc-esp-freertos
>
> Not yet fully supporting all the GCC features, but getting there. Obviously also not as many 3rd party libraries.
>


What?

This is excellent news for me. I didn't know that now I can also
compile code for the ESP32/esp8266 family. Several times I mentioned
that I make embedded electronics, and when I need software for the
desktop I use Lazarus/Freepascal (since 2002~2005 or so, I started
with Freepascal and then moved on to Lazarus). I use esp8266 and ESP32
since 2016 and I already have a few thousand lines of code for these
microcontrollers. Many thanks to all developers of Freepascal, Lazarus
and all complementary projects and extensions. For those who are and
those who are no longer with us, who will not be forgotten. This news
really warms my heart, I always used and defended the Freepascal
compiler with love (in my work they even make fun of me for using a
"forgotten" language). Thank you all for these tremendous advances, I
can't tell you how much I want to give you a hug. Thanks!


Gustavo


> --
> _______________________________________________
> lazarus mailing list
> lazarus at lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus

From d.ioannidis at nephelae.eu  Tue Mar 15 14:06:55 2022
From: d.ioannidis at nephelae.eu (d.ioannidis at nephelae.eu)
Date: Tue, 15 Mar 2022 15:06:55 +0200
Subject: [Lazarus] Love the IDE
In-Reply-To: <CADiB+22=WiBi65nv5=Ev82kk8gDeP4zj+sPKFQUvio3-R-tT-g@mail.gmail.com>
References: <ad8b65fb-dae8-aea4-74c6-9cfa74d5c27e@nevets.com.au>
 <CAGOmfbGHBV1Wtwj=SmPctaXfAmJ=1vwy7Ly30vJnmLXzbxwmuw@mail.gmail.com>
 <CADiB+22=WiBi65nv5=Ev82kk8gDeP4zj+sPKFQUvio3-R-tT-g@mail.gmail.com>
Message-ID: <04a66727ee8edc44a1d782072a5b7420@nephelae.eu>

On 2022-03-15 14:42, Gustavo Enrique Jimenez via lazarus wrote:

< snip >

> ... Several times I mentioned
> that I make embedded electronics, and when I need software for the
> desktop I use Lazarus/Freepascal (since 2002~2005 or so, I started
> with Freepascal and then moved on to Lazarus). ....

Then, I'll think that, you'll pleased also with the updated HidApi 
library bindings, 
https://forum.lazarus.freepascal.org/index.php/topic,58678.0.html .

regards,

-- 
Dimitrios Chr. Ioannidis

From coppolastudio at gmail.com  Fri Mar 18 21:51:12 2022
From: coppolastudio at gmail.com (Salvatore Coppola)
Date: Fri, 18 Mar 2022 21:51:12 +0100
Subject: [Lazarus] Patch for improvement of the StringGrid Editor
In-Reply-To: <CAJvBmOZ1rct3D0X4uDnmwV0uh_KG4zvqyGkTNHL+yfzs9__Dsw@mail.gmail.com>
References: <CAMhKuRseR9bi1-tyniCk6KAoX61mGqLKte0YSzwKe7y4xApxkQ@mail.gmail.com>
 <CAJvBmOZ1rct3D0X4uDnmwV0uh_KG4zvqyGkTNHL+yfzs9__Dsw@mail.gmail.com>
Message-ID: <CAMhKuRtQxhJaq5EpuYWAdfeSB=jF=MdpH8nLTDz0S5Qj=m+pnQ@mail.gmail.com>

Tried to create an issoue on gitlab with diff files uploaded, not sure is
ok or is in the right place! In the screenshot how the LazaStringGridEditor
will appare
ciao
Salvatore

Il giorno gio 10 mar 2022 alle ore 22:30 Fl?vio Etrusco via lazarus <
lazarus at lists.lazarus-ide.org> ha scritto:

> Hello Salvatore,
> Maybe you could open a ticket at
> https://gitlab.com/freepascal.org/lazarus/lazarus?
>
> Best regards,
> Fl?vio
>
> Em qui., 3 de mar. de 2022 ?s 17:47, Salvatore Coppola via lazarus
> <lazarus at lists.lazarus-ide.org> escreveu:
> >
> > Hi, particularly to the list moderators,
> > have you taken a look at the patch (oversize 104 kb) sent to this list
> on February 26th?
> > ciao
> > --
> > _______________________________________________
> > lazarus mailing list
> > lazarus at lists.lazarus-ide.org
> > https://lists.lazarus-ide.org/listinfo/lazarus
> --
> _______________________________________________
> lazarus mailing list
> lazarus at lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220318/90b828cb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Immagine.png
Type: image/png
Size: 8144 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220318/90b828cb/attachment.png>

From jmlandmesser at gmx.de  Mon Mar 21 11:49:22 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Mon, 21 Mar 2022 11:49:22 +0100
Subject: [Lazarus] will fixes_2_2 be merged to trunk before next release?
Message-ID: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>

I had an issue with qt5pas that was fixed in lazarus fixes_2_2.

Because i now use:

Lazarus 2.3.0 (rev main-2_3-996-ga94312373c) FPC 3.2.2 x86_64-linux-gtk2

I would like to know if the fixes for lazarus 2.2 will be merged to
trunk before next release?

And yes: i have a very poor knowledge about release models with git :-(


From jmlandmesser at gmx.de  Mon Mar 21 17:32:28 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Mon, 21 Mar 2022 17:32:28 +0100
Subject: [Lazarus] will fixes_2_2 be merged to trunk before next release?
In-Reply-To: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>
References: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>
Message-ID: <1fd54b3c-4384-f3bf-82c5-58f5e4f835ae@gmx.de>

Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:
> I had an issue with qt5pas that was fixed in lazarus fixes_2_2.
>
> Because i now use:
>
> Lazarus 2.3.0 (rev main-2_3-996-ga94312373c) FPC 3.2.2 x86_64-linux-gtk2
>
> I would like to know if the fixes for lazarus 2.2 will be merged to
> trunk before next release?
>
> And yes: i have a very poor knowledge about release models with git :-(
>
answer to zeljko at holobit.hr

Allready closed issue:

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


From lazarus at mfriebe.de  Tue Mar 22 01:52:40 2022
From: lazarus at mfriebe.de (Martin Frb)
Date: Tue, 22 Mar 2022 01:52:40 +0100
Subject: [Lazarus] will fixes_2_2 be merged to trunk before next release?
In-Reply-To: <1fd54b3c-4384-f3bf-82c5-58f5e4f835ae@gmx.de>
References: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>
 <1fd54b3c-4384-f3bf-82c5-58f5e4f835ae@gmx.de>
Message-ID: <2be8f7e2-e7d9-9632-f321-948a321c6d4b@mfriebe.de>

On 21/03/2022 17:32, John Landmesser via lazarus wrote:
> Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:
>> I had an issue with qt5pas that was fixed in lazarus fixes_2_2.
>>
>> Because i now use:
>>
>> Lazarus 2.3.0 (rev main-2_3-996-ga94312373c) FPC 3.2.2 x86_64-linux-gtk2
>>
>> I would like to know if the fixes for lazarus 2.2 will be merged to
>> trunk before next release?

I don't know much about that particular issue, but from what I read: 
There are no fixes in 2.2 that could be merged.

- 2.2 uses old code that works with the dependencies you have installed

- 2.3 has newer code and needs newer dependencies.
 ? On the issues it says, you may have to build them yourself. (I have 
no idea, when they will be avail pre-compiled)


>
> Allready closed issue:
>
> https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39676
>


From jmlandmesser at gmx.de  Tue Mar 22 12:09:30 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Tue, 22 Mar 2022 12:09:30 +0100
Subject: [Lazarus] will fixes_2_2 be merged to trunk before next release?
In-Reply-To: <2be8f7e2-e7d9-9632-f321-948a321c6d4b@mfriebe.de>
References: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>
 <1fd54b3c-4384-f3bf-82c5-58f5e4f835ae@gmx.de>
 <2be8f7e2-e7d9-9632-f321-948a321c6d4b@mfriebe.de>
Message-ID: <38f6f7a7-5d0a-9804-22b6-202505a0448e@gmx.de>

Am 22.03.22 um 01:52 schrieb Martin Frb via lazarus:
> On 21/03/2022 17:32, John Landmesser via lazarus wrote:
>> Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:
>>> I had an issue with qt5pas that was fixed in lazarus fixes_2_2.
>>>
>>> Because i now use:
>>>
>>> Lazarus 2.3.0 (rev main-2_3-996-ga94312373c) FPC 3.2.2
>>> x86_64-linux-gtk2
>>>
>>> I would like to know if the fixes for lazarus 2.2 will be merged to
>>> trunk before next release?
>
> I don't know much about that particular issue, but from what I read:
> There are no fixes in 2.2 that could be merged.
>
> - 2.2 uses old code that works with the dependencies you have installed
>
> - 2.3 has newer code and needs newer dependencies.
> ? On the issues it says, you may have to build them yourself. (I have
> no idea, when they will be avail pre-compiled)
>
>
Your answer would fit to the answer? Alexey Torgashin gave me to my
question with title

"[Lazarus] IDE qt5 compile error" from? 14.03.2022 18;15

I am thinking about which is the base for next lazarus release if
fixes_2_2 is NOT merged back to main development branch.

But as i said before: i'm noob also at? these topics.

Best of all: i start my only ex-qt5 application with environment
variable set

LAZUSEAPPIND=NO

and even in gtk2 trayicon.Hint wortks again.





From lazarus at mfriebe.de  Tue Mar 22 17:07:01 2022
From: lazarus at mfriebe.de (Martin Frb)
Date: Tue, 22 Mar 2022 17:07:01 +0100
Subject: [Lazarus] will fixes_2_2 be merged to trunk before next release?
In-Reply-To: <38f6f7a7-5d0a-9804-22b6-202505a0448e@gmx.de>
References: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>
 <1fd54b3c-4384-f3bf-82c5-58f5e4f835ae@gmx.de>
 <2be8f7e2-e7d9-9632-f321-948a321c6d4b@mfriebe.de>
 <38f6f7a7-5d0a-9804-22b6-202505a0448e@gmx.de>
Message-ID: <db33ac69-9c87-e5b4-4666-d8211d381908@mfriebe.de>

Note:
- My below reply only answers part to the general workflow in git. (e.g. 
how we merge and release, etc).
- I am not working on the QT related parts of Lazarus. Therefore I can 
not give any answers on the specific plans for QT.

On 22/03/2022 12:09, John Landmesser via lazarus wrote:
> Am 22.03.22 um 01:52 schrieb Martin Frb via lazarus:
>> Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:
>>> I would like to know if the fixes for lazarus 2.2 will be merged to
>>> trunk before next release? 
>> I don't know much about that particular issue, but from what I read:
>> There are no fixes in 2.2 that could be merged.
>
> Your answer would fit to the answer? Alexey Torgashin gave me to my
> question with title
> "[Lazarus] IDE qt5 compile error" from? 14.03.2022 18;15

Ok, that was a different mail thread, which I hadn't seen/read.

> I am thinking about which is the base for next lazarus release if
> fixes_2_2 is NOT merged back to main development branch.

- "next release" => "next major release" = "2.4" (NOT: "next (minor) 
release" = "2.2.2")
- The base for Lazarus 2.4 will be whatever is in the current git "main" 
branch.

**AFAIK** (with regards to this QT issue) => As I said:
=> "fixes_2_2" does not contain anything that can be merged to fix your 
issue.
-? Something new (like a new feature) was added to "main" (aka trunk)
-? It was never added to "fixes_2_2"

So "fixes_2_2" does not have anything to "fix" your issue.
Rather "fixes_2_2" does not have the feature that doesn't work for you.

If you can't install (build yourself) the dependencies for that new 
feature, then your options are:
- wait for the dependencies to become available (as installable package 
/ as part of some installer)
- use "fixes_2_2"
- use "main", but revert (undo) the changes (aka: "the addition of the 
feature")
 ?? => of course, over time that means to also revert/undo any 
change/addition that requires the new code....


On 21/03/2022 11:49, John Landmesser via lazarus wrote:
> I would like to know if the fixes for lazarus 2.2 will be merged to
> trunk before next release?
>
> And yes: i have a very poor knowledge about release models with git :-(

For the "release model", we use git (i.e., branches in git) exactly as 
we used branches in svn before.

- In SVN we had "trunk"?????? => Now, in GIT we have "main"
- In SVN we had "fixes_*_*" => Now, in GIT we have "fixes_*_*"

The only changes between how we use branches in GIT vs SVN is
- increased use of "feature branches" (we did once or twice in SVN)
- use of "merge-request branches"
Neither affects release management.
That is any? "feature branches" or "merge-request branches" eventually 
become part of "main" (or sometimes part of "fixes_*_*").
Before that, they don't account towards any future release. But once 
they are part of "main" (or "fixes"), they are simply seen as part of 
that branch.

For future releases, we have the same branches as we had in svn.
Exactly as we used to do with SVN, we now do in GIT:
=> New code goes into "main".
 ?- "Feature": ? If it is a feature, then it goes to "main" only.
 ??? ?? It may get further changes, fixes, even part-undo.... And it 
will go into the next major release.
 ? ? ?? (In rare cases, features that are not ready when the next major 
release happens, can be undone in the next "fixes" branch (i.e. for 
"2.4" that would be "fixes_2_4" once that has been branched).
 ?- "Bug-Fix": ? If it is a bug-fix, then it will/should be merged to 
the fixes-branch.
 ??? ? That is if the bug exists in the current "fixes" branch....
=> Sometimes a bug only exists in "fixes":
 ? That is, something got broken in "fixes", but it was not broken in 
"main". Maybe a bug-fix that was merged had a side effect causing such a 
bug.
 ? Then the "code to fix this" will go directly into the "fixes" branch. 
And only there.
=> Sometimes an individual developer works in "reverse":
 ? That is, if there is a *bug* in "main" and in "fixes":
 ?? ? - the developer adds his fix first in the "fixes" branch
 ?? ? - then merges it to "main"
 ? ?? ? (again, that actually also happened in SVN / IIRC, I haven't yet 
seen it happening in GIT)

**The issue you mentioned** belongs to (and only to):
"??? => New code goes into "main".? "
"? ? ?? - "Feature": ?? "

If you build your own IDE from a "cloned " git repo, then you can use 
"git revert" https://git-scm.com/docs/git-revert to undo any changes you 
don't want in your build.
- I do not know which commits that are
- you would need to learn more about git, if you want to keep updating 
after the revert....





From jmlandmesser at gmx.de  Wed Mar 23 11:58:39 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Wed, 23 Mar 2022 11:58:39 +0100
Subject: [Lazarus] will fixes_2_2 be merged to trunk before next release?
In-Reply-To: <db33ac69-9c87-e5b4-4666-d8211d381908@mfriebe.de>
References: <be58ed90-041b-9a73-21d2-af4a1aba6329@gmx.de>
 <1fd54b3c-4384-f3bf-82c5-58f5e4f835ae@gmx.de>
 <2be8f7e2-e7d9-9632-f321-948a321c6d4b@mfriebe.de>
 <38f6f7a7-5d0a-9804-22b6-202505a0448e@gmx.de>
 <db33ac69-9c87-e5b4-4666-d8211d381908@mfriebe.de>
Message-ID: <7435a31a-d628-ed76-e3ee-e8903e0c7ae5@gmx.de>

thanks Martin? for that tutorial in ' general workflow in git', but i'm
just a pensioner and programmer hobbyist.

As you wrote lazarus fixes_2_2 has no issue concerning qt5pas, so its
old code and nothing has to be fixed.

I don't will reopen my issue ... poor knowledge on my side, see above.

Happy coding ...

John



From the.tail.kinker at gmail.com  Sat Mar 26 18:00:41 2022
From: the.tail.kinker at gmail.com (Timothy Groves)
Date: Sat, 26 Mar 2022 13:00:41 -0400
Subject: [Lazarus] Adding unit automatically adds to uses clause
Message-ID: <d3da883c-c3b3-e8af-a795-76880e2b70b4@gmail.com>

Good day.? When I click on "New Pascal Unit" on the toolbar, or select 
it from the menu, the new unit is automatically added to the uses clause 
of my main program.? Worse, the new unit is invariably added as "unit1", 
even after I change the name of the unit.? I cannot seem to find a way 
to suppress this behaviour. Can anyone tell me how to stop Lazarus from 
doing this?


From lazarus at mfriebe.de  Sat Mar 26 18:58:01 2022
From: lazarus at mfriebe.de (Martin Frb)
Date: Sat, 26 Mar 2022 18:58:01 +0100
Subject: [Lazarus] Adding unit automatically adds to uses clause
In-Reply-To: <d3da883c-c3b3-e8af-a795-76880e2b70b4@gmail.com>
References: <d3da883c-c3b3-e8af-a795-76880e2b70b4@gmail.com>
Message-ID: <507b1ab9-54d4-aff8-ff05-ab2e51f0dbc6@mfriebe.de>

On 26/03/2022 18:00, Timothy Groves via lazarus wrote:
> Good day.? When I click on "New Pascal Unit" on the toolbar, or select 
> it from the menu, the new unit is automatically added to the uses 
> clause of my main program.? Worse, the new unit is invariably added as 
> "unit1", even after I change the name of the unit.? I cannot seem to 
> find a way to suppress this behaviour. Can anyone tell me how to stop 
> Lazarus from doing this?
>
I am not aware how to entirely to disable this.

About renaming.
If you do "Save Unit as" and enter a new name, then it should rename the 
unit in other units "uses" clauses.

IMHO, I consider it a bug that it does not update other units, if you 
change the name in source code before you save the unit for the very 
first time.

Obviously, once you saved the unit, you must do "save as" to rename it. 
Otherwise the name in the source, and the filename will not match.

From bartjunk64 at gmail.com  Sat Mar 26 23:08:38 2022
From: bartjunk64 at gmail.com (Bart)
Date: Sat, 26 Mar 2022 23:08:38 +0100
Subject: [Lazarus] Adding unit automatically adds to uses clause
In-Reply-To: <d3da883c-c3b3-e8af-a795-76880e2b70b4@gmail.com>
References: <d3da883c-c3b3-e8af-a795-76880e2b70b4@gmail.com>
Message-ID: <CAMye31zrxoaBLv7cWOe=vOo17x1ZhUqN=HGLvfiV-pTaYW4q+A@mail.gmail.com>

On Sat, Mar 26, 2022 at 6:00 PM Timothy Groves via lazarus
<lazarus at lists.lazarus-ide.org> wrote:

> Can anyone tell me how to stop Lazarus from
> doing this?

Yes, it's annoying.

Project->Options->Miscalleneous: uncheck "Main unit has uses section
containing all units of a project."

I think this is a per project setting and not globall.

--
Bart

From the.tail.kinker at gmail.com  Sun Mar 27 09:22:27 2022
From: the.tail.kinker at gmail.com (Timothy Groves)
Date: Sun, 27 Mar 2022 03:22:27 -0400
Subject: [Lazarus] Adding unit automatically adds to uses clause
In-Reply-To: <CAMye31zrxoaBLv7cWOe=vOo17x1ZhUqN=HGLvfiV-pTaYW4q+A@mail.gmail.com>
References: <d3da883c-c3b3-e8af-a795-76880e2b70b4@gmail.com>
 <CAMye31zrxoaBLv7cWOe=vOo17x1ZhUqN=HGLvfiV-pTaYW4q+A@mail.gmail.com>
Message-ID: <83879d0a-3ae2-fce4-2c6d-15056c78714e@gmail.com>

Yep, that did the trick.? Thanks!

On 2022-03-26 18:08, Bart via lazarus wrote:
>
> Project->Options->Miscalleneous: uncheck "Main unit has uses section
> containing all units of a project."
>
> I think this is a per project setting and not globall.
>
> --
> Bart

From jmlandmesser at gmx.de  Tue Mar 29 15:44:24 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Tue, 29 Mar 2022 15:44:24 +0200
Subject: [Lazarus] How to check in code if LCLWidgetType is qt5?
Message-ID: <af9de7b8-2006-b7a4-7317-8d7c4fe50683@gmx.de>

My app checks in code if trayIcon.Hint is working.

Therefor I have to distinguish in my code if the application has

LCLWidgetType=qt5 or LCLWidgetType=gtk2

The solution for gtk2 is:

> getEnvironmentVariable('LAZUSEAPPIND')

I couldn't google a check for LCLWidgetType=qt5, how to do that?


Tipps are welcome ....



From michael at freepascal.org  Tue Mar 29 15:50:03 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Tue, 29 Mar 2022 15:50:03 +0200 (CEST)
Subject: [Lazarus] Component icons howto ?
Message-ID: <alpine.DEB.2.22.394.2203291542230.1838613@home>


Hi,

2 questions :

1. What is the current procedure for registering a component ?

    I see there are 3 icons for every standard component:
    mycomponent, mycomponent_150 and mycomponent_200

    How does the IDE pick which image it needs ?

    As a corollary: what's with the strange names ?
    Why not use the size of the icon in the name, that would be a lot clearer IMHO?

    I looked in the WIKI but could not find any relevant info.

2. I would like to create icons for some new dataset descendents.
    The icons for the well-known datasets all have a text on it.
    Where can I find the icon without a text on it ?

Michael.




From nc-gaertnma at netcologne.de  Tue Mar 29 15:52:33 2022
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Tue, 29 Mar 2022 15:52:33 +0200
Subject: [Lazarus] How to check in code if LCLWidgetType is qt5?
In-Reply-To: <af9de7b8-2006-b7a4-7317-8d7c4fe50683@gmx.de>
References: <af9de7b8-2006-b7a4-7317-8d7c4fe50683@gmx.de>
Message-ID: <20220329155233.36a17fd7@limapholos>

On Tue, 29 Mar 2022 15:44:24 +0200
John Landmesser via lazarus <lazarus at lists.lazarus-ide.org> wrote:

> My app checks in code if trayIcon.Hint is working.
> 
> Therefor I have to distinguish in my code if the application has
> 
> LCLWidgetType=qt5 or LCLWidgetType=gtk2
> 
> The solution for gtk2 is:
> 
> > getEnvironmentVariable('LAZUSEAPPIND')  
> 
> I couldn't google a check for LCLWidgetType=qt5, how to do that?

Do you mean
{$IF defined(lclqt5) or defined(lclgtk2)}
?

Mattias

From jmlandmesser at gmx.de  Tue Mar 29 16:06:28 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Tue, 29 Mar 2022 16:06:28 +0200
Subject: [Lazarus] How to check in code if LCLWidgetType is qt5?
In-Reply-To: <20220329155233.36a17fd7@limapholos>
References: <af9de7b8-2006-b7a4-7317-8d7c4fe50683@gmx.de>
 <20220329155233.36a17fd7@limapholos>
Message-ID: <8fc9e47a-6037-7370-dec6-5b1357acb119@gmx.de>

Am 29.03.22 um 15:52 schrieb Mattias Gaertner via lazarus:
> On Tue, 29 Mar 2022 15:44:24 +0200
> John Landmesser via lazarus <lazarus at lists.lazarus-ide.org> wrote:
>
>> My app checks in code if trayIcon.Hint is working.
>>
>> Therefor I have to distinguish in my code if the application has
>>
>> LCLWidgetType=qt5 or LCLWidgetType=gtk2
>>
>> The solution for gtk2 is:
>>
>>> getEnvironmentVariable('LAZUSEAPPIND')
>> I couldn't google a check for LCLWidgetType=qt5, how to do that?
> Do you mean
> {$IF defined(lclqt5) or defined(lclgtk2)}
> ?
>
> Mattias

I try

{$IF defined(lclqt5)

Thank you!


From jmlandmesser at gmx.de  Tue Mar 29 17:14:56 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Tue, 29 Mar 2022 17:14:56 +0200
Subject: [Lazarus] How to check in code if LCLWidgetType is qt5?
In-Reply-To: <20220329155233.36a17fd7@limapholos>
References: <af9de7b8-2006-b7a4-7317-8d7c4fe50683@gmx.de>
 <20220329155233.36a17fd7@limapholos>
Message-ID: <ca7305ff-2eef-f221-2d6e-f42fd86145c9@gmx.de>

Am 29.03.22 um 15:52 schrieb Mattias Gaertner via lazarus:
> On Tue, 29 Mar 2022 15:44:24 +0200
> John Landmesser via lazarus <lazarus at lists.lazarus-ide.org> wrote:
>
>> My app checks in code if trayIcon.Hint is working.
>>
>> Therefor I have to distinguish in my code if the application has
>>
>> LCLWidgetType=qt5 or LCLWidgetType=gtk2
>>
>> The solution for gtk2 is:
>>
>>> getEnvironmentVariable('LAZUSEAPPIND')
>> I couldn't google a check for LCLWidgetType=qt5, how to do that?
> Do you mean
> {$IF defined(lclqt5) or defined(lclgtk2)}
> ?
>
> Mattias

My first answer got lost?

I'll take

{$IF defined(lclgtk2)}

Thanks, that worked!


From werner.pamler at freenet.de  Tue Mar 29 18:05:01 2022
From: werner.pamler at freenet.de (Werner Pamler)
Date: Tue, 29 Mar 2022 18:05:01 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <alpine.DEB.2.22.394.2203291542230.1838613@home>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
Message-ID: <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>

Am 29.03.2022 um 15:50 schrieb Michael Van Canneyt via lazarus:
> ?? I see there are 3 icons for every standard component:
> ?? mycomponent, mycomponent_150 and mycomponent_200
>
> ?? How does the IDE pick which image it needs ?

The basic image name must match the component name (including the "T"). 
The image without an appendix is used for standard resolution (96 ppi, 
100%), the image with appendix "_150" is used for 144 ppi (150%), and 
the image with appendix "_200" is used for 192 ppi (200%)


> ?? As a corollary: what's with the strange names ?
> ?? Why not use the size of the icon in the name, that would be a lot 
> clearer IMHO?

That's the way it was decided. One advantage is that when images are 
needed for other purposes, but at different sizes (e.g. the icons in the 
message window which are much smaller) the scaling procedure can still 
be the same


> ?? I looked in the WIKI but could not find any relevant info.

https://wiki.lazarus.freepascal.org/How_To_Write_Lazarus_Component#Step_3%3A_Create_icons_for_the_package

There is also a short chapter in the Lazarus Handbook vol 2, page 717.


> 2. I would like to create icons for some new dataset descendents.
> ?? The icons for the well-known datasets all have a text on it.
> ?? Where can I find the icon without a text on it ?

Roland Hahn, who designed most of the new icons, recommends to paint the 
images in svg format (using InkScape for example). For there you can 
export the required images in any size as png. He does create three 
differently sized svg images for fine-tuning, but in my own work I 
usually draw only one size, e.g 36x36.

You can find the svg source files from which all (well - most) of our 
images are created on CCR (folder "image_sources"). The TDbf database 
icons, for example, are located in 
(ccr)/image_sources/lazarus/components/tdbf etc (like in the IDE 
folder). From there you can delete or edit the text overlays.


From michael at freepascal.org  Tue Mar 29 18:37:43 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Tue, 29 Mar 2022 18:37:43 +0200 (CEST)
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
Message-ID: <alpine.DEB.2.22.394.2203291833100.1845474@home>



On Tue, 29 Mar 2022, Werner Pamler via lazarus wrote:

> Am 29.03.2022 um 15:50 schrieb Michael Van Canneyt via lazarus:
>> ?? I see there are 3 icons for every standard component:
>> ?? mycomponent, mycomponent_150 and mycomponent_200
>>
>> ?? How does the IDE pick which image it needs ?
>
> The basic image name must match the component name (including the "T"). 
> The image without an appendix is used for standard resolution (96 ppi, 
> 100%), the image with appendix "_150" is used for 144 ppi (150%), and 
> the image with appendix "_200" is used for 192 ppi (200%)

So you must always register the three images.

>
>
>> ?? As a corollary: what's with the strange names ?
>> ?? Why not use the size of the icon in the name, that would be a lot 
>> clearer IMHO?
>
> That's the way it was decided. One advantage is that when images are 
> needed for other purposes, but at different sizes (e.g. the icons in the 
> message window which are much smaller) the scaling procedure can still 
> be the same

Not sure I follow the logic ?

>
>
>> ?? I looked in the WIKI but could not find any relevant info.
>
> https://wiki.lazarus.freepascal.org/How_To_Write_Lazarus_Component#Step_3%3A_Create_icons_for_the_package

Hehe, the history shows you sneaked in the different sizes today. 
I checked only last week, so I was pretty sure the info was outdated ;-)

Many thanks !

>
> There is also a short chapter in the Lazarus Handbook vol 2, page 717.

I must be getting old. I edited this book myself :-(

>
>
>> 2. I would like to create icons for some new dataset descendents.
>> ?? The icons for the well-known datasets all have a text on it.
>> ?? Where can I find the icon without a text on it ?
>
> Roland Hahn, who designed most of the new icons, recommends to paint the 
> images in svg format (using InkScape for example). For there you can 
> export the required images in any size as png. He does create three 
> differently sized svg images for fine-tuning, but in my own work I 
> usually draw only one size, e.g 36x36.
>
> You can find the svg source files from which all (well - most) of our 
> images are created on CCR (folder "image_sources"). The TDbf database 
> icons, for example, are located in 
> (ccr)/image_sources/lazarus/components/tdbf etc (like in the IDE 
> folder). From there you can delete or edit the text overlays.

OK, I will look at the SVG files. It didn't occur to me I can remove the
text. Or possibly simply change it to what I need.

Thank you very much !

Michael.

From werner.pamler at freenet.de  Tue Mar 29 19:31:40 2022
From: werner.pamler at freenet.de (Werner Pamler)
Date: Tue, 29 Mar 2022 19:31:40 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <alpine.DEB.2.22.394.2203291833100.1845474@home>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
Message-ID: <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>

Am 29.03.2022 um 18:37 schrieb Michael Van Canneyt:
> So you must always register the three images.

You are not forced to. But when you provide only the standard size and 
run the IDE at 200% the IDE will upscale the 24x24 image to double size, 
and the icon will become blurry - just as it was in the days before 
Ondrej implemented all these scaling functions. (BTW: a long time before 
Delphi which seems to support High-Dpi only now in the recent release).


>>> ?? As a corollary: what's with the strange names ?
>>> ?? Why not use the size of the icon in the name, that would be a lot 
>>> clearer IMHO?
>>
>> That's the way it was decided. One advantage is that when images are 
>> needed for other purposes, but at different sizes (e.g. the icons in 
>> the message window which are much smaller) the scaling procedure can 
>> still be the same
>
> Not sure I follow the logic ?

I don't know the actual procedure names ATM, but imagine that when the 
message window needs a "warning" icon (which is - say - 12x12 at 96ppi) 
then the scaling procedure at 192ppi only needs to look for 
"warning_200.png". If the exact image size would have been included in 
the file name instead ("warning_24x24.png"), it would have to know the 
size of the base image at 96ppi in order to select the right image. A 
little simplification.


>>> ?? I looked in the WIKI but could not find any relevant info.
>>
>> https://wiki.lazarus.freepascal.org/How_To_Write_Lazarus_Component#Step_3%3A_Create_icons_for_the_package 
>>
>
> Hehe, the history shows you sneaked in the different sizes today. I 
> checked only last week, so I was pretty sure the info was outdated ;-)

I had written this part of the wiki already in 2018, so it definitely 
was not outdated. I just noticed that it was missing some basic 
requirements (like component name = image name) and decided to rewrite 
the paragraph.


> OK, I will look at the SVG files. It didn't occur to me I can remove the
> text. Or possibly simply change it to what I need.
I am attaching the three "database" png images extracted from the TDbf 
svgs without the text, in case you have problems with InkScape (which 
definitely will not win the prize of the most user-friendly software).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: database-icon.png
Type: image/png
Size: 876 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220329/ab95210d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: database-icon_150.png
Type: image/png
Size: 1595 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220329/ab95210d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: database-icon_200.png
Type: image/png
Size: 1464 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220329/ab95210d/attachment-0002.png>

From michael at freepascal.org  Tue Mar 29 19:45:43 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Tue, 29 Mar 2022 19:45:43 +0200 (CEST)
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
Message-ID: <alpine.DEB.2.22.394.2203291939290.1854851@home>



On Tue, 29 Mar 2022, Werner Pamler wrote:

> Am 29.03.2022 um 18:37 schrieb Michael Van Canneyt:
>> So you must always register the three images.
>
> You are not forced to. But when you provide only the standard size and run 
> the IDE at 200% the IDE will upscale the 24x24 image to double size, and the 
> icon will become blurry - just as it was in the days before Ondrej 
> implemented all these scaling functions. (BTW: a long time before Delphi 
> which seems to support High-Dpi only now in the recent release).

OK, thank you.

>
>
>>>> ?? As a corollary: what's with the strange names ?
>>>> ?? Why not use the size of the icon in the name, that would be a lot 
>>>> clearer IMHO?
>>> 
>>> That's the way it was decided. One advantage is that when images are 
>>> needed for other purposes, but at different sizes (e.g. the icons in the 
>>> message window which are much smaller) the scaling procedure can still be 
>>> the same
>> 
>> Not sure I follow the logic ?
>
> I don't know the actual procedure names ATM, but imagine that when the 
> message window needs a "warning" icon (which is - say - 12x12 at 96ppi) then 
> the scaling procedure at 192ppi only needs to look for "warning_200.png". If 
> the exact image size would have been included in the file name instead 
> ("warning_24x24.png"), it would have to know the size of the base image at 
> 96ppi in order to select the right image. A little simplification.

I fail to see the link between 192 and 200. This requires people to know
that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a standard size.

For me - and I've been in IT for quite some time now - this is far from
obvious that this should result in 24x24, 36x36 and 48x48 icon sizes.

In short: I think this is a horribly contorted scheme.

All other systems I came across simply use icon dimensions in the name. 
Far simpler and hence preferable in my opinion.

>>>> ?? I looked in the WIKI but could not find any relevant info.
>>> 
>>> https://wiki.lazarus.freepascal.org/How_To_Write_Lazarus_Component#Step_3%3A_Create_icons_for_the_package 
>> 
>> Hehe, the history shows you sneaked in the different sizes today. I checked 
>> only last week, so I was pretty sure the info was outdated ;-)
>
> I had written this part of the wiki already in 2018, so it definitely was not 
> outdated. I just noticed that it was missing some basic requirements (like 
> component name = image name) and decided to rewrite the paragraph.

the 3 sizes were not mentioned when last I looked ?

>
>
>> OK, I will look at the SVG files. It didn't occur to me I can remove the
>> text. Or possibly simply change it to what I need.
> I am attaching the three "database" png images extracted from the TDbf svgs 
> without the text, in case you have problems with InkScape (which definitely 
> will not win the prize of the most user-friendly software).

Well, I managed to get something working with Inkscape. 
I already committed TJSONDataset. 
(for which, strangely enough, there was already an image)

Thank you for all explanations.

Michael.

From lazarus at kluug.net  Wed Mar 30 09:16:38 2022
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Wed, 30 Mar 2022 09:16:38 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <alpine.DEB.2.22.394.2203291939290.1854851@home>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
Message-ID: <9c588008-6817-d405-aae9-525b380a6449@kluug.net>

On 29.03.2022 19:45, Michael Van Canneyt via lazarus wrote:
> On Tue, 29 Mar 2022, Werner Pamler wrote:
>> I don't know the actual procedure names ATM, but imagine that when 
>> the message window needs a "warning" icon (which is - say - 12x12 at 
>> 96ppi) then the scaling procedure at 192ppi only needs to look for 
>> "warning_200.png". If the exact image size would have been included 
>> in the file name instead ("warning_24x24.png"), it would have to know 
>> the size of the base image at 96ppi in order to select the right 
>> image. A little simplification.
>
> I fail to see the link between 192 and 200. This requires people to know
> that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a 
> standard size.

Forget about the DPI/PPI values. What you need is the %-scaling factor 
of the original size.


> For me - and I've been in IT for quite some time now - this is far from
> obvious that this should result in 24x24, 36x36 and 48x48 icon sizes.

What?

100% => 24px - that is the usual and recommended size for component 
palette icons at 100% scaling - e.g. Delphi uses the same size for the 
component icons. Take it as a starting point.
150% => 24px * 150 / 100 = 36px
200% => 24px * 200 / 100 = 48px

That should be obvious for everybody who knows basic math :)


> In short: I think this is a horribly contorted scheme.
>
> All other systems I came across simply use icon dimensions in the 
> name. Far simpler and hence preferable in my opinion.

I don't think so. Let me explain:

1.) One reason is legacy&compatibility. Before the High-DPI stuff, all 
the IDE icons did not have the size in the name. Having the icon size in 
px in the name would require a bigger rewrite of Lazarus code than it 
was necessary for the scaling-postfixes and without any gain (see [2] 
below).

There are various places where icons with different sizes are used: tool 
bars (16px), code editor (11px), component palette (24px). All these 
icons did not have the size in the name originally.

2.) The second reason and the main advantage is that Lazarus doesn't 
[need to] know what size of the icon is supplied at a specific scaling 
(even at 100%). The icon sizes are not strictly defined.

The file naming convention is: the original variants (at 100%) do not 
have a postfix, the scaled variants have a postfix with the scaling 
factor in % based on the original icon => you open Lazarus on a screen 
with 150% scaling, Lazarus automatically picks up the icons with "_150" 
postfix. If not found, it scales the original ones automatically. Easy.

Having the size in the file name means that every function that requests 
an icon would have to know the resulting px-size it looks for. That is 
not wanted due to:

2.a) Rounding problems: do you round 11*150%=16.5 to 16px or 17px? You 
would have to consider the same rounding both in the Lazarus code and in 
the graphics editor. Currently only the graphics editor decides about 
the best size of the scaled icon and Lazarus can cope with the undefined 
icon size.

2.b) unwanted fixed icon size: there can be icons at 100% with 16px and 
at 200% with 30px, if the graphics designer decided so. Lazarus will 
take the 30px icons without any issues.

Or, if somebody now decides that the 11px code editor icons need a 
redesign and the new icons will have a base size of 12px instead of 
11px, there is no need to change anything in the code. Lazarus will cope 
with the new size of the icons unless the new size is a complete nonsense.

Ondrej


From michael at freepascal.org  Wed Mar 30 09:57:07 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Wed, 30 Mar 2022 09:57:07 +0200 (CEST)
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
Message-ID: <alpine.DEB.2.22.394.2203300944060.1871868@home>



On Wed, 30 Mar 2022, Ondrej Pokorny via lazarus wrote:

> On 29.03.2022 19:45, Michael Van Canneyt via lazarus wrote:
>> On Tue, 29 Mar 2022, Werner Pamler wrote:
>>> I don't know the actual procedure names ATM, but imagine that when the 
>>> message window needs a "warning" icon (which is - say - 12x12 at 96ppi) 
>>> then the scaling procedure at 192ppi only needs to look for 
>>> "warning_200.png". If the exact image size would have been included in the 
>>> file name instead ("warning_24x24.png"), it would have to know the size of 
>>> the base image at 96ppi in order to select the right image. A little 
>>> simplification.
>> 
>> I fail to see the link between 192 and 200. This requires people to know
>> that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a standard 
>> size.
>
> Forget about the DPI/PPI values. What you need is the %-scaling factor of the 
> original size.

Why do you think I know this is a scaling factor ?

I didn't have a clue until Werner explained.

Sorry, you can argue all you like, but if I see a list of icon files xyz_24x24.png 
then I know *exactly* what to create, just from the filenames. 
No need to do math, open file whatnot.

With your method, I need to open the file (unless I know standard size is
24), check the size, and then possibly multiply (if I know that the suffix
is the scaling factor in %).

As it was, I actually opened 3 files to see what the needed sizes were.

By contrast, if I need to create icons for a Linux app I check e.g:

> ls /usr/share/icons/gnome/
128x128/  16x16/  22x22/  24x24/  256x256/  32x32/  48x48/  512x512/  64x64/  8x8/  icon-theme.cache  index.theme  scalable/

and I know exactly what to create, just from the names.

If you think that your method is easier, we have very different concepts of what is 'easy'.

Clearly, I would not be asking these questions if it was so obvious.

Michael.

From lists at kingel.net  Wed Mar 30 10:20:12 2022
From: lists at kingel.net (Arne Hanssen)
Date: Wed, 30 Mar 2022 10:20:12 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <alpine.DEB.2.22.394.2203300944060.1871868@home>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
 <alpine.DEB.2.22.394.2203300944060.1871868@home>
Message-ID: <94c43215-2995-8bb0-1b07-55381a3d3a56@kingel.net>


Den 30.03.2022 09:57, skreiv Michael Van Canneyt via lazarus:
>
> [...]
>
> Why do you think I know this is a scaling factor ?
>
> I didn't have a clue until Werner explained.
>
> Sorry, you can argue all you like, but if I see a list of icon files 
> xyz_24x24.png then I know *exactly* what to create, just from the 
> filenames. No need to do math, open file whatnot.
>
> With your method, I need to open the file (unless I know standard size is
> 24), check the size, and then possibly multiply (if I know that the 
> suffix
> is the scaling factor in %).
>
> [...]
>
I would guess that naming the files 'xyz_24x24.png' (base size 24px), 
'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) 
could be a reasonable naming solution?

-- 
Best regards
Arne Hanssen


From michael at freepascal.org  Wed Mar 30 10:44:20 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Wed, 30 Mar 2022 10:44:20 +0200 (CEST)
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <94c43215-2995-8bb0-1b07-55381a3d3a56@kingel.net>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
 <alpine.DEB.2.22.394.2203300944060.1871868@home>
 <94c43215-2995-8bb0-1b07-55381a3d3a56@kingel.net>
Message-ID: <alpine.DEB.2.22.394.2203301038590.1872584@home>



On Wed, 30 Mar 2022, Arne Hanssen via lazarus wrote:

>
> Den 30.03.2022 09:57, skreiv Michael Van Canneyt via lazarus:
>> 
>> [...]
>> 
>> Why do you think I know this is a scaling factor ?
>> 
>> I didn't have a clue until Werner explained.
>> 
>> Sorry, you can argue all you like, but if I see a list of icon files 
>> xyz_24x24.png then I know *exactly* what to create, just from the 
>> filenames. No need to do math, open file whatnot.
>> 
>> With your method, I need to open the file (unless I know standard size is
>> 24), check the size, and then possibly multiply (if I know that the suffix
>> is the scaling factor in %).
>> 
>> [...]
>> 
> I would guess that naming the files 'xyz_24x24.png' (base size 24px), 
> 'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) could be 
> a reasonable naming solution?

As I said: 150, 200 do not strike me as scalings in percent.

That the CPU needs to do an extra couple of cycles (convert scaling to
pixel) to make things easier on humans - that's why mankind invented it.

Forgive me, but I will discontinue the discussion.

I think I made it clear what I think is (in my view) absurd and have no wish
to antagonize anyone by continuing to argue for something which should be
obvious and plain.

Michael.

From lazarus at kluug.net  Wed Mar 30 11:21:04 2022
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Wed, 30 Mar 2022 11:21:04 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <alpine.DEB.2.22.394.2203300944060.1871868@home>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
 <alpine.DEB.2.22.394.2203300944060.1871868@home>
Message-ID: <c85eca21-b44d-6cd5-1bc2-92818959aefa@kluug.net>

On 30.03.2022 09:57, Michael Van Canneyt via lazarus wrote:
> On Wed, 30 Mar 2022, Ondrej Pokorny via lazarus wrote:
>> On 29.03.2022 19:45, Michael Van Canneyt via lazarus wrote:
>>> On Tue, 29 Mar 2022, Werner Pamler wrote:
>>>> I don't know the actual procedure names ATM, but imagine that when 
>>>> the message window needs a "warning" icon (which is - say - 12x12 
>>>> at 96ppi) then the scaling procedure at 192ppi only needs to look 
>>>> for "warning_200.png". If the exact image size would have been 
>>>> included in the file name instead ("warning_24x24.png"), it would 
>>>> have to know the size of the base image at 96ppi in order to select 
>>>> the right image. A little simplification.
>>>
>>> I fail to see the link between 192 and 200. This requires people to 
>>> know
>>> that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a 
>>> standard size.
>>
>> Forget about the DPI/PPI values. What you need is the %-scaling 
>> factor of the original size.
>
> Why do you think I know this is a scaling factor ?
>
> I didn't have a clue until Werner explained.
>
> Sorry, you can argue all you like, but if I see a list of icon files 
> xyz_24x24.png then I know *exactly* what to create, just from the 
> filenames. No need to do math, open file whatnot.
>
> With your method, I need to open the file (unless I know standard size is
> 24), check the size, and then possibly multiply (if I know that the 
> suffix
> is the scaling factor in %).
>
> As it was, I actually opened 3 files to see what the needed sizes were.
>
> By contrast, if I need to create icons for a Linux app I check e.g:
>
>> ls /usr/share/icons/gnome/
> 128x128/? 16x16/? 22x22/? 24x24/? 256x256/? 32x32/? 48x48/ 512x512/? 
> 64x64/? 8x8/? icon-theme.cache? index.theme? scalable/
>
> and I know exactly what to create, just from the names.
>
> If you think that your method is easier, we have very different 
> concepts of what is 'easy'.

Well, the difference is the point-of-view and not the concept. My 
point-of-view is the Lazarus IDE developer. Yours is the user.
Mine is easier from the Lazarus development POV, yours is from the 
user's POV.


> Clearly, I would not be asking these questions if it was so obvious.

Once you get to know what the postfixes mean, I think it is obvious. I 
agree that it is not obvious per se and having the size in the file name 
is more obvious and easier for the user. Having said that, both methods 
would have to be documented, so after reading the docs both methods 
should be equally clear and easy.

When I worked at the high-DPI Lazarus IDE, I picked up the more obvious 
and easier way for the Lazarus IDE development.

I mainly didn't want to bother with these questions about legacy icons: 
what do you do with the icons "abc.png" (11x11px) and "def.png" 
(16x16px) - do you rename them[?], what do you do with 3rd party IDE 
extensions and packages that supply such icons and Lazarus doesn't have 
control over them etc etc? With the "_150" and "_200" I did not have to 
solve these issues. With yours I did have to solve them indeed.

I am not saying your concept is wrong, I just try to explain the 
reasoning about the concept with scaling postfixes.

Of course all the issues above exist just due to the fact that the IDE 
uses different icon sizes and to keep things simple I decided to have 
the same naming convention for both IDE icons and component icons.

---

I am not against extending the component icon loading to handle a 
different file name convention. As Delphi uses the same concept that you 
prefer https://blogs.embarcadero.com/new-in-10-2-2-component-icons/ , if 
the Lazarus code should be extended then definitely to support the 
Delphi way:

RCDATA TLabel32_PNG "tlabel32.png"

The resource name is the component class name plus the px-value postfix 
(16, 24, 32, ...) and "_PNG" in case of a png file.

Yes, I am absolutely OK with it as an alternative naming convention for 
the component palette because we probably do not want to give up the 
current naming convention due to the effort needed for renaming all the 
files and due to legacy compatibility. But if others agree and somebody 
is willing to take the maintenance effort, we could also deprecate the 
current naming convention and remove it in the 2nd-to-come stable version.

Lazarus had the High-DPI support before Delphi so there was no chance 
for us to know what Delphi would eventually choose, so having the 
Delphi-convention as an alternative was inevitable anyway.

---

I am not sure about the IDE icons, though - due to the issues regarding 
different icon sizes. But if you have a solution for these issues, you 
can definitely implement it as well.

Ondrej


From lazarus at kluug.net  Wed Mar 30 11:24:59 2022
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Wed, 30 Mar 2022 11:24:59 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <94c43215-2995-8bb0-1b07-55381a3d3a56@kingel.net>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
 <alpine.DEB.2.22.394.2203300944060.1871868@home>
 <94c43215-2995-8bb0-1b07-55381a3d3a56@kingel.net>
Message-ID: <000e55dd-5ec1-1d2b-9eb8-3f15c55483bc@kluug.net>

On 30.03.2022 10:20, Arne Hanssen via lazarus wrote:
> I would guess that naming the files 'xyz_24x24.png' (base size 24px), 
> 'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) 
> could be a reasonable naming solution?

On the contrary: it is the bad from both naming solutions :)

You need to know both the scaling factor and the size.

Ondrej


From werner.pamler at freenet.de  Wed Mar 30 12:33:01 2022
From: werner.pamler at freenet.de (Werner Pamler)
Date: Wed, 30 Mar 2022 12:33:01 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <c85eca21-b44d-6cd5-1bc2-92818959aefa@kluug.net>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
 <alpine.DEB.2.22.394.2203300944060.1871868@home>
 <c85eca21-b44d-6cd5-1bc2-92818959aefa@kluug.net>
Message-ID: <b6f4a83b-f5ce-520c-7997-a8283c27f9de@freenet.de>

Am 30.03.2022 um 11:21 schrieb Ondrej Pokorny via lazarus:
> I am not against extending the component icon loading to handle a 
> different file name convention. As Delphi uses the same concept that 
> you prefer 
> https://blogs.embarcadero.com/new-in-10-2-2-component-icons/ , if the 
> Lazarus code should be extended then definitely to support the Delphi 
> way:
>
> RCDATA TLabel32_PNG "tlabel32.png"
>
> The resource name is the component class name plus the px-value 
> postfix (16, 24, 32, ...) and "_PNG" in case of a png file.
>
> Yes, I am absolutely OK with it as an alternative naming convention 
> for the component palette because we probably do not want to give up 
> the current naming convention due to the effort needed for renaming 
> all the files and due to legacy compatibility. But if others agree and 
> somebody is willing to take the maintenance effort, we could also 
> deprecate the current naming convention and remove it in the 
> 2nd-to-come stable version.
>
> Lazarus had the High-DPI support before Delphi so there was no chance 
> for us to know what Delphi would eventually choose, so having the 
> Delphi-convention as an alternative was inevitable anyway.


Not convinced that this offers a significant advantage. The component 
writer has to consider so many differences to Delphi anyway, so I would 
not care about a different icon naming convention. I am against 
deprecating the old naming scheme because we would have to rename 
thousands of icons (and their svg source files).

Rather than that, I think the effort should be put into support of svg 
images.


From lazarus at kluug.net  Wed Mar 30 16:52:16 2022
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Wed, 30 Mar 2022 16:52:16 +0200
Subject: [Lazarus] Component icons howto ?
In-Reply-To: <alpine.DEB.2.22.394.2203301038590.1872584@home>
References: <alpine.DEB.2.22.394.2203291542230.1838613@home>
 <e3b0b377-9a5f-f451-bf57-30f52f2985f8@freenet.de>
 <alpine.DEB.2.22.394.2203291833100.1845474@home>
 <f42042f6-494b-b2c8-1c1d-47b69023c730@freenet.de>
 <alpine.DEB.2.22.394.2203291939290.1854851@home>
 <9c588008-6817-d405-aae9-525b380a6449@kluug.net>
 <alpine.DEB.2.22.394.2203300944060.1871868@home>
 <94c43215-2995-8bb0-1b07-55381a3d3a56@kingel.net>
 <alpine.DEB.2.22.394.2203301038590.1872584@home>
Message-ID: <177e971e-fb89-c735-26a0-0fc46f369ca8@kluug.net>

On 30.03.2022 10:44, Michael Van Canneyt via lazarus wrote:
> On Wed, 30 Mar 2022, Arne Hanssen via lazarus wrote:
>> Den 30.03.2022 09:57, skreiv Michael Van Canneyt via lazarus:
>>>
>>> [...]
>>>
>>> Why do you think I know this is a scaling factor ?
>>>
>>> I didn't have a clue until Werner explained.
>>>
>>> Sorry, you can argue all you like, but if I see a list of icon files 
>>> xyz_24x24.png then I know *exactly* what to create, just from the 
>>> filenames. No need to do math, open file whatnot.
>>>
>>> With your method, I need to open the file (unless I know standard 
>>> size is
>>> 24), check the size, and then possibly multiply (if I know that the 
>>> suffix
>>> is the scaling factor in %).
>>>
>>> [...]
>>>
>> I would guess that naming the files 'xyz_24x24.png' (base size 24px), 
>> 'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) 
>> could be a reasonable naming solution?
>
> As I said: 150, 200 do not strike me as scalings in percent.
>
> That the CPU needs to do an extra couple of cycles (convert scaling to
> pixel) to make things easier on humans - that's why mankind invented it.
>
> Forgive me, but I will discontinue the discussion.
>
> I think I made it clear what I think is (in my view) absurd and have 
> no wish
> to antagonize anyone by continuing to argue for something which should be
> obvious and plain.

I don't think anybody took this personal - definitely not myself. But I 
still don't know what you intended with the discussion. The naming 
convention has been like this for 5 years - I introduced it in this 
commit 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/2135d3058f078e3df8b957c4fa4e52e1fa1ae83b

We now tried to explain the reasoning behind it - I honestly did not 
care that much about the naming convention back then: I just took what 
was the simplest way from my POV - simplest to extend the existing code 
and the existing directory and file structure. I concentrated much more 
on the scaling system behind it as it was quite a monster of a change. I 
do admit that I did not think about the icon creators on the other side 
at all - so I missed what you see is "obvious and plain". Sorry for that 
but what should I do with it now?

If somebody (including you) had raised the discussion about the (not 
obvious) naming back then before hundreds of icons were added, it would 
have been a much easier change than today. But there was no such 
discussion (no alternative was either suggested or rejected), so we 
ended up with the solution that I picked up. There were no bad 
intentions from my side, I just decided somehow and nobody has 
complained about it for 5 years. That's all about it.

I now cannot do a lot about a 5-year-old decision. Yes, it may have been 
wrong, but I am not going to rename all the files added in the meantime 
by myself...

Yes, we can still extend the code to support Delphi's naming convention. 
But as Werner stated before, we won't rename current icons ourselves. If 
you want to take the effort because you think it is worth it and Werner 
is not against, go for it. I personally don't think it is worth it.

In the end it's just about file names, the result is the same: the user 
sees pixel-perfect icons and the IDE scales nicely. A different naming 
convention won't improve that.

Ondrej