Hi,

Here's a first version of a graphical front end for fppkg. Currently it supports all basic commands. It's my plan to extend this front end in the future and at some time support lazarus packages as well.

Please review and commit if approved.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fppkg.zip
Type: application/zip
Size: 49026 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110510/c32bfb70/attachment-0001.zip> -------------- next part --------------

Regards, Darius

Darius Blaszyk wrote

Here's a first version of a graphical front end for fppkg.

Unfortunately you are not the first. ;-) I have already seen a graphical front-end for fppkg (I think in Lazarus CCR). Either way, I guess having more choices are always good. :)

Regards,
- Graeme -

Graeme Geldenhuys wrote

I have already seen a graphical front-end for fppkg (I think in Lazarus CCR).

Found it on Lazarus CCR download section:
http://sourceforge.net/projects/lazarus-ccr/files/fppkg%20gui/

Announcement from original author:

http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-March/041989.html

Darius, I haven't looked at your version yet, but maybe some project collaboration could be done (unless ideas/goals are very different of course)? The original front-end could be used as stand-alone and as a Lazarus IDE plugin - which is kinda nice for differing use cases.

Anyway, I just thought I would give you the information from a similar project.

Regards,
- Graeme -

Darius Blaszyk wrote

it supports all basic commands. It's my plan to extend this front end in the future and at some time support lazarus packages as well.

I guess you developed it against Lazarus (trunk). Anyway, I just thought I would let you know it compiles against Lazarus 0.9.30 (stable) too, with just a few minor changes.

To compile with Lazarus 0.9.30
==============================
1) Remove LCLBase package dependency. The LCL package is enough.

2) Comment line 16 in 'project1.lpr' file.
     //  RequireDerivedFormResource := True;

My comments/feedback:
---------------------
1) Unlike the original fppkg front-end, you hard-coded all text strings. Those should be changed to resource strings so they can allow for translation.

2) The idea of the "settings" tab is good, but I think its hard to read of first sight. Maybe a dedicated Config Dialog would serve the end-user better - rather than simply dumping all the settings to a read-only textbox. With a config dialog, the end-user could then edit the settings too.

3) I really liked the idea from the original front-end project. Having the ability to run it as stand-alone (normally my preferred choice), but also as a Lazarus IDE add-on (somebody will probably like this option).

4) Maybe rename the project and actually give it a name rather than 'project1'. ;-)

5) The "Fix broken" button seems to always be enabled, even at start-up, when no package has been selected yet. What is weird too is that the button text is painted as an enabled button, but the image is painted as a disabled button.

Regards,
- Graeme -

Graeme Geldenhuys wrote

3) I really liked the idea from the original front-end project. Having the ability to run it as stand-alone (normally my preferred choice), but also as a Lazarus IDE add-on (somebody will probably like this option).

Ignore that, I only now saw the lazfppkg.lpk file.

Regards,
- Graeme -

Thanks, I have seen the mail, but i couldn't find it on the CCR repositories. Just had a quick look and from a functionality point of view it does even less than the code I sent yesterday. I will contact the original author but I doubt he will be interested as the release is already more than 2 years old.
The tool I sent out yesterday can also be built as stand alone btw, actually this is the way I do testing.

Regards, Darius

Hi Graeme,

Thanks for the feedback.

1) Remove LCLBase package dependency. The LCL package is enough.

I will look at dependencies later on indeed. For now I have slung a couple of units together from other projects and didn't pay too much attention to the "details". Probably there are other units in as well that can be taken out.

For sure this is planned.

I have chosen for a dump for now. Later this will be replaced by a parser. I will probably link to the fppkg units to use that parser instead. Reading the commandline output seems a bit too hard to do. This will also make it possible to modify configuration?!? The results will be presented in a config stringgrid (like in the object inspector).

It's there ;)

4) Maybe rename the project and actually give it a name rather than 'project1'. ;-)

Have a better name for it? :)

The image is not very good. It's just a mockup, will replace with a better one when I find it. The fixbuild functionality is now allways enabled because it's not depending on a package. The command will try to fix the build for any package it finds broken. Perhaps I should only enable it when a broken package was detected.

Regards, Darius

