Application: PortableApps.com Development Toolkit
Category: Development
Description: PortableApps.com Development Toolkit is a utility for assisting with PortableApps.com app development.
Download PortableApps.com Development Toolkit 1.0 Alpha 1.2 [8.00MB download / 9.71MB installed]
(MD5: 7fc19ced03b76caabc2eecc1fbbd3429 / SHA1: 333cd6b8563b4aac105a97ff6ab816cbbbf73f4d)
Note: This is a continuation of the project development by Chris Morgan with some help from Aluísio A. S. G.(previously known as kAlug) available from here.
Release Notes:
1.0 Alpha 1.2 (2016-03-18):
- Launcher can now be found under it's new "PortableApps.comLauncherGenerator.exe" name.
- The Browse buttons on the Options page work.
1.0 Alpha 1.1 (2016-03-18):
- UI overhaul (Chris Morgan)
- Bug fixes & other improvements by Chris Morgan & kAlug
- Released to showcase how far the project had come before it got abandoned.
1.0 Alpha 1 (2011-04-07):
- Released by Chris Morgan on his thread.
Source is available at GitHub.com//3D1T0R/PortableApps.com-DevelopmentToolkit.
Sorry about the odd versioning, I'm pretty sure Chris didn't release it as it was because it has some bugs that need to be ironed out before it's really ready for Alpha 2. I'll work on these as Alpha 1.x releases, then when I think it's ready I'll post Alpha 2, and hopefully get to where I can call it Beta soon...ish.
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
This week I'm (along with trying to get the rest of outdated apps updated) going to try to get the PAF spec internal to this app updated to the current standard & pushed to the repo.
I look forward to having your help on this.
~3D1T0R
So I'm trying to update this to verify against the current PortableApps.com Format specifications, and I see that some of the items are stated as being optional, but I was wondering … in App\AppInfo\appinfo.ini, under [Details], are Donate & Language really required, or are they just missing their "(optional)" notes?
~3D1T0R
Language defaults to multilingual if you leave it off.
Donate and homepage are optional
Sometimes, the impossible can become possible, if you're awesome!
Thanks for the info.
~3D1T0R
Technically they're optional for compiling.
Homepage is required for all official releases. As is Language. As is Donate if there is a valid donation link/page for a given app.
I'm adding them all to apps as they get updated since the platform now uses both Homepage and Donate as of 13.0
Sometimes, the impossible can become possible, if you're awesome!
You said pretty much what I was going to say...Optional, BUT...
OK, in that case do you mind if I treat Homepage & Language as required (for the purpose of the ini validator), and Donate as optional?
~3D1T0R
What if you used an IF/ELSE statement?
In other words, if this is an official release (or revision, I think there's that distinction), treat it as required, otherwise treat it as optional?
I'm not really a very knowledgeable python developer (yet), and the way it all works is a bit convoluted, so I'm actually not sure how to do that at the moment.
If I can figure it out, I'd like to make it a warning if they're not present, but I'm still figuring out how a lot of it works.
~3D1T0R
I've started looking into adding appicon.ico validation.
Right now, the app verifies if the file exists, and stops there. It does not verify if the required sizes exist or not.
I've opened an issue for it on github, and will hopefully get somewhere with it.
Cool, that sounds like a very nice feature to have.
~3D1T0R
I think I found a bug on install - appinfo.ini appears to be written on a single line, rather than spaced as it should be.
This appears to have happened with the original app as well, when I do a clean install of it.
Since I haven't previously come across this problem, I wonder if it has anything to do with Win10 or x64, since I didn't have either of those when Alpha 1 came out.
I'm going to do some further testing with my VM's, but can anyone duplicate?
This is probably due to unix/linux style line endings. I see this all the time, sometimes even in official PA.c apps' text files. I'm sorry I didn't think to check for this prior to publishing.
Edit: I set "autocrlf" to true in git's settings, so my text files in future should have Windows style line endings. If you want to do so too, run
git config --global core.autocrlf true. (If you're using Git GUI in Git Portable, you can run this from "Repository" > "Git Bash" menu entry.)Note: this doesn't change files already in your working copy, so you'll want to commit any changes you've made, delete everything that has the wrong line-endings (or everything in your working copy), then 'revert' the files back to what you just committed so that they're written by git back to what they were. … If you weren't really ready to commit all the changes you just did, then (after you have everything reverted to your temporary commit) you can use one of Git GUI's "Repository" > "Visualize … History" menu entries to right-click on your previous commit & "Reset … branch to here" choosing "mixed" which will set you back to that commit, but leave the files in your working copy as they are.
~3D1T0R
Awesome, thanks for looking into it. The only reason I noticed was because I had installed the new app beside the old one, and the new one wasn't showing up for me in the platform, even after refreshing icons. It still launched manually.
What surprises me is that Alpha 1 exhibited the same problem, however I didn't notice it until now.
That shouldn't happen. The Platform should handle ini files with *nix & mac line endings just fine (it always has for me).
~3D1T0R
It all seems to work great but if keeps giving an error telling me this:
ERROR: [Details]:Name [Details]:AppID or [Version]:PackageVersion not found in appinfo.ini files.
Even though when I check the file these parts are accounted for. Am I missing something?
Which app are you testing?
I just ran a quick test against AkelPad Portable, and the only errors that popped up are PAF Specification ones - i.e. - this app isn't up to date with the current specs yet.
I spoke with Cheshire_Cheval yesterday, and this error was coming from the PA.c Launcher, not the PA.c Development Toolkit.
Also, I believe it was due to a corrupted/damaged installation of the Launcher Generator, and have asked Cheshire_Cheval to reinstall the PA.c Launcher. Hopefully that'll fix it, but we'll see. (Please let us know Cheshire_Cheval.)
~3D1T0R
Hopefully it was a corrupt install, rather than something else we need to fix within PAL...there's enough we need to fix in it.
BTW, are you free to chat on IRC?
Sorry, not only am I a bit busy at the moment, I actually don't use IRC (I know how to, I just don't have an account, and don't really want my static IP address showing up in the logs). I need to do something about that at some point, but unfortunately it's going to have to wait a bit as I have other, more pressing matters to attend to for now.
Sorry.
~3D1T0R
No worries, I was just going to chat about Dev environments. Another time
I know it adds another external source to things, but what about setting up a Slack team for PortableApps (even just as a development channel)? It is IRC-like and easy to use. Just for a free account you can't rely on how long the history will stick around (my work uses it heavily, we have around a month and a half of history).
I am planning to get on IRC, I just don't want it all tied to my physical location, so I just need to take the time to sign up for an account and set up an account with a good BNC.
Actually, I've been intending to do so for quite a while, and have figured out just about exactly what I want to do, now I have to find the time to do it and I can't this week (other, more pressing matters), but I may be able to in the near future after that.
In fact, I was intending to ask if I could be a Release Team member, but as I wasn't set up for IRC yet, I held back. Once I get myself set up properly, I intend to set up Quassel IRC so I can be available as much as possible.
~3D1T0R
Hello again, I'm working on adding validation for the [Associations] section of appinfo.ini (currently it says it's an invalid section) and I'm not entirely certain what the validator should check for.
So far, I have it (in my local copy) accepting [Associations] as an optional section, enumerating what filetypes are in [Associations]:FileTypes (if present) and what protocols are in [Associations]:Protocols (if present), and allowing for all the optional keys within [Associations] currently in PAF 3.0.
The following is what validation I have working in my local copy [and some questions in square brackets.]:
".:/\<>?*[is there anything else I should check for?]%1is not in the value [is this right? is %1 required? or can other %something's be used? (same goes for other somethingCommandLine values)](where extension is one of the filetype extensions found in [Associations]:FileTypes)
%1is not in the value".:/\<>?*[any of these I should not check for? anything else I should check for?]%1is not in the value(where protocol is one of the protocols found in [Associations]:Protocols)
%1is not in the value%1is not in the valueWhat am I missing? Is anything wrong? Do I have anything on there that perhaps I shouldn't? Should I change any Warnings to Errors, or vice versa?
I'm not sure what else to check for, but I don't feel it's quite ready for me to push it to the public repo yet.
Edit: Updated to reflect changes I've made to my local copy since I first posted this question.
[Edit: Bump… Hello? … Anyone?]
~3D1T0R
This looks good to me. Commandlines I believe use %1 for filenames, nothing else.
At a glance, I think the errors are all correct.
Some of the information I found when trying to figure out what kind of requirements to put on [Associations]:ShellCommandLine, indicated that %1 might contain a 'short name' (not sure if this is 8.3 notation, or something else) even when the receiving exe would accept a 'long name', and that %L would contain the 'long name' unless the exe being launched was a 16-bit exe, in which case it too would switch to the 'short name' (because 16-bit exe's can't handle the 'long name').
I'm not sure if that information applies to any of this or not though.
~3D1T0R
See this superuser answer, I think ti contains some possible answers: http://superuser.com/questions/136838/which-special-variables-are-availa...
Yes, I saw that while looking up info, but I'm not sure how/if any (or how much) of it applies to the PAF's [Associations]:…CommandLine values. (especially as the Platform's File Association feature isn't yet active for me to experiment with)
~3D1T0R