[Lazarus] QT5 progress?
Is anything going on with the QT5 port? The QT mailing list has been pretty dead for a year, and it doesn't appear there's been updates to the qt4pas alpha in that time either. -- Zoë Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Beyond Compare 4 built with Lazarus 1.2
On Dec 31, 2013, at 3:19 AM, Michael Van Canneyt wrote: > First find a ThousandSeparator and DecimalSeparator that would actually need > this. > Then we'll see. Several locales on OS X use U+00A0 no-break space as a thousands separator, which is $C2$A0 in UTF-8, so it doesn't fit in a single AnsiChar. We had to add a lossy conversion to $20 to preserve the appearance, if not the semantics, of it. There was a thread on the Mac-pascal mailing list a few months back about it. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Beyond Compare 4 built with Lazarus 1.2
On Dec 25, 2013, at 5:11 PM, Hans-Peter Diettrich wrote: > I wonder what exact "support" he means. Wonder no more: 1) "string" uses a Unicode encoding 2) AnsiString/UTF8String casts perform appropriate conversions 3) File APIs support Unicode filenames 4) Windows headers use W version by default. 5) LCL and RTL agree on string encoding 6) In a stable Lazarus and FPC release As long as the language and libraries agree on an encoding I don't really care whether it's UTF-8 or UTF-16. I've also been working with Unicode since 2001 though, and have had to deal with plenty of different encodings, file formats, and API conversions in that time, so I don't think our usage is indicative of the average Delphi programmer, and I wouldn't want to speak for anyone else. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Beyond Compare 4 built with Lazarus 1.2
Hi All, Yep, Beyond Compare 4 for OS X uses Lazarus with the Carbon backend. Thank you to all of the hard working Lazarus and Free Pascal developers that helped make it possible. While I did mention some things in that post that I didn't like about Lazarus/Free Pascal, I think you've done excellent work. I was really impressed with how much worked out of the box and how compatible everything was, both in the LCL and the compiler. The Objective Pascal extensions are really well done. Not having the IDE go brain dead while debugging was a welcome change too. :) We actually got the core product up and running fairly quickly; the last two years have been spent making it more at home on OS X. We've submitted most of our changes back to the team, and will get the remaining ones out soon. Unfortunately a number of the enhancements, like per-window sheet support, rely on a lot of our application level behavior, so they can't be incorporated into the LCL easily, but I am happy to answer any questions or share the relevant code snippets for anyone who wants them. We will definitely be looking into LCL/Qt for our Linux version once we get v4 released. Seeing the Qt5 bindings has made me very happy. On Dec 25, 2013, at 11:51 AM, Marco van de Voort wrote: > On Tue, Dec 24, 2013 at 04:44:37PM +, Graeme Geldenhuys wrote: > Which hopefully makes clear that Delphi compat unicode is needed by some :-) As long as "string" supports Unicode, and AnsiString/UTF8String casts do appropriate conversions, I don't really care whether it's UTF-8 or UTF-16. One of the things that made code sharing easier is that OS X and modern Linux both use UTF-8 for C strings, so we were able to use string/TStringList/etc on all three platforms, with all three compilers, and know that it was always Unicode. AnsiString was used in places on Windows where we needed it, but that was about it. There were cases where we had to use UTF-16 on OS X to minimize conversions during drawing, and there were cases on Windows where we had to use UTF-8 to reduce memory usage. Delphi compatibility in general has been very important, though, and I appreciate all the efforts in that direction. BC's source code needed it, of course, but we also rely on some large third party libraries, like Indy and SecureBlackBox, and have had to port several others ourselves (ZipForge, Abbrevia, chsdet, some bits of the JCL). I'm quite confident that if there had been a significantly higher barrier to bringing our code over we would have switched to a non-Pascal environment instead. In any case, thanks again. We really couldn't have done it without this community. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?
On Dec 25, 2013, at 3:43 PM, Jy V wrote: > I cannot let you answer alone and make you appear as the only knowledgeable > reference for this important subject, > it looks like defining default code page 65001 for Windows make it perfect > fit to handle UTF-8 > http://msdn.microsoft.com/en-us/library/dd317756%28VS.85%29.aspx Windows doesn't support using UTF-8 as the default system code page and never will. Michael Kaplan, from Microsoft, has talked about it a number of times in his blog. The original site is unfortunately offline, but it's available through the Internet Archive at https://web.archive.org/web/20120414160234/http://blogs.msdn.com/b/michkap/archive/2006/10/11/816996.aspx https://web.archive.org/web/20110108050100/http://blogs.msdn.com/b/michkap/archive/2006/07/04/656051.aspx The short answer is that all of the selectable ANSI codepages have at most 2 bytes, and UTF-8 can have up to 4, which would require auditing/updating huge amounts of code. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Deleteing a file that has a path that's longer than 256 characters
On Nov 26, 2013, at 7:59 AM, Richard Mace wrote: > I have an issue where I am unable to delete a file where the path name is > longer than 256 characters. You need to call the Unicode variant of the file APIs and add \\?\ to the start of the path in order to interact with paths longer than MAX_PATH. See http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath for details. -- Craig Peterson Scooter Software-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Proprietary vs Open Source mentality
On Sep 3, 2012, at 2:14 AM, Graeme Geldenhuys wrote: > I don't know who Uwe is, I just got to his website by following various links > on the internet. Is Uwe an Embarcadero employee? No, just a community member. In addition to the project you linked to he maintains the open source version of Delphi's Subversion Integration (Version Insight) and he's one of the two maintainers for the JEDI VCS project, as well as developer for the JCL/JVCL. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Proprietary vs Open Source mentality
I don't think it's an open source vs closed source mentality. It's quite possible that Uwe can't open source it; in the post you linked he even mentions that he used knowledge of the compiler internals to implement it. Andreas Hausladen's fix packs aren't open sourced either, and I know I've seen an Embarcadero developer mention that he has a "special arrangement", implying some sort of source level access. It's possible Uwe has something similar. I've seen the source to one of his unreleased projects and it completely bypassed the OpenTools API and poked around in a lot of IDE internals to do what it did. You're also overlooking the fact that his other project, Version Insight, is open source, but also has an optional closed source portion for similar low-level access. Maybe he just doesn't want such techniques to become common knowledge so Embarcadero doesn't have to try supporting it or so he doesn't have to spend his time answering questions about it. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Comments on rev 36091 / issue #21459
On May 2, 2012, at 7:08 PM, Paul Ishenin wrote: > Then the applied fix needs to be reimplemented. The need to show a non-modal > form on top of modal is needed even for LCL components - for TDateEdit and > TCalcEdit as they use forms for dropping down editors. Similar needs exists > in many other component sets. TDateEdit and TCalcEdit both worked correctly prior to the patch. TDateEdit is shown non-modally, but its PopupMode is pmAuto, which parents it to the modal form. Since it's owned by the modal form it works correctly, but stays on top. TCalcEdit just shows its form using ShowModal. The original bug reporter was asking for the ability to show a non-modal form while a modal form is active, with the ability for the non-modal form to go into the background. As far as I can tell, Carbon doesn't support that because SetWindowModality works program-wide. A possible solution would be to replace the calls to SetWindowModality in TCarbonWindow.ShowModal and CloseModal with a loop over all of the open forms to manually enable/disable them. I wouldn't recommend that as change to the official Lazarus distribution though, since it bypasses the OS-provided behavior and would probably have side effects. It wouldn't be hard to register a custom TCarbonWindow descendant in his application code to do that. Alternatively, he can just set PopupMode to pmAuto like TDataEdit and accept that the non-modal dialog will stay on top of the modal one. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] What is the most widely used Pascal on Linux and other Unix variants?
On 2/27/2012 4:21 PM, Graeme Geldenhuys wrote: > My point was more about the fact that Scooter Software has applied > there own fixes to CLX, and have also upgraded their Kylix 3 to use > Qt3 (instead of Qt 2.3 which came with Kylix). Actually, the upgrade to Qt 3 was Andreas Hausladen's doing, and he did release it, but it isn't available online anymore. It was an impressive piece of work, and I think it laid the groundwork for Lazarus' Qt support, since I remember seeing Zeljan's name associated with it too. We do have a shocking number of fixes on top of it though. > If they shared all there Kylix enhancements, I have no idea. No, we haven't. Borland screwed up the Kylix community project, and Andreas stopped maintaining the unofficial patches at the same time, so there isn't anywhere for us to share them. > So at least the framework around Kylix has grown, after is was > "considered" to be dead. It was "considered" dead, and then the Kylix community project and Borland's poor handling of Simon Kissel's cross-compiler killed it completely. > Also, Kylix 3 is still perfectly fine for web development work. I'm not aware of any Linux distro post-2006 that runs the IDE, and even then you needed a hack to debug threads. We would have given it up years ago, but I thought Delphi's cross-platform support would use Qt right up until they purchased VGScene. I'm sure there are a few other holdouts, but there's certainly no community anymore. Before they removed it, the .kylix newsgroup's last post was in 2008 or so. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Libc functions and types
On 1/17/2012 2:49 PM, Marco van de Voort wrote: > There is no Embarcadero Radstudio that supports Linux. In ancient times > there was Kylix, but it was buried. A part of it escaped, called unit libc, > but we finally caught up with it, and now it is dead and buried too. And now they have the Posix.* units which provide the same functionality in a more cross-platform manner. The original poster gave localtime_r as a specific example. It's part of the OpenGroup's Unix specification (in time.h), but FreePascal only exposes it in libc.pas. If you don't want people using that header you really should provide a better alternative than just making everyone redeclare everything in their own units. -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] OS X locale information (FormatSettings)
A new OS X Carbon Lazarus project doesn't fill the FormatSettings structure properly (using recent versions of Lazarus/FreePascal trunk). It appears the FreePascal sanctioned method to support that is to add clocale.pp to your project, but that only works when launched from the terminal, not from the dock or directly from Lazarus. I've attached the output from three variants below, to show the differences. I first noticed the issue because by default Lazarus uses '-' for the date separator, rather than '/', and adding clocale.pp clears the ThousandSeparator value. Is there a way to make clocale work correctly? If not, I think the correct approach would be to replace it with a new unit that queries CFLocaleGetValue instead. The "LongDateFormat" string also doesn't match the system in any of the approaches. According to my "Languages & Text" settings, it should be something like "January 5, 2011" or "Jan 5, 2011". On a related note, the AnsiString encoding isn't correct when launched from the dock either. It should be UTF-8, but defaults to ASCII, so extended characters are all converted to '?'. We've worked around the issue by overriding LC_CTYPE in our .app .plist file, but it seems like something that the environment should handle automatically. Default Lazarus project (no clocale.pp) CurrencyFormat: 1 NegCurrFormat: 5 ThousandSeparator: , DecimalSeparator: . CurrencyDecimals: 2 DateSeparator: - TimeSeparator: : ListSeparator: , CurrencyString: $ ShortDateFormat: d/m/y LongDateFormat: dd" "" " TimeAMString: AM TimePMString: PM ShortTimeFormat: hh:nn LongTimeFormat: hh:nn:ss ShortMonthNames: Jan, Feb, ... Nov, Dec, LongMonthNames: January, February, ... November, December, ShortDayNames: Sun, Mon, Tue, Wed, Thu, Fri, Sat, LongDayNames: Sunday, Monday, ... Friday, Saturday, TwoDigitYearCenturyWindow: 50 clocale.pp, run from Terminal CurrencyFormat: 0 NegCurrFormat: 1 ThousandSeparator: , DecimalSeparator: . CurrencyDecimals: 2 DateSeparator: / TimeSeparator: : ListSeparator: , CurrencyString: $ ShortDateFormat: mm/dd/ LongDateFormat: mm/dd/ TimeAMString: AM TimePMString: PM ShortTimeFormat: hh:nn:ss LongTimeFormat: hh:nn:ss ampm ShortMonthNames: Jan, Feb, ... Nov, Dec, LongMonthNames: January, February, ... November, December, ShortDayNames: Sun, Mon, Tue, Wed, Thu, Fri, Sat, LongDayNames: Sunday, Monday, ... Friday, Saturday, TwoDigitYearCenturyWindow: 50 clocale.pp, run from Lazarus CurrencyFormat: 1 NegCurrFormat: 5 ThousandSeparator: DecimalSeparator: . CurrencyDecimals: 127 DateSeparator: / TimeSeparator: : ListSeparator: , CurrencyString: ShortDateFormat: mm/dd/yy LongDateFormat: mm/dd/yy TimeAMString: AM TimePMString: PM ShortTimeFormat: hh:nn:ss LongTimeFormat: hh:nn:ss ampm ShortMonthNames: Jan, Feb, ... Nov, Dec, LongMonthNames: January, February, ... November, December, ShortDayNames: Sun, Mon, Tue, Wed, Thu, Fri, Sat, LongDayNames: Sunday, Monday, ... Friday, Saturday, TwoDigitYearCenturyWindow: 50 -- Craig Peterson Scooter Software -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