Thanks, I have seen the mail, but i couldn't find it on the CCR repositories.

That confused me too, but I was pretty sure I saw it on CCR. In the end I found the code is not hosted in the repository, just in the File Downloads section.

Just had a quick look and from a functionality point of view it does even less than the code I sent yesterday.

To be fair, back in 2009 fppkg itself didn't do much either. :)

On the flip side, even though it was developed back in 2009, it compiled and ran without problems on my system today using FPC 2.4.3 and Lazarus 0.9.30.

the original author but I doubt he will be interested as the release is already more than 2 years old.

I just thought as a courtesy I would let you know about an existing project that does similar to yours. What you do with that knowledge is your decision. I know how frustrated I get when I just finished developing something, then find an open-source project that does exactly the same thing. :)

Regards,
- Graeme -

dhkblaszyk at zee***** wrote

I have chosen for a dump for now. Later this will be replaced by a parser. I will probably link to the fppkg units to use that parser

No problems. The dump was at least informative to see where packages will be installed and what compiler will be used etc.

> 4) Maybe rename the project and actually give it a name rather than > 'project1'. ;-) Have a better name for it? :)

Nope, but 'project1' is a bit generic. :)

The image is not very good. It's just a mockup, will replace with a better one when I find it.

The image is fine, its contrast is just a bit low - thus it looks like a disabled image.

Perhaps I should only enable it when a broken package was detected.

That might be a good idea.

Regards,
- Graeme -

Darius Blaszyk kirjoitti tiistai, 10. toukokuuta 2011 02:24:39:

Please review and commit if approved.

Commit where?

I noticed you wrote also to forum thread suggesting a similar installer: http://www.lazarus.freepascal.org/index.php/topic,12827

This idea seems to boil in "collective subconsciousness" or where-ever it boils. Anyway many people are getting the same idea. This must be synchronized or else effort and energy get wasted.

There is already one repo created for it (see the forum thread). Should it be used? Lazarus trunk may not be the best place because of limited access for potential committers.

Juha

Darius Blaszyk wrote

Here's a first version of a graphical front end for fppkg. Currently it supports all basic commands. It's my plan to extend this front end in the future and at some time support lazarus packages as well.

I didn't looked at it yet, but how does it works? Does it call fppkg on the command-line?

I'm happy that you are doing all this work, that way I don't have to do it. ;)

But my plan was to do one of the following:

A: Install the fppkg units, so that these can be used to create frontends to fppkg
B: Create a fppkg-lib, so that that one can be used to build fppkg-frontends.

Question is what is the best option?

Joost.

Since everything is based on classes, I would think that A is the best option. We can create a lazarus package for it, which contains all units as virtual units.

Michael.

Darius Blaszyk kirjoitti tiistai, 10. toukokuuta 2011 02:24:39: > Please review and commit if approved. Commit where?

./trunk/components/lazfppkg/

I noticed you wrote also to forum thread suggesting a similar installer: http://www.lazarus.freepascal.org/index.php/topic,12827

No, not a similar installer, but exactly the same graphical frontend to fppkg. I just put up a link to this mailinglist.

This idea seems to boil in "collective subconsciousness" or where-ever it boils. Anyway many people are getting the same idea. This must be synchronized or else effort and energy get wasted.

Hence the link I put up on the forum and the original email to the lazarus list.

There is already one repo created for it (see the forum thread). Should it be

Yes there's a repository, but it should stay with Lazarus imho. Besides the idea of the person that created the repository was planning to create his own package manager.

used? Lazarus trunk may not be the best place because of limited access for potential committers.

Lack of resources is no proper reason to start a new repository. If you have doubts then please make functional remarks. I have supplied patches for several years now with success and I can also commit to the tree myself. However I find it polite to ask on the list first before adding new components.

Regards, Darius

I would say A as well. However I have no idea what you mean with virtual units. What are they? Also if I'm not mistaking fppkg lives in utils. Should this be moved to packages then?

Regards, Darius

That's exactly the idea. When those units are moved to packages, they are available (virtual) to everyone. Lazarus and non-Lazarus. (So making them a Lazarus package is not the right way, imho)

Problems of this option can be that the fppkg version installed on a system is different then the version which is used when building the application. The library solves that problem.

