I am trying to find information on the packages that are included by default with Lazarus (Win64). Many of their names aren't very descriptive and the majority of them don't include enough information in the "Package info" section of the Install/Uninstall Packages dialog to make an informed decision about whether to install them.

None of the packages in the "Install" list display anything more than a file path and a (redundant) indication that they are installed. Can I assume that these all provide some necessary functionally for the IDE, which would otherwise be either crippled or of limited value without them?

Most of the ones in the "Do not install" list at least have the author's name and a vague description of the package's purpose (some display nothing at all). Are these descriptions maintained by the contributing authors?

I have found some information by searching for the package's names on the internet but a new user shouldn't need to google a package when there's a perfectly good "Package Info" section that's not being used effectively.

My final question is: If I were to research each of these packages and determine their purpose how would I go about contributing more detailed descriptions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121009/84b5c954/attachment.html>

Which ones?

None of the packages in the "Install" list display anything more than a file path and a (redundant) indication that they are installed. Can I assume that these all provide some necessary functionally for the IDE, which would otherwise be either crippled or of limited value without them?

The base packages are:
lazutils, lclbase, lcl, codetools, synedit, lazcontrols, syneditdsgn, ideintf.
All other are optional.

Most of the ones in the "Do not install" list at least have the author's name and a vague description of the package's purpose (some display nothing at all). Are these descriptions maintained by the contributing authors?

Yes.

If you have an idea for a better description, don't hesitate to post it here.

Mattias

The IDE does not allow you to uninstall the base packages. You can not cripple the IDE with this way.

Mattias

Sorry, the real list is:
fcl, lazutils, lclbase, lcl, codetools, synedit, lazcontrols, ideintf.

Mattias

Mattias listed the base (or core) packages for you. If you are using Lazarus trunk, these currently have a red overlay in the bottom left of their icon (in the Install/Uninstall packages dialog). Packages included in the Lazarus distribution have a black L overlay in the bottom right of their icon.

Eventually, core packages will have a red LAZ overlay instead while non core Lazarus packages will have a black LAZ one.

Stephano

2012/10/10 Kenneth Cochran :

My final question is: If I were to research each of these packages and determine their purpose how would I go about contributing more detailed descriptions?

You could send a patch for each package that updates its description to the Lazarus bug tracker, there is a section "patches" in the bug tracker, this way each of your contributions can't be accidentally forgotten, has a number you can refer to and you can comfortably track which of them is still open. The mailing list has a tendency to "forget" things after a while if they are not super critical or somebody is not already working on it.

The simplest way to generate the patch is to check out svn trunk, make your changes locally and then use svn diff to generate the patch file for the changed files. (make sure the patch file affects only the files and contains only the changes you actually want to submit and not other unrelated changes). After this you can still use svn up to keep it synched with trunk even in the presence of local changes.

i do not see this in my laz 1.1 svn:38505 which i compiled on 2012 Sep 3... this is on w2kpro... all i have are orange boxes for the icons beside each package in the install/uninstall dialogue...

Then you're not using bleeding edge technology ;)
IIRC, this feature was implemented around mid September.

Stephano

as far as my machines and chosen OS', true... as far as sticking with pascal and using the latest and greatest FPC and Lazarus, false ;)

IIRC, this feature was implemented around mid September.

i note that the term "overlay" was used above... is this some fancy OS GUI thing? why can't the plain icons beside each package carry these notations??

oh, wait... mid-september... i need to update this dev box to the latest and see what it shows... my other box is updated but i rarely go into the packages area... i'll do this update in a bit and see what turns up ;)

i've just updated this dev box... looking at the svn changes, i think you are talking about this...

REV:38595 2012 Sep 9 IDE: Added package overlay icons

so, i'm now on 3942 if it compiles OK ;)

oops! 39042... and yes, confirmed on that version with laz 1.1 (trunk, IIRC)...

back to the icons, yes, they, too, have changed... now they all have tiny dark I or L in the bottom right and some also have a "light blue flag" in the top left... i'm on a 1600x1200 21inch monitor...

Now that your Lazarus is updated, the goal is to have:
- A light blue gear at the top left denotes a design package
- A green arrow at the top right denotes a runtime package
- A crossed out light blue gear and a green arrow denotes a runtime only package
- No overlay at the top denotes a design + runtime package

Stephano

That's over engineering in its finest I guess. you have only 2 states for a package and 4 icon sets?
As I see it
1) blue gear = design time package.
2) Green arrow = run time package.
everything else is not needed.
If an overlay is shown then that state is part of the package if not then it is not. This leaves one icon state with no meaning ee. no overlay is shown.
it would make more sense to me to change the crossed gear to design time but not installed or something and this has already been taken care off by the list boxes so you have two states to many.

Regards
Jo.

stdreamer hat am 11. Oktober 2012 um 15:43 geschrieben:

No.
The package type is not *two* booleans. For instance there is no type "not designtime and not runtime".

If an overlay is shown then that state is part of the package if not then it is not. This leaves one icon state with no meaning ee. no overlay is shown.

The purpose of an overlay is to spot the specials easier. By far the most packages are "design time and run time". Therefore they should not have any overlay or at most a very plain/unimposing one. There are three special package types:
design time - usable by projects, but not compiled into projects run time - usable by design time packages, but not directly installable run time only - not installable, not even indirectly

These are abstract topics and I doubt that you will find icons that the majority will understand.

Maybe the overlays should be different for each dialog. For example the install package dialog only shows "design & run time" and "design time".
The project inspector and package editor can show all four, but only the "design time" is noteworthy.

