Sorry for the long delay (and post)!
Additionally, as I thought about it more, I added the following dropdown to the mockup. Dunno if it would be possible, but it would be handy if Knossos could auto-select the Debug or Fast Debug of the same build number as the mod dependency.
I can do that but recent nightlies only offer Fast Debug builds. Do we hide the Debug option in the case it's not available or should we display it as disabled?
Oh, and ngld.. I'm going to work with qt and see if I can figure out how to actually start building such an interface. Mostly I don't want you to think I'm just posting these and expecting you do just do all the work! 
I'm fairly handy with HTML/CSS, so I'm gonna try and give it a go.
I think the easiest path would be to realize most of the UI in HTML/CSS because the Qt Widgets try to provide a native look&feel and aren't as easy to style as HTML.
I could make a dev build of Knossos which would allow you to directly change the HTML, CSS and JS files. Would that help?
Yes, that would be awesome!
Here you goLastly, I redesigned the "Development" tab based on feedback to make it much easier for developers to have access to the launcher tools the use most often. I'm not quite sure how the Mod Path section would be handled since Knossos does most of that automatically, but that's something mod creators use a lot. I was also considering a Mod Dependency Add/Remove button. These mods are probably not linked to Nebula, so perhaps that will make that section easier. The rest is just copied/duplicate access to what's already in each mod's settings page (normally accessed through the Details page). Take a look.
*snip*
If the user changes the Mod Path, I could move the mod.json file to the new directory. If you had several copies of your mod folder, this would allow you to switch between these copies. I'm not sure if that's very useful, though.
I'm wondering if we should add an additional field "Mod Folders" which would allow you to specify several folders if your mod folders are in more than one folder. The "Mod Dependencies" field is supposed to contain only a list of mods.
All the BTA1_* entries from you example would be in the "Mod Folders" list instead. This would also allow Knossos to automatically pack each folder as a .vp before uploading to Nebula if/when we implement that later.
I agree that editing the mod dependencies should be possible. For every dependency, Knossos needs a mod ID and instead of asking for the mod ID, I'd rather ask the modder to pick from the list of available mods.
Well, he said he's using 3.7.4, which uses the registry on Windows, not fs2_open.ini.
Sorry, I keep forgetting that the SDL2 builds aren't released as stable, yet.
@Joshua: In that case it would be HKEY_LOCAL_MACHINE\Software\Volition\Freespace2\CurrentJoystick in the registry.
Also, the joystick selection has changed a bit since the SDL2 merge since it's now possible to identify joysticks better when using SDL2. If you set the "CurrentJoystickGUID" option in your ini then FSO will use that to determine the correct joystick. You can retrieve this GUID with SDL_JoystickGetGUID. I'll try to add support for this to Knossos when I find the time to implement it.
Thanks for telling me about that. If I want to keep compatibility with the pre-SDL2 builds, would it be possible / make sense to set both CurrentJoystick and CurrentJoystickGUID?
@ngld: First, awesome job fixing and extending Nebula!
Thanks!
The changes you mentioned regarding Knossos UI, I guess it's a rework of the Javascript API, exposing features required by the new UI proposal (which is awesome, @mjn !) ?
Are you aiming at fully separating a mostly Javascript + HTML + CSS display code, and system features (installation an removal of mods...) ?
The JS API is a part of the internal changes but most of the changes are related to additional data I need to store (the new mod settings and additional fields for the mod metadata).
Given the added complexity of the new UI, I'd say it would be time to move away from jQuery and pick a proper framework to handle widgets and the UI state.
This would allow to handle design tasks separately, with mjn only having to care about the main layout and widgets. Much less work for him!
This would also be useful if the mod library in Nebula and in Knossos end up sharing the same appearance and code.
I'm not sure about using React. It feels like overkill because we only have 3 different screens (the mod lists, the details screen and the development screen) with mostly simple interaction (modals and hover effects). The complicated actions (installing, updating, etc.) are handled in Python.
React would make it easier but it would also require me to use a bundler (most likely Webpack), a compiler (Babel) and the minified JS code would probably be much larger than the current ~110KB.
With the currently planned UI it seems more work to add React than to use jQuery.
My personal choice for this would be React + Redux, with a Knossos/Nebula middleware to talk to the required APIs.
I don't think Redux is neccessary because we don't need a centralized state here. Instead of writing middleware or reducers, I'd just use React's this.setState() to update the UI.
Also, to handle all the asynchronous things going on in the new UI (installations, checksums...), it would be super interesting to support Promises/A+ in Knossos API.
The JS API can't support promises (unless I write a wrapper) because the browser interface is too simple to do that. Also, I don't use the API to retrieve data instead I provide the neccessary data whenever I trigger an event to update the UI.
PS: I'm also thinking about rationalising Nebula API, especially regarding the library, so it's more convenient to use in Knossos. So much stuff I didn't know when I started this, since it was my first Symfony project, time to make things right!
It's great that you want to help! Please take a look at my fork because
a lot has changed. I've updated Symfony, scrapped the ACL system and switched back to using Voters and made quite a few changes to the forms (file uploads are now possible!).
The only API that Knossos uses is the repository JSON file which contains the mod metadata and a single endpoint which I added to track mod installations. If you're talking about the API between Nebula and knossos-server (I should really give it a proper name), I've made a few changes to it and it's fine the way it is.
Important changes that are still missing would be a WYSIWYG editor for the mod description, resizing for uploaded images (+ thumbnails), an integrated help guide (
something like this) and translations.
The previous version (0.4.1 iirc) installed correctly, launched correctly, but I was not able to do anything with it (when I click on the button to select my FS2 install, nothing happens)
That bug is fixed in 0.4.3.
The new version installs correctly, but won't launch. I get a fatal error "Failed to execute script _main_"
Can you please check if "%APPDATA%\Knossos\log.txt" exists? If it does, please post its contents here.
- show download speed, download size, estimated time to completion, ability to pause downloads and limit download speed
Download speed: Not sure where
Download size: Will be shown in the install dialog
Estimated time to completion: This is
HARD since several files are downloaded at the same time which often leads to fluctuating download speed. Also, the currently downloading progress and still queued files have to be taken into account. If I implement this, it will most likely only be after 1.0.0.
Ability to pause downloads: Maybe
Limit download speed: Once again, kinda hard since the library I'm using doesn't support this and implementing this myself will cause additional overhead during downloading (more CPU load) which I'd like to avoid.
- ability to discover/add already downloaded mods
This is planned.
- mod details should include rating, news, update changelogs
Not sure about news and changelogs because those could be part of the mod's description.
Ratings are planned.
- link to IRC / real time chat maybe?
Or Discord? I think we can put that as well as a link to the "Getting started" forum on a help page.
