user input

[MikeFromMesa]

Is there any way to get user input when running a PSP script? The raw_input and input commands do not seem to work when placed in a script.

I am trying to simplify my scripts by writing a single script to replace multiple ones, but to know what action to take I need to ask the user, so I tried both raw_input and input. Both caused internal errors and aborted the script. I am trying to avoid writing a separate little app and have the script run it, so any way to do it in a simple way would be appreciated.

Thanks.

[LeviFiction]

GetNumber and GetString commands inside PSP will let you prompt for values from the user. Eventually, if you're up to it and find you need a full dialog you can use the tkinter GUI libraries that come with PSP's Python implementation to do more advanced UIs.

GetNumber and GetString present a small dialog with either a scroll-box for numbers with a maximum and minimum value. Or just a text box to enter a string.

You can find details on these commands in the API and the Scripting for Script Authors PDF in the "Commands" index. Here is an excerpt on GetString


Command: GetString
Parameters:

• DefaultText – the text that is initially shown in the dialog
• DialogTitle – text shown in the title bar of the dialog
• Prompt – a string shown above the edit box
• MaxLength – the maximum length of the string allowed. If this is shorter than the DefaultText then it is automatically increased to be as long as the default text

Sample Script

Code: Select all

from PSPApp import *
def Do(Environment):
    Result = App.Do( Environment, 'GetString', {
        'DefaultText': 'Hello World',
        'DialogTitle': 'This should be the title',
        'Prompt': 'This is a fairly long prompt string that will probably wrap around to a second line',
        'MaxLength': 25,
        'GeneralSettings': {
            'ExecutionMode': App.Constants.ExecutionMode.Interactive
            }
        })
    print Result[ 'OKButton' ]
    print Result[ 'EnteredText' ]
    Result = App.Do( Environment, 'GetString', {
        'DefaultText': 'Silent Mode',
        'DialogTitle': 'Foobar',
        'Prompt': 'Short entry',
        'MaxLength': 25,
        'GeneralSettings': {
            'ExecutionMode': App.Constants.ExecutionMode.Silent
            }
        })
    print Result[ 'OKButton' ]
    print Result[ 'EnteredText' ]

Description
This command brings up a simple dialog box that contains an edit box and prompt. The user types in a string and presses OK or Cancel.

[MikeFromMesa]

Thank you. That is more than sufficient for now.

The idea is to bundle all of the external editor scripts into a single script that can take input from the user to determine what external editor to call. Your post has saved me the trouble of installing Visual Studio and creating an unnecessary external GUI to get the information from the user.

Perhaps once I have this working I will look into creating a more involved dialog box, but then I have always believed "one step at a time".

[JoeB]

Thank you. That is more than sufficient for now.

The idea is to bundle all of the external editor scripts into a single script that can take input from the user to determine what external editor to call. Your post has saved me the trouble of installing Visual Studio and creating an unnecessary external GUI to get the information from the user.

Perhaps once I have this working I will look into creating a more involved dialog box, but then I have always believed "one step at a time".

As very much a non-expert in scripting and the intricacies of Python, if you get that script to work I hope you'll be willing to share it!

[MikeFromMesa]

As very much a non-expert in scripting and the intricacies of Python, if you get that script to work I hope you'll be willing to share it!

Well, yes, but ...

A couple of things I should mention. First, I am not an expert in scripting, nor in Python. In fact I only downloaded and installed Python perhaps a week ago, so I am learning it by trial, and I only started working with the PSP scripting language a couple of days before that, so I am far from being an expert in either.

Second, in order to combine the multiple scripts I currently have (ViewPoint, Aurora, Luminar, PerfectlyClear, etc) into a single script I had to add some complexity to the script, both in the coding and in the user supported information.

For example, when I ask what exe to run I have to then validate the entered information to make sure I run the right thing, or exit if invalid information has been entered. Since any user may wish to select any exes he or she wants, that means that the user has to enter the valid response and the valid exe paths. And since the match is found via a validation routine that means that the user has to enter the information both correctly and in the same order in several places. Otherwise a specification for ViewPoint might end up running Luminar.

The user also has to define exactly what the app should ask when asking for when prompting for a response. I specified a set of letters to represent the apps - v for ViewPoint, l for Luminar, p for PerfectlyClear and so on. The user would have to update those as well.

Also I have changed the place where the files are stored as I thought it would be best if the temporary file for use in calling the exe were in the same folder as the original file. Some users may not want that. And there are other changes, some of which require the user to enter the correct information. All of this may well be more than most users want to do, especially when they only have to copy the current script and change (I think) 2 entries. My script would require perhaps 5 or 6 lines to be entered and/or changed, depending upon what exes are to be called.

All of this may well be more than most users want to do for the convenience of only having a single script. For me it is worth it as it simplifies my usage and gives me something to do now that I am retired. And, since I love coding anyway, it is a labor of love. For others it may well not be worth the trouble.

[JoeB]

I see the issues, Mike, and so perhaps nothing would be gained by my having your resultant script.

That said, I'm going to speculate very wildly about a concept for what you're trying to achieve just to see if it's possible to think about this script from another angle. My lack of scripting knowledge will be apparent here but I figure nothing is lost by asking about out-of-the-box possibilities.

I recall that there are some scripts that start with a dialogue window with radio buttons where the user makes a choice of some parameter they wish the script to start with. I can't recall a specific instance but perhaps one could be choosing whether to put the effect the script creates on the original image, a new layer or a new image (assuming it's actually possible to write a specific script like that). This would mean the script would need something like else-if statements (or some other statement which can take user input or a combination of same), which would point to the specific save command chosen by the user (similar to how the scripts to run outside programs allow the user to edit the script to determine output save formats). But I'm wondering if a script could be written so that this determination could be done by the user selecting a radio button on the opening dialogue instead of having to actually edit the script ahead of time.

And what I'm specifically speculating about is the use of Gary Barton's Pause script. This script allows the script to pause at intervals to allow user input. The different, successive parts of the script that run and then pause are defined by the do environment being named doStep1, doStep2, etc., with each step running and then pausing before the next step until the user runs the script again which causes it to run the next step. A msgbox can appear when the user runs the script for the next step asking if the user wants to continue. Clicking No terminates the script.

So my thought is that each script could be a separate step. The radio box would have each button identified by the script the user wants to use - e.g., the first button titled Luminar would be doStep1, the second labelled Viewpoint would be doStep2, etc.

So the question that I have absolutely no idea of the answer to is whether or not such a script could be written (perhaps by using else-if statements, getString commands or a combination thereof) so that the script can start by taking the user input (e.g., the second radio button selected which points to doStep2) and then start at that step, which would run the Viewpoint script and pause.

I recall awhile ago user TerryPin asking about putting more than one script into a single script, although his scripts weren't trying top open outside editors. Maybe he was thinking of something similar to what you are trying to achieve.

Probably sounds pretty farfetched but thought I'd ask anyway!

[LeviFiction]

Those are done with Tkinter. I have several scripts that make use of such dialogs. And the Luminosity/Shadow/Highlight/Midtone mask script (I can't remember what they're called) were expertly created aslo using Tkinter and their styling routines. They look beautiful.

With Python Tkinter is the default GUI method, and with PSP the only GUI method as other thirdparty libraries have to be compiled to use PSP's CorePython.dll library instead of the standard Python27.dll when they are created. It's a mess. But Tkinter is fully compiled to work with PSP. So it's the best method we have.

[JoeB]

Those are done with Tkinter.

Just to cover all the bases, could it be done without Tkinter if the user had to type something into the opening message window? I'm thinking of something like the input window telling the user to type Luminar (or doStep1, or some other relatively simple text that could be interpreted by the script) if that was the script they wanted to run, or Viewpoint (or doStep2), etc, and is that the type of user input that the script could interpret and - again using either else-if, getString or some other command(s) or a combination thereof - start the script at the step/position required based on relatively simple user input, the options for which could be suggested to the user in the dialogue. Just another thought.

[MikeFromMesa]

That said, I'm going to speculate very wildly about a concept for what you're trying to achieve just to see if it's possible to think about this script from another angle. My lack of scripting knowledge will be apparent here but I figure nothing is lost by asking about out-of-the-box possibilities.

In the end, software is software, and all programming languages, scripting included, have to deal with the same issues. Not only is nothing lost by asking questions, especially "out-of-the-box" questions, much is generally gained.

I recall that there are some scripts that start with a dialogue window with radio buttons where the user makes a choice of some parameter they wish the script to start with. I can't recall a specific instance but perhaps one could be choosing whether to put the effect the script creates on the original image, a new layer or a new image (assuming it's actually possible to write a specific script like that). This would mean the script would need something like else-if statements (or some other statement which can take user input or a combination of same), which would point to the specific save command chosen by the user (similar to how the scripts to run outside programs allow the user to edit the script to determine output save formats). But I'm wondering if a script could be written so that this determination could be done by the user selecting a radio button on the opening dialogue instead of having to actually edit the script ahead of time.

When developing software of any complexity the developer usually has to ask some up-front questions. Does he or she want to make the software user controllable? If so, how? Using a configuration file? Using a dialog box? Using step-by-step inquiries? Or by some other way. While this software is not complex in relation to normal software packages (it is only a couple of hundred lines, and only involves perhaps fewer than a dozen decisions) the real question is whether to create a separate configuration file, allow the user to set up the values in the script, show some dialog box with the possible values or post inquiries during process. My personal opinion is that the software ought to run as quickly as possible and with as few annoying pop-ups as possible, and that generally means no sequence of pop-ups. Your suggestion is certainly a good one, but I think that users do not want to be processing dozens or hundreds of images and have to answer a series of questions for each.

The same thing, in a shorter version, applies to a dialog box. Each time the script runs the user would have to answer the same questions and, since probably the answers would be the same most of the time, this does not seem like the best solution for this particular problem. The script is already set up to ask what exe to run, and I think that is a bit of a burden, but I can see that as valid as the particular exe that the user needs to run may well change from time to time. I suspect that whether to use a jpg or tiff is probably not something that would change with every image. Either a user prefers to use tiffs or prefers to use jpgs. That leaves either a configuration file or settings in the code for the rest of the options. My personal favorite of those is the first, but I can live with the second, but that is just my opinion.

And what I'm specifically speculating about is the use of Gary Barton's Pause script. This script allows the script to pause at intervals to allow user input. The different, successive parts of the script that run and then pause are defined by the do environment being named doStep1, doStep2, etc., with each step running and then pausing before the next step until the user runs the script again which causes it to run the next step. A msgbox can appear when the user runs the script for the next step asking if the user wants to continue. Clicking No terminates the script.

So my thought is that each script could be a separate step. The radio box would have each button identified by the script the user wants to use - e.g., the first button titled Luminar would be doStep1, the second labelled Viewpoint would be doStep2, etc.

So the question that I have absolutely no idea of the answer to is whether or not such a script could be written (perhaps by using else-if statements, getString commands or a combination thereof) so that the script can start by taking the user input (e.g., the second radio button selected which points to doStep2) and then start at that step, which would run the Viewpoint script and pause.

Yes. Certainly that should be possible, and might be a good solution. I just am not sure if it is feasible from a usage prospective. Does the user wish to continually have to answer the same series of questions?

In the software world much has been written about how software must conform to specifications, but the truth is that there are both written and unwritten specifications and the unwritten ones are often the most important. As I have repeatedly told managers, there is almost never a specification about how fast software must run, but processing an image can not take 1 hour because the software becomes useless due to the time that is consumed. Similarly there is almost never a specification about how much user interaction there must be, but it can not be too cumbersome or the software will never be used. And I suspect that a series of pop-ups, having to be answered every time an image is processed, will just be too much of a burden. Perhaps I am wrong about that, but this has been my experience in the past.

Probably sounds pretty farfetched but thought I'd ask anyway!

It is not far-fetched at all. In fact they are good suggestions, and I truly appreciate your suggestions. Really.

I just believe that they might be too time consuming when processing hundreds of images as I sometimes have to do. I could be wrong. It has happened before ...

[juergen]

Hi,
don't know if i understand the actual question. Do you mean something like this?
The user has to choose a number from 1-... and the option -what-to-do is "hard-coded" in the script...


# choice
okay = 1
result = App.Do( Environment, 'GetNumber', {
'DefaultValue': okay,
'MinValue': 1,
'MaxValue': 6,
'DialogTitle': 'NIK-Collection',
'Prompt': '1=Viveza 2=ColorEfexPro 3=AnalogEfexPro 4=SilverEfexPro 5=Dfine 6=SharpenerPro',
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Interactive
}
})
if not result['OKButton']:
return
okay = result['EnteredNumber']

# NIK start
if okay == 1:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Viveza 2\\Viveza 2 (64-Bit)\\Viveza 2.exe" c:\\temp\\NIK-IN.tif')
nikname = 'Viveza'
elif okay == 2:
...


Regards, Jürgen

(made for old Jasc PSP9...)?
complete script:

# store actual selected picture temporary as an TIF
# choice -> external program NIK-Collection
# open selected program NIK-Collection with temporary stored TIF
# wait for ok in PSP...
# ...external work with NIK-Collection...overwrite temporary stored TIF
# ...press ok in PSP
# loads processed TIF (result of the external program) and copy to clipboard
# paste clipboard as a new layer on top of actual picture ("open file as new layer" not found in PSP9)
#
# ToDo once
# temporary file: c:\\temp\\NIK-IN.tif (search & replace if you want to use another place) <----------------
# NIK-Collection: C:\\Program Files\\Google\\Nik Collection\\ (search & replace espec. when using 32bit versions) <----------------
# HRDEfexPro not useful to process in this way
#

from JascApp import *
import os

def ScriptProperties():
return {
'Author': u'Juergen Galupki',
'Copyright': u'copyright (c) 2015 http://galupki.de',
'Description': u'process actual picture with external program - paste result as new layer v1.0 04.04.2015',
'Host': u'Paint Shop Pro 9',
'Host Version': u'9.01'
}

def Do(Environment):
# SkriptOptimiertRückgängigAktivieren
App.Do( Environment, 'EnableOptimizedScriptUndo', {
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# DateikopieSpeichernUnter
App.Do( Environment, 'FileSaveCopyAs', {
'Encoding': {
'TIF': {
'Compression': App.Constants.TiffCompression.LZW,
'Channels': App.Constants.ColorChannels.RGB
}
},
'FileName': u'C:\\temp\\NIK-IN.tif',
'FileFormat': App.Constants.FileFormat.TIF,
'FormatDesc': u'Tagged Image File-Format',
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
},
'DefaultProperties': []
})

# choice
okay = 1
result = App.Do( Environment, 'GetNumber', {
'DefaultValue': okay,
'MinValue': 1,
'MaxValue': 6,
'DialogTitle': 'NIK-Collection v1.0 04.04.2015 http://galupki.de',
'Prompt': '1=Viveza 2=ColorEfexPro 3=AnalogEfexPro 4=SilverEfexPro 5=Dfine 6=SharpenerPro',
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Interactive
}
})
if not result['OKButton']:
return
okay = result['EnteredNumber']

# NIK aufrufen
if okay == 1:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Viveza 2\\Viveza 2 (64-Bit)\\Viveza 2.exe" c:\\temp\\NIK-IN.tif')
nikname = 'Viveza'
elif okay == 2:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Color Efex Pro 4\\Color Efex Pro 4 (64-Bit)\\Color Efex Pro 4.exe" c:\\temp\\NIK-IN.tif')
nikname = 'ColorEfexPro'
elif okay == 3:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Analog Efex Pro\\Analog Efex Pro (64-Bit)\\Analog Efex Pro.exe" c:\\temp\\NIK-IN.tif')
nikname = 'AnalogEfexPro'
elif okay == 4:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Silver Efex Pro 2\\Silver Efex Pro 2 (64-Bit)\\Silver Efex Pro 2.exe" c:\\temp\\NIK-IN.tif')
nikname = 'SilverEfexPro'
elif okay == 5:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Dfine 2\\Dfine 2 (64-Bit)\\Dfine2.exe" c:\\temp\\NIK-IN.tif')
nikname = 'Dfine'
elif okay == 6:
os.system('"C:\\Program Files\\Google\\Nik Collection\\Sharpener Pro 3\\Sharpener Pro 3 (64-Bit)\\SHP3OS.exe" c:\\temp\\NIK-IN.tif')
nikname = 'SharpenerPro'
#elif okay == 7:
# os.system('"C:\\Program Files\\Google\\Nik Collection\\HDR Efex Pro 2\\HDR Efex Pro 2 (64-Bit)\\HDR Efex Pro 2.exe" c:\\temp\\NIK-IN.tif')
# nikname = 'HDREfexPro'

# Wait for input
ButtonTypes = ( 'Cancel/No', 'OK/Yes' )
result = App.Do(Environment, 'MsgBox', {
'Buttons': App.Constants.MsgButtons.OK,
'Icon': App.Constants.MsgIcons.Info,
'Text': 'OK for importing picture as new layer',
})
ButtonTypes[ result ]

# DateiÖffnen
App.Do( Environment, 'FileOpen', {
'FileList': [u'C:\\temp\\NIK-IN.tif'],
'Folder': u'C:\\temp',
'FileFormat': App.Constants.FileFormat.Unknown,
'ShowPreview': False,
'EnableBrowser': True,
'FavFileList': [],
'RawCameraSettings': {
'WhiteBalance': App.Constants.WhiteBalance.AsShot,
'SharpenMode': App.Constants.SharpenMode.Low,
'Exposure': 0,
'Rect': ((0,0), 0, 0),
'ShowMaximized': False,
'ShowPreview': False
},
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# DokumentAusw
App.Do( Environment, 'SelectDocument', {
'SelectedImage': 0,
'Strict': False,
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# Kopieren
App.Do( Environment, 'Copy', {
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# DateiSchließen
App.Do( Environment, 'FileClose', {
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# DokumentAusw
App.Do( Environment, 'SelectDocument', {
'SelectedImage': 0,
'Strict': False,
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# AlsNeueEbeneEinfügen
App.Do( Environment, 'PasteAsNewLayer', {
'CreateFromDropData': False,
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})

# Ebeneneigenschaften
App.Do( Environment, 'LayerProperties', {
'General': {
'Opacity': None,
'Name': nikname,
'IsVisible': None,
'IsTransparencyLocked': None,
'LinkSet': None,
'UseHighlight': None,
'PaletteHighlightColor': None,
'GroupLink': None,
'BlendMode': None
},
'BlendRanges': None,
'Path': (0,0,[],False),
'ArtMediaTexture': None,
'BrightnessContrast': None,
'ChannelMixer': None,
'ColorBalance': None,
'CurveParams': None,
'HSL': None,
'Threshold': None,
'Levels': None,
'Posterize': None,
'Overlay': None,
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Silent,
'AutoActionMode': App.Constants.AutoActionMode.Default,
'Version': ((9,0,1),1)
}
})

# ZwischenablageLöschen
App.Do( Environment, 'EmptyClipboard', {
'GeneralSettings': {
'ExecutionMode': App.Constants.ExecutionMode.Default,
'AutoActionMode': App.Constants.AutoActionMode.Match,
'Version': ((9,0,1),1)
}
})



Regards, Jürgen

[MikeFromMesa]

Actually I used GetString and presented the user with a set of characters to reflect the app they wanted to run. In my case it was "vlp" for ViewPoint, Luminar and PerfectlyClear. The only problem I ran into was when I added PhotoLine to the list as I then had no letter left for PhotoLine. P was taken up for PerfectlyClear and L for Luminar.

I used a simple configuration file to specify the various information - paths to the exes, the type of image to send (tif or jpg), the string to present to the user and so on. I did not want to include any hard-coded information in the script that I did not need to include, so the only thing that ended up being hard-coded was the path to the cornfugraiton file.

[juergen]

Ok, if you use "GetNumber" the user can't input a wrong number. He can use a slider to choose one...
If you place the number into the config file in every line, you have program and number direct linked...
Regards, Jürgen

[MikeFromMesa]

Ok, if you use "GetNumber" the user can't input a wrong number. He can use a slider to choose one...
If you place the number into the config file in every line, you have program and number direct linked...
Regards, Jürgen

It is all a matter of taste, I guess, but I have the script set up so that it terminates (without doing anything) if the user enters an incorrect value. It just seems more logical to me to allow the user to enter the first letter of the app to be called than trying to remember which number corresponds to which exe.

As it is the script only requires the single user entry and the config file takes care of everything else, based on the user defined entries. This allows me to have tifs set up for some apps, jpgs for others, it allows me to handle apps that do not return the same file suffix as was sent to it (as in the case of some apps that will take a "tif", but automatically return a "tiff") and the process of adding another app to the entire system only takes the addition of that entry to the config table to work properly. I set it up for ViewPoint, Luminar and PerfectlyClear, but it took only about 20 seconds for me to add PhotoLine to the config file, and everything worked perfectly after that.

But, like all software, it generally depends upon the individual taste of the person writing the code. I thought seriously about writing a small windowed app to allow the user to select from a group of radio buttons, but then decided that the addition of a C# interface to allow for that was a bit much for a relatively simple python script. And, for me, it was a good opportunity to learn python.

[LeviFiction]

It is indeed all a matter of taste.

Depending on your format for the config file you could do any number of things to allow for choosing an index without the user having to remember for themselves what each index is.

For example:

Let's say I have a config file formatted like so

Name#Path - I chose # as the separator as it's an illegal character in filenames and unlikely to exist as part of a name.

I can import these into Python, then use a simple For loop to assign an index and create the prompt that lists the available software and their index.

Code: Select all

    config = []
    with open("config.txt", 'r') as f:
        for x in f:  #for each line in file
            config.append(x.split('#')) #creates a list separating title from path, appends list as an item in config list
    prompt = ""
    for i,x in enumerate(config):
        prompt = prompt +  str(i) + ' - ' +  x[0] #creates a single text prompt with all softwares listed
    result = App.Do( Environment, 'GetNumber', {'Prompt':prompt, 'MinValue':0, 'MaxValue':len(config)})
    if Result['OKButton']:
        path = config[Result['EnteredNumber']][1]

So this would give a list of the available software options and their index on the number picker dialog. A user just reads through the list and picks the appropriate software.

But as you said, it all depends on taste. I also have no idea if any of that code would even work. xD

[MikeFromMesa]

It is indeed all a matter of taste.

Depending on your format for the config file you could do any number of things to allow for choosing an index without the user having to remember for themselves what each index is.

For example:

Let's say I have a config file formatted like so

Name#Path - I chose # as the separator as it's an illegal character in filenames and unlikely to exist as part of a name.

I can import these into Python, then use a simple For loop to assign an index and create the prompt that lists the available software and their index.

Code: Select all

    config = []
    with open("config.txt", 'r') as f:
        for x in f:  #for each line in file
            config.append(x.split('#')) #creates a list separating title from path, appends list as an item in config list
    prompt = ""
    for i,x in enumerate(config):
        prompt = prompt +  str(i) + ' - ' +  x[0] #creates a single text prompt with all softwares listed
    result = App.Do( Environment, 'GetNumber', {'Prompt':prompt, 'MinValue':0, 'MaxValue':len(config)})
    if Result['OKButton']:
        path = config[Result['EnteredNumber']][1]

So this would give a list of the available software options and their index on the number picker dialog. A user just reads through the list and picks the appropriate software.

But as you said, it all depends on taste. I also have no idea if any of that code would even work. xD

In my case I chose # as the comment character, so I could not use it as a separator. I chose the '^' character as a separator and all of my data entries look like this: name^value1^value2^value3 ... I then read the items in, store them in a dictionary with the name as the key and the values, with the separators, as the data. I then get the index of the app to run and use that to return the appropriate value for each data name.

In my case the config file is a simple text file stored somewhere on the system. The user picks the entry he or she wants for the app and that index is the proper index for all of the values associated with that app.

The code ran to about 400 lines, but that includes the internal comments, blank lines I use to separate blocks of code, and the class and function definitions, so the actual code was not very long. It was an interesting little project and I had some fun using it to learn python as the bulk of my previous experiences had been with high level compiled languages (c, c++, c#, Java, COBOL, Fortran, objective-c, COM and others) and various machine assemblers. Fortunately languages like COBOL and Fortran and not much used anymore as they are not object oriented and the code tends to get a bit nasty if the programs get too long.