Rethink app launchers

[Infernio]

We need to rethink app launchers. Shortcuts make no sense on non-Windows systems, plus they keep confusing users - remember how many people have trouble getting a shortcut for xEdit cleaning to work. On top of all that:

• syscalls on boot
• will make profiles more complex - #250
• app_buttons.py is very ugly

Instead, I think a more usable solution is using our settings dialog to implement a page where you can add custom launchers (along with some default ones that we auto-detect, most likely). Or a new tab? Not sure yet. We can then even generalize concepts like the special links that the BOSS launcher has by allowing users to add right click options that will enable or disable custom CLI flags. And a toggle on each link to allow suspending Lock Load Order while that app is running, etc.

Ref #178, #250

[Infernio]

Launching LOOT on Linux now opens the /opt/loot/LOOT file in my browser to let me download it :sweat_smile:

Edit: fixed in af58c76d1a9002f852ec79dc943862367dffa78f, but not sure this is the right way to go - for one, how do we determine if an executable is native or meant to run through wine? Maybe just rely on the .exe extension?

[BGazotti]

Launching LOOT on Linux now opens the /opt/loot/LOOT file in my browser to let me download it 😅

Edit: fixed in af58c76, but not sure this is the right way to go - for one, how do we determine if an executable is native or meant to run through wine? Maybe just rely on the .exe extension?

We could just do that; alternatively, we could check the file's "magic" bytes to see that type of file it is. Running file from a shell will give you a short textual description we could read and then determine what to do with it. Not sure how we feel about running external commands, but it sure is easier than doing the magic-figuring-out ourselves. For example, file skse64_loader.exe gives you skse64_loader.exe: PE32+ executable (console) x86-64, for MS Windows, 7 sections. We could check that string for "windows" or "PE" to determine it should be run with Wine.

Calling xdg-open may also be a valid option for most orthodox Linux systems, as long as they're configured properly - but one must never assume that, right?

[Infernio]

xdg-open is what we do as a fallback if it's not an executable. That won't work properly with proton though, unless we pass the right WINEPREFIX, which sounds like tons of work (compared to letting protontricks figure that out). Checking file might be an option, but I'm leaning towards just using the extension, we can always replace that with file or something else later if it turns out to be necessary.

[Utumno]

4d74aaec062fdbaff498662496f11a49ccf431a3

TODOs:

• UI
  • [ ] add the app icon on the left of the name
  • [x] make path expandable
  • [x] make the drop down list expandable
  • [x] add a file open icon on the right of the path
  • [x] make the predefined launchers non editable apart from the path
  • [x] make the predefined launchers non removable
  • [ ] replace the remove button with a reset button
  • [x] remove the <New> item
  • [x] replace it with a New button that makes the read-only UI for (predefined) launchers editable (and replaces Reset/Save with Cancel/Add)
  • [ ] display added launchers with a [Custom] prefix
  • [ ] offer buttons to hide/display only predefined/custom/hidden/existing etc launchers and sort by those types
  • [ ] after dust settles add different colors/formatting
  • [ ] absorb the Hide/Display status bar settings page in here (Hidden checkbox)

Backend:

• [ ] settings[launchers] =[{'launcher_path': ..., 'cli_args': ...}, ...]
  • [ ] what is the launchers key? Should we go for a nested dict platform/launchers,... or the opposite? On loading say on linux does not make much sense to fallback to the paths the user stored in settings while running on windows - import from another platform?
• [ ] Implement reading from settings per platform - we keep reading from App/Ini as usual
• [ ] If first time this runs warn user that App folder will be deprecated (if they have shortcuts) and same for the ini (if they use it to define launchers paths)
  • [ ] may need refactoring in warnings - #353 related
