I have an idea to make LCL based TFontDialog- which will be LCL form, which can be called by TFontDialog.Execute (if Boolean variable in LCL is set). Why make it?

- we can make all best features of FontDlgs from all WSes

- we can make additional events- e,g, OnSelectFont (called when used selects name in listbox)

- we can make it resizable (and save/load size)

- same look on all WS

If it's good- ok to merge to Laz?

Not as default TFontDialog. Maybe as TLazFontDialog or similar.

zeljko

Default must be native OS dialog. I suggest to use my dialog when boolean option in LCL (will be added) true. Here's my GH repo with dialog which almost 100% mimics GTK2 FontDialog.
https://github.com/alexey-t/atfontdialog

It even increases preview height for big sizes >20.

zeljko wrote

Not as default TFontDialog. Maybe as TLazFontDialog or similar.

PM AlexeyT wrote

Default must be native OS dialog. I suggest to use my dialog when boolean option in LCL (will be added) true.

Please no!

Please no? What do other developers think, also no (lcl option for universal dialog not wanted)? AT

Alexey wrote

Please no? What do other developers think, also no (lcl option for universal dialog not wanted)? AT

IMHO, it should be a separate component. So no code will be pulled into the user app, if it is not used.

While certainly useful, it is not necessarily something that needs to be included by default.
With the online package manager, I would think that an installable package might be useful. (And could later be extended, to contain other dialog replacements)

AlexeyT wrote

Default must be native OS dialog. I suggest to use my dialog when boolean option in LCL (will be added) true.

The replies so far are not prides itself staying
with "native components". Granted I find that has many drawbacks, but that was LCL's design choice from the start, and will not change. I battled the same arguments/suggestions years back. ;-)

If you want the full benefits of 100% customisability, better go with the custom drawn toolkits out there. fpGUI and MSEgui are 100% custom drawn and fully written in Object Pascal - no limitations with what can be done.

Regards,
Graeme

zeljko wrote

On 03/06/2019 07:54 PM, AlexeyT via lazarus wrote: > I have an idea to make LCL based TFontDialog- which will be LCL form, > which can be called by TFontDialog.Execute (if Boolean variable in > LCL is set). Why make it?

I haven't checked recently, but the system TFontDialog on a mac does not an OK/cancel button, making the system dialog useless, so a standard alternative might be helpful. I reported this a while back (https://bugs.freepascal.org/view.php?id=13383) but it was closed as expected behavior, which I am not sure is right.

Checking further, is the font dialog working at all under carbon? Checking a couple of different versions of my program and lazarus simply gives an access violation when it is invoked. (These versions are from SVN a couple of months ago at least - I will check with current when I have time)

Colin

AlexeyT wrote

Here's my GH repo with dialog which almost 100% mimics GTK2 FontDialog. https://github.com/alexey-t/atfontdialog

On Windows the font dialog also allows to select the color which is missing here.

An issue: the dialog is resizable, but the height jumps back to its original value when I click into one of the listboxes.

PM zeljko wrote

Not as default TFontDialog. Maybe as TLazFontDialog or similar.

+1
AlexeyT, what is wrong in having a separate component for those who need it? If the current native dialogs have bugs (Carbon etc.) they should be fixed obviously. That is a different issue.

Mapping to native controls has its problems but it also has benefits. The beauty is that you can mix native LCL components with custom drawn ones.

Juha

Juha, I wanted to hook new dialog (ok, separate component) into TFontDialog. Can I make a patch to allow such a hook? It must be very small diff which don’t bloat the lcl.

Juha, I wanted to hook new dialog (ok, separate component) into TFontDialog. Can I make a patch to allow such a hook? It must be very small diff which don’t bloat the lcl.

Do you want to embed a component into the native dialog, or to create a complete custom drawn font dialog?

Mattias

Completely new form.

Do you want to embed a component into the native dialog, or to create a complete custom drawn font dialog?

PM Alexey wrote

Juha, I wanted to hook new dialog (ok, separate component) into TFontDialog.

I also feel a separate dialog, TLazFontDialog or whatever, is better. It should be put into a package and then provided through OPM. I think you should create a new package which can later be extended with other components.
I remember there was a long discussion about a currency edit component. I already then suggested a similar new package but the author did not want to make it.
Everybody wants to include their custom components in LCL. Why? The Online Package Manager is designed exactly for easy access to external components. Let's use it please!

Juha

Okay, will do so. About lcl patch, we ll talk later.

Juha Manninen wrote

Everybody wants to include their custom components in LCL. Why? The Online Package Manager is designed exactly for easy access to external components. Let's use it please!

PM Juha Manninen wrote

Everybody wants to include their custom components in LCL. Why?

