Re: [Lazarus] Regular Lazarus crash when starting a new project
11.05.2024 08:16, Michael Van Canneyt пишет: On Fri, 10 May 2024, Maxim Ganetsky via lazarus wrote: commit 16e2f677e2b2e0eaf14bcb4ef67f4ed83db21cfe Author: Juha Date: Fri Mar 8 07:21:11 2024 +0200 LCL: Fix TForm.LastActiveControl behavior. Issue #40774, patch by Bernd Jung. Anything else I could check ? Please bisect to find commit that broke it for you. I did that, going back half a a year (I did my last lazarus update roughly 2 months ago). It didn't change anything. So I rebuilt 'bigide' instead of 'useride'. All worked. I then removed the anchordockingdesign package, and after a make of useride, the bug was no longer there. Meaning the error is in the anchordocking package. It is likely that AnchorDocking package just triggers some issue in Gtk2 widgetset which manifests only under some specific WM (or even with some specific Gtk2 theme, it may be good idea to test this too BTW). Please create an issue with backtrace and exact description of environment where it can be reproduced (it works just fine in Xfce for example). It seems I didn't start a new project since I activated anchordocking. (which is a little over a month ago...) Michael. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Regular Lazarus crash when starting a new project
10.05.2024 16:24, Michael Van Canneyt via lazarus пишет: Do I understand correctly that it crashes when you try to open Project->"Create Project ..." or "File"->"Create ..." dialog? Yes. It works just fine here with FPC 3.2.2 (in Xfce, but I doubt that it matters in this case). Are you using FPC 3.3.1? No, I only use FPC 3.2.2 to compile Lazarus, never 3.3.1. I am not so sure that it is not related to Xfce, I suppose it uses a different window manager than Linux Mint ? I had problems with Lazarus and Cinnamon in the past: more often than not starting a debugging session crashed Cinnamon. But that improved when I upgraded to Mint 21. Maybe it is a regression in Cinnamon, but since Lazarus is the only program on my computer that has this issue, I tend to look at Lazarus for the cause. My main problem is that I have no clue how to debug it, maybe the --sync option as explained in the error message will tell me more. Well, I am now 99.99% sure it is a Lazarus issue, recently introduced: It also happens on my work PC: a standard Ubuntu 22.04 with Gnome. I didn't have it before. Only after updating lazarus to the latest git wednesday. Unfortunately, I don't have the exact git commits :/ However, now I have a backtrace when running with --sync: #0 0x779698d0 in _XError () at /lib/x86_64-linux-gnu/libX11.so.6 #1 0x77969af7 in () at /lib/x86_64-linux-gnu/libX11.so.6 #2 0x77969b95 in () at /lib/x86_64-linux-gnu/libX11.so.6 #3 0x7796b40d in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6 #4 0x7795f172 in XReconfigureWMWindow () at /lib/x86_64-linux-gnu/libX11.so.6 #5 0x77f517d1 in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #6 0x0050bb3e in APPREMOVESTAYONTOPFLAGS (this=0x7696a250, ASYSTEMTOPALSO=true) at gtk2/gtk2widgetset.inc:1286 #7 0x004a7758 in REMOVESTAYONTOP (this=0x76969bf0, ASYSTEMTOPALSO=true) at include/application.inc:1369 #8 0x004a4e73 in MODALSTARTED (this=0x76969bf0) at include/application.inc:375 #9 0x0049e9eb in SHOWMODAL (this=0x7fffef37dbf0) at include/customform.inc:3002 #10 0x019fabd4 in SHOWMODALOPTIONS (this=0x7fffef9166e0, FRM=0x7fffef37dbf0) at pjsdsgnregister.pas:502 #11 0x019fa8fe in SHOWOPTIONSDIALOG (this=0x7fffef9166e0) at pjsdsgnregister.pas:468 #12 0x019fb0a1 in DOINITDESCRIPTOR (this=0x7fffef9166e0) at pjsdsgnregister.pas:540 #13 0x008a1740 in INITDESCRIPTOR (this=0x7fffef9166e0) at projectintf.pas:1337 #14 0x004d5ced in DONEWPROJECT (this=0x74805050, PROJECTDESC=0x7fffef9166e0) at main.pp:6403 #15 0x004cd5f3 in MNUNEWPROJECTCLICKED (this=0x74805050, SENDER=0x7fffef86cfc0) at main.pp:4306 #16 0x00b136cf in MENUITEMCLICK (this=0x7fffef86cfc0, SENDER=0x7fffef8bfae0) at menuintf.pas:562 #17 0x00b17500 in MENUITEMCLICK (this=0x7fffef86cfc0, SENDER=0x7fffef8bfae0) at menuintf.pas:1720 #18 0x005fc871 in CLICK (this=0x7fffef8bfae0) at include/menuitem.inc:83 #19 0x005fd178 in DOCLICKED (this=0x7fffef8bfae0, MSG=0) at include/menuitem.inc:296 #20 0x004397c8 in DISPATCH (this=0x7fffef8bfae0, MESSAGE=0) at ../inc/objpas.inc:684 #21 0x007db769 in DELIVERMESSAGE (TARGET=0x7fffef8bfae0, AMESSAGE=0) at lclmessageglue.pas:116 #22 0x0067c120 in DELIVE RMESSAGE (TARGET=0x7fffef8bfae0, AMESSAGE=0) at gtk2/gtk2proc.inc:3796 #23 0x008297d6 in GTK2MENUITEMACTIVATE (WIDGET=0x3425040, DATA=0x7fffef8bfae0) at gtk2/gtk2wsmenus.pp:139 #24 0x778a9d2f in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #25 0x778c5c36 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #26 0x778c7614 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #27 0x778c7863 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x77cd041c in gtk_widget_activate () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #29 0x77bba335 in gtk_menu_shell_activate_item () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #30 0x77bbbec3 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #31 0x77ba84d7 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #32 0x778a9d2f in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #33 0x778c5624 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #34 0x778c7026 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #35 0x778c7863 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #36 0x77cd4024 in () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #37 0x77ba6094 in gtk_propagate_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #38 0x77ba76db in gtk_main_do_event () at /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #39 0x77f4316b in () at /lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #40 0x777b0d3b in
Re: [Lazarus] Regular Lazarus crash when starting a new project
09.05.2024 17:45, Michael Van Canneyt via lazarus пишет: Hi, I'm getting a regular lazarus crash when starting a new project that opens a dialog that allows you to configure the project (fpcunit, web browser..) Today's lazarus from git. Linux 64-bit, gtk2 widgetset, linux mint running cinnamon. Console output: - Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-linux--gtk2 New=x86_64-linux--gtk2 Changed: OS/CPU=True LCL=False Hint: (lazarus) [TMainIDE.DoOpenProjectFile] "/home/michael/projects/fresnel/demo/Basic/basic.lpi" Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-linux--gtk2 New=wasm32-wasi-browser-gtk2 Changed: OS/CPU=True LCL=False The program 'lazarus' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 111751 error_code 3 request_code 12 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Projects that do not open a project configuration dialog seem unaffected. I recently switched to using a docked IDE, maybe this has some influence ? Any hints, things I can try ? Do I understand correctly that it crashes when you try to open Project->"Create Project ..." or "File"->"Create ..." dialog? It works just fine here with FPC 3.2.2 (in Xfce, but I doubt that it matters in this case). Are you using FPC 3.3.1? -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Merge requests vs patches on issues?
08.05.2024 23:33, Zoë Peterson via lazarus пишет: Is there a preferred submission style for patches? That is, is one of these better/easier for the maintainers than the others? 1) Create issue, then create merge request referencing issue 2) Create merge request with bug details as part of the merge request submission (or in commit message?) 3) Create issue and include raw patch Also, should we preemptively tag the appropriate maintainer? I've done #2 twice now, and I see that in the merged one the GitLab UI makes it fairly easy to view the original merge request where I included more details and a sample project, but I could see the lack of an "issue #1234" in the commit message making it more annoying to refer back to. Generally I prefer #2. But #1 can be warranted sometimes too, yes. It should be decided individually for each case. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Main shows lots of changes in language files after rebuilding
09.04.2024 08:30, Christo Crause via lazarus пишет: I updated the Lazarus main version yesterday. After rebuilding the IDE, git shows that the PO files in ide/packages/ideconfig/languages changed. If these files are modified by the build process can they be updated in git please. Or is something else wrong? Committed. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus 2.2.6 on Raspberry Pi5B, error during build
10.12.2023 19:51, Bo Berglund via lazarus пишет: I am setting up my new RPi3B with 64 bit Pi-OS Bookworm and have now come to FreePascal/Lazarus. Freepascal is built from sources (trunk of 3.2.3) using a seed compiler 3.2.2 earlier obtained as an apt install on an RPi4B also running Pi-OS 64 bit Bookworm. [...] Note that I am using fpc 3.2.3 head revision on this system since no other version seems to be possible to build on the 64 bit Pi-OS. But that version builds without problems. So I am using the self-compiled fpc 3.2.3 to build Lazarus 2.2.6 and it fails during build with the following exit message (only end of output shown): This combination of FPC and Lazarus won't work. You should use head revisions of Lazarus from `fixes_3_0` or `main` branches if you want use FPC 3.2.3 and up. make bigide (9009) Assembling translations (3104) Compiling uitypes.pas /home/bosse/devtools/lazarus/2.2.6/components/lazutils/uitypes.pas(105,14) Error: (3285) Expected another 2 array elements /home/bosse/devtools/lazarus/2.2.6/components/lazutils/uitypes.pas(93,58) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted make[1]: *** [Makefile:3394: lazutils.ppu] Error 1 make[1]: Leaving directory '/home/bosse/devtools/lazarus/2.2.6/components/lazutils' make: *** [Makefile:3802: lazutils] Error 2 [...] -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Attn. Mattias, adding x86 CPU detection function to DefineTemplates.pas
24.11.2023 0:55, Mattias Gaertner via lazarus пишет: On 23.11.23 02:11, Maxim Ganetsky via lazarus wrote: Hello. I am trying to solve https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/38786 (Lazarus emits x86-specific assembler mode compiler option for non-x86 CPUs). In order to solve it, I need to add the following function to DefineTemplates.pas: function IsCPUX86(TargetCPU: string): boolean; begin TargetCPU := GetFPCTargetCPU(TargetCPU); Result:=(TargetCPU='i8086') or (TargetCPU='i386') or (TargetCPU='x86_64'); end; ok Cool, fixed in https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/7eb6be5a2cdbd9d57ac4adb71348701f9139e709 and merged to `fixes_3_0`. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Attn. Mattias, adding x86 CPU detection function to DefineTemplates.pas
Hello. I am trying to solve https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/38786 (Lazarus emits x86-specific assembler mode compiler option for non-x86 CPUs). In order to solve it, I need to add the following function to DefineTemplates.pas: function IsCPUX86(TargetCPU: string): boolean; begin TargetCPU := GetFPCTargetCPU(TargetCPU); Result:=(TargetCPU='i8086') or (TargetCPU='i386') or (TargetCPU='x86_64'); end; The questions are: 1. Is it correct place? 2. Is its name OK? 3. Maybe I missed some existing function? The complete patch is attached in the issue. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Building lazarus broken ?
20.11.2023 0:51, Michael Van Canneyt via lazarus пишет: On Sun, 19 Nov 2023, Maxim Ganetsky via lazarus wrote: 19.11.2023 19:07, Michael Van Canneyt via lazarus пишет: Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. Makefiles are updated by updatemakefiles tool: Make sure *Additions and Overrides* are empty and run FPCDIR=/path/to/fpc/src/trunk PATH=/path/trunk/fpc/utils/fpcm/bin/x86_64-linux/:$PATH ./tools/updatemakefiles Thank you. Maybe this should be documented somewhere ? Actually it was a copy-paste from Lazarus release management page in Wiki: https://wiki.freepascal.org/Lazarus_3.0_fixes_branch#Tagging_release So it is documented. :) But documentation can be improved indeed. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Building lazarus broken ?
19.11.2023 19:07, Michael Van Canneyt via lazarus пишет: Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. Makefiles are updated by updatemakefiles tool: Make sure *Additions and Overrides* are empty and run FPCDIR=/path/to/fpc/src/trunk PATH=/path/trunk/fpc/utils/fpcm/bin/x86_64-linux/:$PATH ./tools/updatemakefiles -- Best regards, Maxim Ganetskymailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Building lazarus broken ?
19.11.2023 19:21, Michael Van Canneyt via lazarus пишет: On Sun, 19 Nov 2023, Michael Van Canneyt via lazarus wrote: Hi, I did some changes to the fpcunit support. All worked in the IDE. In order to push my changes, I did a git pull. The change broke the "make bigide" command, so I was told by the CI/CD. Turns out the makefiles did not respect the lazarus dependencies in the packages: the new dependency on the codetools package was not taken into account by the makefiles. (how an uninitiated heathen like me is supposed to know this is probably only known to the happy initiated... ;)) I managed to fix that, fix is pushed so 'make bigide' works again. However, the git pull destroyed building the IDE in the IDE. For some reason, the IDE (I'm on linux mint) thinks it needs to build a cocoa version of the LCL. This is the lcl.pas as generated by the build procedure: uses AllLCLIntfUnits, CocoaConfig, CocoaCursor, CocoaMenus, LazarusPackageIntf; In the build settings, I did specify gtk2,linux,x86_64 as the platform settings. So why does the IDE insist on recreating a cocoa version of lcl.pas ? Well, as usual I found the answer myself after asking the question :/ This is the culprit: --- commit f821ad251b945f3435303f208b2e7de045749424 Author: rich2014 Date: Sun Nov 19 18:36:11 2023 +0800 Lcl: udpate lcl lpk and cocoa unit files --- I undid that commit: No need to do this. Clearly, the LCL package should not use any platform/wigetset specific units. I changed settings for newly added units, they should not be included in lcl.pas just like other ones in LCL interfaces. Also I added link to the package you added. Build works fine now. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Where is lazarus 3.0 RC2?
04.09.2023 19:16, Giuliano Colla via lazarus пишет: I'd like to test lazarus 3.0 RC2, but I'm unable to locate on github the proper branch/tag. Where is it? The tag has not been created yet. Branch is `fixes_3_0`. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LazGitGui a git tool.
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:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Compilation failed : PolygonNonZeroWindingRule unknown
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:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release Candidate 1 of 3.0
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:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release Candidate 1 of 3.0
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:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Call for translations updates for 3.0 release
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 \languages\README.md for details. Mark your reports with Lazarus version clearly in order to avoid confusion. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
01.07.2023 10:59, Sven Barth via lazarus пишет: Maxim Ganetsky via lazarus 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@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:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
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:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
30.06.2023 22:16, Giuliano Colla via lazarus пишет: 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. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
30.06.2023 17:25, Michael Van Canneyt via lazarus пишет: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: 30.06.2023 16:55, Michael Van Canneyt via lazarus пишет: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: 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. That was funny to read :-) I think the biggest issue in this regard is actually making releases to begin with. Yes indeed, but then in case of rare releases it is even more important to have right version numbering. :) Changing versioning is an easy and logical move in any case, why not do it? That was even more funny to read... Honestly: I'll settle for actually managing to get a release out. Yes indeed, this is most important. But I fail to see how these moves contradict each other. In any case, this is relevant only for the next major release (so next major version of FPC will be e.g. 4.0, not 3.4.0 ). And yes, this is minor issue/move, but still is IMO important (it is always wise to show to the general audience that the project is alive and kicking, which is indeed the case for FPC compiler too). But again, by any means, I do not insist on this. It is just a suggestion to consider. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
30.06.2023 16:55, Michael Van Canneyt via lazarus пишет: On Fri, 30 Jun 2023, Maxim Ganetsky via lazarus wrote: 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. That was funny to read :-) I think the biggest issue in this regard is actually making releases to begin with. Yes indeed, but then in case of rare releases it is even more important to have right version numbering. :) Changing versioning is an easy and logical move in any case, why not do it? -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
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@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. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus trunk version number
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@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. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dbg file on smb share hangs IDE
12.05.2023 14:55, Mattias Gaertner via lazarus пишет: Hi, When debugging a project on Windows with external debug info (.dbg) the IDE hangs. It works on the local C partition, but it hangs the IDE when the project is on a smb share. I have to kill lazarus.exe. Is this known? I guess it is better to create an issue. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cocoa maintainer and submitting patches
12.04.2023 21:57, Zoë Peterson via lazarus пишет: As we're winding up preparations for our upcoming release, we've been collecting all of our outstanding changes relative to Lazarus trunk and splitting them into patches. Outside some that are specific to us, we currently have about 130 distinct patches, half of which are for LCLCocoa, with the remainder being a mix of LCL core, LCLQt5, or components. Some of those would require significant effort to develop example apps and bug write-ups for, which would be hard to justify if they're unlikely to be merged. High quality patches, especially with good descriptions, will be merged indeed. Dmitry hasn't been actively maintaining the Cocoa widgetset for quite a while now, and my understanding is that he's stepped down. Alextp has Unfortunately, yes, due to lack of time. been pinging me on a issues that impact him, but I'm not currently a member of the Lazarus team. I think I can do good job of evaluating Probably, it is time to become a member? patches, but macOS has already taken up significantly more of my time than I can justify, and I've already had to reduce my Cocoa efforts here. David Jenkins is our primary macOS/Linux developer and did at one point have LCLCarbon commit access, but he's never been very active in that capacity. He doesn't want maintainership himself either, but we can have him help, especially if it helps get our patches merged. BTW, a good start will be reviewing Cocoa-related merge requests, for example: https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/117 https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/118 One concern I have with either of us is that an explicit design goal of our app is that it feel as macOS-native as possible, and that has involved considerable work to bypass the LCL in various ways. We don't use the LCL common dialogs, for example, so if those break, we're less likely to notice. We also don't use Lazarus on Windows, and David doesn't have any significant Win32 experience, so cross-widgetset functionality that we need on macOS/Linux could easily conflict with things that the LCL needs elsewhere. This can always be discussed with other developers, your concerns in this regard are not unique. Has there been any movement to replace Dmitry? Are there any other Currently we don't have any Cocoa developers in the team. Historically I merged Dmitry's work on Cocoa since migration to Git, but note that I cannot even test these changes because I don't have a Mac. developers who've expressed interest or even shown significant knowledge on the LCLCocoa innards? Only you and David. :) -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] make all compilation error after 319649fb (Attn: Martin)
10.01.2023 3:37, Wayne Sherman пишет: On Sun, Jan 8, 2023 Marcus Sackrow wrote: make all for at least x86_64-linux does not compile since 319649fb On Mon, Jan 9, 2023 Martin Frb wrote: There is "make" (aka "make all" ?) and "make bigide". If there is an automatic job for "make all", it apparently did not catch the build failure reported by Marcus. We have only `make bigide` ones, otherwise it would have failed indeed. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] make all compilation error after 319649fb (Attn: Martin)
09.01.2023 21:14, Mattias Gaertner via lazarus пишет: On Mon, 9 Jan 2023 18:01:19 +0100 Martin Frb via lazarus wrote: [...] There is "make" (aka "make all" ?) and "make bigide". Afaik "make useride" depends on what packages are configured, so that is not just a single setting? Yes. But if you start with an empty config directory "make useride" should be reliable and is a good test for lazbuild. It is no problem to add some `make useride` job. In principle, we can even switch e. g. x86_64-win64 job to this (to avoid crowding even more our already huge job list). What do you think? -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] make all compilation error after 319649fb (Attn: Martin)
09.01.2023 20:01, Martin Frb via lazarus пишет: On 09/01/2023 17:50, Marcus Sackrow via lazarus wrote: Hi, Am 08.01.23 um 23:11 schrieb Wayne Sherman: make all for at least x86_64-linux does not compile since 319649fb thanks it compiles again About a week ago Lazarus was failing to build with "make useride". Are these two build targets being run as part of the CI / CD tests? these compilations (from this error report) are on m own Jenkins server and atm it does only a "make all" it's mainly focused on catching problems with latest FPC (because it uses always the latest FPC, compiled some minutes before that) and to check if the compilation for Amiga-style systems still work (and with it the MUI widget set) in other jobs Of course if there is interest in more tasks, it can be added, the server still has some resources. It needs to be discussed with other devs as well, what they think... We do still have free minutes at GitLab. But the amount of combinations for testing is (near) infinite. Yes. There is "make" (aka "make all" ?) and "make bigide". Afaik "make useride" depends on what packages are configured, so that is not just a single setting? But each of them may fail only for a specific OS/Arch, or for some other specific setting. (like compile time range check error for constant eval, with -Cr enabled). We already have builds for win, gtk2, qt, iirc some with 32bit, and fpc 3.2.2 and trunk. (not all variations though). Yes, details are here: https://wiki.freepascal.org/Lazarus_Team_-_Git_Workflows#Continuous_integration_.28CI.29_System There are too much variations and I don't think that it is feasible to define them all. I think that current set of jobs in CI is quite comprehensible, but if there is justified need, yet another job can be added indeed. I personally currently don't have the time to look into it. (I'll ping the others, if anyone wants to pick up) If I should find time eventually, my interest will be much more in adding some of the tests we have to be run. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Attn. Don, documentation snapshots via CI
Hello. As a first step of solving outdated documentation snapshot issue (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40032 ) I propose to generate it as an artifact of CI job (in `main` branch for now), which then can be uploaded wherever we want. So I have the following questions: 1. FPDoc from which FPC version is preferred (from `main` branch I guess)? 2. Where rtl.xct and fcl.xct should be obtained? Should FPC documentation be built first? 3. Should we build HTML, CHM or both? 4. Are there any dependencies beyond Lazarus, FPC and their sources? -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Makefile issues
30.11.2022 16:35, Michael Van Canneyt via lazarus пишет: Hello, The lazarus makefile has some dependency issues. I would recommend to run `make lazbuild` first and then try to proceed again with your commands. make ide: make ide make -C ide ide make[1]: Entering directory '/home/michael/projects/lazarus-tst/ide' /bin/mkdir -p ../units/x86_64-linux/gtk2 make -C ../tools svn2revisioninc OS_TARGET=linux CPU_TARGET=x86_64 OPT='' make[2]: Entering directory '/home/michael/projects/lazarus-tst/tools' Makefile:2956: warning: overriding recipe for target '.' Makefile:2954: warning: ignoring old recipe for target '.' /usr/local/bin/ppcx64 -gl -Fu. -Fu../components/lazutils/lib/x86_64-linux -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/nogui -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FU. -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -dx86_64 svn2revisioninc.pas svn2revisioninc.pas(64,3) Fatal: Can't find unit FileUtil used by Svn2RevisionInc Fatal: Compilation aborted make[2]: *** [Makefile:2967: svn2revisioninc] Error 1 make[2]: Leaving directory '/home/michael/projects/lazarus-tst/tools' make[1]: *** [Makefile:5387: revisioninc] Error 2 make[1]: Leaving directory '/home/michael/projects/lazarus-tst/ide' make: *** [Makefile:3788: ide] Error 2 Based on the output of "make help", in an attempt to create svn2revisioninc I did: make tools make -C tools make[1]: Entering directory '/home/michael/projects/lazarus-tst/tools' Makefile:2956: warning: overriding recipe for target '.' Makefile:2954: warning: ignoring old recipe for target '.' make --assume-new=lazres.pp lazres make[2]: Entering directory '/home/michael/projects/lazarus-tst/tools' Makefile:2956: warning: overriding recipe for target '.' Makefile:2954: warning: ignoring old recipe for target '.' /usr/local/bin/ppcx64 -gl -Fu. -Fu../components/lazutils/lib/x86_64-linux -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/nogui -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FU. -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -dx86_64 lazres.pp lazres.pp(43,22) Fatal: Can't find unit LazLogger used by LazRes Fatal: Compilation aborted make[2]: *** [Makefile:2964: lazres] Error 1 make[2]: Leaving directory '/home/michael/projects/lazarus-tst/tools' make[1]: *** [Makefile:3394: all] Error 2 make[1]: Leaving directory '/home/michael/projects/lazarus-tst/tools' make: *** [Makefile:3784: tools] Error 2 Similar, make basecomponents make -C components/buildintf make[1]: Entering directory '/home/michael/projects/lazarus-tst/components/buildintf' /bin/rm -f units/x86_64-linux/buildintf.ppu /bin/mkdir -p units/x86_64-linux /usr/local/bin/ppcx64 -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq -Fu../../packager/units/x86_64-linux -Fu../lazutils/lib/x86_64-linux -Fu. -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FUunits/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -dx86_64 buildintf.pas Hint: (11030) Start of reading config file /home/michael/.fpc.cfg Hint: (11031) End of reading config file /home/michael/.fpc.cfg Free Pascal Compiler version 3.3.1 [2022/11/05] for x86_64 Copyright (c) 1993-2022 by Florian Klaempfl and others (1002) Target OS: Linux for x86-64 (3104) Compiling buildintf.pas (3104) Compiling baseideintf.pas /home/michael/projects/lazarus-tst/components/buildintf/baseideintf.pas(21,3) Fatal: (10022) Can't find unit LazUTF8 used by BaseIDEIntf fatal: (1018) Compilation aborted After some more failed attempts trying to compile "sub-targets", I gave up. Am I correct in my understanding that in fact only the "main" targets all, bigide, useride are supposed to work out of the box when you start from a fresh checkout ? Michael. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] More Gtk3 Status
19.07.2022 10:50, zeljko via lazarus пишет: On 18. 07. 2022. 17:53, Alexey Torgashin via lazarus wrote: Zeljko, currently gtk3 WS is not able to run my text editor app. Various visual bugs in the main form. I will be happy to pay you (initial author) 200$ if you fix the gtk3 for my editor (others will benefit too in theory). Sorry, but I don't have enough spare time to play with gtk3, but even if I fix it I don't need money for that work, better give it to lazarus project. Can you point to specific issues ? E. g. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39335 It even has a patch attached, which needs a review. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] gtk3, glib2 headers, gir2pascal
17.07.2022 15:09, Marco van de Voort via lazarus пишет: On 16-7-2022 21:27, Maxim Ganetsky via lazarus wrote: It is actually worse, it's Git->SVN. Although the patch set is not very big (and looks fine BTW), so it's doable. But IMO, this tool should just be incorporated into Lazarus sources. What do you (and others) think about this? Agree. Due to the usage for the interface headers it is kind of like a dependency of lazarus, so it shouldn't be in a repo for 3rd party components. This tool is now part of Lazarus source code tree in main branch and located in /tools/gir2pascal. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] gtk3, glib2 headers, gir2pascal
16.07.2022 16:42, Marco van de Voort via lazarus пишет: Who maintains the gtk3 headers and gir2pascal? Last week I tried to port a glib based library (Aravis), and I noticed that the interface/gtk3/gtk3defs headers were out of date, and didn't support Windows. So I sought to regenerate them, with a modified gir2pascal and also saw that some more recent patches (https://github.com/n1tehawk/gir2pascal) were not incorporated in lazarus-ccr yet. (I base myself on that version). Since local changes and github<>gitlab is complicated, it is probably the best to work with patches. Anybody interestd? It is actually worse, it's Git->SVN. Although the patch set is not very big (and looks fine BTW), so it's doable. But IMO, this tool should just be incorporated into Lazarus sources. What do you (and others) think about this? -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Gtk 1.2 fixes (again)
12.02.2022 20:25, Kostas Michalopoulos via lazarus пишет: Sending this mail again since it didn't arrive last time (can't even see it in the archives). This is actually my third attempt, using my gmail account now (i tried my own email - not sure if it didn't pass through because the other one wasn't subscribed or due to some configuration issue... the mailing list page mentions that i only need to be subscribed to receive messages, not to send them too so i assumed it'd work - in the former case, i wonder how many of my replies were ignored since i switched to my own domain's account). --- Hi all, I submitted some fixes for the Gtk 1.2 LCL backend here that should bring it in working state (as it is right now it doesn't build due to some procs being moved to other units and even after adding those it barely works, windows get moved to 0,0, changing desktops or shading windows is broken, opening various dialogs crashes the program and other nice stuff :-P). https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/69 In the meantime your fixes have been merged. But I still can't understand, why you put so much an effort into an ancient and obsolete widgetset. IMHO finishing fpGUI widgetset makes much more sense. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
03.11.2021 1:24, Bart via lazarus пишет: Untracked files: (use "git add ..." to include in what will be committed) components/lazutils/test/backup/ components/lazutils/test/testmasks.or I changed lazutils test projects to make their output to `units` subdirectory (it is already included in .gitignore) and also added `backup` subdirectories to .gitignore. Please test. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Release Candidate 2 of 2.2.0
02.11.2021 18:51, Kostas Michalopoulos via lazarus пишет: On 11/2/2021 2:54 PM, Mattias Gaertner via lazarus wrote: The Lazarus team is glad to announce the second release candidate of Lazarus 2.2. Neat. I did a bit of testing with some of my projects and everything that worked in the last stable version i had (2.0.6) seems to work fine with 2.2.0RC2. I also did some testing with the MDI functionality that was implemented in Win32 last year, which BTW... Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.2.2 ...isn't mentioned in the Lazarus changelog (the first non-trunk version to have it was 2.2.0RC1, at least from a quick look in the source code of 2.2.0RC1 and 2.0.12). The MDI stuff seem to work mostly fine, however there is an issue i noticed with paint and form resize events. I used this doodle app Please create a bug report. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Add entries to .gitignore
28.10.2021 20:31, Don Siders via lazarus пишет: I wanted to add the following entries to the .gitignore file for the Lazarus repo: /docs/html/*.log /docs/html/*.inc Can there be any subdirectories in /docs/html? /docs/html/*.xml Are you sure about XML ones? There are committed useful ones already. They're generated artifacts from building help. Can I add these? Or, should someone else do that? Yes, you can. .gitignore already contains entries for /docs/chm directory. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: the naming of ...
27.10.2021 18:50, Bart via lazarus пишет: Hi, I thought I better start a new therad for this one, otherwise I get lost in the previous "TMask revisited" thread. I would like to rename some stuff, now we still can. Easier to remeber IMO: WindowsQuirksAllAllowed -> AllWindowsQuirks WindowsQuirksDefaultAllowed -> DefaultWindowsQuirks MaskOpCodesAllAllowed -> AllMaskOpcodes MaskOpCodesDefaultAllowed -> DefaultMaskOpcodes property RangeAutoReverse -> AutoReverseRange Internal consistency: TMaskWindows -> TWindowsMask TMaskListWindows -> TWindowsMaskList (Because of the Matches* functions we already have) Consitent coding style: TMaskParsedCode enums: mpcXXX TMaskFailCause enums: mfcXXX Opinions please. Looks good to me. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
28.10.2021 0:33, Bart via lazarus пишет: On Wed, Oct 27, 2021 at 11:17 PM Juha Manninen via lazarus wrote: Attached the codetools popup for TMask.Create constructor. I would think it would be clear enough? It is clear for people who know the details already. For new users there is no hint of an extended syntax. Anyway, we can consider it as an advanced feature which requires users to study deeper. No problem. I'm OK with leaving them in, but in time they should be removed. CreateLegacy in version 3.6 is going to look a little bit "off". We want people staring to use the "new" syntax (that is: use the additional last parameter(s)) as fast as possible. Maybe deprecate them in 2.5 and remove in whatever we release after 2.4? I don't see the need in CreateLegacy/CreateExtended constructors as far as backward compatibility is maintained (it is the case as far as I understand). Just commit your Create constructors refactoring and document the changes (and update release notes). -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Masks: ConstructLegacy
28.10.2021 0:17, Juha Manninen via lazarus пишет: On Thu, Oct 28, 2021 at 12:02 AM Bart via lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: Attached the codetools popup for TMask.Create constructor. I would think it would be clear enough? Ok, if you say so. :) It is clear for people who know the details already. For new users there is no hint of an extended syntax. I like Bart's proposal. This syntax is extended only for now, in a year it will be perceived as pretty much standard, so such constructor division (Create/CreateExtended/CreateLegacy) will itself be considered a quirk. ;) Anyway, we can consider it as an advanced feature which requires users to study deeper. No problem. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
23.10.2021 13:22, Bart via lazarus пишет: On Sat, Oct 23, 2021 at 12:02 PM Bart wrote: since we are still looking for a better (?) name for the eMaskOpcodeOptionalChar enum: This brings me to another point, and please, please, please don't see this as criticism of feel offended by me. Naming conventions. Typically we don't have the habit of haveing the literal phrase "enum" in our enum typenames. We also tend to adopt that enum names are derived form the typename in a manner like typename: TSomeType enum name: stXXX Then we have TMaskOpcode and TMaskOpcodesEnum types. The first one is more or less an internal type. The latter one is for common user interface. Since TMaskOpCode is used in the interface part of TMask, we must have it in the interface part of the unit. If we rename TMaskOpCode to TInternalMaskOpCode and rename TMaskOpcodesEnum to TMaskOpcodesEnum to TMaskOpcode and TMaskOpcodesSet to TMaskOpcodes (we tend to do that with sets of enums: set typename = typename+s), then the opcode enum names can be changed to moAnyChar, moAnyCharOrNone etc. So: TInternalMaskOpcode (integers) TMaskOpcode (the enums) TMaskOpcodes: set of TMaskOpcode Enum names: moXXX This would be more in line with our unwritten style guide (at least this is how I percieve it). Also we have shorter, yet not less intuitive, enum names. The same for TWindowsQuirks: TWindowsQuirks: enums TWindowsQuirks: set of TWindowsQuirks Enum names: wqXXX Yes, those are intrusive changes, and they add no functionality, nor do they fix any bugs, but this is the time to consider such a change. The new and improved (yes, improved) TMask with all new types won't be used very much ATM. In a few weeks or months this might not be the case anymore. Opinions please! Makes sense. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
16.10.2021 15:13, Maxim Ganetsky via lazarus пишет: 16.10.2021 11:54, Juha Manninen via lazarus пишет: On Sat, Oct 16, 2021 at 11:20 AM Juha Manninen mailto:juha.mannine...@gmail.com>> wrote: Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with '*abc.pas.bak*'. Fixed in a111270ed0. Please test. No code changes were needed. I only disabled one of the Windows quirks, namely eWindowsQuirk_Extension3More. Please read the comments in code for details. Thanks, I'll test later and report. Works OK now. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
16.10.2021 16:11, Bart via lazarus пишет: On Sat, Oct 16, 2021 at 12:14 AM DougC via lazarus wrote: Shouldn't the mask "*.pas*" be used to match file.pas.bak ? If so, the old code and new code are ok. You miss the point. It was said that the mask '*.pas;*.pp;*.inc' now also matched the file foo.pas.bak, which would be a bug. So far, this has not been reporduced by others in this thread. Juha already reproduced it. Happens in `Find in Files` dialog. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
16.10.2021 13:00, Juha Manninen via lazarus пишет: P.S. Not related to the Mask code but I installed TortoiseGit on Windows. It works OK but still does not offer anything as good as *gitk*. The "Show log" view shows commits and their messages, and names of changed files but no diffs. Getting diffs requires extra mouse clicking for each file separately. You can right-click on the revision entry (in the log) itself, and there you will be able to open unified diff viewer. Also 'raw' diffs are not very convenient to me, I prefer to inspect them in a separate viewer (TortoiseGit has an excellent built-in one, and on Linux I use Meld). Then there is "Revision graph" which is actually a branch graph. Not very useful. Revision graph is located at the left of the log window. You mean it? It looks just like in any other tool? Earlier I have tried SmartGit but I didn't see any benefit using it either. "*git gui*", *gitk* + some git console commands work best for me. You didn't try to cherry-pick, TortoiseGit has the best interface for this in my experience. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
16.10.2021 11:54, Juha Manninen via lazarus пишет: On Sat, Oct 16, 2021 at 11:20 AM Juha Manninen mailto:juha.mannine...@gmail.com>> wrote: Yes, the TMaskWindows indeed behaves wrong. '**.pas*' matches with '*abc.pas.bak*'. Fixed in a111270ed0. Please test. No code changes were needed. I only disabled one of the Windows quirks, namely eWindowsQuirk_Extension3More. Please read the comments in code for details. Thanks, I'll test later and report. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
15.10.2021 02:07, Juha Manninen via lazarus пишет: On Thu, Oct 14, 2021 at 12:53 AM Maxim Ganetsky via lazarus mailto:lazarus@lists.lazarus-ide.org>> wrote: Don't know if it is related but just noticed that `Find in files` dialog now "ignores" file masks. E. g. I have the following file mask: `*.pas;*.pp;*.inc;*.lpr;*.lfm`, but it also finds (existing) entries in *.bak files, which is not really desired. I cannot reproduce that. No matches in *.bak files here. Please try with, for example bla.pas and bla.pas.bak files. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMask revisited
13.10.2021 18:16, Juha Manninen via lazarus пишет: I restored the great TMask implementation by José Mejuto in our development branch. I also fixed a few issues that hindered the transition last time. It was discussed at least in this mailing list with title "unit Masks vs. unit FPMasks" in 23 February this year. The logic in ShellCtrls unit is retained as it was. MaskList is used only when there are many ';' separated masks. I found a way to disable ranges in the new TMask code. The syntax differs a little from the old one though. If the old TMaskOptions syntax is needed, it can be added as a compatibility layer. Don't know if it is related but just noticed that `Find in files` dialog now "ignores" file masks. E. g. I have the following file mask: `*.pas;*.pp;*.inc;*.lpr;*.lfm`, but it also finds (existing) entries in *.bak files, which is not really desired. function TMaskList.MatchesWindowsMask() now works using a hack. It is deprecated for that reason. Tests to lazutils/test/testmasks.lpr were added for disabled ranges. Please test everybody. I will read the old posts more carefully later. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GTK3 Status?
11.09.2021 1:25, Michael Van Canneyt via lazarus пишет: On Fri, 10 Sep 2021, Anthony Walter via lazarus wrote: After a small bit of research, it looks like most of the information related to the LCL GTK3 can be found on this page. I am unsure how up to date the issues are as the README.txt file was last updated 8 years ago. https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/lcl/interfaces/gtk3 I think all info you can have currently is this file, Git log on gtk3 directory and open issues. The FPC/Lazarus foundation follows up on GTK3 development, Mattias Gaertner reports on it. My understanding is that GTK is being worked on, and it becomes more important to have a working version, since GTK2 is on it's way out in most distros. GTK3 is improved from time to time by Anton Kavalenka, but the progress is not very fast. This widgetset does not have a dedicated maintainer. Mattias is on a holiday, so we'll have to wait for his return for more detailed info. Michael. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] .mo files not working in multi language
23.07.2021 1:08, Bart via lazarus пишет: On Thu, Jul 22, 2021 at 11:02 PM Maxim Ganetsky via lazarus wrote: Put them to RES or LRS file, link this file to your program, then extract them at runtime to some directory and load it from there. Can't you use them from the resource like you can with po-files? From one of my units that does thi using old style .lrs resource: Yes, this should work the same way for MO files. In this case LCLTranslator unit will not help, functions from GetText should be called instead. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] .mo files not working in multi language
22.07.2021 15:41, Dietmar Braun via lazarus пишет: Hi, On 20.07.2021 23:36, Maxim Ganetsky via lazarus wrote: Make sure you are using at least Lazarus 2.2 RC1. Make sure you do not have PO and POT files in this subdirectory. one further question: Is it possible to add the .mo files as resources so that they are being hold in the exe file? How could I achieve this? Put them to RES or LRS file, link this file to your program, then extract them at runtime to some directory and load it from there. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] .mo files not working in multi language
21.07.2021 0:03, Dietmar Braun via lazarus пишет: Hi! sorry if I'm wrong here, but I posed my question in the Lazarus forum and was redirected here, so I am asking here again... After some years of pausing Lazarus development, I just started again with a small project and the problems I had years ago with MultiLanguage - these days, I managed to create a working multilanguage application, but when I try to distribute it, I run into problems. My directory structure looks like this: project (main folder): project1.exe !--languages (sub folder): project1.de.mo, project1.en.mo Make sure you are using at least Lazarus 2.2 RC1. Make sure you do not have PO and POT files in this subdirectory. With this setting, switching from the default (German) to English (en) does not work. It seems the .mo files are just being ignored. When I add the .PO files to the subfolder, it works. Can you advise? I just don't want to have to distribute the plain text .po files... Thx! Dietmar -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Call for translations updates for 2.2 release
Hello. Now that Lazarus 2.2 branch has been created it is time for translators to review and update their translations. Check out fixes branch (http://svn.freepascal.org/svn/lazarus/branches/fixes_2_2 ), review and update your translations and post updates to our bugtracker. See \languages\README.txt for details. Mark your reports with Lazarus version clearly in order to avoid confusion. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
09.10.2020 5:33, Martin Frb via lazarus пишет:
It might be dead simple (at least I hope)
{$IFDEF WINDOWS_LIGATURE}
function GetCharacterPlacementW(hdc: HDC; lpString: LPCWSTR; nCount,
nMaxExtend: Integer; var lpResults: GCP_RESULTSW; dwFlags: DWORD):
DWORD; stdcall; external 'gdi32' name 'GetCharacterPlacementW';
{$ENDIF}
Add stdcall.
At least on win10 that makes 32bit working. Not booting up win 7 again.
Yes, my IDE is 32 bit. It works now correctly for me on Win7 too. Thanks!
--
Best regards,
Maxim Ganetsky mailto:gan...@narod.ru
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
07.10.2020 14:23, Martin Frb via lazarus пишет:
On 07/10/2020 01:42, Maxim Ganetsky via lazarus wrote:
06.10.2020 16:23, Martin Frb via lazarus пишет:
On 06/10/2020 15:09, Maxim Ganetsky via lazarus wrote:
Can you try to catch it in the debugger, and see what params are given
to NewTextOut
in
#2 0x00ab95f6 in DRAWHILIGHTMARKUPTOKEN (ATOKENINFO=...,
parentfp=0x13abf6e8)
at lazsyntextarea.pp:1741
fTextDrawer.NewTextOut(TxtLeft, rcToken.Top, TxtFlags, tok,
ATokenInfo.Tk.TokenStart, ATokenInfo.Tk.TokenLength, FEtoBuf);
Can you add some debugln in a format convenient to you? This will
simplify things, I think.
This is in the paint handler, and it is called for each token. So
potentially very slow with debugln.
But since it is in startup, hopefully you wont have to many.
Apply this patch please
With this patch applied Lazarus seems to crash on debugln in
lazsyntextarea.pp. Just in case, I tried to remove this particular
debugln, then it printed 'BEFORE' and nothing more.
Sorry my fault, I thought I had all the nil checks
Please replace that debugln with
debugln('Calling NewTextOut L: %s rcT: %s tok: %s tkt: %s // %s // eto:
%s', [dbgs(TxtLeft), dbgs(rcToken), dbgs(tok),
dbgMemRange(PByte(ATokenInfo.Tk.TokenStart), ATokenInfo.Tk.TokenLength),
dbgs(ATokenInfo.Tk.TokenLength), dbgs(FEtoBuf<>nil) ]);
I got the following output:
i:\FPC\lazarus>lazarus
Hint: (lazarus) [TMainIDE.ParseCmdLineOptions]
PrimaryConfigPath="C:\Users\Maxim
\AppData\Local\lazarus"
Hint: (lazarus) [TMainIDE.ParseCmdLineOptions]
SecondaryConfigPath="i:\FPC\lazar
us"
Hint: (lazarus) [TMainIDE.LoadGlobalOptions]
Hint: (lazarus) LastCalled="I:\FPC\lazarus\lazarus.old.working.exe"
Hint: (lazarus) CurPrgName="i:\FPC\lazarus\lazarus.exe"
Hint: (lazarus)
AltPrgName="C:\Users\Maxim\AppData\Local\lazarus\bin\lazarus.exe
"
Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=i386-win32-win32
New=i386-win
32-win32 Changed: OS/CPU=True LCL=False
Calling NewTextOut L: 71 rcT: l=71,t=36,r=85,b=54 tok:
l=71,t=36,r=85,b=54 tkt:
2020 // 2 // eto: False
BEFORE
--
Best regards,
Maxim Ganetsky mailto:gan...@narod.ru
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
06.10.2020 16:23, Martin Frb via lazarus пишет: On 06/10/2020 15:09, Maxim Ganetsky via lazarus wrote: Can you try to catch it in the debugger, and see what params are given to NewTextOut in #2 0x00ab95f6 in DRAWHILIGHTMARKUPTOKEN (ATOKENINFO=..., parentfp=0x13abf6e8) at lazsyntextarea.pp:1741 fTextDrawer.NewTextOut(TxtLeft, rcToken.Top, TxtFlags, tok, ATokenInfo.Tk.TokenStart, ATokenInfo.Tk.TokenLength, FEtoBuf); Can you add some debugln in a format convenient to you? This will simplify things, I think. This is in the paint handler, and it is called for each token. So potentially very slow with debugln. But since it is in startup, hopefully you wont have to many. Apply this patch please With this patch applied Lazarus seems to crash on debugln in lazsyntextarea.pp. Just in case, I tried to remove this particular debugln, then it printed 'BEFORE' and nothing more. i:\FPC\lazarus>lazarus --debug-output=.\dbgoutput.txt Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] PrimaryConfigPath="C:\Users\Maxim \AppData\Local\lazarus" Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] SecondaryConfigPath="i:\FPC\lazar us" Hint: (lazarus) [TMainIDE.LoadGlobalOptions] Hint: (lazarus) LastCalled="I:\FPC\lazarus\lazarus.old.working.exe" Hint: (lazarus) CurPrgName="i:\FPC\lazarus\lazarus.exe" Hint: (lazarus) AltPrgName="C:\Users\Maxim\AppData\Local\lazarus\bin\lazarus.exe " Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=i386-win32-win32 New=i386-win 32-win32 Changed: OS/CPU=True LCL=False TApplication.HandleException: EAccessViolation Access violation Stack trace: $00C12B2D DRAWHILIGHTMARKUPTOKEN, line 1740 of lazsyntextarea.pp $00C11C76 PAINTLINES, line 1799 of lazsyntextarea.pp $00C11847 PAINTTEXTLINES, line 1871 of lazsyntextarea.pp $00C113D8 DOPAINT, line 1489 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00C0FDD2 DOPAINT, line 1134 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00D9A022 DOPAINT, line 1353 of sourcesyneditor.pas $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $0079ECCB PAINT, line 4221 of synedit.pp $005B3471 PAINTWINDOW, line 123 of include/customcontrol.inc $0059BB7B PAINTHANDLER, line 4857 of include/wincontrol.inc $005A00A4 WMPAINT, line 6851 of include/wincontrol.inc $005B3330 WMPAINT, line 103 of include/customcontrol.inc $004103A1 $0059D0A7 WNDPROC, line 5429 of include/wincontrol.inc $007A6B0F WNDPROC, line 6399 of synedit.pp FreeFormEditor: FormEditor1=TFormEditor Hint: (lazarus) [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE Hint: (lazarus) [TMainIDE.Destroy] END Heap dump by heaptrc unit of i:\FPC\lazarus\lazarus.exe 6222427 memory blocks allocated : 556846869/572547168 6211889 memory blocks freed : 555436555/571105040 10538 unfreed memory blocks : 1410314 True heap size : 28114944 (128 used in System startup) True free heap : 25543392 Should be : 25661040 Call trace for block $1CEE6DD0 size 64 $00418EBF $770034A1 $77003473 $76FB0133 $00C11C76 PAINTLINES, line 1799 of lazsyntextarea.pp $00C11847 PAINTTEXTLINES, line 1871 of lazsyntextarea.pp $00C113D8 DOPAINT, line 1489 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00C0FDD2 DOPAINT, line 1134 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00D9A022 DOPAINT, line 1353 of sourcesyneditor.pas $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $0079ECCB PAINT, line 4221 of synedit.pp $005B3471 PAINTWINDOW, line 123 of include/customcontrol.inc $0059BB7B PAINTHANDLER, line 4857 of include/wincontrol.inc $005A00A4 WMPAINT, line 6851 of include/wincontrol.inc Call trace for block $1C6FECD0 size 92 -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
06.10.2020 13:32, Martin Frb via lazarus пишет: > On 06/10/2020 01:01, Maxim Ganetsky via lazarus wrote: >> 05.10.2020 18:36, Martin Frb via lazarus пишет: >>> On 05/10/2020 00:27, Maxim Ganetsky via lazarus wrote: >>>> Lazarus hangs on start for me on Windows 7 when compiled with this >>>> define. >>>> >>>> Lazarus 2.1.0 r63957 FPC 3.2.0 i386-win32-win32/win64. I use >>>> JetBrains Mono font. >>>> >>> >>> The other ...TextOut in the lines below that should be kept as they are. >> >> This change does not help. > > Ok, I installed Win7 in a virtualbox, got Lazarus, installed the > "JetBrains mono" font (just the regular, skipped all the > light/italics) and "JetBrains mono Variable". > > No crash. > Ligatures work (well the subset as described in other mail) > > Without any way of reproducing, there isn't much I can do. > > > Can you try to catch it in the debugger, and see what params are given > to NewTextOut > in > #2 0x00ab95f6 in DRAWHILIGHTMARKUPTOKEN (ATOKENINFO=..., > parentfp=0x13abf6e8) > at lazsyntextarea.pp:1741 > > fTextDrawer.NewTextOut(TxtLeft, rcToken.Top, TxtFlags, tok, > ATokenInfo.Tk.TokenStart, ATokenInfo.Tk.TokenLength, FEtoBuf); Can you add some debugln in a format convenient to you? This will simplify things, I think. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
05.10.2020 18:36, Martin Frb via lazarus пишет: On 05/10/2020 00:27, Maxim Ganetsky via lazarus wrote: Lazarus hangs on start for me on Windows 7 when compiled with this define. Lazarus 2.1.0 r63957 FPC 3.2.0 i386-win32-win32/win64. I use JetBrains Mono font. I installed the font myself. And it works on windows 10 and that works. However I found one possible issue. Please go to SynTextDrawer.pp line 1269 and replace the current Windows.ExtTextOutW(FDC, X, Y, fuOptions or ETO_GLYPH_INDEX, @ARect, Pointer(Glyphs), Length(Glyphs), EtoArray); with the following new Windows.ExtTextOutW(FDC, X, Y, fuOptions or ETO_GLYPH_INDEX, @ARect, Pointer(Glyphs), CharPlaceInfo.nGlyphs, EtoArray); The other ...TextOut in the lines below that should be kept as they are. This change does not help. I also tried your suggestion to make function TheFontStock.GetNeedETO to always return false. This did not make any difference too. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
05.10.2020 1:48, Martin Frb via lazarus пишет: On 05/10/2020 00:27, Maxim Ganetsky via lazarus wrote: 04.10.2020 19:05, Martin Frb via lazarus пишет: On 04/10/2020 10:14, Mr Bee wrote: If it does work, would you please submit it as a patch for the next release? At least, add a note that the font ligatures feature only supports monospaced fonts and only works on Windows. It's better than nothing. revision 63951 Windows only, compile with -dWINDOWS_LIGATURE Tested with Cascadia. Lazarus hangs on start for me on Windows 7 when compiled with this define. Lazarus 2.1.0 r63957 FPC 3.2.0 i386-win32-win32/win64. I use JetBrains Mono font. Could you start with an empty project? To make sure its not content related? Though the code changes do not have any loop. You could run in gdb gdb lazarus.exe r ctrl-c when it hangs bt Tried with an empty project, nothing changed. Actually it does not hang, it segfaults. GDB output: i:\FPC\lazarus>i:\FPC\lazarus_gdb_w32\bin\gdb.exe lazarus.old.exe GNU gdb (GDB) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from lazarus.old.exe...done. (gdb) r Starting program: i:\FPC\lazarus\lazarus.old.exe [New Thread 6324.0x994] [New Thread 6324.0x1834] [Thread 6324.0x1834 exited with code 0] [New Thread 6324.0x1c78] Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0024 in ?? () #2 0x00ab95f6 in DRAWHILIGHTMARKUPTOKEN (ATOKENINFO=..., parentfp=0x13abf6e8) at lazsyntextarea.pp:1741 #3 0x00ab8a8e in PAINTLINES (parentfp=0x13abf6e8) at lazsyntextarea.pp:1798 #4 0x00ab86f3 in TLAZSYNTEXTAREA__PAINTTEXTLINES (ACLIP=..., FIRSTLINE=0, LASTLINE=27, FIRSTCOL=1, LASTCOL=154, this=) at lazsyntextarea.pp:1870 #5 0x00ab831c in TLAZSYNTEXTAREA__DOPAINT (ACANVAS=0x1a798798, ACLIP=..., this=) at lazsyntextarea.pp:1489 #6 0x00ab00d0 in TLAZSYNSURFACE__PAINT (ACANVAS=0x1a798798, ACLIP=..., this=) at syneditmiscclasses.pp:1308 #7 0x00ab6f82 in TLAZSYNSURFACEMANAGER__DOPAINT (ACANVAS=0x1a798798, ACLIP=..., this=) at lazsyntextarea.pp:1134 #8 0x00ab00d0 in TLAZSYNSURFACE__PAINT (ACANVAS=0x1a798798, ACLIP=..., this=) at syneditmiscclasses.pp:1308 #9 0x00c1c402 in TSOURCELAZSYNSURFACEMANAGER__DOPAINT (ACANVAS=0x1a798798, ACLIP=..., this=) at sourcesyneditor.pas:1353 #10 0x00ab00d0 in TLAZSYNSURFACE__PAINT (ACANVAS=0x1a798798, ACLIP=..., this=) at syneditmiscclasses.pp:1308 #11 0x0070603f in TCUSTOMSYNEDIT__PAINT (this=) at synedit.pp:4221 #12 0x0057270d in TCUSTOMCONTROL__PAINTWINDOW (DC=469832019, this=) at ./include/customcontrol.inc:123 ---Type to continue, or q to quit--- #13 0x0055ffa7 in TWINCONTROL__PAINTHANDLER (THEMESSAGE=..., this=) at ./include/wincontrol.inc:4857 #14 0x00563427 in TWINCONTROL__WMPAINT (MSG=..., this=) at ./include/wincontrol.inc:6850 #15 0x00572630 in TCUSTOMCONTROL__WMPAINT (MESSAGE=..., this=) at ./include/customcontrol.inc:103 #16 0x00410221 in SYSTEM$_$TOBJECT_$__$$_DISPATCH$formal () #17 0x0001 in ?? () #18 0x0120f754 in VMT_$CONTROLS_$$_TCUSTOMCONTROL () #19 0x0120f2b8 in VMT_$CONTROLS_$$_TGRAPHICCONTROL$indirect () #20 0x005725f0 in TCUSTOMCONTROL__WSREGISTERCLASS (pvmt=0x13abfbf4) at ./include/customcontrol.inc:90 #21 0x0056100b in TWINCONTROL__WNDPROC (MESSAGE=..., this=) at ./include/wincontrol.inc:5429 #22 0x0070d54f in TCUSTOMSYNEDIT__WNDPROC (MSG=..., this=) at synedit.pp:6399 #23 0x0061ff2a in DELIVERMESSAGE (TARGET=0x1bdaf3a0, AMESSAGE=pointer.> ) at lclmessageglue.pas:112 #24 0x0054410f in TWINDOWPROCHELPER__SENDPAINTMESSAGE (CONTROLDC=0, this=...) at ./win32/win32callback.inc:746 #25 0x00547922 in TWINDOWPROCHELPER__DOWINDOWPROC (this=...) at ./win32/win32callback.inc:2357 #26 0x005487a1 in WINDOWPROC (WINDOW=1312066, MSG=15, WPARAM=0, LPARAM=0) ---Type to continue, or q to quit--- at ./win32/win32callback.inc:2774 #27 0x76f1630a in gapfnScSendMessage () from C:\Windows\syswow64\user32.dll #28 0x00140542 in ?? () #29 0x76f17326 in USER32!GetDC () from C:\Windows\syswow64\user32.dll #30 0x00548750 in TWINDOWPROCHELPER__DOWINDOWPROC ( this=) at ./win32/win32callback.inc:2745 #31 0x76f16df8 in USER32!GetThreadDesktop ()
Re: [Lazarus] -dWINDOWS_LIGATURE [[Re: Font ligatures support]]
04.10.2020 19:05, Martin Frb via lazarus пишет: On 04/10/2020 10:14, Mr Bee wrote: If it does work, would you please submit it as a patch for the next release? At least, add a note that the font ligatures feature only supports monospaced fonts and only works on Windows. It's better than nothing. revision 63951 Windows only, compile with -dWINDOWS_LIGATURE Tested with Cascadia. Lazarus hangs on start for me on Windows 7 when compiled with this define. Lazarus 2.1.0 r63957 FPC 3.2.0 i386-win32-win32/win64. I use JetBrains Mono font. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6
16.10.2019 19:15, Werner Pamler via lazarus пишет: > Am 16.10.2019 um 16:52 schrieb Juha Manninen via lazarus: >> On Wed, Oct 16, 2019 at 4:41 PM Werner Pamler via lazarus >> wrote: >>> I don't know what you are referring to, here. In r61814 I had added the >>> "System" namespace here in VTV because fpc 3.2+ has a Move method in >>> TCollection which conflicts with the old code. >> r61814 in fixes branch seems to a merge from Michael's r60784 in trunk. >> Your big rename commit r60132 in trunk would be useful, too, but I >> guess difficult to merge. > > > Hmmh - I never thought about this, I always thought this is a "new > feature" and should stay in trunk. ATM, I cannot focus on merging VTV to > fixes. It isn't a show-stopper, isn't it? This should NOT be merged, because it introduced dotted unit names into the wild and required major changes to translation system. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multi-line msgid in PO file
06.02.2019 15:42, Henry Vermaak via lazarus пишет: > On Wed, Feb 06, 2019 at 03:58:37AM +0300, Maxim Ganetsky via lazarus wrote: >> 01.02.2019 19:38, Henry Vermaak пишет: >>> On Fri, 1 Feb 2019 at 12:46, Maxim Ganetsky via lazarus >>> wrote: >>>> As I remember, it was not the case earlier at least with Poedit. But its >>>> current version behaves exactly as you describe. Maybe it is indeed a >>>> good idea to avoid changing these newlines. I will look into it. >>> >>> Thanks, much appreciated. >> >> Fixed in r60343. Please test. > > We've merged them onto fixes_2_0 and everything works well now, thanks! Great. > It's a pity we've missed the release, can you merge this onto fixes_2_0? I don't think that this is a good idea at this point of time, the change is too noisy/invasive. Technically this was not a regression, but rather a (mis)feature. > Do you still have to strip trailing newlines from translated strings for > lazarus PO files? All such translations will be marked as fuzzy on their regeneration. All affected Lazarus PO files have already been regenerated. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multi-line msgid in PO file
01.02.2019 19:38, Henry Vermaak пишет: On Fri, 1 Feb 2019 at 12:46, Maxim Ganetsky via lazarus wrote: As I remember, it was not the case earlier at least with Poedit. But its current version behaves exactly as you describe. Maybe it is indeed a good idea to avoid changing these newlines. I will look into it. Thanks, much appreciated. Fixed in r60343. Please test. Note that there can be spurious changes of PO files on first IDE rebuild. You can safely revert them. Also do not forget to rebuild updatepofiles tool if you use it. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multi-line msgid in PO file
01.02.2019 12:43, Henry Vermaak пишет: > On Thu, 31 Jan 2019 at 23:38, Maxim Ganetsky via lazarus > wrote: >> Should be fixed in r60268. > > No, lazarus still adds an extra newline to the end of the msgid > entries in the PO files. This is incorrect, the original text does > not include a trailing newline (check the lrj file). rstconv also > doesn't write spurious newlines to PO files when I feed the lrj to it. > >> Linebreak at the end of multilined string should be present as per PO >> format examples, most PO editors add it anyway. > No, this is incorrect. PO editors have nothing to do with what gets > added to msgid, but they will preserve the newlines that are in the > msgid and make sure that the translation ends in a newline if the > original ends in a newline. xgettext is responsible for extracting > strings from source and it does not add an extra newline when used > with C or lua source, we've been using multiline strings in C and lua > for years without issues. As I remember, it was not the case earlier at least with Poedit. But its current version behaves exactly as you describe. Maybe it is indeed a good idea to avoid changing these newlines. I will look into it. > Could you explain what was wrong with the patch I sent in the first message? It needlessly changes formatting of PO files and is not sufficient to correctly solve the problem at hand anyway. But changes along its lines should be made, yes. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multi-line msgid in PO file
31.01.2019 14:01, Henry Vermaak via lazarus пишет: On Wed, Jan 30, 2019 at 08:19:47PM +0300, Maxim Ganetsky via lazarus wrote: 30.01.2019 20:10, Henry Vermaak via lazarus пишет: I've had a problem with multi-line translations not working and realised that an extra '\n' was appended to the last line of the msgid in the PO file causing the translation lookup to fail. I'm assuming that this is a bug, but thought I'd ask here first. Should be fixed in r60268. Note that multiline strings seem to be always stored with Unix-style linebreaks in MO file, while in form they can have e.g. Windows-style or maybe even Mac-style linebreaks. Because of this, these strings should be normalized with regards to linebreaks before searching in MO file. Linebreak at the end of multilined string should be present as per PO format examples, most PO editors add it anyway. Also note, that loading multiline resourcestrings from MO files probably won't work in many cases for aforementioned reasons too, because Gettext unit does not account for platform-specific lineending changes at all. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multi-line msgid in PO file
30.01.2019 20:10, Henry Vermaak via lazarus пишет: > I've had a problem with multi-line translations not working and realised > that an extra '\n' was appended to the last line of the msgid in the PO > file causing the translation lookup to fail. I'm assuming that this is > a bug, but thought I'd ask here first. Multiline translations are used in Lazarus and seem to work? Please send a test project. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Translation templates (master files) now have .pot extension
Hello. In r60208 I changed extension of master PO files (a.k.a. templates) from .po to .pot, adapted IDE, POChecker, updatepofiles tool and localize.bat/.sh scripts. Reasons: 1. .pot is 'industry standard' extension for PO template files. As a consequence, PO editors can now open our templates 'out of the box' and automate creation of translations. 2. It is now much simpler to detect template files now that dotted unit names are allowed. Example for IDE translation: Previously we had: Template:lazaruside.po German: lazaruside.de.po Russian: lazaruside.ru.po Spanish: lazaruside.es.po French: lazaruside.fr.po Italian: lazaruside.it.po Now we have (note extension of the template): Template:lazaruside.pot German: lazaruside.de.po Russian: lazaruside.ru.po Spanish: lazaruside.es.po French: lazaruside.fr.po Italian: lazaruside.it.po You can safely remove .po template files from your project AFTER you rebuild your IDE and rebuild your project with it (at this point .pot files should be generated). Note that although .po template files have been removed from Lazarus SVN, they may reappear during first IDE rebuild (with the old one). In this case it may be a good idea to clean them up after rebuild. If you use updatepofiles tool or localize.bat/.sh scripts in Lazarus directory, do not forget to rebuild updatepofiles (run "make tools" in Lazarus directory). -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Can't compile Lazarus on Raspberry Pi3 using fpc 3.3.1 and Larzarus r>57100
02.11.2018 0:42, Valdas Jankūnas via Lazarus пишет: gtk2proc.inc(4631,15) Fatal: Internal error 200108231 This line indicates FPC bug. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Package -> New Component ...
26.09.2018 21:08, Juha Manninen via Lazarus пишет: I try to hurry this up because a new book about Lazarus will have a chapter about this New Component feature and the old dialog was badly outdated. The HighDPI support with multi-resolution icons is a major new feature in Lazarus / LCL after all. Hurrying and rushing features at the last moment is never good. Chances are the dialog will have regressions and it may turn out that further significant rework will be needed. I would like to push this improvement to the 2.0 branch although it touches the IDE's resource strings and thus breaks the basic rule of letting translators do their job in peace after a release branch is forked. What do you think? Changes are quite minimal, so I don't see any major problem from this side. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Call for translations updates for 2.0 release
Hello. Now that Lazarus 2.0 branch has been created it is time for translators to review and update their translations. Check out fixes branch (http://svn.freepascal.org/svn/lazarus/branches/fixes_2_0 ), review and update your translations and post updates to our bugtracker. See \languages\README.txt for details. Mark your reports with Lazarus version clearly in order to avoid confusion. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LCLProc.KeyAndShiftStateToKeyString needs param
14.08.2018 10:58, AlexeyT via Lazarus пишет: > function KeyAndShiftStateToKeyString(Key: word; ShiftState: > TShiftState): String; > > Maxim, can you add here param Localized too? it can be 3rd param with > default "true". AFAIR this function is exposed in LCLProc interface. As it seems to be localized from the start, I don't want to change its parameter list without obvious need. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Unix Select Printer dlg: tab-order fix
27.07.2018 13:29, Juha Manninen via Lazarus пишет: > On Thu, Jul 26, 2018 at 12:52 PM AlexeyT via Lazarus > wrote: >> this fixes weird tab-order. > > I applied this one in r58640. Thanks. > I leave the i18n patch for Maxim. The patch looks good, please apply it too. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multilang application and syncing .po files
20.06.2018 16:30, Tomáš Emresz via Lazarus пишет: > Hello, > > I have checked project inspector, and add some files to it. This time, > all is good, both files are updated as needs. Good. > Other question is : is there any possibility to describe RS for > PoEdit, like if it is caption on some components ? Something like this > : > > resourcestring > //Text when type of addres is Button > rsButton = 'Button'; > //Text in list of types > rsListButton = 'Button'; No, but you can use meaningful string identifier names, Poedit shows them. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multilang application and syncing .po files
19.06.2018 21:07, Tomáš Emresz via Lazarus пишет: Hello, úterý 19. června 2018, 16:14:01, napsal jste: 19.06.2018 16:26, Tomáš Emresz via Lazarus пишет: Hello, i was searching for, changing something and I don't understand. When I add force update po on next compile, change showed only in .cs.po (main .po was not changed). Therefore only .cs.po was outdated. Please, what do you exactly mean by this ? (in xxx.po there is no this RS. This new RS was added only to xxx.cs.po but xxx.po was not changed and is missing this RS) This is plain impossible. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multilang application and syncing .po files
19.06.2018 16:26, Tomáš Emresz via Lazarus пишет: > Hello, > > i was searching for, changing something and I don't understand. When I > add force update po on next compile, change showed only in .cs.po > (main .po was not changed). Therefore only .cs.po was outdated. > When I add some resoucestrings to unit > (not form), this RS is not somewhere (I also tried force update .po). Is this unit part of project? Please check in Project Inspector. > Antivir is disabled. > > tool updatepofiles (in other directory for test) did nothing (and > needs admin access (drive D, user could write in this directory). -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multilang application and syncing .po files
19.06.2018 14:55, Tomáš Emresz via Lazarus пишет:
> Hello,
>
> lazarus 1.8.5 (fixes)
> Date : 2018-06-14
> FPC: 3.0.5
> SVN: 58067
> i386-win32-win32/win63
>
> Running on Windows 10 CZ Pro.
>
> In some unit a have added LCLTranslator, setup i18n in project config
> with right path, so components and resouceestrings
> showed in po. When I add new, there is in main xxx.po file.
>
> Lang I switching with :
> SetDefaultLang('','langs\');
> in lpr on first line after begin.
>
> Should I say Lazarus, that there is also xxx.cs.po (next will be
> xxx.de.po etc) files or it should detect it in this directory ?
No, Lazarus will find all of them automatically.
Note that Lazarus will update translations only when main .po file is
changed (i.e. you made changes to resource strings in code). So in case
you place to your directory outdated translation when your main .po file
is already up to date, you should use updatepofiles tool, which will
update it.
--
Best regards,
Maxim Ganetsky mailto:gan...@narod.ru
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multilang application and syncing .po files
19.06.2018 14:37, Carlos E. R. via Lazarus пишет: > On 2018-06-19 13:09, Tomáš Emresz via Lazarus wrote: >> Hello, >> >> i have done generating .po files, could translate it through PoEdit, >> but - when i add some RS or component, Lazarus update only main .po >> file, not .cs.po etc. So could Lazarus update these files too, or is >> there any merge tool for this ? Of course, I understand, that I must >> translate this string after, but this time, I sync this files >> manually, which is bad. >> >> Any idea ? > > I'll answer as translator, I do not yet know how Lazarus handles this. > > The programmer should only change the .pot files. Lazarus handles all this itself. Main .po file is actually is what you mean by .pot (historically it has .po extension instead of .pot). -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Multilang application and syncing .po files
19.06.2018 14:09, Tomáš Emresz via Lazarus пишет: > Hello, > > i have done generating .po files, could translate it through PoEdit, > but - when i add some RS or component, Lazarus update only main .po > file, not .cs.po etc. So could Lazarus update these files too, or is > there any merge tool for this ? Of course, I understand, that I must > translate this string after, but this time, I sync this files > manually, which is bad. > > Any idea ? Which Lazarus version, OS? Lazarus does update translations together with main .po file. Make sure that your antivirus does not block writing to them (look at dates/times of translation files, if e.g. the half of them have the same date/time after update and the others not, this is antivirus). Note that you can sync translations with main .po file manually using \tools\updatepofiles tool: updatepofiles mainpofile.po -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Changes to bugreport #33331 completely changes long standing behaviour
03.04.2018 11:52, Torsten Bonde Christiansen via Lazarus пишет: > Dear List. > > The bug report: https://bugs.freepascal.org/view.php?id=1 > > has completely changed the behavious of how TTreeview behave! > > The old behaviour (sending OLD current node in OnChanging, sending > NEW/SELECTED node in OnChange) is consistent across other components as > well. > > The bug report is closed so i cannot make an objection to this "fix". > > It has created a heck loads of bug in our programs due to this change - > can this please be reverted?!? I reopened this bug report. Please comment there. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Sharing translations between Lazarus and Delphi versions of the same project
26.01.2018 14:24, Werner Pamler via Lazarus пишет: > Am 26.01.2018 um 12:05 schrieb Werner Pamler via Lazarus: >> Wouldn't it be better to have a menu command "Clean po file" which >> just rebuilds the rsj and po files? > > Ah - there's a checkbox "Force update po files after next compile" for > this purpose. But this is not working. It requires a Run > Build instead > of Run > Compile. I suggest it is renamed to "Force update po files > after next build" Done, thanks for the hint. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Sharing translations between Lazarus and Delphi versions of the same project
26.01.2018 14:05, Werner Pamler via Lazarus пишет: > > Am 26.01.2018 um 11:33 schrieb Maxim Ganetsky via Lazarus: >> 26.01.2018 12:54, Werner Pamler via Lazarus пишет: >> Maybe you can use adapted copies of translations.pas unit (from >> LazUtils) and lcltranslator.pas unit (from LCL). They will need to be >> ported for Delphi, though. > > Hmm... A lot of work for just a demo. No other way? Can't gnugettext be > configured to use the Lazarus structure? Don't know, TBH. >>> BTW: Working with the i18n options again I noticed that there are now >>> two boxes "Excluded" > "Identifiers", "Originals" in the i18n project >>> options. What can be put in there? Which effect does it have? Does it >>> solve the issue that the same strings enter the po files again and >>> again? >> PO file consists of entries. Each entry consists of (at least) >> identifier name, original string value and translated string value. By >> default IDE collects all captions from components on form. If you use >> resource strings for translation at the same time you may want in some >> cases to filter some strings. >> >> For example, you have a form with caption 'Form1' and with some labels >> in it. Then you translate this caption via resource string and all >> labels by IDE means. In this case you will have in PO file 'Form1' entry >> and entry for resource string which effectively replaces it. Obviously >> you don't want to burden translators with 'Form1' entry. That is where >> the filters are useful. > > Thanks for the explanation. It motivated me to play with these two > boxes: If I don't want to have the auto-generated entry 'Form1' to be > in the po file I must enter this string in the box "Originals". > Alternatively I can use the identifier of the caption in the box > "identifiers" - it must be entered in the po syntax: "tform1.caption", > or "tform1.button1.caption" for a button named TButton. What was > confusing me is that the ignored entries remain in the master po and > translated po files after these modifications. Only after "Clean up and > Build" they do disappear. This, however, takes a long time because all > required units are recompiled. Wouldn't it be better to have a menu > command "Clean po file" which just rebuilds the rsj and po files? You have for this: 1. 'Project Options' -> 'i18n' -> 'Force PO files update on next compilation' check box at the bottom of the page. 2. 'Project' -> 'Resave forms with enabled i18n' in main Lazarus menu to regenerate all .lrj files in project. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Sharing translations between Lazarus and Delphi versions of the same project
26.01.2018 12:54, Werner Pamler via Lazarus пишет: > Currently I am porting the component TMoon to Lazarus > (https://github.com/Ahoerstemeier/delphimoon). A goal is to be able to > compile package and demo with Lazarus AND Delphi. The original demo is a > multi-language application which achieves translation using resource > strings in a (I guess) Delphi1-like, windows-specific way. Using the > Lazarus system of po files really is very easy and much more versatile > compared to that. > > But now I am faced with the problem how to bring this back into the > Delphi version. I know that the Lazarus translation system is based on > gnugettext. I can add the unit gnugettext to the Delphi project. But how > to continue? The original gnugettext requires the language to be > specified as the name of a subfolder between "locale" and "LC_MESSAGES" > (e.g., "locale/de/LC_MESSAGES/default.mo" for German), but Lazarus puts > the language code into the po/mo file name (e.g., "project.de.po"). And > I also don't get the point how to switch languages at runtime. Maybe you can use adapted copies of translations.pas unit (from LazUtils) and lcltranslator.pas unit (from LCL). They will need to be ported for Delphi, though. > Does anybody have experience with a similar project? I mean: how to use > the po files for both Lazarus and Delphi. > > BTW: Working with the i18n options again I noticed that there are now > two boxes "Excluded" > "Identifiers", "Originals" in the i18n project > options. What can be put in there? Which effect does it have? Does it > solve the issue that the same strings enter the po files again and again? PO file consists of entries. Each entry consists of (at least) identifier name, original string value and translated string value. By default IDE collects all captions from components on form. If you use resource strings for translation at the same time you may want in some cases to filter some strings. For example, you have a form with caption 'Form1' and with some labels in it. Then you translate this caption via resource string and all labels by IDE means. In this case you will have in PO file 'Form1' entry and entry for resource string which effectively replaces it. Obviously you don't want to burden translators with 'Form1' entry. That is where the filters are useful. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Translation becomes "fuzzy". Why?
14.07.2017 12:06, Valdas Jankūnas via Lazarus пишет: > Hello, > > In file "languages/lazaruside.lt.po" resides string: > > #: lazarusidestrconsts.lischangedscoordofsfromdtodinsides > msgid "Changed %s coord of %s from \"%d\" to \"%d\" inside %s." > > I translate it to: > > msgstr "„%4:s“ viduje „%1:s“ koordinatė „%0:s“ pakeista iš „%2:d“ į > „%3:d“." > > After revision update this translation is always marked as > "fuzzy,badformat". Why? Is rearrangement of arguments prohibited, or I > don't see where I made a mistake? IIRC currently formatting arguments in translation should match original string, otherwise formatting is considered incorrect. It is not very flexible, but it is simple and allows to avoid subtle errors in translations. Probably this check can be relaxed/made more elaborate, but I don't think it is worth potential risks and complications. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Call for translations updates for 1.8 release
Hello. Now that Lazarus 1.8 branch has been created it is time for translators to review and update their translations. Check out fixes branch (http://svn.freepascal.org/svn/lazarus/branches/fixes_1_8 ), review and update your translations and post updates to our bugtracker. See \languages\README.txt for details. Mark your reports with Lazarus version clearly in order to avoid confusion. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Can't add new form to Lazarus App
29.09.2016 22:26, Terry A. Haimann via Lazarus пишет: I created the form by clicking on NewForm and then I tried to rename it from the Object Inspector. I am running Lazarus 1.2.4 This app has Lazarus 1.2.4? Is it a joke? probably been used by several versions of Lazarus. -- Best regards, Maxim Ganetsky mailto:gan...@narod.ru -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
