1. packager/globallinks/lclextensions_package-0.6.1.lpl <https://github.com/graemeg/lazarus/commit/1f08853d6c395f8cdc6f5a17f576aadcefdd8cf1#diff-b63ec2eea110a76c389b9157d1972dac>

2. +1 −0
<https://github.com/graemeg/lazarus/commit/1f08853d6c395f8cdc6f5a17f576aadcefdd8cf1#diff-1b7d532b8503805bf41f081a47371282> packager/globallinks/virtualtreeview_package-5.5.3.1.lpl <https://github.com/graemeg/lazarus/commit/1f08853d6c395f8cdc6f5a17f576aadcefdd8cf1#diff-1b7d532b8503805bf41f081a47371282>

(trunk)

It is good filenames, with _package suffix, easy to see filenames from all filenames in big dir. AT* packages also use this suffix. i suggest to add this suffix to ALL default packages.

It is good filenames, with _package suffix, easy to see filenames from all

filenames in big dir

I don't agree, that's what file extension is for. Filtering and sorting should easily be done to distinguish package files from others.

I am glad to read this, I also think the _package is completely redundant.

Michael.

I don't agree, that's what file extension is for. Filtering and sorting should easily be done to distinguish package files from others.

There is one moment: ATSynedit has

- atsynedit.pas (main unit)

- atsynedit_package.pas (with suffix)

You see suffix is useful here.

I am glad to read this, I also think the _package is completely redundant.

many Laz packages have suffix anyway: Dsgn, Pkg, pkg, maybe others.

Again, we had this already in a similar context, but now it will break EVERY project out there.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180107/2105a6b9/attachment.html>

True. And this is unfortunate, because it is not "problem" is that the pascal unit generated for a package has the same name as the package and often conflicts with a unit in the package. IMO it would be better to prefix it automatically. (fpmake does this when it makes a build unit)

MyPackage.lpk -> build_Mypackage.pas
or maybe
MyPackage.lpk -> run_Mypackage.pas
MyPackage.lpk -> ide_Mypackage.pas
Depending on what you chose for package options.

That way you would not need to prefix your package name with anything, unless you split your package in a design and runtime package. In the latter case the prefix (or suffix) is still functional: it tells you that it is run or design...

Michael.

conflicts with a unit in the package. IMO it would be better to prefix it automatically.

I agree: better to auto add prefix or suffix (i like suffix _package). good wish.

[...] The "problem" is that the pascal unit generated for a package has the same name as the package and often conflicts with a unit in the package.

The package unit can have a different name as the package. See for example synedit.

Mattias

leledumbo wrote

I don't agree, that's what file extension is for.

Fully agree.

I feel I should also add that DOS is not the mainstream OS any more like it was in the early 90's (some 26 years ago), so why is everybody still limiting file extensions to 3 letters?? Some of my fpGUI included applications use file extensions like *.project etc. Hell, even Microsoft is catching up with that idea (although minor) and now use 4 letter extensions like *.docx etc.

Regards,
Graeme

Michael Van Canneyt wrote

> many Laz packages have suffix anyway: Dsgn, Pkg, pkg, maybe others. True. And this is unfortunate, because it is not , I think it is very important to distinguish between "runtime" and

"design time" packages. One has very different dependencies and meaning compared to the other one.

Your idea of fpmake using automatic prefixes is good and all, but when a developer creates a package using Lazarus IDE, there is no "automatic naming" in play.

The "pkg" suffix is pointless indeed, that is what the file extension is for. But the "dsgn" suffix is commonly used to distinguish between runtime (no suffix) and design time usage.

Regards,
Graeme

idea of fpmake using automatic prefixes is good and all, but when a

developer creates a package using Lazarus IDE, there is no "automatic naming" in play.

You are right, and i suggest this - make auto prefixes in IDE (when creating lpk?)

I didn't know this, and this is good to know !

Should not the IDE do this automatically by default then ?

Michael.

I didn't know this either. Where can the pas file name be changed? I can't find any entry in the Package Options dialog.

Ondrej

Hi,
click Package->New Package...
it immediately opens Save dialog, where you choose filname. It saves xyz.lpk Then click Compile and xyz.pas is autogenerated.
 
V.
______________________________________________________________

I didn't know this either. Where can the pas file name be changed? I can't find any entry in the Package Options dialog.

Ondrej

:D

The question was: it saves xyz.lpk, where can I define that abc.pas is autogenerated/used for xyz.lpk instead of xyz.pas?

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180107/017a3211/attachment-0001.html>

This issue seems to be only about the case one package = one component. I have 28 components in package where each component has unique name and I never needed any pre/suffix.  
V.
______________________________________________________________

There is one moment: ATSynedit has

- atsynedit.pas (main unit)

- atsynedit_package.pas (with suffix)

You see suffix is useful here.

I think, add a unit, select it in the list, right click it, and in "file type" make it the "main unit"

Maybe there is an easier way

SynEditDsgn has this

the auto generated unit is allsyneditdsgn.pas

