Forums

Well i've been testing playonlinux aggressively for the last 2 days as i wanted to see if i could get my favourite media players (zoomplayer and media player classic-home cinema) from windows running on linux and thankfully i have. So i wanted to give back to the projects that have made it possibly by submitting entries in wine's appdb and submitting feature suggestions to playonlinux.

Unfortunately my feature suggestions have been considered spam and removed and i've been warned about submitting any more and instead i should submit it here. if i was having problems with playonlinux and wanted answers, then i would have definitely come to the forum, but if an application has problems, you submit bug reports. i'm new to bug reporting and was adviced by other applications i've contributed suggestions to that if i had bugs/features to submit, that i should submit them as individual bugs, which was why i sent in 6, when i could have easily compiled them into one. Below is the list.

1) shortcuts with the same name get overwritten (#3770)

2) shortcut tree view list (#3771)

3) install components titles/descriptions (#3772)

4) defaults in configuration/display (#3773)

5) run a .exe file in this virtual drive with debugger button (#3774)

6) view debugger button/menu item (#3775)

DJYoshaBYD, was kind enough to reply to 3 of them, and here are my replies.

> That is simply because that is not how PlayOnLinux is really supposed to work.

* please let me know how an individual would test different versions of an application to see its compatibility on wine without overwriting the main executable filename. wanted to suggest a simple overwrite dialog could have come up and suggested the user change the name.

> If you are doing manual installs, and dont know why you need a specific wine version, or a specific component then you need a lot more than a description, and need to stick to the automated installs. There is more to WIne/PlayOnLinux than what you think. 

* playonlinux doesnt have automated install for every software available on windows, so if its not in the list, people will have to do a manual install, and if they do, then the option to install components has a list with no explanation of what they are. when i first started using playonlinux, i didnt know much about it, but after many hours i've spent exploring the various features of it, i can happily say that i've gotten the hang of it and there will definitely be others like me who will do the same, so why not make their go at it easier. The point of playonlinux is to make wine easier to newbs, at least that what think its there for, and it has for me. Winetricks was made for the same reason and gives descriptions for components and i was suggesting playonlinux does the same.

> Yes, there is a way to check the logs from the last run, without running the application, but how are you going to get accurate, current logs without running the app? 

* you are correct. i had skimmed through the menu before and must have missed it. i was only suggesting easier access to it, like possibly a toolbar button or possibly the right-click on the shortcut.

I apologize for my ignorance to the system of playonlinux's bug reporting, but my only intent is to help the FOSS community and hopefully my little contributions can make someone who comes after me have an easier experience with the software i contribute to.

I leave you with three additional features i was intending to submit to the bug system.

1) backup container, even ones with no shortcuts - i manually configure playonlinux from the configuration dialog and i wanted to create a container of just preconfigured components which i could backup and reuse to test it with various types of softwares or to test different versions of the same software. at the moment a shortcut is needed in order to backup the container, even though you can have multiple shortcuts that still only backup the same container. so maybe the playonlinux vault could have the option to backup containers in addition to shortcut-linked containers.

2) always debug - option to always run playonlinux in debug mode.

3) intuitive shortcut names - most executables have internal details of the actual name of the application, so maybe that could be present to the user rather than the filename.exe.

Thank you for your time and keep up the great work.

Hi,

Unfortunately my feature suggestions have been considered spam and removed and i've been warned about submitting any more and instead i should submit it here.

I reopened and commented most of them, as I think they denote genuine needs, or at very least are worth discussing. I don't mind feature suggestions even when they're unlikely to be implemented, or implemented soon.

i'm new to bug reporting and was adviced by other applications i've contributed suggestions to that if i had bugs/features to submit, that i should submit them as individual bugs, which was why i sent in 6, when i could have easily compiled them into one.

It's definitely better to submit different concerns separately, so they can be better tracked. Mixing concerns tends to turn bug tracker history into a forum discussion and lose focus.

>1) backup container, even ones with no shortcuts

That looks like a regression, I think this extension once had a checkbox to switch between shortcuts view and virtual drives view. This component is contributed, so that'd be something to ask the author.

2) always debug - option to always run playonlinux in debug mode.

I franky see no real use case for that, and this is the kind of feature users may enable by accident and get annoyed by for ages because they don't understand what's going on. They're ergonomical solutions (like, have a checkbox for this feature in the debugger window), but still.

3) intuitive shortcut names - most executables have internal details of the actual name of the application, so maybe that could be present to the user rather than the filename.exe.

If you can provide code that [b]always[/b] does better suggestions that current solution, we're interested.

While all this is suggestion to improve the ergonomy for the manual use of PlayOnLinux, which exists and is ok to use, from my point of view ultimately to ease the use of PlayOnLinux more scripts should be contributed (and maintained).

Edité par petch

Word. The main reason I closed them, as they were literally just small blurbs, and back-to-back, which isnt really bad, but they didnt really offer too much on half of them, so I closed those ones, and yeah, I did add warnings. Its not that they were bad, but more detail for sure would rock. I apologize if it seemed rash. You wouldnt believe the things we see on bug reports sometimes. :)

I do firmly believe that the scripts are the heart of these installs and this program. It really does give a leg-up over a lot of alternatives.

Yesterday was a long day. haha.

That looks like a regression, I think this extension once had a checkbox to switch between shortcuts view and virtual drives view. This component is contributed, so that'd be something to ask the author.

so how can i contact him to send this feedback

I franky see no real use case for that, and this is the kind of feature users may enable by accident and get annoyed by for ages because they don't understand what's going on. They're ergonomical solutions (like, have a checkbox for this feature in the debugger window), but still.

well the harder you make it for newbs to find the feature, the more difficult it will be for them to mess things up, but still make it accessible non-newbs to use it. :)

If you can provide code that [b]always[/b] does better suggestions that current solution, we're interested.

Unfortunately i'm not a coder, but if you want something that will always do better than showing the exe filename, i'd bet the folder the exe is in (or possibly the folder above it) would normally do the trick. so maybe the exe name and the folder name can be displayed.

Coding wise, i did some googling and  i see that the windows api has functions to do that - < http://stackoverflow.com/a/14829808 >. This code might also assist - < http://www.codeproject.com/Articles/36928/Parse-a-PE-EXE-DLL-OCX-Files-and-New-Dependency-Wa >. If you want a executable file that can extract the info, i think pestudio can do it < http://www.winitor.com/ >.

so how can i contact him to send this feedback

http://en.congelli.eu/contact.html

Unfortunately i'm not a coder,

Unfortunately, thats what is making it hard to understand.

It is simpler to have a checkbox, then to have it on all of the time. Especially because wine throws all sorts of stuff out, and if one is not the wiser, they look like errors, and bug reports get filed simply because of confusion. Hence:

well the harder you make it for newbs to find the feature, the more difficult it will be for them to mess things up, but still make it accessible non-newbs to use it.

Is exactly right. :)

As far as the .EXE stuff, the function that takes care of that (in a manual install) will scan the WHOLE virtual drive, and list all shortcuts, as well as give you the option to search for one. In automated installs, however, they are hard-coded into the script for ease. Now, these do break from time to time, but for the most part, they work well, and if the shortcut fails, you can always click a button to create one manually, and then report it to us so that we can make the corrections.

Coding wise, i did some googling and i see that the windows api has functions to do that - < http://stackoverflow.com/a/14829808 >. This code might also assist - < http://www.codeproject.com/Articles/36928/Parse-a-PE-EXE-DLL-OCX-Files-and-New-Dependency-Wa >. If you want a executable file that can extract the info, i think pestudio can do it < http://www.winitor.com/ >.

That isnt really the problem. If a user installs World of Warcraft, and they got THAT far on a manual install, and cant tell what their .exe is to start the game, with all of them listed on the screen, well, then there other issues besides computer ones. haha.

Again, these are in manual installs. And its really straightforward. Very few computer users DONT know what a .exe file is.

Displaying the folder name may even be worse alongside it, simply because now the USER has to parse (with their brains) the folder AND the .exe.

All .exe's that are listed when you do that are only in that virtual drive, so it wont pick up anything that the user did not install. Im not sure what good that would do, by showing something other than the .exe. Especially if the user now has to figure out if its a .bat, .msi, .exe, or any other installer. Just my .2

Well, suggesting install directory name as shortcut name is not a bad idea, but it can break easily (simple case: there's more than one .exe in the directory, say the game itself, the setup program, and an extension... you get the idea: the same name will be suggested for the three, the heuristic is rather weak in this case).
That's why I won't accept anything but code: it's easy to come up with ideas, but most of the work is getting everything right (often requires lots of experimentation, when it comes to heuristics like this).

Edité par petch

It is simpler to have a checkbox, then to have it on all of the time.

Yes i was suggesting something like that in the configuration, possibly a checkbox under 'debug flags', or to make it harder to find, on the miscellaneous tab.

That isnt really the problem. If a user installs World of Warcraft, and they got THAT far on a manual install, and cant tell what their .exe is to start the game, with all of them listed on the screen, well, then there other issues besides computer ones. haha.

I guess i should clarify a bit. I'm not suggesting the exe name be replaced on the 'please choose a file for PlayOnLinux to make a shortcut' dialog. I'm suggest it show the folder name and exe name on the 'please choose a shortcut name for ***.exe' dialog. The point here is to make it easier for the user to name the shortcut, and many times the folder the exe is in is the full name, if its not, then they just have to delete those characters.

Well, suggesting install directory name as shortcut name is not a bad idea, but it can break easily ... That's why I won't accept anything but code: it's easy to come up with ideas, but most of the work is getting everything right.

I was suggesting listing both (folder and filename) and i do code in php, so i will provide some logic code, which i hope you can convert over whatever playonlinux is programmed in.

Check you bug reports that you filed. The folder/filename thing isnt going to happen, as it will interfere with low-level functions in POL. I dont really know how showing a folder and file name will help someone name it. You can always rename them after in POL.

and many times the folder the exe is in is the full name, if its not, then they just have to delete those characters.

If Im not mistaken, its verbose in its path for a reason.

I didnt say that last two. That was petch.

I was suggesting listing both (folder and filename) and i do code in php, so i will provide some logic code, which i hope you can convert over whatever playonlinux is programmed in.

In this case it's Bash code:
https://github.com/PlayOnLinux/POL-POM-4/blob/master/lib/setupwindow.lib#L727

Unfortunately i dont know bash code so wouldnt be able to supply that. I did some thinking about it and here are my thoughts on how it can be implemented. I have done testing of this logic according to 60 executable files i had in my start menu on my windows partition and it had a success rate of 95%.

1) FLN = executable filename without extension and FLP = its path
2) split FLP into an array and eliminate the drive letter and unnecessary folders. example - 'Program Files'
3) if FLN is camelcase, loop through the FLP array and see if any of the directories are equal to its name without the spaces, and use the entry which matches or else add spaces to the filename.
examples: CodecTweakTool.exe, ImageReady.exe, VirtualDubMod.exe, WindowsLiveWriter.exe, YahooMessenger.exe, GeoSetter.exe, CCleaner.exe, DirLister.exe, mp3DirectCut.exe, AoAAudioExtractor.exe
4) loop through the FLP array and compare each value against a regular expression version of FLN, assuming its an abbreviation of the real programs name (entries in FLP array that were fewer characters to FLN's length should be ignored). regexp ex - FLN=www.exe to regexp=/.*w.*w.*w.*/i
examples: C:\Program Files\HTTPSniffer\HTTP.exe, E:\Program Files\FileZilla FTP Client\filezilla.exe, C:\Program Files\Mozilla Thunderbird\thunderbird.exe, C:\Program Files\K-Lite Codec Pack\Media Player Classic\mplayerc.exe
5) if no results are found, attempt to eliminate parts of FLN that can be safely removed and do the same regular expression look without FLP array. regexp ex - /(-gui|client)$/
examples: E:\Program Files\UltraVPN\bin\openvpn-gui.exe, E:\Program Files\BulletProof FTP\bpftpclient.exe
6) some common regexp list for the full name and path of the file can be used to convert it
example: /acrobat (\d\.\d)\\\reader\\\acrord32.exe/ -> C:\Program Files\Adobe\Acrobat 7.0\Reader\AcroRd32.exe
example: /jre(\d+)\bin\\\javaw?\.exe/ -> C:\Program Files\Java\jre6\bin\javaw.exe
example: /google\\\chrome\\\application\\\chrome\.exe/ -> C:\Documents and Settings\philipz\Local Settings\Application Data\Google\Chrome\Application\chrome.exe
example: /nero (\d+)\\\Core\\\nero.exe/ -> C:\Program Files\Nero\Nero 7\Core\nero.exe
7) some commonly known EXEs that can be determined can be automatically switched.
examples: winword.exe, excel.exe
8) if all else fails, display the same FLN which would have been displayed previously

Alternatively you could query online filename database sites like runscanner.net, fileinspect.com, whatsrunning.net and processlibrary.com.

It could also be worth analysing the .lnk files that installers create in users/Public/Start Menu and users/$LOGNAME/Start Menu, that's what I do when writing new scripts.
I use lp64 (http://tzworks.net/prototype_page.php?proto_id=11) for that, but given its license we can't use it easily in PoL, we'd need a similar (possibly much simpler) tool

analyze_menus:

#!/bin/bash
# Required: lp64

PREFIX="$1"
RELATIVEPATH="$2"
if [ -z "$PREFIX" ]; then
    echo "Usage: $0 <prefixname> [<relative program path>]"
    echo "relative program path: unix path from drive C root"
    echo "    (eg. 'Program Files/GOG.com/Lure of Temptress/')"
    exit 1
fi

WINEPREFIX="$HOME/.PlayOnLinux/wineprefix/$PREFIX"
if [ ! -d "$WINEPREFIX" ]; then
    echo "Prefix \`$PREFIX' does not exist."
    exit 1
fi

if [ -d "$WINEPREFIX/drive_c/users/Public/Start Menu" ]; then
    MENUNAME='Start Menu'
elif [ -d "$WINEPREFIX/drive_c/users/Public/Menu Démarrer" ]; then
    MENUNAME='Menu Démarrer'
else
    echo "Could not find global menu data"
    exit 1
fi

for user in "Public" "`id -un`"; do
    cd "$WINEPREFIX/drive_c/users/$user/$MENUNAME" &&
    find . -type f -a -name '*.lnk' -print| \
    while read lnkname; do
        LABEL="${lnkname##*/}"
        LABEL="${LABEL%.lnk}"
        IFS='' LP_OUT="$(lp64 $lnkname)"
        BIN="$(echo $LP_OUT|perl -ne 'chomp; if(/^ID List:\s*(.*)/) { print $1 }')"
        BIN="${BIN//\\//}"
        BIN="${BIN#*drive_c/}"
        [ -n "$RELATIVEPATH" ] && BIN="${BIN#$RELATIVEPATH}"
        ARGS="$(echo $LP_OUT|perl -ne 'chomp; if(/^cmdline args:\s*(.*)/) { print $1 }')"
        echo -e "        * $LABEL\t[\"$BIN\" $ARGS]"
    done
done

As you may see it may still require some work, as "Menu Démarrer" is a hack because my locale is french and sometimes that's what is created by Wine

Edité par petch

Yes if you can find the .lnk that links to the same exe, you can easily use its filename. But if the person decides in the installer not to install the start menu folder, then this would fail.