biltzerpos / enamel Goto Github PK

The BrailleCell constructor takes 8 radio buttons as arguments, which can be time consuming if you have multiple braille cells.

I believe the constructor can be redone so that we pass 1 argument instead: a binary string. Each character of the binary string can represent the status of the pin (raised or unraised).

For example, the constructor currently looks like this:

BrailleCell(JRadioButton radio1x1, JRadioButton radio1x2, JRadioButton radio2x1, JRadioButton radio2x2, JRadioButton radio3x1, JRadioButton radio3x2, JRadioButton radio4x1, JRadioButton radio4x2)

Whereas it could look like this:

BrailleCell("00000000")

The class is just too long a lot of code to go through. Could be divided into 2-3 classes working together.

As of right now, there is only one scenario that will run in this code. It would be useful if the user had the ability to choose other scenarios to run through the GUI as it would be easier. It would also be good to have the function for GUI to connect multiple scenarios to together and run one after another.

When I was implementing the playAudio() in our own Player app, I originally used the Clip Library for audio. I noticed that Clip only allows very short audio files. Any audio that is longer than 5 to 10 seconds was not supported with Clip.

Hence I believe that Clip is not good for the scope of this project, instead SourceDataLine should be used in order to support longer audio files.

The SoundPlayer has mandatory requirement for scenario.txt file. The first two lines must follow format similar to
Cells 2
Button 3
The class can have a new method that allows few mistakes. For example if file has Cells2 Button3 without space, it can check for presence of number and allow the program to run.

There are some methods, specifically the Perform Action that could be extracted into separate methods. Instead of having multiple if statements in one method, each extracted method would have an action associated with it that could make it easier to understand the code, enhance structure and make it easier to change functionality if necessary.

Expected first two lines for scenario files:
Cell num1
Button num2

Any other words can be entered at the start, i.e:

FakeCell num1
NotARealButton num2

And it would be valid.

Some methods such as performAction are too long and can be refactored into multiple methods. Each if statement performs something different so each of these actions can be a separate method on its own with a different name. This enhances readability and makes it easily understandable.

Not really an issue!

Code have all the methods in one class. It does not look like object oriented programming. The Code should be more structured and organized. It is easier to understand code with more than one class.

As of now, there is no limit on the amount of buttons or cells you can specify for the file format. This means when you run it, the Player will create a Simulator with that many buttons or cells. The problem is that depending on the monitor size, there is a point where it becomes impossible to click the buttons or see the cells. For example, if I specify 100 buttons in the file, I can only see and click on about 47 buttons on the Simulator even though the simulator is full-screen.

Hi,

Just a heads up, I took a look at the code yesterday with the device, and I'm noticing an issue with the way I used the PI4J library to access the hardware gpio pins on the Raspberry Pi. Just in case the project decides to continue using Java, Raspberry Pi, and the gpio pins. It's a small thing.

There's a line of code,
GpioController gpio = GpioFactory.getInstance();

in TactilePlayer.java and SCALP.java.

I thought the normal behaviour should be like a normal Singleton judging by the format, where if it was already instantiated, it would just return the existing instance. However, it seems to throw a "fatal error" due to the repeated calls to GpioFactory.getInstance().

I had an idea, but I didn't want to commit it as I'm no longer working on the project, so I'll just leave the idea of the modified versions here.

I just created a GpioControllerContainer class that contains only
"final GpioController gpio = GpioFactory.getInstance();"

Any class that needs GpioController gpio can create a new instance of GpioControllerContainer to get that reference.

Any future calls other than the first call to the class to get the reference to gpio do not throw the error; I tested it by creating several instances of GpioControllerContainer within the same class.

There probably is a better way, but either way this issue needs to be fixed.

Thank you.

Because of the nature of the player software, any person who implements it will need to be able to manipulate the scenario in an easy and user-friendly way, whether he be a programmer or not. Not having the scenario saved in a DT means that whenver anyone implements the Player APP for any reason they would need to write code to save the scenario in a DT to later be able to manipulate it. In this case it makes more sense for the Player APP itself to have that functionality so that if one ever gets their hands on a pre-made scenario, they are then able to access it in a way that would make editing much easier.

Currently with the PlayerSound class, one must instantiate the PlayerSound object and then call the setScenarioFile(String scenarioFile) in order to begin playing the story.

It would be useful if one could pass the scenarioFile directly into the constructor of PlayerSound so that the story could begin playing immediately upon the object being instantiated, rather then requiring the user to call the setScenarioFile method.

Ability to play the audio files at reduced speed for hard to understand words and phrases. This does not have to be done for the whole audio file but for selected parts and words, and could be turned on or off. There could be an added button to repeat in slowmode, or play the whole audio in slowmode. There could also be a way to control how much slower to play it.