OK, it's now usable. Components, events and installation are ok.

The form editing is not really usable.
I'm currently fixing the mouse coords and mouse capturing. Then I will implement/repair the form editing.

Another great advantage - it uses official fpc version.

see thread "Compile error"

Some disadvantages: 1. There is no patching system as an alternative of CVS. Might be, I'll make such inofficial system.

How will this work?

2. Absence of TScrollBox is one of the greatest problems 3. TPicture.LoadFromFile fails in bitmap.inc,pixmap.inc... I'll try to find a bug.

The graphics are still not implemented. You can only load xpm.

4. Running+debugging is not supported. Is somewhat about xxgdb including so difficult?

Debugging works. It's not complete, but it is sufficient for small programs. Since it is under development it is deactivated by default. You can activate it via Environment->General->Files->Debugger Type and Path e.g.: GNU debugger (gdb), /usr/bin/gdb
Debugging will not work with launching applications.

Or (idea!) just lighting run-time error line? Besides, it is not a great problem

Therefore it's already there. :)

5. A number of unical units make lcl incompartible both with vcl and clx.

True.
But for several reasons 100% vcl compatibility is impossible. So, eventually lazarus will provide some tools to automatically add the needed IFDEFs to delphi units and create the lfm files.

Mattias

OK, it's now usable. Components, events and installation are ok. Another great advantage - it uses official fpc version. Some disadvantages:
1. There is no patching system as an alternative of CVS. Might be, I'll make such inofficial system.
2. Absence of TScrollBox is one of the greatest problems
3. TPicture.LoadFromFile fails in bitmap.inc,pixmap.inc... I'll try to find a bug.
4. Running+debugging is not supported. Is somewhat about xxgdb including so difficult?
Or (idea!) just lighting run-time error line? Besides, it is not a great problem
5. A number of unical units make lcl incompartible both with vcl and clx.
6. Difficulties with dpr reading and even including pas+dfm/xfm units. Might be, some simple translators will be usefull. Besides, it is my own problem.
7. Stability is not full.
8. gtk widget is not a best choice. The idea of fpgui was better. But there are problems with popups there
9. Editor does not support full font filter. Besides, there are problems with national keymappings.

Now I'm translating my RED editor from clx to lcl.

"�������" wrote:
�
4. Running+debugging is not supported. Is somewhat about xxgdb including so difficult?
� Or (idea!) just lighting run-time error line? Besides, it is not a
great problem
�
Even the idea will be a great help.
This has been on my wish list forever
I dont see any movement in general on gdb, step, step into� etc. It is the main reason Lazarus is not seen as usable by everyone I know.

but Windoze is no OS for writing serious applications, I think... ;)

for running them, yes, but for development, no... :)

- Sebastian

first of all fpgui has not been active for over a year

yes, and if it will be continued one day (currently I still just don't have the time), then with the ability to have native widget sets bindings as well... (the release of XP with its new widget style makes it necessary to change the basic ideas once more)

second is lazarus not a windows only project and gtk+ is one of the standard linux widget sets and also available on win32 so it's a very good choice to use

although GTK on Windows is still not a real option for writing serious applications, I think...

and lazarus shall have interfaces for several widget sets in the future so if you want fpgui bindings code them :)

with the new fpGUI, it should be possible to write Lazarus binding quite easily. But before this will become reality, I will have to extend fpGFX a lot. (and this will be realized in the not too distant future... fpAsync as the new base is already quite mature, especially with the dozens of improvements I only would have to commit to CVS now...)

- Sebastian

although GTK on Windows is still not a real option for writing serious applications, I think...

this seems to be true
but Windoze is no OS for writing serious applications, I think... ;)

8. gtk widget is not a best choice. The idea of fpgui was better. But there are problems with popups there

gtk widget choice is best choice
first of all fpgui has not been active for over a year second is lazarus not a windows only project and gtk+ is one of the standard linux widget sets and also available on win32 so it's a very good choice to use and lazarus shall have interfaces for several widget sets in the future so if you want fpgui bindings code them :) btw the work for win32 native interface is in progress as long as i know

Hi

Michael A. Hess wrote

Why is this better or even desired over CVS??? How will you determine what exactly needs to go into the patch????

I think we could use cvs to produce the patch file. I have'nt done it before but it should by using a "cvs rdiff". For example:

cvs rdiff -D "2002-05-20" -D "2002-05-25" lazarus > patch1

produces a diff between the 2 dates given as argument. Note usage of "rdiff" instead of "diff" which avoids the need for a working copy of lazarus.

Some more notes:

* A command like this could be set up in a cron job
* It could be useful to also include a specific time into the -D options (eg.: -D "2002-05-20 23:59:59 GMT")
* There's one problem which can result in a version of lazarus which is not compilable. This would happen if a developer commits changes file by file and the changes depend on each other. E.g.

- first file committed at 23:59:50
- second file committed at 00:01:02 the next day

bye,

Stefan

I've made something from my RED to lcl. Course, it is not so good:
1. Table support is implemented, but not working in clx and lcl.
2. Images are not supported due to lcl bug.
3. Fonts are not supported in lcl, it must be a bug in lcl. I saw graphics.pp and fonts.inc, they are not quite stable.

Why is this better or even desired over CVS???

It is neither better, nor more desired. Let's imagine that someone can't use cvs's advantages. For example, I have access to Internet via public computer via proxy (and it is too,too difficult to make work via this squid proxy except web browser). I can browse cvs with webcvs, but it is not usefull: it can't generate patches for directory. Besides, I need compressed files - Internet is limited for our University stuff (I am one of them) with 30 Mb monthly (uploading is not limited, downloading is). So, I can't update files everyday. A year ago I tried to improve lazarus, but I had outdated version, and no official release was for making a patch.

How will you determine what exactly needs to go into the patch????

When I will download lazarus.zip next time.

see thread "Compile error"

If there is a minor error in fpc, may be, it is a good idea to bypass it in the project rather than correcting it and making inofficial fpcs every month.

Simply. Just publish lazarus-20020521.tar.bz2 on a site (I can do this as soon as I take 2nd computer). Then, might be, lazarus-20020615 + patch or so on.

The graphics are still not implemented. You can only load xpm.

Sorry. I can not. This error is during loading xpm.

But for several reasons 100% vcl compatibility is impossible. So, eventually lazarus will provide some tools to automatically add the needed IFDEFs to delphi units and create the lfm files.

Course. The problem is: there are too many unexpected units (lcltypes and other *types), which are not only have no analogs in vcl/clx, but even are not installed in /usr/[local/]lib/lazarus (I don't use /usr/local at all, on my linux computer (it is my, but not connected to internet or other network at all) /usr/local is symlink to /usr :) )
Besides,. let's imagine, I have dfm/xfm, and I have to translate it to lcl. It is not difficult to do it manually, but there is a problem to link this pas+lfm to the project and then edit this form. I couldn't do it simply.

> see thread "Compile error" If there is a minor error in fpc, may be, it is a good idea to bypass it in the project rather than correcting it and making inofficial fpcs every month.

I agree with you.
But there was no inofficial compiler because of a small bug. They were always crashing/nasty bugs or missing things, that were needed for lazarus.

ok

> The graphics are still not implemented. You can only load xpm. Sorry. I can not. This error is during loading xpm.

Sorry, my statement was ambigious.
The xpm representation is the TPixmap, which works. graphics are TGraphic, TPicture and TImage, which are only 50% complete (the VCL part which is OS independent). But the vcl uses bitmaps which are very win32 specific. The LCL api will be the same as the vcl, but the inner algorithms will be very different.

> But for several reasons 100% vcl compatibility is impossible. > So, eventually lazarus will provide some tools to automatically add the needed IFDEFs to delphi units and create the lfm files. Course. The problem is: there are too many unexpected units (lcltypes and other *types), which are not only have no analogs in vcl/clx,

True.
The LazarusResources variable can be moved to controls.pp, so that LResources can be omitted in the uses section. The LCLType and GraphType are simply splits. So a converter can for example simply look for graphics and add graphtype.

but even are not installed

fixed

in /usr/[local/]lib/lazarus (I don't use /usr/local at all, on my linux computer (it is my, but not connected to internet or other network at all) /usr/local is symlink to /usr :) ) Besides,. let's imagine, I have dfm/xfm, and I have to translate it to lcl. It is not difficult to do it manually, but there is a problem to link this pas+lfm to the project and then edit this form. I couldn't do it simply.

True, it's boring work. That's why a converter should do it. A simple converter will only copy the dfm file to an lfm file. A better one will also adjust some values. And the complex one, will scan for all used component classes and removes all missing classes and properties. Since the other way back is nearly the same, we would also have an export function.

Mattias

Why is this better or even desired over CVS???

How will you determine what exactly needs to go into the patch????

Just curious.

You may find it on http://sourceforge.net/projects/lincmd in package red

I think this is a matter of discipline.

There are 2 options:

1. I set up such a cron job on the CVS server.
2. Michael Hess sets up a cron job on his server where most of the download files for lazarus are located.

Michael.

I'm out of town for the holiday and won't be back until Tuesday but I can look into setting that up along with the nightly build.