Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006 13:36:23 -0600 L505 <[EMAIL PROTECTED]> wrote: >[...] > > > There are advantages and disadvantages of using real code versus using > > > DFM files. DFM files are a cleaner format than actual Pascal code. > > > Real code is easier to peak into and copy/paste than DFM files (but a > > > DFM to code converter can be made). DFM files make the exe bigger in > > > size than run time code, generally speaking. > > > > DFM make the exe smaller. It is the streaming code, that needs quite a > > lot of code. But this is a rather fixed amount. So for big applications > > or if the library is in a .dll/.so the DFM mke the exe smaller. > > You say DFM make the exe smaller, period. But you should say - DFM make > the exe smaller in some cases only. : > > Because I've never seen a DFM exe smaller than a non-DFM exe myself, but > I'll take your word for it. All the applications on my hard drive are > several small and only some medium size programs - I make a lot of small > utilities with only 1-5 forms in them. I don't make many large > applications that exist all inside one exe - most of the time I make a > bunch of small programs - then if I have one large program where I think a > small add-on would be useful, I make a plug in system. So it depends what > the threshold is where the DFM does make the EXE smaller, I guess. If it > requires that 5-10MB exe size exist before you start seeing gains in exe > size - that doesn't really affect me.. with the work I do. I generally > like to make the program have a plug-in system once it gets that large > anyway, so it would actually be more advantageous for me to have a lower > threshold. > > Do you know generally what the threshold is before you have seen the exe > become smaller from using DFM? 5MB? 6MB? This depends on how you are doing the non DFM part. For example setting 'Left' to 30 needs 9 bytes in DFM. OTOH for a pascal statement 'AControl.Left:=30' the compiler creates code to push the integer on the stack and call the SetLeft method, which certainly needs more than 9 bytes, but I never measured if this is 2 times or 10 times as much on average. > Lazarus is quite a nice and big application and is only 6MB. I would think > lazarus would be maybe 10MB in size, but it is only 6MB. So maybe we are > seeing the threshold kick in here? The IDE contains all components and does not use half of them. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
> > Back when I started using delphi, I wondered what black magic was creating > > my forms for me? Why couldn't I see and tap in to the code that created my > > forms? I guess curiosity kills the cat. > > You can edit the .dfm. Just not the form and the dfm at the same time. The DFM never told me when the components were created and freed, was what I was getting at. I wondered, as a beginner, what black magic allocated and freed the memory to create those forms. Long ago I was learning about run-time component creation and I wanted to modify my design time forms to be run time, by finding the actual code that freed and allocated the design time forms. I was looking for the code so I could turn my components into run time ones without writing all the run time code myself. I wanted to peak into the code and find out where form1 was created and freed.. couldn't do it. (could have maybe if I knew about GEExperts component to code tool). > > > > > 2) As anybody accidently deleted a component from a form. Afterwards, > > > you don't have a clue as the what custom options where set and what > > > other components it linked to. Have then is lines of code minimizes > > > this issue (yes Source Control software does help in such cases, but > > > not everybody uses source control software - poor folks). > > > > You still use a component pallette and visual design. You still delete > > and link components together. All components are still linked to each > > other the same way. You just link the components through the code instead > > of through an object format. Take Synedit for example: > > > > Synedit1.highlighter:= SynPasHighlighter; > > > > Your highligher is linked to your synedit component. Instead of unlinking > > it and linking it within the DFM file, you do so in the include file with > > real code in it. There's no difference from an end user perspective who is > > using the IDE - components being dropped on the forms will act just the > > same as if you were using a DFM file. > > Binary properties can be difficult to set in code. Like images/resources? > > > > There are advantages and disadvantages of using real code versus using DFM > > files. DFM files are a cleaner format than actual Pascal code. Real code > > is easier to peak into and copy/paste than DFM files (but a DFM to code > > converter can be made). DFM files make the exe bigger in size than run > > time code, generally speaking. > > DFM make the exe smaller. It is the streaming code, that needs quite a lot > of code. But this is a rather fixed amount. So for big applications or if > the library is in a .dll/.so the DFM mke the exe smaller. You say DFM make the exe smaller, period. But you should say - DFM make the exe smaller in some cases only. : Because I've never seen a DFM exe smaller than a non-DFM exe myself, but I'll take your word for it. All the applications on my hard drive are several small and only some medium size programs - I make a lot of small utilities with only 1-5 forms in them. I don't make many large applications that exist all inside one exe - most of the time I make a bunch of small programs - then if I have one large program where I think a small add-on would be useful, I make a plug in system. So it depends what the threshold is where the DFM does make the EXE smaller, I guess. If it requires that 5-10MB exe size exist before you start seeing gains in exe size - that doesn't really affect me.. with the work I do. I generally like to make the program have a plug-in system once it gets that large anyway, so it would actually be more advantageous for me to have a lower threshold. Do you know generally what the threshold is before you have seen the exe become smaller from using DFM? 5MB? 6MB? Lazarus is quite a nice and big application and is only 6MB. I would think lazarus would be maybe 10MB in size, but it is only 6MB. So maybe we are seeing the threshold kick in here? _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006 12:03:59 -0600 L505 <[EMAIL PROTECTED]> wrote: > > > > > 2. Replace the delphi dfm with a real code init (java style). > > > > > > > > What are the advantages? > > > > > > Easier component creation control/management via ONE language. > > > > 1) Please do not forget, that then you will be able to Search / > > Replace on component properties if they are in code! Currently the > > Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you > > do a normal search. > > You can still search and replace - you just store all the design time > components in an include file. > Instead of design time components via an DFM object file, you use an > include file with true Pascal code, not DFM object code. > > When you search for stuff in your code, the include file is not searched - > just as the DFM file is not searched when you search in Delphi. The > include file hides all the design time code so it does not bloat up your > code logic with design code. > > There are real world examples out there that uses this exact system. > KOL/MCK does it inside the Delphi IDE, and there is no difference between > editing a property of a MCK component from editing a property with a DFM > component - the only problem was that Delphi is designed highly around a > DFM system - so KOL/MCK had to implement tricks to get it working in > Delphi. But with an IDE that is not proprietory, no tricks would be > needed. > > Back when I started using delphi, I wondered what black magic was creating > my forms for me? Why couldn't I see and tap in to the code that created my > forms? I guess curiosity kills the cat. You can edit the .dfm. Just not the form and the dfm at the same time. > > 2) As anybody accidently deleted a component from a form. Afterwards, > > you don't have a clue as the what custom options where set and what > > other components it linked to. Have then is lines of code minimizes > > this issue (yes Source Control software does help in such cases, but > > not everybody uses source control software - poor folks). > > You still use a component pallette and visual design. You still delete > and link components together. All components are still linked to each > other the same way. You just link the components through the code instead > of through an object format. Take Synedit for example: > > Synedit1.highlighter:= SynPasHighlighter; > > Your highligher is linked to your synedit component. Instead of unlinking > it and linking it within the DFM file, you do so in the include file with > real code in it. There's no difference from an end user perspective who is > using the IDE - components being dropped on the forms will act just the > same as if you were using a DFM file. Binary properties can be difficult to set in code. > There are advantages and disadvantages of using real code versus using DFM > files. DFM files are a cleaner format than actual Pascal code. Real code > is easier to peak into and copy/paste than DFM files (but a DFM to code > converter can be made). DFM files make the exe bigger in size than run > time code, generally speaking. DFM make the exe smaller. It is the streaming code, that needs quite a lot of code. But this is a rather fixed amount. So for big applications or if the library is in a .dll/.so the DFM mke the exe smaller. > Now the question is: what does Java do this in its Visual ide's? Does it > create an include file with component properties stored as real Java code > - or does Java dump all the code into your Java source files and not > modularize it? I'm interested because I haven't tried any visual Java > ide's. Or does Java use some JFM format in some ide's ? Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006, [UTF-8] BogusÅaw Brandys wrote: > As an answer just look into way in which wxWidgets framework is > developed - XML based dialogs in zip file and totally separate source > code (with only some functions to load and initiate dialogs). > Completely separated GUI and logical code! This is positive,and Lazarus > is not too much behind this fashion. "Not too much behind" ? It was first :-) Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
> > > > 2. Replace the delphi dfm with a real code init (java style). > > > > > > What are the advantages? > > > > Easier component creation control/management via ONE language. > > 1) Please do not forget, that then you will be able to Search / > Replace on component properties if they are in code! Currently the > Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you > do a normal search. You can still search and replace - you just store all the design time components in an include file. Instead of design time components via an DFM object file, you use an include file with true Pascal code, not DFM object code. When you search for stuff in your code, the include file is not searched - just as the DFM file is not searched when you search in Delphi. The include file hides all the design time code so it does not bloat up your code logic with design code. There are real world examples out there that uses this exact system. KOL/MCK does it inside the Delphi IDE, and there is no difference between editing a property of a MCK component from editing a property with a DFM component - the only problem was that Delphi is designed highly around a DFM system - so KOL/MCK had to implement tricks to get it working in Delphi. But with an IDE that is not proprietory, no tricks would be needed. Back when I started using delphi, I wondered what black magic was creating my forms for me? Why couldn't I see and tap in to the code that created my forms? I guess curiosity kills the cat. > 2) As anybody accidently deleted a component from a form. Afterwards, > you don't have a clue as the what custom options where set and what > other components it linked to. Have then is lines of code minimizes > this issue (yes Source Control software does help in such cases, but > not everybody uses source control software - poor folks). You still use a component pallette and visual design. You still delete and link components together. All components are still linked to each other the same way. You just link the components through the code instead of through an object format. Take Synedit for example: Synedit1.highlighter:= SynPasHighlighter; Your highligher is linked to your synedit component. Instead of unlinking it and linking it within the DFM file, you do so in the include file with real code in it. There's no difference from an end user perspective who is using the IDE - components being dropped on the forms will act just the same as if you were using a DFM file. There are advantages and disadvantages of using real code versus using DFM files. DFM files are a cleaner format than actual Pascal code. Real code is easier to peak into and copy/paste than DFM files (but a DFM to code converter can be made). DFM files make the exe bigger in size than run time code, generally speaking. Now the question is: what does Java do this in its Visual ide's? Does it create an include file with component properties stored as real Java code - or does Java dump all the code into your Java source files and not modularize it? I'm interested because I haven't tried any visual Java ide's. Or does Java use some JFM format in some ide's ? _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
As an answer just look into way in which wxWidgets framework is developed - XML based dialogs in zip file and totally separate source code (with only some functions to load and initiate dialogs). Completely separated GUI and logical code! This is positive,and Lazarus is not too much behind this fashion. Regards Boguslaw _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
2006/5/11, Michael Van Canneyt <[EMAIL PROTECTED]>: On Thu, 11 May 2006, Al Boldi wrote: > Michael Van Canneyt wrote: >> On Thu, 11 May 2006, Micha Nelissen wrote: >>> Al Boldi wrote: >> 2. Replace the delphi dfm with a real code init (java style). > > What are the advantages? Easier component creation control/management via ONE language. >>> >>> Management of custom modified code is a PITA and will be a failure for >>> big complex forms. Separate DFM/LFM is one *the* best things of Delphi >>> (and Lazarus), nice separation of layout and behaviour. >> >> My opinion too. > > Separation of layout and behaviour would still hold, only w/o requiring a > special scripting language. > > Remember, the DFM thing is really a copy-cat of VB's FRM format. I think exactly not: VB's frm files contain the code as well. I totally agree. The code must be separated from the interface. I'm currently coding in a language that combines both, even the object encaptulation. It is a nightmare. As for the binary aspect of files, yep, the form files could be code a little bit more, and binary data escaped. But asside that the actuel structure is very good: code / form / ressources. -- Alexandre Leclerc _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
> Greetings! Hi. > Congrats for the delphi replacement. I think these guys are doing a great job. It's open source, so everybody can contibute... (I have some components I going to share). > 1. Lazarus ?!? Cheetah would be a better name, IMHO! The original name was "Megido", a japanese word. The project stop, and new guys "resurrected" with the "Lazarus" name. Check the "Lazarus" page for more info: http://lazarus.freepascal.org";>lazarus.freepascal.org I agree about the name change. Some dosc on the net suggest to avoid "religious" related name for software or hardware projects. Something similar happened to the freebsd O.S. they had a "daemon", not a "demon" pet, and try to make a new logo. http://www.freebsd.org>http://www.freebsd.org > 2. Replace the delphi dfm with a real code init (java style). You mean to have properties initial values in the same unit, (like VB6 or C# does) instead of a "resource" file. I don't think that's a good idea. Resource files allow to do a lot of stuff, like change the properties values without changing the code, change "skins" or "themes" of visual controls, or "localize" the messages, captions or titles into another message. "Resource" files can even be modified in a different editor. Works like some sort of "modular" programming. Any reason you would like that ? > 3. Allow to link in other langs (via plugin eclipse style). Not a bad idea, but the whole project still have to be more "mature". There still several stuff to be done. I would like to have C++ using Lazarus IDE. ;-) Borland did that with its IDE and "open tools A.P.I." and called "Galileo" project, not sure. - Marco Aurelio Ramirez Carrillo [EMAIL PROTECTED] [.mx] _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006, Al Boldi wrote: Michael Van Canneyt wrote: On Thu, 11 May 2006, Micha Nelissen wrote: Al Boldi wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. Management of custom modified code is a PITA and will be a failure for big complex forms. Separate DFM/LFM is one *the* best things of Delphi (and Lazarus), nice separation of layout and behaviour. My opinion too. Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. Remember, the DFM thing is really a copy-cat of VB's FRM format. I think exactly not: VB's frm files contain the code as well. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Al Boldi wrote: Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. It is not a language, let alone a scripting language. It's just PROP = VAL basically, but in OO-style. Micha _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Michael Van Canneyt wrote: > On Thu, 11 May 2006, Micha Nelissen wrote: > > Al Boldi wrote: > 2. Replace the delphi dfm with a real code init (java style). > >>> > >>> What are the advantages? > >> > >> Easier component creation control/management via ONE language. > > > > Management of custom modified code is a PITA and will be a failure for > > big complex forms. Separate DFM/LFM is one *the* best things of Delphi > > (and Lazarus), nice separation of layout and behaviour. > > My opinion too. Separation of layout and behaviour would still hold, only w/o requiring a special scripting language. Remember, the DFM thing is really a copy-cat of VB's FRM format. So from a modularization POV it's great, but from an implementation POV it feels like someone who has no-clue (script-addict) implemented it. > GExperts has an expert 'Components to code' which could be easily ported > to Lazarus. This can create a procedure which recreates (in code) a > number of selected components. > > This can be a useful addition. I agree, but remember that this should be 2-way, so some design time plugin would be necessary. Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Thu, 11 May 2006, Micha Nelissen wrote: Al Boldi wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. Management of custom modified code is a PITA and will be a failure for big complex forms. Separate DFM/LFM is one *the* best things of Delphi (and Lazarus), nice separation of layout and behaviour. My opinion too. GExperts has an expert 'Components to code' which could be easily ported to Lazarus. This can create a procedure which recreates (in code) a number of selected components. This can be a useful addition. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Al Boldi wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? Easier component creation control/management via ONE language. Management of custom modified code is a PITA and will be a failure for big complex forms. Separate DFM/LFM is one *the* best things of Delphi (and Lazarus), nice separation of layout and behaviour. Micha _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On 10/05/06, Al Boldi <[EMAIL PROTECTED]> wrote: > > 2. Replace the delphi dfm with a real code init (java style). > > What are the advantages? Easier component creation control/management via ONE language. 1) Please do not forget, that then you will be able to Search / Replace on component properties if they are in code! Currently the Delphi (and Lazarus I believe) doesn't seach dfm or lfm files when you do a normal search. 2) As anybody accidently deleted a component from a form. Afterwards, you don't have a clue as the what custom options where set and what other components it linked to. Have then is lines of code minimizes this issue (yes Source Control software does help in such cases, but not everybody uses source control software - poor folks). > dfm format is compatible with Delphi, so I can build the same software > with both. Yes, so keep a compatibility option. Why bother! If it is in code, Delphi will be able to build that code just fine! Delphi will not be able to view the form, but building is not an issue at all. Regards, - Graeme - -- There's no place like 127.0.0.1 _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Mattias Gaertner wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > 1. Lazarus ?!? Cheetah would be a better name, IMHO! > > Sounds like cheater. I know. > May be good, may be bad. Definitely good ;) > > 3. Allow to link in other langs (via plugin eclipse style). > > You can link to other languages if they provide c like structures. Yes, but what I meant was to make the IDE compiler-agnostic, ie. remove its dependency on FPC as a target compiler, which would make it much more competitive. Michael Van Canneyt wrote: > On Wed, 10 May 2006, Mattias Gaertner wrote: > > Al Boldi <[EMAIL PROTECTED]> wrote: > > > 2. Replace the delphi dfm with a real code init (java style). > > > > .lfm need a format that can be easily parsed. Pascal is too powerful. Of > > course it would not be hard to write a component writer, that writes > > pascal statements instead of .lfm files. If someone wants to implement > > that I can help. > > You can't, I think. > Binary properties cannot be expressed as pascal code. > (thinking bitmaps and so on) Leave those in a .res file. Felipe Monteiro de Carvalho wrote: > On 5/10/06, Al Boldi <[EMAIL PROTECTED]> wrote: > > 2. Replace the delphi dfm with a real code init (java style). > > What are the advantages? Easier component creation control/management via ONE language. > dfm format is compatible with Delphi, so I can build the same software > with both. Yes, so keep a compatibility option. > > 3. Allow to link in other langs (via plugin eclipse style). > > Please send a patch =) OK, but don't hold your breath :) Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Wed, 10 May 2006, Mattias Gaertner wrote: > On Wed, 10 May 2006 23:08:33 +0300 > Al Boldi <[EMAIL PROTECTED]> wrote: > > > > > Greetings! > > > > Congrats for the delphi replacement. > > Thanks. > Although it is a little bit humiliating to call lazarus a 'delphi > replacement'. The biggest part of the development time of FPC/Lazarus was > spent on features, that Delphi does not have. > And of course Delphi has a lot of features FPC/Lazarus do not have. > > > > It's rather neat, despite the following suggestions: > > > > 1. Lazarus ?!? Cheetah would be a better name, IMHO! > > Sounds like cheater. May be good, may be bad. > > > > 2. Replace the delphi dfm with a real code init (java style). > > .lfm need a format that can be easily parsed. Pascal is too powerful. Of > course it would not be hard to write a component writer, that writes pascal > statements instead of .lfm files. If someone wants to implement that I can > help. You can't, I think. Binary properties cannot be expressed as pascal code. (thinking bitmaps and so on) Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
On Wed, 10 May 2006 23:08:33 +0300 Al Boldi <[EMAIL PROTECTED]> wrote: > > Greetings! > > Congrats for the delphi replacement. Thanks. Although it is a little bit humiliating to call lazarus a 'delphi replacement'. The biggest part of the development time of FPC/Lazarus was spent on features, that Delphi does not have. And of course Delphi has a lot of features FPC/Lazarus do not have. > It's rather neat, despite the following suggestions: > > 1. Lazarus ?!? Cheetah would be a better name, IMHO! Sounds like cheater. May be good, may be bad. > 2. Replace the delphi dfm with a real code init (java style). .lfm need a format that can be easily parsed. Pascal is too powerful. Of course it would not be hard to write a component writer, that writes pascal statements instead of .lfm files. If someone wants to implement that I can help. > 3. Allow to link in other langs (via plugin eclipse style). You can link to other languages if they provide c like structures. And you can use fpc code just like a c library. If you want to use eclipse plugins: I never tried, but I guess, that could be as difficult as using an eclipse plugin in apache. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Suggestions for Improvement
Hello, On 5/10/06, Al Boldi <[EMAIL PROTECTED]> wrote: 2. Replace the delphi dfm with a real code init (java style). What are the advantages? dfm format is compatible with Delphi, so I can build the same software with both. 3. Allow to link in other langs (via plugin eclipse style). Please send a patch =) thanks, -- Felipe Monteiro de Carvalho _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] Suggestions for Improvement
Greetings! Congrats for the delphi replacement. It's rather neat, despite the following suggestions: 1. Lazarus ?!? Cheetah would be a better name, IMHO! 2. Replace the delphi dfm with a real code init (java style). 3. Allow to link in other langs (via plugin eclipse style). Thanks! -- Al _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
