Hello,
I'm the author of the 7+ Taskbar Tweaker program, and one the users mentioned that it would be great if the tweaker would be a part of PortableApps. I'm all for it. Are there any criteria for a requested application, except for the obvious, such as being portable? Is there anything that should be done for the inclusion?
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
I like this program. I already hate computers that don't have 7+ Taskbar Tweaker installed so I have it on memory stick (it's already portable). It's on my list of 10 must have programs (not including security programs).
The main requirements are to be fully portable and to be in PortableApps.com Format. Since you're already portable, it's really about ensuring it matches the common directory structure of PAF and stores Data in the right place (within the Data directory). Using a PA.c Launcher in the root to move your config file to/from App and Data would be all you'd need since your app doesn't deal with paths. It'd be even better if your app took a command line to direct it to the settings file so it could live in the Data directory and not move back and forth.
Read: Details on PA.c Format
If you need help, just let us know.
Sometimes, the impossible can become possible, if you're awesome!
Currently, this is the folder structure of the portable version:
http://i.imgur.com/HNZCj7o.png
I could add a command line parameter for the .ini file location, if necessary. All other files can be readonly.
Are there any other requirements in addition to this? In general, I prefer to make as little changes as possible, as the current folder structure has been working well for quite a while.
(I haven't read the linked article yet. I'll try to find time for it in the near future.)
I tried to put together a quick example of showing how it moves the files, but I'm not sure if PAL can handle the switch to the odd .ex2 secondary executable. I'm not sure how your main EXE calls the secondary one but it's somehow breaking out of the launcher. Possibly by injecting into explorer.exe? (which crashed on my Windows 8.1 box) You may also find increased false positives due to running an EXE that doesn't end in either EXE or BIN.
Here is as far as I'd gotten in my quick test to serve as a good example starting point:
http://downloads.portableapps.com/portableapps/misc/7PlusTaskbarTweakerP...
Your existing directory layout can stay within ours. The data file is moved back and forth to your app (7+TaskbarTweakerPortable\App\7+ Taskbar Tweaker) and to the Data location (7+TaskbarTweakerPortable\Data) by our launcher that would then wait for your main and secondary EXEs to exit. If there is a command parameter we can pass, we could eliminate the move back and forth and our launcher would just serve as a portable/relative glorified shortcut to start your app with the command line parameter and then immediately exit.
We use this layout and our special installer for lots of reasons:
https://portableapps.com/about/what_is_a_portable_app#whypaf
Sometimes, the impossible can become possible, if you're awesome!
The .exe is a tiny launcher, and it uses the standard method of starting a new process to launch .ex2.
The .ex2 is launched with additional command line parameters, which make it behave like a portable version (use the .ini file and not the registry).
The reasons that both .exe and .ex2 exist are the following:
* The setup is universal: it allows both standard and portable installation. To minimize the setup file size, the main executable files are the same, and in order for the program to know that it's the portable version, it's launched with extra command line parameters.
* The launcher runs the correct executable, 32 or 64-bit, depending on the current OS.
The .ex2 extension is being used because if left as .exe, it could be launched by accident and start polluting the registry, which is undesirable for a portable version.
Perhaps a solution for PAL would be to run the .ex2 file directly, with the correct command line parameters. Then, you could also specify the .ini file path.
The command line should be in the following format:
"D:\7tt_path\bin\(32|64)\7+ Taskbar Tweaker.ex2" -launcher "D:\7tt_path\7+ Taskbar Tweaker.exe" -ini "D:\7tt_path\7+ Taskbar Tweaker.ini"
PAL can detect 32 vs 64-bit and launch the appropriate EX2 file and then pass the -ini to the appropriate place all automatically without any custom code. That's all built in functionality. It can then exit immediately, serving as a glorified shortcut. You wouldn't need any changes on your end, and we can launch it when you're comfortable with it. I can likely take another look at it today.
Sometimes, the impossible can become possible, if you're awesome!
I've updated it to launch the EX2 files directly using the command options you provided. It's configured to launch and exit immediately. The settings file now remains in Data and works properly. You can download Dev Test 2 and try it out.
Check out the 7PlusTaskbarTweakerPortable.ini launcher configuration within App\AppInfo\Launcher so you can see how the launcher is configured.
When you update to a new version later, you just drop your new files in the 7PlusTaskbarTweakerPortable\App\7+ Taskbar Tweaker directory and adjust the two version entries within App\AppInfo\AppInfo.ini. You can then use the PA.c Installer to compile a new installer package just by pointing it to the 7PlusTaskbarTweakerPortable directory. You won't need to change the launcher configuration unless you later change the way your app works.
Let me know what you think. Once you're happy and hosting it later, we can release it.
Sometimes, the impossible can become possible, if you're awesome!
It mostly looks good, but the fact that there are two launchers now ("7PlusTaskbarTweakerPortable.exe" and "7+ Taskbar Tweaker.exe") will interfere with some of the features:
* Automatic update. After updating the tweaker version, the "7+ Taskbar Tweaker.exe" file is being launched.
* Running at startup. If the user chooses to set the tweaker to run at startup, the path of "7+ Taskbar Tweaker.exe" is being written.
* Also, the user might run "7+ Taskbar Tweaker.exe" manually.
In all these cases, the tweaker will use the .ini file which resides in the folder where "7+ Taskbar Tweaker.exe" resides.
I can't think of a solution to it without modifying the tweaker, but perhaps the simplest solution that does modify the implementation is to add a new entry to the .ini file, which will set a new path to the .ini file. Something similar to:
7+ Taskbar Tweaker.ini
==================
[Config]
new_ini_file=..\..\Data\7+ Taskbar Tweaker.ini
Then, the PAL launcher will only need to launch "7+ Taskbar Tweaker.exe", and moving the data won't be needed.
Portable apps in PA.c Format are not supposed to update themselves. Most users that use PA.c Format apps use the PA.c Platform which automatically keeps all their apps up to date without them needing to manually launch app individually and wade through separate update processes for each one.
https://portableapps.com/platform/features#updater
A portable app is generally not run at Windows startup. A user can select to run it at platform startup automatically (right click option). And the PA.c Platform can be run at Windows startup.
A user won't run the EXE directly and it's not something you should worry about. We have hundreds of apps all with EXEs contained within and millions of users. And we've been doing it that way for over 10 years. There's even a readme.txt within the app directory that says not to mess with things in the App directory. Plus, any user that would poke around inside an app and run random EXEs and get annoyed when they don't do what they expect could just as easily rename EX2 to EXE and run it directly anyway. Trying to protect your app against idiotic behavior is often a losing proposition. You do the basics to prevent it, but you can't idiot-proof it.
Sometimes, the impossible can become possible, if you're awesome!
You are mostly right, but the user still might want to e.g. use the portable version without the PA.c Platform, or might choose to run the program at startup from the settings. Therefore, I implemented my idea of the ini file redirection. Here's a beta version, with a folder hierarchy example:
https://www.dropbox.com/s/95f5pr6ssqrt7ik/7tt_setup_beta_4.5.10.4.zip?dl=1
I believe that this is a good solution, as it doesn't require from the PA.c launcher to do anything except running 7+ Taskbar Tweaker.exe. That creates less dependencies and less options for making mistakes.
Tell me what do you think.
Hi John,
Any news on this?
bump, I would like such a paf version
It's finally been released: https://portableapps.com/news/2024-02-06--7-plus-taskbar-tweaker-portabl...
Sometimes, the impossible can become possible, if you're awesome!