Online Package Manager

[wp]

Clever!

[balazsszekely]

I am currently converting some more components of the jvcllaz project in ccr (JVCL components). For easier conversion I'll stick to the package structure of the JVCL Delphi version.

This is great! I always wondered why such a good component is not converted to Lazarus? Which version exactly are you converting? The newer one are more focused on XE2+ support.

[minesadorada]

1. I implemented @minesadorada's request(screenshot)
2. The update is only visible if the package is installed. I hide it because a direct update, without install, although possible is not recommended. The update may fail if dependencies are not found.
3. Added Help button which points to OPM wikipage
4. Fixed a few bugs.

Looks good.

We should add the LastNotifyDate(TDateTime) to the JSON + remove name.zip because it's not needed, just the name:

{
  "UpdatePackageData" : {
    "DownloadURL" : "https://sourceforge.net/projects/lazautoupdate/files/otherpackages/cryptini.zip",
    "ForceNotify" : false,
   "LastNotifyDate" : 4.2689000000000000E+004, <--add this
    "Name" : "cryptini"                         <--cryptini instead of cryptini.zip
  },
  "UpdatePackageFiles" : [
    {
      "Name" : "cryptini.lpk",
      "Version" : "0.1.1.0"
    }
  ]

I'd like to keep the '.zip' in if possible.  In jsoneditor it acts as a redundancy check on the URL - which is an easy field to get wrong.  If you think it's important, then I suppose the GUI could insist on the .zip but only store the name part in the json, but this would make it inconsistent for manual editing.

With the LastNotifyDate entry, I have a couple of issues:
1. What if I upload a json with LastNotifyDate set for 10 years from now? As I understand, OPM will keep polling the json but be unable to change the 'bad' entry.
2. With the date in TDateTime format (which it has to be), it becomes difficult and error-prone to manually edit the json file (which some users will do)

I assume what is wanted is really an 'expire-by' date (days).  If so, then it's probably better to store the current date (internally) and let the user specify a number of days for the NotifyUpdate to apply.  (The GUI can calculate and display the ExpiryDate for the user to confirm) This can be stored as a simple integer field.  If OPM can parse the filedate of the json, then it doesn't even need the problematical LastNotifyDate TDateTime field - only the ExpiryDays one.

[balazsszekely]

I'd like to keep the '.zip' in if possible.  In jsoneditor it acts as a redundancy check on the URL - which is an easy field to get wrong.  If you think it's important, then I suppose the GUI could insist on the .zip but only store the name part in the json, but this would make it inconsistent for manual editing.

The *.zip is not used internally by OPM, if it's useful for you then feel free to keep it.

With the LastNotifyDate entry, I have a couple of questions:
1. What if I upload a json with LastNotifyDate set for 10 years from now?
2. With the date in TDateTime format (which it has to be), it becomes difficult and error-prone to manually edit the json file (which some users will do)

I assume what is wanted is really an 'expire-by' date (days).  If so, then it's probably better to store the current date (internally) and let the user specify a number of days for the NotifyUpdate to apply.  This can be stored as a simple integer field.  If OPM can parse the filedate of the json, then it doesn't even need the problematical TDateTime field - only the ExpiryDays one.

First of all the "ForceNotify" feature will be rarely used, secondly we need a system that prevents continuous alert messages even when ForceNotify is set to true.  Consider this:
1. A package maintainer modifies the source, without increasing the version number(it's not unusual)
2. To trigger an alert message on the users computer, he/she sets ForceNotify to true(the other valid alert method is to increase the version number, which do not apply here)
3. OPM alerts the user, the package is downloaded/installed through the update feature
4. Now comes the confusing/annoying part, although the source is updated, the user will receive continuous alert messages since ForceNotify is true. To prevent this, I want to add a TDate/TDateTime field, which represents the date when the last update was released. After the update is done, OPM remembers internally the date, preventing further messages until the date changes again. We can replace the date with an integer, the effect would be the same. You're right about the TDate/TDatetime, it's very difficult to edit manually in the JSON file, however is more suggestive then an integer value, besides why did you developed the jsoneditor? To handle dates in the json  . So what's gonna be: integer or date?

[minesadorada]

OK thanks for the explanation.  I'd made the wrong assumption that the user was setting the TDateTime.
Why can't OPM read the FileDate of the downloaded json and use that?  Am I missing something?

[lainz]

I think better is an integer. What for example I use is an integer with year-month-day, so today will be 20161208, tomorrow 20161209 and is easy to write. In the GUI editor just pick a date and then convert to this is really easy.

The time I don't know if it's neccessary, I think updating once a day is most that all users will do, more times in a day is not a good thing.

Edit: or just a regular int to increase. number of notify: 0, 1, 2, 3, 4, and so on.

[balazsszekely]

@minesadorada

Why can't OPM read the FileDate of the downloaded json and use that?  Am I missing something?

The JSON never "touch" the hard disk, it's loaded directly into a memory stream.

@lainz
Edit: or just a regular int to increase. number of notify: 0, 1, 2, 3, 4, and so on.

I like this better. What about a meaningful name? InternalVersion is ok?

[lainz]

InternalVersion is ok. The most important thing along with the name is the hint you can give to the package mantainer on what it does, and that is done in the wiki or in the json maker minesadorada keeps updating.

[wp]

I am currently converting some more components of the jvcllaz project in ccr (JVCL components). For easier conversion I'll stick to the package structure of the JVCL Delphi version.

This is great! I always wondered why such a good component is not converted to Lazarus? Which version exactly are you converting? The newer one are more focused on XE2+ support.

I am continuing with the version with which the initial porter started. Fortunately I found this in my archive, it is v 3.33, and I can install it in my Delphi 7 to see how things should work.

I was motivated by a bug report by Michał Gawrycki who converted the Validators and the HTcontrols (HT = hypertext) - this is really nice work done by him. I saw that the XPControls did not have a demo, and so I decided to continue with this package. XPControls are almost complete now, but this is more an exercise than an important addition since nobody cares about XP controls any more nowadays.

The currently ported components work in Windows and Linux. The JvNavigationPane still lacks the component editor for adding pages, i.e. you must use runtime code to add pages (like in the demo). 

I changed the folder structure in the ccr folder to facilitate adapting other JVCL components. And I also separated runtime and designtime code into separate packages. So, users of the JVCL components forgive me because this breaks your code - sorry. But it effectively avoids compilation issues due to the same compiled units found by several packages.

But conversion is quite a pain because numerous classes and units are involved before you can test a component on the component palette and because the code is heavily loaded with Windows-stuff. After being unsuccessful with the OfficeColorButton today after two days of work I don't know if I'll spend more time on this...

[minesadorada]

InternalVersion is ok. The most important thing along with the name is the hint you can give to the package mantainer on what it does, and that is done in the wiki or in the json maker minesadorada keeps updating.

So what is the consensus?  I can update jsoneditor on Sunday once I know:
1. Which new fields in the json
2. What can the GUI user visually change?
3. Validation rules for (2)
4. Hint text for (2)

[lainz]

Add InternalVersion that holds an arbitrary integer set by the package mantainer. Add a spin edit in the GUI. Is arbitrary, so there's no validation, only it must be an integer. The hint text is 'Increase internal version when you have made changes in the source. It  works only combined with ForceNotify.'

[JuhaManninen]

HtmlViewer master project is ported to FPC/Lazarus.
 https://github.com/BerndGabriel/HtmlViewer
I realized this from a recent bug report:
 http://bugs.freepascal.org/view.php?id=31075
Should it be included in the repository? CCR only has an old version which maybe should be removed.

[balazsszekely]

@wp

The currently ported components work in Windows and Linux.

After OPM is finished, I would like to contribute by porting those components to OSX. 

@minesadorada
See @lainz answer.

The update feature soon will be ready. The last missing, major feature is the voting system. Some of the reply on this thread suggest, that rating packages would be beneficial. What do you think about this?
My thoughts:
  - each package can have from 1 to 5 starts
  - a user can vote only once/package(we need a login system for this, it can be used later to directly update the main repository)
  - a vote can be later edited/modified
  - OPM will display an avarage for each package
Implementing the feaute will take time, since it's a complex issue.

PS: I will remove the SVN/GIT item from the tree, since the package maintainer now can push trunk version through the update feature.
 

[molly]

Hi GetMem,

The voting as i envisioned it had more to do with the functionality of the package.

- does the package install correctly or are there any issues encountered
- does the package work/compile for specific targets or only for some of them
- is the package well maintained or does it take ages for reported bugs to be fixed
- etc.

The idea behind that, was that anyone can offer his/her package but users are able to provide information about the package so that good well written packages/components have perhaps a better chance to get integrated into ccr or similar (simply because they get noticed)

imho there is no use whatsoever to use a ranking system when all we get is response from those that are happy enough the package exist at all and support only one single platform (how well written it might be, and of course with exception of those that are only capable of targeting one platform).

It would also allow for newcomers to take a shot at things and get some positive feedback and packages might be able to get a classification (new, in development, official, etc)

Not a big issue if something like that would be missing but could perhaps help in getting things more automated on its own without too much human required interference when talking about OPM manager. It has nothing to do with the manager itself in that regards so, i was not complaining 

Thank you for the tremendous and excellent job already done.

[minesadorada]

Add InternalVersion that holds an arbitrary integer set by the package mantainer. Add a spin edit in the GUI. Is arbitrary, so there's no validation, only it must be an integer. The hint text is 'Increase internal version when you have made changes in the source. It  works only combined with ForceNotify.'

I found an hour to do this this morning.
jsoneditor to V0.1.19.0 in svn ccr
Windows installer at https://sourceforge.net/projects/lazautoupdate/files/otherpackages/setup_jsoneditor.exe/download
Please check.