The ini method would be easiest as I stated earlier since I have already written the TInifile and it is in the FCL. As to the tree structure that should be that much of a deal. It would just be a matter of loading all of the tree levels into one name and making that a section head Ex.

[HKEY_LOCAL_MACHINE-SOFTWARE-Lazarus]

The tree itself is really just an illusion.

The other alternative which in fact might be the best alternative would be to make it be an XML document. Then you could maintain the actual Tree structure and appearance in the file itself. Would make editing it very easy. I kind of like this idea better myself since we do hav XML capability in the FCL now.

Opinions?

I could help with this, but I will let someone else work on it so I can do the clipboard class (see below). It would be nice if we can get some of you new people helping with all this. It is easier than it looks :-)

TRegistry: Not usre how we want to handle this. I'm not sure if Linux has some registry compatable system.

This is just my opinion, but I want to open this to discussion. I think we should implement TRegistry in some better way than the Windows way, on Linux. I personally think the Registry was one of the biggest blunders I have seen M$ do in quite a while. In the Windows implementation, it needs to work with the real registry, but I don't think we should copy that same blunder in Linux. I would suggest implementing it as Conf files or something like that. As long as the Interace is the same, it doesn't necessarily have to work the same.

ClipBoard: I need someone to write a class that will allow me to CuttoClipboard, PasteFromClipboard CopyToClipBoard and such. Same as Delphi.

I have already committed to do this one. I will work on it today and tomorrow before I leave to go camping for the weekend. I already know how to do it, so it shouldn't be all that difficult for me to create the class.

Well, I'm not new, but I will get the clipboard working for ya.

Curtis

----------------------------------
Curtis White
Curtis White
http://www.teleport.com/~osiriz/
----------------------------------

Probably won't help you much, but as soon as I finish getting the forms and buttons up tonight, it should be fairly easy to get a ScrollBar and Clipboard up on Win32. Whoever takes this for GTK can contact me and we can coordinate on it.

This should all fall together tonight, as all of the questions I had about how things should work have been answered. Is it possible for me to get commit access to CVS to put this stuff in? The only file I will need to modify that will affect linux/gtk will be Interfaces.pp, and I promise to be -real- careful ;^)

Jeff.

Jeff Wormsley wrote

>I think Michael was working on this. How close is it to being done?

I sort of started on it. I was editing all of the .pas and .inc files so that they didn't need to call the interfaces.pp unit. This should get it down to just controls.pp using it. Then we remove the interfaces.pp unit entirely and move the gtkint.pp and it's inc's into a subdirectory of LCL which would be

lazarus/lcl/gtk

and rename the gtkint.pp to guiAPI.pp.

Then you create another directory

lazarus/lcl/win32

and name your file guiAPI.pp as well.

This way when you link your program you just tell it which guiAPI.ppu you want to use. It uses the correct one for the API you want to compile against.

So you can see what work I have to do and still make sure that everyone keeps working OK. Uses clauses need to be changed, files moved, files renamed, and makefiles modified.

That is why I haven't been too don't want to break things that people are working on.

As I have mentioned before I will be on holiday from the 14th-28th. I don't think I will get these modifications done before I leave. So either someone else will need to do it, or you can just continue as you are and use gtkint.pp and win32int.pp and I'll deal with it when I get back.

Curtis White wrote

If it is important enough to everyone, I can probably finish it when I get

back

from camping (Sunday night or Monday evening). Have you already commited

what

you have done to CVS?

No, I won't do that until later tonight, presuming I get the HELLO.PP example to compile and run. That is the goal, anyway. If I don't get it before about 11:30 eastern, I'll start cleaning up what I have and put it in by midnight or so.

Jeff.

Yea, I agree. I don't really want to mess with it. I would prefer to just continue working on components. I was just offering in case it was really needed before the 28th. But like you said, things are working fine the way they are. Right now, we just have GTK and Win32. They are different enough that it won't be all that confusing right now. We just need to make sure we do it before we add too many more APIs.

But if you need any help with any of it, let me know. I can go through the different units and remove references to Interface in the uses clauses and some of the simpler things like that to help you out.

Curtis

Curtis White wrote

