Why don't you use the XML parser units that already exist in the FCL? There are units in there to handle most XML processing. It utilizes DOM instead of SAX, but that is probably fine with the size of files these will be (they probably won't be very large files). Also, it has that TXMLConfig class that is really nice. You just give it a path, almost exactly like when using the Winblows registry and it creates your XML file for you. Very handy for config files.

I just don't see any reason to add another XML parser unless there is a need to. If anything, the existing XML parser should be enhanced to handle either SAX or DOM. Then we would have the best of both worlds and all part of the FCL.

Curtis

I have no problem with you writing the designer stuff. Someone else mentioned working on the object inspector. Not sure if they started or are working on it.

I am currently saving the project info file (.dsk) as an INI file. I am going to convert that over to xml format soon.
---------------------------------------
Shane Miller
Take a look at other product/projects of mine below!

Get paid to surf the net!
http://alladvantage.com/go.asp?refid=DEX-870

Get paid to surf the net by clicking here too!!!
http://epipo.com/sine.asp?dex870

Home page : http://www.lakefield.net/~smiller

Auto-IP Publisher : http://www.lakefield.net/~smiller/autoip

Advanced Clipboard : http://www.lakefield.net/~smiller/advclipboard

Lazarus : http://www.lazarus.freepascal.org

Hey does anyone have any problems with me converting the project and ide setting files to xml. I will use the sxmlparser.pp that I posted a few weeks ago to do it. Has anyone started on the designer, if not I will start it would make a good test component for the QT library. This way I would be killing two birds with one stone.

Cliff

Just noticed that compiler options uses xml config I guess that is what we should use then.

BTW how are we going to handle object construction. Perhaps store the designer for definition as a lfm in xml format and then create a include that contains component initialization stuff.

Cliff

Shane,

I think we should seperate the designer from the ide code into a seperate working directory. I believe we should keep a little seperation there since it is going to be a large chunk of code. I have a copy of the FEdit stuff but it is only good as a design model since it calls way to much winblows stuff. I also built one in python for the boa-constructor project so I have a damn good shot at making something that works. The inspector will be done by myself also since it has to tie closely with the designer in the inheritance model.

Cliff

I say go for it. Start it out and keep updating CVS. Once you have a skeleton version that we can look at maybe others can get involved and help. We REALLY need this step taken. This is a big part of a good IDE and it needs to be worked on so we need someone that knows what they are doing and has the time to work on it. As for myself, I'm afraid I simply never looked into how it worked and I don't really have a good idea on how to code it.

Once I see where you are going, I will be able to help you.

As for myself, I want to work out the minor issues (some major) with the editor and the way it displays/saves/renames etc. the files. Some of these things will be done in the designer and I would like to see something ASAP so I know what to do and what to leave for you.

What would be helpful is for someone to give an overall explanation on how it will be done. That way perhaps we can get others involved.

---------------------------------------
Shane Miller
Take a look at other product/projects of mine below!

Get paid to surf the net!
http://alladvantage.com/go.asp?refid=DEX-870

Get paid to surf the net by clicking here too!!!
http://epipo.com/sine.asp?dex870

Home page : http://www.lakefield.net/~smiller

Auto-IP Publisher : http://www.lakefield.net/~smiller/autoip

Advanced Clipboard : http://www.lakefield.net/~smiller/advclipboard

Lazarus : http://www.lazarus.freepascal.org

Yes I blasted off at the mouth too soon that is exactly what I am using.

Shane should be able to use it for the lazarus config file very easily also. I am going to use the same thing for the .LFM files also.

Cliff

If you have written Delphi programs that utilize the Windoze registry, you will find that TXMLConfig class very easy to use. It is very similar to using the Delphi TRegistry classes. Then it writes and reads XML files. It should be really easy to convert if you use that class.

Curtis

Michael Van Canneyt wrote

It already handles DOM. There are changes planned to make it DOM level 3 compliant, which would make it compatibe to SAX.

Sorry, this is not correct: DOM level 3 doesn't exist yet; within the next few days it is expected that the needs for DOM 3 are specified. Probably it will contain interfaces for loading and storing XML files. SAX is a different matter: While DOM is specified by the World Wide Web Consortium (W3C), SAX is a public domain specification created for OpenSource XML parsers.
My first XML parser as present in the FCL parses a XML file and creates the DOM tree directly. The new parser will have a SAX interface, for DOM support there will be a special SAX->DOM 'converter'. (Converter might not be the correct term; it simply defines callback functions for parser events and creates the DOM tree based on this events.) The current implementation is more or less DOM level 1 compliant; the next release of the XML units will support the most important DOM level 2 extensions such as namespaces.

- Sebastian

Not much of anything just yet some class stubs thats all.

Cliff Baeseman
------------------------------------------------------------------------ --------------------
There is nothing wrong with Windows 2000 that LINUX won't fix!!! ------------------------------------------------------------------------ --------------------

I have been trying to put together a little "plan" for the designer/inspector, but didn't get very far... i'll check the code out right away and see what you did... :o)

Curtis White wrote

If anything, the existing XML parser should be enhanced to handle either SAX or DOM. Then we would have the best of both worlds and all part of the FCL.

I'm already working on a new XML parser which supports both SAX and DOM; but this project has a quite low priority so it can take a few weeks until it's finished. But then it will support namespaces etc....

- Sebastian

It already handles DOM. There are changes planned to make it DOM level 3 compliant, which would make it compatibe to SAX. Sebastian Guenther can give more details on this.

So I definitely think you should use the provided classes.

Michael.

A common designer/object inspector would be great. Not sure where to put it but I'm sure the FPC guys will give their opinion on the packages directory.

If it helps get the code written quicker, then I'm all for it. Shane

>> 04/18/00 12:18PM >>>

Cliff" wrote

Not much of anything just yet some class stubs thats all.

I proposed this already some time ago: what about using common designer/object inspector/debugger/browser components for the KCL/LCL??? It would save a lot of work! It could be pu into the packages module of the cvs under packages/components/ide! Especially bceause I suppose that the debugger/brower stuff has to do someone of the FPC core team.

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Cliff" wrote

Not much of anything just yet some class stubs thats all.

I proposed this already some time ago: what about using common designer/object inspector/debugger/browser components for the KCL/LCL??? It would save a lot of work! It could be pu into the packages module of the cvs under packages/components/ide! Especially bceause I suppose that the debugger/brower stuff has to do someone of the FPC core team.