Application: PortableApps.com Development Toolkit
Category: Development
Description: PortableApps.com Development Toolkit is a utility for assisting with portable app development. Currently it'll be most useful for its PAF validation. More features later.
Screenshots:
(These aren't quite of Alpha 1, but they're approximately the current state.)
- Main window (running in Ubuntu)
- PAF validation (running in Ubuntu)
- AppInfo.ini editor (running in Ubuntu)
- More screenshots coming next week, when I next get a chunk of spare time for this
Download the PortableApps.com Development Toolkit 1.0 Alpha 1 [7.6MB download / 8.6MB installed]
(MD5: 1dfc3c0be1c5d425b33736c228ef6f6a)
Source code (get it, Python and either PyQt4 or PySide and you can run it on Linux. Also requires Wine for some functionality.)
Release notes:
- 1.0 Alpha 1 (2011-04-07):
- Features: package creation, appinfo.ini editor, partial PAF validation (files/directories, appinfo.ini), running Installer
- Using PyQt4; compatible with PySide, but PySide binaries are bigger at the moment (TODO: shrink PySide build with Hatchet and use PySide instead of PyQt4)
- Will work perfectly running from source code in Linux with Wine installed, with the slight exception that filename checks are currently case sensitive when run from Linux. If you run the Windows version from Wine this won't happen. But it won't feel native for Linux.
- Before today, I've done nothing on this for more than three months. Tonight I decided I felt like actually releasing Alpha 1, so I did.
- Still has various rough edges, e.g. window sizing is absolute, appinfo edit save button doesn't indicate that it saved it.
- Still has lots of missing functionality.
Oh, and for reference,
PortableApps.com Format validation passed with 1 warning.
Warnings
- File App/AppInfo/Launcher/splash.jpg is missing
[EDIT] This app is now outdated & has been superseded by a continuation of the work here. Please see that thread for further details on this app. - mod GC
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Hey Chris, thanks for your work on this, and especially for releasing it, it looks really good.
I've had a quick play with it and it has pointed out a couple of things I've been doing wrong in the packages I've not yet gotten around to upping for Dev test. I think this will go a long way to help a lot of us with little to moderate Pafing experience.
As above, something it pointed me to something but I am not sure who is correct.
I am working on Qucs portable it complains that in \Other\Soure I don't have a 'AppNamePortable.ini'
There I have a 'QucsPortable.ini'
What is the correct name for this file?
Thanks for answering
I was just about to comment on this. The few officially released apps I looked at have an "xyzPortable.ini" where xyz is the App name in Other/Source, but the validator checks for the actual filename "AppNamePortable.ini".
Everytime I stumbled upon that, John and Chris stated that it is to be left as AppNamePortable.ini, as it is just a template that requires user action. In older apps it was xyz.Portable.ini, but that should have changed with newer releases. (Just checked ZSoftUninstaller and it has AppNamePortable.ini)
Well a few recent apps I've seen still are doing it wrong then:
Explorer++
Hex-a-Hop
Pathological
Scorched 3D
And Opera, TinyTask & FrHed don't even have a .ini in that directory.
Refer to template-readme.txt and Other\Source\Readme.txt from the Application Template; it should remain as AppNamePortable.ini in the current release (perhaps a mistake - even if doing it this way, it would have made more sense to give it an obviously different name).
Before 1.0 of this I'll be having this take control of Other\Source and update it so that it reflects genuine package information (app name, AppID, etc.). For PAL 2.1 (which I plan to release within a couple of weeks, now I've finally got back to doing this) I plan to update the app template to go back to information where it may be renamed (perhaps saying in Readme.txt that it may be called AppNamePortable.ini or AppNamePortable.ini).
In view of this, I think I'll modify it to consider appid.ini valid as well.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Does not function. Pointed it at a private test. Tried to validate. Did nothing. Crashed on close.
Error report should go in Data\ IMO
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
Seems that it's not catching parsing errors.
I had problems with a UTF-16LE AppInfo.ini.
It only checks for a big endian BOM, however, IIRC Windows uses little endian.I'll provide a patch soon.
It doesn't support Unicode INI files at all.
Previously known as kAlug.
I knew that it wouldn't work with UTF-16LE files, but hadn't got to fixing it. I'll patch it up to support that next week.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I clearly forgot to catch the INI parsing errors and consider them PAF errors. I'll fix that next week.
I'll also take a look at dealing with error reports. That went in App\DevelopmentToolkit\PortableApps.comDevelopmentToolkit.exe.log (py2exe stderr), I presume?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Yep.
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
I think that you should make it optional to use a splash screen, seeing as some apps have a splash screen and some don't. This is useful when having an app that needs it and those that don't need. That way official developers can post there apps with or without the splash. That will only be useful if it is meant for an official app release.
Note: All Development Applications most include the Beta Splash Screen. Only when an apps is deem official that it is determent if it needs a splash screen or not.
I was thinking about that when I released this yesterday and the best two options I have come up with are:
What do people think of these? In particular, John: what do you think?
(kiriko: the validation window gives you the HTML for a good reason; you can copy straight from it and paste in the forums here with all the formatting intact.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I think that is the best step so far in creating portable apps.
Also I did notice that you added the validation window, and that is great for creating "Error logs" for better improving the PA.c Tool kit and for helping in the making of new apps.
Oh by the way, you did a great job with this application. I can't wait what new stuff you have in mind for this project.
Just an idea, you could stick a MessageBox in there to notify the user/developer (same thing with this app ☺) that there is no splash.jpg, and ask if they really don't want a splash, or if they just forgot it (or something to that effect).
And a feature request, perhaps the DevToolkit could check when a package calls itself something other than a DevTest, and warn the user/developer if they have left the default DevTestSplash in place. By no means a problem if you don't want to, but it might be nice, just so it's harder to forget ;).
Also I was having some weirdness when trying to run the Installer via the DevToolkit, it took me longer to figure it out than it rightfully should have, but it seems that when you select an apps folder via the Browse button it uses
/'s instead of\'s as the folder separator, and the PA.c Installer doesn't seem to like it.~3D1T0R
I alos have problems with the installer not finding what it needs. I haven't looked for the source of the problem though.
I'd check the "Package:" box (right next to "Browse...") and change any and all "
/"s to "\"s (without the quotes), that was my problem, it seems that the DevToolkit has no issues with using forwardslashes as the folder separator, but the PA.cInstaller does, and it also seems that using the "Browse..." button to find your Apps folder automatically uses forwardslashes, despite the fact that Windows' default is to use backslashes.It's kind of weird, the issue isn't entirely the fault of either App, but rather a mix of two smaller issues with both :p.
@Chris: Thanks for all your work on the numerous PortableApps.com projects you've either spear-headed, or helped on. This is a great addition to any PortableApps.com Developers' Portable Development Environment.
~3D1T0R
Yes, it was the '/' instead of '\' problem
Concerning the idea and feature request: later on when validation does more (including things like automatic fixing - if you look at the source code you'll see there's basic structure for it in place but no functionality) there will be a better interface for it all and the functionality will include things like this.
Concerning the bug: I found the forward-slash thing late (just before releasing, actually - most of my testing is in Linux as it's more convenient as I don't need to start a VM, and I've only got 2GB of memory on my laptop - only one accessible memory slot, somehow) and fixed it in Create, but forgot to deal with it in Browse. Thanks for that.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Chris,
First of all I'd like to add my thanks to all the others above. I've already used your validation process across some of my posted Development Tests and have identified a number of PA.c Format errors, although nothing critical that prevents any of the apps from working correctly, so updating these shouldn't need to be a hurried process.
I've also been one of those guilty of renaming the AppNamePortable.ini file in the Source Directory as a matter of course, simply because it appeared to be the logical and sensible thing to do! This leads me to my Template question:
For the overarching (structure) AppNamePortable Template: Why is the AppNamePortable.ini Template included in the Source Directory where it will never be used and when for many applications it appears to be totally unnecessary; whilst on the other hand, neither the appinfo.ini template (required in every case), nor the installer.ini template (required in a very high proportion of cases) have been included as standard in the AppInfo Directory where they are used? This seems to be totally illogical to me, or am I missing something?
Also, if anyone is looking at the installer.ini template, I would suggest that all Languages except ENGLISH should initially be set to 'false' rather than 'true', so that Developers are then required to change the relevant ones to 'true'. This would produce a more positive checking and editing process, especially as the majority of apps have a relatively small number of language options available.
Mervyn
The Other directory is now meant to be "we've done it once, now there's no need to ever touch it across any apps" stuff. (And it's there for the end user, not the developer.) Whereas I do not want us using any sort of appinfo.ini or installer.ini or Launcher AppNamePortable.ini templates; it leads to things that we don't want, generally things being left in when they're not wanted. The way this should be done is through providing an easy mechanism for creating and editing them in this utility - which is what I'm doing. appinfo.ini is just the start of it.
In the languages section of installer.ini, my personal recommendation is not to use it at all. Either specify English or Multilingual; don't filter the multilingualism of the installer. It's one more thing to maintain and far too easy to forget, when new languages are added to the base app.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I can't say anythings , it's a excellent app, I hope you can release a full version soon.
(I'm not good at english)!
**:::...CQH...:::**
Awww... I wanted to make an AppInfo.ini editor
Anyway, great job. I was a bit surprised that the sceenshots were actually using the Ambiance theme, but then I kept reading
Why were you surprised? I specified that the screenshots were from running in Ubuntu. And that more screenshots (from Windows, I mean) would come.
Any ideas, opinions, notions, requests, proposals, or other miscellaneous entities of any description?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Hey Chris, I validated an app I was working on that required .NET 4.0. I set it in the Edit Details section, and then when I validated, it gave the following:
-------------------------------------
PortableApps.com Format validation passed with 1 warning.
Warnings
-------------------------------------
I think you forgot to add 4.0 to the validation code.
4.0is missing at line 228EDIT: this should fix it
Previously known as kAlug.
I used the examples in the Format specification - "(example: 1.1, 2.0, 3.0, 3.5)". At the time it was written, .NET 4 hadn't been released, and when I was integrating it into PADT I neglected to include it. Fixed now for the next release.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Hey Chris, been using this a bit tonight and a couple of feature ideas and potential bugs/issues popped into my head:
1) A bit of feedback when clicking "Save" in the Edit Details screen would be handy. I think a popup would be too much, but maybe the Save button being disabled until further changes are made could do it.
2) The Edit Details screen doesn't allow you to change, or doesn't automatically change, the [Control] Start entry.
3) Potential for a help editor. Not that HTML scares me (it better not since I call myself a web designer), but I could see others having more use of it.
Once again, though, thanks for this awesome little tool.
Thanks for your feedback.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
What's the status on this?
Previously known as kAlug.
I need to release Alpha 2. I should do so Thursday or Friday evening, I think. Or possibly late tonight. Then I can get on and do more after that.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Ran this opn latest app did not accept file name eula.txt wanted it to say license.txt in other source directory
Graphics and Pictures was accepted by platform as category but validater demand and & instead of and
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
is there no update to this so far? you should add a launcher editor too, not just an appinfo editor.
I think Chris has been busy with some outside work. And he'd been waiting on an update to the PA.c Format, Installer and Launcher. All of which should be coming out this week.
Sometimes, the impossible can become possible, if you're awesome!
It's Worth the wait. but i wish that it could come out this week so we can test it for bugs.
Is there any news about this one?????
hope chris is alright
News or updates about this program?:shocked:
I really would like it if this was continued, When I edit the app details and click he save button, nothing happens. Could somebody help me with this? Thanks...
Hey All,
I've been playing with this some lately, and I'm wondering if anyone (particularly, John T. Haller, Chris Morgan or kAlug/Aluísio A. S. G.) would have a problem with me posting some new Alpha releases, starting with a build of the latest sources in the repository, then adding my own changes after that.
Basically I'm looking at releasing a different app, but I'd like to have the Dev Toolkit available to me, and feel like fixing it up so it can be more useful for me and others.
Also, I'd like to move the sources to GitHub, and I'll need people to test the releases & post feedback.
Please let me know what you think.
~3D1T0R
Nope, not all, feel free.
I've been working on doing the same thing, switching to use Lazarus instead of Python. I'll upload my work so far to a Github repo and edit this comment once I've done so.
[EDIT] Here's the repo, I've included the original source as an issue. https://github.com/GordCaswell/portableapps.comdevelopmenttoolkit
I was intending to try to pick up from where Chris Morgan and kAlug/Aluísio A. S. G. left off, and then post what I've done with it since, but if you're picking it up and porting it to Pascal, I'm not sure where my version will fit in. (I have made some changes already, but I was intending to make my first post be a build straight from the latest source in the SF repo, so as not to let it look like I did any more of the work than I had.)
Also, a question: Do I presume correctly that you build this with your latest Dev Test of Lazarus Portable? (as found here/here.)
Edit: After some work to make your Lazarus Portable Dev Test work (I hope to post to it's thread soon), I found that your Dev Toolkit doesn't seem to build. Is this accurate, or are you able to build it? If so, how do you do so?
~3D1T0R
I'm actually using a local copy of Lazarus, currently using 1.6, although I'm hoping to update Lazarus Portable soon.
I haven't had a chance to work on either this or Lazarus Portable recently, due to trying to get caught up on outdated apps.
With that said, I've got it building, you can pull from my repo and build. Here's some images if what it looks like so far. Note that essentially nothing works right now, (other than selecting from the top menu) as I'm working on the UI first, followed by everything else, based on what was previously written in Python for the release above. I'm also aware that the menu does not indicate which page is active yet, but that should be an easy fix.
Start screen: http://imgur.com/PlD7xCN
Details page: http://imgur.com/kGA9hWD
Launcher page: http://imgur.com/svvrqJI
Also, I've added you as a collaborator on Github, so feel free to push to the repo as well.
Oh, I see. Lazarus 1.6/FreePascal 3.0.0 is probably the difference, as I fixed everything I could with my local copy of the Dev Test, but it kept complaining about things that I was pretty sure would have been the same in a Local install of Lazarus as well. These are probably things that they've fixed since Lazarus 1.4.4/FreePascal 2.6.4 though.
Thanks, I'll take a look at it when I can.
Edit: OK, so I took a look at it with a local install of Lazarus 1.6, and it works, but I see what you mean about it having a (partial) UI, but still lacking the associated functionality. As such, how do you feel about me publishing my changes to the Python version as more 1.0 Alphas (hopefully leading to a 1.0 release), and we consider the Lazarus rewrite as 2.0 and when it's mature enough, it can replace the Python version?
~3D1T0R
By all means, that sounds like a great plan.
I've already added you as a collaborator on github, do you want to start a separate branch for the python-based update?
I was thinking I'd just upload it under my GitHub account (it has been feeling empty lately).
I'll add you as a collaborator too.
~3D1T0R
That works, too!
OK, so I've posted my source to GitHub.com/3D1T0R/PortableApps.com-DevelopmentToolkit, and added you as a collaborator. Also I'll be posting info about updates on this new thread I created here.
~3D1T0R