Most likely because it is much easier to have a single "batteries included" installer that provides everything you need out of the box now and much more likely to be there and working in the future (since it is part of the codebase that the Lazarus devs are compiling against after every modification), than chase after packages provided by others who may or may not keep them available and up to date (keeping your own copies can solve the "available" part, but then you take unofficial ownership of the package for the "up to date" part).

FWIW i tend to avoid anything that isn't part of Lazarus itself personally. The only time i used an external package was with multithreadprocs and i was very happy when i saw it become part of Lazarus itself.

Besides, Lazarus already comes out of the box with a ton of packages, it isn't weird to expect that you can add more to it.

Which makes me wonder, what is the goal with the bundled packages? Are they going to transition to OPM with Lazarus only providing the "bare bones", are they going to stay frozen in time or are they going to be expanded and if so, what would be the criteria for expansion?

FWIW i think Python's approach sounds good here: the installers come "batteries included" with stable APIs that you can generally rely on being there in the future with no (or very minimal) changes (ignoring the Python2-to-Python3 fiasco at the moment), but you can still get more stuff through PIP and over time useful packages "migrate" from PIP to the official distribution (as long as there aren't functionality duplicates, but that is mainly because of Python's "there should be only one way to do something" and Lazarus already has several duplicates already).

Exactly.

Relying on packages somewhere in the cloud can lead to nasty surprises. I've been bitten by npm ("packaging on steroids") more than once when developing browser-based apps, and I am very reluctant to use such mechanisms. You're constantly chasing version numbers for no good reason.

IMO Lazarus should provide a decent selection that allows someone to do most common tasks without needing to install something extra. (what this "decent selection" is, is up for debate, of course)

Michael.

Well, that and where does the manpower originate from (aka "who does it?")

Adding more and more to the main product, means more resources needed to maintain it.

The Idea that none included packages can break (be broken by changes in the main product) or become outdated, already says it: There may be no one to maintain it.
Once added to the core product, the core team will maintain it ("must" maintain it), and therefore reduce efforts on other works.

Besides packages that come with Lazarus, but are not bigide have been broken before too. (afaik)

----
My understanding is (not using it myself, only from hearsay), that at current the OPM repository is maintained. So if there is a version that works, then opm should know, and you need not search for it yourself. Sure that may break sometimes, but as I said, so do packages that are in core.

A good idea, would be to have CI. If someone would invest the time, in setting it up, and contributing the test cases needed (start with "does it compile") then that would be a solution.
Provided the OPM registry is part of it.

If a change to trunk, would break an opm package, the team, and the package maintainer would know.

If the maintainer no longer exists, then the team can choose: Fix it, or remove it from opm.
In the past, afaik, packages have been moved from core to ccr (maybe due to similar reasons?)

----
Looking at the bugtracker, shows that core is already too big. And that therefore it does not guarantee, that all issues will be fixed - or will be fixed quicker than in an opm package.

Obviously.
Otherwise there would be no debate: just add all available stuff ;-)

Michael.

Just to confirm the carbon font dialog seems completely broken under the current SVN with OSX fully patched.
(https://bugs.freepascal.org/view.php?id=35214) Given Carbon is on its way out, replacing the native control with a (more or less equivalent) substitute might be the most sensible work-around. I am not sure top what extent the native dialog ever worked anyway, as it is not intended to be used as a modal dialog.

Colin

En Mon, 11 Mar 2019 07:01:33 -0600, Michael Van Canneyt via lazarus

BTW Is not fppkg something like npm?

and BTW although not for MVC but, can fppkg-lazarus integration be removed until it just works? I would like not to see the config lazarus IDE dialog to open on every launch just because fppkg is not setup right (Error: the Fppkg configuration is corrupt. et al), and there is no way the user can fix it (when you are not using 'by default' the default fpc install).

Jesus Reyes A.

At least it should explain, what it has tested and what failed exactly, to give the user some clue how to repair it.

Mattias

Op 15-03-19 om 20:55 schreef Jesus Reyes A. via lazarus:

BTW Is not fppkg something like npm?

Yes, but fppkg is used for Pascal-code. With the advantage that is can be compiled. So it is easier to spot broken dependencies.

Because 'it works'. At least, on my machine. ;)

The only way to catch all problems in the wild, is to release it into the wild. I think it's viable to use trunk for that.

Did you try to fix it? Does the initial-setup dialog show you the option to create a new fppkg configuration? Does that work? Is the prefix for the fpc-installation filled? Are there any other paths in the drop-down?

And, after you have re-created the config-files, what does 'fppkg listsettings' on the terminal show you? And 'fppkg list -d'?

Regards,

Joost.

Because 'it works'. At least, on my machine. ;)

:)

Indeed.

Does the initial-setup dialog show you the option to create a new fppkg configuration? Does that work?

