Re: [Lazarus] Help System with Chromium Embedded component

2016-11-08 Thread Lars via Lazarus
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

2016-11-08 Thread Lars via Lazarus
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

2016-11-08 Thread Lars via Lazarus
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

2016-11-08 Thread Lars via Lazarus
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

2016-11-08 Thread Mattias Gaertner via Lazarus
On Tue, 8 Nov 2016 21:45:16 +0100 (CET)
Michael Van Canneyt  wrote:

> 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

2016-11-08 Thread Mark Morgan Lloyd via Lazarus

On 08/11/16 16:30, Mattias Gaertner via Lazarus wrote:

On Tue, 8 Nov 2016 15:20:22 +Mark Morgan Lloyd via Lazarus 
 wrote:

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

2016-11-08 Thread Jürgen Hestermann via Lazarus

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 Lazarus  wrote:


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

2016-11-08 Thread Werner Pamler via Lazarus

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

2016-11-08 Thread Graeme Geldenhuys via Lazarus
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

2016-11-08 Thread Mattias Gaertner via Lazarus
On Tue, 8 Nov 2016 13:00:44 +
Graeme Geldenhuys via Lazarus  wrote:

>[...]
> 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

2016-11-08 Thread Mattias Gaertner via Lazarus
On Tue, 8 Nov 2016 13:10:40 +0100 (CET)
Michael Van Canneyt via Lazarus  wrote:

> 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

2016-11-08 Thread Michael Van Canneyt via Lazarus



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?

2016-11-08 Thread Mattias Gaertner via Lazarus
On Fri, 28 Oct 2016 11:58:31 +0300
Alexey via Lazarus  wrote:

> 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

2016-11-08 Thread Michael Van Canneyt via Lazarus



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

2016-11-08 Thread Graeme Geldenhuys via Lazarus
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

2016-11-08 Thread Graeme Geldenhuys via Lazarus
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

2016-11-08 Thread Bart via Lazarus
On 11/8/16, Lars via Lazarus  wrote:

> 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