Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2011-02

LCL=Package changes issue

11 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Joost van der Sluis

Hi all,

Although the new LCL=package approach is a big step forward, I have the idea that all complaints about the old system, which you can find everywhere, are all addressed. But those parts that were useful for the power-users, who didn't complain, have become a little bit trickier.

One thing, for example. I have a package installed which only compiles for gtk2. I use it to design forms (webpages, actually). Now I have an application that depends on this package because of other dependencies, but doesn't really use it. But I compile this application for the 'nogui' widgetset.

Now the IDE detects a change in settings (as I understood it right), so recompiles all packages with the settings for the application. Which fails, because my package doesn't compile for 'nogui'.

Is there some 'trick' possible to avoid this? Or do I have to split up some packages so it has a design-time and a run-time part? (Making maintenance and installation more difficult for new users?)

Joost.

Reply by email

Unknown author
to Joost van der Sluis
Joost van der Sluis wrote 20 lines
Hi all, Although the new LCL=package approach is a big step forward, I have the idea that all complaints about the old system, which you can find everywhere, are all addressed. But those parts that were useful for the power-users, who didn't complain, have become a little bit trickier. One thing, for example. I have a package installed which only compiles for gtk2. I use it to design forms (webpages, actually). Now I have an application that depends on this package because of other dependencies, but doesn't really use it. But I compile this application for the 'nogui' widgetset. Now the IDE detects a change in settings (as I understood it right), so recompiles all packages with the settings for the application. Which fails, because my package doesn't compile for 'nogui'. Is there some 'trick' possible to avoid this? Or do I have to split up some packages so it has a design-time and a run-time part? (Making maintenance and installation more difficult for new users?)

You should always do so ? This is also true in Delphi as of version 6. I think it is good to force users to separate design and run-time code.

I would even go so far as to forbid the dependency of a run-time package on a design-time package if the latter depends on the IDE interface package.

Michael.

Reply by email

Joost van der Sluis
to Unknown author
Show quoted text 29 lines
On Thu, 10 Feb 2011, Joost van der Sluis wrote: > Hi all, > > Although the new LCL=package approach is a big step forward, I have the > idea that all complaints about the old system, which you can find > everywhere, are all addressed. But those parts that were useful for the > power-users, who didn't complain, have become a little bit trickier. > > One thing, for example. I have a package installed which only compiles > for gtk2. I use it to design forms (webpages, actually). Now I have an > application that depends on this package because of other dependencies, > but doesn't really use it. But I compile this application for the > 'nogui' widgetset. > > Now the IDE detects a change in settings (as I understood it right), so > recompiles all packages with the settings for the application. Which > fails, because my package doesn't compile for 'nogui'. > > Is there some 'trick' possible to avoid this? Or do I have to split up > some packages so it has a design-time and a run-time part? (Making > maintenance and installation more difficult for new users?) You should always do so ? This is also true in Delphi as of version 6. I think it is good to force users to separate design and run-time code. I would even go so far as to forbid the dependency of a run-time package on a design-time package if the latter depends on the IDE interface package.

I thought you would say so. I hoped Mattias would respond earlier then you. ;)

But even in that case: to properly design my project you need this design-time package. So I want my project to depend on this design-time package, or else users who open it will not be prompted to install this design-time package. All they will see are some error messages that the IDE can not handle the forms.

But now the project depends on the design-time package, so it will try to compile it with the new settings, so this particular problem is still not solved.

Joost

Reply by email

Unknown author
to Joost van der Sluis
Joost van der Sluis wrote 39 lines
On Thu, 2011-02-10 at 11:55 +0100, wrote: > > On Thu, 10 Feb 2011, Joost van der Sluis wrote: > >> Hi all, >> >> Although the new LCL=package approach is a big step forward, I have the >> idea that all complaints about the old system, which you can find >> everywhere, are all addressed. But those parts that were useful for the >> power-users, who didn't complain, have become a little bit trickier. >> >> One thing, for example. I have a package installed which only compiles >> for gtk2. I use it to design forms (webpages, actually). Now I have an >> application that depends on this package because of other dependencies, >> but doesn't really use it. But I compile this application for the >> 'nogui' widgetset. >> >> Now the IDE detects a change in settings (as I understood it right), so >> recompiles all packages with the settings for the application. Which >> fails, because my package doesn't compile for 'nogui'. >> >> Is there some 'trick' possible to avoid this? Or do I have to split up >> some packages so it has a design-time and a run-time part? (Making >> maintenance and installation more difficult for new users?) > > You should always do so ? This is also true in Delphi as of version 6. > I think it is good to force users to separate design and run-time code. > > I would even go so far as to forbid the dependency of a run-time package on > a design-time package if the latter depends on the IDE interface package. I thought you would say so. I hoped Mattias would respond earlier then you. ;) But even in that case: to properly design my project you need this design-time package. So I want my project to depend on this design-time package, or else users who open it will not be prompted to install this design-time package. All they will see are some error messages that the IDE can not handle the forms.

