On Sat, 3 Sep 2005, Mattias Gaertner wrote:
> On Sat, 3 Sep 2005 11:17:23 -0700
> "L505" <[EMAIL PROTECTED]> wrote:
>
> >
> > > > And FPC, too bad KOL is win32 specific, if would have solved the
> > > > eternal "huge executable" discussion.
> >
> >
> > True..
> > Someone has done work to get KOL working on Kylix, but I've never used or
> > tried Kylix.. so I don't know what size the KOL apps turn out to be. Plus,
> > they are done with QT.
> >
> > There is also light Pascal toolkit which I have tried - it makes
> > 300kb-400kb executables on linux and windows. But Mac and other platforms?
> > I don't know.
> >
> > I figured we could at least build tools to help make developing KOL and
> > lptk applications HALF visual with some sort of plug-in to lazarus. i.e.
> > even in text editors, you can do a bit of what I call visual HTML editing
> > with some nice toolbar widgets. Not 100 percent visual, but better than
> > just doing it all by hand. And even so, you could still create a 100
> > percent visual KOL development in lazarus, with a plug in. Since KOL uses
> > include files to create the components on the fly at run time, there is no
> > "lfm" or "dfm" stored in the executable. This means that all that needs to
> > be created, is a visual widget that inserts text into the include file in
> > the appropriate places (as opposed to Delphi that includes the DFM in the
> > exe).
> >
> > Maybe light Pascal toolkit won't work with the native lazarus designer,
> > but people could still make tools (plugins) that assist making light
> > Pascal toolkit applications. I think an include file setup would work with
> > light Pascal toolkit too, like with KOL. All components that are created
> > on application loading, are done via an include file. This hides the
> > component creation from the developer in the include file (as a DFM/LFM
> > does) , but yet it also let's the developer peak in and see how the
> > components are being created via the include file. With this extra
> > knowledge, the developer can now see how the internals of the visual IDE
> > actually work, and how the components are truly created on the fly.
> > Whereas dfm/lfm are kind of blackbox magic that is just done for you
> > without you ever seeing how (unless of course you look into the source
> > codes of lazarus IDE).
>
> Just some thoughts:
> Someone could create a TReader/TWriter which writes pascal include files
> instead of lfm.
> If the KOL classes descends from TComponent they can be edited like
> datamodule.
No. KOL does not use classes, which is why they make such compact code.
The reason applications are so big are the VMT's for classes.
Every virtual/dynamic method creates an entry in the VMT, thus referencing
the method, even if it is never used in your application. Therefore all
virtual methods are always compiled in every application, even if they
are not used.
KOL does not use classes, and therefore only code that is actually used
goes into your application, which makes it very small.
(I'm assuming here you use smartlinking)
> And if you want we can extend the designer to support TControl/TCustomForm
> similar classes. Then you could design KOL forms.
KOL is not based on classes, so that won't work. You can design forms using
the existing forms/whatever, and let the IDE create code based on the forms.
You could for instance create dummy components that support only the properties
for which KOL has methods, and design that. The form need not be distributed
with the application. The only problem is the callbacks, but the IDE codetools
could be used to extract the code of all methods.
Michael.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
