Hi,

I'll try to straighten things up.

Cliff" wrote

hmmm the dfm should be in xml format so that us or any other language wishing to use a lazarus dfm can do so without having to build a parser. Lazarus will interpret the xml file using a parser to generate the

necessary

Yes, I agree.

There is no pain in Delphi now, because from Delphi (2?) up you can stream out just any component. But way back in Delphi 1, this was a major drawback. </THEORY> I am talking about a persistent state of objects, which is a great thing to have - it means that the object has easy and STANDARD way to remeber its attributes before it is destroyed and is able to retrieve them back when it is created again. (See the awkward way how to accomplish this in COM, various discussions on Delphi forums, etc.}.
<THEORY/>
As I understood, the CreateDesignForm is created by IDE to be compiled into the project as a virtual procedure and later called from the constructor. While this is sufficient for basic IDE RAD, the TForm is still a SPECIAL case and a more generic approach (Delphi-wise) is what should be in here.

> 2} It is for design-time only. While this may be enough for RAD, This is all it is good for. That is all it is used for in Delphi.

Maybe you are right, I do not have the Delphi sources. How do you think they copy components via clipboard? Anyway, that is NOT all it is used for by Delphi programmers (me included), trust me. Consider how easily can be done a custom report design (for printing, by end-users) in Delphi applications ...

But the RAD in Delphi USES that mechanism. See component streaming support in TStream and its descendants, TFiler, TReader, TWriter objects. The .DFM file is just a component hierarchy having its persistent state written into a file. So the Delphi IDE makes heavy use of these features, in fact it is build upon it.

I think you can link that into the executable, which is a part done by linker, but I am not expert in this area, so you are probably right.

However, the streaming techniques on which is Linux build, simply fascinates me. Through streams in XML format, you could even stream TForm or TGroupBox or whatever out of Lazarus to a WWW server, creating a WWW page !!!

How would you represent a bitmap or a sound clip in text? BASE-64 or MIME-encoding? or these nice numbers Delphi shows when you open a .dfm? Could be fairly large, and I am not sure about compiling efficiency then.

Maybe we still don't understand each other, in which case I apologize and beg for further explanations.

Regards,

Mike

____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

This will not work for TBitmaps and so on. How will you specify the bitmap in pascal code ???

I think we should make some resource compiler after all. We'll need it anyhow. On windows we can simply use Windows resources; on other platforms we can do something else.

Michael.

Start by studing the XML reader; from that it will be pretty obvious what to do; all that needs to be done is to

a) Define your XML document. xmlread will read it and make a DOM structure out of it.
b) Define how you want to use resources;
c) Adapt the xmlwrite unit so it writes a resource file instead of a

   text file, starting from the DOM structure;

d) compile the resource file.
e) link the resource file

Steps a-d should be done by the IDE. Step e is done by the compiler.

In principle, we can easily define a resource section in the FPC binaries, it's just a matter of conventions. If we want to use windows conventions, then the matter becomes more complicated.

I will discuss this with the other FPC developers first. Anyway, steps a-d must be prepared first. that'll keep you busy for a while. =-)

Michael.

Oh hey I'm all for this method as well. It was item 3 on my other email. I was just concerned about what this means. It is line #2 where I get itchy. This "special resource compiler". First off getting this thing designed and built. Then line #3 states "resource is linked in the app". Isn't that something that the FPC compiler/linker team would have to deal with? You yourself said that once 1.0 comes out, which should be soon, things will get real messy since you are going for a redesign. When would we be able to get this kind of feature available in the compiler/linker. Would we have to wait until the next major release?

The other options weren't compiler depended that is why I was looking at them. Any others with input???

Not to mention that it doesn't allow you to specify a bitmap for a TBitmap;
You cannot get that in pascal source.

Haha :). My biggest project is an end-user report designer; it streams all designed reports into a compression stream; which is read again when the report is read from disk... VERY convenient. No custom code to read/write a report from/to disk, just a simple

Stream.WriteComponent(FReport)

and voila. The lazarus IDE need do nothing more than this when creating forms.

Very much true; it uses streaming to copy&paste all form components from&to the clipboard. So do I in my application.

the XMLRead and XMLwrite units have been changed so they can read/write to streams; in principle you could open a compression stream on top of a socket stream to a remote server, and stream your whole form to it in XML.