This is also the case in Delphi.

I don't see a problem with that, because you should always install the design-time package, never a run-time package. The run-time package will automatically be compiled when you install the design-time package.

If you stick to this rule, then your "problem situation" will not .

Reply by email

Joost van der Sluis
to Unknown author
Show quoted text 17 lines
On Thu, 10 Feb 2011, Joost van der Sluis wrote: > On Thu, 2011-02-10 at 11:55 +0100, wrote: >> I would even go so far as to forbid the dependency of a run-time package on >> a design-time package if the latter depends on the IDE interface package. > > I thought you would say so. I hoped Mattias would respond earlier then > you. ;) > > But even in that case: to properly design my project you need this > design-time package. So I want my project to depend on this design-time > package, or else users who open it will not be prompted to install this > design-time package. All they will see are some error messages that the > IDE can not handle the forms. This is also the case in Delphi.

Well, I think that's not user-friendly. If I open a project I would like to see that the IDE tells me: install this package and it will work.

I don't see a problem with that, because you should always install the design-time package, never a run-time package. The run-time package will automatically be compiled when you install the design-time package.

Now you are confusing Lazarus with Delphi. In Lazarus it is impossible to install a design-time package which depends on a run-time package without installing the run-time package. So also all run-time packages have to be installed.

(Note however, that if you use fpmake, you can put the runtime-part in the fpmake-package, and separately install a designtime-package into Lazarus. Now in this case I use fpmake, so I can circumvent this problem. But I'm the only one who uses fpmake this way... But then remains the problem: how do I tell Lazarus/the user that he need to install a package when he opens the project?)

If you stick to this rule, then your "problem situation" will not , the user will need to know this rule. So when he opens the

project, and the IDE complains that he needs the 'WebDesign' package, he has to know that he has to install the 'WebDesign-designtime' package, and not the 'webdesign' package as the IDE tells him to do...

Joost.

Reply by email

Mattias Gaertner
to Joost van der Sluis
Show quoted text 30 lines
On Thu, 2011-02-10 at 12:14 +0100, wrote: > > On Thu, 10 Feb 2011, Joost van der Sluis wrote: > > > On Thu, 2011-02-10 at 11:55 +0100, wrote: > >> I would even go so far as to forbid the dependency of a run-time package on > >> a design-time package if the latter depends on the IDE interface package. > > > > I thought you would say so. I hoped Mattias would respond earlier then > > you. ;) > > > > But even in that case: to properly design my project you need this > > design-time package. So I want my project to depend on this design-time > > package, or else users who open it will not be prompted to install this > > design-time package. All they will see are some error messages that the > > IDE can not handle the forms. > > This is also the case in Delphi. Well, I think that's not user-friendly. If I open a project I would like to see that the IDE tells me: install this package and it will work. > I don't see a problem with that, because you should always install the > design-time package, never a run-time package. The run-time package will > automatically be compiled when you install the design-time package. Now you are confusing Lazarus with Delphi. In Lazarus it is impossible to install a design-time package which depends on a run-time package without installing the run-time package. So also all run-time packages have to be installed.

The IDE warns when installing a runtime package directly.

