Have you thought about making a UI?

[Kurren123]

If not I can give it a bash if/when I get some free time. If you want to keep this repo as purely a library so that others can add whatever UI they want to it then thats cool with me too.

[JibbSmart]

Hi @Kurren123 ! @Electronicks has proposed plans on a big refactor that would help with implementing GUI, but we don't have plans yet to do it ourselves. If you're up for giving it a go, that'd be great! :D I think it'd be good to get the refactor done first and then see what can be done GUI-wise.

I think to start I'd like to keep the GUI-free branch or repo separate so that we can add new options and features to JSM without having to think too hard about how that affects GUI layout (though of course we would be mindful of not breaking anything). This is also because JSM is fairly lightweight as it is, and it's easy to get more bloated (dependencies and so on) and very hard to slim down later -- and having a GUI will certainly introduce some dependencies. This will probably mean the GUI version lags a little behind the CLI version, but even if it doesn't always have the absolute most recent features of JSM, it'll still be extremely useful.

Long term, I'm sure having a GUI will make JoyShockMapper more accessible to a lot of people. I can see a GUI version of JSM becoming the popular version and I think that'd be awesome.

Before we do this refactor, it'd be great if we can all figure out how we can make it useful for you and whoever else wants to work on GUI stuff. Even if you don't want to commit to getting a UI working (depending on your time), it'd be really useful to have your input so we can get this into a good place so that, as you say, others can add whatever UI they want, too.

[SharlSherif]

@JibbSmart I was thinking of making a UI for the configuration file. That shouldn't be too hard considering I would be editing the txt file but through a UI options menu.

[ghost]

@JibbSmart I was thinking of making a UI for the configuration file. That shouldn't be too hard considering I would be editing the txt file but through a UI options menu.

Please do.

[Kurren123]

I was thinking of making a UI for the configuration file. That shouldn't be too hard considering I would be editing the txt file but through a UI options menu.

I think a UI to allow the user not to have to edit text is definitely the way to go. @JibbSmart, is the text file of a standard format? It looks a bit like ini.

[JibbSmart]

I don't know if it happens to be some kind of standard format. It's mostly lines of: [PROPERTY] = [VALUE] (eg: MIN_GYRO_SENS = 1.0) But some properties can optionally take more than one value (eg: MIN_GYRO_SENS = 1.0 0.5 for different X and Y sensitivity)

Some properties override others. For example, setting GYRO_SENS overrides both MIN_GYRO_SENS and MAX_GYRO_SENS.

It's probably a good idea to have some different "validation groups". Like, the "numeric" where the input is a number between A and B, "selection" where the input is one of a select group of valid strings (eg RIGHT_STICK_MODE can be NO_MOUSE, AIM, FLICK, FLICK_ONLY, ROTATE_ONLY, MOUSE_RING, MOUSE_AREA), "digital" which can be a keyboard key or mouse button.

Things like tap + hold, simultaneous presses, chorded presses + mode shifts, double presses are a little more complicated, but maybe if you start with the simple stuff you can have something useful very quickly?

Also comments (ignored by the parser) start with a '#'.

[Electronicks]

Hi guys. I think drawing inspiration from other mapping software in terms of UI might be very beneficial [insert "copy my homework" meme here]. That would make the application familiar to users of other remappers. Starting with simple is definitely the way to go. It will be easier to brainstorm the more complicated features together once we have something to work with.

[Electronicks]

Also, I meant to say, my refactoring focuses on creating a Model-View-Controller design (well actually there's no "view" part just yet, that's where you come in ;-) ). I am willing to sync up with you to make sure that the refactoring sets you up properly to make use of my classes. When I have time I'll do a quick UML to show you what I'm up to.

[Darthagnon]

Why not join with Ryochan7's DS4Windows and use that for the GUI? DS4Windows is struggling a bit with gyro stuff at the moment.

[Kurren123]

Is this even needed now, seeing as steam are integrating the JSM functionality into steam input?

[Electronicks]

Is this even needed now, seeing as steam are integrating the JSM functionality into steam input?

JSM still offers unique features outside of steam, such as threshold based gyro acceleration. That and many enjoy a configurator outside of the Steam ecosystem.

JSM's original purpose was to showcase the potential of flick stick. It is easy to prototype and experiment new and innovative control schemes in a already existing framework. Someone on the discord invented his own scheme based off mouse area stick mode that was pretty sweet.

[Kurren123]

Has any progress been made towards this? I should have a few spare minutes so I might just give it a bash and keep it in my own repo? Any preference of programming languages? I'm thinking F# with WPF as the UI is pretty, or maybe elm with electron?

[Electronicks]

I'll take the liberty to answer. There has been no progress. Jibb and I were thinking having it as a separate application that would only edit the config files would be appropriate. Pick the language you are the most comfortable with, with cross-platform languages being tiebreakers.

The refactoring is done, so the new header should be helpful to you. Also, I recommend you join the discord, where we have a channel to sync our development.

[Kurren123]

Great. I like the idea of a ui just to edit the config files as it allows more flexibility and different devs can compete.

[Darthagnon]

@Kurren123 DS4Windows recently implemented FlickStick, and has a GUI. Works pretty well (though I still haven't figured out how to "recenter" the gyro properly