Suggestions for next version

29 posts / 0 new

Last post

March 9, 2009 - 4:26am

temp4746

Offline

Last seen: 12 years 7 months ago

Joined: 2009-03-09 04:06

Suggestions for next version

I suggest the following features for the next version:

1. A settings menu - PortableApps has a few settings that are edited through an ini file it will be nicer to have a setttings menu for them.

2. Select applications for auto languages switching - PortableApps version 1.5 added support for switching of application languages according to the menu language.
I want to be able to select applications that will not switch instead of only behing able to disable it completely.
Since a few application i use have nasty translations to my language and i want them to stay in english, yet i still want to be able to use the auto language switching for other applications.

3. Categories/tree view of applications - it will be useful when you have many application or application with many icons on the menu (eg. openoffice).
I saw that there are mods to the menu that accomplish this but i wish this feature will be in the normal PortableApps menu.

4. Option to change icon of drive - You can change the title of the drive via the bottom left corner but i also want to be able to change its icon which is by default the portable apps icon to a diffrent icon or the default icon for a portable drive. (Pheraps in a settings menu? :P)

5. More a bug report than a feature but the border that appeared when you hover around the spot for the personal picture in the menu doesnt appear anymore (version 1.5)

6. Portable file associations - It would be nice if PortableApps changed the systems file associations to point to the portable applications.
It will probably require the portable applications to specify which file types to point to them and it will also require to handle cases when permissions are not avalible to preform this. A bonus would be to also allow creating custom overrides so you can for example create file associations for "mailto:" links to gmail.

March 9, 2009 - 5:37am

matrix737

Offline

Last seen: 14 years 2 months ago

Joined: 2009-03-02 15:06

a few more

i totally agree with those features, and i want to suggest a few more:

1.Changing Themes - right now we have to do it manually and overwrite the old theme, it would be very nice if we had option to choose between several themes.

2.Hide Icons - right now this option isnt really working in a way its comfortable to use it.

3.change the path and icon of the videos\music\documents... shortcuts.

4.eject script - instead of using the windows USB safety removal, there r several nice ejact scrip that work. u can even make it optional.

5.auto start programs

overall, this is a great program, cheers for the developers.

March 9, 2009 - 7:05am

TaffinFoxcroft

Offline

Last seen: 9 years 5 months ago

Joined: 2006-12-14 17:24

In reply to

In reply to temp4746:
Categories are in to todo list for 2.0, according to John. T. Haller.
Portable file associations can be done through PortableFileAssociator at the moment.

In reply to matrix737:
John also has a theme selector in the making for the 2.0 release, as well as an easy method of installing themes. more details here.
Hiding icons was only implemented in the current manner because John had to get a release out, but he plans to redo this in 2.0 .
There is several eject scripts floating around the internet, but they often kill apps accessing the thumb drive rather forcefully (by sending WM_CLOSE), which can result in a loss of data. The smarter thing to do would be to send WM_QUIT (I think) instead, which causes the application to do the whole "Save before exit?" thing (If its written into the app).
Auto start apps - I don't know if this is being done. presumably yes. But until it is done, you could use something like MenuLauncher.

But there’s no sense crying over every mistake,
You just keep on trying till you run out of cake.

March 9, 2009 - 11:06am

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

Some Answers

Settings Menu - The settings that are INI only are mainly because we didn't have time to get things translated into 37 languages before getting this release out in time for CeBit. They'll all be in the menu.

Language Switching Disable Per App - I'm going to add this in on a per-app basis. It'll be a nice easy right-click in the PA.c Menu. I wasn't aware that so many apps have faulty translations in specific languages, so I think this is important.

Categories - Categories are coming. They may hit 2.0 but may be 2.1 instead. They weren't originally scheduled for 1.5 (which is now called 2.0 after 1.2 became 1.5) but I'm pushing for them to be. It'll use the categories from the website by default as well as your own custom ones. For right now, you can set OO.o to be a single icon using the show single app icon option.

Drive Icon - You'll be able to set this from the menu in the next release just by clicking on its name.

Personal Picture Border - It's a bug in 1.5 that it doesn't appear on hover, it'll be back.

File Associations - These will be coming probably in the release after 2.0 but may debut in 2.0. It'll be more stable than some of the simple hacks out there now.

Theme Switcher - The theme switcher is debuting in 2.0

Hide Icons Process - As stated in the hide icons info the current implementation is temporary as we didn't have translations yet.

Custom Folders In Menu - You'll be able to customize the folder icons, names and paths in 2.0

Eject Script - We'll be using a built in process to properly close apps (instead of killing them as most scripts do). We may not be able to automatically tell Windows to safely remove the drive, though, as all the eject code out there is closed source or under a non-OSI license that we can't use.

Autorun Programs - You will be able to automatically run stuff on start and exit of the Platform in 2.0.

That all helpful?

Sometimes, the impossible can become possible, if you're awesome!

March 9, 2009 - 11:45am

(Reply to #4) #5

Bruce Pascoe

Offline

Last seen: 11 years 5 months ago

Joined: 2006-01-15 16:14

...

"All the eject code out there is closed source or under a non-OSI license that we can't use." Maybe, but certainly they all use the Windows API to do it, right? It's not like it's some dark art or anything. I'm sure if you looked through the Platform SDK docs, you could find a way to do it...

March 9, 2009 - 12:16pm

(Reply to #5) #6

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

C++

I don't know C++.

There is an old AutoStart app out there that has GPLed eject code in it that we could use. But I don't know C++.

http://xpt.nl/products-autostart

If you can get that loaded and put together a simple GPLed EXE for ejecting a drive, we would be singing your praises.

Sometimes, the impossible can become possible, if you're awesome!

March 9, 2009 - 4:47pm

(Reply to #6) #7

ZachHudock

Offline

Last seen: 5 months 5 days ago

Joined: 2006-12-06 18:07

C++ isn't necessarily

C++ isn't necessarily required. Just about every programming language out there has some way to access the Windows API

The developer formerly known as ZGitRDun8705

March 14, 2009 - 6:54am

(Reply to #7) #8

incognite

Offline

Last seen: 14 years 2 months ago

Joined: 2008-08-28 06:40

what about Unicode John are open source all supposed to comply with UTF-8 and UTF-16, aren't those character sets enough with others supplied as needed, ie ANSI etc?

March 14, 2009 - 11:59am

(Reply to #8) #9

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

One or The Other

Most apps are either Unicode or ASCII. Or they have to do two separate builds which we aren't doing. We've discussed Unicode before. It involves another $1,000 outlay by me and then it will cut off Windows 95,98,Me.

Sometimes, the impossible can become possible, if you're awesome!

March 9, 2009 - 11:55am

(Reply to #9) #10

John Bentley

Offline

Last seen: 13 years 9 months ago

Joined: 2006-01-24 13:26

These may be of

These may be of interest.

http://vbnet.mvps.org/index.html?code/disk/devioejectload.htm (Not sure about the license for this one.)
http://www.codeproject.com/KB/system/usbeject.aspx (C#, but uses the windows API.)

cowsay Moo
cowthink 'Dude, why are you staring at me.'

March 12, 2009 - 11:20am

(Reply to #10) #11

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

One request for the next version

JTHLanguage Switching Disable Per App - I'm going to add this in on a per-app basis. It'll be a nice easy right-click in the PA.c Menu. I wasn't aware that so many apps have faulty translations in specific languages, so I think this is important.

John, at the moment it's possible the disable the language switching. That option will be my default option, but I have a feature request though. If you disable the app language switching at the moment (PAP 1.5), the automatic language switching for the installer will be disabled too (so I'll have to choose the installer language when installing an app within the menu). I think that isn't necessary. Just disable the automatic language switching for the apps and NOT for the installers.
Thanks for your hard work!

March 12, 2009 - 11:23am

(Reply to #11) #12

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

Both

No, they have to be one and the same as they're all keyed off the same environment variables. And some app installers will switch the language based on the language they're installing in. So, it's all or nothing at the moment. Disabling the switching on a per-app basis takes into account a buggy translation for a specific app, which is what was originally desired. Disabling it across the board is primarily intended for developers.

Sometimes, the impossible can become possible, if you're awesome!

March 12, 2009 - 3:32pm

(Reply to #12) #13

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

Alright John,

now it's all or nothing. That's cool.
You're going to add the ability on a per-app basis, right? But then it won't be all or nothing anymore. And maybe I'm wrong, but then my feature request makes sense too.

JTHAnd some app installers will switch the language based on the language they're installing in.

That isn't an issue for end-users. They're using the menu in their most wanted (native) language, so the installer and the app (after installation) will be in the same language. And it will be easy for an end-user finding the setting to change the language if the app starts in his native language. It's just as easy as changing the language at a local install.

JTHDisabling it across the board is primarily intended for developers.

Maybe intended for developers, but who knows how many use that option? I'm the first one

Just my 2 cents.

March 12, 2009 - 3:46pm

(Reply to #13) #14

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

All Or Nothing

I mean it's all or nothing platform wide. There's a single set of environment variables used everywhere. I'm going to have to specifically blank them out, launch the individual app, and then reset them for that disable language switching for one app thing. And I'm not quite sure on the timing of it all yet as we may need to add a short wait when doing this.

We're working on the assumption that most apps have decent translations in whatever language the user is in right now, which is a pretty safe bet for the major languages. If we get more requests, I'll consider complicating the whole system, but for now I'd like to keep it simple.

The per-app basis is targeted at end users for that rare app with a bad translation that they want to keep in a different language. The disable lang switching is for people that want to do everything themselves... especially developers for testing.

Honestly, you probably fall more into the first category. Keep it enabled. Installers are automatically in your language. When you run into an app you want in a different language you can just install it as normal. Fire it up in native. Switch it to say English since it has a bad native translation. Then right-click on that app in the menu and select to disable language auto-switching.

And remember, you'll only really be doing this once per app.

Sometimes, the impossible can become possible, if you're awesome!

March 12, 2009 - 4:05pm

(Reply to #14) #15

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

:-)

I'm happy John. Looking forward to answering support questions about how to change the language
And remember, if I disable the complete app switching thing, I'll only set the language once per app. And many apps start in the system language anyway (at first launch).
IMHO, automatic language switching has more disadvantages than advantages --> DisableAppLanguageSwitching=true.

March 13, 2009 - 8:27am

(Reply to #15) #16

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

Easy way to implement my feature request

John, you would like to keep the system simple. How about that?

If DisableAppLanguageSwitching=false, the menu will set the old environment variables (PortableApps.comLanguageCode, PortableApps.comLocaleCode2, PortableApps.comLocaleCode3, PortableApps.comLocaleglibc, PortableApps.comLocaleID, PortableApps.comLocaleWinName).
If DisableAppLanguageSwitching=true, the menu won't set the old environment variables, but it will set one environment variable PortableApps.comLocaleIDInstaller. It will use the same LocaleID as the PortableApps.comLocaleID.

Well, we need two extra lines in the PortableApps.comInstaller.nsi, so that all my dreams come true.
Old PortableApps.comInstaller.nsi (0.12.4, lines 383-385)

!ifdef INSTALLERMULTILINGUAL
	ReadEnvStr $0 "PortableApps.comLocaleID"
	!ifdef USES_ENGLISH

New PortableApps.comInstaller.nsi suggestion

!ifdef INSTALLERMULTILINGUAL
	ReadEnvStr $0 "PortableApps.comLocaleID"
	StrCmp $0 "" "" +2
	ReadEnvStr $0 "PortableApps.comLocaleIDInstaller"	
	!ifdef USES_ENGLISH

Simple, isn't it?

March 13, 2009 - 11:50am

(Reply to #16) #17

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

We have all our apps on an installer with specific features. Not to mention lots of outside entities. All using it. And then we'd have some app installers working with it and some not since, usually, some apps don't get updated for at least 6 months or more. So that is absolutely not going to happen.

Why don't you just do exactly what I said? Once the next Platform release comes out, keep it enabled (all your installers will happily be in your requested language as you want) and for the specific apps you don't want language switched, just right click on them and disable language switching for them. One time per app. And you're not really gonna know if the language is wrong until you try it. Is that honestly so hard?

Sometimes, the impossible can become possible, if you're awesome!

March 13, 2009 - 1:12pm

(Reply to #17) #18

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

Noooo!

John, look at the code and think!

DisableAppLanguageSwitching=false ->

everything will work, there is no difference

DisableAppLanguageSwitching=true ->

Old Apps (with old installers) have all or nothing, no automatic language switching for the installer and app (same as now). That's fine
New Apps (with new installers) have the automatic language switching for the installer, but NOT for the apps. That would be really cool

Why don't you see that some (or many) people don't want that automatic app language switching? Maybe because you are an english native, I really don't know. That new feature is surely well-meant, but in my opinion not practical. I call that a gimmick.

That was definitely my last approach, will NEVER make any suggestions/feature requests again.
Bart.S over.

March 13, 2009 - 1:45pm

(Reply to #18) #19

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

Please Read This Entire Thing And Comment

I'm sorry but I'm still looking for a logical reason for your approach besides it being the way you want it.

For situations where a user likes the language switching, they keep it enabled. All their apps automatically switch. If they encounter an app with a bad language translation for their chosen localization, they can right-click and disable it for that app.

For situations where a user doesn't like language switching, they can disable it. All apps will handle language just as their local installs do.

I guess what I'm missing here is who isn't covered by the two above possibilities? It covers someone who wants to do it manually. It covers someone who wants it all automated...

And it covers someone who has a couple apps that (as an example) have bad Polish translations even though they have the Platform in Polish and want apps to usually be in Polish. Let's say in this example that Task Coach has a bad Polish translation and they want it to appear in English. They can launch the installer from the Platform and it'll automatically do Polish in the PA Installer. After it is installed, they can right click on Task Coach in the menu and say "Disable Language Switching". Then they can start Task Coach and it'll be in English... or they can manually switch it to another language. And it'll be that way for that app on every upgrade after that. And they can do that for as many or as few apps as they want.

So, why are you saying things like "Why don't you see that some (or many) people don't want that automatic app language switching?" when it's obvious that the above scenarios cover those users. The above scenarios cover everybody. Why would there need to be more options? If you can logically explain it with actual scenarios for end users, I'll consider something additional.

Sometimes, the impossible can become possible, if you're awesome!

March 17, 2009 - 10:13am

(Reply to #19) #20

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

Progress

Well, the logical reason for my suggestion is progress (improve the usability), John. Oh, and I don't need it, but it would improve the PAP, IMHO.
John, you're right, your scenarios cover all users, but why not improve the user-experience?
I apologize to you for my statement "Why don't you see that some (or many) people don't want that automatic app language switching?", but I was angry with you. Not the fact that you don't like my suggestions was the reason, it's how you say no.
Why are you implying that my suggestions would break the compatibility with apps, installer or platform when you don't prove your statements? Why are you saying things like "..your method would NOT work with the new Platform anyway" or "If you truly don't understand the concepts I explained to you..."?
That isn't fair and I can't accept that.
Saying "Thanks for the suggestion, but I don't see any benfits for the platform so I probably don't change the code" or "That part of your suggestion isn't good, because that won't work or that will break the entities ..." would be nice! I'm aware of the fact that not all of my suggestions are perfect.

Sorry for the criticism but now back to topic:
It's more comfortable to disable the language switching for all users speaking non-major languages too!
Say we have an unexperienced korean user who sets the menu to english.

enabled language switching: Menu is in english, installer is in english, app is in english. The user changes the language to korean and restarts. It's in english again, the user doesn't know why and asks for support. He doesn't know the language switching and disabling on a per-app basis features. Then he has to disable the switching for almost every app.
disabled language switching: Menu is in english, user chooses installer language (korean), app is in korean (because most apps start in system language). The user is happy. Say the app isn't in korean (because not system language), user set it to korean and the app is in korean after a restart, everything is fine. User is happy too!

And now the question? What is more comfortable, disabling or enabling the language switching?
My suggestion would improve the "disabled language switching" scenario a little bit, because there is no need to choose the installer language every time. Even better would be, if the user could set a different installer language.
So our korean user from the example sets the menu to english, but the installer to korean. The variable PortableApps.comLocaleID points to the english locale and the variable PortableApps.comLocaleIDInstaller points to the korean locale.

disable language switching (my suggestion): Menu is in english, installer is in korean, app is in korean (always, if app has korean locale). User is extreme happy!

There is no need to right-click most of the apps, the user only disable the language switching once!

But as said above, there is no need to regard my suggestion, your second scenario covers all users!

March 17, 2009 - 10:39am

(Reply to #20) #21

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

Less Usable

Honestly, in my opinion, it makes it less usable. I ran your suggestion in your post before by a half-dozen other PortableApps.com developers, including those that don't use English as their main language, and they didn't see the logic behind it either. It just makes things more complicated. Why would a user want the menu in English but all their apps to be in Korean? I still just don't get it.

Doing something just for the sake of having a feature does not improve usability, it complicates it. It's one more option that a user needs to understand and mentally scan through when they're trying to figure out what they want.

Sometimes, the impossible can become possible, if you're awesome!

March 17, 2009 - 10:45am

(Reply to #21) #22

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

Where is it?

Well, John, where is the korean menu locale? No locale, noone can't choose it. And you have only locales for major languages!

March 17, 2009 - 11:09am

(Reply to #22) #23

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

Won't Work

I think I see your point now, but you're missing a part of the way everything works together in your thinking...

If the menu doesn't have a locale file for a given language... it *CAN'T* set that language for anything at all. So, even if you wanted the installer and apps to be in Korean, the Platform can't do that for you since it doesn't even know what Korean is, let alone what the 2-character language code, 3 character language code, glibc code and NSIS code are for it (all of which are required by language switching because different apps use different ones depending on how they treat it internally).

In the case where the menu doesn't have their language, the end user would probably want to disable language switching, which we're going to expose in the options window to make it easier (rather than INI only). Major languages like Korean, we're actively looking for a translator for the next release (we already have a 95% complete Korean translation that will be in the next release). We've got about 97% of the world covered language-wise with the 37 languages we support in the current release and are working on the other 3%. Korean is actually the only big outlier at this point (it's #10 online with about 2% of web users / #18 based on speakers offline).

Sometimes, the impossible can become possible, if you're awesome!

March 17, 2009 - 1:05pm

(Reply to #23) #24

Bart.S

Offline

Last seen: 3 months 4 weeks ago

Joined: 2008-07-23 07:56

LOL

I think I see your point now, but you're missing a part of the way everything works together in your thinking...
Yeah, could be solved with "mini"-locales though. Only the name and the LocaleID are necessary for the installer.
The Korean.locale (for example) could look like this:

[PortableApps.comLocaleDetails]
Name=Korean
LocaleID=1042

Oh, and my first thought was without setting a different installer language. It would be more comfortable for the korean user as well, if the menu automatically do english in the installer.

March 10, 2009 - 9:47pm

#25

monarocv8

Offline

Last seen: 11 years 2 months ago

Joined: 2009-03-10 21:43

Shortcuts & command switches

Would be nice to be able to alter the startup for certain apps to include startup parameters/switches, rather than just the executable.

One way to do this would be to recognise Windows shortcut files, as well as .EXE files when refreshing App icons.

March 11, 2009 - 1:53am

(Reply to #25) #26

Chris Morgan

Offline

Last seen: 7 years 11 months ago

Joined: 2007-04-15 21:08

Already in

Command line arguments are already in - see AppNamePortable\Other\Source\AppNamePortable.ini, line "AdditionalParameters=". If you're wanting this in the Platform, you never know, by version 5.0 a GUI for it might be in...

As to shortcuts, that's something which we have no intention of supporting; we handle PortableApps.com Format apps, not Windows shortcuts (which, btw, use absolute paths and so are not a solution).

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

March 12, 2009 - 1:14pm

(Reply to #26) #27

dragonmage

Offline

Last seen: 4 months 3 weeks ago

Joined: 2007-01-15 02:25

Here's an idea I don't have a

Here's an idea I don't have a use for, but someone will I'm sure.

AppnamePortable.ini allows for adding AdditionalParameters

What about being able to make AppnamePortable2.ini with different AdditionalParameters? It would create another menu item, that would run the app with those parameters.

I'm sure there are people who need to start apps with different params at different times, this should make it easier.

March 14, 2009 - 1:49pm

#28

The_Steve

Offline

Last seen: 10 years 11 months ago

Joined: 2009-03-14 12:43

Option suggestion

For the 2.0 release I would love it if you could turn off the drop shadow effect. (The drop shadow around the app launcher itself)

The shadow makes skins with curved edges look silly. Unless you could make the shadow follow the edge of the mask?

March 14, 2009 - 1:54pm

(Reply to #28) #29

John T. Haller

Offline

Last seen: 5 hours 50 min ago

Joined: 2005-11-28 22:21

Skinning

That will be addressed next week as we start to address skinning (skinning isn't yet supported)

Sometimes, the impossible can become possible, if you're awesome!

Please Help Support Us

Please consider making a donation so we can keep bringing you great software.

You are here

Suggestions for next version

Please Help Support Us

Translate Page

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com

You are here

Suggestions for next version

Please Help Support Us

Translate Page

User login

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com