it would make more sense to me to change the crossed gear to design time but not installed or something and this has already been taken care off by the list boxes so you have two states to many.

We need multiple overlays.
One set for the type.
One set for "base" = "uninstallable".
One set for "is/will be installed".
Maybe one for "repository", for example the package "is in the Lazarus sources" or "comes from fppkg" or whatever repository.

Mattias

OK lets take a step back, and see this a bit simplistic.

1) The type of a package.

A package can be

1) run time package
2) Design time package.
3) Both
what else a package can be? Can a package

So far I have thought those things as flagged for a state or not flagged. for example a package that is flagged for run time it can be used by end user programs if it is not flagged it shouldn't. If it is flagged as design time the the IDE needs to load it and show what ever design time
The run time only state makes no sense to me, I would like an explanation but I do understand if this is outside this threads scope.

2) The Base. That is a big one this requires a new icon in my opinion eg shift the icons color to the red spectrum red is always danger or gold it is always considered needed.

3) installation state. There is no need for this to be shown on the icon area this can be done by changing the background color or the text color of the name why would you want an overlay for this?

4) Repository. Is not the icons job to show anything of the sort. if you must show that then I recommend to either add one more column that will show the packagers name or go for a treeview structure and keep everything grouped by the packager or both.

In sort the package icon should say things about the package only not the state of the installation or the package manager. Its a convenience that looses its value the moment that more than 1 overlays start cluttering that 16x16 pixel space.

Regards
Jo.

the problem, very subtly noted in my reply, is that they are too small to see what they really are... at least what i looked at in the package install area...

If you don't understand one of my points, just ask. Do not post my whole answer and then ignore it.

Incomplete. see above.

[...]

Mattias

These are the possibilities:
- design package : light blue gear at the top left
- runtime package : green arrow at the top right
- "runtime only" package : crossed out light blue gear and a green arrow
- design + runtime package: No overlay at the top

Note that "runtime only" is not the same as runtime. A runtime package can be used by a design time package that is installable in the IDE. A "runtime only" package will not allow any package that uses it to be installed in the iDE.

Stephano

That's a double edged sword for the time being I'll ignore it and move on to more productive thoughts.

What is incomplete? Which other states you have in mind Installable for instance? In that case let me ask you once more. What is the difference between a run time package and a run time only package? How can a design time package, use a run time only package and be installed in the IDE? What is the reason of existence of this option?

As for the Boolean part,
What would you answer if I asked you "is that a design time package ?"

and last but I think is the most important part the convention I have never questioned the branding of the packages this is just to satisfy my curiosity and it doesn't matter to me either way.

I red the last message you posted you have explained it there efficiently. My objection is that those are too many overlays that will make things harder not easier. There are a lot of ways to accomplish the same thing. For example

run time only package = gray box
run time = yellow box
design time = gray box with a gear
run time and design time = yellow box with a gear.

Note that "runtime only" is not the same as runtime. A runtime package can be used by a design time package that is installable in the IDE. A "runtime only" package will not allow any package that uses it to be installed in the iDE.

I don't understand the need for this but if it is there some one needs it.

Now interpreting the second post as an authoritative declaration and after I satisfied my insecurity of not being understood I'm going to stop posting any more objections I might have.

There are four types, you gave three.

Which other states you have in mind Installable for instance? In that case let me ask you once more. What is the difference between a run time package and a run time only package?

See above.

How can a design time package, use a run time only package and be installed in the IDE?

It can not.

What is the reason of existence of this option?

There are some packages that should never be installed, not even indirectly.

As for the Boolean part, What would you answer if I asked you "is that a design time package ?"

Do you mean
a) can this package be used at design time?
b) can this package only be used at design time?
c) should this package use type "design time"?
d) has the developer decided to use the type "design time"?

and last but I think is the most important part the convention I have never questioned the branding of the packages this is just to satisfy my curiosity and it doesn't matter to me either way.

Mattias

Yes, you where clear the first time you said that I still do not believe that such a condition is necessary, from lack of experience perhaps.

You are being evasive that tells me 2 things. One you do not really care about this conversation, which raises the question why you bothered answering in the first place, and two you see me like some kind of pest which dropped in from no where and spoiled your serenity, which raises the question why should I keep on wasting my time on this. Well, my opinion is in the open if you do fill like explaining I'll probably read it with interest.
In any case have fun.

Jo.

I'm not sure what you are reading between my lines. I'm not a native English speaker so maybe I misused a word and I apologize for that.
I explained in a former mail the package type "design time". Then you asked about "is that a design time package", which depending on context can mean different things. This is not your fault. As I explained earlier it is hard to give the four types unambiguous names. Maybe someone has better names for them.

Mattias

Maybe you should re-read and re-assess Mattias' replies. He is afterall one of the main core devs and consequently a treasure trove of info. But the question "is that a design time package ?" is quite ambiguous and can't be answered straight away.

As for the "runtime only" package type, there are packages which should not trickle into the IDE be it directly or indirectly as they are incompatible (eg: they conflict with LCL). I believe Mattias clarified this too.

Stephano

You haven't misused any word and I wasn't offended at any level I was trying to point out that there was no point on continuing down that path of conversation so please no apologies, it doesn't feel right.

No, I asked you how you would answer such a question I didn't include any "usage info" because they where irrelevant to the question. In any case it is of no importance to me If I do not like something I can always change it to accommodate my needs. There is no point for me continuing this conversation, I have tried to contribute my 2 cents and that is all I can do at this point. Sorry for leading this thread away from its original question.