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 ).

Now I would like to make use of this existing work. But I don't know where to start :(

Can someone help me out, please?

The 1st step would be to transform the lazarus-forms to XUL-Documents with proper css (component positioning, etc)
Later on create the JavaScript stuff with XPCOM binding to the event handlers.

thankful for any help
alex

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

Do you mean you want to write a converter tool to convert LCL apps into XUL/XPCOM-Gui apps?
Or do you want to extend the IDE to create XUL/XPCOM-Gui apps?

This is more about the lfm file than about a Lazarus project. Take a look at lfm files: There are the components and the properties. The types are stored in RTTI and are accessible via the unit typinfo of the FCL.

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

The OI and form designer are just editors. The access functions are part of the compiler and the unit typinfo.

Now I would like to make use of this existing work. But I don't know where to start :( Can someone help me out, please?

I guess there are not many people here knowing how a XUL/XPCOM-Gui application works, so it is hard to help.
Maybe you can give some small examples and/or start a wiki page?

The 1st step would be to transform the lazarus-forms to XUL-Documents with proper css (component positioning, etc) Later on create the JavaScript stuff with XPCOM binding to the event handlers.

Ehm, you know that there are more than a hundred classes and several thousand properties which interact in complex ways, don't you? Maybe it is easier to start with an IDE extension to write XUL/XPCOM apps?
Since 0.9.29 the IDE can design non LCL gui components. So you can write your own XUL components and use the IDE as designer, including drag and drop, events, component editors, object inspector, visual form inheriting and more.

Mattias

Hi Mattias,

Hmm I am not shure what is the better/easier way to start. Would be great to have it as a new LCL-Interface.

ok I thought this is a part of lazarus, good to know :)

I read this tut:
http://www.ar-ent.net/dar/arlib32/out/html/man/xul/index.html

tbh I dont event know really many about it. But I am familiar with web-tech, CSS/JavaScript so the XUL-Stuff is easy for me to understand. The Problem is how to add this features to lazarus.

Yes I know ... This is one reason why I dont know where to start :) But I think the mozilla-projects and afaik the GNOME-Projekt shows that everything is possible with this kind of technology.

So the main-part of this work is to replace the lcl-stuff which is in the app-binary as javascript-pendants. Because all gui-stuff is done in this language in xul. So you could see the app as the server and the XUl-gui-stuff as the client.

Maybe it is easier to start with an IDE extension to write XUL/XPCOM apps?

