subject:"\[Lazarus\] The future of desktop"

I've said what I had to say.  I tried to point to a potential new avenue to
increase the Lazarus/FPC community and possible contributors, both code and
financial.  If the suggestion isn't welcome then so be it.

On Wed, Dec 4, 2013 at 11:06 PM, Florian Klaempfl wrote:

> Am 04.12.2013 21:48, schrieb Avishai:
>
>  Really?  I thought it started fro Megido.
>>
>
> And? Then the same would apply to Megido.
>
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>

-- 
Shalom,
Avishai
avishai.g...@gmail.com
אבישי גוֹר
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Florian Klaempfl


Am 04.12.2013 21:31, schrieb Avishai:

The guys that started Lazarus had a base to start from.  They didn't
start from scratch.  They already had the basic code to do a lot of
things and it worked.  But it only worked for LeftToRight.

If Lazarus could address even a few of the major issues, I think it
would become the dominant programming tool of the Middle East. I thing
that's significant.


No. Significant are the contributors.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Florian Klaempfl


Am 04.12.2013 21:48, schrieb Avishai:

Really?  I thought it started fro Megido.


And? Then the same would apply to Megido.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Sven Barth


On 04.12.2013 21:48, Avishai wrote:

Really?  I thought it started fro Megido.


On Wed, Dec 4, 2013 at 10:44 PM, Avishai mailto:avishai.g...@gmail.com>> wrote:

@vfclists.  I agree with what you said.  I have the knowledge about
the requirements of RightToLeft applications, but I don't have the
programming skills to make it happen.  My suspicion is that the
great majority of Lazarus/FPC users are not proficient enough to dig
down into the low level code and figure out how to fix problems.  I
know for fact that I am not.  That doesn't keep me from trying
though.  I've been looking for that TWinControl Canvas bug for 2
years and I'm no closer today than the day I started.

But Mirroring technology is the simplest and most straightforward
approach to RightToLeft on the MSWindows platform.  For the most
part it already works, but only if you disable Themes.  That's a
price most programmer feel they can't pay.


Is it just me or am I only receiving half of the discussion? O.o

Regards,
Sven


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

Really?  I thought it started fro Megido.


On Wed, Dec 4, 2013 at 10:44 PM, Avishai  wrote:

> @vfclists.  I agree with what you said.  I have the knowledge about the
> requirements of RightToLeft applications, but I don't have the programming
> skills to make it happen.  My suspicion is that the great majority of
> Lazarus/FPC users are not proficient enough to dig down into the low level
> code and figure out how to fix problems.  I know for fact that I am not.
>  That doesn't keep me from trying though.  I've been looking for that
> TWinControl Canvas bug for 2 years and I'm no closer today than the day I
> started.
>
> But Mirroring technology is the simplest and most straightforward approach
> to RightToLeft on the MSWindows platform.  For the most part it already
> works, but only if you disable Themes.  That's a price most programmer feel
> they can't pay.
>
>
>
> On Wed, Dec 4, 2013 at 10:31 PM, Avishai  wrote:
>
>> The guys that started Lazarus had a base to start from.  They didn't
>> start from scratch.  They already had the basic code to do a lot of things
>> and it worked.  But it only worked for LeftToRight.
>>
>> If Lazarus could address even a few of the major issues, I think it would
>> become the dominant programming tool of the Middle East. I thing that's
>> significant.
>>
>>
>> On Wed, Dec 4, 2013 at 10:20 PM, Florian Klämpfl 
>> wrote:
>>
>>> Am 04.12.2013 21:08, schrieb Avishai:
>>> > There's very little interest because it simply can't do the job.  If
>>> > you're looking to buy a new car, you don't stop at a motorcycle shop.
>>> >  If Lazarus could overcome just a few of the major obstacles I think
>>> > there would be RightToLeft people that would make the effort to create
>>> a
>>> > great RightToLeft tool.
>>>
>>> If the guys who started lazarus, would have thought the same, there
>>> would be no lazarus at all. If an OSS tool misses a certain feature,
>>> then there is simply not enough interest, else somebody who needs it,
>>> would implement it. Period.
>>>
>>>
>>> --
>>> ___
>>> Lazarus mailing list
>>> Lazarus@lists.lazarus.freepascal.org
>>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>>>
>>
>>
>>
>> --
>> Shalom,
>> Avishai
>> avishai.g...@gmail.com
>> אבישי גוֹר
>>
>
>
>
> --
> Shalom,
> Avishai
> avishai.g...@gmail.com
> אבישי גוֹר
>



-- 
Shalom,
Avishai
avishai.g...@gmail.com
אבישי גוֹר
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

@vfclists.  I agree with what you said.  I have the knowledge about the
requirements of RightToLeft applications, but I don't have the programming
skills to make it happen.  My suspicion is that the great majority of
Lazarus/FPC users are not proficient enough to dig down into the low level
code and figure out how to fix problems.  I know for fact that I am not.
 That doesn't keep me from trying though.  I've been looking for that
TWinControl Canvas bug for 2 years and I'm no closer today than the day I
started.

But Mirroring technology is the simplest and most straightforward approach
to RightToLeft on the MSWindows platform.  For the most part it already
works, but only if you disable Themes.  That's a price most programmer feel
they can't pay.

On Wed, Dec 4, 2013 at 10:31 PM, Avishai  wrote:

> The guys that started Lazarus had a base to start from.  They didn't start
> from scratch.  They already had the basic code to do a lot of things and it
> worked.  But it only worked for LeftToRight.
>
> If Lazarus could address even a few of the major issues, I think it would
> become the dominant programming tool of the Middle East. I thing that's
> significant.
>
>
> On Wed, Dec 4, 2013 at 10:20 PM, Florian Klämpfl 
> wrote:
>
>> Am 04.12.2013 21:08, schrieb Avishai:
>> > There's very little interest because it simply can't do the job.  If
>> > you're looking to buy a new car, you don't stop at a motorcycle shop.
>> >  If Lazarus could overcome just a few of the major obstacles I think
>> > there would be RightToLeft people that would make the effort to create a
>> > great RightToLeft tool.
>>
>> If the guys who started lazarus, would have thought the same, there
>> would be no lazarus at all. If an OSS tool misses a certain feature,
>> then there is simply not enough interest, else somebody who needs it,
>> would implement it. Period.
>>
>>
>> --
>> ___
>> Lazarus mailing list
>> Lazarus@lists.lazarus.freepascal.org
>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>>
>
>
>
> --
> Shalom,
> Avishai
> avishai.g...@gmail.com
> אבישי גוֹר
>

-- 
Shalom,
Avishai
avishai.g...@gmail.com
אבישי גוֹר
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Sven Barth


On 04.12.2013 21:31, Avishai wrote:

The guys that started Lazarus had a base to start from.  They didn't
start from scratch.  They already had the basic code to do a lot of
things and it worked.  But it only worked for LeftToRight.


They *did* start from scratch, because there was *no* code to achieve 
what Lazarus has done: implement a clone of the VCL in a platform 
independant way.



If Lazarus could address even a few of the major issues, I think it
would become the dominant programming tool of the Middle East. I thing
that's significant.


I know it sounds harsh, but: patches are accepted. In Open Source one 
mostly investigates in problems that oneself is interested in. Afterall 
most developers are working on such projects in their free time. So if 
you want something implemented then either implement it yourself or find 
someone else to implement it for you (e.g. by putting up a bounty or by 
finding some kind soul that would implement it).


Regards,
Sven

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

The guys that started Lazarus had a base to start from.  They didn't start
from scratch.  They already had the basic code to do a lot of things and it
worked.  But it only worked for LeftToRight.

If Lazarus could address even a few of the major issues, I think it would
become the dominant programming tool of the Middle East. I thing that's
significant.

On Wed, Dec 4, 2013 at 10:20 PM, Florian Klämpfl wrote:

> Am 04.12.2013 21:08, schrieb Avishai:
> > There's very little interest because it simply can't do the job.  If
> > you're looking to buy a new car, you don't stop at a motorcycle shop.
> >  If Lazarus could overcome just a few of the major obstacles I think
> > there would be RightToLeft people that would make the effort to create a
> > great RightToLeft tool.
>
> If the guys who started lazarus, would have thought the same, there
> would be no lazarus at all. If an OSS tool misses a certain feature,
> then there is simply not enough interest, else somebody who needs it,
> would implement it. Period.
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>

-- 
Shalom,
Avishai
avishai.g...@gmail.com
אבישי גוֹר
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread vfclists .

On 4 December 2013 20:20, Florian Klämpfl  wrote:

> Am 04.12.2013 21:08, schrieb Avishai:
> > There's very little interest because it simply can't do the job.  If
> > you're looking to buy a new car, you don't stop at a motorcycle shop.
> >  If Lazarus could overcome just a few of the major obstacles I think
> > there would be RightToLeft people that would make the effort to create a
> > great RightToLeft tool.
>
> If the guys who started lazarus, would have thought the same, there
> would be no lazarus at all. If an OSS tool misses a certain feature,
> then there is simply not enough interest, else somebody who needs it,
> would implement it. Period.
>
>
> --
>

I think the problem is more of an issue of newcomers confidence that they
can dive into the codebase and start tackling stuff, or at least they can
find someone to guide them if they want to. Systems programming is not an
easy area to get involved with and there are many developers who have never
had to get anywhere close to that kind of programming. It all looks rather
daunting for those who may not be so proficient at Pascal or experienced in
low level programming

-- 
Frank Church

===
http://devblog.brahmancreations.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Florian Klämpfl

Am 04.12.2013 21:08, schrieb Avishai:
> There's very little interest because it simply can't do the job.  If
> you're looking to buy a new car, you don't stop at a motorcycle shop.
>  If Lazarus could overcome just a few of the major obstacles I think
> there would be RightToLeft people that would make the effort to create a
> great RightToLeft tool.