Yes but it doesn't work, the error message say:
"Problem with Fppkg Configuration"
"Failed to create a new fppkg configuration. You will have to fix the configuration manually or reinstall Free Pascal"

There is a message in the log: "Error: the configuration is corrupt."

Is the prefix for the fpc-installation filled?

It is: C:\Users\Jesus\dev

Are there any other paths in the drop-down?

No

Using the "browse" button I selected the install dir of my trunk compiler which according to the help text (the one that contains the fpmkinst dir) is "C:\Users\Jesus\dev\fpcbin", it makes not difference or perhaps the same message "Error: the configuration is corrupt." appears.

And, after you have re-created the config-files, what does 'fppkg listsettings' on the terminal show you? And 'fppkg list -d'?

Using fpc trunk:

(In the following:
APPDIR=C:\Users\Jesus\AppData\Local\FreePascal\fppkg BINDIR=c:\Users\Jesus\dev\fpcbin\bin\i386-win32
)

BINDIR>fppkg listsettings
Warning: Configuration file is in an old format
Warning: Failed to write compiler-configuration file "APPDIR\config\default": Backup of file "APPDIR\config\default" to file "APPDIR\config\default.bak" failed.
Warning: Failed to write compiler-configuration file "APPDIR\config\default": Backup of file "APPDIR\config\default" to file "APPDIR\config\default.bak" failed.
Settings from configuration-files:
Global-section:
RemoteMirrorsURL: http://www.freepascal.org/repository/mirrors.xml RemoteRepository: auto
LocalRepository: "{AppConfigDir}" -> "APPDIR\" BuildDir: "{LocalRepository}build\" -> "APPDIR\build\" ArchivesDir: "{LocalRepository}archives\" -> "APPDIR\archives\" CompilerConfigDir: "{LocalRepository}config\" -> "APPDIR\config\" DefaultCompilerConfig: "default"
FPMakeCompilerConfig: "default"
Downloader: lnet
Commandline-section:
-section:
Name: global
Description: "global"
Dir: "\" -> "\"
Prefix: "" -> ""
InstallRepository:""
-section:
Name: local
Description: "local"
Dir: "APPDIR\\" -> "APPDIR\\"
Prefix: "APPDIR\" -> "APPDIR\"
InstallRepository:""
Using compiler configuration file "APPDIR\config\default": Compiler: "BINDIR\fpc.exe"
Target: i386-win32
Version: 3.3.1
GlobalPrefix: "" -> ""
LocalPrefix: "{LocalRepository}" -> "APPDIR\" GlobalInstallDir: "{GlobalPrefix}\" -> "\"
LocalInstallDir: "{LocalPrefix}\" -> "APPDIR\\"
Options: ""
Using fpmake-building compiler configuration file "APPDIR\config\default": Compiler: "BINDIR\fpc.exe"
Target: i386-win32
Version: 3.3.1
GlobalPrefix: "" -> ""
LocalPrefix: "{LocalRepository}" -> "APPDIR\" GlobalInstallDir: "{GlobalPrefix}\" -> "\"
LocalInstallDir: "{LocalPrefix}\" -> "APPDIR\\"
Options: ""

