Hey everyone developing in Linux. I found a decent IDE that has a Pascal plugin module for syntax highlighting. It is setup to compile using FPC and all. It is pretty decent to use for developing Lazarus in Linux. Basically, this one can be used in place of the Simple IDE we were previously building. It has Find/Replace and some other helpful options. If you are working on Lazarus in Linux under XWindows, I would suggest checking this one out. Much easier than vi and the command line :-)

Moonshine
http://www.rednecksoft.com/

BTW, I think this one also needs either KDE or the QT libraries.

Curtis

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

Why should they be called the same? Please remember we are making a Delphi like tool not a Delphi compatible tool. Do not expect this to be able to compile and build Delphi application as they are currently written for Delphi. You will be able to use it and write programs they same way that you do in Dlephi but not use Delphi code in it's entirity.

I am currently working on the layout for the DFM or LFM file which will be using XML which is nothing like the Delphi format. Expect there to be some differences most likely for the better.

They are the same thing as the hint. Initialy they got that name because that's whaat they are called in gtk. They should be changed to hints.

------------------------------------------------------------ Shane Miller

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.pcpros.net/~vbman
----------------------------------------------------------

I was just working on the notebook component, trying to figure out how this whole thing works (separating out the gtk code to the gtkint.pp unit). I noticed a couple things that we may want to change now before too much code gets written with them this way.

According to the instructions, to add a new component, we add a constant to vclGlobals.pp and then again to gtkint.pp. These are the exact same constants in both units. Why not just add it to vclglobals and then include that unit in the uses clause of gtkint? Then we just have to add the constant once.

Another thing I noticed was a function in gtkint called Converttogdk. This function converts a TColor to a gdk color. But this function name does not describe what the function does and could be really confusing. I suggest changing it to more closely resemble the way Delphi does these kind of functions and call it ColorToGDKColor. This would describe the what the function does much better. There is already a function called TColortogdkColor, but all it does is create a gdkcolor record, set the color to Red and return a pointer it. This function seems pretty useless as it is. It doesn't even do anything with the color that is passed in. I think these two functions should be combined to do what they are supposed to do.

Thanks...Curtis

I created a directory called lcl under lazarus. We will put all of the component code in there as I break them out into unit.pp and unitimp.inc files....

I did not know what else to call it lcl seemed cool to me. I did not wish to call them fcl to avoid any confusion between class libraries.

Cliff

It needs QT 1.42.

Don't forget to download the pascal module on the 'exchange' page. Default you only get C and C++

And be certain to set the MOONSHINE environment variable correct; you get a SEGV otherwise :)

Looks really cool. This is what you should try to beat in terms of nice GUI (not functionality) :-)

Michael.

I will fix the color conversion functions. I did them just as tests when doing the TCanvas stuff.

Shane Miller

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.pcpros.net/~vbman

There is one more thing I noticed that I forgot to mention. In the controls.pp unit is the TControls class. There are properties called ToolTip and ShowToolTip. In Delphi, these are called Hint and ShowHint and there is another called ParentShowHint. If we want to be compatible with Delphi, shouldn't these properties be called the same? Or are they something different.

Curtis

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

But still keep compatibility possible. See all the problems people have with the procvar of fpc which is also better, but uses a different syntax.

You can use the existing xml routines; the xmlfcg unit should show you how to use it.

I already started dissecting some of the XML stuff to get a better understanding. :-)

Curtis White wrote

OK. Well if that is the case, then why are we even using the same filenames and component list as Delphi?

A starting place.

Go for it. :-)

As a matter of fact, we could even create an import tool that would automatically convert their Delphi code to Lazarus when they "import" it.

That is sort of what I am going to be doing with the LFM. Since we don't have a RAD feature yet I planned on building a DFM to XML converter so that I could code the features for using the LFM before the RAD portion is finished. Then it will be possible to take Delphi DFM files and convert them into Lazarus LFM files.

Michael A. Hess wrote

I have to study this one some more. Can't find any books that really relate to it. Not surprising. :-)

It's brand new...

We also talked about building a resource compiler for the LFM (which is an XML file ). This is something I haven't dealt with before. Do you have any good leads for me to look at with regards to doing this?

http://wotsit.org/

search for 'res' you'll fid 2 references which explain the win32 resource format.

Michael.

Shane Miller wrote

They are the same thing as the hint. Initialy they got that name because that's whaat they are called in gtk. They should be changed to hints.

I vote that they stay as tips. As you indicated that is what they are called in GTK and I believe QT. I also know that that is what they are called in many Windows add-on tools for VB and Delphi and whatever. I think that Delphi is the only thing that calls them hints. To me a hint sounds like I am cheating. What it really is doing is tipping you off to what the tool can do.