If the guys who started lazarus, would have thought the same, there
would be no lazarus at all. If an OSS tool misses a certain feature,
then there is simply not enough interest, else somebody who needs it,
would implement it. Period.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

There's very little interest because it simply can't do the job.  If you're
looking to buy a new car, you don't stop at a motorcycle shop.  If Lazarus
could overcome just a few of the major obstacles I think there would be
RightToLeft people that would make the effort to create a great RightToLeft
tool.

As it stands right now, if you mirror any TWinControl (like the Forms) to
make it RightToLeft it corrupts the canvas and makes it unusable.  At that
point, you close Lazarus, and delete it from your system and continue
looking for a development tool that can do what you need.  Bottom line,
very little interest.

Delphi doesn't have this problem.  You can make true RightToLeft
applications that work very well with very little effort.  But Delphi is
expensive and in many respects it is inferior to Lazarus.

On Wed, Dec 4, 2013 at 9:38 PM, Florian Klämpfl wrote:

> Am 04.12.2013 15:49, schrieb Avishai:
> > Everything I say here is my opinion only and related to MSWindows only
> > because I do not have another OS to work with.  I think Lazarus could
> grow
> > quite a bit and maybe find some deep pockets, if it would address the
> > problems of RightToLeft language support.  There are a few billion people
> > that must deal with the RightToLeft world.
>
> If there was a significant interested, I'am sure somebody using
> RightToLeft would have addressed these problems.
>
> > But with Lazarus's RightToLeft
> > limitations, programmers take one look and move on to something with
> better
> > support.  At the moment, on MSWindows, you can not produce a true
> > RightToLeft application with Lazarus.
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>

-- 
Shalom,
Avishai
avishai.g...@gmail.com
אבישי גוֹר
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Florian Klämpfl

Am 04.12.2013 15:49, schrieb Avishai:
> Everything I say here is my opinion only and related to MSWindows only
> because I do not have another OS to work with.  I think Lazarus could grow
> quite a bit and maybe find some deep pockets, if it would address the
> problems of RightToLeft language support.  There are a few billion people
> that must deal with the RightToLeft world. 

If there was a significant interested, I'am sure somebody using
RightToLeft would have addressed these problems.

> But with Lazarus's RightToLeft
> limitations, programmers take one look and move on to something with better
> support.  At the moment, on MSWindows, you can not produce a true
> RightToLeft application with Lazarus.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

Everything I say here is my opinion only and related to MSWindows only
because I do not have another OS to work with.  I think Lazarus could grow
quite a bit and maybe find some deep pockets, if it would address the
problems of RightToLeft language support.  There are a few billion people
that must deal with the RightToLeft world.  But with Lazarus's RightToLeft
limitations, programmers take one look and move on to something with better
support.  At the moment, on MSWindows, you can not produce a true
RightToLeft application with Lazarus.



--
View this message in context: 
http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-The-future-of-desktop-tp4034532p4034656.html
Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Mark Morgan Lloyd


Lukasz Sokol wrote:


Considering Mac OS: were they ever away?

Regards, Sven


Well spotted :) I never had one...

Me neither, but it's one of the things I know about Mac OS (X).


I think that all this thread about the history of GUI and who copied
whom is going a little too far, and too much off topic ;-)



No I beg to differ: even if word :Lazarus: just because isn't mentioned in 
every other post here,
doesn't mean that it is too off topic yet. 


I'd suggest migrating to the -other topic.

--
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.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Junior


Em 04-12-2013 10:07, Lukasz Sokol escreveu:

On 04/12/13 11:29, Santiago A. wrote:

El 04/12/2013 11:50, Sven Barth escribió:

Am 04.12.2013 09:40 schrieb "Lukasz Sokol" mailto:el.es...@gmail.com>>:

On 03/12/13 12:42, Sven Barth wrote:

Am 03.12.2013 10:26 schrieb "Lukasz Sokol" mailto:el.es...@gmail.com> >>:

And the [GEM/DR/?] idea of menus on top of screen also makes
a come back in Ubuntu... and IIRC Gnome3.

Considering Mac OS: were they ever away?

Regards, Sven


Well spotted :) I never had one...

Me neither, but it's one of the things I know about Mac OS (X).


I think that all this thread about the history of GUI and who copied
whom is going a little too far, and too much off topic ;-)




+1

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Lukasz Sokol

On 04/12/13 11:29, Santiago A. wrote:
> El 04/12/2013 11:50, Sven Barth escribió:
>> 
>> Am 04.12.2013 09:40 schrieb "Lukasz Sokol" > >:
>>> 
>>> On 03/12/13 12:42, Sven Barth wrote:
 Am 03.12.2013 10:26 schrieb "Lukasz Sokol" >>>  >>:
> And the [GEM/DR/?] idea of menus on top of screen also makes
> a come back in Ubuntu... and IIRC Gnome3.
 
 Considering Mac OS: were they ever away?
 
 Regards, Sven
 
>>> Well spotted :) I never had one...
>> 
>> Me neither, but it's one of the things I know about Mac OS (X).
>> 
> 
> I think that all this thread about the history of GUI and who copied
> whom is going a little too far, and too much off topic ;-)
> 

No I beg to differ: even if word :Lazarus: just because isn't mentioned in 
every other post here,
doesn't mean that it is too off topic yet. 

Oh there, I mentioned Lazarus. Again. :)

> -- Saludos
> 
> Santiago A. s...@ciberpiula.net
> 
-L.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Santiago A.

El 04/12/2013 11:50, Sven Barth escribió:
>
> Am 04.12.2013 09:40 schrieb "Lukasz Sokol"  >:
> >
> > On 03/12/13 12:42, Sven Barth wrote:
> > > Am 03.12.2013 10:26 schrieb "Lukasz Sokol"    >>:
> > >> And the [GEM/DR/?] idea of menus on top of screen also makes a
> come back in Ubuntu...
> > >> and IIRC Gnome3.
> > >
> > > Considering Mac OS: were they ever away?
> > >
> > > Regards,
> > > Sven
> > >
> > Well spotted :) I never had one...
>
> Me neither, but it's one of the things I know about Mac OS (X).
>

I think that all this thread about the history of GUI and who copied
whom is going a little too far, and too much off topic ;-)

-- 
Saludos

Santiago A.
s...@ciberpiula.net

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Sven Barth

Am 04.12.2013 09:40 schrieb "Lukasz Sokol" :
>
> On 03/12/13 12:42, Sven Barth wrote:
> > Am 03.12.2013 10:26 schrieb "Lukasz Sokol" >:
> >> And the [GEM/DR/?] idea of menus on top of screen also makes a come
back in Ubuntu...
> >> and IIRC Gnome3.
> >
> > Considering Mac OS: were they ever away?
> >
> > Regards,
> > Sven
> >
> Well spotted :) I never had one...

Me neither, but it's one of the things I know about Mac OS (X).

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-04 Thread Lukasz Sokol

On 03/12/13 12:42, Sven Barth wrote:
> Am 03.12.2013 10:26 schrieb "Lukasz Sokol"  >:
>> And the [GEM/DR/?] idea of menus on top of screen also makes a come back in 
>> Ubuntu...
>> and IIRC Gnome3.
> 
> Considering Mac OS: were they ever away?
> 
> Regards,
> Sven
> 
Well spotted :) I never had one...

-L.



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread Hans-Peter Diettrich


Kostas Michalopoulos schrieb:

On Mon, Dec 2, 2013 at 9:55 PM, Hans-Peter Diettrich
 wrote:

Right, but it was the first desktop presented by Microsoft.



No it wasn't. GEM was presented by Digital Research, Microsoft had
nothing to do with it.


At least it was the first desktop I saw in our company on an IBM-PC. It 
came very close to my Atari desktop, but turned out to be crippled to 
allow only for 4 windows, and more crap. I may be misleaded in so far, 
as it might be presented by DRI even on an PC? [I only saw it running on 
one of our desktops]



I'm not sure what GEM has to do with multitasking.



You said that they were technically similar, which isn't the case.
Multitasking was an example of a major technical difference they had.


As the acronym GEM says, it's a Graphical Environment Manager, which 
e.g. on my Atari ST was installed on top of TOS. Multitasking is a 
feature of the underlying OS, not of GEM.




I don't see a need for an special Windows compiler. The only requirement is
a linker that links the resources into the executable. This was a separate
program for a long time, in addition to the compiler and linker.



Windows (Win16) executables are a different format and while a linker
*could* do it, a windows-aware compiler is still needed. The Win16
calling convention is (was) different to whatever DOS compilers used
(usually compilers used their own). Windows was doing software-based
virtual memory management and would unload parts of the program by
unloading functions and patching the memory where the function was
make a system call for loading them back (so running code that tried
to call the function would continue to work). The compiler had to know
about that do make proper prologs and epilogs. Also AFAIK callbacks
required special handling too.


Okay, that's the same for every platform, not Windows specific. Every 
platform has its own ABI and object file format, which must be supported 
by every compiler for that platform. See also the --target etc. switches 
of FPC.



Some notes are given in
http://www.openwatcom.org/index.php/Exploring_Windows_3.x but that is
mostly Win3.x specific. There some notes about Windows 1.0 and Windows
2.0 in Raymond Chen's "the old new thing" blog, but i can't find
specifics right now.


Windows 3.0 turned out to be the first released and usable desktop 
version for our portable PCs (from GRiD). At that time we also used a 
(beta) version of the Borland C development system on Win3.0, which 
became our new development environment after GW-Basic. I also assisted 
in the development of an Atari version of BC, and there I wrote a window 
library that allowed (to some degree) to run Windows code on GEM. From 
that experiment I remember some of the fundamental differences between 
GEM and Windows.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread waldo kitty


