@Juha
When this gets integrated with the current package management code, dependencies will be handled by it (I think).
Yes.
You have implemented your own code for TZipper, TUnZipper etc. You should use the TZipper provided by FCL :
http://wiki.freepascal.org/paszlib#TZipper
Not quite! I used the same unit provided by FCL, but with a few modifications, this is also true for httpclient. Neither one provides a timeout function. For example when you try to connect to an offline server with httpclient, sometimes it waits 25 - 30 sec before returns an error. The same is true for zip/unzip from Zipper.pas, once started you have to wait until the entire zip process is over, no possibility to abort the process. More over httpclient doesn't even show a download progress. I had to create a thread timer and a modified streamer class to be able to provide a feedback(see opkman_downloader.pas unit). The possibility to show a progress with TZipper is also limited, (although is there) so I had to enhance the function.
I know this is code duplication. Ideally I should create a patch for those units, but when will be accepted(if ever)? Since zipper.pas and httpclient.pas functionality is more then enough in 99% of the cases, fpc core members would not accept a patch just to satisfy the online package manger needs(at least this is what I think).
BTW, your zipper code has a memory leak somewhere.
I always develop with "Debug IDE" profile to avoid leaks. I fixed many leaks in my package, obviously I missed something. Thanks.
You have also added a copy of the VirtualTreeview code into your package. Can't it use the VirtualTreeview package as a dependency?
Initially I wanted to avoid third party components. Unfortunately TTreeView is so limited in so many ways I decided to switch to VST. The only version which works well in every major widgetset is VST4.8.7R2. The newer one doesn't even compile under osx for example. What if somebody already has a newer version installed? It will lead to conflicts, multiple resource errors, etc. It's not a good practice to force the developers to use a specific version of VST, just to be able to install opkman. So I added VST internally to the package manager, even replaced the resource names with a resource editor to avoid conflicts. This way it can happily coexists with any version of VirtualStringTree. Code duplication again? Perhaps but the benefits outweigh the drawbacks.
@shobits1
It needs a filter for the packages with available new updates.
Ok. I can add this later.
@lainz, @Leledumbo
I will add the source to github soon.