Re: [Lazarus] Help System with Chromium Embedded component
On Tue, November 8, 2016 3:42 am, Michael Van Canneyt via Lazarus wrote: > I seriously doubt that. It's just something that will exist next to > javascript but in essence will perform the same tasks as javascript. You > can create relatively clean and structured javascript if you want. It just > requires discipline as the language doesn't enforce it. I start off by writing some javascript and I think, hey this isn't so bad. But eventually after about 10 paragraphs of code it starts to get ugly, no matter what I try. That's why there is a book written called "Javascript, the good parts" because it has become such a large mammoth that they needed to write a book about a subset of java that may (or may not) be the good parts. Whether those are the good parts or not, is still up for debate, because I haven't read the book. If I had time.. > > The problem is IMHO not so much the language, but what you do with it. > > Okay but take brainf*ck language as an example. In this case the language is in fact a serious problem. Or take C++. The language just encourages you to do nasty things when you need/want to. In order to write sensible looking C++ code you should... just use a subset of C++, such as C, and avoid most C++ features. But then you call in some library and they are using that feature, so, you have to use it too... the issue with javascript is you pull in a lot of libraries that make use of the features so you have to end up using them indirectly too. Again, I guess I should read the book "Javascript the good parts" if I have time. > > Well, there is interest in a WebAssembly backend for FPC. > Someone is looking at it. > Just as we are working on a transpiler from Pascal to Javascript. > That's good news, and I have no idea how you guys keep up with all this crap that comes out every year. The work required to port fpc to all these systems, whether virtual machines, or real machines, is enormous. What ever happened to LLVM ? much interest? Yet another port to a virtual machine. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Tue, November 8, 2016 9:36 am, Werner Pamler via Lazarus wrote: > Am 08.11.2016 um 15:56 schrieb Martok via Lazarus: > >> Hi, >> >> >> I may have missed this point in the discussion, but would it not make >> more sense to get a native HTML component (either from IPro or the THTML >> port) to the point where it can provide everything needed? ... > +1 Well the reason chromium is in my line of sight, is because other people do the work to maintain the browser for you. Creating your own web browser component is massive amounts of work, whereas chromium is coded by other people. True you have to write wrappers around it, but you also end up with a standard component where there are already plenty of c++ examples to learn from, and you are supported by a massive team over at chromium. Whereas writing your own browser component requires constantly playing "catch up", implementing every feature needed which chromium had 5 years ago. So does IPro or THtml have any large following and existing codebase to work with? I would have to learn about these as I have not used them. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Tue, November 8, 2016 3:19 am, Graeme Geldenhuys via Lazarus wrote: > On 2016-11-08 02:51, Lars via Lazarus wrote: > >> It's sort of like a JVM bytecode, but for the web browser. >> > > That makes you wonder, why not simply go back to Java Applets. One issue, back in the day, was that you could only use Java programming language, right? At that time no one had thought of multi language jvm targetting with different originating languages... all java applets were java programming language coded, afaik... I could be wrong. Another issue with java applets is you had to make sure they were installed correctly, whereas javascript need not install. With webassembly I don't think there is a java system you have to install on the machine. Java applets required first downloading the JVM from Sun, right? It's been so long since I've seen a java craplet (that's the locker room talk name for it) that I cannot remember. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Tue, November 8, 2016 3:49 am, Michael Schnell via Lazarus wrote: > On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: > >> >> I seriously doubt that. It's just something that will exist next to >> javascript but in essence will perform the same tasks as javascript. > ==OFF TOPIC== (so ignore if there is not a very short answer) > > > Any plans for a webassembly support with FPC ? > > There is an old thread about it here: http://forum.lazarus.freepascal.org/index.php/topic,28836.0.html Many skeptics, but many think it is an interesting idea even though skeptical. And what happened to microsoft silverlight? did anyone care? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Version
On Tue, 8 Nov 2016 21:45:16 +0100 (CET) Michael Van Canneytwrote: > packagename_version.p(p|pas) Ok. Although if we make it configurable, we can use it for lclversion.pas as well. >[...] > [x] Generate unit with version number Ok. Needs update when saving the package. > [x] Generate version numbers for all used packages Ok. Needs update when compiling the package. So the IDE and lazbuild can do that. fpmake cannot. > Then > > unit a_version; > > interface >AVersionStr = '1.2.3'; >BversionStr = '2.3.4'; To make compare operations simple I suggest to use the lclversion scheme: const lcl_major = 1; lcl_minor = 7; lcl_release = 0; lcl_patch = 0; lcl_fullversion = ((lcl_major * 100 + lcl_minor) * 100 + lcl_release) * 100 + lcl_patch; lcl_version = '1.7'; > implementation > > end. > > Or somesuch... Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus Version
On 08/11/16 16:30, Mattias Gaertner via Lazarus wrote: On Tue, 8 Nov 2016 15:20:22 +Mark Morgan Lloyd via Lazaruswrote: On 08/11/16 13:30, Mattias Gaertner via Lazarus wrote:> > On Tue, 8 Nov 2016 13:08:41 +0100 (CET)Michael Van Canneyt wrote: > >> [...]> I'm not sure we're talking about the same thing. I don't know what 'version> unit' you mean ? > > For example lazarus/lcl/lclversion.pas > > I don't want to hijack anybody else's thread, but I habitually use that > file to get version info so that I can always find out what compiler > etc. has been used to build a binary. How does lclversion tell you the used compiler? I said compiler /etc./ lazV= 'Lazarus IDE v' + (*$I version.inc *) ; lclV= 'Lazarus Class Library v' + lcl_version; fpcV= 'Free Pascal v' + (*$I %FPCVERSION% *) ; fpcC= ' for ' + (*$I %FPCTARGETCPU% *) ; fpcO= (*$I %FPCTARGETOS% *) ; ..and much other stuff, almost all captured at build although in some cases post-processed. The one downside of this is that I > end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the > entire LCL being rebuilt more often than is strictly necessary. Alternative: add lclbase as requirement in the project inspector. Thanks, I'll try that. Is there an easy way to get the version.inc file without specifying an absolute path? At the moment I'm using -Fi (or rather, the equivalent in the paths dialogue). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Anchoring fails on Windows 10
Am 2016-11-08 um 16:47 schrieb Mattias Gaertner via Lazarus: On Tue, 8 Nov 2016 14:59:45 +0100 Jürgen Hestermann via Lazaruswrote: I have a simple form with 2 components, a TVirtualDrawTree and a TProgressBar. The TProgressBar is anchored to the bottom of the form and the bottom of the TVirtualDrawTree is anchored to the top of the TProgressBar. This works okay on Windows 7 and 8.1 but not on Windows 10! When I resize the form by moving down the bottom border or by making it full size then the position of the TProgressBar within the form stays where it was and is not moved to the bottom of the form. Anybody else having such issues on Windows 10? I tested with a TTreeView and a TProgressBar and it works here with Laz 1.7 at design time and run time. On Windows 10? I am using Lazarus 1.6. Where there changes in 1.7? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
Am 08.11.2016 um 15:56 schrieb Martok via Lazarus: Hi, I may have missed this point in the discussion, but would it not make more sense to get a native HTML component (either from IPro or the THTML port) to the point where it can provide everything needed? THTML (my favourite) already has fairly solid layout and CSS support, so it should provide most things that are required. What it does miss is proper DOM access and manipulation, but I'd rather see efforts focused there than on CEF, which would require the same work to wrap it on the pascal side anyway... Depending on the scenario, we might get away without any Javascript support by using PascalScript, iff there would be some interface between DOM and the host application. Certainly doing that would result in lots of reusable code for completely different applications. +1 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] ctrl-c code completion
On 2016-11-08 13:14, Mattias Gaertner via Lazarus wrote: > In this case codetools don't have enough information. Because it does > not know the former connection. By why does it work if I do them one at a time. eg: Change the first interface declaration and do code completion. Change the second interface declaration and do code completion. That works. But doing them at the same time it doesn't. So in the first case, CodeTools somehow knows the connection, even though the interface and implementation declarations don't match (until code completion is invoked). It then magically knows which implementation declaration to update. So why would CodeTools not know the connection when both interface declarations are updated at the same time? I don't know how CodeTools works, but I would imagine it has some memory lookup (line numbers) where interface declaration xyz has an implementation at line 123. So when the declaration xyz changes (by the developer), go to line 123 and change it there too? Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] ctrl-c code completion
On Tue, 8 Nov 2016 13:00:44 + Graeme Geldenhuys via Lazaruswrote: >[...] > I can confirm, I've seen this quite a few times recently too. > > Not sure if this is related: > Another way to reproduce this is to change the parameters of two > overloaded methods and then do Ctrl+Shift+C to class complete (update > their implementation signatures). Instead of updating the existing > methods, it defines new ones. In this case codetools don't have enough information. Because it does not know the former connection. It only sees two declarations without bodies and two bodies without declarations. It can't know for sure which belong together. The non-interactive-code-completion should stop with an error. The interactive can ask. Please create a report. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] ctrl-c code completion
On Tue, 8 Nov 2016 13:10:40 +0100 (CET) Michael Van Canneyt via Lazaruswrote: > On Tue, 8 Nov 2016, Mattias Gaertner via Lazarus wrote: > > > On Sun, 6 Nov 2016 18:05:39 +0100 (CET) > > Michael Van Canneyt via Lazarus wrote: > > > >> [...] > >> - Function to function, > >> > >> - Procedure to procedure > >> > >> - and the setter in > >> > >>property Values[const Name: string]: string read GetValue write > >> SetValue; > >> > >>is changed from > >> > >>procedure SetValue(const Name, Value: string); > >> > >>to > >> > >>procedure SetValue(const Name : string; Const Value: string); > >> > >>Causing the compiler to generate an error... > > > > Why does that cause a compiler error? > > Because both procedures remained in the sources. > > Open classes unit, press code completion shortcut while in TStrings (or was > it TStringlist?), and observe the effect... I noticed this while fixing a bug > report. Please create a bug report. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Tue, 8 Nov 2016, Michael Schnell via Lazarus wrote: On 08.11.2016 11:42, Michael Van Canneyt via Lazarus wrote: I seriously doubt that. It's just something that will exist next to javascript but in essence will perform the same tasks as javascript. ==OFF TOPIC== (so ignore if there is not a very short answer) Any plans for a webassembly support with FPC ? I wrote it in the email you are replying to. Please re-read. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] CCR, how to send files?
On Fri, 28 Oct 2016 11:58:31 +0300 Alexey via Lazaruswrote: > Hi > I try to send mail to Vincent S, he is unreachable, mail cannot send. > How to send my files to CCR? Has Vincent answered in the meantime? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On Mon, 7 Nov 2016, Lars via Lazarus wrote: On Mon, November 7, 2016 12:25 pm, vfclists . via Lazarus wrote: I mean the latest thing now is WebAssembly which shows how ridiculous the whole business has become. Web assembly, if designed properly, might actually get rid of some problems. Javascript is a large mammoth, or ugly beast. Web assembly may allow one to for example compile freepascal code directly to byte code that runs in the browser, instead of people using ugly obfuscated bloated javascript "hacks". It's sort of like a JVM bytecode, but for the web browser. Or a .net bytecode. I don't fully know what web assembly intends to be, as it's not completed yet fully, but, it may actually get rid of some of the javascript bloated crap out there. I seriously doubt that. It's just something that will exist next to javascript but in essence will perform the same tasks as javascript. You can create relatively clean and structured javascript if you want. It just requires discipline as the language doesn't enforce it. The problem is IMHO not so much the language, but what you do with it. Lots of people may in fact ignore webassembly and continue to use javascript. God forbid. Well, there is interest in a WebAssembly backend for FPC. Someone is looking at it. Just as we are working on a transpiler from Pascal to Javascript. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-08 02:51, Lars via Lazarus wrote: > It's sort of like a JVM bytecode, but for the web browser. That makes you wonder, why not simply go back to Java Applets. They came out in 1996 and I thought they were brilliant for web applications. You had the full power of the Java language and graphics stack at your disposal. Yes there was phase when Java had some security issues, but those were resolved, and any future security issues could be resolved just as easily. I simply don't understand why they must always try and reinvent the wheel, when they could simply fix or improve the wheel. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help System with Chromium Embedded component
On 2016-11-08 02:31, Lars via Lazarus wrote: > One issue is firefox has a track record of not supporting embedded browser > for very long without abandoning it, or changing the api to make it > incompatible with old code... so who says this isn't also going to happen > with chromium (CEF) at some point... My point is, for a help system you really don't need the latest and greatest HTML5 features. It's simply not needed. What you do want in well formatted text, images and some basic rich text styles. Good help is more about the contents and the speed of getting to that contents, that about the presentation. But some people are more obsessed about presentation with rubbish or near zero content. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] ctrl-c code completion
On 11/8/16, Lars via Lazaruswrote: > On Sun, November 6, 2016 10:05 am, Michael Van Canneyt via Lazarus wrote: >> >> press ctrl-c to do command-completion > > If ctrl - c is for copying, how does this not interfere? It is Shift+Ctrl+C by default. Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus