New: Zoom (May 18, 2023), Platform 25.0 (Apr 07, 2023)
New Apr 14: macOS Portable Drive Support
450+ real apps (49GB), 1.1 billion downloads, Please donate.
Would it be possible to drop the "Portable" suffix for display in the menu? The front page no longer uses the suffix in the list of updates, and it's kinda pointless in the menu, also. Would it be possible to just have the menu show the base name of the app?
Obviously Mozilla's stuff will have to retain the "Portable Edition" nomenclature, even in the menu, to keep Mozilla happy, but the other stuff... it just seems too verbose.
We're PortableApps.com, we make Portable apps. I think the reason they may have been removed from the front page feed is because it was too long.
That was my point. We're PortableApps.com (the menu even says it in the header), any app displayed in the menu is going to be portable. I wasn't suggesting changing the "official" names of the apps (i.e. officially it would still be Notepad++ Portable, OpenOffice.org Portable etc. and would reflect that on the app pages); I was just suggesting not to show the "Portable" suffix in the menu as it's redundant in that context.
Does it matter? The main point is that the apps work, and we're getting quality products. Adding/losing 8 or 9 characters (8 in portable, possibly a space) in a display really doesn't affect anything. If the screen one runs the apps from is so small, or resolution so bad, that those 8 or 9 characters distort the view, then it's probably time to upgrade.
if it matters that much to you, just get the menu mod and change the name yourself.
I don't know, it just seemed like it would make things more consistent, especially if we're going to open the PAF format up to outside developers. Lots of devs are going to design their apps specifically for portability and so might not want to use the "Portable" suffix. Toucan is a great example.
It's bad enough we have the inconsistent "Portable Edition" baloney on the Mozilla apps. It's weird having in the menu "App1 Portable", "App2 Portable", then "App3", then "App4, Portable Edition." First impressions are everything, and inconsistency generally leaves a bad impression.
Sorry if I sound like I'm on the warpath here. I'm really not. As said, I'm just throwing an idea out there. 
It actually doesn't matter that much to me either way, seeing as I don't use the Menu, but instead PStart. 
No need to apologize
Both the question and the idea are valid,
it just might not happen,
You could recompile the launchers. Just as long as you don't modify anything other then the display name, I think, you should be fine.
I also brought this up before. It seems people are attached to the Portable suffix. I rather would like to see also the Portable Suffix dropped. But I do understand the reason for adding it, to differentiate between the regular and portable versions of apps.
But in the menu it's kinda lame seeing the same suffix for every app. Many people new to PortableApps would have the same feeling...
Take IE7's official nomenclature:
"Windows Internet Explorer for Windows XP"
"Windows Internet Explorer in Windows Vista"
Just be thankful those aren't the names shown in the Start menu!
Just be thankful those aren't the names shown in the Start menu!
Touché! :lol:
-hea
way I like it is that "blahblah Portable" I know that I got it from portableapps.com, while all the others programs that I put there, like some of my games or other programs are not listed as such.
With the the new version of PAM which will be upcoming, isn't is supposed to allow renaming of display files? So it may be moot?
I posted my comment below before seeing this one.
"blahblah Portable" I know that I got it from portableapps.com
That brings up a good point... It seems that PAM should visually indicate which items are "official". Instead of relying on lengthy and inconsistent suffixes (e.g., Mozilla, Toucan), I presume that PAM could flag items that are signed with PortableApps.com's certificate. I would leave it to the graphics arts geniuses to come up with a non-intrusive yet immediately understood indicator of "official" PortableApps.com status.
For some reason, I can't help but envisioning a "PortableApps.com Red" check-mark overlaid with John's avatar to the right of all official apps... Like I said, I should leave it to the pros.
Thoughts? -hea
some sort of graphical identifier for official apps would be good. Not sure about using John's avatar though lol. I do like the idea of a small PortableApps.com Red check mark.
The future PAM will pay attention to AppInfo\appinfo.ini:[Details]Name to decide how to display it, rather than going blindly from the executable. I do think it makes sense for the executables to retain the "Portable" in their hover details, so the AppInfo trick is a reasonable fix.
It also seems reasonable to have the PAM simply remove {, Portable Edition|Portable} suffixes from menu items before displaying them. Perhaps this could be the default PAM option (e.g., CleanMenu=true).
-hea
I agree, it is redundant to have a portable suffix for apps that show up on a portable menu, but the fact is that this is a fairly simple problem that creates other issues when something is done about it. Ex:
The portable suffix is removed.
on websites, it is difficult to distinguish between regular and portable versions.
I think it is simply more practical to leave it and let the user deal with it if necessary, using the ini method mentioned above, recompiling, or another method.
That's my 2 cents...
The "official apps" argument is fallacious: Seeing "[appname] Portable" isn't a good indicator of "official PortableApps.com app" status because there's plenty of third-party PAFs out there already following the same template, e.g. IcoFX Portable, Dev-C++ Portable...
PortableApps.com, PortableApps, and the logo are trademarked; "[appname] Portable" is not (and I doubt it could be).
And everyone keeps bringing up the website argument... why? I never suggested removing the suffix from the "true" name of the app as displayed on the website... just the menu.
are certainly using the "blahblah Portable" tags, but I'm only getting those 3rd party apps from here, not anywhere else. Other websites may be using the correct format, but if it isn't BETA/PRE/DEVed or officially released here, I wasn't gonna install it because of my trust issues with this site.
Or even if I did, I would know that it wouldn't have the assumption of as rigourous a test of portability.
I'm not trying to be contrary with you, I don't think anyone else is either. I just know that for me, the default would to have it. If for some reason the PAM defaulted to not show it with some ini line to strip "Portable" out or something, I would probably have it set to show it.
It helps me also in that I've got non-pafed programs that are also in beta/pre/dev right now, and it helps me that I am running both versions as comparison.
_I_ know the programs are portable, I put it there, I got it from this website, but I like having it in the title as well.
Some apps are ridiculously slow and have a splash. I'd say for something like OO.o, which is slow+it has a splash, I say that it Execs before shows the splash to save time.
The real issue with the splash is that it disappears before the app is completely loaded. If there was a way to keep it up until the app's main window appeared, that would be better, I think.
require the screenshot plugin and highly advanced system-intensive logic that has to be more flexible than the GIMP. Therefore, no.
No... there's a Win32 function called FindWindow... no screenshots or image processing required.
and if I started it minimized?
Just because the window is minimized (or invisible, in the case of minimize-to-tray) doesn't mean it doesn't exist. FindWindow would still find it.
The only issue would be with a local copy of the app running at the same time as the portable version... the window would be found straight away.
okay- didn't know.
I think by default, you can't run a portable app and its non portable version (hmm. . .) at the same time.
I'm starting to think you can do anything with the system plugin.
FindWindow is also a built-in NSIS command.
To be bulletproof, however, what's needed is wraithdu's ${Execute} macro (which returns process ID) and a loop of user32::EnumWindows() and user::GetWindowThreadProcessId() to find any window created by that process.
AutoHotKey does exactly that with their built-in WinWait commands.
And, yes, that functionality could be provided via System.
-hea
P.S. Sounds like a worthy addition to ProcFunc.nsh, doesn't it? ${WinWait} and ${WinWaitVisible}, taking as arguments the PID or process name, and optional timeout.
As for newadvsplash, you can change its timeout to something long (e.g., 99999) and then newadvsplash::stop without the /WAIT flag to abruptly remove it at any time (e.g., upon noticing that a specific process has created a [visible] window).
Can't you set an infinite timeout for newadvsplash?
I think the main purpose is to differentiate from offitial PA.com apps from regular ones.
As I said before, that argument is fallacious. There are plenty of "unofficial" non-PA.com-supported apps following the same AppName Portable template. "____ Portable" isn't a trademark and I don't think it possibly could be.
I have both "WinMerge" and "WinMerge Portable" on my menu. If I had just "WinMerge" there, how would I differentiate the two?
Also, it doesn't matter if they are "unofficial" apps, because they are still portable.
So you have the non-portable WinMerge in your Portable Apps menu?
Seems like you would be a candidate for the CleanMenu=false option.
-hea
Which is a different issue entirely. I was just pointing out that "AppName Portable" is not a reliable indicator that the app was released by PortableApps.com, since a few people seem to think it is.
But I do have to ask: why would you have the regular WinMerge in there if you already have WinMerge Portable? What's the point?
Visit the Community page
Join our forums