> 1. glib likes to pass around gpointers. I like to pass around

TObjects. There are merits in doing both.

> By passing around TObjects we wave the application programmer from

constantly doing this: pointer( thing ).

> But, by restricting the user to TObjects, they can't store records.

The obvious solution is to overload

> the Inser function so that it accepts both pointers and TObjects. Any

other suggestions?

Why not make it a descendent of TList or TStrings (with whatever

enhancements you want) ?
Well, I don't think a hashtable, map, or other non-linked list class would fit that interface very well. About the only one that maps well is the singly-linked list.

TThread is implemented already. If possible, a descendent should be used.

I am thinking that TThread is fine for Delphi portability, but that a more comprehensive thread management interface will be needed. But for the creation of threads, I agree that there should be one interface: TThread. Perhaps a descendant class with a few extra methods.

Thanks for the comments,

John Margaglione

Why not make it a descendent of TList or TStrings (with whatever enhancements you want) ? I was planning to do this, but due to lack of time I didn't do it yet.

2. glib provides OS-independed threading/thread synchronization control. How should this be wrapped? Should it be a class, TThread, like Delphi 3 does it? Or should we integrate threading into TObject, like Java does it? I love the Java constructs, but that is a LOT more work on our part! Any suggestions?

TThread is implemented already. If possible, a descendent should be used.

Michael.

Wrapping glib is a good idea. In reference to your queastions:
1) Why not pass around TObjects and type cast them internally as a TLinkedList or whatever and store the gpointer within the class itself. Then you can pass the gpointer within the class that they passed you....understand?

2) I would go with TThread simply because our thought here is to create a Delphi-like environment and even if it's not perfect we would like to port over Delphi apps into this environment and have them compile. Creating a TThread to be added to our library would be useful.

Shane

>

There are a few issues I would like some comments upon, though.

1. glib likes to pass around gpointers. I like to pass around TObjects. There are merits in doing both. By passing around TObjects we wave the application programmer from constantly doing this: pointer( thing ). But, by restricting the user to TObjects, they can't store records. The obvious solution is to overload the Inser function so that it accepts both pointers and TObjects. Any other suggestions?

2. glib provides OS-independed threading/thread synchronization control. How should this be wrapped? Should it be a class, TThread, like Delphi 3 does it? Or should we integrate threading into TObject, like Java does it? I love the Java constructs, but that is a LOT more work on our part! Any suggestions?

I'm sure there's more, but I can't remember them anymore.

John Margaglione

>

Hi all,
�
I'm looking at wrapping up the glib functions in object wrappers.� Let me explain why:
�
1.� There is WAY too much useful functionality in there to pass up.� The FCL needs most of that functionality available, but programmers should not have to revert to C programming constructs to use it.
�
2.� By wrapping up the functions in objects, we open up the possibility of converting the object implementations to pure pascal in the future, with minimal impact to application code (including our implementation of the gtk libraries).
�
Example:
�
class TLinkedList = class(TObject)
� private
��� _list: TGList;
� public
��� constructor Create;
��� destructor�Destroy;
override;
�
��� procedure Insert( obj: TObject
);
��� procedure Remove( obj: TObject
);
� end;
�
The public interface is now clear of glib
constructs/variables, and the application programmer doesn't need to know/care about glib.
�
There are a few issues I would like some comments upon, though.
�
1.� glib likes to pass around gpointers.� I like to pass around TObjects.� There are merits in doing both.� By passing around TObjects we wave the application programmer from constantly doing this: pointer( thing ).� But, by restricting the user to TObjects, they can't store records.� The obvious solution is to overload the Inser function so that it accepts both pointers and TObjects.� Any other suggestions?
�
2.� glib provides OS-independed threading/thread synchronization control.� How should this be wrapped?� Should it be a class, TThread, like Delphi 3 does it?� Or should we integrate threading into TObject, like Java does it?� I love the Java constructs, but that is a LOT more work on our part!� Any suggestions?
�
I'm sure there's more, but I can't remember them
anymore.
�
John Margaglione
<A
href="">

You lost me. What do you mean by "cast them internally"? Do you mean the wrapped class, or the TObject being passed to a function of the wrapped class?

Wrapping glib is a good idea. In reference to your queastions: 1) Why not pass around TObjects and type cast them internally as a

TLinkedList or whatever and store the gpointer within the class itself. Then you can pass the gpointer within the class that they passed you....understand?

2) I would go with TThread simply because our thought here is to create a

Delphi-like environment and even if it's not perfect we would like to port over Delphi apps into this environment and have them compile. Creating a TThread to be added to our library would be useful.

Michael C. says we already have a TThread class. I'll look into the source and see if I can dig it up. If we have a usuable TThread class, I see no reason to make another one. Unless there is additional functionality to be had. Actually, TThread in Delphi never handled mutexes and semaphores, so maybe there is some merit. I'm not sure how well using TThread as a descendant will work.

This brings me to another issue: I realize the importance of bringing over current Delphi projects, and therefore we need a compatible interface. However, I would very much like to see us fix any of the deficiencies of Delphi (real container classes and thread management classes come to mind). This interface should probably be separate from the main interface. Unless we want to start using real-live interfaces (pure abstract classes) as a basis for our libraries.

But,

I'll be working on the first version of the interfaces this week. If there are any particular wrappings that you need, please let me know and I will boot them to the top of the list. I'll most likely start off with linked lists, then move to hashtables, then maybe the thread stuff.

John Margaglione

Not way off but I'm not sure if it is practical. While that would be a wonderful goal I'm not sure if it would be possible. In the simpliest of Delphi programs it will probably be possible. The problem is most of my Delphi programs I write are not just written using simple components. Almost all of them use special DLLs written for Windows. Or they might use an ActiveX and many call Windows APIs and deal with trapping Windows messages. So in that sense there is no way that I would be able to do a clean write once compile anywhere which is what you are suggesting.

I feel that our goal should be that they can port their Delphi code but then still need to tweek and modify it for use in FPC. Once they have written it for FPC then they can compile it for Linux OR Windows. They do not have to go BACK to Delphi.

We just need to create and environment where current Windows Delphi developers will feel comfortable and have some familiarity of how to do things. They also need to be able to enhance their investment by not having to write code once for Windows and a second time for Linux. While I like Open Source it doesn't put bread on the table. Unless some programmers can leverage their work on Linux and be able to sell version of their software for that platform Linux will just never quite get to the level of Windows as the personal or corporate desktop of the world.

Opinion generator turned off now. :-)

Greetings all,

I'm new to the group, just a long time delphist checking up on interesting projects.

rgds,
RAM

John Margaglione wrote

Does anyone know how to convert a pascal String to a glib PGChar? I assumed that since PGChar is actually just a pointer to a char, that I could use PChar( stringvar ). That, however, doesn't compile. I tried PGChar(PChar(stringvar)). That didn't work either. Any ideas?

If you use ansistrings
PChar(SringVar)
will work.

If not, you must use the strpcopy () function. (see strings unit in documentation)

Michael.

Does Linux have an equivalent to Microsoft's UNICODE support? As a programmer, I find the transitioning between UNICODE and ANSI strings (in Win32 Api calls) annoying. Does this issue exist in linux (regardless of the programming language?).

== d0hb0y

I think this is a great idea. But I think that maybe improvements over Delphi should be put into a compiler switch so "Delphi Compatible" mode can be enabled or disabled. That way if someone wants to port pure Delphi code, they can without worrying that something extra might get added in. But I would sure hate to limit people who are smart enough to be programming in Linux to Windows limitations :-)

Curtis

d0hb0y wrote

Does Linux have an equivalent to Microsoft's UNICODE support? As a programmer, I find the transitioning between UNICODE and ANSI strings (in Win32 Api calls) annoying. Does this issue exist in linux (regardless of the programming language?).

gtk+ 1.4 will have native Unicode support, the standard libc has e.g. mbs[r]towcs and wcs[r]tombs to convert between char* and wchar_t*. Also glibc2.1 is introducing Unicode versions of many standard libc functions, if compatibility with other/older libcs is not an issue. (Traditionally Unix systems didn't support Unicode, and is largely ASCII-based, the heritage of which *is* present in Linux, but GNU is aiming for the future with its Unicode-aware extensions.)

I agree. I don't think we should limit Lazarus to only the functionality that Delphi provides. Linux offers much more than Windows. I was just thinking that it might be interesting to write a program in Lazarus and be able to export it to Delphi, or be able to read in a Delphi program into Lazarus and compile it. Basically, that would mean Lazarus is a Delphi++ :)

I didn't realize that glib was portable to Windows. Just my lack of knowledge. So will this require Delphi users to load glib and then replace Borlands built-in components with ours?

I was under the impression that we were building the equivilent of the Delphi components using glib so we could compile Delphi programs under Linux without change, with extended functionality to take advantage of Linux's added abilities. Then the programs could move to Windows and back without change run in both environments. I just wonder if very many Delphi programmers will be willing to replace Borlands components with ours.

I may be way off base here. If so, not a problem. I will be happy to be enlightened on this :) I probably just need a little better understanding of what our end goal is. Either way, I am enjoying working on it!

Curtis

Does anyone know how to convert a pascal String to a glib PGChar? I assumed that since PGChar is actually just a pointer to a char, that I could use PChar( stringvar ). That, however, doesn't compile. I tried PGChar(PChar(stringvar)). That didn't work either. Any ideas?

John

I don't know that a compiler switch would be necessary, since all of this code would be Windows-portable via glib. This would, however, entail porting the glib wrappers to compile under Delphi. But this may be irrelevant anyway. If a programmer wants an executable that runs under both Linux and Windows, he can use the FPC to make a Windows-native OR Linux-native version, and that version would link to the Windows port or Linux port of glib. So cross-platform compatibility is maintained.

Now, if we're looking at cross-TOOL compatibility, that's a different issue, and one I don't entirely agree with. I think importing Delphi code is one thing, but constraining Lazarus to Delphi functionality is a big mistake. Here's why I think that: Delphi was written by Borland to address *Windows* users using *Windows* technology. So their main focus has been MS compatibility. That means COM and the Windows API. We will never be able to support those! Unless WINE comes through, but then we don't have a purpose, as Delphi would run under Linux! We should consider making Lazarus an *alternative* to Delphi, not a *replacement*. I would like to see us follow the Delphi model, because I love it, but we will never be able to achieve anywhere near 100% (or even 90%) cross-tool compatibility. If we are really making Delphi for Linux, then by all means let's make Delphi for LINUX!

John

Interestingly enough, Java deals ONLY with Unicode strings. You can read and write ansi strings, but internally the String class is Unicode. I happen to think that all-Unicode languages are great, but I happen to work for a Japanese-owned company, so I'm always under the threat of porting to extremely non-Western languages.

Would it be too much to make the FPC String class Unicode? Are there good reasons to do this (not to do this)? Personally I would like to be able to transparently use unicode (no translation function!).

John Margaglione

_______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com