Re: [Lazarus] Web vs desktop development

[Dariusz Mazur]

On 2016-01-18 11:52, Graeme Geldenhuys wrote:

On 2016-01-18 10:22, Dariusz Mazur wrote:

on web much less data ar drawn from serwer

That is debatable. Back in the day (circa 1994) loading a web page with
stacks of content was in the region of 100-200KB max. Now you load a
page with hardly any content and it is a 5-8MB download!! When last did
you actually measure web traffic in your browser?

I've not talk about webside only  about (my) webapp.
And not about data throughput  only storage information (sorry for 
imprecise)

Of course you have to load bitmaps/js/css but only one time.

I've measure web traffic on my application very often:
 most of request are shorter than 1 Ethernet frame,
full page reload  take 100kb.

It is on line demo on which everybody cane try, but in polish.


--
Darek





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

Re: [Lazarus] Web vs desktop development

[Dariusz Mazur]

On 2016-01-17 02:10, Graeme Geldenhuys wrote:

On 2016-01-15 17:29, Anthony Walter wrote:

For businesses web development is probably a better fit for their software
needs.

Yes in a way I see that, but having worked in the past (2014) in a 100%
web based company developing online banking and mortgages software, I
have seen first hand it is not all sunshine and roses - although
everybody on the web wants you to believe it is.
We write our business application as web from several years. Its the 
same as desktop version, and development are done parallel as 90% of 
both version have the same source code.  And i have some others 
consideration:





* Browser incompatibility plagued us every other day. Even different
versions of the same browser caused problems (eg: Chrome being a big
culprit).
Current browsers on base task are behave near equals. Of course new 
features discover new problems, but after some time there are gone also.




* There seems to be a million and one web technologies. So you start
your project using this and that. Six months later they all go... Oh
that is so old school, or component A is now the coolest toy on the web,
so we should rather use X and Y instead. This cycle never ends. Web
technologies or components come and go WAY to quick.

This is main problem. But we choice ... VCL.
Some of assumptions:
on application forms and widgets have the same architecture as VCL: 
forms, windows, controls, fonts, near the same API