On 12/3/2013 3:48 AM, Michael Schnell wrote:

(or did you just stumble at the capitals and blanks ? )


yes, exactly and thus why i asked for clarification since they changed the 
meaning considerably ;)


--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread Kostas Michalopoulos

On Mon, Dec 2, 2013 at 9:55 PM, Hans-Peter Diettrich
 wrote:
>
> Right, but it was the first desktop presented by Microsoft.
>

No it wasn't. GEM was presented by Digital Research, Microsoft had
nothing to do with it.

>
> I'm not sure what GEM has to do with multitasking.
>

You said that they were technically similar, which isn't the case.
Multitasking was an example of a major technical difference they had.

>
> I don't see a need for an special Windows compiler. The only requirement is
> a linker that links the resources into the executable. This was a separate
> program for a long time, in addition to the compiler and linker.
>

Windows (Win16) executables are a different format and while a linker
*could* do it, a windows-aware compiler is still needed. The Win16
calling convention is (was) different to whatever DOS compilers used
(usually compilers used their own). Windows was doing software-based
virtual memory management and would unload parts of the program by
unloading functions and patching the memory where the function was
make a system call for loading them back (so running code that tried
to call the function would continue to work). The compiler had to know
about that do make proper prologs and epilogs. Also AFAIK callbacks
required special handling too.

Some notes are given in
http://www.openwatcom.org/index.php/Exploring_Windows_3.x but that is
mostly Win3.x specific. There some notes about Windows 1.0 and Windows
2.0 in Raymond Chen's "the old new thing" blog, but i can't find
specifics right now.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread Sven Barth

Am 03.12.2013 10:26 schrieb "Lukasz Sokol" :
> And the [GEM/DR/?] idea of menus on top of screen also makes a come back
in Ubuntu...
> and IIRC Gnome3.

Considering Mac OS: were they ever away?

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread Danny Weldon

> That history has gone full-circle, and the NEW DESKTOP APPS (for Windows 8 
> Metro) are
> predominantly full screen...

And the metro look itself with the buttons as a plain flat
rectangle are like they are from Windows 1.0  Very ugly IMHO.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread Lukasz Sokol

On 02/12/13 20:55, Hans-Peter Diettrich wrote:
> Kostas Michalopoulos schrieb:
>> Actually, Microsoft has nothing to do with GEM, it was made by
>> Digital Research.
> 
> Right, but it was the first desktop presented by Microsoft.
> 
>> Also technically GEM is/was very different from Windows (GEM relies
>> on interrupts and can run only a single program while Windows was
>> multitasking from the start,
> 
> I'm not sure what GEM has to do with multitasking.

That history has gone full-circle, and the NEW DESKTOP APPS (for Windows 8 
Metro) are
predominantly full screen...

And the [GEM/DR/?] idea of menus on top of screen also makes a come back in 
Ubuntu...
and IIRC Gnome3.

[...]

> 
> DoDi
> 
-L.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-03 Thread Michael Schnell


On 12/02/2013 06:43 PM, waldo kitty wrote:

On 12/2/2013 4:06 AM, Michael Schnell wrote:
If your effort allows for compiling pascal to Java Script this might 
be even


do you mean "java" or "javascript" above? ;)


Michael v.C. said:
"That is exactly my plan: 1. Convert pascal to javascript"

(or did you just stumble at the capitals and blanks ? )

-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Hans-Peter Diettrich


Kostas Michalopoulos schrieb:

Actually, Microsoft has nothing to do with GEM, it was made by Digital
Research.


Right, but it was the first desktop presented by Microsoft.


Also technically GEM is/was very different from Windows (GEM
relies on interrupts and can run only a single program while Windows
was multitasking from the start,


I'm not sure what GEM has to do with multitasking.


GEM apps can be made by any DOS
compiler that can issue interrupts and has the necessary header files,
Windows apps require special compilers, etc).


I don't see a need for an special Windows compiler. The only requirement 
is a linker that links the resources into the executable. This was a 
separate program for a long time, in addition to the compiler and linker.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Dmitry Boyarintsev

We need a desktop development history page on the wiki.
It is not FPC or Lazarus related, but something that's interesting to read
for a developer :)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Kostas Michalopoulos

Actually, Microsoft has nothing to do with GEM, it was made by Digital
Research. Also technically GEM is/was very different from Windows (GEM
relies on interrupts and can run only a single program while Windows
was multitasking from the start, GEM apps can be made by any DOS
compiler that can issue interrupts and has the necessary header files,
Windows apps require special compilers, etc). You can check FreeGEM
for an up to date version (the source code of GEM was released a while
ago and some people fixed bugs and added a few features).

Both Microsoft and Digital Research were sued by Apple when their
systems were released. DR decided to modify their 'desktop' program to
disallow overlapping windows and removed the trash can (previously it
looked very similar to Mac Finder) while Microsoft decided to counter
Apple's claim. In fact Windows 2 was even more like Mac (overlapping
windows vs Windows 1's tiled windows, more Mac-like colors, etc) and
AFAIK even when Windows 3 was released, they hadn't settled yet on the
case.

Check http://toastytech.com/guis/guitimeline.html for a timeline, some
history notes, screenshots, etc of various GUIs over time, from the
first Alto to Windows 8.1 The site is slightly biased against
Microsoft, but the historic comments are good. I've read about
Microsoft's and Apple's history from a couple of books too (i like
computer history) and i think whatever mentioned there is mostly
right. I haven't checked everything in the site though and i believe
it misses some aspects (f.e. Lisa introduced more than just pulldown
menus - f.e. the whole concept of finder was something new at the time
and Andy Hertzfeld's book on the development of Macintosh has images
from other prototypes that show how much the Mac and Lisa teams
actually came up with that today we take granted).

On Mon, Dec 2, 2013 at 2:39 PM, Hans-Peter Diettrich
 wrote:
> Michael Schnell schrieb:
>
>> On 12/02/2013 10:55 AM, Mark Morgan Lloyd wrote:
>>>
>>>  I think you're at risk of mixing layers again.
>>
>> Of course you are absolutely right and I do know this.
>>
>> But I replied to Microsoft being the inventor of the desktop we are using.
>> And Microsoft does not use a  (publicly) defined X layer but that layer is
>> an integral part of what is perceived as the thingy that holds the programs'
>> GUIs (and might be called "Desktop").
>
>
> The first MS desktop was GEM, borrowed from Digital Research borrowed from
> Apple, I used it also on my Atari ST. License issues forced MS to create
> something slightly different, named Windows. The major difference of Windows
> (vs. GEM) is the added messaging system, with message pipes and loops, which
> turned the GEM event polling model upside down. Next come menus, which were
> moved from the screen into forms. The rest is technically almost the same,
> with only a different look to convince judges in defense against Apple and
> DRI claims.
>
> DoDi
>
>
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread waldo kitty


On 12/2/2013 4:06 AM, Michael Schnell wrote:

If your effort allows for compiling pascal to Java Script this might be even


do you mean "java" or "javascript" above? ;)

--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Hans-Peter Diettrich


Michael Schnell schrieb:

On 12/02/2013 10:55 AM, Mark Morgan Lloyd wrote:

 I think you're at risk of mixing layers again.

Of course you are absolutely right and I do know this.

But I replied to Microsoft being the inventor of the desktop we are 
using. And Microsoft does not use a  (publicly) defined X layer but that 
layer is an integral part of what is perceived as the thingy that holds 
the programs' GUIs (and might be called "Desktop").


The first MS desktop was GEM, borrowed from Digital Research borrowed 
from Apple, I used it also on my Atari ST. License issues forced MS to 
create something slightly different, named Windows. The major difference 
of Windows (vs. GEM) is the added messaging system, with message pipes 
and loops, which turned the GEM event polling model upside down. Next 
come menus, which were moved from the screen into forms. The rest is 
technically almost the same, with only a different look to convince 
judges in defense against Apple and DRI claims.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Sven Barth

Am 02.12.2013 11:32 schrieb "Michael Schnell" :
> But I replied to Microsoft being the inventor of the desktop we are
using.

Let's look at what you replied to:
On 11/30/2013 01:44 PM, vfclists . wrote:

The 'desktop' for Delphi developers where many FreePascal come from
basically means Microsoft.

So where did vfclists write that Microsoft invented the desktop? He just
said that for Delphi developers (what quite some FPC users are or have
been) the desktop means Microsoft. At least until XE2 with OS X support
appeared.

Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 12/02/2013 10:55 AM, Mark Morgan Lloyd wrote:

 I think you're at risk of mixing layers again.

Of course you are absolutely right and I do know this.

But I replied to Microsoft being the inventor of the desktop we are 
using. And Microsoft does not use a  (publicly) defined X layer but that 
layer is an integral part of what is perceived as the thingy that holds 
the programs' GUIs (and might be called "Desktop").


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Mark Morgan Lloyd


Michael Schnell wrote:

On 11/30/2013 01:44 PM, vfclists . wrote:


The 'desktop' for Delphi developers where many FreePascal  come from 
basically means Microsoft.
AFAIK, the mother of the Desktop is X11, which IIRC was invented by 
Xerox (for headless Unix boxes).


The mother of the /desktop/, i.e. with printer and trash icons 
displayed, is the Xerox Star, but X is a completely distinct 
lower-level. If you want to compare Xerox's desktop ideas with anything 
then you should be going directly to KDE and Gnome, and leaving X out of it.