Joost.

kirjoitti tiistai, 10. toukokuuta 2011 12:09:56:

Yes, my wording was inaccurate. I meant that people on the forum thread suggested a similar installer. That's why I suggested uniting the efforts.

The problem is that people don't know about the existing development, or similar ideas from other people. That's partly why the person (Glenn) wanted to create his own package manager.
I was just trying to figure out what is the most flexible way to commit code of potential devels. They can't get access to Lazarus trunk at once, thus another repo would be a good idea.

Juha

> 4) Maybe rename the project and actually give it a name rather than > 'project1'. ;-) Have a better name for it? :)

how about 'myproject' or '%date%%time%project' where %date% is YYYYMMDD format and %time% is HHMM or possibly HHMMSS format? this would allow one to view the projects in proper date ordering based on the name for those times that it is needed... ie: making small projects to test certain things or to facilitate branching...

one might also fix up the name of the project after the initial "program foobar;" line is written so the project has the same name as the program?

i'm sure that other naming schemes might arise...

I have not tested the package, but there are a few minor formatting issues:

Please use separate directories for lpk and lpi.

The comment in lazfpc_pkg.pas is wrong. It was not automatically created by Lazarus.

Please add comment headers with at least a hint about license and what the unit is about.

Fill in the package options description, author, license, version.

I guess you don't need the option to "add package unit to uses section".

Please enable i18n and use resourcestrings.

Where is the help?

Why is the short cut named "Show fppkg form" and the menu item "Show fppkg manager"?

Mattias

Thanks for the feedback. I have fixed all the issues you mentioned in a new patch. For ease and because the patch is becoming rather large I have put it up on the bug-tracker: http://bugs.freepascal.org/view.php?id=19335 so everyone can test it by themselves. I also do expect a couple of patches to fppkg and this way I can add relationships between these patches as well.

Couple of known issues:
- mem leaks -> will have to sort the fppkg classes out, I'm finding it hard to follow all the code in fppkg
- read all packages (remote and local): same as above
- I have added a local copy of ffpkg to the patch, this will go once fppkg moves to packages in FPC
- I disabled fppkg commands, was through command line in future will be direct from code
- error when installing the lpk. "Error while compiling resources"

Darius

Joost, will you move fppkg to ./packages? Do I need to create a report for it?

Darius

Just the units need to be moved imho, the actual program not really ?

Michael.

You're right on that. On a side note, I would like to use some of the features that fppkg implements as well (like setting up the repositories). Is it OK to move these functions to a separate class or unit? This way both fppkg as the GUI can use the same functions and do not need to implement them separately.

Darius

Sure...

Michael.

Please add comment headers with at least a hint about license and what the unit is about.

What's the purpose of a license statement, in a unit?

Of course every unit should include a purpose notice, but since source code can be distributed under several licenses, I see no need for a (possibly inappropriate) license note in every unit. All licensing is up to the author or project (team), so that this (author or project name) might be another recommended note in every unit - unless the correspondence can be determined from the directory structure.

Fill in the package options description, author, license, version.

That's the place where license information can reside. Then eventual later changes or extensions have to be reflected in only one place, not in all related units.

The FSF recommendations IMO apply to C/C++ or other languages, that have no notion of projects or packages.

DoDi

The license hint can be as short as:
For license see the file <name>.

Mattias

Please do the move as soon as possible. Just identify the units, and I'll start working on moving them to packages/

This way, the move can be done for the 2.6 branching which would help merging back fppkg related stuff tremendously.

I'll see if I can move them tonight.

Michael.

(no extreme rush, branching is in the magnitude of a couple of weeks away, not days. And it still has to be debated on core)

I finally finished the Lazarus version of fppkg. Please review and test. In the zip file you will find a modified version of fppkg, I have created a separate patch for these changes (19348) . Once committed I will cleanup this patch again and it could go for commit if approved of course.

Regards, Darius

Darius Blaszyk wrote

I finally finished the Lazarus version of fppkg. Please review and test. In the zip file you will find a modified version of fppkg, I have created a separate patch for these changes (19348) . Once committed I will cleanup this patch again and it could go for commit if approved of course.