server build only HTML , each frame and widgets and data, but all look 
are done by CSS+JS on browser side.
Application has one page form, all  changes are transfer thought AJAX or 
websockets (similar as http://www.webtoolkit.eu/wt)




each user action (click, touch) are transfer to application  and browser 
receive new content, this sound time bottleneck, but only seemingly,

this take less than 80ms , painting go longer.





* Security was a major concern





* Most web code look absolutely horrible! Desktop software is not
immune, but they seem to have more practise in good design.
JS/CSS/HTML are hard to make good design, thus only smart part we write 
on it, most are in Pascal


* Update Deployments were a nightmare - not nearly as easy as they make
you believe.

why?



* Testing and Quality assurance is really hard.
we don't notice difference from desktop, but theoretically its easier to 
imitate browser and testing behaving click by click.




--
Darek



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

Re: [Lazarus] Web vs desktop development

[Dariusz Mazur]

On 2016-01-15 19:01, Dmitry Boyarintsev wrote:
On Fri, Jan 15, 2016 at 12:29 PM, Anthony Walter > wrote:


For businesses web development is probably a better fit for their
software needs.

For people who are computer enthusiasts that use their computers
to process tasks or solve problems, desktop development is
probably better.

What are your opinions on the subject title ?


I think you're missing security considerations as well.

When a desktop application is compromised, it's likely that only a 
particular user would a victim.

For web-applications, all users might be compromised as well.

Thats only one side. On desktop when one application is compomised, all 
others may be also. And much of attacs are done throught acrobat  and 
others plugin or semi desktop application.


Many of client-server (desktop) application have poorer sercurity than 
web application. VPN only protect link machine-machine , but https 
protect application-application
And last but not least: on web much less data ar drawn from serwer,and 
the same when stolen local computer is not equal data stolen


--
Darek

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

Re: [Lazarus] The future of desktop

[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

[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

[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] unit on relative path is not recompile

[Dariusz Mazur]

On 2013-09-30 17:13, Mattias Gaertner wrote:

On Mon, 30 Sep 2013 16:35:30 +0200
Dariusz Mazur  wrote:


On 2013-09-27 17:03, Mattias Gaertner wrote:

On Fri, 27 Sep 2013 16:59:04 +0200
Dariusz Mazur  wrote:


Hi

I've noticed than lazarus (1.0.12) don't recompile units, which are
include in program on relative path

program p;
uses
 u1 in '..\..\test\u1.pas';
begin
...
end;


Is "..\..\test\u1.pas" listed in the project inspector?

no,
only mention u1 with name in main file.

Add it. Then the IDE will check the file date.

  

After change something in u1, even in full build u1 is not recompile.

What do you mean with "full build"?


Shift F9



I've made some test

1. When u1 is not compiled (u1.o and u1.ppu removed) everything is OK.
FPC prepare units, program work .
2.After this I change u1.pas, and press Shift-F9.  Source is saved, buf
ppu is not changed. Program is linking with old ppu.

Sounds like compiler bug.

Please create a bug report.


done:
http://bugs.freepascal.org/view.php?id=25119

Darek

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

Re: [Lazarus] unit on relative path is not recompile

[Dariusz Mazur]

On 2013-09-27 17:03, Mattias Gaertner wrote:

On Fri, 27 Sep 2013 16:59:04 +0200
Dariusz Mazur  wrote:


Hi

I've noticed than lazarus (1.0.12) don't recompile units, which are
include in program on relative path

   program p;
uses
u1 in '..\..\test\u1.pas';
begin
   ...
end;


Is "..\..\test\u1.pas" listed in the project inspector?

no,
only mention u1 with name in main file.


After change something in u1, even in full build u1 is not recompile.

What do you mean with "full build"?


Shift F9



I've made some test

1. When u1 is not compiled (u1.o and u1.ppu removed) everything is OK. 
FPC prepare units, program work .
2.After this I change u1.pas, and press Shift-F9.  Source is saved, buf 
ppu is not changed. Program is linking with old ppu.



Darek


PS. Sorry for late answer, I must leave for some days.

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

[Lazarus] unit on relative path is not recompile

[Dariusz Mazur]

Hi

I've noticed than lazarus (1.0.12) don't recompile units, which are 
include in program on relative path


 program p;
uses
  u1 in '..\..\test\u1.pas';
begin
 ...
end;


After change something in u1, even in full build u1 is not recompile.
If I added path '..\..\test\' to directory options everything is ok.
Is this bug or I've miss something

Darek


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

Re: [Lazarus] IDE change source itself

[Dariusz Mazur]

W dniu 2013-05-29 09:59, Mattias Gaertner pisze:

On Wed, 29 May 2013 09:54:44 +0200
Dariusz Mazur  wrote:


W dniu 2013-05-29 07:55, Mattias Gaertner pisze:

On Tue, 28 May 2013 20:07:11 +0200
Dariusz Mazur  wrote:


Hi
I have problem with editor under Win8

If I try edit attached file, IDE remove some of chars from source.
There are some of diacritic chars from different code page, but I think,
editor mustn't it changed.
Is this know behavior? Is this bug?

Simply opening and saving a file should at most alter #0,#10,#13
characters.
Editing might change invalid characters. There can be invalid
characters if you open a file with the wrong encoding. You change the
encoding via Right click / File settings / encoding.

I don edit line with weird characters, and I think editor shouldn't
change it.

Then please create a bug report and steps to reproduce.

http://bugs.freepascal.org/view.php?id=24510


--
  Darek




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

Re: [Lazarus] IDE change source itself

[Dariusz Mazur]

W dniu 2013-05-29 01:35, waldo kitty pisze:

On 5/28/2013 14:07, Dariusz Mazur wrote:

Hi
I have problem with editor under Win8

If I try edit attached file, IDE remove some of chars from source.
There are some of diacritic chars from different code page, but I 
think, editor

mustn't it changed.
Is this know behavior? Is this bug?

I use Lazarus x64 ver 1.08 (under Linux was everything ok)


what codepage are you using? what codepage(s) are the missing 
characters in? perhaps a different codepage is needed to be able to 
represent both?



I don't need  IDE to represent this characters only not remove them

i ran into something similar in other products where a text file was 
being seen as UTF-8 because it contained double byte characters... the 
solution was to tell that editor to "convert" (not really) to ANSI 
(yes, wrong nomenclature) and then the display the file using 
WIN-1252... the characters in question were Cyrillic...





--
  Darek




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

Re: [Lazarus] IDE change source itself

[Dariusz Mazur]

W dniu 2013-05-29 07:55, Mattias Gaertner pisze:

On Tue, 28 May 2013 20:07:11 +0200
Dariusz Mazur  wrote:


Hi
   I have problem with editor under Win8

If I try edit attached file, IDE remove some of chars from source.
There are some of diacritic chars from different code page, but I think,
editor mustn't it changed.
Is this know behavior? Is this bug?

Simply opening and saving a file should at most alter #0,#10,#13
characters.
Editing might change invalid characters. There can be invalid
characters if you open a file with the wrong encoding. You change the
encoding via Right click / File settings / encoding.


I don edit line with weird characters, and I think editor shouldn't 
change it.

In source some times i mix strings with different code page (don't ask why)

most of editors don't change it, even if they can't show proper characters

Darek


--
  Darek




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

[Lazarus] IDE change source itself

[Dariusz Mazur]

Hi
 I have problem with editor under Win8

If I try edit attached file, IDE remove some of chars from source.
There are some of diacritic chars from different code page, but I think, 
editor mustn't it changed.

Is this know behavior? Is this bug?

I use Lazarus x64 ver 1.08  (under Linux  was everything ok)


--
  Darek




unit testchar;

interface


const
  setLiter1= 
['0'..'9','A'..'Z','a'..'z','†','«','�','ľ','˘','ä','©','�','Ą','Ź','Ť','—','˝','ŕ','ă','¨','ť','¤'];
  setLiter2= 
['0'..'9','A'..'Z','a'..'z','†','«','=','ľ','˘','ä','©','�','Ą','Ź','Ť','—','˝','ŕ','ă','¨','ť','¤'];

 

implementation

end.

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

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

 W dniu 2010-12-02 11:38, michael.vancann...@wisa.be pisze:



On Thu, 2 Dec 2010, Dariusz Mazur wrote:


W dniu 2010-12-02 09:25, michael.vancann...@wisa.be pisze:



On Thu, 2 Dec 2010, Dariusz Mazur wrote:



ExtPascal uses threads to handle multiple connections. I remember 
you

don't accept this way, right? BTW, what is there wrong if ExtPascal
uses threads?


I accept using threads, but not the way ExtPascal does it. Threads 
should be
optional. In extpascal, the thread is equal to the session: if you 
have many
sessions, the application will create as many threads as there are 
sessions.


I use different architecture: each session has own thread and each 
connection has own thread. Sessions are separated from connections 
and communicate via FIFO queue.
Session runs whole life time in the same thread. With this i can 
use modal form and thread var in the same manner, as normal 
(desktop) application.


I understand this is the easy way.

But you don't need this architecture to do that. As long as a single 
request
runs in a single thread, there is no problem with decoupling 
sessions and

threads, and still be able to keep everything in memory.


I dont understand.
I parse single request in single thread (for each request new thread)
and what can I do (other) with sessions?


One scenario looks like this:
- Request comes in (on whatever thread).
- Determine session data (your form) for the request.
  Session data is in a global list.
- Find a thread to handle the request.
- Pass session data to thread and let it handle request.

Another way is
- Connection is accepted.
- An idle thread to handle request is found.
- Thread looks up session data from data in request.
- Thread handles request using found session data.



At the beginning I use second attempt, after that first. But both have 
limitation, because not follow (not act as desktop OS) desktop architecture.
There are  not pass to more complicated application (when it is porting 
from Delphi).


1. All task of application should be prepare as response for request, 
there is problem with modal forms, which stop and wait to user action, 
and after response go on (next statement in current procedure, not other ).
2.  When application is busy for long time with preparing response, its 
no chance to make simple response with message of waiting (or progress bar)
3. With second attempt session data is computing with different threads, 
thus thread vars can't be used





--
  Darek





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

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

 W dniu 2010-12-02 09:25, michael.vancann...@wisa.be pisze:



On Thu, 2 Dec 2010, Dariusz Mazur wrote:




ExtPascal uses threads to handle multiple connections. I remember you
don't accept this way, right? BTW, what is there wrong if ExtPascal
uses threads?


I accept using threads, but not the way ExtPascal does it. Threads 
should be
optional. In extpascal, the thread is equal to the session: if you 
have many
sessions, the application will create as many threads as there are 
sessions.


I use different architecture: each session has own thread and each 
connection has own thread. Sessions are separated from connections 
and communicate via FIFO queue.
Session runs whole life time in the same thread. With this i can use 
modal form and thread var in the same manner, as normal (desktop) 
application.


I understand this is the easy way.

But you don't need this architecture to do that. As long as a single 
request

runs in a single thread, there is no problem with decoupling sessions and
threads, and still be able to keep everything in memory.


I dont understand.
I parse single request in single thread (for each request new thread)
and what can I do (other) with sessions?


--
  Darek





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

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

ExtPascal uses threads to handle multiple connections. I remember you
don't accept this way, right? BTW, what is there wrong if ExtPascal
uses threads?


I accept using threads, but not the way ExtPascal does it. Threads 
should be
optional. In extpascal, the thread is equal to the session: if you 
have many
sessions, the application will create as many threads as there are 
sessions.


I use different architecture: each session has own thread and each 
connection has own thread. Sessions are separated from connections and 
communicate via FIFO queue.
Session runs whole life time in the same thread. With this i can use 
modal form and thread var in the same manner, as normal (desktop) 
application.




Under normal circumstances you would have a fixed (or limited) thread 
pool, and each request is  handled by a free thread in the pool. So 
requests of

a session can (and will) be handled by different threads.





In ExtPascal, it is impossible to separate the thread from the session.
This has the advantage of being simple, but doesn't scale, and creates 
unneeded dependencies between different parts of the software.


that is next point


--
  Darek





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

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

 W dniu 2010-11-24 19:06, Michael Van Canneyt pisze:



On Wed, 24 Nov 2010, Dariusz Mazur wrote:

That's not true. Transfer every action to server is very simple 
task, and computing results also. Thus (on my web app) it took less 
than 10ms and every user very rare generate more actions than 1 per 
second.  Computing and sending pdf reports took much more (more 
than 90% of working time). As I observe two on core machine can 
work 100 users concurent without problem. With more can be problem, 
but  with memory.


Yes, I remember my discussion with you. I also remember that the 
round trip time I observed is over 100 ms, which is noticeable. 
(maybe not on intranet, but definitely on internet)


You told about scalability.
10ms is on server, on user side You should add transfer as ping (but 
this not load server)


Let me put it differently. In the interface I was talking about, I 
need exactly 3 HTTP requests, no matter how much the user clicks/hits 
keyboard to set checks:

1. Fetch form 2. Fetch data.
[grid is built on client using fetched data]
3. Save Data (user presses save buton)

Your implementation needs 3 (maybe 2) requests to fetch form and data 
and process save, plus additionally a request for each user 
click/keyboard hit to set a check.

1.Fetch form with data
 after user action: request what should change: server test its 
validity, and generate new value for changed widgets

on most cases it took only one frame
2.Save button send nothing but number of button




If that is correct, I don't even need to build these 2 systems to know 
that my system will scale better.




And - unless I understand your code wrong - you keep the complete form 
state on the server ? (I.e. keep a pascal instance of all visible

TForms and controls in memory).

yes, then same as in desktop,
but also compute of data,  size of "visible" control doesn't matter with it


I don't need that at all. The amount of data I need on the server per 
user session is roughly 200 bytes, and it doesn't much change during 
the session.


In module computing as OLAP I need 10..100MB during session



Again, if my assumption is correct, my system again scales better, 
because it does not need nearly the memory your system uses.


Of course. I didn;t say not. But many Delphi todays application need 
involve strong interaction between database and user front end. Very 
often, after user actions, rather complicated computation on huge amount 
of data is done, and its transfer to forms.
My approach has better scalability from programmer side: I don;t need 
thing about browser, what should compute server and what not. Browser 
paint beautiful widgets (with CSS3,HTML5) similar as OS Windows or GTK, 
QT. All rest i've done without care which widgets set will be used.  
That is enough fast to service 100 concurrent user , with higher demand 
I can  use cluster.





Looking at recent trends (Ajax, rich client interface toolkits) people 
agree more with me than with you. But I may definitely be wrong; 
everybody sees the world through his own spectacles...
Most of webapp are rather simple (counting forms and controls) compare 
to desktop app. For example even advanced internet shop has ten times 
less function than average store or POS application.
We talk about choose between fat and thin client. Both have good and bad 
use case.





Secondly, you have not very demanding users and/or GUI, it seems :-)
Of course this is not game application, but on every ERP application 
(like my)  are places with rather sophisticated GUI.


I'll describe an interface which I currently have: A grid with about 
600 checkboxes (don't ask why, they want it so).  Users click the 
checkboxes in rapid succession, thus generating much more than 1 
event per second.


I have forms with similar widgets too. Second: faster than clicks is 
keyboard.


Well, most likely not if you must check which key was pressed, discard 
bad keypresses etc, on the server.


On ordinary input not, but I use this on dictionary searching thought 
grid. I simply observe what users do in real.





I also proposed keyboard but they require the mouse :(


This is user choose, not us. Both should work good. Today i thinking 
about fingers (on iPhone, Android)




But even that: its no problem when response arrive after next click. 
If response is under 300ms users thinks : "that is at now"


On average the user sets 50 checkboxes before he presses save.
50x300ms = 15.000 Ms = 4 minutes just to process the checks ?
I don't think so :-)


You don understand. This is not sequential but pipelining. Man need 
50*100ms (I dont think its so fast) Server need 50*10ms. Browser (and 
user) don't need wait to response



But different behavior of user: after 10 min and clicking 50  user press 
RELOAD on browser: whats happens?








But if you believe in it: why not cooperate with the Lazarus team and
create a web widget set ?

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

On Wed, 24 Nov 2010, Dariusz Mazur wrote:


W dniu 2010-11-24 10:21, michael.vancann...@wisa.be pisze:



On Wed, 24 Nov 2010, ik wrote:


Hello List,

Well I know about the framework fur Javascript library in Lazarus, 
but I'm

thinking in the past year or so, what will it take to design a gui
application using Lazarus, and make it work like a web app that act 
the same

as the desktop version, without any specific components for it.

Then today I found the following link:
http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ and it looks 
like

someone made something like that on GTK3.
The problem is that I do not have the time to do it myself (or I 
would have
created at least the start for it), what will it take to create 
something
like that for Lazarus that is not dependent on the widgets (it will 
not care
if it's GTK, Qt, WinAPI etc..), and take also 3rd party components 
for it ?


You should first answer the question this man asks:

"Now, I want to know, Is this useful?"

The answer IMHO is: no.

Each and every GUI or user action/change/whatnot will result in a 
request from the browser to the webserver (with corresponding result 
sent back), and will cause a lot of traffic.


While this is fine and doable for small apps, it is not scalable at 
all. If 100 users use your system, it will crash under the load (if 
not earlier).


That's not true. Transfer every action to server is very simple task, 
and computing results also. Thus (on my web app) it took less than 
10ms and every user very rare generate more actions than 1 per 
second.  Computing and sending pdf reports took much more (more than 
90% of working time). As I observe two on core machine can work 100 
users concurent without problem. With more can be problem, but  with 
memory.


Yes, I remember my discussion with you. I also remember that the round 
trip time I observed is over 100 ms, which is noticeable. (maybe not 
on intranet, but definitely on internet)


You told about scalability.
10ms is on server, on user side You should add transfer as ping (but 
this not load server)




Secondly, you have not very demanding users and/or GUI, it seems :-)
Of course this is not game application, but on every ERP application 
(like my)  are places with rather sophisticated GUI.


I'll describe an interface which I currently have: A grid with about 
600 checkboxes (don't ask why, they want it so).  Users click the 
checkboxes in rapid succession, thus generating much more than 1 event 
per second.


I have forms with similar widgets too. Second: faster than clicks is 
keyboard.  But even that: its no problem when response arrive after next 
click. If response is under 300ms users thinks : "that is at now"







But if you believe in it: why not cooperate with the Lazarus team and
create a web widget set ? All options must be explored, you obviously 
have a good basis for it, so why not share it 


I try to share my work  (without this hope I simply not write this post) 
but nobody is interesting.

link: http://www.emadar.com/fpc/xwebdemo.zip



--
  Darek





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

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

2010/11/24 ik:

SilverLight/Moonlight are the wrong way to do things (so does Flash). HTML5
provide in the DOM support for Canvas (you have some games for it), And IE9,
Webkit, Opera and Gecko support it, so it's like 99% of web browsers that
support for it.

But the HTML5 Canvas is only programmable in Javascript.


You can generate script on server, send it via AJAX to browser and execute


--
  Darek





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

Re: [Lazarus] GUI development for web UI

[Dariusz Mazur]

 W dniu 2010-11-24 10:21, michael.vancann...@wisa.be pisze:



On Wed, 24 Nov 2010, ik wrote:


Hello List,

Well I know about the framework fur Javascript library in Lazarus, 
but I'm

thinking in the past year or so, what will it take to design a gui
application using Lazarus, and make it work like a web app that act 
the same

as the desktop version, without any specific components for it.

Then today I found the following link:
http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/ and it looks like
someone made something like that on GTK3.
The problem is that I do not have the time to do it myself (or I 
would have
created at least the start for it), what will it take to create 
something
like that for Lazarus that is not dependent on the widgets (it will 
not care
if it's GTK, Qt, WinAPI etc..), and take also 3rd party components 
for it ?


You should first answer the question this man asks:

"Now, I want to know, Is this useful?"

The answer IMHO is: no.

Each and every GUI or user action/change/whatnot will result in a 
request from the browser to the webserver (with corresponding result 
sent back), and will cause a lot of traffic.


While this is fine and doable for small apps, it is not scalable at 
all. If 100 users use your system, it will crash under the load (if 
not earlier).


That's not true. Transfer every action to server is very simple task, 
and computing results also. Thus (on my web app) it took less than 10ms 
and every user very rare generate more actions than 1 per second. 
 Computing and sending pdf reports took much more (more than 90% of 
working time). As I observe two on core machine can work 100 users 
concurent without problem. With more can be problem, but  with memory.



More to the point would be the morfik approach:
- Design and code your app as you do now.


yes. I compile the same code for Web and desktop


- Translate the lot to Javascript+HTML+CSS

nothing translate
every widget on form generate string consists several  and other 
html tokens

JS consists behaviour of widgets and communication API (rather consts)
CSS describe look of widgets

Because then, the browser does all the GUI work, and only when 
necessary (get

data from server or store data on server) does the server get a request.

I am building all blocks for the latter approach, but it is slow 
progress.


My clients use it every day. Web has about 95% of usability of desktop. 
Today I prefer web approach, because its easy to make something 
beautiful (with CSS3  only several lines and widget get shadow, 
background , animations etc.







--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-21 09:51, Michael Schnell pisze:

 On 09/18/2010 06:08 PM, Dariusz Mazur wrote:

 with CILK approach we deal with task, not threads.

IMHO this does not make much sense.

For the user-programmer, the relevant difference between tasks and 
threads is that thread share memory.


This results in the increasing complexity with mutually accessed 
variables which of course provides a real challenge.


But you can think of a programming paradigm (=CILK") that does not 
allow the user programmer to share the variables between the "tasks" 
even though the "tasks" in fact are threads as far as the OS is 
concerned.


Not the tasks switch is done with a lot less overhead as the OS does 
not need to change the environment (such as MMU tables), the cache is 
used more efficiently (especially on ARM as here the cache needs to be 
cleared with each change in the MMU tables).


The communication between the tasks (here done not by the user but by 
would be automated the system (e.g. CILK) would be a lot faster when 
it uses threads instead of processes, as it could easily make uses of 
shared memory (though hidden from the user).


I don;t understand. You say "processes" , but i don't talk about it.  
Task for me (in CILK approach) is thing, that only program itself  care 
about without OS help (as in threads).
Task is function, which can be invoke by worker any time (similar to 
events) and stop on sync.   Deal with memory is the same as normal MT 
program.  Workers run as normal threads.




--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-20 16:03, Mattias Gärtner pisze:

Zitat von Dariusz Mazur :


[...]
Most of programs are huge count of simple computing. There are many 
places, that things may run parallel without pain. But very often 
this places are computing short, thus very often overhead of starting 
thread is bigger than using second core. But CILK potentially (I can 
prof that, only imagine) reduce this overhead. Second : its very 
readability solution, and compiler potentially can warning about some 
danger . If we try to concurrency smaller things, without loss 
efficiency, danger   will be minimize


Start a wiki page with a proposal for the syntax.
Create a unit like mtprocs that demonstrates CILK and how the syntax 
should be converted by the compiler.

Find someone to implement and, more important, maintain this.
Then there is a good chance to get this into the fpc main branch.
I know, every one say this. But without help (or even permission) of 
core developer its none chance to achieve this. I can prepare some of 
units, but because i;m rather poor with documentation its little chance 
to achieve this.




[...]

Even the mtprocs does that.
http://wiki.lazarus.freepascal.org/Parallel_procedures#Features

realy?
cite:" a procedure or method is executed with an Index running from 
an arbitrary StartIndex to an arbitrary EndIndex"


assigning iteration to threads are done on start loop, eq. we must 
know count of iteration.

what when iteration 1 is ten times longer than rest?


Then the other threads will sleep OR if this is a nested sub procedure 
the other threads will continue on the other work.

For example:

for i:=1 to 10 paralleldo
  for j:=1 to 10 paralleldo begin
if j=1 then DoAlotOfWork else DoLittleWork;
  end;

With mtprocs all threads will work until the end when the everything 
was done except the last DoAlotOfWork, which is then executed by only 
one thread.


mtprocs is just a unit, it can not auto parallelize DoAlotOfWork as a 
compiler could.
No, its just by architecture. Iterations are divide between threads. 
Because thread are limited and costly we must limit granularity.

CILK may work the same, also with loops, but main difference is under.




[...]
I thinking about Fifo queue, I use one Lock free,
its need 16 byte per spawn (func addres, param and result)
time of swich less than 1us


Are you sure about the 1us switch? The algorithm looks more dramatic.


Which algorithm? I say about pop and push form lock free queue. I use 
this heavy with my webserver to distributing messages.



--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-20 16:09, Sven Barth pisze:

Am 20.09.2010 15:22, schrieb Dariusz Mazur:

W dniu 2010-09-20 13:55, Mattias Gärtner pisze:

Zitat von Dariusz Mazur :


[...]

Before using multi threading, try to use a better single threaded
algorithm. And when comparing multi with single threading speed, you
must not compare a multi threaded algorithm running single threaded,
but
a multi threaded algorithm with a good single threaded algorithm.

I don;t talk about best solution of fibbonaci computing. But about
possibility do deal with some class of task using multithreading.
Its easy imagine task, which is hard to resolve with loops.


Of course.
I think, we both agree that CILK is a nice approach.

Nice to hear this.

I just said, that there are not many multi threading examples that are
easy to read and are practical at the same time. Computing Fibonacci
numbers does not need multi threading.


Most of programs are huge count of simple computing. There are many
places, that things may run parallel without pain. But very often this
places are computing short, thus very often overhead of starting thread
is bigger than using second core.


You are aware that for using a second core you need a thread (no 
matter how fancy a syntax construct hides it)? Thus for reducing the 
overhead of creating a thread at least one thread per core must be 
created before the first call of a "spawned" function/procedure.
Of course, Some of workers (threads) sleep, Also queue must be 
initializing. But i think its not a problem.


--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-20 13:55, Mattias Gärtner pisze:

Zitat von Dariusz Mazur :


[...]

Before using multi threading, try to use a better single threaded
algorithm. And when comparing multi with single threading speed, you
must not compare a multi threaded algorithm running single threaded, 
but

a multi threaded algorithm with a good single threaded algorithm.
I don;t talk about best solution of fibbonaci computing. But about 
possibility do deal with some class of task using multithreading.

Its easy imagine task, which is hard to resolve with loops.


Of course.
I think, we both agree that CILK is a nice approach.

Nice to hear this.
I just said, that there are not many multi threading examples that are 
easy to read and are practical at the same time. Computing Fibonacci 
numbers does not need multi threading.


Most of programs are huge count of simple computing. There are many 
places, that things may run parallel without pain. But very often this 
places are computing short, thus very often overhead of starting thread 
is bigger than using second core. But CILK potentially (I can prof that, 
only imagine) reduce this overhead. Second : its very readability 
solution, and compiler potentially can warning about some danger . If we 
try to concurrency smaller things, without loss efficiency, danger   
will be minimize





Its simple example to show, that CILK can play with recurrence (even
with one invoke).

Yes.
BTW: Same for parallel loops. You can write the above as parallel loop:

...
  for i:=0 to 1 paralleldo begin
if i=0 then x := fib (n-1)
else y := fib (n-2);
  end;
  exit(x+y);
...

I doubt this run. Very soon you receive lack of threads. Second this 
two iteration has very different time of computing.

I don;t know approach, that balance this.


Even the mtprocs does that.
http://wiki.lazarus.freepascal.org/Parallel_procedures#Features

realy?
cite:" a procedure or method is executed with an Index running from an 
arbitrary StartIndex to an arbitrary EndIndex"


assigning iteration to threads are done on start loop, eq. we must know 
count of iteration.

what when iteration 1 is ten times longer than rest?



Of course mtprocs has some disadvantages, e.g. it uses slow critical 
sections and task size must be tuned by the programmer.





Third: readability is poor.


Compare this to OpenMP programs. ;)



[...]

CILK has different attempt to task scheduling., its fullfil
Work-requesting idea from
http://groups.google.com/group/lock-free/browse_frm/thread/18f90bdd8c721880 


That's an implementation detail.

This is not detail, but quite different attempt.


Parallel loops implementations can use
this too. There are for example plugins for OpenMP using work stealing.
Probably some use some form of work requesting too.
OpenMP is heavy framework, not suitable to all area. Some need 
something light. But as You notice, work stealing is not useless. Am 
best with strong integration with FPC.


Yes, that would be nice.
But some one should choose on approach, even weak, and start play with 
them. Till now every one (me too) complaint: my solution is better.




More on CILK documentation, I;m to weak in english.


Second: we not initialize thread on SPAWN (with
loops threads are initializing on start loop), Workers wait  for 
task on

idle. Push and pop task from queue can be very fast. Of course this
depend on implementation (for example each worker should deal 
with own

queue, but should be possibility to draw task form other queue, this
approach is faster than single MPMC FIFO queue)

Ehm, you know that parallel loops normally use thread pools, do you?

Thats resolved only one problem.
Thread switching is done slowly (less than 100Hz) and rather 
expensive,

thus we cant start  one thread per iteration. We should a priori pass
iteration to threads.

Of course. I don't know any parallel loop implementation starting one
thread per iteration (only in extreme cases).

But CILK can effective play with this.


I doubt that. For example:

for i:=1 to 1 do
  spawn DoSomething(i);

It will work (unless run out of mem), but it obviously needs some tuning.

but
for i:=1 to 100 do
  spawn DoSomething(i);

should work,


I thinking about Fifo queue, I use one Lock free,
its need 16 byte per spawn (func addres, param and result)
time of swich less than 1us

problem is with assigning local stack per task, my asm is too weak.


--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-20 09:25, Mattias Gaertner pisze:

On Sun, 19 Sep 2010 22:22:21 +0200
Dariusz Mazur  wrote:


   W dniu 2010-09-18 18:55, Mattias Gaertner pisze:
[...]

Whats about CILK http://en.wikipedia.org/wiki/Cilk


|_function_  fib (n: integer):integer;
var
  x,y : integer;
begin

 if (n< 2)  then exit(n)
 else begin

x :=_spawn_  fib (n-1);
y := fib (n-2);
_sync_;
exit(x+y);
end;
end;
|

[...]

Only the first 46 Fibonacci numbers fit into an integer, which a
simple loop can compute. I don't know any task scheduler
that produces less enough overhead to compute this faster.

But this is not that case. Its can`t be compared do iteration computing.
We can compare different algorithms. Faster than loop is cons array with
results, but this tell nothing.

Yes, it does:
Before using multi threading, try to use a better single threaded
algorithm. And when comparing multi with single threading speed, you
must not compare a multi threaded algorithm running single threaded, but
a multi threaded algorithm with a good single threaded algorithm.
I don;t talk about best solution of fibbonaci computing. But about 
possibility do deal with some class of task using multithreading.

Its easy imagine task, which is hard to resolve with loops.





Its simple example to show, that CILK can play with recurrence (even
with one invoke).

Yes.
BTW: Same for parallel loops. You can write the above as parallel loop:

...
   for i:=0 to 1 paralleldo begin
 if i=0 then x := fib (n-1)
 else y := fib (n-2);
   end;
   exit(x+y);
...

I doubt this run. Very soon you receive lack of threads. Second this two 
iteration has very different time of computing.

I don;t know approach, that balance this.
Third: readability is poor.


On real programs are many plays, that can be done
concurrency, but  when its to short, overhead in classic thread model is
too big (computing or programing time).


- OR practical, but hard to understand
?

Note: afaik CILK is the same as parallel loops:

No. On loop we divide iterations on start loops. When each iteration has
different  time of computing, we lost concurrence, because one thread
finish, but rest  work.

And how does CILK solve this?

Pass task to workers. Each SPAWN start new task.
But good implementation of background is needed.

Its very similar to thread model, but not so heavy. Even short task can
be computed efficiently

CILK has different attempt to task scheduling., its fullfil
Work-requesting idea from
http://groups.google.com/group/lock-free/browse_frm/thread/18f90bdd8c721880

That's an implementation detail.

This is not detail, but quite different attempt.


Parallel loops implementations can use
this too. There are for example plugins for OpenMP using work stealing.
Probably some use some form of work requesting too.
OpenMP is heavy framework, not suitable to all area. Some need something 
light. But as You notice, work stealing is not useless. Am best with 
strong integration with FPC.



More on CILK documentation, I;m to weak in english.


Second: we not initialize thread on SPAWN (with
loops threads are initializing on start loop), Workers wait  for task on
idle. Push and pop task from queue can be very fast. Of course this
depend on implementation (for example each worker should deal with own
queue, but should be possibility to draw task form other queue, this
approach is faster than single MPMC FIFO queue)

Ehm, you know that parallel loops normally use thread pools, do you?

Thats resolved only one problem.
Thread switching is done slowly (less than 100Hz) and rather expensive,
thus we cant start  one thread per iteration. We should a priori pass
iteration to threads.

Of course. I don't know any parallel loop implementation starting one
thread per iteration (only in extreme cases).

But CILK can effective play with this.


--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-18 18:55, Mattias Gaertner pisze:

On Sat, 18 Sep 2010 18:08:09 +0200
Dariusz Mazur  wrote:


   W dniu 2010-09-17 17:49, Mattias Gaertner pisze:

On Fri, 17 Sep 2010 14:09:59 +0200
Dariusz Mazur   wrote:


[...]
Whats about CILK http://en.wikipedia.org/wiki/Cilk


|_function_  fib (n: integer):integer;
var
 x,y : integer;
begin

if (n<2)  then exit(n)
else begin

   x :=_spawn_  fib (n-1);
   y := fib (n-2);
   _sync_;
   exit(x+y);
   end;
end;
|

Have you noticed that most examples for multi threading are either
- easy to understand, but completely impractical (the above is an
order of magnitude slower than single threaded)

I don;t agee. First with CILK approach we deal with task, not threads.
Thus we need good task passing to workers.
But seems, that this approach will be faster because on each SPAWN
invoke we add only task (and this is very simple and short function, as
add to FIFO queue)
And each worker (worker count is similar to cores) find task to do. Even
when task are very different (shorter and longer) gueue pass task to
worker with balancing .   Why You think  this will be magnitude slower I
don't know.

Only the first 46 Fibonacci numbers fit into an integer, which a
simple loop can compute. I don't know any task scheduler
that produces less enough overhead to compute this faster.


But this is not that case. Its can`t be compared do iteration computing. 
We can compare different algorithms. Faster than loop is cons array with 
results, but this tell nothing.
Its simple example to show, that CILK can play with recurrence (even 
with one invoke) . On real programs are many plays, that can be done 
concurrency, but  when its to short, overhead in classic thread model is 
too big (computing or programing time).









- OR practical, but hard to understand
?

Note: afaik CILK is the same as parallel loops:

No. On loop we divide iterations on start loops. When each iteration has
different  time of computing, we lost concurrence, because one thread
finish, but rest  work.

And how does CILK solve this?


Pass task to workers. Each SPAWN start new task.
But good implementation of background is needed.

Its very similar to thread model, but not so heavy. Even short task can 
be computed efficiently


CILK has different attempt to task scheduling., its fullfil 
Work-requesting idea from

http://groups.google.com/group/lock-free/browse_frm/thread/18f90bdd8c721880

More on CILK documentation, I;m to weak in english.




Second: we not initialize thread on SPAWN (with
loops threads are initializing on start loop), Workers wait  for task on
idle. Push and pop task from queue can be very fast. Of course this
depend on implementation (for example each worker should deal with own
queue, but should be possibility to draw task form other queue, this
approach is faster than single MPMC FIFO queue)

Ehm, you know that parallel loops normally use thread pools, do you?

Thats resolved only one problem.
Thread switching is done slowly (less than 100Hz) and rather expensive, 
thus we cant start  one thread per iteration. We should a priori pass 
iteration to threads.





It allows to make some
special cases need less typing, can increase readability and can
decrease overhead. As always with multithreading: wrongly used it can
make code run much slower.

Multithreading is not only for faster computing.

Does that mean, you agree?


I don;t agree with statement: multithreading is hard thus we don`t use them


--
  Darek




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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

 W dniu 2010-09-17 17:49, Mattias Gaertner pisze:

On Fri, 17 Sep 2010 14:09:59 +0200
Dariusz Mazur  wrote:


[...]
Whats about CILK http://en.wikipedia.org/wiki/Cilk


|_function_  fib (n: integer):integer;
var
x,y : integer;
begin

   if (n<   2)  then exit(n)
   else begin

  x :=_spawn_  fib (n-1);
  y := fib (n-2);
  _sync_;
  exit(x+y);
  end;
end;
|

Have you noticed that most examples for multi threading are either
- easy to understand, but completely impractical (the above is an
   order of magnitude slower than single threaded)
I don;t agee. First with CILK approach we deal with task, not threads. 
Thus we need good task passing to workers.
But seems, that this approach will be faster because on each SPAWN 
invoke we add only task (and this is very simple and short function, as 
add to FIFO queue)
And each worker (worker count is similar to cores) find task to do. Even 
when task are very different (shorter and longer) gueue pass task to 
worker with balancing .   Why You think  this will be magnitude slower I 
don't know.



- OR practical, but hard to understand
?

Note: afaik CILK is the same as parallel loops:
No. On loop we divide iterations on start loops. When each iteration has 
different  time of computing, we lost concurrence, because one thread 
finish, but rest  work.  Second: we not initialize thread on SPAWN (with 
loops threads are initializing on start loop), Workers wait  for task on 
idle. Push and pop task from queue can be very fast. Of course this 
depend on implementation (for example each worker should deal with own 
queue, but should be possibility to draw task form other queue, this 
approach is faster than single MPMC FIFO queue)



It allows to make some
special cases need less typing, can increase readability and can
decrease overhead. As always with multithreading: wrongly used it can
make code run much slower.


Multithreading is not only for faster computing.




--
  Darek





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

Re: [Lazarus] Threads in Lazarus code base

[Dariusz Mazur]

The parallel loop solves nothing which makes threading hard and is only
a cheap excuse. The real problems of threading are synchronization and
especially abording threads e.g. triggered by the main thread.




Whats about CILK http://en.wikipedia.org/wiki/Cilk


|_function_  fib (n: integer):integer;
var
  x,y : integer;
begin

 if (n<  2)  then exit(n)
 else begin

x :=_spawn_  fib (n-1);
y := fib (n-2);
_sync_;
exit(x+y);
end;
end;
|


  Darek




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

Re: [Lazarus] Lazarus make me create better apps

[Dariusz Mazur]

W dniu 2010-05-18 18:10, Bee Jay pisze:

There is a sense that web development work feels like writing mainframe apps in the 
early 1980s.  Its slower, more cumbersome and you have to feel like there must be a 
better way to do this.  The ability to craft a PC application quickly due to great 
IDEs, WYSIWYG tools, etc. has enabled development to be done quickly for the 
desktop environment.  I guess we're all just waiting for the day when web 
development can be done as fast.  I feel we are still a long way off, but it does 
mean that whoever can achieve this will ultimately dominate the web development 
space.  I look back to what it took to write the same application in 1985 in, say, 
Turbo Pascal, vs. embracing something like Delphi/Laz/FPC today, and its night& 
 day.  But despite advances in software engineering practices such as object 
oriented, design frameworks, etc. writing web apps today is still more like a TP 
app development project in 1985 than a Delphi desktop windows app in 2010.
 

EXACTLY! That's why I hate web app development in the first place. After more 
than 10 years being spoiled by Delphi and then Lazarus, writing web app today 
is like back to those TP days. Morfik had been trying to solve this very issue, 
but I don't think it's ready for the prime time yet. Somehow I feel that 
Morfik's solution is still incomplete. There's must be something missing, 
though I don't know for sure what it is.

   
I can say quite different. I like web development. From back side of 
program working with web and desktop is equal, thats doesn't matter. But 
front makes me happy: When I need new widget for special purpose, I 
must: write new descent class (several lines in pascal), 2-4 line of 
html (several divs),  then add several lines to CSS and add some png  
and thats all. I dont need fight with any pixels, rendering, etc, all 
this work has done in browser, debugging can be done online (with firebug)


--
  Darek






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

Re: [Lazarus] Lazarus make me create better apps

[Dariusz Mazur]

projects there are other people that forget to free some stuff.


What do you use?
Have you made any real app using some of these technologies and FPC?
I would like to use FPC for my web apps, but I don't see many examples...

Does anyone uses FPC for real web applications?


   
We also develop web application. Better: its the same application as 
desktop: mid size enterprise ERP
from web side its work as FCGI or embedded server, also with ssl,  can 
work on Linux or Win, as daemon or console application,
Also both version, desktop and web coexists, some users work local, some 
via browser

Since several weeks it can work on ARM too (not whole, but monitoring part)



its consists small part AJAX, CSS and several base units writes for web, 
but rest code (95%) is shared between desktop and web,


From developer view:
In normal code is no HTML and no Javascript.
Its consists forms, grids, modal windows, popup menus,  reports based on 
PDF, keyboard navigation, etc

Logically is very similar do LCL, VCL, with passing messages as in windows

if someone want to see: http://www.invoicer.pl/mobile  (freeware part)
For someone interesting I've prepare xweb library  with source, with it 
simple web app can be build.




--
  Darek





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

Re: [Lazarus] FCL-Web and new WebDesign packages

[Dariusz Mazur]

W dniu 2010-01-28 14:22, Graeme Geldenhuys pisze:

Adrian Veith wrote:
   

environments - I use pascal since 30 years for my every day development
and love it - but IMHO for web programming, it is more productive to
have a dynamic language - it is the nature of websites. (Free)-Pascal
 

A matter of taste I guess. I use pure Object Pascal to write all our CGI
applications. Our CGI apps do things PHP, JavaScript etc can only dream of!
Not to mention I have the full RTL, lots of the FCL and other non-GUI
frameworks at my disposal - and execution speed is probably magnitudes
faster too.

   
I fully agree. And add that Pascal are more suitable to maintain big 
application. There are few big projects dynamic languages comparable  to 
Delphi. Existing application for CMS, shopping, bugzilla etc.  are 
relative small.


But is big problem with distribution of such (pascal) programs. Boys 
from hostings firm  believe  more to PHP script (which has more holes 
than cheese)  than binary executables.



But in the end I'll take desktop GUI apps any day over Web apps. ;-)
   


I have it today. 500+ forms works on desktop and web from the same source.


--
  Darek





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

Re: [Lazarus] FCL-Web and new WebDesign packages

[Dariusz Mazur]

W dniu 2010-01-26 09:30, Graeme Geldenhuys pisze:

Joost van der Sluis wrote:
   

EmbWeb: Adds to possibility to FCL-Web to create webapplications with a
build-in webserver, based in LNet which is also included. Usefull for
debugging
 

I'm very interested in this feature. I have been looking at nYume (web
server implemented in less that 1000 lines of code) for a product we need
to distribute and run from CD-ROM. nYume is implemented in Object Pascal
(using FPC) and only adds 80KB to an executable.

Do you know how LNet's HTTP server compares to nYume?


   
I prefer HTTPServ from Synapse. It run on win32 and  linux (ARM also) on 
my production program.

It has SSL too, what is important to me.
But if  for some one is too slow, several changes should be added. 
Especially header parsing and generating (this from synapse is rather 
slow). And sometimes worth is compress request.



--
  Darek





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

Re: [Lazarus] Do FPC generates old EABI code?

[Dariusz Mazur]

Florian Klaempfl pisze:

Dariusz Mazur schrieb:
  

Kjow pisze:


2009/12/15  :
 
  

Should be
  Target OS: Linux for ARMEL

You have to recompile crosscompiller
Its not EABI (see my descuss with Jonas on fpc-devel)

make crosssinstal OPT="-dFPC_ARMEL" ...



This is the command that I used to make crosscompiler:

sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/home/kjow/lazarus/fpc/binutils/ CROSSOPT="-CaEABI
  
  
-dFPC_ARMEL -CfSOFT -gl -O-" INSTALL_PREFIX=/usr/

COMPILER_OPTIONS="cpufpemu"
  
  

sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/home/kjow/lazarus/fpc/binutils/ OPT="-dFPC_ARMEL"
CROSSOPT="-CaEABI -dFPC_ARMEL -CfSOFT -gl -O2" INSTALL_PREFIX=/usr/



add OPT, remove COMPILER_OPTIONS



Please, don't spread the nonsense of -CfSOFT -CaEABI, it's neither
  

This is no I, as You see upper:

make crosssinstal OPT="-dFPC_ARMEL" ...
add OPT, remove COMPILER_OPTIONS


I test about -CaEABI its not needed, then same with CROSSOPT="-dFPC_ARMEL

I know too few to say to omit some options
Jonas say about:  CROSSOPT="-dFPC_ARMEL
last time when I ask about reduction options everyone blame me


but how compiler know, that FPU is present or absent (-CfSOFT)?



needed nor desired. -dFPC_ARMEL is enough. Neither is -dFPC_ARMEL needed
 in CROSSOPT. It is only needed when the first arm compiler is built and
in this case OPT=-dFPC_ARMEL is enough.
  

for me better:  CPU_TARGET=armel  (similar as ARMEB)




--
 Darek





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

Re: [Lazarus] Do FPC generates old EABI code?

[Dariusz Mazur]

Kjow pisze:

2009/12/15  :
  

Should be
  Target OS: Linux for ARMEL

You have to recompile crosscompiller
Its not EABI (see my descuss with Jonas on fpc-devel)

make crosssinstal OPT="-dFPC_ARMEL" ...



This is the command that I used to make crosscompiler:

sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/home/kjow/lazarus/fpc/binutils/ CROSSOPT="-CaEABI
  



-dFPC_ARMEL -CfSOFT -gl -O-" INSTALL_PREFIX=/usr/
COMPILER_OPTIONS="cpufpemu"
  


sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux
CROSSBINDIR=/home/kjow/lazarus/fpc/binutils/ OPT="-dFPC_ARMEL" CROSSOPT="-CaEABI 
-dFPC_ARMEL -CfSOFT -gl -O2" INSTALL_PREFIX=/usr/



add OPT, remove COMPILER_OPTIONS







However, when I compile from terminal "Hello world" programs (a simple
writeln) it works well and it runs on my phisical arm device:

~/dev/TestARM$ fpc -Tlinux -Parm TestARM.pas
Free Pascal Compiler version 2.5.1 [2009/12/14] for arm
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARM
Compiling TestARM.pas
Assembling hello
Linking TestARM
4 lines compiled, 0.1 sec


The problems are in Lazarus IDE with the linking of target libs.

Kjow

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

  



--
 Darek





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

Re: [Lazarus] Do FPC generates old EABI code?

[Dariusz Mazur]

Kjow pisze:

Hi all again,

I think that I'm almost at the end of my path to make Lazarus able to
build for arm-linux "graphical projects".

It compiles and it seems to link right, I found all target libs I need
(I grabbed most of these from sdk), but almost at the end I have this
error:

...
/home/kjow/lazarus/fpc/binutils/ld: error: Source object
/home/kjow/lazarus/fpc/libcross/libX11.so has EABI version 5, but
target /home/kjow/dev/TestARM/LazARM/LAzARM has EABI version 0
  

did you compile FPC and libcross with the same binutils?
how you made crossppcarm ?
to read EABI version you may use
readelf -a ./linX11.so



--
 Darek





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

Re: [Lazarus] Cross Compile for arm-linux

[Dariusz Mazur]

Kjow pisze:

Now I have this problem:

/home/kjow/fpcarm/lib/fpc/2.5.1/ppcrossarm -XParm-linux-
/home/kjow/Programmazione/TestARM/prova1.pas
  

try

/home/kjow/fpcarm/lib/fpc/2.5.1/ppcrossarm  -XParm-linux-   prova1.pas

which is curr dir?
have You write access to TestARM ?

Free Pascal Compiler version 2.5.1 [2009/12/07] for arm
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARM
Compiling /home/kjow/Programmazione/TestARM/prova1.pas
Assembling hello
Linking /home/kjow/Programmazione/TestARM/prova1
/usr/local/bin/arm-linux-ld: cannot open linker script file link.res:
No such file or directory
prova1.pas(3,21) Error: Error while linking
prova1.pas(3,21) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

what's link.res? Where can I find it? (Or, how do I create it?)
  

the same dir where You compile

--
 Darek





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

Re: [Lazarus] Cross Compile for arm-linux

[Dariusz Mazur]

Kjow pisze:

2009/12/7 Dariusz Mazur :
  

this is fpc.cfg in the same dir as you compile,
as you see it include default fpc



Thank you very much!
I understand better now :)

in your fpc.cfg there are these rows:

-FU/home/darek2008/fpcarm/praca/$fpctarget
-Fu~/lib/synapsesvn/trunk

what's "praca"?
  

name of work directory
synapse works well on arm-linux? 

yes

do you know about lnet?
  

I don't know


--
 Darek





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

Re: [Lazarus] Cross Compile for arm-linux

[Dariusz Mazur]

Kjow pisze:

2009/12/7 Dariusz Mazur :
  

and at last fpc.cfg:



Thank you very much!

I'm going to try all, but I don't know a thing: the fpc.cfg you posted
is to append to existing one or it is a replace? I'm not expert to
config fpc...
  

this is fpc.cfg in the same dir as you compile,
as you see it include default fpc


--
 Darek





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

Re: [Lazarus] Cross Compile for arm-linux

[Dariusz Mazur]

view only output commands...

Please, help me to make a generic script/tutorial to make fpc/lazarus
arm-linux "compatible"!
  

I have this script to compile FPC from svn:

make crossinstall CPU_TARGET=arm OS_TARGET=linux 
CROSSBINDIR=/home/darek2008/fpcarm/arm-linux-uclibc/bin 
CROSSOPT="-CaEABI -dFPC_ARMEL -CfSOFT -gl -O-" 
INSTALL_PREFIX=/home/darek2008/fpcarm COMPILER_OPTIONS="cpufpemu"


there are two folders with toolchain
/home/darek2008/fpcarm/arm-linux-uclibc/bin
with: as,ar, ld   
/home/darek2008/fpcarm/arm-linux-uclibc/lib
with : cprt0.o , libptrhead.so.0 .


and at last fpc.cfg:

#INCLUDE /etc/fpc.cfg
#DEFINE DEMOTEST
#DEFINE DEMOTEST1
#DEFINE LAZARUS

-Fu~/fpcarm/lib/fpc/2.5.1/units/$fpctarget/*
-Fl~/fpcarm/$fpctarget-uclibc/lib/
-FU/home/darek2008/fpcarm/praca/$fpctarget
-Fu~/lib/synapsesvn/trunk
-Fu/usr/lib/lazarus/lcl
-Fi/usr/lib/lazarus/lcl/include
-Fu/usr/lib/lazarus/lcl/nonwin32

-a
-Sd
-Xd
-Xs


-O-


#IFDEF CPUARM
;-XParm-linux-uclibc-
-XP/home/darek2008/fpcarm/arm-linux-uclibc/bin/
-Xr/home/darek2008/fpcarm/arm-linux-uclibc/lib
-XR/home/darek2008/fpcarm/arm-linux-uclibc/
-darm
-CfSOFT
-CaEABI
-Tlinux

#ENDIF
#IFDEF CPUI386

-XP/home/darek2008/fpcarm/i386-linux-uclibc/bin/
-Xr/home/darek2008/fpcarm/i386-linux-uclibc/lib/
-FL/home/darek2008/fpcarm/i386-linux-uclibc/ld-uClibc.so.0
#ENDIF



--
 Darek





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

Re: [Lazarus] What's the hold-up with Lazarus v1.0?

[Dariusz Mazur]

Florian Klaempfl pisze:

Graeme Geldenhuys schrieb:
  

2009/11/29 Florian Klaempfl :


Do you really think we should care about people looking at version
numbers? Wine took years to get 1.0 and people used it, one of the
greatest emulators (qemu) is still at 0.11 having a quality Borland had
selled as version "2007".
  

And who are they targeting? Linux and Unix users which as I already
mentioned, do not care much about version numbers. Lazarus targets
Mac, Windows, Linux etc Most of those targets DO care about
version numbers, even thought it might only be psychological.



Being honest, should an OSS project care about users looking at version
numbers? The most important thing for an OSS project are contributors,
no more, no less (don't tell me that a person/company selecting software
by version number will ever contribute to an OSS project ...). 
If You want to do professional project You should care about users. In 
businesses then most valuable thins are client, not only because they 
bought, but much more because business can learn from. Every hard,  
difficult client is important, because what firm can learn from it, can 
sell others.
If Lazarus, FPC and others don't want to be a toy (and I believe then 
don't) then should care about some users.  Contribute its not only 
patch, but also bugs etc.. Firms which want to switch to Lazarus always 
make contribution, of course not all contribution are valuable nor 
accepted, but  developers can choose, whats they like. Without those, 
developers can't resolve some  problems.  Persons which do not any 
contribution, are not problem also (You are happy when You have more 
downloads)


Why professional should choose  this  project for ground of its core , 
if even developers don't believe they are ready.
We not discuss about different between version 1.0 and 2.0, but between 
ready (1.0) and not ready (0.x). For persons that selecting software 
this is
significant. And every OSS project should't discard them (should discard 
every bad contribution)






And for
contributors a serious and defined development modell is import and not
some marketing speech.
  
Some marketing speech yes, but as You say on other post  publish 1.0 
version any API can change. Some users not accept those insecurity


  

Any steps taken to reduce bad publicity is a good thing. Seeing
comments like the ones I mentioned in my first post is what stops
potential developers from trying Lazarus, even though the original
poster of that comment didn't really give Lazarus a fair chance.



Do you really want such people using lazarus :)? They'll waste our time
with whinning, no more no less.
  

You simply ignore those whinnying,  You don't give any promise, phone etc.

  

Developers read those comments and take it as fact and simply stay
away from Lazarus.

Clearly you know the benefits of version numbers, otherwise FPC would
still have been at v0.x!



It took FPC also eight years to reach 1.0 and it was clearly feature
driven: TP compatibility as far as possible.
  
Of course. But not 100%. Some of them You implement after. An even today 
its not 100%, but those left are not important.
Lazarus is much harder. After years of development its not close to 
ideal, because ideal was changed. An I suppose that after some years 
will be the same. Or worse: ideal Lazarus will not be ideal for users, 
because expectation will change.
  



--
 Darek





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

Re: [Lazarus] Powerpdf

[Dariusz Mazur]

Michael Van Canneyt pisze:



On Thu, 26 Nov 2009, Dariusz Mazur wrote:


Hi
I've made several changes to powerpdf unit
it consist:
- possibility of using char form charset 1250:aogonek, Sacute, 
Zdotaccent (simple change to other)

- draw vertical text

using this unit without dependency of Lazarus (even pdfImage depends 
only from fpImage)


My source in http://www.emadar.com/fpc/powerpdf(darek).zip

Is any interesting to integrate this with ccr version?

And by the way. I write library, which can draw on canvas form screen 
(tControlCanvas), printer, PDF, postscript  and soon on HTML canvas. 
I use them to prepare reports on different media.

Is any , who need something like that.


Absolutely. But it exists already: all you need to do is draw on a
TFPCustomCanvas class; Your code will then be able to draw on screen,
printer, pdf and whatnot, because the canvas classes in the LCL descend
from TFPCustomCanvas.

of course its good choice, and I say about something similar,
but its not ready do use:

powerPDF is not based on it,
second: what about scaling factor, PDF has different
handling bitmap, font style  are also different
there is also problem with last point on drawing line

where is implementation  of postscript and html



--
 Darek





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

Re: [Lazarus] Powerpdf

[Dariusz Mazur]

Jesus Reyes pisze:

--- El jue 26-nov-09, Dariusz Mazur  escribió:

  

De:: Dariusz Mazur 
Asunto: [Lazarus] Powerpdf
A: "Lazarus mailing list" 
Fecha: jueves 26 de noviembre de 2009, 12:03
Hi
 I've made several changes to powerpdf unit
it consist:
- possibility of using char form charset 1250:aogonek,
Sacute, Zdotaccent (simple change to other)
- draw vertical text

using this unit without dependency of Lazarus (even
pdfImage depends only from fpImage)

My source in http://www.emadar.com/fpc/powerpdf(darek).zip

Is any interesting to integrate this with ccr version?



In the mean time, PowerPDF (our version) can convert from UTF-8 to 1252 and 
support for the rest of 1250 not included in 1252 can be added easily.
  

I did not notice that. But my solution has  proper compute textwidth
Main problem are diacritic char


Maybe you based your port on very early PowerPdf version or maybe our version 
was based on a too old powerpdf version? (I think the former)
  

I use powerPdf for years

I have compared both versions and they are too diferent.
  
not so many, but i know this, thus I send whole, and someone can choose 
what part can be prepare
have you tried our version?, 

yes, but not whole,
pdfimage is base direct from ccr version


what are the main advantages of your version over ours? (I understand that a 
powerpdf independent of LCL it's good one).
  


some minor bugs like
   procedure SetTextMatrix(a, b, c, d, x, y: Word); {  Tm  }
should use single
or circling  dependency (pdfFonts use pdfdoc)



--
 Darek





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

[Lazarus] Powerpdf

[Dariusz Mazur]

Hi
 I've made several changes to powerpdf unit
it consist:
- possibility of using char form charset 1250:aogonek, Sacute, 
Zdotaccent (simple change to other)

- draw vertical text

using this unit without dependency of Lazarus (even pdfImage depends 
only from fpImage)


My source in http://www.emadar.com/fpc/powerpdf(darek).zip

Is any interesting to integrate this with ccr version?

And by the way. I write library, which can draw on canvas form screen 
(tControlCanvas), printer, PDF, postscript  and soon on HTML canvas. I 
use them to prepare reports on different media.

Is any , who need something like that.



--
 Darek





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

Re: [Lazarus] web apps - http header inspection

[Dariusz Mazur]

Graeme Geldenhuys pisze:

Hi,

Does anybody know how I can inspect the HTTP header information passed
to my web browser.

  

the best tool is firebug get*firebug*.com for firefox
in Safari You can enable development menu


--
 Darek





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

Re: [Lazarus] Code Metrics and Project Analysis

[Dariusz Mazur]

Graeme Geldenhuys pisze:

If not, anybody know of such a tool I can use on Object Pascal code?

  


watch at www.peganza.com

--
 Darek





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

Re: [Lazarus] help plz

[Dariusz Mazur]

Alexander Kaupp pisze:

Hi Dariuz,

wow great job :)
Gut the benefit of using XUL would be that it can be run in a
XUL-capable browser or native as an local application or both :)

In your case it could be possible to generate XUL on the server instead
of HTML and send this to the browser. And if you have all XUL-Documents
local on a machine with the app-binary it should run as a local app.
  
Of course I can generate XUL, but thus I don't control how its look 
like, how its rendering. Some times it is advantages, some disadvantages.
In other posts there are discus how application should look: on every OS 
the same or follow style of OS.
But for me more important is behavior of application, how it play with 
mouse, keyboard.

For me web application should be aware:
- function and arrow keys
- tabs (browser walk  also through  href, not only input field)
- reload, back browser command (for example: what do back after close 
forms with saved transaction)

- modal forms (with expected behavior on browser and server side)
and many others
Is this possible to control with XUL?  I doubt.




And it could be possible to have the GUI on the client started by the
browser or XULrunner and the application on the server. There are a lot
of options then.
  
I don't say about theoretical possibility. I don't have several years to 
build quite new application. I;ve simply took  exist API,
an build library for web. An I must say, that is not problem generate 
web pages: need HTML code is simple  and CSS is very flexible, on web is 
much beautiful examples.
Most hard problem is the rest: how browser is cooperate with server, how 
it play with instances, events , how is transfer optimized. XUL or EXTJS 
are only one abstract layer, similar to  GTK or WIN32. But to effective 
build application we need LCL or VCL, which used them.



--
 Darek





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

Re: [Lazarus] help plz

[Dariusz Mazur]

Alexander Kaupp pisze:

Hello,

I had the idea to try to make it possible to transform an existing
lazarus-project to a XUL/XPCOM-Gui application.

So I need many informations about a Lazarus Project:

- forms
- gui-components inside a form
- properties of all gui-components
- eventhandler of gui-components
- ressorces (images, lanuage-files, etc )

So i think this work has already been done by the lazarus project
(Objectinspector, form-designer, etc ).
  

Ive done full transform  not so small Delphi project to web application.
Ive follow VCL idea to communicate with browser. Implement forms, 
several components, event handlers.
And also make things absent in normal application like application 
management, HTTP server (FCGI also)
Application  can use long grids (no problem with 1M rows), modal 
windows, generate reports for PDF and many others.


Last but most important: both version desktop and webbased are compiled 
daily from the same source (only difference is compilator: for web is 
FPC and some libraries - pascal is great )


But is some disadvantage's from this approaches. I dont use any form 
designer, all forms are made dynamically from source. I dont use XUL, 
only pure HTML with CSS and small Javascript (about 2k LOC). Every 
computing is made by server, client (browser) computing only visual 
things (shape, colors). This is very different approach from example 
EXTJS, but i think is closer to widgetset like VCL or LCL.


I have some example code
http://www.emadar.com/fpc/xwebdemo.zip

and working demo:
http://emadar.eu:8004

but is pure translating to other than my native language
I know its hard to start, but if somebody find it interesting I can help


--
 Darek





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