X came from MIT, which  means that in principle at least it inherited 
from some of the very earliest multiuser work while Xerox was more 
oriented towards singleuser workstations (some of which were physically 
big, as I understand it their Artificial Intelligence Workstation was a 
full 19" rack).


Using the siblings of same, we now have KDE and GNOME (and several more) 
in Linux.


Careful there, I think you're at risk of mixing layers again. Qt and GTK 
are normally implemented on top of X11, although Qt also has a fairly 
wide selection of other substrates. GTK is also being forced in that 
direction since a number of players- particularly Ubuntu- are 
experimenting with graphical subsystems which provide roughly the same 
services as X11 but are designed from the ground up with a different 
emphasis (e.g. single-user with no provision for serialising the API 
over the LAN or a pipe).


So IMHO Microsoft was a copycat (as always) but very successful (as 
always).


But reminding people who are devoted to their products of that 
particular point is not always helpful :-)


--
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.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


lost in translation:


 simple compiler switch ... convert it (e.g.) in a cgi with a browser 
based remote GUI.


-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 04:28 PM, Michael Van Canneyt wrote:



Easy:
Because of all the advantages that Pascal has over the mess that 
Javascript is.

+1

(so your idea would be a nice option to do javascript stuff even with no 
gui actions involved)




The inventors of Javascript should be publicly flogged on the town 
square.

You can choose any town you like. The bigger, the better ;)

:-) :-) :-)

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 02:24 PM, Andrew Brunner wrote:


The more server off-loading the better.


This was the idea behind Silverlight.

But seemingly Silverlight is not actively supported any more, which IMHO 
makes the idea of C# / CIL / .net rather senseless (obsolete).


-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 01:38 PM, Michael Van Canneyt wrote:



Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all.


A really scalable solution would have to provide both:
 - just compile the normal Lazarus / mseGUI based program and with a 
simple compiler switch

 - allow for running selectable parts of the application at the user site.

This is what Microsoft intended by C# / CIL / .NET / Silverlight but 
seems to have dumped due to the overwhelming success of Java / Java 
Script in the mobile world.


In fact mseIFI seems to intend to provide the scalability by allowing 
for Pascal Script at the user site.


If your effort allows for compiling pascal to Java Script this might be 
even better at the client site, but IMHO this is not an argument against 
the "ifi" way of communicating between client and server, as IMHO it 
makes a lot of sense to allow for gradually migrate parts of the  
"business logic" code from server to client without much porting effort.


-Michael



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 02:24 PM, Andrew Brunner wrote:


 If you use HTTPS as the transport mechanism, you can assume code is 
secure and just execute it.
Seemingly this is not good enough and that is why WebSockets seems to 
replace Comet.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-02 Thread Felipe Monteiro de Carvalho

On Mon, Dec 2, 2013 at 9:31 AM, Michael Schnell  wrote:
> AFAIK, the mother of the Desktop is X11, which IIRC was invented by Xerox
> (for headless Unix boxes).

X11 isn't the mother of desktop according to:
http://en.wikipedia.org/wiki/X_Window_System#Predecessors

"X originated at the Massachusetts Institute of Technology (MIT) in 1984."

"Several bitmap display systems preceded X. From Xerox came the Alto
(1973) and the Star (1981). From Apollo Computer came Display Manager
(1981). From Apple came theLisa (1983) and the Macintosh (1984). The
Unix world had the Andrew Project (1982) and Rob Pike's Blit terminal
(1982)."

-- 
Felipe Monteiro de Carvalho

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 01:44 PM, vfclists . wrote:


The 'desktop' for Delphi developers where many FreePascal  come from 
basically means Microsoft.
AFAIK, the mother of the Desktop is X11, which IIRC was invented by 
Xerox (for headless Unix boxes).


Using the siblings of same, we now have KDE and GNOME (and several more) 
in Linux.


So IMHO Microsoft was a copycat (as always) but very successful (as 
always).


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/29/2013 11:22 PM, Dariusz Mazur wrote:


Could You mention this problems?

I did not do tests myself, but when researching I was told that some Web 
servers would kill the connection to the client and/or the fast-cgi and 
would not recover decently.


At that time I did not know about WebSockets. This now seems mere like 
the way to go. So I would not invest more effort in Comet.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 09:08 AM, Martin Schreiber wrote: ...

If course I do remember very well, how ifi works. For me, it is a really 
great idea to decently physically separate the "business logic" from the 
GUI without completely loosing the "RAD" features Delphi, Lazarus and 
mseGUI provide. At best you could develop the program with a local GUI 
and then set a switch to compile it as an ifi Server.


Regarding the OP's question:

I suppose regarding ifi "socket" includes "WebSockets". So the server 
site seems to be in place.


As the "ifi" byte stream is well defined, it should be possible to do 
the server and the client in different languages/environments. Thus as a 
client "Browser plugin" you could do a pascal program, which seemingly 
would be rather easy to do, but would need installing it at the client 
site, which in some environments (we did get burnt :( ) is impossible 
due to IT guide lines (aka incompetence).


Thus other ways could be considered:
 - compiling the pascal code with Delphi Prism to a CIL plugin and use 
Silverlight / Moonlight to run it in the browser sandbox.

 - re-implement the client site of the library in java script.

-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-01 Thread Michael Schnell


On 11/30/2013 09:08 AM, Martin Schreiber wrote:
IIRC I even made a MSEifi-remote demo-binary especially for you so 
that you could show the principle to your co-workers some years ago. ;-)


This is why I dared to mention it right now :-) :-) .

-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-12-01 Thread Hans-Peter Diettrich


Dmitry Boyarintsev schrieb:

LCL is not going to be network based, for one simple reason - it 
technically cannot - too much is bound to low lever WinAPI-like functions.


I'd say that the problem resides in the adaptation of the (given) VCL 
interface to multiple widgetsets. Some widgetsets fit better into this 
model than others do.


We could try something like Borland tried to achieve with CLX, and 
construct an subset of the LCL functionality that makes less assumptions 
about window/layout managers and built-in functionality of the basic 
controls. Unfortunately it's not sufficient to simply *not use* features 
not available in a certain (HTML...) widgetset, as long as the LCL 
controls use (and consequently rely on) such features internally. One 
solution could try to "outsource" specific features, i.e. move them into 
dedicated classes which can be overridden as suitable for every 
supported widgetset. This would allow to fully disregard properties or 
other programmatical requests internally (in the dumb base classes), 
without causing consequential errors. But it looks impossible to me, to 
separate all problematic functionality from the existing LCL. A complete 
refactoring would be required (too complicated), or a restart from point 
zero (who would be interested in doing that?).


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Dmitry Boyarintsev

On Fri, Nov 29, 2013 at 4:52 AM, Michael Schnell  wrote:

> On 11/28/2013 05:39 PM, Dmitry Boyarintsev wrote:
>
>> Even if LCL will start "web target" today, it will be 10 years later that
>> LCL can be used without problems.
>>
> You don't seem to know what Michel v C and friends can do :-) :-)

Yes, I do. I also do know how LCL works internally.
As you can see below in MVC's reply, he actually confirms my point.

LCL is not going to be network based, for one simple reason - it
technically cannot - too much is bound to low lever WinAPI-like functions.

And of course, a web-framework can be created based on Lazarus. But using
Lazarus as IDE only (or at least - package manager).
So to be more accurate a web-framework will be Free Pascal based.

thanks,
Dmitry

On Sat, Nov 30, 2013 at 8:28 AM, Michael Van Canneyt  wrote:
>
> You are missing the point, I think.
>
> The idea is not to create a new widgetset.
>
> The idea is just to be able to program in pascal, output Javascript.
>
> Using some kind of 'external' declarations would enable you to use Adobe
> Air,
> ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see
> fit.
>
> I am not making any assumptions on that.
>
> But, and this is what I miss in all other attempts mentioned here: I want
> to be able to program the browser WITHOUT necessarily having an application
> server running on a webserver.
>
> It must be possible to ship a HTML file and a Javascript file for a
> working application. That's it.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, Marcos Douglas wrote:


Is the pascal scripting engine ready for production use?



Not at all.

Michael.


This project will be open source?


It will be, obviously.


If yes, why don't you release the code right now? Other people can
contribute too.


Because I want to have a decent subset of Pascal translated before I publish it, 
so there is something to build on.


Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Marcos Douglas

On Sat, Nov 30, 2013 at 11:30 AM, Michael Van Canneyt
 wrote:
>
>
> On Sat, 30 Nov 2013, Andrew Brunner wrote:
>
>> On 11/30/2013 06:38 AM, Michael Van Canneyt wrote:
>>>
>>> No.
>>>
>>> Extpascal does wat mseide does. Transport everything back to the server.
>>> That is completely the wrong approach. Not scalable at all. Slow, not
>>> guaranteed to have a return etc. In short: wrong.
>>>
>>> I want to program the browser itself. In Pascal.
>>>
>>
>> Do you mean an embedded component that displays web pages?  Or do you mean
>> a scripting project that takes lfm and pas units and build the app "on the
>> fly"?
>
>
> Not on the fly. See it more as a Pascal-to-Javascript compiler.
>
> You really should have a look at the Morfik AppsBuilder or Smart Mobile
> studio products.
>
> I just want to be able to do what they do, but in Lazarus.
>
>
>> Is the pascal scripting engine ready for production use?
>
>
> Not at all.
>
> Michael.

This project will be open source?
If yes, why don't you release the code right now? Other people can
contribute too.


Marcos Douglas

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, Felipe Monteiro de Carvalho wrote:


On Fri, Nov 29, 2013 at 12:13 PM, Michael Van Canneyt
 wrote:

That is exactly my plan:

1. Convert pascal to javascript.
2. Use the custom widget design capabilities of Lazarus to design the form.

Just like Morfik does/did, and recently Smart Mobile studio.


But a very large piece here is at stage zero of development: the
pascal 2 javascript compiler.

Or does it already exist and I am not aware of it?


Well. 2 pieces exist publicly: the fcl-js and fcl-passrc.