Show quoted text 6 lines
(Note however, that if you use fpmake, you can put the runtime-part in the fpmake-package, and separately install a designtime-package into Lazarus. Now in this case I use fpmake, so I can circumvent this problem. But I'm the only one who uses fpmake this way... But then remains the problem: how do I tell Lazarus/the user that he need to install a package when he opens the project?)

Just opening a project does not require to install a package. Opening a form does.
At the moment the IDE warns for all needed designtime packages, which can be annoying if the form does not use any component of the package.

Show quoted text 7 lines
> If you stick to this rule, then your "problem situation" will not > appear at all. Well, the user will need to know this rule. So when he opens the project, and the IDE complains that he needs the 'WebDesign' package, he has to know that he has to install the 'WebDesign-designtime' package, and not the 'webdesign' package as the IDE tells him to do...

Yes, that is an open issue.
If a project requires a design-time-only package, it should not be compiled to the project.

Mattias

Reply by email

Joost van der Sluis
to Mattias Gaertner
Mattias Gaertner wrote 11 lines
On Thu, 10 Feb 2011 12:53:25 +0100 Joost van der Sluis wrote: > > Well, the user will need to know this rule. So when he opens the > project, and the IDE complains that he needs the 'WebDesign' package, he > has to know that he has to install the 'WebDesign-designtime' package, > and not the 'webdesign' package as the IDE tells him to do... Yes, that is an open issue. If a project requires a design-time-only package, it should not be compiled to the project.

Ah, shall I submit a feature-request, or do you have this already on your todo-list? This will solve my problem, well, if I split into a runtime and designtime package.

Joost.

Reply by email

Mattias Gaertner
to Joost van der Sluis
Show quoted text 16 lines
On Thu, 2011-02-10 at 13:12 +0100, Mattias Gaertner wrote: > On Thu, 10 Feb 2011 12:53:25 +0100 > Joost van der Sluis wrote: > > > > Well, the user will need to know this rule. So when he opens the > > project, and the IDE complains that he needs the 'WebDesign' package, he > > has to know that he has to install the 'WebDesign-designtime' package, > > and not the 'webdesign' package as the IDE tells him to do... > > Yes, that is an open issue. > If a project requires a design-time-only package, it should not be > compiled to the project. Ah, shall I submit a feature-request, or do you have this already on your todo-list? This will solve my problem, well, if I split into a runtime and designtime package.

Feel free to create such a feature request.

Mattias

Reply by email

Mattias Gaertner
to Mattias Gaertner
Show quoted text 19 lines
On Thu, 10 Feb 2011 13:48:09 +0100 Joost van der Sluis wrote: > On Thu, 2011-02-10 at 13:12 +0100, Mattias Gaertner wrote: > > On Thu, 10 Feb 2011 12:53:25 +0100 > > Joost van der Sluis wrote: > > > > > > Well, the user will need to know this rule. So when he opens the > > > project, and the IDE complains that he needs the 'WebDesign' package, he > > > has to know that he has to install the 'WebDesign-designtime' package, > > > and not the 'webdesign' package as the IDE tells him to do... > > > > Yes, that is an open issue. > > If a project requires a design-time-only package, it should not be > > compiled to the project. > > Ah, shall I submit a feature-request, or do you have this already on > your todo-list? This will solve my problem, well, if I split into a > runtime and designtime package.

I implemented it.

Mattias

Reply by email

Joost van der Sluis
to Mattias Gaertner
Mattias Gaertner wrote 24 lines
On Thu, 10 Feb 2011 15:08:58 +0100 Mattias Gaertner wrote: > On Thu, 10 Feb 2011 13:48:09 +0100 > Joost van der Sluis wrote: > > > On Thu, 2011-02-10 at 13:12 +0100, Mattias Gaertner wrote: > > > On Thu, 10 Feb 2011 12:53:25 +0100 > > > Joost van der Sluis wrote: > > > > > > > > Well, the user will need to know this rule. So when he opens the > > > > project, and the IDE complains that he needs the 'WebDesign' package, he > > > > has to know that he has to install the 'WebDesign-designtime' package, > > > > and not the 'webdesign' package as the IDE tells him to do... > > > > > > Yes, that is an open issue. > > > If a project requires a design-time-only package, it should not be > > > compiled to the project. > > > > Ah, shall I submit a feature-request, or do you have this already on > > your todo-list? This will solve my problem, well, if I split into a > > runtime and designtime package. I implemented it.

Do i need to set some setting, or should this be the case by default (for runtime-only packages)

Joost.

Reply by email

Mattias Gaertner
to Joost van der Sluis
Show quoted text 6 lines
[...] > > > > If a project requires a design-time-only package, it should not be > > > > compiled to the project. [...] Do i need to set some setting, or should this be the case by default (for runtime-only packages)

Just set your package to runtime only.

Mattias

Reply by email