This discussion was split off from the bug tracker and is preserved here. I wanted to ensure the helpful bits were retained and the discussion continued, since the bug tracker is normally cleared of comments.
New: Run-Command (Dec 2, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
TL;DR:
Acutal Message:
Also the Platform is more high profile, I use it and come across things that I would like to help with (e.g. custom theme suport, custom color support, …) regularly, while the Installer & Launcher I rarely come across an issue or missing functionality unless I'm developing a PortableApp, though there are a couple of things to do with them that I'm still hoping to find the time to get to.
Also I realise that there isn't a big pile of us, but I personally would submit more patches if there was a specific route for doing so, as posting a full copy of my version of the source gets messy when I want to submit several patches at about the same time, and feel that they should be submitted separately, so that you can take one or another and review it alone without having to figure out which changes are connected to which and selectively ignore some of them.
Re: "John brain no worky." get some rest, I can wait.
I can wait for now and will talk to you about it whenever it comes up again.
~3D1T0R
On the SCM front, VSS predated most modern SCM tools and standards, so it's a very different product. Also, it was 1996-1998, so 16+ years ago. Nothing in the skillset is really transferable since all it did was basically lock files and keep track of who had them checked out so others couldn't edit. Think old school basic GUI SCM. Yes, you could diff and such, but that was about it. It isn't that I don't know Git. I don't know any of them yet.
I know having things up on github and synced to the current release will help a lot. That's one of my top projects going forward. Github seems to be the best way to get more folks interested, which is why I wanted to learn git first. I'm going to learn the command line as well as the basic methods/theories and use Github for Windows as well.
Thanks for the support and suggestions. We'll get there. I think I may take a nap and then post 12.0 hoping some more translations and bugfix confirmations come in.
Sometimes, the impossible can become possible, if you're awesome!
I'm working right now on updating Github For Windows Portable, last being worked on by bungshea, with the goal of having an official client for the SCM we utilize that we can direct people to who want to get involved for the first time.
I'm not familiar with git, but as far as I understand it, git is similar(ish) to mercurial, and I've familiarised myself to that SCM tool over the last couple years.
John, if I'm able to figure git out quickly enough, I'd be happy to show you the process I utilize for keeping apps, including PAL, (and even a local copy of the platform I've been fiddling with off and on - mostly off) in a repository.
If PortableApps.com is going to be using GitHub for more source repositories then an official Portable git client would be nice , though "GitHub for Windows Portable" seems a bit long and makes it sound like it's "GitHub" for "Windows Portable", so maybe we could just call it "GitHub Desktop Portable" as they do call it that in some places?
Also I didn't see a "GitHub" Portable anywhere, and what I found by bungshea was 'Git for Windows Portable' (sans "Hub"), so … are you looking at doing GitHub for Windows Portable, or Git for Windows Portable?
~3D1T0R
I hadn't looked closely at his yet, other than to note it existed, as I prefer starting fresh to avoid potential errors.
I'm working on Github Desktop, Github's official client.
[EDIT] Eww, .Net
However, I've found SmartGit, which uses Java, but otherwise can be installed entirely portably, even allowing to set the settings directory to Data\something
Here's a big list of git "Interfaces, frontends, and tools" which might interest you if you hit more roadblocks on the gitPortable front.
~3D1T0R
Do you still have your development progress from GitHub Desktop because I'd like to use it anyway.
I grab the latest PortableGit release from the msysGit people (https://github.com/msysgit/msysgit/releases) and unzip it into X:\Git. Then in the configuration script for Command Prompt Portable I include the following lines:
The command line, git-gui, and gitk have proven sufficient for my needs.
I can't speak on the installer's repo, as I haven't had anything to do with it, however, I can speak to PAL's: The last commit was one I made 6 months ago, and I personally haven't had much time since to work on PAL, and as far as I can tell, neither Aluisio or Chris have either.
the way sourceforge is set up isn't terribly ideal for adding new committers, i'm looking forward to how github will change that.
As for PAL having lots of changes versus the released version - We could likely push out an update to PAL, but I'm not sure if there's any specific roadmap we're aiming for before doing so or not.
Next topic - John, so as to not lose this thread, would it be possible to split it off?
I think Chris Morgan has made a few posts in the forums stating individual things that he wanted to have ready before the next release, but I'm not sure where they are (or what they were).
~3D1T0R
Any news?
Since the topic of you being the only PA.c Platform Developer has been brought up again (here) I thought I'd ask:
How are things going on the 'source control improvement' front?
I would like to contribute, but as I've said before, your nonacceptance of .diff patches has made it difficult for me.
I would like to be able submit patches (or pull requests) that you can apply (or clone) to a local repo for evaluation, then accept or reject it/them (on a case by case basis).
If there's anything I can do to help you on this front, let me know.
[Edit: Just bumping this again, any progress? Any way I can help?]
~3D1T0R
Hello again John,
I was wondering what kind of source control you've been using, both lately and in the past for the PortableApps.com Platform.
In other words, I'm asking "How have you been keeping track of the Platform's source on your machine all these years?" (copies of the source directories? zip files? an scm? N/A?)
I ask this because I'd really like to revisit the idea of creating a git repository with all the history I can rebuild, and the Platform's source downloads on SF.net (especially the old ones) are a bit of a mess, and I'm wondering if you have some local system that could help me.
The idea is that I'd make a git repository with all the historical commits I can (with as accurate historical dates as possible), tag all releases, post it on GitHub, and transfer ownership of it to PortableApps' GitHub organization.
Please let me know what you think, and if you can help at all.
[Edit: Any chance I could get a response from John about this? (Please?)]
~3D1T0R
John will correct me if I'm wrong, but currently the source is released publicly via 7z files by him, so possibly that's how he's keeping track of it on his system as well.
We're in the process of adding our internal tools to github (including, i believe, the platform), along with a master repo including only the launcher files for all apps (I'm working on this second one around some other projects).
With that said, I've added you as a member of the PA organization on github, as you've certainly proven yourself over the years here, and we appreciate any help you can provide in adding historical and go-forward source control for the platform.
Hope that helps!
I'm glad to be able to help.
Anyway, I'll do my best to make sense of the old copies of the Platform/Menu sources, but if John can help me with that, I'd really appreciate it.
~3D1T0R
This is a great move.
It will be great if yo moved form SourceForge to GitHub.
I hope it will bring new people to assist your wonderful work.
I believe the idea is to move the source repositories to Git, hosting them on GitHub, and keep uploading the binaries to SourceForge, as there are still some issues John has mentioned before with GitHub's binary release system. To my knowledge, the source archives relating to each release will continue to be released on SourceForge as well, though for people who would rather download them from GitHub, as long as we tag each release, GitHub will offer a zip download of them too.
~3D1T0R
For clarification: We will not be hosting individual repositories on Github for each application we have here.
We will have repositories for each of our internal tools, along with the occasional related application (such as Toucan).
For PAL-based applications, which we are slowly moving more and more custom-launcher based applications to, the launcher file (and custom code if applicable) will be kept in a master repository as well.
Full source archives will continue to made available via our SourceForge project, as will binary releases.
As this is the case, we will not be providing any releases via Github's release system, in source form or otherwise, at this time.
I'd forgotten about this old topic and it's been a long time since I updated it. I've learned git since 2014 and been using my own local repositories for some stuff. I'm currently working on constructing older repositories for the installer and platform with properly dated commits for every release going back to the beginning, including pre-1.0 installer stuff, and ensuring these will properly transfer in a digestible form to github. Partially so we have an accurate record over time, partially so nothing gets lost or buried in harder-to-access 7z files of text sources. I'll be moving these to github shortly so we have the full history of all releases in an easily accessible public form and then we'll be continuing work from that point on on github complete with all the usual github goodies.
Sometimes, the impossible can become possible, if you're awesome!
I tried to put together a git repository with historical accuracy for the Platform, and my main issues were that it's hard to tell what's what with a few of the older releases' source uploads on SourceForge, and that there seem to be a few (early) source releases missing.
As far as editing past commits, I have that pretty well in hand, so... I'm offering to help.
Also... slightly separate topic, but while gathering files for the purpose of creating said repository I came across these:
Edit:
I'd also like to know what author/committer information should be used for historical commits based on past source releases. It would be nice to use the same thing between repositories.
For instance:
What should the author name be? "PortableApps", "PortableApps.com" or "John T. Haller", or something else?
What email address should be associated with these commits? The GitHub "PortableApps" account's @users.noreply.github.com address, one of @PA.c addresses? (developers_developers@..., JohnHaller@..., etc?) or an address @JohnHaller.com?
Then, the author date should be the the date/time the file was published, but what about the committer data? should the committer be the same as the author, or should it be the person who prepared the repository? and finally should the committer date be set to the same as the author date or should it be the date/time when the repository was prepared?
~3D1T0R
The author name & email will be up to John solely., so I can't speak to those questions.
The committer data should, based on how we've handled PAL, likely be identical to the author data, unless there is some reason this isn't feasible.
Finally, the commit date, in my opinion, should be the same as the author date.
[EDIT] Note that I've created an empty repo on Github for the platform.
Hey Gord, I've been keeping an eye on the GitHub repos, and I'm wondering... seeing as the recently created ApplicationINI repository contains more than just
.inifiles, and in actuality contains just about everything needed to build each app (minus the app, PAF stuff, etc.) I'm curious if it wouldn't be a better idea to call it "Applications" (or "Apps") rather than "ApplicationINI"?I'm also thinking it might be a good idea to add the
DefaultDatafolder for those that have one as it would be necessary in order to correctly build the app, and perhaps theappicon*files too.With the addition of this repo, I'm considering adding the ability to use each app's files in this repo's folder structure as a starting point to build apps in the PAF format to the PA.c DevToolkit, as such we'd need to have everything necessary to build each app in there.
@JohnTHaller and @GordCaswell: What are your thoughts?
~3D1T0R
Applications could imply that full apps are contained there. ApplicationINI may not be the best option. AppFrameworks, AppConfigs, or something similar is a possibility.
Sometimes, the impossible can become possible, if you're awesome!
"AppConfigs" or something similar (AppCFGs?) seems better to me.
Any thoughts regarding adding DefaultData/appicons/etc. so that this can be used for a more fully automated method of building PA.c Apps?
~3D1T0R
It has been renamed to "AppConfigs".
Can I get write access to the AppConfigs repository?
I tried to push to it to move ZoomIt out of ZintBarcodeStudio, and it wouldn't let me.
~3D1T0R
I've added access to the repo.