Questions & Suggestions

[DirtDiglett]

Hey Ditti4,

Great project, I'm hyper excited for this, but I have some questions and some suggestions.

Handling Skins updates, etc.

I had a look through and the way you're handling skins information and updating is quite interesting. That XML file is a local copy, but that means to add skins to this list or adjust URLs and such would require a redownload of the program right? If that's the case I think it really should be replaced with a remote manifest that can be updated and have the clients periodically check for that.

Perhaps we could change it up so that the onus of the information is on the skin providers, something like having a manifest that just contains URLs to each skin's individual info.json that the author of the skin maintains (and maybe fallback to the current method if there isn't one). I'd have no problem with including a json file in my skin and I am sure Inhibitor would happily do it to Air, not sure on Metro though.

This would open the way for more features such as compatability checking, a skin developer includes what Steam version it was built for, and then as versions come out and break the skin the program can show users.

Something like:

info.json

{
    "themedata": {
        "title": "Pressure for Steam",
        "author": "Dirt Diglett",
        "authorURL": "http://steamcommunity.com/id/DirtDiglett",
        "description": "Pressure is a blend of beauty and function. Every part of Steam has been carefully considered and reworked to create the most fluid and wonderful experience possible.",
        "website": "http://www.hydra.tf/pressure",
        "steamgroup": "http://steamcommunity.com/groups/pressureskin",
        "previewImage": "http://hydra.tf/pressure/images/pressure.png"


        "meta": {
            "version": "1.0.4",
            "steamversion": "12345678?",
            "changelog": [
                "Change1",
                "Change 2",
                "Change 3",
                "Change 4"
            ]
        }

        "installation": {
            "dependencies": {
                "fonts": {
                    "Roboto": "fonts/roboto.otf",
                    "RobotoBold": "fonts/robotbold.ttf",
                    "Bebas": "fonts/Bebas Neue Bold.otf"
                }
            }

            "removeOnSuccess": ["fonts", "readme.md", ".gitattributes"]
        }

        "configuration": {
            "gridtransparency": {
                "title": "Game Grid Transparency",
                "description": "This will adjust the grid image used for uninstalled games. You can either enable the transparency, or disable it.",
                "fileoverride": 0

                "options": {
                    "Enabled": "include 'includes/tweaks/grid/transparent.styles'",
                    "Disabled": "include 'includes/tweaks/grid/not-transparent.styles'"
                }
            },
            "leftalignedsearch": {
                "title": "Left-Aligned Search",
                "description": "Enabling this tweak will left-align the search box in the Game Details View",
                "fileoverride": [1, "resource/layout/uinavigatorpanel.layout"]

                "options": {
                    "Enabled": "includes/tweaks/uinavigatorpanel_leftaligned.layout",
                    "Disabled": includes/tweaks/uinavigatorpanel_centered.layout"
                }
            }
        }
    }
}

Configuration

Something that would be amazing would be if we could setup a method of configuring skins through the app. There's two main ways that skin devs provide customization currently: File Overrides and config.ini includes. Supporting both would be marvellous. I've included a brief idea for how this could be implemented in an info.json

Visible Progress

Right now when installing skins and such there is little to alert the user to what is happening. Perhaps include an indecisive progress wheel or bar with a bit of a status so it doesn't look frozen. "Downloading Skin: 50%..." or "Downloading Skin: 100kb/5MB" and things like "Installing required fonts..."

GUI

Right now it's very basic, which I understand as it's all WIP. But if I were to throw together a mockup would you be willing to take a look and see if you can do it? I think the GUI needs more information than just a short description, it needs a way to preview a skin before installing (JSON Above includes that). A way to see changes between releases, etc.

[Ditti4]

Hey DirtDiglett!

Sorry for not answering earlier and just adding tags but I had to leave for university and didn't have enough time to give you a detailed answer.

First of, thanks for all your input - that's exactly what I wanted. Secondly, I suck at UI and UX design and I know that so any input on this topic is more than just wanted - it's needed. I'll try to address every point in your comment and state my opinion on it.

Let's start with the easiest one which I more or less addressed already: UI. If you can come up with anything, then please feel free to send me any kind of suggestion. I always hated UI design and went with the "works, so meh" way of designing user interfaces.
So please, send me a mockup and I'll try to implement it.

Visible Progress

This one actually was in the works already but I stopped working on it because the restructuring will take some time so I went ahead and implemented some other features first. But I'll have to restructure the code anyway since it's a pure mess so I'll look into this again. The feature itself isn't too hard to implement anyway.

Configuration

