DisplayIdentifiers are the minimum GPU/Display
that will allow us to identify whether a profile
will actually work. We look for the same DisplayIdentifiers
or a subset of them to determine whether a profile
will be valid to show. This is different from the data
stored under DisplayTarget, as that is used for detailed
compatibility....
First part of installing an MSTest suite.
Included some config file to read in
for testing the ShortcutRepository and
the ProfileRepository. Had the data
handy so it made sense to save it :)
The IsPossible logic in the ProfileItem incorrectly
uses the ToPathTargetInfo, when a better match is
to look for all the actual displays that are currently
turned on, and then allow all profiles that include
only the displays that are turned on. That involves
1. getting a list of the display devicepaths, and then
2. checking if this profile has all the devicepaths
needed to show the profile. If it does, then it
IsPossible.
The ProfileAdapter and ShortcutAdapters used
by the ImageListView Control unfortunately
have to access the sizes of the bitmaps being
loaded into the respective imagelistviews. I
can't find anyway of stopping the GDI+
from complaining about the Bitmap being
accessed by multiple different threads (as
ImageListView creates one thread per image.
This will be fixed once I move to this being a
WPF application as we'll use a different control.
Profile selection logic was running functions multiple
times which was resulting in a lot of extra delay
while using the DisplayProfileFOrm. These changes
streamline it and make it work a lot faster!
Moved the shortcut running logic from the
main Program into the ShortcutRepository
so that it can be used from the
Shortcut Library UI as well as from the
commandline.
It's marked as WIP because I also moved
the ApplyingChangesForm and accompanying
ApplyTopos/ApplyProfiles logic and I broke
it. It needs refactoring and hopefully
simplifying but I need to work on that next!
Fixed SteamGame so it handles copies, and also
fixed the SteamLibrary so it works properly and
works. HeliosPlus now will run shortcuts and
load the game perfectly!
Pulled out the the library list mgmt from SteamGame
and put it in a new SteamLibrary class. This means I
can replicate the learnings from the ShortcutRepo
amd Profile Repo, and can save separate JSON files
in the future if I so desire.
There is a little bit outstanding to make the SteamGame
Properties to be writeable as well as readable, otherwise
the SteamGame.CopyTo function won't work.
Updated the 'Save To Desktop' button in the
ShortcutLibraryForm to use the CreateShortcut
function in the ShortcutItem, and fixed that so
it now uses the IWshRuntimeLibrary to create
a Windows Script Host that will create the
shortcut.
Did a fix for the SHortcutAdaptor doing exceptions
for showing the form before loading all the graphics
but can't really do much about it without adding
background loading to the main form. This is a lot of
work considering we'll be moving from WinForms
to WPF UI in the future.
Also fixed the 'Do you want to save' prompt detection
logic so that it correctly waits until all the loading has
finished before monitoring for users making changes.
Should stop the form incorrectly suggesting you
should save unless they've really made a change.
The 'change' detection logic now works (mostly)
but it still incorrectly triggers if you change tabs,
even if the settings don't change. Should probably
look at a proper fix.
If a shortcut has Autoname turned on, and if the user
changes the name of the profile, then the shortcut will
be renamed to keep pace with the new profile name.
If autoname is NOT turned on, then the shortcut name
will be kept as is, and the user will need to make any
changes. Please note that HeliosPlus will not make
any changes to any desktop shortcuts saved to the PC.
It will only change the name of the shortcut in the
shortcut library within the App.
Moving to using a ProfileRespository will make it
easier when moving to a WPF style app, and it will
allow some freedom if I want to change the storage
to a database or soemthing different.
Partially completed bitmap work.
Need to implement generic bitmap
resizing to work with small and large
icons, and for different sizes for overlay
bitmap.
Created ShortcutRepository which handles
the loading/saving and lifecycle management
of shortcuts. There can only be one shortcut
repository at a time, hence it's mainly static
methods.
Also started down the path of troubleshooting
the profileIcon overlays. The ToBitmapOverlay
still isn't working properly, so I need to figure
out how it was working originally, and how I
broke it :). Then I need to unbreak it.
Still having issues with the shortcutAdaptor for the
Imagelistviewitem loading. Even though it's based
on the same code as the profileAdaptor it's not
reading the Shortcut bitmap properly. Too tired to
figure out why at the moment, so will be trying again
tomorrow. I expect its something to do with the
different Bitmap format for the two options. May
need to revise that to compare image data.
The logic I chose for the ShortcutForm controls is
really not suited towards distributed logic. I am
going to have to centralise the logic into a single
function that will evaulate when to enable the
save button.
Have created the Shortcut class for use within the
ShortcutLibrary. Next step is modifying the
ShortcutForm to generate a Shortcut so that I
can check the loading and saving is working ok.
I won't concentrate on the ShortcutForm redesign
until this bit is tested.
Created the initial form for the shortcut library
and will now start working on getting the
shortcuts saving to a similar json format as
the display profiles.
Manged to get the ImageListView working directly
from the Bitmap stored in the Profile. This makes
the refresh of the ILV much faster, and makes it way
easier to use it in other UI forms.
Started to work on getting the profile images directly
into the imagelistview rather than doing it via files.
Wasn't a fan of doing icons by file but it was the fastest
way to getting things going. Now going to try and sort
it out so I feel a bit bettter about the code.
Simplified the ApplyingChangingForm size positioning
and made the messages a bit less technical. Also added
in a submessage so that can explain things a bit better
in the future if we need to.
Finished the rework of the DisplayProfilesForm so
that the correct states are kept throughout the
lifecycle of the display profile. It handles changes
to current display profile, and seems to work fine.
Future improvements will be to make the
imagelistview use bitmaps in memory rather than
the images on disk, but that will be done under
another branch.
Display Profile Form now works and handles all the
adding, removing of the display profiles. I've fixed
the comparison (Equals/Contains) for the various
forms so that profile.equals() works well. This fixed
IsActive and IsAvailable as well.
The existing comparisons didn't work well, and my earlier
changes didn't help at all. Decided to recreate them from
Microsoft's latest documentation. Nearly completed it but
need to finish off SurroundTopoly and do proper testing.
The DisplayProfilesForm is mostly working, but it doesnt
cope with invalid profiles yet. This is where the profile
was set in a different configuration of screens, but those
screens have physically or OS level changed, meaning the
profile can't be used. This is handled in the Profile.IsPossible
function, and currently that appears to be broken. It needs
fixing.
Nearly have it working. It now saves, loads and renames
the display profiles. Need to fix up the delete, apply buttons
and make it remove the old ilv images when we rename
profiles.
It seemed to me that it would make more sense to
separate tht two main tasks completely and have them
independent from each other in the program. So I
created a new MainForm that opens up either a
'Setup Display Profiles' or 'Setup Game Shortcuts'
window depending on what the user clicks.
The idea is that Display Profile setup only happens
when the app is first installed, and after that it's just
the game shortcut that gets updated.
Also created a first attempt at a new HeliosPlus Icon.
The icons were way too low res due to the use
of the built-in windows fileextracticon which only
extracts the 32x32 icon. This was making the list
of games look pretty bad. Fixed it now so it extracts
the PNG where possible. Also adjusted the extraction
so that the files are all extracted when the Shortcut form
is loaded.
Also fixed the commandline options that result in
a Steam game being run, so that they now work. Also
fixed up the names of the extracted icons and made the
suggested naming of the shortcut more reliable and
less likely to include usable characters.
The current Icon Library is old and I haven't been
using it properly :). I need to use something different
and the IconExtractor library is still being updated
whereas the IconLib.Unofficial isn't any longer.
Had to adjust both the order and structure of the command
line so that the shortcuts would work, and wouldn't make
people crazy! And adjusted the shortcut creator to make sure
it generated correct shortcuts. Still a lot of edge cases sitting
in there so need some good testing.
Also disabled the CreateShortcut option, as it doesn't really
work with the future combined list of multiple game library
families.
So the main command line options now are:
- SwitchProfile permanent ... = swaps to a new display profile
- SwitchProfile exe ... = temp swaps to profile and runs an exe
- SwitchProfile steam ... = temp swaps to profile and runs a steam game
- SwitchProfile uplay ... = temp swaps to profile and runs a uplay game
- EditProfile ... = goes straight to the edit display profile screen
- <none> = starts up the graphical UI.
Added in a binary VDF reader to find and figure out all
of the Game Icons, Exe locations, Names, Ids and
Install Dirs all from the local file syste,m. It makes the
shortcuts populate within 1 second, rather than the
60 seconds it was taking beforehand. Users should
love the newfound responsiveness.
