Re: [Lazarus] unit Masks vs. unit FPMasks
On Tue, Feb 23, 2021 at 12:00 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Since it comes from Lazarus in the first place, they are supposed to be > compatible, yes. If not, then the unit in FPC can be updated to add missing > things. > Oops, now I understand that FPMasks does not really support Unicode. Type UTF8String only converts encoding automatically when assigning values. There is no code to identify codepoints. The LazUtils Masks iterates codepoints, although in a very slow way. Has anybody tested FPMasks with multibyte-codepoints? I guess it may not work correctly. BTW, the UTF8String change is not in FPC 3.0.4 which we still must support. Even if FPC libs get new code that can be used in Lazarus, It takes many years before we can use it due to the slow release cycle. I hope FPC 3.2.2 comes out soon. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] unit Masks vs. unit FPMasks
A related thing. I am confused with different mask classes. Embarcadero docs for TMask http://docwiki.embarcadero.com/Libraries/Sydney/en/System.Masks.TMask says: "*Note:* Do not confuse TMask with the EditMask of a field or masked edit object. While both are used for comparing strings to a symbolic description of valid values, the special mask symbols and matching rules are completely different." Is the "*masked edit object*" the same as MaskEdit? Is the syntax really different? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] unit Masks vs. unit FPMasks
Hello LazUtils has unit Masks with classes TMask and TMaskList. FPC's packages/fpindexer has unit FPMasks also with classes TMask and TMaskList. A comment in FPMasks says "Moved here from LCL". Revision control shows it was added 9 years ago in 2012. Since 2.5 years ago it supports Unicode by using UTF8string for all strings. LCL has a related MaskEdit. It was first added in 2002 by Mattias with comment "added TMaskEdit from Tony" I don't know who Tony is. Unit Masks was first added to LCL in 2007 by tombo with comment "LCL: implemented TMask, MatchesMask, added Masks docs" I don't know who Tombo is either. In 2011 Masks was moved to LazUtils by Felipe. Masks and MaskEdit have some identical code. IMO MaskEdit should reuse some code from Masks. MaskEdit is maintained by Bart but he didn't know details of the history. Masks in LazUtils has a slow implementation. I planned to optimize it but now I realize we may have overlapping code. Q: Are Masks (LazUtils) and FPMasks (fpindexer) compatible? If they are, we should dump the LazUtils Masks and use code from FPC's libs. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LHelp and LazMouseAndKeyInput package
On Mon, Feb 22, 2021 at 10:52 AM Juha Manninen wrote: > The libXtst library dependency pulled in for Linux (and UNIX) was a > 100% increase of system dependencies for a Lazarus release, and for > absolutely no benefit. > Now Lazarus BigIde depends on just libgtk2.0-dev. > Ok, that was not accurate. Many other system libraries are pulled in by libgtk2.0-dev. However in a distro package system level it is the only requirement. Adding dependency for X brings another problem: Lazarus would not work with Wayland display server. Now it works if the widgetset supports Wayland. Major widgetsets like GTK3 and QT5 do support it. Not sure about GTK2. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LHelp and LazMouseAndKeyInput package
On Mon, Feb 22, 2021 at 3:29 AM Andrey Sobol via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> You excluded this code from lcore.pas
>
> procedure THelpForm.ShowApp();
> ..
> {$IFDEF WINDOWS}
> // Go to TOC TreeView and to get focus on foreground window
> KeyInput.Apply([ssCtrl]);
> KeyInput.Press(VK_T);
> KeyInput.UnApply([ssCtrl]);
> {$ENDIF}
>
Oh, LazMouseAndKeyInput was just for that code.
It created a serious bug. After pressing F1 in source editor the end of
current word was cut off.
The reason was that VK_T went to Lazarus IDE, although LHelp sent it to
itself, and the default command for VK_T is "Delete to end of word".
Didn't you notice the bug?
It was discussed in Lazarus devel mailing list. It should have happened
here instead.
Something funny happens in the interprocess communication. How could key
VK_T bring LHelp to front if it went to Lazarus' source editor?
> Without the code on windows system we can`t get rightly a focus lHelp
> by an event of restore the window after hide (the window is blinking on
> an aplication panel sometimes). We should send an user input sentence to
> the foregroud window from a mouse or from keyboard to get focus (that is
> windows specific problem).
>
Yes, in Windows terminology bringing to front means blinking an icon in
Taskbar.
A Lazarus user however wants to see the help window right after pressing F1.
I see some solutions of that:
> 1. To rewrite that code by WinApi (that is simple).
> 2. To exclude the package dependency on Mac system, but I don`t know how?
>
LazMouseAndKeyInput must be fixed for MacOS Cocoa but that is a whole
different issue.
Now that problem involves only Windows. A cross-platform package is not
needed for that.
The libXtst library dependency pulled in for Linux (and UNIX) was a
100% increase of system dependencies for a Lazarus release, and for
absolutely no benefit.
Now Lazarus BigIde depends on just libgtk2.0-dev.
3. To fix the Application.BringToFront() function at windows to rightly
> bring a foreground window to a front of a display.
>
That was my idea, too.
The method name BringToFront() is quite unambiguous. It should bring the
application to front. :)
The name is not BlinkAnIconInTaskbar().
If you know how to fix it, please do. I don't use Windows much myself. Does
this idea go against some Windows convention?
But I don`t see that problem now :). May be the blinkg was also a part
> of that issue https://bugs.freepascal.org/view.php?id=38276
>
> I redone many pieces after that, that a second round :)
>
I removed the LazMouseAndKeyInput dependency in r64647.
Please fix the remaining issues as you see fit (without libXtst dependency
for Linux).
Regards,
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] LHelp and LazMouseAndKeyInput package
Help has improved lately thanks to Andrey Sobol's patches mostly. However a new dependency was added: LazMouseAndKeyInput. On Linux and UNIX systems it pulls in libXtst dependency. LHelp is part of Lazarus BigIde target which is used for releases. Extra dependencies for BigIde should be avoided if possible. Now I studied how LazMouseAndKeyInput is used in LHelp. Well, it is not used! LHelpCore has MouseAndkeyInput in its uses section but removing it and the whole package dependency makes no difference. My analysis: LazMouseAndKeyInput dependency can be removed from LHelp. Am I right? Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] I say a little prayer (for the Lazarus editor)
On Sun, Feb 21, 2021 at 1:30 PM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > And one more thing, if you plan to submit a patch, please add an option > to SynEdit.Options2 > Many people are used to the current behaviour, I do not plan to upset them. > This particular feature should not have an option IMO. Now it can be considered a missing feature or even a bug. When a user presses Alt-key when selecting, he clearly wants something special to happen with Ctrl-C. Now nothing special happens which is a semi-bug. I am sure everybody will be happy when this feature gets implemented. I can remember many situations where it would have been useful. IMO there are too many options already. If I accidentally change something during my tests, it takes a long time to figure out what changed and how to revert it. Please add more options only when really needed. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LHelp memory leak
On Mon, Feb 15, 2021 at 1:36 PM Juha Manninen wrote: > I downloaded Marco's CHM snapshots linked here: > https://forum.lazarus.freepascal.org/index.php/topic,52437.0.html > There are 2 updates from Andrey Sobol. I downloaded them, too. > Now I learned they are also in Lazarus binaries SVN directory. https://svn.freepascal.org/svn/lazarus/binaries Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] LHelp memory leak
On Mon, Feb 15, 2021 at 2:16 PM Marco van de Voort via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Some memory leaks were fixed FPC side, retest with a stable branch > compiler. > Ok, I was using FPC 3.2 release. Do you mean testing with the 3.2.1 fixes branch? BTW, people are anxiously waiting for 3.2.2 release. I hope it happens reasonably soon. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] LHelp memory leak
I finally configured LHelp as a CHM help viewer in my development Lazarus. I downloaded Marco's CHM snapshots linked here: https://forum.lazarus.freepascal.org/index.php/topic,52437.0.html There are 2 updates from Andrey Sobol. I downloaded them, too. LHelp opens correctly, although slowly for the first time. There is a strange flicker. First an empty window shows up, then it disappears. A little later the actual help window with contents shows. Anyway, then it works well and the documentation itself has improved, too. Nice! When I close LHelp, it asks if I really want to do it. Yes, I want it. Then LHelp leaks memory. See below. IIRC it does not leak when I start it standalone. It is caused by the IDE integration. Andrey Sobol and everybody who develops LHelp, please use the Debug buildmode I added there some time ago. All debug flags should be on when developing code. I tested with Linux 64-bit. IDE is built with LCL-QT5, I guess the same is used for LHelp. Juha --- Heap dump by heaptrc unit of /home/juha/SW/lazarus_trunk/components/chmhelp/lhelp/lhelp 2104258 memory blocks allocated : 408948350/417932920 2104238 memory blocks freed : 408947390/417931960 20 unfreed memory blocks : 960 True heap size : 2686976 True free heap : 2681536 Should be : 2682176 Call trace for block $7FE448ECC900 size 96 $0051AEEA PROCESSASYNCCALLQUEUE, line 1066 of include/application.inc $00518ABB PROCESSMESSAGES, line 419 of include/application.inc $0089ED50 DOLOADURI, line 458 of chmcontentprovider.pas $008A28FC LOADURL, line 1299 of chmcontentprovider.pas $0052C828 OPENURL, line 1110 of lhelpcore.pas $0052AE5D SERVERMESSAGE, line 813 of lhelpcore.pas $006F26AE DOONTIMER, line 179 of customtimer.pas $006F2519 TIMER, line 151 of customtimer.pas $007513D1 SIGNALTIMEOUT, line 4706 of qt5/qtobjects.pas $7FE4713AFE10 $7FE4713B3E4B $7FE4713B3E4B $7FE4713B3E4B Call trace for block $7FE448ECBF00 size 96 $0051AEEA PROCESSASYNCCALLQUEUE, line 1066 of include/application.inc $00518ABB PROCESSMESSAGES, line 419 of include/application.inc $0089F6D9 QUEUEFILLTOC, line 602 of chmcontentprovider.pas $0089F290 NEWCHMOPENED, line 539 of chmcontentprovider.pas $008DB878 $008A27E7 LOADURL, line 1278 of chmcontentprovider.pas $0052CA58 OPENURL, line 1137 of lhelpcore.pas $0052AE5D SERVERMESSAGE, line 813 of lhelpcore.pas $006F26AE DOONTIMER, line 179 of customtimer.pas $006F2519 TIMER, line 151 of customtimer.pas $007513D1 SIGNALTIMEOUT, line 4706 of qt5/qtobjects.pas $7FE4713AFE10 $7FE4713B3E4B $7FE4713B3E4B Call trace for block $7FE4484FC600 size 32 $0051AEEA PROCESSASYNCCALLQUEUE, line 1066 of include/application.inc $00518ABB PROCESSMESSAGES, line 419 of include/application.inc $0089ED50 DOLOADURI, line 458 of chmcontentprovider.pas $008A28FC LOADURL, line 1299 of chmcontentprovider.pas $0052CA58 OPENURL, line 1137 of lhelpcore.pas $0052AE5D SERVERMESSAGE, line 813 of lhelpcore.pas $006F26AE DOONTIMER, line 179 of customtimer.pas $006F2519 TIMER, line 151 of customtimer.pas $007513D1 SIGNALTIMEOUT, line 4706 of qt5/qtobjects.pas $7FE4713AFE10 $7FE4713B3E4B $7FE4713AFE10 $7FE4713B3E4B Call trace for block $7FE4484FD600 size 24 $0051AEEA PROCESSASYNCCALLQUEUE, line 1066 of include/application.inc $00518ABB PROCESSMESSAGES, line 419 of include/application.inc $0089ED50 DOLOADURI, line 458 of chmcontentprovider.pas $008A28FC LOADURL, line 1299 of chmcontentprovider.pas $0052CA58 OPENURL, line 1137 of lhelpcore.pas $0052AE5D SERVERMESSAGE, line 813 of lhelpcore.pas $006F26AE DOONTIMER, line 179 of customtimer.pas $006F2519 TIMER, line 151 of customtimer.pas $007513D1 SIGNALTIMEOUT, line 4706 of qt5/qtobjects.pas $7FE4713AFE10 $7FE4713B3E4B $7FE4713B3E4B $7FE4713AFE10 $7FE4713B3E4B Call trace for block $7FE4484FDB00 size 40 $0051AEEA PROCESSASYNCCALLQUEUE, line 1066 of include/application.inc $00518ABB PROCESSMESSAGES, line 419 of include/application.inc $0089ED50 DOLOADURI, line 458 of chmcontentprovider.pas $008A28FC LOADURL, line 1299 of chmcontentprovider.pas $0052CA58 OPENURL, line 1137 of lhelpcore.pas $0052AE5D SERVERMESSAGE, line 813 of lhelpcore.pas $006F26AE DOONTIMER, line 179 of customtimer.pas $006F2519 TIMER, line 151 of customtimer.pas $007513D1 SIGNALTIMEOUT, line 4706 of qt5/qtobjects.pas $7FE4713AFE10 $7FE4713B3E4B $7FE4713B3E4B $7FE
Re: [Lazarus] Lazarus configuration - portable between versions?
LazarusDirectory tag indeed has version dependent paths. I don't remember what exactly it is used for. The Recent file lists are not important. They are updated dynamically and old entries will go away. So, you can copy the whole configuration if you do some minor editing. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus configuration - portable between versions?
On Sat, Feb 6, 2021 at 1:00 PM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > By looking inside the file on my old installationm I see clearly that this > is > not the file I can modify, lots of version dependent paths inside... > What paths are version dependent? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to find out which version of Lazarus was used to build last?
On Sat, Jan 23, 2021 at 5:40 PM Luca Olivetti via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I know because I had to do it recently and the answer is: a lot. > And I wasn't even using a really old version (I last modified the > program 3 years ago). > That is unexpected. Was it related to the Unicode string change? Indeed it broke backwards compatibility. If not, what required the biggest change? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to find out which version of Lazarus was used to build last?
On Sat, Jan 23, 2021 at 4:02 PM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > And I do not want some auto-upgrade function launched from a newer Lazarus > destroy the sources if I need to go back to an earlier version. > There are no auto-upgrade functions. If a new library version for some reason requires a modification, it must be made manually. Maybe I asked poorly. I meant: What modifications are needed because of updating FPC and Lazarus? Why don't you try it? Obviously backup your sources. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to find out which version of Lazarus was used to build last?
On Sat, Jan 23, 2021 at 1:18 AM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I don't want to modify too much so I would like to use the same version > now... > How many and what kind of modifications are needed? All libraries try to stay backwards compatible. As a general rule new versions are better than old versions. I recommend you jump to the latest versions of FPC and Lazarus. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Profiling with Valgrind and KCacheGrind
I am profiling and optimizing code in Lazarus IDE. Valgrind profiler + KCacheGrind visualizer tool make a very nice combination. A picture of KCacheGrind in real action : https://photos.app.goo.gl/YGn3uiNgciWPKSGx7 KCacheGrind is part of KDE project and thus integrates well with KDE Plasma desktop. Its authors have clearly profiled and optimized their own project. It opens super-fast although it processes megabytes of complex data and draws fancy graphics. Wow! There are lists for callers and callees. Data can be sorted by cumulative time, self time, number of calls, caller's distance from the function etc. Playing with it gives a good view of what is going on, and sometimes unexpected surprises. Usage instructions : https://wiki.freepascal.org/Profiling#Using_Valgrind.2FCallgrind KCacheGrind opens by clicking the default output file, at least with my KDE + Dolphin. No need to generate any human readable text files. KCacheGrind makes it human readable. I built Lazarus with "-gw3 -gl -gv" Martin builds without debug info with optimization. I will do the same thing. Optimization does not do harm for profiling as it does for debugging. -gv is the important flag for Valgrind profiler. Recommended! Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Component-View Presets
In r64336 I made the selected tab (PageIndex) persistent. I also added a test for define NoComponentListTreeExpand. Build Lazarus with it and the trees will not open as expanded. The define can be replaced with a proper option if you find a good place for it. Please test. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Component-View Presets
On Sun, Jan 3, 2021 at 1:59 PM R.Smith via lazarus < lazarus@lists.lazarus-ide.org> wrote: > ..., but it is a pain in an otherwise flawless environment. > Lazarus project has over 2000 open bug reports, but yes it is *almost* flawless. :) Is there any way I could achieve that in a setting or such so that > Lazarus starts by showing the Palette tab and starts it with the > Collapsed state? > The chosen tab, in this case Palette tab, should be persistent and stored in a configuration file. It will be applied for sure if you implement it. The Expanded/Collapsed state would require an option. Where to put it? The global options page for Component Palette is crowded. A new page for just 1 or 2 new options sounds like waste of space. Any ideas? If the Component-view window gets its own options, maybe the "Keep open" Checkbox should go there, too. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Issues getting sources from the repository
On Sat, Dec 26, 2020 at 11:41 AM Лев Бронштейн via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Hmmm... You are probably right. I recently changed my wifi router and > internet provider > It would be nice to know why only the FPC's Subversion installation is so sensitive. Now at least 3 people have had problems with it. For me everything else worked. Big downloads, streaming HD video, Subversion in Sourceforge ... I guess I would still happily use my old router without this one single problem with FPC's Subversion. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Issues getting sources from the repository
On Sat, Dec 26, 2020 at 2:49 AM Leyba Bronstain via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Somebody tell me pls, what happened? > It might be the same problem that I had earlier this year. On my Linux I got : svn: E120106: ra_serf: The server sent a truncated HTTP response body. again and again after just a few files were updated. All other internet traffic worked, including streaming videos. I have a Wifi router using 4G mobile phone network. It turned out to be bad. I tested with my Android phone as a Wifi hotspot and "svn co" worked. Then I bought a new router. Maxim Ganetsky had a similar problem on Windows and the reason was buggy WiFi drivers. It is a mystery why only Subversion in the FPC server is sensitive for the internet connection quality. Subversion in SourceForge worked. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Feedback for a patch supporting of EUDC to PUA for Microsoft mapping
Regarding issue : https://bugs.freepascal.org/view.php?id=38206 The latest patch for asiancodepagefunctions.inc compiles OK. Anybody who has knowledge of those encodings, please test and give feedback. I don't know how to test it myself. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TBitbtn
On Mon, Dec 14, 2020 at 11:59 PM Larry Dalton via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I am trying to create a tcomponent that will be a tpanel with align set at > albottom that will have several tbitbtns, the first of which will be kind > bkclose. I want to set that button’s onclick procedure to close the form > that the tpanel is on. What is the best way to write the onclick procedure? > TButtonPanel already does what you are planning. You can study its code and then either inherit your own component from it or create a new one. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Package requirement dialog & OLPM ?
On Sat, Dec 12, 2020 at 5:14 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > On my Mac, the "new package requirement" dialog shows the IDEIntf package > as an online > package (see attached screenshot req.png). As a result, I can't select it > without > 'installing' it first, which is of course total nonsense as it is already > installed. The lazarus on my Mac is a 2.0.10, no modifications except it > was > recompiled with some extra packages... > Please try Lazarus trunk. I remember there was a problem caused by uninitialized data which manifested itself only on MacOS for some reason. It was fixed in trunk. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Profiling with Valgrind
There is another wiki page about Valgrind : https://wiki.freepascal.org/Debugging_with_Valgrind It is not very good. It does not even mention the callgrind tool. What more, the page name is "Debugging with Valgrind" while it should be "Profiling with Valgrind". If somebody wants to improve instructions for profiling, please remove this Valgrind page after maybe merging useful information to the comprehensive Profiling page. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus (idescout) cannot be compiled after 64182
On Wed, Dec 9, 2020 at 4:39 PM Vojtěch Čihák via lazarus < lazarus@lists.lazarus-ide.org> wrote: > property Comps: TRegisteredComponentList read fComps; > > was removed (accidentaly? because the private field fComps is still there). > Oops, yes. I restored it in r64190. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Designer speedup, issue #37706, Sven Barth
On Wed, Dec 9, 2020 at 2:56 AM Juha Manninen wrote: > I want to optimize function TPkgManager.GetUnitsAndDepsForComps. > Actually that function is OK. I finally understood what it does. In r64188 I changed MainIDE.PropHookPersistentAdded so that it gets dependencies only for the newly added component instead of all components on a form. It surely affects speed with densely populated forms. Please test. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Designer speedup, issue #37706, Sven Barth
Partly inspired by issue https://bugs.freepascal.org/view.php?id=37706 I profiled Lazarus code with Valgrind to find what could cause such a slowdown in form designer. I didn't see any serious slowdown myself but clearly the designer eats more resources than it should. Registered components were searched all the time by class name. I changed the cache to use class type instead. It actually simplified and sped up things. It is function TBaseComponentPalette.FindRegComponent (was FindComponent) which is called also when mouse moves over the designer. The biggest change is in r64182. In r64184 I changed more code to use the component class type cache. By surprise it caused extreme slowdown. Selecting a component in designer took > 5 seconds with QT5 bindings, but the CPU was not under load. In addition with GTK2 bindings the selection dots didn't show. All that was gone after a clean build! What could cause it? I have no idea. A Sleep() call or Thread.WaitFor could cause a delay without CPU load but the code had neither. Anyway please test with the latest changes. Build clean if you need to. I want to optimize function TPkgManager.GetUnitsAndDepsForComps. It is part of Sven Barth's recent addition. It has 2 nested for-loops. The inner is : for CurUnitIdx:=0 to CurUnitNames.Count-1 do just after an item is added to CurUnitNames. Maybe the loops should go after each other instead of being nested. Now it may indeed be slow with a densely populated form. Comments? Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Is TForm.LastActiveControl working correctly?
On Sun, Dec 6, 2020 at 1:22 PM frans via lazarus < lazarus@lists.lazarus-ide.org> wrote: > ActiveControl and lastActiveControl always point to the same control. > > Is this a bug or is my understanding of lastActiveControl wrong? > That is how it is implemented. It is set to ActiveControl unless ActiveControl is Nil or a TCustomForm. if (FActiveControl<>nil) and not (FActiveControl is TCustomForm) then FLastActiveControl := FActiveControl; I did not know about LastActiveControl. What is the use of it? TScreen class seems to have it, too. Anyway, you can easily keep track of the previous ActiveControl in your code yourself. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Issues with apps on Linux...
On Mon, Nov 30, 2020 at 3:34 PM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I have two questions regarding Lazarus applications on Linux (Ubuntu > 18 Mate): > > 2) Is there a way to make forms transparent on Linux? > Using the AlphaBlend and AlphaBlendValue do not wor while they do on > Windows. > Is there some other way on Linux to make the form body transparent? > I need to see the background through it since I want to "measure" the > object by moving the form on top and adjusting its size to fit. > AlphaBlend + AlphaBlendValue work here with both GTK2 and QT5 bindings. It must be a Mate issue in your case. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Issues with apps on Linux...
On Mon, Nov 30, 2020 at 8:12 PM Andreas Schneider via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I also only learned this quite recently and was surprised by this, but > yes, that is unfortunately how it works on X11. Pasting basically asks > the application that "copied" it to get the content. If that app is gone > in the meantime, there's nothing to paste anymore. > > This will likely change with Wayland, but then it will also need some > unified API, which there is not yet, afaik. > Proper desktop systems have a clipboard manager which caches the data and essentially makes clipboard persistent. At least my KDE Plasma has it. An app in the taskbar also shows clipboard history which can be browsed and selected. Thus it is better than a traditional clipboard. I recommend such versatile desktops for anybody. At least KDE Plasma has been optimized over time and is now slim and fast. Memory consumption is not really more than with XFCE. Once a user opens Firefox, it hogs more memory than any desktop, thus overturning any benefits a minimal desktop might have given. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Profiling with Valgrind
Actually it is : $ valgrind --tool=callgrind --instr-atstart=no ./lazarus & The tool must be defined there. I fixed the wiki page. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Profiling with Valgrind
There is a wiki page about profiling, edited by many people: https://wiki.freepascal.org/Profiling It explains the usage of Valgrind among other profilers. There is a section: --- You can also profile only specific parts of your program. For example you can start the program with valgrind --instr-atstart=no ./myprogram --options --to --my --program --- It is not correct. I try to profile Lazarus project but Valgrind gives an error: valgrind: Unknown option: --instr-atstart=no If I start without parameters like: $ valgrind ./lazarus it uses the mem tool. What is the right syntax for starting Valgrind without a tool? I have Manjaro linux and Valgrind version 3.16.1. I have used Valgrind earlier but forgot many details. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus totally destroyed... :(
On Fri, Nov 20, 2020 at 12:32 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > - Updated Lazarus from SVN. > - Lazarus no longer compiles (FPC 3.2) > > - Managed to fix that: > > home:~/lazarus> svn diff ide/ideoptionsdlg.pas > Index: ide/ideoptionsdlg.pas > === > --- ide/ideoptionsdlg.pas (revision 64150) > +++ ide/ideoptionsdlg.pas (working copy) > @@ -36,7 +36,7 @@ > ExtCtrls, StdCtrls, Dialogs, > // LazControls > TreeFilterEdit, > - LazControlDsgn, // move this to lazarus.lpr > + // LazControlDsgn, // move this to lazarus.lpr > // IdeIntf > IDEWindowIntf, IDEOptionsIntf, IDEOptEditorIntf, IDECommands, > IDEHelpIntf, > ProjectIntf, IDEImagesIntf, > I remember that LazControlDsgn required some tweaking but it was a long time ago. No recent changes have affected it. I just today built Lazarus without problems. I don't know what is causing your errors. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Default project ?
On Wed, Nov 18, 2020 at 8:51 PM Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Especially since Lazarus crashes greatly if there is a problem with > the last project ... > Report all such crashes please. Test with Lazarus trunk and include a minimal test project to reproduce. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Project Group error ?
Regarding issue : https://bugs.freepascal.org/view.php?id=38011 People with easy access to Windows, please check if you can reproduce the problem? Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] AutoCommit
On Fri, Nov 13, 2020 at 6:19 PM Larry Dalton via lazarus < lazarus@lists.lazarus-ide.org> wrote: > So we lose some backwards portability? > IIRC it has been called "forward compatibility" as opposed to "backward compatibility". Backward compatibility means your old code works in new versions of FPC/LCL/Lazarus. The other direction is not guaranteed. New code cannot always be used in old versions. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RegisterWSComponent documentation?
FYI, the TTreeView in LCL is custom drawn. It does not map to a native widget unlike LCL controls typically do. There are empty classes TWSCustomTreeView and TWSTreeView and I guess you can derive from them as Dmitry explained. Replacing the current TTreeView in LCL is not realistic though. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Request for merge to 2.0
On Tue, Nov 3, 2020 at 6:02 PM Martok via lazarus < lazarus@lists.lazarus-ide.org> wrote: > may I ask to merge rev 62042 into fixes_2_0 for the next patch release? > There was an attempt to merge it to 2.0.10 but conflicts prevented it. I did not study deeply how to solve them. There will be no more patch releases for 2.0.x series. The next release will be 2.2. For now I would recommend Lazarus trunk for you. It works very well now. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Object Inspector, FValueFont and FDefaultValueFont
Regarding issue :
https://bugs.freepascal.org/view.php?id=37901
I improved the property name/value hints in OI.
I had to comment out code that selects FValueFont or FDefaultValueFont.
The relevant code is below.
Q: How to get a font with negated color?
Does it even make sense to tweak it? The hint works OK with the default
color now.
I ask in case somebody knows the topic well.
I did not study what Editor.ValueIsStreamed means. It never triggered in my
tests.
Regards,
Juha
---
procedure DoShow(pt: TPoint); inline;
//var HintFont: TFont;
begin
if WidgetSet.GetLCLCapability(lcTransparentWindow)=LCL_CAPABILITY_NO
then
Inc(pt.Y, fPropRow.Height);
{ By Juha :
FValueFont and FDefaultValueFont are nearly unreadable.
We should maybe get their negated color as the hint background is black.
if HintType<>pehValue then
HintFont := Screen.HintFont
else
if fPropRow.Editor.ValueIsStreamed then
HintFont:=FValueFont
else
HintFont:=FDefaultValueFont; }
FHintManager.ShowHint(ClientToScreen(pt), TheHint, False{, HintFont});
if FHintManager.CurHintWindow<>nil then
FHintManager.CurHintWindow.OnMouseLeave := @HintMouseLeave;
end;
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GUI for package dependency properties in Project Inspector
Package dependencies = Required Packages node in the Project Inspector. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] GUI for package dependency properties in Project Inspector
FYI In Lazarus trunk I implemented a GUI pane in Project Inspector, similar to what Package Editor has. Now only package dependencies have properties with GUI, the project member files have not. The GUI controls and some code are reused. Please test. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] App for PinePhone
On Sun, Aug 30, 2020 at 8:59 AM SteveG via lazarus wrote: > Dont mind if has to be QT5 / Gtk3 / fpGui / etc QT5 widgetset is rather complete and stable. AFAIK it does not require X11. That's the number 1 choice. GTK3 is still buggy and features are missing but it may be enough for some applications. fpGui widgetset binding is not maintained very actively. I am not sure how it works currently. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] weird error message
On Fri, Aug 21, 2020 at 7:14 PM duilio foschi via lazarus
wrote:
> In Delphi you write
> qryMain.AfterOpen:=TB_DPTAfterOpen;
>
> but whatever works is ok to me :)
It works also with FPC when using {$mode delphi}
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Fri, Aug 14, 2020 at 9:32 AM Ondrej Pokorny via lazarus wrote: > Why have you removed the (FTextHint <> '') check in CanShowEmulatedTextHint? > Why should the emulated text hint be shown if there is none? It was restored later as I noticed the same error. First I planned to make it generic code for both TEdit and TCombobox. Then I just copied it. The latest revision is 63734. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Thu, Aug 13, 2020 at 9:54 PM Ondrej Pokorny via lazarus wrote: > So for TMemo we need the emulated code, which works now with a minor bug > (the TextHint is not visible when the form is shown the first time). > Strangely the bug is present only in a themed application, not in an > unthemed one. Please test with the demo by Lagunov Aleksey in https://bugs.freepascal.org/view.php?id=37553 adding the line Memo1.TextHint:='My own TextHint'; as seen in my note. Also remember to change function TCustomMemo.CanShowEmulatedTextHint. It now returns False always. The emulation does not work with GTK2. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
Please test with r63734. The 3-state type TEmulatedTextHintStatus and its thsChanging was needed after all. Should have tested still more. :( At least here it works now. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Thu, Aug 13, 2020 at 6:56 PM Vojtěch Čihák via lazarus wrote: > something went wrong. When I open IDE Options or Project Options and I click > on any item of TreeView, everything disappear. Content of the filter become > "(filter)". When I change it (i.e. non-empty string), content is back. > > And many of the content is italic. > > Lazarus 2.1.0 r63731M FPC 3.3.1 x86_64-linux-qt Yours is QT4 I guess. Damn right, I can reproduce with GTK2 IDE. I mostly tested individual applications only. I try to figure out what is going on... Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Thu, Aug 13, 2020 at 6:50 PM Juha Manninen wrote: > AFAIK it is not emulated on Windows. LCL-Win32 reports LCLCapability > flag lcTextHint. Actually it is emulated for older Windows versions. function TWin32WidgetSet.GetLCLCapability has : ... lcTextHint: begin if (ComCtlVersion >= ComCtlVersionIE6) then Result := LCL_CAPABILITY_YES else Result := LCL_CAPABILITY_NO; end; For Windows 10 it should report LCL_CAPABILITY_YES. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Thu, Aug 13, 2020 at 6:40 PM Ondrej Pokorny via lazarus wrote: > Emulated TMemo.TextHint (r63708) works perfectly on Win32 (Windows 10). > I haven't checked your more recent changes. WinAPI doesn't support > TMemo.TextHint natively. AFAIK it is not emulated on Windows. LCL-Win32 reports LCLCapability flag lcTextHint. There is a related bug report : https://bugs.freepascal.org/view.php?id=35967 I tested the emulation only with GTK2. I should have mentioned the problem comes only when adding lines to a Memo by code when the Memo has no focus. It is demonstrated by the example project in issue #37553. I don't have Windows now at all. I was hoping not to install it again as I don't need it for anything. Maybe I must have it for Lazarus testing anyway. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TextHint in TComboBox
On Thu, Aug 13, 2020 at 3:23 PM Ondrej Pokorny via lazarus wrote: > If I am not mistaken, TEdit has TextHint-emulation for WidgetSets > without native support. There is no reason why the same emulation > shouldn't work with TMemo. It does not. Actually it never worked. Nobody has tested it maybe because TMemo.TextHint was not published. The native support eg. with LCL-QT5 does work. What happened so far: The emulated TEdit.TextHint was not updated always. I fixed it : https://bugs.freepascal.org/view.php?id=37506 Then I simplified the code in r63725 which broke TMemo's behavior : https://bugs.freepascal.org/view.php?id=37553 Then I realized that emulated TMemo.TextHint never worked and disabled it completely in r63726. You can test by reverting it. I believe it can be fixed somehow. I will be happy if you take a look at it. -- r63726 -- function TCustomMemo.CanShowEmulatedTextHint: Boolean; begin - Result := -Assigned(Lines) // CM_EXIT is sent in destroy -> this function is called in destructor when Lines are already destroyed -and (Lines.Count = 0) -and inherited CanShowEmulatedTextHint; + // CM_EXIT is sent in destroy -> this is called in destructor when Lines are already destroyed + //Result := Assigned(Lines) and inherited CanShowEmulatedTextHint; + // ToDo: Make this work. The line above does not work with GTK2 at least. + Result := False; end; Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TextHint in TComboBox
Regarding issue : https://bugs.freepascal.org/view.php?id=30682 I added TextHint to TComboBox in r63731. QT5 now works with native TextHint, GTK2 with emulated one. Native support for Win32 is not implemented yet. Somebody please implement it. Other widgetsets that natively support this feature for TComboBox, should also be updated. I have a question about TextHint support of TEdit in Win32. The widgetset binding code tests EmulatedTextHintShowing and calls CreateEmulatedTextHintFont from generic LCL code. Does it mean it actually emulates the feature inside the binding code instead of using a native feature? It should not be needed as the emulated TextHint works purely in LCL code level. Same thing with QT4 binding code. It also uses emulated TextHint specific stuff. Is it needed? TextHint in TMemo works only with widgetset's native support. It works with QT5 but not with GTK2. The emulation for TMemo turned out to be tricky. It may never be implemented, unless somebody provides a patch of course. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] SIGEGV crash when a hint displays under certain circumstances, qt5
On Mon, Aug 10, 2020 at 12:21 PM Julius via lazarus wrote: > Hi, for anyone following this thread: it is fixed in Trunk. Good :) Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] GTK2 app starts faster
On Sat, Aug 8, 2020 at 3:58 PM AlexeyT via lazarus wrote: > > With last changes (may-june-july 2020) in Laz, CudaText gtk2 starts faster- > > before with small window: 220ms, with big window: 330ms (BoundsRect > change was SLOW) > > now with small window: 220ms, with big window: 260ms I applied some patches about BoundsRect in GTK2, but I didn't realize they made such a big speed difference. Which revision exactly made it? Note, LCL component registration (TLCLComponent.NewInstance) was also optimized recently. It affects all widgetsets and apparently was not the reason for your faster startup. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] SIGEGV crash when a hint displays under certain circumstances, qt5
On Sun, Aug 9, 2020 at 10:17 AM Julius via lazarus wrote: > I'm running Laz 2.0.6, Kubuntu 20.04, it is a qt5 project. When built > "generically" (ie, no qt5 widgetset specified) it works with no > problems. I also tested Laz 2.0.10. > > Maybe someone has insights? If someone could confirm it so that I know > it is not just my computer/code, I will file a bug report. Building "generically" means the widgetset is GTK2. Can you please test also with Lazarus trunk. QT5 has got fixes and improvements there. If you can still reproduce, please file a bug report. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Treeview Question
On Tue, Jun 30, 2020 at 2:10 AM Martin via lazarus wrote: > In Lazarus there seems to be no disabled property for nodes, ... It could be implemented in TreeNode. However property "Enabled" instead of "Disabled" would be more consistent with other controls. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot find inc file from a registered package...
On Thu, Jun 25, 2020 at 9:51 PM Bo Berglund via lazarus wrote: > On Wed, 24 Jun 2020 11:44:29 +0300, Juha Manninen via lazarus > wrote: > >I installed Indy10 and checked. "Include files (-Fi)" says : > > .;Core;Protocols;System > >So the System directory is there. > > Not in my case, OPM did not place it there. The box is empty. OPM does not alter the packages. It only lets you download and install them. I wonder what could cause the difference. I got package indylaz 10.6.2 from OPM. > But it stopped at the exact same place again with the error message: > class_SSRemoteServer.pas(84,2) Fatal: Cannot open include file > "IdCompilerDefines.inc" > > So adding a path to the include path box for the package does not work > either. Yes, that was my experience, too, as I explained. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot find inc file from a registered package...
On Tue, Jun 23, 2020 at 10:40 PM Juha Manninen wrote: > Is the path containing the include file (Indy10\System or similar) in > Indy package's include search path? Bo, why don't you just answer my question? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot find inc file from a registered package...
On Tue, Jun 23, 2020 at 10:10 PM Bo Berglund via lazarus wrote: > I have added indylaz as a "Required Package" for the project but it > does not solve this problem even though it solved a few other Indy > related errors. Is the path containing the include file (Indy10\System or similar) in Indy package's include search path? If not then please add it. Otherwise it sounds like a bug. Unit files are found from required packages but apparently include files are not. Please report a bug with steps to reproduce. > What are you supposed to do in order to make Lazarus find this file? As a dirty workaround you can add the path containing the include file into your project's include search path. > And I don't even know where Lazarus has stored the package sources > during installation of indylaz so I cannot enter that into the project > properties either. You will figure it out. Open the Indy's package editor for example. Regards, Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] SQLdb Tab lost
On Sat, May 30, 2020 at 1:17 PM Special via lazarus wrote: > On a Raspberry Pi 4B 4GB, I installed Lazarus Trunc with fpcupdeluxe. > All seemed well, but then I discovered the SQLdb tab is lost. So I > cannot compile my SQLite Applications. How to fix? Install package sqldblaz. > Version # 2.1.0, FPC Version 3.3.1, SVN Revision: 63249. (Same problem > was already on SVN Version 6327). It does not depend on revision because it is a local configuration issue. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Keyboard mapping probelm
On Sat, May 30, 2020 at 4:40 PM Brian via lazarus wrote: > Unless you have some reason to believe that the QT5 version of > fpcupdeluxe doesn't build lazarus with QT5 bindings, I have already > tried this idea and still seen the same problem. Yes, I deleted back > EVERYTHING except for the actual fpcupdeluxe executable - all config > files and the entire target directory - from the GTK2 build. Then I > downloaded the QT5 version of the executable and ran that. Once again, > it built, but I still saw the key mapping etc. problem. Yes I have a reason to believe so. The LCL widgetset used for fpcupdeluxe executable does not affect how Lazarus is built. You can check the current widgetset of Lazarus executable from Help -> About Lazarus. All this hassle proves that fpcupdeluxe should not be used for the simple task of building native (OS, CPU) version of Lazarus trunk. It only complicates things and confuses. Getting sources and building Lazarus is so easy when FPC is already installed. Things are different when you want FPC trunk. It is not as trivial. (*) Cross-compilation is another good reason to use fpcupdeluxe. I have understood it shines there. > Since I've come this far, though, I guess I'm willing to try building > the lazarus code downloaded via subversion with the QT5 bindings. Is > there a web page, or some other documentation, that leads me though > doing that? I've never previously built the QT5 version except the > attempt to build it via fpcupdeluxe. As John Landmesser showed, Tools -> Configure "Build Lazarus" ... Juha (*) I have FPC trunk built and installed automatically from Manjaro AUR. It was actually trivial. :) -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Keyboard mapping probelm
On Fri, May 29, 2020 at 5:40 PM Bart via lazarus wrote: > It is a Lazarus/LCL/WS issue though, since other programs don't have that > issue. Yes, let's hope GTK3 bindings will be better. Now it is alpha but already usable for many applications. For Brian I recommend using QT5 bindings. It has no problem with keys. Lazarus trunk from fpcupdeluxe or from SVN directly should behave the same. I don't know why the build failed. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Keyboard mapping probelm
On Thu, May 28, 2020 at 7:38 PM Brian via lazarus wrote: > Thanks, but I have also tried various .DEBs from Sourceforge (I think > I stated that in an earlier message, but not 100% certain) with no > change in the problem. The .deb packages provide a released version. If something is fixed in the development version (trunk), you must use it instead. fpcupdeluxe is not needed. Just get the sources (svn co ...) and then build with "make". Run it directly ($ ./lazarus). No installation is required. FPC must be installed obviously before all that. The version from your distro's repository will do. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE "Rename identifier" misfeature
On Tue, May 26, 2020 at 10:49 AM Pascal Riekenberg via lazarus wrote: > Well, IDE doesn't check for conflicts. It's up to you! Actually it should check. There is also different pieces of code for different rename functions behaving a little differently. There are some related issues. See: https://bugs.freepascal.org/view.php?id=24275 https://bugs.freepascal.org/view.php?id=33024 Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Fwd: Consulta sobre Lazarus Ide
On Thu, May 21, 2020 at 8:12 PM Alexander Nava via lazarus wrote: > I have some questions: What are the actual questions? What means "... and nothing that allows us to port the application." The libraries that come with FPC and Lazarus are cross-platform. For example an LCL GUI application can be compiled for different OS / widgetset systems. Android is also supported but LCL is not ported for it. You must use different GUI libs then. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus crashes when opening project under conversion, how to fix?
On Fri, May 22, 2020 at 12:39 AM Bo Berglund via lazarus wrote: > ... I get to an access violation and Lazarus crashes! That is bad. Please copy a compressed project which crashes the IDE. I will look at it. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] GTK3, OnKeyDown
Strange. With LCL-GTK3 a Form.OnKeyDown handler is not called. The test app from issue : https://bugs.freepascal.org/view.php?id=37073 can be used. It has a splashscreen but have tested with a normal form, too. Same effect. The attached patch takes out a test if Widget^.has_focus then in function Gtk3WidgetEvent(). Then an OnKeyDown handler is called twice. Strangely enough, debugger shows the following line Result := TGtk3Widget(Data).GtkEventKey(Widget, Event, True); is called at least sometimes even when the Widget^.has_focus test is there. The message is delivered somewhere but not to the form. GTK3 experts, do you know what is going on? Juha From 26ea6e9395387d117fb81105c2cec15e6e067c6f Mon Sep 17 00:00:00 2001 From: Juha Date: Sat, 16 May 2020 20:39:28 +0300 Subject: [PATCH] LCL-GTK3: Make TForm.OnKeyDown work. --- lcl/interfaces/gtk3/gtk3widgets.pas | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lcl/interfaces/gtk3/gtk3widgets.pas b/lcl/interfaces/gtk3/gtk3widgets.pas index dd54483fa..d4f834619 100644 --- a/lcl/interfaces/gtk3/gtk3widgets.pas +++ b/lcl/interfaces/gtk3/gtk3widgets.pas @@ -1224,13 +1224,13 @@ begin // GDK_KEY_PRESS 8: begin - if Widget^.has_focus then + //if Widget^.has_focus then Result := TGtk3Widget(Data).GtkEventKey(Widget, Event, True); end; // GDK_KEY_RELEASE 9: begin - if Widget^.has_focus then // or (Widget = TGtk3Widget(data).GetContainerWidget) then + //if Widget^.has_focus then // or (Widget = TGtk3Widget(data).GetContainerWidget) then Result := TGtk3Widget(Data).GtkEventKey(Widget, Event, False); end; -- 2.26.2 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Keyboard mapping probelm
On Sat, May 16, 2020 at 2:49 PM Brian via lazarus wrote: > I tried that. Now *every* keypress is duplicated. It was allegedly fixed in trunk r63089 less than 3 weeks ago. See: https://bugs.freepascal.org/view.php?id=30863 If nobody gets the duplicate key problem with trunk any more, that issue and all its related issues can finally be resolved. Please test everybody. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Where to define conditionals for FPC
On Fri, May 8, 2020 at 7:03 PM Bo Berglund via lazarus wrote: > > All of this works OK in Delphi 2007 when I use the GUI to set the > conditional variables. You must have separate projects for Delphi and Lazarus in any case. Maintaining those variables in the Delphi project should not be a problem. > But what is worrying me is that the Lazarus Delphi Converter will not > find these conditionals and then convert stuff that are to be Delphi > only... > As far as I have understood the converter does not read the dproj file > where Delphi stores these settings. > But I might be overly anxious? Maybe Lazarus Delphi Converter can read > the dproj file and find the settings? No, a .dproj file is not supported currently. The converter reads .dpr project file and also .dof and .cfg files if available. At least earlier Delphi versions stored settings in those. > I made a test conversion a number of weeks ago and it failed because > of a lot of dependencies on components with no FCP counterpart etc... > Then I had to backtrack a lot to get the project in working order > again and decided to try to make the code FPC aware via the > conditionals and still keep the way it works now. Some projects are almost impossible to convert because they have components which are not ported to Lazarus. The automatic conversion cannot help you there. On Mon, May 11, 2020 at 10:33 AM Bo Berglund via lazarus wrote: > 2) Lazarus project file (lpi) > When you convert to Lazarus are you also getting an lpi file? Yes. When a project is converted for Lazarus you obviously get an .lpi project file. > And does the lpi file contain references into the Delphi install > directories? > The lpi file from my first (failed) conversion contains stuff like > this: > > > > > > It means those directories are in your Delphi project settings. Why are they there? Usually Delphi stores them in a global search path when components are installed. If they are also in the global search path, they can be removed from the project and the converter will not add them. > 3) Compiling same code with Delphi and FPC? > Do you convert your projects (manually) to make it possible to use > both Delphi and Lazarus as the IDE for further work on the same > sources? > If so do you have any hints as to what to look out for? Experience has proven that maintaining a project for both Delphi and Lazarus is difficult. At some point you will decide to dump the Delphi support. Maybe you should rethink your porting strategy and do a one-direction conversion from the beginning. You would save time in the long run. During a transition period you must maintain 2 versions, one for Delphi and one for Lazarus, but you don't need to struggle with an IFDEF mess. Replacing code and the whole porting process becomes easier. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TComboBox.ReadOnly
On Sat, May 2, 2020 at 11:37 AM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Yes, sorry - you are right. I missed that. I would just remove it. > Ok, I removed it in r63112. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TComboBox.ReadOnly
On Sat, May 2, 2020 at 9:09 AM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > From what I can see the ReadOnly property is still published. I would > remove it completely, there is no reason to have it anymore if it was > deprecated for 3 years. Not even in the public section. (Again, even > with ReadOnly=True you can still change the value with the drop down.) > No, the published property is gone. You must rebuild the IDE before it disappears from OI. There is a public TCustomComboBox.ReadOnly : property ReadOnly: Boolean read GetReadOnly stored False; ... function TCustomComboBox.GetReadOnly: Boolean; begin Result := Style in [csDropDownList, csOwnerDrawFixed, csOwnerDrawVariable]; end; This works in Lazarus as well: > procedure TForm1.Button1Click(Sender: TObject); > begin >// make combobox read-only (make sure ComboBox1.Style=csDropDown) >SendMessage(GetWindow(ComboBox1.Handle, GW_CHILD), EM_SETREADONLY, > Ord(True), 0); > end; > Works only with LCL-Win32. I just realized that a custom cross-platform component could easily be inherited from TCustomEditButton. It is the ancestor of TFilenameEdit, TDateEdit etc. It makes sense if you need many instances of those controls. Otherwise a TEdit + anchored dropdown button suffices. Such a custom component will not be added to LCL however because TComboBox and TComboBoxEx are enough for most people. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TComboBox.ReadOnly
I applied my own patch. It removes the deprecated published property so it will be gone in Lazarus 2.2. A public ReadOnly property remains but is cannot be assigned any more. Thus ReadOnly property is itself readonly. :) Please test. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TComboBox.ReadOnly
Regarding issue:
https://bugs.freepascal.org/view.php?id=36978
TComboBox ReadOnly was deprecated in r55243 by Ondrej at 2017-06-05.
No reason is mentioned but I believe it had good reasons.
The deprecated message was updated in r59467 by Mattias at 2018-11-06.
The deprecated message says: "use extended Style values instead."
How exactly should they be used to get the old ReadOnly behavior?
The deprecated message says the ReadOnly property will be removed in
Lazarus 2.2.
I removed it and fixed the numerous side effects. The changes are in the
attached patch.
There may be more side effects, I only tested with packages that happened
to be installed here.
Is it OK to apply?
Juha
From 74ded84dd5b5d9bb6f07ea9d6c77e90fa4470c91 Mon Sep 17 00:00:00 2001
From: Juha
Date: Fri, 1 May 2020 12:45:07 +0300
Subject: [PATCH] LCL: Remove deprecated TComboBox.ReadOnly.
---
components/tachart/tachartcombos.pas | 1 -
components/turbopower_ipro/iphtml.pas | 1 -
lcl/colorbox.pas | 1 -
lcl/include/comboex.inc | 2 --
lcl/include/customcombobox.inc| 5 -
lcl/stdctrls.pp | 4 +---
6 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/components/tachart/tachartcombos.pas b/components/tachart/tachartcombos.pas
index 9d1265c94..9f1897e48 100644
--- a/components/tachart/tachartcombos.pas
+++ b/components/tachart/tachartcombos.pas
@@ -234,7 +234,6 @@ constructor TChartComboBox.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
DropdownCount := DEFAULT_DROPDOWN_COUNT;
- ReadOnly := true; // Needed to see the symbol without dropdown.
Style := csOwnerDrawFixed;
SetLength(FPenPattern, 2);
FPenPattern[0] := 1;
diff --git a/components/turbopower_ipro/iphtml.pas b/components/turbopower_ipro/iphtml.pas
index fdce7771e..8ea476e72 100644
--- a/components/turbopower_ipro/iphtml.pas
+++ b/components/turbopower_ipro/iphtml.pas
@@ -12445,7 +12445,6 @@ begin
AdjustControl;
with TComboBox(FControl) do begin
Style := csDropDownList;
- ReadOnly := not FComboBox;
OnEditingDone := ControlOnEditingdone;
end;
end;
diff --git a/lcl/colorbox.pas b/lcl/colorbox.pas
index 515f85b1a..f3e9044f7 100644
--- a/lcl/colorbox.pas
+++ b/lcl/colorbox.pas
@@ -381,7 +381,6 @@ constructor TCustomColorBox.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
inherited Style := csOwnerDrawFixed;
- inherited ReadOnly := True;
FColorRectWidth := -1;
FColorRectOffset := cDefaultColorRectOffset;
diff --git a/lcl/include/comboex.inc b/lcl/include/comboex.inc
index de2af4755..f24d91366 100644
--- a/lcl/include/comboex.inc
+++ b/lcl/include/comboex.inc
@@ -275,7 +275,6 @@ begin
FAutoCompleteOptions:=cDefAutoCompOpts;
FItemsEx:=TComboExItems.Create(self, TComboExItem);
FNeedMeasure:=True;
- ReadOnly:=True;
inherited Style:=csOwnerDrawFixed;
FStyle:=cDefStyle;
FStyleEx:=[];
@@ -492,7 +491,6 @@ constructor TCustomCheckCombo.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
TStringList(Items).Duplicates:=dupIgnore;
- ReadOnly:=True;
Style:=csOwnerDrawFixed;
FNeedMeasure:=True;
FRejectToggleOnSelect:=True;
diff --git a/lcl/include/customcombobox.inc b/lcl/include/customcombobox.inc
index e236923e2..649e8a52e 100644
--- a/lcl/include/customcombobox.inc
+++ b/lcl/include/customcombobox.inc
@@ -1091,11 +1091,6 @@ begin
end;
end;
-procedure TCustomComboBox.SetReadOnly(const AValue: Boolean);
-begin
- // will be removed in 1.10
-end;
-
{--
procedure TCustomComboBox.UpdateSorted;
--}
diff --git a/lcl/stdctrls.pp b/lcl/stdctrls.pp
index f00e146c1..feeda55d2 100644
--- a/lcl/stdctrls.pp
+++ b/lcl/stdctrls.pp
@@ -306,7 +306,6 @@ type
procedure LMMeasureItem(var TheMessage: TLMMeasureItem); message LM_MeasureItem;
procedure LMSelChange(var TheMessage); message LM_SelChange;
procedure CNCommand(var TheMessage: TLMCommand); message CN_Command;
-procedure SetReadOnly(const AValue: Boolean);
procedure UpdateSorted;
procedure SetArrowKeysTraverseList(Value: Boolean);
procedure WMChar(var Message: TLMChar); message LM_CHAR;
@@ -404,7 +403,7 @@ type
property DropDownCount: Integer read FDropDownCount write SetDropDownCount default 8;
property Items: TStrings read FItems write SetItems;
property ItemIndex: integer read GetItemIndex write SetItemIndex default -1;
-property ReadOnly: Boolean read GetReadOnly write SetReadOnly stored False;
+property ReadOnly: Boolean read GetReadOnly stored False;
property SelLength: integer read GetSelLength write SetSelLength;// UTF-8 length
property SelStart: integer read GetSelStart write SetSelStart;// UTF-8 position
property SelText: String read GetSelText write SetSelText;
@@ -480,7 +479,6 @@ type
property Parent
Re: [Lazarus] EAccessViolation exception on exit qt5 project in Kubuntu 19.10
On Wed, Apr 15, 2020 at 12:22 AM Erwin van den Bosch via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I build FPC 3.20 RC1 on my Kubuntu 19.10 and I can confirm that the > segfault does not happen anymore. I created a simple project with button > and opendialog and all worked fine. > > So FPC 3.2rc1 seems to fix it. > I got the crash every time, even with an empty LCL application without anything added. No OpenDialog was involved. Yes, it happened only with FPC3.0.x. Now I have installed FPC trunk from Manjaro's AUR repo and the crash is gone. I hope we will get rid of FPC3.0.4 soon. I will use only FPC trunk or 3.2(RC) from now on. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] EAccessViolation exception on exit qt5 project in Kubuntu 19.10
On Mon, Apr 13, 2020 at 10:01 PM Erwin van den Bosch via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Just did a fresh install of kubuntu 18.04 LTS and all my Lazarus QT5 > projects works fine. No access violation error on application close. So > there must be something wrong/incompatible with kubuntu 19.10. > > I did two installs of kubuntu 19.10. One on a real machine and one in > VirtualBox. Same problem on both. > > Someone experience the same problem? > I have the same problem with Manjaro + KDE Plasma. I had it for a long time already but didn't study further. Manjaro has a recent version of everything. Maybe the pre-compiled libQt5Pas works only with older versions of QT5 libraries. I didn't even try to build libQt5Pas myself yet. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Online Package Manager question
On Mon, Apr 13, 2020 at 8:47 PM silvioprog via lazarus < lazarus@lists.lazarus-ide.org> wrote: > What do you think about to create a new project "OPM" > at bugs.freepascal? ☺ This way, the package's author just opens an new > issue categorized with "OPM" providing steps/requirements he wants to > upgrade his package, making it public and available for > future consultation/reference. > That sounds dangerous. We would get bug reports of components delivered by OPM although they are maintained elsewhere. Actually it has happened already. (MinGW follows something like this, allowing merging from Github's PRs to > their upstream) > Then they both must be in the same source tree somehow. I don't know about their process. Note, the sources of packages delivered by OPM are not merged to Lazarus source tree. They are just copied. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] We are planning the next release: Lazarus 2.0.8
On Sat, Apr 11, 2020 at 2:06 AM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I haven't gotten to test gdb 8.3 myself yet. So I do not know how it > compares to other gdb versions. > gdb 8.3 is old! Manjaro has already version 9.1. Maybe it contributed to my solid debugging experience. $ gdb --version GNU gdb (GDB) 9.1 Copyright (C) 2020 Free Software Foundation, Inc. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] We are planning the next release: Lazarus 2.0.8
On Fri, Apr 10, 2020 at 11:46 AM C Western via lazarus < lazarus@lists.lazarus-ide.org> wrote: > The current FPC 3.2.0RC1 / 2.0.8 release works fine for me, though I > would comment that debugging with gdb seemed particularly crash prone; I > am using: > > GNU gdb (GDB) Fedora 8.3.50.20190824-30.fc31 (64 bit) > Can you please test if Lazarus trunk makes a difference for the GDB experience. I am running Lazarus trunk on Manjaro Linux and just debugged Lazarus IDE itself without problems. (Bug tracker issue #36872). Actually debugging works amazingly well despite its known limitations. My FPC is now 3.0.4 but I don't think it makes a difference. The debug info format has not changed. It is either a Lazarus problem or a Fedora problem. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] We are planning the next release: Lazarus 2.0.8
On Fri, Apr 3, 2020 at 11:35 AM Rolf Wetjen via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I wanted to ask for https://bugs.freepascal.org/view.php?id=35362 and > https://bugs.freepascal.org/view.php?id=36798. > OK, that makes more sense. :) Issue #35362 is a regression. If your patch works it surely should be applied and merged to 2.0.8 branch. Apparently Michl is not active right now so I assigned the issue to Martin. I myself don't have a Windows now. I am setting up Lazarus under Wine in my new super-computer (!) and then I can test Windows patches, too. Wine has improved steadily and is very good nowadays. Issue #36798 is solved and I believe the commit r62781 can be merged. I will not add it to the list, somebody else must decide it. I see you have added a documentation update _after_ the issue was resolved. Please reopen the issue, it is left unnoticed otherwise. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] We are planning the next release: Lazarus 2.0.8
On Fri, Apr 3, 2020 at 10:58 AM Rolf Wetjen via lazarus < lazarus@lists.lazarus-ide.org> wrote: > can you please check for r35362 and r36798 and probably include them too? > Those are from February and April 2012. Eight years ago. Are you surely looking at Lazarus commit history? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] We are planning the next release: Lazarus 2.0.8
On Thu, Apr 2, 2020 at 12:40 PM Luca Olivetti via lazarus < lazarus@lists.lazarus-ide.org> wrote: > It's not urgent (because I use my local copy with the patch) but there > is this: > > https://bugs.freepascal.org/view.php?id=35715 > I took care of it. It can safely be merged. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RFC: Selection Editors to extend handling of object inspector selections
On Sun, Nov 10, 2019 at 11:26 PM Sven Barth via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I've got a RFC for a feature that allows to extend the IDE. It's based > on something that Delphi supports as well: Selection Editors. > I finally took a proper look at this. First remark without testing is that unit SelEdits should be in LCL instead of IdeIntf. It says Abstract: This unit contains selection editors for various LCL components. Thus it is not needed by external IDE plugin packages which use IdeIntf. I will test the patches later. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Close all menu item ?
On Tue, Mar 24, 2020 at 5:54 PM Juha Manninen wrote: > Ok, project inspector showing the closed project is clearly a bug. > I fixed this in r62813. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The Problem with the Linux Desktop
On Fri, Mar 27, 2020 at 10:09 AM Anthony Walter via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I was looking at the Unity tray icon code I submitted a while back and it > had stopped working on my desktop environment. > David Bannon, forum name dbannon, made a version for GTK3 based on your work. You may know that already but anyway... Maybe you can join forces for a solution that works on many desktops. It requires maintenance yes, but Linux desktops have some standards. The situation is not completely hopeless. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Close all menu item ?
On Tue, Mar 24, 2020 at 4:58 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Note the project inspector is still open, and the package editors as well. > Ok, project inspector showing the closed project is clearly a bug. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Close all menu item ?
On Tue, Mar 24, 2020 at 11:39 AM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > To any normal human being, *Close All* means close *ALL*. > But when it is under File menu, it means "Close All Files". :-) -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Close all menu item ?
On Tue, Mar 24, 2020 at 10:56 AM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I though "Close Project" does the thing, or isn't this good enough? > +1 Exactly. As a bonus the editor files session of the closed project is remembered and reopened next time. Please remember that "Close all" is in File menu, not in Project menu. Delphi has its project menu items in File menu which is counter-intuitive. IMO Lazarus works logically in this regard. If you don't want to do "Close Project", you can do "New Project". You don't need to save it but all IDE features remain enabled. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IdeIntf was split to BuildIntf
On Tue, Mar 24, 2020 at 9:47 AM Juha Manninen wrote: > The easiest cure is to open components/buildide.lpk in the IDE. > Oops :( It should be "components/buildintf/buildintf.lpk" obviously. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] IdeIntf was split to BuildIntf
IdeIntf package was refactored, non-GUI parts were moved to a new BuildIntf package. Commit r62795 by Mattias (although I did the actual split). Rebuilding the sources after r62795 using a Lazarus executable built before it gives an error. The old IDE does not know where the BuildInf package is. The easiest cure is to open components/buildide.lpk in the IDE. Building succeeds once the IDE has seen it. See issue : https://bugs.freepascal.org/view.php?id=36819 Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Close all menu item ?
On Mon, Mar 23, 2020 at 2:35 PM Marco van de Voort via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Personally I hate the mandatory open project (or else the modal > options). E.g. you want to open a .lpk and you have to create a project > first to open the menu item. > Not really because a project is always opened automatically when you start Lazarus. It's either the previously used project or a new empty project. The new empty project behaves almost like "no project" because you don't have to save it. IIRC the "Close Project" entry was added after a user request, but it is rather useless. You cannot do much anything when projects are closed. Everything is disabled then. I also remember the initial confusion because of this feature but now it feels very functional. A project never needs to be closed explicitly, it gets closed when another project is opened or when the whole IDE is closed. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE trunk cannot build on fpc 3.0.2
On Thu, Mar 19, 2020 at 10:11 AM Ondrej Pokorny via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Well, generics may cause an internal error on a simple compile. A clean > rebuild is needed to compile even after a small change. > It may be true when a generics class definition changes. Typically they don't change often. This happens a lot for me now. Sometimes in the changes from r62639, > sometimes in different code. If I work on the source of the Lazarus IDE and > I recompile it, I get an internal error. Then I have to rebuild Lazarus IDE > clean, which takes a lot of time. > r62639 required a clean compile also because the container class was moved to LazUtils. Other containers are already there. If the old .ppu remains in its old place, it causes an incompatible ppu error. An internal error happens because of a bug in FPC. I also get them a lot but I didn't notice any connection to generics. The error comes in unexpected places, not related to changes I made. Usually no generics are used there. I am also worried when the FPC bug or bugs get fixed. It is not a new thing and it may have gotten worse. There are bug reports like: https://bugs.freepascal.org/view.php?id=33087 It is really frustrating when this happens every 10 minutes :/ I really > don't see a point to change working code to generics. > Please don't blame my refactoring if it happens every 10 minutes. It was a one-time shot. The change was related to a substantial new feature for the package system provided by Sven Barth. See issues : https://bugs.freepascal.org/view.php?id=36654 https://bugs.freepascal.org/view.php?id=36734 Generics make a lot of sense in containers bringing type checking and safety also there. The code becomes more self-documenting as well. In this particular case the container usage was not obvious. The Pointer -> Pointer container was used in 2 different ways in the same unit, now specialized as TPackagePackageArray and TOwnerPackageArray. Unit ObjectLists is now used only in unit PkgManager but it looks like a useful container and deserves to be in LazUtils. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TCheckBox
On Mon, Mar 16, 2020 at 4:34 PM Jean SUZINEAU via lazarus < lazarus@lists.lazarus-ide.org> wrote: > May be you can create a new component class, based on TPanel, in which > you place a TCheckbox with empty text and a TLabel at the position you > want ? > For temporary use you could just anchor a Label and a Checkbox together on a form and set a border space between them. Yes, the Caption of Checkbox would be empty then. I am not sure how well that works in practice. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] lazarus (2.0.6) on ubuntu 19.10 fails
On Thu, Mar 5, 2020 at 3:15 PM Евгений Кадисов via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Lazarus writes that it compiles and builds with "sucess" but is 'unable to > run "/home/eugen/aux/lmarka/project1"' > Can you run the executable from console? If not, what is the error message? Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Application.Title and .Scaled automation + logic fix
Application.Title in project's main unit is updated automatically based on a project title setting. Unchecking the option "Main unit has Application.Title statement" was originally meant as an alternative in case the automation failed. The text was misleading. If automation was turned off, the main unit could still have Application.Title statement in case a user decided to add it manually. Earlier changes in code followed the flawed text and removed the statement always when the option was turned off. I improved the logic some days ago in r62669 and changed the text to "Update Application.Title statement in main unit". I also improved the automation. Now the LCL GUI specific options cannot be set for a console program any more. The code tests for LCL dependency and Forms unit in uses section. This all fixes issue : https://bugs.freepascal.org/view.php?id=36521 among other unreported issues. Similar change was made for Application.Scaled. I also changed the text for "Application.CreateForm statements" checkbox although I did not change its logic. Comments? Are the texts good? Project template "Console Application" uses TCustomApplication which has Title which is not set automatically now. I guess it is OK because the Title is not used anywhere.(?) Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE trunk cannot build on fpc 3.0.2
On Thu, Feb 27, 2020 at 7:59 AM Michael Thompson via lazarus < lazarus@lists.lazarus-ide.org> wrote: > >> On Tue, Feb 25, 2020 at 8:05 PM AlexeyT wrote > >> pkgmanager.pas(77,78) Error (5000) Id not found TObjectArray$2 > > I'm hitting this error on Windows. fpc 3.0.4 > I built Lazarus with with FPC 3.0.4. It works with 100% certainty. No idea. Warning - the following does not contain known facts! Wildly > guessing (honestly) that for 3.0.4 the code in fgl only accepts types and > you compiled with 3.1 which may have improved support for classes? Dunno. > A class is also a type. Generics have worked with classes from the beginning. My solution for now is to revert to revision 62638 > I guess the right solution is to build clean, so that old .ppu files get deleted. The unit ObjectLists (and class TObjectArray) was moved to another place. The left-over compiled files may cause problems. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE trunk cannot build on fpc 3.0.2
On Tue, Feb 25, 2020 at 8:05 PM AlexeyT via lazarus < lazarus@lists.lazarus-ide.org> wrote: > pkgmanager.pas(77,78) Error (5000) Id not found TObjectArray$2 > The line is: TPackagePackageArray = specialize TObjectArray; I turned TObjectArray into a generics container to reduce typecasts. It uses a very basic syntax, similar to what unit fgl has used for ages. generic TObjectArray = class Does "TObjectArray$2" mean the compiler does not find the second parameter? Why wouldn't it? Both parameters are the same "TLazPackageID". Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] svn update can't be compiled
On Tue, Feb 25, 2020 at 1:35 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Use yay as user instead of pamac and most trouble with pamac are gone :-) I have used yay _once_ when installing drivers for a Brother printer by following written instructions. Anyway, good to know. > But i have to test this, or do i stay with 3.1.1? FPC 3.1.1 (trunk) seems to work well. It may have experimental code for a new language feature or something but if you don't use that feature it should be OK. Sometimes there are hiccups, broken revisions, but usually they are fixed quickly. If you bump into a bug, you can either wait for a fix or revert to an earlier revision. It seems FPC trunk is used a lot (because there are no recent releases) and thus tested a lot, too. Actually the same applies to development branches of many FOSS projects, including Lazarus. Its developers use it for obvious reasons and spot broken revisions quickly. Many other people seem to use it as well. It is not recommended for production use but if you can afford few hiccups occationally, it is very usable. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] svn update can't be compiled
On Tue, Feb 25, 2020 at 11:53 AM Andrea Mauri via lazarus wrote: > I get the same error on MacOS There is a fix/workaround in r62671, commit by Ondrej this morning. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] svn update can't be compiled
On Mon, Feb 24, 2020 at 10:22 PM John Landmesser via lazarus wrote: > For Manjaro (ArchLinux) i installed fpc-svn and fpc-src-svn from AUR > with yay and now i have a running: > > Lazarus 2.1.0 r62669 FPC 3.3.1 x86_64-linux-gtk2 I also run Manjaro Linux but I didn't know that AUR has FPC trunk. I would download it if I didn't build it already myself. Manjaro's official repo always has the latest versions of everything. It is super nice compared to repos of Debian + its derivatives for example. However it doesn't help with FPC because they release so seldom. Ancient FPC 3.0.4 is still the latest. This is almost unbearable. Issue #30306 was an important compatibility feature/fix. It got fixed some 3 and half years ago. When FPC 3.2 finally comes out, it may well be 4 years. Insanity! More and more people must build FPC from sources. It hogs resources also from FPC devels. They have an endless merge exercise. Bug fixes from past years must be dug up and merged to 3.2 branch. Still the release will be outdated already when it finally comes out, because trunk has collected so much new stuff during the years. Other FOSS projects have faced the same problem in past. They typically fixed it by adjusting their release policy. Release early, release often. A principle of "release when it is ready" is doomed. No substantial SW is "ready" ever. There will always be things to fix and improve. I hope there will be more forks of FPC project which concentrate on release schedule. Maybe one of them could replace FPC in distro repos. Maybe Lazarus can switch to use it. Don't know ... Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] svn update can't be compiled
On Mon, Feb 24, 2020 at 5:24 PM John Landmesser via lazarus
wrote:
> Lazarus 2.1.0 r62571M FPC 3.0.4 x86_64-linux-gtk2
> ...
> screen.inc(438,26) Error: Call by var for arg no. 1 has to match exactly: Got
> "TScreen.{Dynamic} Array Of TCursor" expected "UnicodeString"
It is reported :
https://bugs.freepascal.org/view.php?id=36728
The nasty thing is that the bug in FPC was fixed almost 3.5 years ago
but still not included in any released FPC version.
See the related issue #30306.
FPC project's release policy would need a revamp.
Juha
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE PackageManager crash on placing ATSynEdit on a form
On Mon, Feb 24, 2020 at 1:21 PM AlexeyT via lazarus wrote: > https://forum.lazarus.freepascal.org/index.php/topic,48617.0.html See my forum post. Juha -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