Awesome idea. We'd need to come up with a exact way of doing this, though. Do the config lines get added to the config file or do they replace other lines? But I think this is just some minor problem with this idea, I'll definitely look into this.

Handling Skins updates, etc.

That XML file is a local copy, but that means to add skins to this list or adjust URLs and such would require a redownload of the program right?

Actually that's not correct. The skins.xml isn't compiled into the assembly, it's just a normal file. The "Refresh list" button in the top right corner will be able to download a newer version of this file from this GitHub repository as soon as I set it to public and I remove the // TODO: in this line. But, of course, I'm open to other ways of handling this and I like your idea of just having URLs to manifests right there. One problem though:

.json

From what I've heard, the built-in .NET JSON (de-) serializer … isn't the best and I didn't want to include any external library to keep this project as small as possible but I'll look into the built-in JSON stuff since that's easier to use and maintain than XML.

This would open the way for more features such as compatability checking, a skin developer includes what Steam version it was built for, and then as versions come out and break the skin the program can show users.

The implementation itself should be pretty easy (since you can find the installed version in some of the manifest files in the package directory) and the idea is awesome but how is the installer supposed to determine whether the latest Steam beta update breaks the skin? There are quite a few Steam client updates which don't change the UI elements and, thus, old skins will work just as well as before. If you can come up with any idea on how to handle this, I'd be really thankful.

Thanks again for all your input, it's more than helpful.

[DirtDiglett]

So please, send me a mockup and I'll try to implement it.

This is an idea, thrown together with some laziness to boot (Ordering of skins was just in the order I grabbed the names for example. I'd expect it to be ordered by last update descending). I also need to work on adding other things such as including steam groups, a 'report an issue' button that loads to the git issue tracker for the skin or a contact the dev otherwise, etc.

Awesome idea. We'd need to come up with a exact way of doing this, though. Do the config lines get added to the config file or do they replace other lines? But I think this is just some minor problem with this idea, I'll definitely look into this.

I think this is a discussion that should be had by all the popular skin devs to create a sort of pseudo standard. But from my own experience there's two main ways to handle it and both have their place:

1. Create a config.ini with includes of the customized files, and uncomment them as needed (See my config.ini in pressure).

2. Complete file replacements. This is needed for layout changes rather than style changes.

Both would need to be supported I'd think. And perhaps if all the skin devs can agree on a standard we could do something like standardizing how we organize color variables and then a user could customize colors.

From what I've heard, the built-in .NET JSON (de-) serializer … isn't the best and I didn't want to include any external library to keep this project as small as possible but I'll look into the built-in JSON stuff since that's easier to use and maintain than XML.

JSON would be more appropriate in my opinion, esspecially if it's being sourced externally.

and the idea is awesome but how is the installer supposed to determine whether the latest Steam beta update breaks the skin?

I've had to have a real think on this one, and there's a few solutions that could be explored. From a program perspective it would be possible to 'know' an update breaks functionality if in a diff of the version there is a new control added to a file that exists in the skin. IE: if I specify that pressure works on version X of Steam, and then version Y of Steam comes out with a new control in steamrootdialog.layout, then it's a guarantee the skin will be broken. I am sure i've seen a git repo or something before that follows the diffs between steam client versions, but I'm struggling to find it again.

Alternatively, it could be done by manually checking when new versions come out, then in the manifest mark it as out of date.

[Ditti4]

First of all, thanks for the design concept. I'll definitely look into this the next few days.

I think this is a discussion that should be had by all the popular skin devs

Sure thing, we'd just need to find a place to discuss this. I'm not sure if GitHub is the right place for that, maybe we should use some more-instant way of communicating like IRC or Steam group chat.

I am sure i've seen a git repo or something before that follows the diffs between steam client versions, but I'm struggling to find it again.

You're probably looking for SteamDatabase/SteamTracking

And I had a closer look at it. The program wouldn't only need to track the steamrootdialog.layout but the whole layout directory. Looking at the phone reminder bar for example shows that they might just add new files without modifying the steamrootdialog.layout file. But that shouldn't be too hard to track either thanks to the repository/the modification dates of the individual files.

[DirtDiglett]

And I had a closer look at it. The program wouldn't only need to track the steamrootdialog.layout but the whole layout directory.

You're right, I was using steamrootdialog as an example though. You would only need to monitor whatever layout files that exist in the skin though. For example, if I didn't modify downloadspage.layout then it doesn't need to be watched as it'll always be using the Steam version of the file.

[Ditti4]

I just split the whole issue into multiple smaller issues so they're easier to overview. I hope I didn't forget any of them. If I did miss any, feel free to just add them.