Seems like your package depends on lnet. But lnet is not bundled with fpc or Lazarus, it has to be installed separately. (The lnet code in fpc is more an ugly hack, you can not depend on it)

But you're lucky, since lnet is installable through fppkg. Maybe we can add this package itself to the fppkg repository, so it installs lnet automatically.

Downside is that in that case it is not possible to make it work 'out-of-the-box' in lazarus. People always have to configure and install this graphical front-end from the command line.

Or lnet, or an lnet-light with different unit-names has to be added to a default Lazarus-installation.

Joost

We don't need lnet. LNet is a full-blown TCP/IP suite. When all you need for fppg is a leightweight HTTP client, able to fetch a file. This can be easily written in 30 minutes on top of ssockets, and distributed by default.

I looked at nYume/aservia as HTTP server, and decided I can do better than that, so I'm currently working on a simple HTTP server. While I'm at it, I'll write a small HTTP client. It can then be used by default in fppkg, so we can have lnet entirely optional (just as wget or synapse)

Michael.

Is that a matter of days or weeks? Because else we can commit the lnet-light version for now. It's not very easy to work with two people on a project, using numbered zip files in a bug tracker as versioning system...

Joost.

It is a matter of days. Server is already done, I am now testing it. HTTP Client should be even more simple.

I don't know what you're talking about "zip files" ? I commit everything I do in subversion.

Michael.

http://bugs.freepascal.org/view.php?id=19335

Joost

Ah.
You'll have to take that up with Darius.
I'm not involved in that part :-)

As soon as the TFPHTTPClient is working, I'll check it in and notify you it can be used.

Michael.

This is why I offered the patch as a "final" patch. Only a couple of cleanups left and it will be eligible for committing.

Items that need sorting:

- lnet : we will either need to wait for Michaels solution or use the lnet light code. I would vote for the first option personally, but if Lazarus core devels agree we can add the lnet light code.
- add a FPC version check to the code

This means that if all goes well we can commit by the end of next week probably.

Regards, Darius

I forgot to add:

- create a new Laz_ExecuteAction

I have made two changes to make it work within the IDE.

1: laz_pkgcommands have to be added in the uses somewhere, to register the lazarus commands.

2: when the TFppkgForm is created, the global FppkgForm variable as to be used, because this variable is used in LazLog to show the log-messages in the form. And a check in LazLog has to be added to check that FppkgForm is assigned.

Joost

Thanks I added both. I also created a new Laz_ExecuteAction and enabled the lnet light code (you forgat to add a file). I will create a new patch now.

Regards, Darius

Joost van der Sluis wrote

But you're lucky, since lnet is installable through fppkg. Maybe we can add this package itself to the fppkg repository, so it installs lnet automatically.

That sounds like a terrible idea. Automatically installing packages just because of other optional packages (gui frontends) than not everybody will need, want or use.

Joost van der Sluis wrote

lnet-light version for now. It's not very easy to work with two people on a project, using numbered zip files in a bug tracker as versioning system...

I know this might sound old, but git works perfectly for such cases. SourceForge, GitHub, etc all allow public git repositories - big or small. I have done just that with fpprofiler some months back. I wanted to make many changes and the bug tracker and subversion wasn't up to the job. A small github repository was created where I could work with ease. Then later that code was merged back into wherever fpprofiler now lives (some other subversion repository).

It's called a dependency and unfortunately a package manager cannot do without a dependency on some other networking package. However Michael is working on a networking client that will be supported out of the box in FPC. So no external dependency will be needed finally. Unfortunately this means that the package manager will not be supported for earlier compiler versions, unless lnet is enabled again.

Regards, Darius

Darius wrote

It's called a dependency

I know, and a dependency that is not included with FPC - which is why I call it a terrible idea. Michael's idea is a much better one.

working on a networking client that will be supported out of the box in FPC. So no external dependency will be needed finally. Unfortunately this means that the package manager will not be supported for earlier compiler versions, unless lnet is enabled again.

That shouldn't be a big far as I know, the fppkg
repository and latest features of fppkg is only supported with FPC 2.5.1, so the latest released FPC+fppkg is pointless any way.

There are talks of FPC 2.6.0 being released before the end of the year, so then all will be well again. :)