Comments on the new 0.91 release can be found here:
https://portableapps.com/node/19414
I'm creating this topic to get comments from developers, moderators and others on the updated PortableApps.com Format 0.90 and PortableApps.com Installer 0.90.0. Any discussion and contributions can take place here.
All existing bugs from the 0.13.3 release of the installer have been fixed in 0.90.0 based on testing.
This 0.90 release represents our next big step to making the format open for all and automating it as much as possible. It's now being promoted on the frontpage alongside our apps and is available for use by free and freeware publishers as well as commercial publishers by contacting us.
Comments and suggestions are always appreciated.
Format:
Installer:
*runs away and rewrites custom code*
Thanks John, Dia Portable 0.97 is on the way
I fixed Uzbek (it was just on the format page description. The sample installer.ini and the PortableApps.com Installer itself are unaffected.)
I'll fix the Help and Readme.txt in the next release.
We're standardizing on AppNamePortable_1.2.3.4_English.paf.exe from now on. It's easier.
The icon of the installer makes sense in relation to Windows installers for software which use more standardized installer icons. It can be confusing when installing Firefox Portable and seeing a Firefox icon in your taskbar... but it's not actually Firefox. The appicon is still visible in the header of the installer while it's installing.
Yeah SHORTNAME became APPID since it's more descriptive of what it really is (it's supposed to be globally unique). Most apps shouldn't need custom code and if they do shouldn't really need to reference the shortname or appid variables.
Sometimes, the impossible can become possible, if you're awesome!
Yeah, but it's more annoying to have a folder including several installers and all have the same icon. Just my 2 cents.
Hmmm, maybe there should be a warning: Because if you don't have a backup, all languages will be lost.
The header image of the installer pages isn't nice. It shows the appicon, but around that there is a grey rectangle. This should be white, IMO.
The installer.ini entries OptionalDirectory1, OptionalDirectory2 ... will be deleted when compiling the package. So you install the program and can't recompile it without creating new installer.ini entries.
The automation of the components page isn't implemented yet? Because it doesn't work.
The installers would still be alphabetical by name if you had dozens in there, so still really easy to find the right one.
The header should be white and it is when I compile on my PC. What OS and other info can you give on your PC? Are you using a custom Windows theme?
The installer.ini entries remain between compiling. It moves the appropriate files into AppNamePortableOptional1, compiles, then moves em back. We're just not manually using the AppNamePortableOptional1 directory anymore.
The automation is implemented but will only be used with the next updater release. It requires a special command switch. When launched from the platform, the welcome page and directory selection screens are switched, but the component page will always be shown.
Sometimes, the impossible can become possible, if you're awesome!
Well, I can't read but pictures are nice
Ohh, my bad. Didn't recognize that the compilation failed with these parameters. So I used my older installer for testing. So I guess that is a real bug. If I create the AppNamePortableOptional1 folder, compilation will work. If I use the installer.ini (OptionalDirectory1, OptionalDirectory2 ...), compilation will fail. Maybe I should read the log next time
Edit: Got it sorted, it was a space in my path. It works now (using the installer.ini).
Ok, compiled 3 packages. The first 2 (Dia + Diashapes) have that grey rectangle. The third (FreeMat) hasn't, but the icon isn't sharp (and it was before). The header of the old installer (0.12.x) looks far better. WinXP Pro SP3.
Be sure the icon has the exact formats specified in the spec. If it has non-standard ones, it won't work right. In Toucan, which I just compiled, it had a 64px 32bit icon in it and wound up with the gray rectangle. Removing it fixed the issue. Also make sure you're using an icon editor that saves the ICOs properly (proper order, etc). Some don't. IcoFX is what I use.
Sometimes, the impossible can become possible, if you're awesome!
I saved the icons with GIMP long time ago, but I'm not a graphic guru. Well, I've released Dia and Diashapes yesterday, both with the gray rectangle. (It may take some time till Patrick uploads them). Maybe the Release Team could look at the icons too.
um like how do you get this thing to work it keeps saying no valid dri or base dir ami missing something here ?
It won't work until you have an app in PortableApps.com Format as detailed here:
https://portableapps.com/development/portableapps.com_format
Then you just pick the app's base directory (the directory that contains the App, Data and Other directories as well as your AppNamePortable.exe launcher and help.html file) and it will create the installer.
Sometimes, the impossible can become possible, if you're awesome!
I haven't been around in a while and randomly swung by today. I'm checking out this app for the first time. Because I don't know how this installer thing works, I hit the "Go to the PortableApps.com Installer Homepage >>" help link in the help.html file and the following page doesn't exist:
https://portableapps.com/Installer
EDIT: Without some basic instructions, this app is pretty worthless. I can't even get the program to get past the prompt for a "base application directory" or whatever. I could go read the portable app format spec page, but this app's name makes it sound like it does all that hard work for you. I guess it doesn't. Did I mention we need an instruction page that tells the user how to use this app and get them going in the right direction. All this time off for me not browsing this website is making me see things as an "outsider" and they're not going to be able to use this thing.
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
I fixed the link.
The installer is *only* for apps in PortableApps.com Format. When you follow the PAF spec, using the installer is just a point and click affair, but you have to be following the spec. The installer will point out basic mistakes for you like missing the appinfo.ini or missing the important keys the installer needs in appinfo.ini, but it's not designed to tell you how to do PAF. You need to learn that yourself by reading the spec.
You're right about needing to make that more clear... I added a couple notes to make that more clear. No additional instructions beyond the PAF spec for the installer are really necessary since the app only has a single dialog with a single entry. If you follow the spec, the installer just works.
UPDATE: Now that I think about it, perhaps I could have it prompt for the needed values to create the appinfo.ini and possibly appicon.ico if needed, but only when launched directly (from the command line, it'll still output the log file). Any thoughts on this?
Sometimes, the impossible can become possible, if you're awesome!
Ah HA! I see...it's a "helper app" to get your portable app all packaged up.
I was extra cranky earlier...sorry 'bout that!
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
I think you have a bug in your installer.
This is the log.
It reports a bug on line 721.
This is line 721.
Shouldn't there be 4 parameters... right?
You probably have CHECKRUNNING set as a blank entry. It needs to be either omitted or filled in.
Sometimes, the impossible can become possible, if you're awesome!
Okay...
But what if you don't want it to check? (In my packages I do... but... the user should still have an option for it not to check if an exe is open)
And over on the PortableApps.com Format...
It says both CloseEXE and CloseNAME are optional.
Also, should the installer be deleting AppNamePortableOptional1?
It's annoying.
It has to check. Because it can't upgrade an app if it's already running. So, if your app is already installed and running... *something* must be running.
CloseEXE and CloseName are optional. If you omit them they use the info for the launcher specified in the appinfo.ini. This is detailed in the PAF spec in the entries.
Yes, AppNamePortableOptional1 is automatically deleted. Oops... I forgot the section in the specs on how we handle that now (hint: it's now automatic). I'll add that in right now.
UPDATE: The PAF Spec is fixed. The options are OptionalDirectory1, etc and OptionalFile1, etc. Both are part of the OptionalComponentsSection. You don't have to manually move any files to AppNamePortableOptional1 from now on. The wizard does it all for you.
Sometimes, the impossible can become possible, if you're awesome!
Wait but...
If I leave CloseEXE blank, it gives me errors.
It says to fill it in... or omit it (as in leave the whole line out). You can't leave it blank.
Sometimes, the impossible can become possible, if you're awesome!
Another solution here is to use
That way it'll have a string there whatever.
Note that I'm not commenting on whether it's right or not, I'm just saying if you do it that way you'll avoid an error if CHECKRUNNING is defined but blank.
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
That's correct. I've updated the spec to mention that.
Sometimes, the impossible can become possible, if you're awesome!
I have one question about the licensing. Does the exception allow for commercial open source apps?
cowsay Moo
cowthink 'Dude, why are you staring at me.'
The simple rule is, if they sell it, they contact us. If they give it away free (and the recipient users can share it with others for free like open source licenses state), the freeware/open source exception applies to them.
Sometimes, the impossible can become possible, if you're awesome!
Hmm, so if there is a freeware application that does not allow it's users to re-distribute (which is quite common) it's not allowed to use the installer creator? Is this because PortableApps wants to redistribute the freeware apps themselves or by alternative roads? (redistribution (ie downloading from other site than the author's site) might make keeping tabs on downloads harder.
What is the preferred developement path for developers?
Will this app or a future version include the latest installer/launcher combinations to facilitate developers only keeping an eye on the specs and this package and not specs, installer and launcher separate? Also does this application includes the platform specs as reference?
Big thanks to offer freeware publishers to join the platform and I hope they can find their way around the PortableApps specs.
Freeware publishers can do that. I was just answering the question about commercial open source (which can mean a lot of different things).
This is for compiling the installer only. It does not have to do with the current launchers.
Sometimes, the impossible can become possible, if you're awesome!
Ok thanks for clearing that up. I'll still have to look into the latest launcher (which uses the ini and doesn't need compiling) to get up-to-date with the platform again
There are a couple unofficial ones, but the official one will be posted soon.
Sometimes, the impossible can become possible, if you're awesome!
Doesn't having the launcher you need to compile yourself for freeware (that is not distributed by PortableApps.com, as noted in the previous exception) go against the exception?
If the publisher makes their own freeware launcher, they're good. If they use our new one, they're good.
Sometimes, the impossible can become possible, if you're awesome!
At the moment, with each app having its own launcher, another app maker can make their own launchers. There would be a question though about it if they based it off an existing launcher as they'd be likely to...
Anyhow, with John and I working on the launcher now, we should soon be able to have a common launcher to all our apps, with a similar exception or something. After the release of Test 2 of mine, I'll be going more methodically through all our launchers and making sure they can all work with my thing, and adding new features as necessary. I think BPBible is going to be the hardest one as it's got pretty deep logic in it, even after my simplifying it significantly (code committed to BPBible SVN yesterday).
When I get my hands on a copy of John's launcher, then we can start amalgamating them properly. His has (or will have) some features which mine doesn't have and which I won't be putting in until we amalgamate, for example service handling.
I reckon that launcher work is a better area for me to be useful in than in the release team at the moment.
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
The red graphic in the new installer looks great = )
PortableApps.com Advocate
I meant to make that comment earlier too. Snazzy red arrow looks nice.
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
Um...
I'm not sure If I'm being paranoid or anything, but...
Is the new installer somehow bigger?
My last Eclipse installer was about 160 megs, the new one is somehow 190.
The size installed is the same though...
wierd..
What about multiple optional components?
Multiple optional components are not supported. Optional components is primarily for additional languages when they add a lot of size to an app.
If there is a specific reason to support multiple optional components, it will be considered, though.
Sometimes, the impossible can become possible, if you're awesome!
Just for those apps that have extra files included but not actually being required by the app.
It wouldn't hurt to have the support included anyway, even if most apps don't use it.
(Just like all other variations of installers.)
(Viz, bug for BPBible Portable :P)
App\installer\PortableApps.comInstaller.nsi:
Should be:
For multi-lingual things it'll be fine ("Multilingual" or "English") but for BPBible, they're "with resources" and "" - both of which won't work.
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
Got it. It'll be included in 0.91 which I'm targeting for tomorrow.
Sometimes, the impossible can become possible, if you're awesome!
I'm having this issue also. The system is XP SP3, and has 32-bit colour on.
Interesting... when running through the Installer, first time, this happened, but then when I ran MakeHeader.exe manually, it made an apparently white-backgrounded image (which pesky Adobe PhotoDeluxe couldn't open, complaining of bad data), but then when I tried the Installer again it made a grey-backgrounded one. Could it possibly be transparency of some sort or something? I tried changing the "3D objects" appearance property in Windows... my grey background disappeared! Somehow though lime green is worse
Edit: the icon, bpbible.ico, was generated by IcoFX. I even tried resaving it with IcoFX - nothing doing.
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
a quick thought, would it be worth putting a quick check in the installer to make sure that the Data folder is empty, if it doesn't already that is. My thinking being it would help to add an extra layer of security.
The Data directory is not included in the installer.
(BTW, BPBible Portable's optional section uses files in Data\resources)
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
am referring to the fact that at the moment I can package up an app that has a load of the developers settings in the Data folder (for example from testing). Then when a user runs the installer it happily overwrites the users settings. Admittedly it is a fairly small risk (I personally have my own build script that deletes the contents of the Data folder before building the installer), I just thought it might be a nice idea to reduce accidents, if some apps do have files in there though it isn't such a good idea
the installer DOESN'T include the Data folder. My Data folder is never empty, but the packages are fine
you are right, I was looking at the wrong copy of installer code, ignore this whole set of comments
Hi John, how about not including the AppnamePortable\AppnamePortable.ini in the installer?
In 0.91 (should be tomorrow) it'll only get *.exe and help.html.
Sometimes, the impossible can become possible, if you're awesome!
I'm currently putting the finishing coding on 0.91 of the spec and installer maker. This will fix the above mentioned bugs like the section name having spaces, excluding INIs in the root directory. It'll also be using new icons in AppInfo in PNG format. appicon_16.png and appicon_32.png. The 16px one will be used in Menu 1.6 PR1 and later which will solve display issues in Vista/Win7 120dpi (icons partially cut off) and Wine (16 color icons). The 32px one will be used to generate the app icon in the installer header and alleviate the need to have your PC in 32-bit color mode in Windows XP/Vista/7 as well as enable proper header creating in Windows 2000 and Wine (and possibly Win 9x though I'm not testing that or listing it as supported).
I'm also working to get download support in this release. You'll be able to download files from web or ftp servers automatically using the local PC's proxy settings (and prompting for a password if needed), check the file's MD5 sum to ensure it's legit, extract it if it's a ZIP/XPI and even some installers (like LZMA compressed ones) and then get all that in your app. Some of the translations will be in English for now, but we'll put out a call and get them translated for the release after. This will open the door to some freeware apps for us.
Sometimes, the impossible can become possible, if you're awesome!
Um...
In the AppInfo.ini
There's a entry called
Plugins=NONE
From which directory is this?
For example, The FirefoxPortable plugins directory is "FirefoxPortable\App\Firefox\plugins"
Would I type in "App\Firefox\plugins" in that entry...
or something else?
[Edit:Nevermind, I figured it out, sorry for troubling you
(from the app directory)]
How to configure a plugin-installer (0.90)?
Any special installer.ini or appinfo.ini settings necessary?
BTW: Old plugins don't have an appinfo.ini yet.
Out of all the languages I'm using in installer.ini, not all of them are showing up in the installer. What am I doing wrong? Hungarian, as an example.
It's based on what your install of Windows has available. It will only show the ones it can display based on your current code page.
Sometimes, the impossible can become possible, if you're awesome!
OK, thanks. I thought I was messing it up
PreserveFile1=App\Appname\abc.def works, file is preserved
PreserveFile2=App\Appname\*.ab fails, all files are removed
Seems it's been like this the whole time as the NSIS Rename function doesn't support wildcards. I'll fix this up in 0.91 which I'm posting today.
Sometimes, the impossible can become possible, if you're awesome!
One comment that you may consider unimportant, but it will probably impact many users. I apologize for jumping in with this so late in the game, but better late than never.
The way the appinfo.ini file is structured, category support within PAM will have to be implemented on a per-folder basis. This is fine for "proper" portableApps, which have a launcher executable in the root folder and nothing else, but it may make things more difficult for users who use non-portableApps.com applications which are designed to be run from a portable drive.
As an example, if a folder has multiple executables in it, each of these would presumably be controlled by the categorizations, icon settings, labels, descriptions etc. This hit me when I started re-working category support in geek.menu to support the official format. It can certainly be worked around, but it may bear an official note in the spec.
So, I guess the consideration is whether the platform needs to build in support for un-official apps in the specification.
Non-PAF apps will be classified as 'Other' by default. Users can reclassify them per-EXE.
BTW - Do you want to keep doing Geek.Menu? Or do you still want to work on the official menu? We're gonna incorporate most of the features, though we we won't be doing a per-app sizing. It's gonna be 10 or 20 (or maybe 30) and based on the theme. It's just taken a back seat while I flush the rest of the spec out.
Sometimes, the impossible can become possible, if you're awesome!
I'd love to help, just got tired of waiting.