I am going to try to get the clipboard class in GTK going today if I can. I will let you know when I get it going.

Ok, I'll won't be able to look at more than Form and buttons tonight, maybe menus if I am lucky.

I haven't even looked at it, yet. I don't know about Michael. I believe since until now there has been nothing but GTK, it hasn't been urgent. All of the LCL code that is supposed to be gtk specific (other code still is that shouldn't be) is named gtk*.*, and all of the win32 code I am working on is named win32*.* which makes it easy to see what is what. So for the immediate future, it doesn't need to be split.

Tell me if this this feasable. I don't know enough about how makefiles work to know for sure. It would be very very nice to leave the generic functions in the LCL directory (not INC) and put the toolkit functions in subdirectories from the LCL with the toolkit name, and all of the files having the same names. This would let the makefile choose the include directory based on the toolkit, so that, for example, to make the examples you could do MAKE WIN32_ALL to create the win32 files, or MAKE GTK_ALL to make the GTK files. Could it work?

Jeff.

I really like this idea. It gives us a lot of flexibility if we ever want to expand on it. Plus, it could be easily converted to work with just about anything. I vote for doing the Registry as an XML file.

Curtis

seen M$

do in quite a while. In the Windows implementation, it needs to work with the real registry, but I don't think we should copy that same blunder in Linux.

I dont see it as a big blunder if you compare it to the situation before. he biggest problem is that not everybody is using the registry as where it was ment for.
It provides you general and personal settings for apps/system/etc. complete with permissions avbout who/what is allowed to add/modify/read/remove/etc a specific item.

I would suggest implementing it as Conf files or something like that. As

long as

the Interace is the same, it doesn't necessarily have to work the same.

That's correct. In fact, the windows registry consists of 4 files.

Marc

if you look at the way a registry key is exported, I feel a TInifile solution is more "same"

[HKEY_CURRENT_USER\Software\Borland\Delphi\4.0\Main Window] "TopDockSiteWidth"=dword:000004f8
"TopDockSiteHeight"=dword:0000005a

Marc

(But it might be better not to use the Windows the one hand, Windows applications are expected to store their configuration in the registry, on the other hand the whole registry is a big mess)

It would be knid of nice to be able to create a logo compliant app with a free tool, though ;^)

Jeff.

I am going to try to get the clipboard class in GTK going today if I can. I will let you know when I get it going.

We need to move the Interfaces into their own directories. Are we close to having that done? Otherwise, it is going to get confusing what code is generic and what code is specific to each environment. I kind of like the way the FCL stuff is organized. It is really easy. All the stuff in the inc directory is generic and all the stuff specific to each environment is in its own directory (linux, win32, etc). Instead of "linux" we would probably have "gtk", "qt", etc. I think Michael was working on this. How close is it to being done?

Curtis

Shane Miller wrote

TRegistry: Not usre how we want to handle this. I'm not sure if Linux has some registry compatable system.

There really isn't a registry with Linux (hope there never is) but the closest thing would be to use an .ini file in place of a registry. The TIniFile class already exists in the FCL so it would be a matter of writing a TRegistry class that just calls the normal TIniFile stuff.

Should be easy.

It's better to have one system independent inc/ directory and all the toolkits in their own directory. This is needed if you want to have multiple toolkit targets installed. You can't have a guiapi for every toolkit and independent .ppu's which depend on the guiapi. So for every toolkit you need to have their own Makefile (which can ofcourse include generic parts) and will create their own .ppu's in their own directory. In the main lcl directory you then place a general Makefile which will call the makefiles in the toolkit directories which you specify. And maybe a readme file.

Peter

Here's a list of what needs to be done for me. There are things I have run into while working on the editor. It would be GREAT if some new person that would like to try and learn this would get involved.

TScrollBar : Cliff said he was going to work on this but I'm not sure if he did start or not. I need to be able to send it a number (say 100) so itscrolls for 100 ticks or something similiar. Also, I need to be able to read it's position, set an onchange event handler along with all the normal behavior.

TRegistry: Not usre how we want to handle this. I'm not sure if Linux has some registry compatable system.

ClipBoard: I need someone to write a class that will allow me to CuttoClipboard, PasteFromClipboard CopyToClipBoard and such. Same as Delphi.