and the unit with registration is "syneditlazdsgn.pas" (see checkbox at the bottom of package dialog.
So this as afaik why the unit will be called from the autogenerated unit.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180107/03ac9815/attachment.html>

Right click on an unit in the package editor and set File Type to "Main Unit". That is then the auto generated unit.

Here is how to create a new package with this:
http://wiki.freepascal.org/Lazarus_Packages#Create_a_package_with_a_unit_that_has_the_same_name_as_the_package

If you often need to create packages a custom main unit name, feel free to create a new package type or an initial setup dialog.

Mattias

Great, thank you! IMO it's perfectly sufficient as it is now. And I don't think the IDE should add any prefixes/suffixes by default.

Ondrej

I noticed: if the main package file has the same name as the lpk than it is not listed in that lpk, right? V.
______________________________________________________________

Right click on an unit in the package editor and set File Type to "Main Unit". That is then the auto generated unit.

Here is how to create a new package with this:
http://wiki.freepascal.org/Lazarus_Packages#Create_a_package_with_a_unit_that_has_the_same_name_as_the_package <http://wiki.freepascal.org/Lazarus_Packages#Create_a_package_with_a_unit_that_has_the_same_name_as_the_package>

If you often need to create packages a custom main unit name, feel free to create a new package type or an initial setup dialog.

Mattias

I noticed: if the main package file has the same name as the lpk than it is not listed in that lpk, right?

Correct.
Not every package needs such a file.

Mattias

On Sun, Jan 7, 2018 at 1:06 PM, Graeme Geldenhuys via Lazarus <

wrote: so why is everybody still limiting file extensions to 3 letters?? Some of

my fpGUI included applications use file extensions like *.project etc. Hell, even Microsoft is catching up with that idea (although minor) and now use 4 letter extensions like *.docx etc.

One reason is simply habit, but also because these extensions are visible to the user more often than not and having long extensions in filename lists (like, e.g, when using version control) become redundant noise and in some cases it takes space (like in file managers). Up to 4 letters is fine for me, 5 is stretching it and anything above that is only something i'd use for file types that i wont see often in a list and even then only if i can't avoid it (but really even just 4 characters gives you a lot of variation).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180108/7f56d207/attachment.html>

Then it seems Windows Explorer is right up your alley. :) They hide the file extension by default. Users (like me) have to explicitly go into the settings and enable "show file extensions" option.

Even better, Linux and FreeBSD don't even need file extensions. File Extensions are simply for [some] human benefit (unlike Windows that requires them). Linux and FreeBSD OS's query the first 4-8 bytes of a file to accurately determine the file type and use the appropriate application to open them.

Regards,
Graeme

Graeme Geldenhuys wrote

Even better, Linux and FreeBSD don't even need file extensions. File Extensions are simply for [some] human benefit (unlike Windows that requires them). Linux and FreeBSD OS's query the first 4-8 bytes of a file to accurately determine the file type and use the appropriate application to open them.

yup! i have a ton-load of scripts in perl, python, python3, bash, and just plain commands as if i were to type them manually... none of them have extensions on them... i don't even know what they are written in unless i go into them with an editor to modify them for some reason ;)

On Mon, Jan 8, 2018 at 11:38 PM, Graeme Geldenhuys via Lazarus <

wrote: Then it seems Windows Explorer is right up your alley. :) They hide the

file extension by default. Users (like me) have to explicitly go into the settings and enable "show file extensions" option.

I do the same as i dislike having the extensions hidden. I want them to be short, not hidden. Also you see file lists in more places than a file manager - a common one being version control programs.

Even better, Linux and FreeBSD don't even need file extensions. File

Extensions are simply for [some] human benefit (unlike Windows that requires them). Linux and FreeBSD OS's query the first 4-8 bytes of a file to accurately determine the file type and use the appropriate application to open them.

Not really. Linux, FreeBSD or any other Unix OS have no idea about file types beyond executable files (and that is set via the executable bit). Application association is something desktop environments concern themselves with. KDE and GNOME back in the 90s decided to use MIME types together with an association database based on globs and eventually they decided to create a common database through the freedesktop.org project. Today most (but not all) desktop environments tend to simply use this shared database which does the association from file to MIME type using several approaches, including globs and magic byte sniffing, depending on each type. In fact the recommended approach is to first match by glob and if that fails or produces conflicting results (e.g. two types claim a single file) only then to try to check the file's contents.

You can read the full spec here:
https://specifications.freedesktop.org/shared-mime-info-spec/0.18/ar01s02.html#idm139750558222816

Although note that this is just a convention and not a standard (freedesktop is not a standards body, it just happens to be popular enough due to being made by KDE and GNOME during their most popular days) - other desktop environments or programs do their own thing and more often than not this thing is based on pattern matching filenames for their extensions. It makes sense after all since opening a file to read its contents would be much slower - especially when done through network filesystems - than simply checking the filename, which is why the content checking part is used as a fallback instead of the primary way to determine the file contents (some file managers even ignore the magic part if they are browsing a network FS). And magic data do not really help with multipurpose file formats like containers - how are you going to tell the difference between a Java JAR, Java WAR and a LibreOffice ODT file when all are ZIP files? - or text files like JSON, Plist, INI and several others that are used for special purpose storage. Hell, you don't even need to look much further than Lazarus here: packages, projects and session files (and perhaps other stuff) are simple XML files and all of them even have the same root node and no namespace configuration, so you cannot really separate them from each other from anything else than the extension.

This "extension isn't a unix thing" wasn't even true in the days of the original Unix - extensions were used all over the place there too as they often were useful for shell scripts. The only system (that i know of) that really didn't need extensions was the classic MacOS which simply stored the file type as metadata and used that to decide what to do with the file. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20180111/1fac7b7a/attachment-0001.html>