If you say it is easier I will try it this way.
But I am not shure if this is possible, because the XUL-Approach is really different to all other GUI-Designs. And I am not a really experienced pascal-programmer tbh. Did too much web the last years :(

thanks again for the tipps and I hope to be able to create someting.

Hope I can contribute this to the project. Imo the idea is great expecially for the lazarus-projekt.

Theoretically possible, but if you want to emulate the LCL with javascript then you have a lot of work to do.

Are there any applications ported from gtk, qt, wxwidgets to xul?

So the main-part of this work is to replace the lcl-stuff which is in the app-binary as javascript-pendants. Because all gui-stuff is done in this language in xul. So you could see the app as the server and the XUl-gui-stuff as the client.

Normal LCL apps do not work as client/server. For example they try to query the mouse position several times per second.

Mattias

part of the/your problem is determining where to add this capability...

1. are you wanting to create XUL for laz such that instead of using the current interface, you use a XUL based one?

OR

2. are you wanting to create XUL addition such that Laz can create XUL based apps?

i think #2 is the one you are after instead of completely redoing the Laz interface in XUL (#1)...

Alexander Kaupp pisze:

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

Alexander,

I would agree with the other posters that maybe an XUL widgetset (interface) would not be the way to start because of LCL overhead and behavior that may be problematic for a client/server type app.

However, you can certainly use a great deal of existing Lazarus IDE functionality in your project. Here's an example of how the IDE can be used:

http://web.fastermac.net/~MacPgmr/ExtPascal/ExtPToolkitStatus.html

In this project I'm using almost all aspects of the IDE, just not using file structure is simply used as a repository of information about the UI and is not used at runtime either. Take a look at the form-to-ExtPascal converter. This converter is run every time you compile or run the ExtPascal app in the IDE. It checks to see if any changes have been made in any form and if so creates new .inc files that contain the actual ExtPascal code that sets up and initializes the window (form) UI. It also adds any event handlers to the app's appthread unit - events are handles by the current thread and then passed along to the UI.

(A form's auto-generated .inc file is analogous to an LCL auto-generated .lrs file.)

I'm using the LCL TCustom ancestors for my "design controls". This helps me meet one requirement for this project, which is to write as little code as possible. Of course the design controls don't look much like Ext JS runtime controls, but that's not the point. The point is to have a way of graphically designing the app.

Example using the MultiSelect (TListBox) control:

http://web.fastermac.net/~MacPgmr/ExtPascal/ExtPascal_MultiSelect_in_IDE.jpg

http://web.fastermac.net/~MacPgmr/ExtPascal/ExtPascal_MultiSelect_at_Runtime.jpg

Source is included with the ExtPascal SVN or as a .zip:

http://code.google.com/p/extpascal/

http://web.fastermac.net/~MacPgmr/ExtPascal/

You might start with a simple LCL form and write an XUL equivalent, then look at commonalities between them. Then start thinking about how best to use Lazarus as a designer. When I was creating my design control package for Lazarus, it was as though the IDE developers had anticipated everything I would ever need. The only problem was the lack of documentation - just follow my extp_proj package to avoid entering a lot of cul-de-sacs.

Thanks.

-Phil

Hi Matias,

Theoretically possible, but if you want to emulate the LCL with javascript then you have a lot of work to do.

Imo the most propblems are solfed by XUL itself and therefore we dont have to emualate everything. For example all XUL-Compos have eventhandlers. But there is a lot of work to figure out how it works.

I am not shure how this GUL-Elements are implemented per platform. I think XUL is using the system-default Widget set.

Are there any applications ported from gtk, qt, wxwidgets to xul?

Here Is a list of some XUL-apps:
http://dafizilla.wordpress.com/2007/07/07/how-many-applications-based-on-xul-exist/

alex

hi,

yes it would be perfect to have a XUL gui added to the lcl. Or in other words a no-gui lazarus-app with XUL-Gui. Sounds strange :)

This needs deep knowlede about how the laz-ide works. And I dont have this experience :(

Hi forgot something,

the XUL-thing would be a designtime-only package. Gererating the XUL-documents, JS and css. The rest is done by XULrunner or a Mozilla-Browser.

greetings
alex

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.

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.

alex

Hi Phil,

wow really great information. I will study your project. Thanks for sharing this.

alex

again, from standing out here on the outside, i'd say that XUL is not warranted for an "internal" FPC/LAZ interface but that the OP need determine exactly what they seem to desire... based on the postings available, it would appear that they are looking to add an additional end-code method such that they have a "XUL client" (if that is the proper term) for their end goal(s)...

FWIW: in my straight procedural mind, that adds additional layer(s) of problems that can easily break current methods as well as opening up other avenues of attack (spoken as an insignificant security personel) :? :(

neither do i but i cannot help but to see the possible security exploits and problems :? thus my apprehension and statements to the converse... i'm all for "better" (note quotes) interfaces but not if they open holes for infiltration :?

Alexander Kaupp pisze:

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.

waldo kitty wrote

FWIW: in my straight procedural mind, that adds additional layer(s) of problems that can easily break current methods as well as opening up other avenues of attack (spoken as an insignificant security personel) :? :(

Shure there are a lot of pros and cons. But I would like to have XUL as an option in the future. And could maybe make lazarus even more popular to some users.

So no doubt the lcl is great ind my goal is not to replace it. Yust adding a new option.

alex

hi Darek,

xml/XUL presentation is done with css like it is in HTML. HTML/XML gives only the struckture and the look comes from CSS. Therefore it would be easy to add skins or styles to the app.

All other thins you askes I can't answer because i dont know much about XUL. But starting from bottom up will bring the answers I hope.

alex