All these streams are available already. (except the socket stream :( )

I think he has a point here, and that the best shot is:

1) A DFM file is a description of the form in DFM - you can easily make a bit representation of a bitmap in XML -
2) when compiling the app, the XML gets translated into resources by a special resource compiler - Delphi has one too - which are linked in in the application.
3) This resource is linked in the app, and read by the TForm startup code.

Maybe we still don't understand each other, in which case I apologize and beg for further explanations.

at least I understand you perfectly, I assume the others got the pictuir also now ?

Michael.

I think we should make some resource compiler after all. We'll need it anyhow. On windows we can simply use Windows resources; on other platforms we can do something else.

OK. Were do we start?

This will not work for TBitmaps and so on. How will you specify the bitmap in pascal code ???

A constant array? Same for any other data such as audio, but I assume there may be limits on how big these structures can be. Or, I suppose, it may be possible to link in raw binary data directly into the executable. I used to do this a long time ago in TP. I would build my screens in an editor that saved its data in the same format as the text video memory (character attribute / character pairs) then save it to disk. I would then run a bin2obj utility, and declare a variable that used the external directive (I think, it may have been a procedure, just one you couldn't call!) and link the obj file into the exe. The code accessed the data through the pointer to this data and simply copied the screen from code space directly into video memory. It was extremely fast, much faster than drawing the screen in code. I'll have to dig up some of those old prjects tomorrow and see how much of that technique could be applicable here.

I think we should make some resource compiler after all. We'll need it anyhow. On windows we can simply use Windows resources; on other platforms we can do something else.

Is there anything inherent in a linux executable that would preclude using the windows style resource information? I would assume that it would be easier to adapt the windows scheme to linux than develop a new scheme from scratch. Not that the way windows does it is the best, but I can see some advantages. For one, the resource files that are -not- managed by the ide would be identical for both platforms, and would require no conversion when migrating Delphi code.

Just thoughts,
Jeff.

the dom model says you have to use base64 encodeing but that should not really matter..

Cliff

yes the xml is parsed by the ide to generate the code necessary for linking into the user built code right before compile.

Cliff

We don't have a resource area in FPC apps (except for apps built for Windows). So how do we get the IDE-RAD built file and the code talking.

I wouldn't mind seeing it as pure source, so that when you run a compile, those inlude files would then be available for viewing directly, instead of like in Delphi where you have to convert them or use the view option. The implementation could be included much as Delphi's System unit, which is where all of the magic things happen for Delphi. Execpt here, the System unit would be modified (via include files) to link in the correct code for the forms and controls as it is compiled.

However, and I may be changing ideas mid-stream, an intermediate XML layer could do this as well, though, at the expense of the time it takes for the translation process. As long as after a compile, I can easily see what extra code has been placed into my executable. And this will also make debugging the IDE so much easier, because we will see the whole interaction between user source and IDE source.

One other note. How will the debugger handle source code in include files?

Jeff.

What is in the gtk rc files. Is this something we might be able to use?

Cliff

Michal Bukovjan wrote

I'll try to straighten things up.

<large portion snipped>

Maybe we still don't understand each other, in which case I apologize and beg for further explanations.

I think I get what our confusion is here. We aren't talking about the same thing. You are talking about how the IDE-RAD will save and read the file data. I'm not worried about that yet. How that is done or what is done can't be decided until we decide what I am talking about.

Let's assume that the RAD has created said file, be that a binary file, source code file, XML file, whatever.

How do we get the code the developer wrote and this RAD generated file together. In Delphi the DFM (binary file) is attached to the application in a resource area of the application. When the program runs it reads this information when a TForm is loaded. It creates instances of any declared objects and sets up any required parameters. Fine.

We don't have a resource area in FPC apps (except for apps built for Windows). So how do we get the IDE-RAD built file and the code talking. Either we have to design and build some sort of resource area and then build a binobj utility to add this to the application or we use an {$I...} mechanism to add the data into the source. The data for the include could be source code that was saved by the IDE-RAD or if desired (probably best idea) is to have the IDE-RAD save the data as XML. Then before the actual compile is performed a utility is run that converts the XML data into pascal source code for inclusion.

The third option would be to tack the XML data onto the end of the application but then that would mean an XML parser would need to be included in every application. I'm not sure what kind of overhead that adds.

If we use the XML to source utility it means that other layout engines could be designed and built to produce the XML file.

So is that what we are looking at. The IDE-RAD saves and works with an XML file which is then converted to source code for inclusion during compliation????