The transformer for the AST is started, but is not published.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Felipe Monteiro de Carvalho

On Fri, Nov 29, 2013 at 12:13 PM, Michael Van Canneyt
 wrote:
> That is exactly my plan:
>
> 1. Convert pascal to javascript.
> 2. Use the custom widget design capabilities of Lazarus to design the form.
>
> Just like Morfik does/did, and recently Smart Mobile studio.

But a very large piece here is at stage zero of development: the
pascal 2 javascript compiler.

Or does it already exist and I am not aware of it?

-- 
Felipe Monteiro de Carvalho

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, Martin Schreiber wrote:


On Saturday 30 November 2013 13:38:58 Michael Van Canneyt wrote:

On Fri, 29 Nov 2013, Marcos Douglas wrote:

Extpascal does wat mseide does. Transport everything back to the server.


That is not quite right. MSEifi does not transport everything back to the
server. It transports only what is defined in the client form- and
datamodule-resources as "interesting for server". Most of the actions (for
example show dropdown lists, scroll and sort datasets) is done client side
without server interaction.
Programming the whole application in Javascript and running in browser surely
is an option, but why use Free Pascal for that purpose?


Easy:
Because of all the advantages that Pascal has over the mess that Javascript is.

The inventors of Javascript should be publicly flogged on the town square.
You can choose any town you like. The bigger, the better ;)

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Paul Breneman

On 11/30/2013 02:08 AM, Martin Schreiber wrote:

On Friday 29 November 2013 13:55:10 Michael Schnell wrote:

MSEgui has a (supposedly not yet finished) extension called "ifi". Same
is supposed to provide a remote GUI via a Byte-pipe. Both the server and
the "user" end is a pascal program.

MSEifi-remote is still experimental because nobody made real applications up
to now. Local inprocess MSEifi is used in production to separate user
interface and business logic in MSEgui applications since years. IIRC I even
made a MSEifi-remote demo-binary especially for you so that you could show
the principle to your co-workers some years ago. ;-)

How MSEifi-remote works:

- Client is an application independent Free Pascal program with MSEgui/MSEifi-
library. The client could be realized as browser plug-in (not done up to
now).
- Server is a Free Pascal program with the necessary MSEifi connection
components. The server needs no GUI library elements.
- The client joins the server by a byte stream connection, currently
implemented are pipes and sockets.
- The server sends *.mfm data (the MSEgui equivalent of Lazarus form files) to
the client. The form data can contain Pascal Script snippets if necessary.
- The client instantiates the forms/datamodules exactly the same as a normal
MSEgui application would do -> look, feel and performance of the components
are the same.
- Client and server use MSEifi data- and event-components which are linked by
the MSEifi-remote protocol.

Example:

A user button click triggers firing of an event in a taction component by the
tbutton.action property, the event is transported over the wire, triggers
tnoguiaction.onexecute in the server, the server sends a modal form to the
client, the client shows the modal form, the user enters data which will be
sent to the data components in the server, the user closes the modal entry
form, the modalresult will be sent to the server.

So for development of server, client or standalone applications the same
MSEide+MSEgui RAD-approach can be used. While developping and debugging it is
possible to run client and server in the same process with
a "shortcut-connection".

Martin

A *long* time ago I was involved a little with Genotechs in Phoenix and
they had a (Delphi) program called AstroMark that sounds similar:

http://www.eweek.com/c/a/Enterprise-Networking/Do-You-Deploy-Thin-or-Thick-Web-Applications/

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, Andrew Brunner wrote:



On 11/30/2013 07:28 AM, Michael Van Canneyt wrote:


But, and this is what I miss in all other attempts mentioned here: I want 
to be able to program the browser WITHOUT necessarily having an application 
server running on a webserver.


It must be possible to ship a HTML file and a Javascript file for a working 
application. That's it.


Don't forget browsers also have database storage now.  So some abstraction 
could be done there as well.


True. But that is just a matter of writing a wrapper class.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Martin Schreiber

On Saturday 30 November 2013 13:38:58 Michael Van Canneyt wrote:
> On Fri, 29 Nov 2013, Marcos Douglas wrote:
>
> Extpascal does wat mseide does. Transport everything back to the server.

That is not quite right. MSEifi does not transport everything back to the 
server. It transports only what is defined in the client form- and 
datamodule-resources as "interesting for server". Most of the actions (for 
example show dropdown lists, scroll and sort datasets) is done client side 
without server interaction.
Programming the whole application in Javascript and running in browser surely 
is an option, but why use Free Pascal for that purpose?

Martin

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

On Sat, 30 Nov 2013, silvioprog wrote:

2013/11/30 Michael Van Canneyt
On Sat, 30 Nov 2013, silvioprog wrote:

2013/11/30 Michael Van Canneyt
[...]
I want to program the browser itself. In Pascal.

Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate
it into Lazarus? That would leave the
responsibility for compatibility
with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support
for cross-platform etc. for the webkit.

You are missing the point, I think.

The idea is not to create a new widgetset.

The idea is just to be able to program in pascal, output Javascript.

Using some kind of 'external' declarations would enable you to use Adobe
Air,
ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see
fit.

I am not making any assumptions on that.

But, and this is what I miss in all other attempts mentioned here: I want
to be able to program the browser WITHOUT
necessarily having an application server running on a webserver.

It must be possible to ship a HTML file and a Javascript file for a
working application. That's it.

But that is exactly what the node-webkit does, however, using a webkit ready,
and without a HTTP server. But node-webkit uses JS, so the
idea would be to use Pascal. E.g., in a pseudo code, would be:

Node-webkit still requires an external binary to be shipped somewhere, like Adobe Air.
It emulates a browser.

That is not what I am trying to accomplish.

Using my approach, you will be able to use node-webkit, if you want to. All I
will do in the first place
is convert pascal to Javascript. What you decide to do with that (how to interact with the browser or
node-webkit, or whatever) is up to you. Once I have the Javascript part running, I will see how to
integrate this with Lazarus so it can be used to design your web applications. Whether this will be
with an existing webkit (and which one) or not is entirely up for discussion, and not relevant at this point.

Michael.--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, Andrew Brunner wrote:


On 11/30/2013 06:38 AM, Michael Van Canneyt wrote:

No.

Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all. Slow, not 
guaranteed to have a return etc. In short: wrong.


I want to program the browser itself. In Pascal.



Do you mean an embedded component that displays web pages?  Or do you mean a 
scripting project that takes lfm and pas units and build the app "on the 
fly"?


Not on the fly. See it more as a Pascal-to-Javascript compiler.

You really should have a look at the Morfik AppsBuilder or Smart Mobile studio 
products.

I just want to be able to do what they do, but in Lazarus.


Is the pascal scripting engine ready for production use?


Not at all.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, Andrew Brunner wrote:


On 11/30/2013 02:08 AM, Martin Schreiber wrote:

How MSEifi-remote works: -


That's not how it *should* be done.  Any logic code that can be executed 
should be executed by way of the client.  If you use HTTPS as the transport 
mechanism, you can assume code is secure and just execute it.


The more server off-loading the better.  Data submission is important and 
validation should be done on the client side with some framework safety 
checks before posting transactional data to the backend-database.


I don't think Lazarus should follow this particular mantra.


Exactly.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread vfclists .

On 30 November 2013 13:28, Andrew Brunner  wrote:

>
> On 11/30/2013 07:04 AM, silvioprog wrote:
>
>  2013/11/30 Michael Van Canneyt 
>
>> [...]
>> I want to program the browser itself. In Pascal.
>>
>
>  Hello Michael,
>
>  Why not use an existing webkit (like Qt or Chrome) and incorporate it
> into Lazarus? That would leave the responsibility for compatibility with
> HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for
> cross-platform etc. for the webkit.
>
>  Please see this nice project:
>
>  https://github.com/rogerwang/node-webkit
>
>
>
> What would it take - in the form of a bounty - to get a community wide
> project to get Lazarus a *real* HTML5 browser for OSX and Linux?  I assume
> windows is already just an Active-X component.
>
> Any ideas? I can't stress this enough that it's like living in the
> technical dark-ages without access to developing front-ends without rich
> text and more often for me  now, web apps.
>
>
>
I think I mentioned what your real problem was in the my previous response.

Most of  we want can be found in
http://www.elevatesoft.com/products?category=ewb&type=web. The developer
speaks of Linux version being in the works which could be because the
backend probably depends on Delphi. Delphi as usual continues to be Lazarus
and FreePascal's worse enemy.

My  own feeling is that getting the Lazarus form builder to generate Pascal
code rather than, or as well as the .lfm files  is the first step. Then
Javascript next, QML or whatever. The Delphi legacy is still hanging over
Lazarus. Phil Hess did something that could translate a subset of the
components in.lfm files into Javascript some years ago and that may be a
start.

-- 
Frank Church

===
http://devblog.brahmancreations.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 06:38 AM, Michael Van Canneyt wrote:

No.

Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all. Slow, not 
guaranteed to have a return etc. In short: wrong.


I want to program the browser itself. In Pascal.



Do you mean an embedded component that displays web pages?  Or do you 
mean a scripting project that takes lfm and pas units and build the app 
"on the fly"?


Is the pascal scripting engine ready for production use?


--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, 
music, and more.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Martin Schreiber

On Saturday 30 November 2013 14:24:03 Andrew Brunner wrote:
> On 11/30/2013 02:08 AM, Martin Schreiber wrote:
> > How MSEifi-remote works: -
>
> That's not how it *should* be done.  Any logic code that can be executed
> should be executed by way of the client.  If you use HTTPS as the
> transport mechanism, you can assume code is secure and just execute it.
>
There is not so much program logic which must be coded. Most is done by the 
MSEgui components, the GUI anyway, then there is the whole palette of DB, 
data entry and data visualisation components.
If one likes one can use client side Pascal Script for the rest of the 
business logic if one thinks that it is save enough. The server merely has to 
send the form resources, scripts and data.