• [ ] once the launchers dict in settings is initialized we keep using that (we never reread the ini and App folder - no backwards compat, users reverting to previous versions will loose their settings (well those will remain in settings - good, but needs measuring twice) - no big harm done why would anyone want to revert ? :P
• [ ] on boot we read the hardcoded ones as we do now and instead of reading the ini we read the values from settings for path/args etc (...) - the ini reading code should remain there however for a release cycle

That's the idea @BGazotti - if you could implement the UI side I could have a try at the backend - from the next year onwards : P that's solid 314

[Infernio]

Fixing the tiny path field should just need an item_expand=True thrown in. Looks like a VLayout containing an HLayout, so try adding an item_expand=True to the HLayout.

[Utumno]

Well it was weight actually 8c1a7542675410da5114fcfca3794cce6050a04e - @BGazotti this is the tip of the branch you can base yours on that one - it contains the code from https://github.com/BGazotti/wrye-bash/commits/313-launchers-menu/

[lojack5]

I'll be home in a few days, so for now just a few points if anyone works on the bullets Utumno pointed out:

• [x] the button on the path selection button and path textbox can have most of the heavy lifting (and gui niceness like icon on the button) handled by FilePickerCtrl. Of course, we'dd need to wrap that in gui.
  • [ ] For icons on the list items, we'll need to swap to a ListCtrl instead of ListBox but otherwise not too hard.

[Utumno]

Thanks @lojack5 - @BGazotti has made some improvements on his fork that I am in the process of merging with yours - be aware that I will force push in 570-launchers so make sure to rebase

[Utumno]

The important thing now is to fish the launcher icon from the launcher path (with a suitable platform/wx fallback). I will start looking at the backend on my end

[Metallicow]

Well... about * make the predefined launchers non editable apart from the path ... Thats kind of impossible. LOL even if you are the refurb type and work with all 1001+ flavors of linux , ... not keeping a "dictionary"/hashtable for the numerous curves you would encounter would just be dumb for most simple users, plus it completely overcomplicates the thing. Plus you have the exe types where the namespace matters to the end result, so um yeah... mod it all to hell... Rename to "world of waldocraft".exe or symbolik link and yeah whatever. Linux systems also require a shit ton more system privilages, and as a gamer, rather than a modded BAIN user, most folks are going to look at us bunch like a bunch of freaks. We are superheros basically,... most just folks just don't understand our powers yet...

... while I still have a few ideas left as to how to deal with all this, the answer just isn't that simple. On the otherhand you could do similar to our project and implement the curve form as a machine component that would never change(who knows how many of you are qualified to do that haha), ... on the other hand a few supporting folks in Embroidermodder project where told to explicitly NOT port the library of formats to any other language other than c/c++ for various reasons some of which resulted in some of us telling all the others they would probably end up in the hospital or worse because they are noobs and don't understand idioms(LIKELY the end of the world with such dynamic formats written in python that embroiderpy did, that 99.9% of people dont understand). Like one of the others, I made a framework function that works with all my classes written in python(I didn't port the format, just made a curve framework for SourceCoder), tho this is program exclusive on almost every level as far as the curve goes. There simply isn't an easy way to discuss or go about it all. We need to just work on getting our database of curves(trees) all working together and try to create a small framework file for it.

As far as the shiny icons go, I have numerous solutions, all of which have presented their own issues in various GUI projects, so to that end I hope for the best, but am not expecting anyone to understand rocket science even at the very basic level. +1up

Good luck all.

[Metallicow]

NOTE: I have written a small framework function that worked with "PortableApps.com" 'format' tahat upon startup converts all that shit paths/curves on your thumbdrive to launchable MenuItem(s) with Menus(and SubMenu(s)) properly structured right at the startup of the program(yours, not theirs LOL). This type of approach takes a lot of testing as yes you have to physically inject/unplug the damned bird and retest it 1001+ times, but such is the nature of refurb/medic types. Some of us work with more than one system,... this may be an tasty option for those, but don't get overwelmed in the sea of flavors of linux you will undoubtably drown in.

[Metallicow]

Effectively in the end if you do go the dictionary/hashtable way you will end up with a modifiable 'super file' of curves that COULD be used as commands on a "working machine", such as a CNC.

... thus makes this point moot unless used locally. Everything is a curve(LOL).

• display added launchers with a [Custom] prefix

ListCtrl instead of ListBox. Yes, but a ListCtrl is way more complicated. I've spent years trying to rip Andrea's python port of AUI apart and stick it into manageable portions, tho it is a behemoth of options that is not easy to ingest/consume as apparently one of the original authors fell off the face of the planet and that is what we are left with. QT has its fair share of bugs too, so don't get your hopes too high on a "works with everything" solution any time soon besides recoding it from the ground up(plus then porting to c/c++).

The only way to keep setting reverse compatible after you "initially initiate" a setting is to write out the settings on "close" of the program in 2 different ways. For example, a settings.ini(format) and a settings.pkl You will have problems if you for example run WryeBash on Py2 with wx2.8 on the same thumbdrive after running it on Py3.11+ with wx9999 for the fact that the pickle protocol is not "reverse", tho it can be done. Better than you stick your thumbdrive in and it all go KABOOM. haha LOL ... So if one FAILS, resort to the other, Ex: ini, pkl or pkl, ini

With launchers the best thing to do is work on it small bits at a time. Don't devote yourself to paths/curves, just try to take in what the people want and consider the sanity of their requests and if it may work for you also.

python zen

If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.