Please let me know if you (SOMEONE NEW) would like to work on one of these items. Cliff, Michael, Curtic, Worm, Peter and I will help you, so don't be worried about not knowing GTK or anything like that.

Thanks
Shane

"Shane Miller" wrote

Here's a list of what needs to be done for me. There are things I have

run into

If there is something of a base OK

TRegistry: Not usre how we want to handle this. I'm not sure if Linux

has some registry compatable system.

See other posts, but it should not be difficult.

ClipBoard: I need someone to write a class that will allow me to

CuttoClipboard, PasteFromClipboard CopyToClipBoard and such. Same as Delphi.

I do know how to handle in win32 not GTK (yet)

Please let me know if you (SOMEONE NEW) would like to work on one of these

items.

Cliff, Michael, Curtic, Worm, Peter and I will help you, so don't be worried about not knowing GTK or anything like that.

Count me in, just me know .

Marc

Well, the registry was a good idea poorly implemented, IMNSHO. The idea of having global machine level settings versus individual user settings was a good one, but it would have been much better for the OS to maintain an independent file from the applications, and severely limit what an application could update in the OS portion. I don't particularly want an application to change my IDE hard drive controller to a SCSI ;^). In NT it isn't so bad, but in win9x it is a nightmare.

One possibility would be to wrap the registry functionality onto files that were accessed like INI files. The key tree stucture could be a trick, but not too bad. This would allow the files to be treated pretty much like normal conf files, in that they would be text editable.

Jeff.

If it is important enough to everyone, I can probably finish it when I get back from camping (Sunday night or Monday evening). Have you already commited what you have done to CVS?

Curtis

"Jeffrey A. Wormsley" wrote

It would be knid of nice to be able to create a logo compliant app with a free tool, though ;^)

Yes I know, that's why I mentioned the possibility to support both (XML and registry). I just can't do everything on my own, perhaps someone from the Lazarus team can have a look on it? (although KCL is my main project, I have spend more time on this general stuff like XML, base64, RTTI and persistence than on KCL itself.)

cu,
Sebastian

Curtis White wrote

If it is important enough to everyone, I can probably finish it when I get back from camping (Sunday night or Monday evening). Have you already commited what you have done to CVS?

I have commited what I have done up to this point, here is what needs to be done.

I have cleaned up everything but the TNotebook stuff. That still needs to be converted to use the new SendMessage. I also didn't finish cleaning controls.inc itself to only use the common SendMessage. As soon as that is done then the gtkproc file can be cleaned to remove the IntSendMessage and the IntSendMessage2. Then I would suggest renaming IntSendMessage3 to just be IntSendMessage or something like that.

Then you need to go through all of the files and make sure that interfaces has been removed.

Then since the only thing that calls interfaces.pp is controls.pp it will be easy to remove this unit and change the gtkint name. However you can't do this until you create the new directories and move the files there since Jeff is makeing the win32int unit which will also have to be named guiapi.

Are you sure you want to get messed up with this? I have been working at this level of things for awhile so I know what's going on.

You will also have to modify some of the initialation stuff for starting up gtk_init and now win32_init.

Let's just say that this is going to get real involved. Myself I would think it would be better if you would continue working on new components and controls and let me deal with this when I get back. Everything will work as it is currently configured so leaving things alone doesn't really hurt anything. Shane needs specific controls and it might be better if you put your efforts into that.

IMHO :-)

Curtis White wrote

I really like this idea. It gives us a lot of flexibility if we ever want to expand on it. Plus, it could be easily converted to work with just about anything. I vote for doing the Registry as an XML file.

Did you ever had a look at fcl/xml/xmlcfg.pp? I've created this unit exactly for this purpose (originally for use in KCL applications, of course ;-) ). It would be really easy to add a generic interface for storing and retrieving hierarchical configuration data and to have two implementations of this interface: one for XML, and one for the Windows registry. The only differences between this implementations would be the constructors, as XML requires a file name and the registry would require the root key for a specific application.
(But it might be better not to use the Windows the one hand, Windows applications are expected to store their configuration in the registry, on the other hand the whole registry is a big mess)

cu,
Sebastian