I think you should have a look at http://www.w3.org/XML

Been there. Done that. :-)

Already bookmarked the link.

Went out this weekend and bought myself a real good book on XML so I can understand the stuff inside and out. :-)

and also the DOM (Document Object Model) can be found there.

Been there done that. :-)

I have to study this one some more. Can't find any books that really relate to it. Not surprising. :-)

We also talked about building a resource compiler for the LFM (which is an XML file ). This is something I haven't dealt with before. Do you have any good leads for me to look at with regards to doing this?

Cool;

You can use the existing xml routines; the xmlfcg unit should show you how to use it.

Michael.

I agree with Michael here if we aren't trying to be Delphi compatible. ToolTip is a much better (more accurate) name for it.

Curtis

That's why I said it's not surprising.

Great! I use this site alot but didn't think about looking there for something like this. I'll check it out.

Michael

I do a lot of XML stuff at work and am very familiar with it let me know if you need anything or have questions..

Cliff

Cliff Baeseman wrote

I do a lot of XML stuff at work and am very familiar with it let me know if you need anything or have questions..

Count on it. :-)

I am getting real familiar with XML. It really isn't that complicated once you get into it. What I might need some help with is the DOM stuff.

I agree that it doesn't HAVE to be the same, however we are trying to get people who programin Delphi to program for Linux. The easier we make that the better. If we make things like the tabber notebook the same that is best. However, we can also create a new TNotebook control that uses the same widget and makes tabbed notebooks easier to use. But I still think that we should make it also work like it does in Delphi.

Remember, if we create 2 kinds of tabbed notebooks the code isn't any bigger when compiled. If we only use one in our application, then the unused code isn't compiled into the EXE.

Make a standard "Delphi" notebook control, then we can worry about improving it by creating another version...

------------------------------------------------------------ Shane Miller

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.pcpros.net/~vbman
----------------------------------------------------------

I think you should have a look at
http://www.w3.org/XML
and also the DOM (Document Object Model) can be found there. The specs are clearly written, and they helped me out.

Michael.

I think you should anyway try to be much more Delphi compatible.

Experience with the compiler shows that this is what people expect. 90% of all users (if not more) says 'Hey, I have some TP or Delphi code, why won't it compile with FPC ?'

With the advent of 'Delphi for Linux' this situation is NOT going to improve; in fact I expect it to worsen a lot.

You may or may not like it; but this is a fact. So I would nevertheless opt for a large degree of delphi compatibility; definitely where the basic components are concerned, and low-level stuff as hints;

In the worst case, you just declare 2 properties; 'hint' and 'tip' they're technically only aliases, so your code doesn't get heavier.

Don't think that I want you to make an exact Delphi clone;
I'm just sharing my experiences here.

On the other hand; you will need to make a dfm2lfm tool anyway for the very same reasons; you could make that tool 'property - aware' in the sense that it could make a translation of well-known Delphi properties to lazarus properties.

Just my thoughts.

Michael.

Experience with the compiler shows that this is what people expect. 90% of all users (if not more) says 'Hey, I have some TP or Delphi code, why won't it compile with FPC ?'

However it shouldn't been copied for copying sake. It there is something better then it should be done that way.

On the other hand; you will need to make a dfm2lfm tool anyway for the very same reasons; you could make that tool 'property - aware' in the sense that it could make a translation of well-known Delphi properties to lazarus properties.

Already starting the research and design of that. :-)

OK. Well if that is the case, then why are we even using the same filenames and component list as Delphi? We have a huge list of components on the web site that are all Delphi components. But if we are not trying to make it Delphi compatible at all, then we shouldn't even worry about those components at all and should just make up our own based on what GTK and QT offer. It will be much easier to build if we make up our own component list and do not worry about if they are called the same thing or act the same as the Delphi components.

For example, I have been working on making the TNotebook component work like and have the same functions and properties as the Delphi TNotebook component. Then we would need another component called TTabbedNotebook that is similar, but has the tabs. If we are not trying to be Delphi compatible at all, then these two components could easily be combined into one that you could turn the tabs on or off.

I don't have a problem with was just under the impression from a lot of the discussion that has taken place that we are trying to be pretty much Delphi compatible (except for resource ffiles).

If we are not going to be compatible with Delphi, I think it might be a good idea to start a list of differences as we build/find them. That way when people want to port their Delphi applications to Lazarus, they will be able to easily find all the places their code needs to change. As a matter of fact, we could even create an import tool that would automatically convert their Delphi code to Lazarus when they "import" it. But we need to know what the differences are. I could start a web page that contains a list of the Delphi/Lazarus differences, if we want, unless someone else would prefer to maintain this list. Should we maintain this list, or not worry about it?

I agree. I much prefer using XML than what Delphi uses.

Curtis