Forum > Showoff - what you are working on

[SHOWOFF] What Are You Working On

<< < (360/371) > >>

iindigo:
Started working on improving Noggit's behavior in the absence of a config file (e.g. first run). Right now, if it can't find WoW or your WoW install is the wrong version, it just crashes and you have to open its log file where it only gives you a vague error about not being able to load fonts. This is nonintuitive (nobody would guess the problem is it not finding the game) and frustrating behavior.

After my modifications it instead displays an error dialog and then lets you select the location of your installation.

[media:7b2uor0u]https://d17oy1vhnax1f7.cloudfront.net/items/2e2p3K2H0u3A0A3R2W3j/dialog.mp4[/media:7b2uor0u]

Right now I've only got it implemented on macOS, but implementing it under Windows should be pretty easy since Noggit already links against winapi. I intend to get it working under Linux is well, probably with GTK+ (unless Linux users have a better suggestion of course).

It'll write the path you choose to a newly made config file (if it doesn't exist already) located where you'd expect to find config files on your platform (beside the EXE file on Windows, ~/Library/Application Support/Noggit/ on macOS, and ~/.config/Noggit/ on Linux).

Amaroth:
Finally someone realized that current unfoolproof way of config usage is absolutely terrible. Making application work even with missing  at end of path, making it write comprehensive error on error and in optimal case, making it able to ask user for new directory as current one seems to be incorrect, dafuq is that complicated about this? This should have been implemented years ago, its barely a couple of rows of code, at least some of this stuff definitely is.

schlumpf:

--- Quote from: "Amaroth" ---Finally someone realized that current unfoolproof way of config usage is absolutely terrible. Making application work even with missing  at end of path, making it write comprehensive error on error and in optimal case, making it able to ask user for new directory as current one seems to be incorrect, dafuq is that complicated about this? This should have been implemented years ago, its barely a couple of rows of code, at least some of this stuff definitely is.
--- End quote ---

I understand it is annoying and I have been trying to make it less annoying some times in the past (especially things like missing fonts == bad path), but people have been working against. *shrug*

The reason this has not been implemented years ago is that as iindigo said his solution is platform dependent. This is the case since we can't load those damn fonts and textures and thus can't use our normal UI. I have been and will be seeing platform dependent things negatively. The Qt branch already has platform independent UI, and -- drumroll -- has such an error message and dialog to choose the right path.

iindigo:

--- Quote from: "schlumpf" ---
--- Quote from: "Amaroth" ---Finally someone realized that current unfoolproof way of config usage is absolutely terrible. Making application work even with missing  at end of path, making it write comprehensive error on error and in optimal case, making it able to ask user for new directory as current one seems to be incorrect, dafuq is that complicated about this? This should have been implemented years ago, its barely a couple of rows of code, at least some of this stuff definitely is.
--- End quote ---

I understand it is annoying and I have been trying to make it less annoying some times in the past (especially things like missing fonts == bad path), but people have been working against. *shrug*

The reason this has not been implemented years ago is that as iindigo said his solution is platform dependent. This is the case since we can't load those damn fonts and textures and thus can't use our normal UI. I have been and will be seeing platform dependent things negatively. The Qt branch already has platform independent UI, and -- drumroll -- has such an error message and dialog to choose the right path.
--- End quote ---


Hope I'm not brushing anybody the wrong way by working on the SDL branch. I plan to work on the Qt branch too, but the Qt branch isn't really usable yet and I'm not equipped with the skills needed to make it more usable — my expertise lies in more traditional UI oriented desktop software, not reading proprietary binary files and drawing things in OpenGL. I can figure these things out (and have just a little bit - I'm working on an M2 tool on the side)but the ramp up time is not going to be short. I figured smoothing out rough edges on NSDL before working on NQt's UI might be a more productive use of my energy.

Skarn:
The current development is happening on SDL branch only, so I think you are doing it right.

Navigation

[0] Message Index

[#] Next page

[*] Previous page