As a part of the directory standardization, I'm thinking about adding a CommonFiles directory. This would be handy for binaries that are shared among multiple applications. GTK+ would be an obvious example (used by Gaim and GIMP). Java would be another candidate for the future.
In adding on to the proposed directory structure, we'd get:
\ (Drive Root)
- Documents
- Music
- Pictures
- Videos
- PortableApps
- CommonFiles
- GTK
- FirefoxPortable (etc)
- GaimPortable (etc
...As an example, the Gaim launcher, if it didn't find GTK in the internal directory, would check the PortableApps\CommonFiles\GTK directory.
Any thoughts?
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
and it should make a lot of things easier when it comes to apps that use the same things such as gtk. That works.
***********************************
Deuce {The Core}{Dev Blog}
Portable Software: Just the beginning.
Deuce
Portable Software: Just the beginning.
I posted a thread several days ago requesting GTK Portable. This would be a great space saver if it worked. In addition to Gimp & Gaim, you could do Scribus, Grisbi, StarDict, etc. Let me know if you need testing on this.
Let's try it out. Here's a test release of the Gaim Portable Launcher with support built in for the above layout:
https://portableapps.com/downloads/GaimPortableLauncher1204.zip
You'll need to place your own binaries in the right places, of course. To try out the CommonFiles directory, be sure to delete the GaimPortable\App\GTK directory.
Incidentally, this launcher also strips out all old alternate directories and INI locations, making it easier to follow.
Sometimes, the impossible can become possible, if you're awesome!
Just gave it a spin, so far so good.
Edit: Nvm, readme.txt cleared my problem.
What I'd like to see, to help with encryption, is to see all the data and profiles under a single folder.
The problem with the split directory structure is that upgrades are a nightmare for a normal end-user (read: non-geek). It was great for backups and for being able to zip up and encrypt your data easily... but you had to manually upgrade all the bits and pieces.
The next suite is gonna keep standard directories with an app/data split inside each app's folder. This accomplishes a couple things. It makes upgrades dead-easy (every app now supports in-place upgrades... install it right over the old one). It also makes it easy to move an app and data from one drive to another (just one directory to copy). It does make backing up your data a bit more difficult, though... but that's why we've now got Portable Apps Backup. It understands the App/Data split in all the apps and can automatically backup all your app data without any configuration from you. It's a beta 2 now... and you can find it in the Beta Forum.
As for encryption... ultimately, having an encrypted 2nd virtual drive is the way to go. Think TrueCrypt but without admin requirements. Some devices now ship with commercial software that will do this. Some have encryptioon hardware on the key. Some even use fingerprint readers to secure it. I'm talking to a few of these manufacturers about being able to integrate these abilities. Most likely, this will be done by the use of an environment variable. Something like PORTABLEAPPDATAPATH. The launchers will check if it's set on launching and, if it is, use that to store all of their data. A handy side-effect of this is that you can also use it to have a single appdata directory on the same drive if you want.
Sometimes, the impossible can become possible, if you're awesome!
I wonder if there is a way you can determine the drive letters assigned to a particular device. Much like PStart uses %pdrive%. There should be a way, because the eject dialog will show what drive letters are assigned. When you plug in, an app can auto start and set the variable and then encryption/decryption is a breeze.
Hmmm...
The problem is that the encrypted virtual drive is created by "something else"... some other piece of software over which we have no control. Getting the drive letter of the drive an app is running from is completely trivial (I do it now). Getting the drive letter of a created virtual drive would mean that the software that handles that drive would have to let us know that. And that involves getting lots of different pieces of commercial software (and hopefully open source soon) to do things in a standard way.
Sometimes, the impossible can become possible, if you're awesome!