BINDIR>fppkg list -d
Start loading configuration file "APPDIR\fppkg.cfg" Warning: Configuration file is in an old format
Loaded global configuration from "APPDIR\fppkg.cfg" Settings from configuration-files:
Global-section:
RemoteMirrorsURL: http://www.freepascal.org/repository/mirrors.xml RemoteRepository: auto
LocalRepository: "{AppConfigDir}" -> "APPDIR\" BuildDir: "{LocalRepository}build\" -> "APPDIR\build\" ArchivesDir: "{LocalRepository}archives\" -> "APPDIR\archives\" CompilerConfigDir: "{LocalRepository}config\" -> "APPDIR\config\" DefaultCompilerConfig: "default"
FPMakeCompilerConfig: "default"
Downloader: lnet
Commandline-section:
Loading compiler configuration from "APPDIR\config\default" Configuration file "APPDIR\config\default" is updated with new configuration settings
Creating Backup File "APPDIR\config\default.bak"
Warning: Failed to write compiler-configuration file "APPDIR\config\default": Backup of file "APPDIR\config\default" to file "APPDIR\config\default.bak" failed.
Using compiler configuration file "APPDIR\config\default": Compiler: "BINDIR\fpc.exe"
Target: i386-win32
Version:
GlobalPrefix: "" -> ""
LocalPrefix: "{LocalRepository}" -> "APPDIR\" GlobalInstallDir: "{GlobalPrefix}\" -> "\"
LocalInstallDir: "{LocalPrefix}\" -> "APPDIR\\"
Options: ""
Loading compiler configuration for fpmake building from "APPDIR\config\default"
Configuration file "APPDIR\config\default" is updated with new configuration settings
Creating Backup File "APPDIR\config\default.bak"
Warning: Failed to write compiler-configuration file "APPDIR\config\default": Backup of file "APPDIR\config\default" to file "APPDIR\config\default.bak" failed.
Using fpmake-buildingcompiler configuration file "APPDIR\config\default": Compiler: "BINDIR\fpc.exe"
Target: i386-win32
Version:
GlobalPrefix: "" -> ""
LocalPrefix: "{LocalRepository}" -> "APPDIR\" GlobalInstallDir: "{GlobalPrefix}\" -> "\"
LocalInstallDir: "{LocalPrefix}\" -> "APPDIR\\"
Options: ""
Loading available mirrors from "APPDIR\mirrors.xml" Directory "\fpmkinst\i386-win32\" Not Found
Directory "\units\i386-win32\" Not Found
Directory "APPDIR\\fpmkinst\i386-win32\" Not Found Directory "APPDIR\\units\i386-win32\" Not Found
Minimum version of hash is not installed, using internal fpmkunit with limited functionality
Minimum version of paszlib is not installed, using internal fpmkunit with limited functionality
Minimum version of fcl-process is not installed, using internal fpmkunit with limited functionality
Minimum version of libtar is not installed, using internal fpmkunit with limited functionality
Minimum version of fpmkunit is not installed, using internal fpmkunit with limited functionality
Directory "\fpmkinst\i386-win32\" Not Found
Directory "\units\i386-win32\" Not Found
Directory "APPDIR\\fpmkinst\i386-win32\" Not Found Directory "APPDIR\\units\i386-win32\" Not Found
Loading available packages from "APPDIR\packages.xml" [<currentdir>] Action: "list" start
Name Installed Available
embweb - 0.9.1-970
gecko - 2.9.0-3
jquery - 0.9.0-842
lazmkunit - 0.9.3-1
lnet - 0.6.6-2613
webdesign - 0.9.0-906
[<currentdir>] Action: "list" end

The fppkg.cfg file is:

[Defaults]
ConfigVersion=4
LocalRepository={AppConfigDir}
BuildDir={LocalRepository}build/
ArchivesDir={LocalRepository}archives/
CompilerConfigDir={LocalRepository}config/
RemoteMirrors=http://www.freepascal.org/repository/mirrors.xml RemoteRepository=auto
CompilerConfig=default
FPMakeCompilerConfig=default
Downloader=lnet

I experimented with several Downloader settings, the important one, 'base' IIRC, doesn't work as it tries to download some files, it gets redirected to a https link that failes because there is no openssl support and it instructs to include some unit and recompile. This I found it by debugging, this is nowhere reported.

I noticed that it tries to download some files: mirrors.xml and packages.xml and someway I manually downloaded the files and put them where it supposed to find them, yet it will not work.

The first issue I found is that the setup dialog for fppkg doesn't look for a fppkg executable, it expects the install directory where is fpc supposed to be installed, I guess in order to use that for locating the right fppkg executable. I expect this to work as is only on released Lazarus because it tries to find the fpc executable by using the PATH environment dirs. This means that it doesn't matter what you choose in the setup Lazarus dialog as your desired compiler. I think this is the first thing that needs fixing. The rest should come after that.

Regards.

Jesus Reyes A.

Actually, an idea.

fppkg (the standalone) has a -C option, and one could have fpcmkcfg -3 and -4 to create a correct config for a compiler that is not on the PATH and place it next to fpc.cfg.

If the Lazarus packager fppkghelper would offer the same and try loading '$(Path($(CompPath(IDE)))\fppkg.cfg', I think most problems would be solved. CompPath(IDE) isn't entirely correct either, but it would be less wrong than the current order...

Op 20-03-19 om 06:21 schreef Jesus Reyes A. via lazarus:

So it is not reading a file that has just been generated.

Warning: Failed to write compiler-configuration file

And is does not have write-permissions on the file

  LocalRepository:       "{AppConfigDir}" -> "APPDIR\"

How can AppConfigDir resolve to "APPDIR"?

These files store a list of available packages, but here the main issue is that it can not find the installed packages.

Fppkg also has a library, which Lazarus uses to list all available packages. So the 'fppkg'-executable is not called. (This changes when the fppkg-packagemanager is installed) And you and Martok are right, we have to find a way to solve problems with the proper configuration file being used.

But in your case, Lazarus should create a 'local' configuration file in your user-profile, that should 'override' the global configuration file. This ain't happening, it seems.

I've addded some tests around fpcmkcfg, and an error-message when it fails to write one of those configuration-files, with the full path. Could you retry?

Regards,

Joost.