Although I must say that I still more like "real" applications. ;-)

Martin

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread silvioprog

2013/11/30 Michael Van Canneyt 
>
> On Sat, 30 Nov 2013, silvioprog wrote:
>
>  2013/11/30 Michael Van Canneyt 
>>   [...]
>>   I want to program the browser itself. In Pascal.
>>
>>
>> Hello Michael,
>>
>> Why not use an existing webkit (like Qt or Chrome) and incorporate it
>> into Lazarus? That would leave the responsibility for compatibility
>> with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for
>> cross-platform etc. for the webkit.
>>
>
> You are missing the point, I think.
>
> The idea is not to create a new widgetset.
>
> The idea is just to be able to program in pascal, output Javascript.
>
> Using some kind of 'external' declarations would enable you to use Adobe
> Air,
> ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see
> fit.
>
> I am not making any assumptions on that.
>
> But, and this is what I miss in all other attempts mentioned here: I want
> to be able to program the browser WITHOUT necessarily having an application
> server running on a webserver.
>
> It must be possible to ship a HTML file and a Javascript file for a
> working application. That's it.


But that is exactly what the node-webkit does, however, using a webkit
ready, and without a HTTP server. But node-webkit uses JS, so the idea
would be to use Pascal. E.g., in a pseudo code, would be:

procedure TForm1.FormCreate(Sender: TObject);
begin
  webBrowser.load('hello');
  webBrowser.elementById('hello').on('onclick', @Button1Click);
  webBrowser.element('window').on('message', @Msg);
end;

procedure TForm1.Msg(wb: TWebBrowser);
begin
  ShowMessage(webBrowser.elementById('hello').value.asString);
end;


> Michael.




-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop



On 11/30/2013 07:28 AM, Michael Van Canneyt wrote:


But, and this is what I miss in all other attempts mentioned here: I 
want to be able to program the browser WITHOUT necessarily having an 
application server running on a webserver.


It must be possible to ship a HTML file and a Javascript file for a 
working application. That's it.


Don't forget browsers also have database storage now.  So some 
abstraction could be done there as well.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop



On 11/30/2013 07:04 AM, silvioprog wrote:
2013/11/30 Michael Van Canneyt >


[...]
I want to program the browser itself. In Pascal.


Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate it 
into Lazarus? That would leave the responsibility for compatibility 
with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for 
cross-platform etc. for the webkit.


Please see this nice project:

https://github.com/rogerwang/node-webkit



What would it take - in the form of a bounty - to get a community wide 
project to get Lazarus a *real* HTML5 browser for OSX and Linux?  I 
assume windows is already just an Active-X component.


Any ideas? I can't stress this enough that it's like living in the 
technical dark-ages without access to developing front-ends without rich 
text and more often for me  now, web apps.



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Sat, 30 Nov 2013, silvioprog wrote:


2013/11/30 Michael Van Canneyt 
  [...]
  I want to program the browser itself. In Pascal.


Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate it into 
Lazarus? That would leave the responsibility for compatibility
with HTML5, CSS3, mp3 encode, webGL, file manipulation, , support for 
cross-platform etc. for the webkit.


You are missing the point, I think.

The idea is not to create a new widgetset.

The idea is just to be able to program in pascal, output Javascript.

Using some kind of 'external' declarations would enable you to use Adobe Air,
ExtJS, Node.js, Jquery, Kendo UI, node-webkit, Dojo or whatever you see fit.

I am not making any assumptions on that.

But, and this is what I miss in all other attempts mentioned here: 
I want to be able to program the browser WITHOUT necessarily having an application server running on a webserver.


It must be possible to ship a HTML file and a Javascript file for a working 
application. That's it.

Michael.--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/30/2013 02:08 AM, Martin Schreiber wrote:

How MSEifi-remote works: -


That's not how it *should* be done.  Any logic code that can be executed 
should be executed by way of the client.  If you use HTTPS as the 
transport mechanism, you can assume code is secure and just execute it.


The more server off-loading the better.  Data submission is important 
and validation should be done on the client side with some framework 
safety checks before posting transactional data to the backend-database.


I don't think Lazarus should follow this particular mantra.


--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, 
music, and more.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread silvioprog

2013/11/30 Michael Van Canneyt 

> [...]
> I want to program the browser itself. In Pascal.
>

Hello Michael,

Why not use an existing webkit (like Qt or Chrome) and incorporate it into
Lazarus? That would leave the responsibility for compatibility with HTML5,
CSS3, mp3 encode, webGL, file manipulation, , support for cross-platform
etc. for the webkit.

Please see this nice project:

https://github.com/rogerwang/node-webkit

It uses a embedded Qt webkit version, and is very easy to use. E.g.:
---
Quick Start

Create index.html:


  
Hello World!
  
  
Hello World!
We are using node.js document.write(process.version).
  

Create package.json:

{
  "name": "nw-demo",
  "main": "index.html"}

Compress index.html and package.json into a zip archive called app.nw:

$ zip app.nw index.html package.json

This should create a structure like this:

app.nw
|-- package.json
`-- index.html

Download the prebuilt binary for your platform and use it to open the app.nw
 file:

$ ./nw app.nw

Note: on Windows, you can drag the app.nw to nw.exe to open it.
---

It tested it in my Windows and worked like a charm:

https://www.dropbox.com/s/hx489n2oxruvf45/nwk.png

Adopting a webkit, we would gain a long time, because it already has all
hard implementation that a browser needs to work.

[...]
> Michael.


-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread vfclists .

On 30 November 2013 08:08, Martin Schreiber  wrote:

> On Friday 29 November 2013 13:55:10 Michael Schnell wrote:
> >
> > MSEgui has a (supposedly not yet finished) extension called "ifi". Same
> > is supposed to provide a remote GUI via a Byte-pipe. Both the server and
> > the "user" end is a pascal program.
> >
> MSEifi-remote is still experimental because nobody made real applications
> up
> to now. Local inprocess MSEifi is used in production to separate user
> interface and business logic in MSEgui applications since years. IIRC I
> even
> made a MSEifi-remote demo-binary especially for you so that you could show
> the principle to your co-workers some years ago. ;-)
>
> How MSEifi-remote works:
>
> Martin
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>

The real issue here is not the future of the desktop, it is basically
Microsoft and Hardware manufacturers 'punking out' business developers
through FUD. The simple fact is that all the industry majors are
'frenemies' of developers, they pretend to be your friends and screw you
over afterwards. Saying that the desktop has no future is simply a side
effect of  the policies Microsoft adopted as a consequence  of trying to
turn itself into Apple.

The 'desktop' for Delphi developers where many FreePascal  come from
basically means Microsoft. It is a consequence of Microsoft trying to force
all sales through their App Stores like Apple does, which is insane as LOB
applications are not consumer applications that are sold through App Stores.

For example Delphi developers feel they are being screwed over by
Embarcadero, if they feel bad they should ask Microsoft developers how they
feel about Microsoft's policies concerning Silverlight, WPF, Windows 8 and
all those issues.

For business developers the main advantage of the Web is that it cuts down
support costs and eliminates deployment issues. The downside is that
HTML5/Javascript combination is not good enough, leaving Flash and
Silverlight. Then Apple refuses to support Flash, Adobe withdraws Flash
(but leaving Microsoft and Google to develop it their versions, ignoring
Mozilla who are doing Shumway) and Microsoft cancels further Silverlight
development. These were the tools that were supposed to enable desktop
software developers to transition to the web, so you see the desktop is not
the issue, the agenda of the industry majors is.

Mozilla has XUL which enabled cross platform development and they started
messing with it. Google has Pepper and they say are ceasing development
from 2014.

Linux would or should work, but when hardware device makers don't want to
release drivers it results in  substandard drivers compared with those
available for Windows and Apple machines.

This doesn't mean that the desktop doesn't have a future it only means that
developers have to think strategically and work out carefully what their
options are.

To summarize the situation:

1. Microsoft seems confused and has apparently lost direction in the sense
of how it supports its traditional developers, or how to support their
transitioning to the tablet and smartphone era.

2. Linux is not getting enough support from hardware manufacturers.

3. Microsoft, Google and Mozilla are disabling their browser plugin
systems, and where they are present requiring apps that use them to be
whitelisted, as successful cross platform applications, especially if they
can be purely browser based would cut them out of the commission loop and
minimize the benefits of their platforms uniqueness. Their basic agenda is
you can do anything you want on our platforms so long as we gain access to
your Javascript, minified, Google Closured, asmjs-ed, whatever and are able
to take out commission.

4. Moral of the story - stick to Linux, port it to your smartphones and
tablets, develop your own Web browser and develop your own plugin system
for it. You just can't depend on 'frenemies'.

-- 
Frank Church

===
http://devblog.brahmancreations.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop




On Fri, 29 Nov 2013, Marcos Douglas wrote:


On Fri, Nov 29, 2013 at 9:13 AM, Michael Van Canneyt
 wrote:



On Fri, 29 Nov 2013, Santiago Amposta wrote:



The solution to this problem is quite easy, and it is what many web-GUI
interfaces do: Move part of program to the client side, so they send big
javascripts to the client. No objection, I don't think it's a big deal
to send javascript libraries to the client, as long as it is transparent
for me as developer. What I intend to avoid, when I write an
application, is having to write half application in pascal and half
application using javascript. I want to write the whole application in
pascal and let the libraries use javascript or whatever they want.

Probably I'm demanding too much, there is no way a component can say "I
will convert this few lines of code into a javascript and send it to the
client"



That is exactly my plan:

1. Convert pascal to javascript.
2. Use the custom widget design capabilities of Lazarus to design the form.

Just like Morfik does/did, and recently Smart Mobile studio.

But only in Lazarus :)


As ExtPascal?


No.

Extpascal does wat mseide does. Transport everything back to the server.
That is completely the wrong approach. Not scalable at all. 
Slow, not guaranteed to have a return etc. In short: wrong.


I want to program the browser itself. In Pascal.

It has been done before (Morfik), it is being done as we speak (Smart Mobile studio), 
only not by Lazarus/FPC. All the big blocks are in place, my next step is the translation 
of Object Pascal to Javascript. There are obviously some inherent limitations due to 
the browser environment (pointers and such) but this is not a real problem.


Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-30 Thread Martin Schreiber

On Friday 29 November 2013 13:55:10 Michael Schnell wrote:
>
> MSEgui has a (supposedly not yet finished) extension called "ifi". Same
> is supposed to provide a remote GUI via a Byte-pipe. Both the server and
> the "user" end is a pascal program.
>
MSEifi-remote is still experimental because nobody made real applications up 
to now. Local inprocess MSEifi is used in production to separate user 
interface and business logic in MSEgui applications since years. IIRC I even 
made a MSEifi-remote demo-binary especially for you so that you could show 
the principle to your co-workers some years ago. ;-)

How MSEifi-remote works:

- Client is an application independent Free Pascal program with MSEgui/MSEifi- 
library. The client could be realized as browser plug-in (not done up to 
now).
- Server is a Free Pascal program with the necessary MSEifi connection 
components. The server needs no GUI library elements.
- The client joins the server by a byte stream connection, currently 
implemented are pipes and sockets.
- The server sends *.mfm data (the MSEgui equivalent of Lazarus form files) to 
the client. The form data can contain Pascal Script snippets if necessary.
- The client instantiates the forms/datamodules exactly the same as a normal 
MSEgui application would do -> look, feel and performance of the components 
are the same.
- Client and server use MSEifi data- and event-components which are linked by 
the MSEifi-remote protocol.

Example:

A user button click triggers firing of an event in a taction component by the 
tbutton.action property, the event is transported over the wire, triggers 
tnoguiaction.onexecute in the server, the server sends a modal form to the 
client, the client shows the modal form, the user enters data which will be 
sent to the data components in the server, the user closes the modal entry 
form, the modalresult will be sent to the server.

So for development of server, client or standalone applications the same 
MSEide+MSEgui RAD-approach can be used. While developping and debugging it is 
possible to run client and server in the same process with 
a "shortcut-connection".

Martin

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Marcos Douglas

On Fri, Nov 29, 2013 at 9:13 AM, Michael Van Canneyt
 wrote:
>
>
> On Fri, 29 Nov 2013, Santiago Amposta wrote:
>
>>
>> The solution to this problem is quite easy, and it is what many web-GUI
>> interfaces do: Move part of program to the client side, so they send big
>> javascripts to the client. No objection, I don't think it's a big deal
>> to send javascript libraries to the client, as long as it is transparent
>> for me as developer. What I intend to avoid, when I write an
>> application, is having to write half application in pascal and half
>> application using javascript. I want to write the whole application in
>> pascal and let the libraries use javascript or whatever they want.
>>
>> Probably I'm demanding too much, there is no way a component can say "I
>> will convert this few lines of code into a javascript and send it to the
>> client"
>
>
> That is exactly my plan:
>
> 1. Convert pascal to javascript.
> 2. Use the custom widget design capabilities of Lazarus to design the form.
>
> Just like Morfik does/did, and recently Smart Mobile studio.
>
> But only in Lazarus :)

As ExtPascal?

Marcos Douglas

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Dariusz Mazur


On 2013-11-29 11:01, Michael Schnell wrote:

On 11/28/2013 10:29 PM, Santi wrote:
I don't want to use Lazarus because it is the last defender of 
"Native controls" against the evil "web-controls". I want to use 
Lazarus because I want to use a powerful language like Pascal in the 
backend and a framework with a RAD that allows me write GUI 
interfaces quickly.


Yep.

Because it wants to provide RAD, the LCL GUI designer is one of the 
most easy to use GUI designers. I once failed on trying to find an 
"active" web page designer tool that comes anywhere close regarding 
user friendliness.


RAD is only small addition. I use Delphi from several years and don't 
use RAD (design forms by mouse). And many professional developers drop 
RAD and made forms in code.




Thus for me a "Web GUI" LCL Widget type makes a huge lot of sense 
(even if the count and features of the widgets  usable in this mode is 
restricted vs the "local" widgets.


Some times (and increasingly) they are much powerful: 3d look, 
textures,  animated, structural hints etc.


In fact it should be possible to switch between "Web GUI" and "local 
GUI" just by setting the Widget type variable. 



This is background

Decent messages for stuff that does not work on the WebGUI appreciated.


I think that 99.9% code may work on proper WebGUI
This is then same like switch form Intel to ARM or to x64. When 
library/compiler developers take care, rest can no/small  worry about it.




Darek

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Dariusz Mazur


On 2013-11-29 10:28, Michael Schnell wrote:

On 11/28/2013 04:39 PM, Michael Van Canneyt wrote:

These days it is very easy to make a very responsive web gui.
"Responsiveness" (the program reacts to user input) is not the problem 
I meant to describe but the ability of the program to issue "state" 
messages spontaneously.


This is hampered by the missing symmetry of the http protocol: The 
client needs to poll for such "reverse" messages.


This can partly be improved by techniques like "comet" that leave a 
http protocol open in a somewhat "non-standard" way. But AFAIK, this 
does result in certain problems.


\

Could You mention this problems?

Darek

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Dariusz Mazur





I have made a small test program, by hand, with no LCL and no RAD
utilities. It is boring and a lot of dirty work, but not difficult (If I
could do it, it can't be difficult, my programming skills are rusted
after years of programming sales reports). I have taken a look at QT
widget, and perhaps it shouldn't be that difficult integrating web with LCL.


I've made myself such web widget set, which have the same API as LCL. 
Thus its simple to recompile desktop application to gain web application


its huge (>1000 forms) program which is use by hundreds user day by day .
I've mention about it a few times, i work with it from  years, and I 
think that HTML5 + Pascal is the best tool to web application.

Nevertheless I have found issues that have little to do with RAD, they
are related to the concept of remote GUI itself.

Let's suppose you have a checkbox that when cheked must enable some
controls. In a common desktop the event is sent to the application, and
application process the event and tells the GUI which controls must
enable. But if the application is remote, the roundtrip may take 30 ms,
add a cascade of events triggered and you get that you uncheking a
chekbox the application gets stalled for a moment or more (I read
somewhere that to get the "no time" perception it must react in less
than 100ms). I said 30ms but it could be 200ms depending on the
connection, and then the moment may become a second.

No time perception is under 300ms.
No one controls must wait to response from server to change its look, 
this do JS lying under each. But of course, each user action is 
transmitted to server and respond carry information of look other 
controls.  In other words: each control take care only of itself, no 
business logic is include in JS, rest is done by server.






The solution to this problem is quite easy, and it is what many web-GUI
interfaces do: Move part of program to the client side, so they send big
javascripts to the client. No objection, I don't think it's a big deal
to send javascript libraries to the client, as long as it is transparent
for me as developer. What I intend to avoid, when I write an
application, is having to write half application in pascal and half
application using javascript. I want to write the whole application in
pascal and let the libraries use javascript or whatever they want.

This is outlined, as I do: 95% in pascal and 5 in JS+CSS+HTML

Probably I'm demanding too much, there is no way a component can say "I
will convert this few lines of code into a javascript and send it to the
client"

I dont send JS for controls, only some HTML like (real copy)



rest is done by JS + CSS
by the way: CSS id great, allows for separation of look and behavior, 
its far better than LCL






Beside this, there are concerns with http protocol, it is document
oriented, not connection oriented. For example, unless you keep the
connection open, every event from GUI to application, even a single
byte,  must send a lot header information, let alone if you use cookies
that are sent with every connection. There are workarounds, comet, html5
websockets, perhaps with some drawbacks.


This is not problem. Today  network is fast, sending packet information 
under size of frame (<1400bytes) has no overhead.

Pooling : only 1 request for 15 s, its under 0.001% overhead.

Much difficult is architecture of HTTP server.  I need modal windows, 
thus I use 3 levels of thread. If add logging, timers or background task 
then levels count. But its work the same as on desktop (only nicer)



Darek



--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Andrew Brunner



On 11/29/2013 03:28 AM, Michael Schnell wrote:
"Responsiveness" (the program reacts to user input) is not the problem 
I meant to describe but the ability of the program to issue "state" 
messages spontaneously.  This is hampered by the missing symmetry of 
the http protocol: The client needs to poll for such "reverse" messages.



I wanted to make 2 points here...
1.) This can be mitigated with existing HTTP protocol if you have 
control over the server.   For instance, with Aurawin SCS if a request 
comes in with access to the "core" I set a flag in the sockets engine 
that says keep this socket stream infinitely open. This way HTTPS 
re-negotiation is a thing of the past, and requests are instant.
2.) Your web browser is key here.  Chrome keeps socket sessions 
cached.  So more often than not there already is a connection made. 
Meaning in the JS code, if you say XMLHTTPRequest(/server/core/command) 
it just creates a string and sends it to the server.  That 
XMLHTTPRequest does not imply a new HTTP connection.


This can partly be improved by techniques like "comet" that leave a 
http protocol open in a somewhat "non-standard" way. But AFAIK, this 
does result in certain problems.


"Non-standard" is a subjective term.  However, there is presently 
WebSockets that standardizes HTML5 event driven socket communication to 
exactly address this entire point.



--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, 
music, and more.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Andrew Brunner



On 11/29/2013 03:36 AM, Michael Schnell wrote:


With the new version they converted to a "remote GUI" in the browser 
(thus the functionality is within the box, while the remote GUI 
implementation is completely independent from the functionality).


I do suppose they did this for a reason :-) .



Pulling all those assets into a browser means that they have optimized 
their vdm for speed not size.  I know at present I need over 120MB of 
storage for assets.  For embedded systems I wonder if that is a rather 
large requirement.



In fact the remote GUI implementation uses a huge java script library 
that the browser pulls when starting the work on that page.


In order to do that they must have a development branch that keeps 
assets separate.  With Aurawin SCS I have 2 domains.  I use directory 
templates and keywords to manage different "boot" modes for each domain 
that has the EXACT same file base. This way daily.aurawin.com under 
Chrome shows me exactly what I'm looking at.  Without that, development 
is a MAJOR PITA.


--
Andrew Brunner

Aurawin LLC
512.850.3117
https://aurawin.com/

Aurawin is a great new way to store, share and enjoy your photos, videos, 
music, and more.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/29/2013 01:11 PM, Santiago A. wrote:
So, you don't plan to create a new widget in LCL for html+javascript, 
but an utility that process application source and generates a big 
javascript. 


MSEgui has a (supposedly not yet finished) extension called "ifi". Same 
is supposed to provide a remote GUI via a Byte-pipe. Both the server and 
the "user" end is a pascal program.


After compiling the user program to HTML5 via Smart Mobile Studio we 
could theoretically have a remote GUI.


-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Mark Morgan Lloyd


Michael Schnell wrote:

On 11/29/2013 11:55 AM, Mark Morgan Lloyd wrote:


That goes back to some of the earliest Netscape versions, IIRC it was 
originally used to update images periodically. While attractive, this 
sort of thing can turn into a nightmare if the browser on an end 
user's system leaks memory until an entire page (i.e. not just part of 
the DOM describing the page) is forcibly reloaded- BTDT.


Do we still need to take into account that a browser is that limited ? 
Browser technology has advanced a lot during the passed few years.


"Do we have to take into account that a browser might have bugs?"

Probably.

"Do we have to take into account that somebody might run a browser older 
than we like supporting?"


Partly: at the absolute minimum to give him a sensible error message, 
and ideally to provide some sort of usable UI even if it lacks the 
"bells and whistles".


--
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.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Santiago A.

El 29/11/2013 12:13, Michael Van Canneyt escribió:
>
>
>
> That is exactly my plan:
>
> 1. Convert pascal to javascript.
> 2. Use the custom widget design capabilities of Lazarus to design the
> form.
>
> Just like Morfik does/did, and recently Smart Mobile studio.
>
> But only in Lazarus :)

So, you don't plan to create a new widget in LCL for html+javascript,
but an utility that process application source and generates a big
javascript.

-- 
Saludos

Santi
s...@ciberpiula.net


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/29/2013 12:26 PM, Sven Barth wrote:

WebSockets is the standardized solution for this.


WebSockets seems to be here to stay, thus having the Lazarus backend 
communicate with a HTML5 / Java Script GUI front end seems like a very 
promising way to do do a remote GUI that might be rather close to what 
is possible with locally the LCL.


-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Sven Barth


Am 29.11.2013 12:07, schrieb Santiago Amposta:

Beside this, there are concerns with http protocol, it is document
oriented, not connection oriented. For example, unless you keep the
connection open, every event from GUI to application, even a single
byte,  must send a lot header information, let alone if you use cookies
that are sent with every connection. There are workarounds, comet, html5
websockets, perhaps with some drawbacks.

WebSockets is the standardized solution for this.

Regards,
Sven

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/29/2013 11:55 AM, Mark Morgan Lloyd wrote:


That goes back to some of the earliest Netscape versions, IIRC it was 
originally used to update images periodically. While attractive, this 
sort of thing can turn into a nightmare if the browser on an end 
user's system leaks memory until an entire page (i.e. not just part of 
the DOM describing the page) is forcibly reloaded- BTDT.


Do we still need to take into account that a browser is that limited ? 
Browser technology has advanced a lot during the passed few years.


As HTML5 is a strong recommendation for "active" web page programming I 
find it hard to believe that spontaneous server-initiated messages is 
not cared for in any decent way with modern servers and browsers.


-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Michael Van Canneyt




On Fri, 29 Nov 2013, Santiago Amposta wrote:



The solution to this problem is quite easy, and it is what many web-GUI
interfaces do: Move part of program to the client side, so they send big
javascripts to the client. No objection, I don't think it's a big deal
to send javascript libraries to the client, as long as it is transparent
for me as developer. What I intend to avoid, when I write an
application, is having to write half application in pascal and half
application using javascript. I want to write the whole application in
pascal and let the libraries use javascript or whatever they want.

Probably I'm demanding too much, there is no way a component can say "I
will convert this few lines of code into a javascript and send it to the
client"


That is exactly my plan:

1. Convert pascal to javascript.
2. Use the custom widget design capabilities of Lazarus to design the form.

Just like Morfik does/did, and recently Smart Mobile studio.

But only in Lazarus :)

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Mark Morgan Lloyd


Michael Schnell wrote:

On 11/28/2013 04:39 PM, Michael Van Canneyt wrote:

These days it is very easy to make a very responsive web gui.
"Responsiveness" (the program reacts to user input) is not the problem I 
meant to describe but the ability of the program to issue "state" 
messages spontaneously.


This is hampered by the missing symmetry of the http protocol: The 
client needs to poll for such "reverse" messages.


It appears that around 50% of our external network traffic is caused by 
a colleague who leaves a significant number of browser windows open each 
with Javascript which periodically polls for server-side updates.


Almost anything is better than getting tarred with that brush.

This can partly be improved by techniques like "comet" that leave a http 
protocol open in a somewhat "non-standard" way. But AFAIK, this does 
result in certain problems.


That goes back to some of the earliest Netscape versions, IIRC it was 
originally used to update images periodically. While attractive, this 
sort of thing can turn into a nightmare if the browser on an end user's 
system leaks memory until an entire page (i.e. not just part of the DOM 
describing the page) is forcibly reloaded- BTDT.


--
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.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop

2013-11-29 Thread Santiago Amposta

El 28/11/2013 15:01, Michael Van Canneyt escribió:
>
>
> On Thu, 28 Nov 2013, Santiago A. wrote:
>
>>
>> Perhaps Lazarus should start thinking about a widget "html+javascript"
>> and  prioritize it.
>
> I am laying the groundwork for this since some years. It is not an
> easy task if you want to do it correctly.
>
> Michael.

I have made a small test program, by hand, with no LCL and no RAD
utilities. It is boring and a lot of dirty work, but not difficult (If I
could do it, it can't be difficult, my programming skills are rusted
after years of programming sales reports). I have taken a look at QT
widget, and perhaps it shouldn't be that difficult integrating web with LCL.

Nevertheless I have found issues that have little to do with RAD, they
are related to the concept of remote GUI itself.

Let's suppose you have a checkbox that when cheked must enable some
controls. In a common desktop the event is sent to the application, and
application process the event and tells the GUI which controls must
enable. But if the application is remote, the roundtrip may take 30 ms,
add a cascade of events triggered and you get that you uncheking a
chekbox the application gets stalled for a moment or more (I read
somewhere that to get the "no time" perception it must react in less
than 100ms). I said 30ms but it could be 200ms depending on the
connection, and then the moment may become a second.

The solution to this problem is quite easy, and it is what many web-GUI
interfaces do: Move part of program to the client side, so they send big
javascripts to the client. No objection, I don't think it's a big deal
to send javascript libraries to the client, as long as it is transparent
for me as developer. What I intend to avoid, when I write an
application, is having to write half application in pascal and half
application using javascript. I want to write the whole application in
pascal and let the libraries use javascript or whatever they want.

Probably I'm demanding too much, there is no way a component can say "I
will convert this few lines of code into a javascript and send it to the
client"

Beside this, there are concerns with http protocol, it is document
oriented, not connection oriented. For example, unless you keep the
connection open, every event from GUI to application, even a single
byte,  must send a lot header information, let alone if you use cookies
that are sent with every connection. There are workarounds, comet, html5
websockets, perhaps with some drawbacks.

What is your approach to these questions?

-- 
Regards
Santiago A.
s...@ciberpiula.net

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/28/2013 11:57 PM, Dmitry Boyarintsev wrote:

Then go ahead. Lazarus does allow creation of backends.
They just having to do with LCL.


The problem is not that it does not make sense. The problem is that it 
is a huge task.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/28/2013 10:29 PM, Santi wrote:
I don't want to use Lazarus because it is the last defender of "Native 
controls" against the evil "web-controls". I want to use Lazarus 
because I want to use a powerful language like Pascal in the backend 
and a framework with a RAD that allows me write GUI interfaces quickly.


Yep.

Because it wants to provide RAD, the LCL GUI designer is one of the most 
easy to use GUI designers. I once failed on trying to find an "active" 
web page designer tool that comes anywhere close regarding user 
friendliness.


Thus for me a "Web GUI" LCL Widget type makes a huge lot of sense (even 
if the count and features of the widgets  usable in this mode is 
restricted vs the "local" widgets.


In fact it should be possible to switch between "Web GUI" and "local 
GUI" just by setting the Widget type variable. Decent messages for stuff 
that does not work on the WebGUI appreciated.


Something similar once had been tried with "EXT Pascal", but AFAIK, the 
project died.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop


On 11/28/2013 05:39 PM, Dmitry Boyarintsev wrote:
Even if LCL will start "web target" today, it will be 10 years later 
that LCL can be used without problems.

You don't seem to know what Michel v C and friends can do :-) :-)

-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] The future of desktop