Config page

[h0ru5]

I totally agree with @ds300 its a good way to separate the core from the config and the storage of that config.

So it might be a good step to sharpen the configuration interface before adding a config page.
What needs to be on the config page?

From the config object i could derive so far:

• user settings: target wpm, scale, skin
• modifiers: (probably per language?), max. word length?
• keybindings

Anything else? Drop something from the list?

[ds300]

Sorry it's taken me so long to get around to this post.

I think the most important thing is to get a tabbed options page with keymap and color configuration. Speed modifiers would be easy too. Then we just need a framework for adding checkboxes for all these off-by-default features that keep popping up.

I'm planning an unobtrusive toolbar to display while the reader is open/paused for scale, wpm, and theme, along with play/pause/forward/back type controls.

[ecsplendid]

Font would be good.

Can you add colour-coding punctuation in.

Perhaps an option to load a custom word list "easily comprehend-able words" from a text file and a respective multiplier.

[h0ru5]

So, we basically have 3 sections, right?
controls, visual and reading

I would add a 4th with something like "lab features", so that new, experimental features can be tested by power-users while not disturbing casual users.

Architectural, I would like to move some of the config and helper functions from jetzt.js to an own js-file that is shared between jetzt.js and options.js. (without having to expose them to window)

option pages are simple html pages that can be reached from the extensions menu
and there's a very nice dev guide.

I can provide a prototype, but probably someone css-gifted should beautify it then.
Google wants to provide a standard style - but that issue remained for 5 years already...

If its ok for all, I'll fix something up on a branch in my fork and provide and upstream PR when its daylight-proof. PRs to that branch are of course more than welcome.

[ds300]

Font would be good.

yep. It's a must. Luckilly, this exists, so it should be easy. And we can look into bundling in some high-quality open fonts.

Architectural, I would like to move some of the config and helper functions from jetzt.js to an own js-file that is shared between jetzt.js and options.js. (without having to expose them to window)

That sounds good. I'd actually like to separate most of the pseudo-modules in jeztz.js into different files. The instruction generating and DOM parsing stuff can be separate from the view stuff, and the window controls can be separate too. It would make working on the codebase more pleasurable, especially as it gets bigger.

The only thing keeping this from happening is the bookmarklet, which would need to then load a bunch more files. @peteruithoven, is that much of a problem?

[ds300]

I would add a 4th with something like "lab features", so that new, experimental features can be tested by power-users while not disturbing casual users.

That sounds good too.

[h0ru5]

yes, the bookmarklet was also my concern.

But we can split up the code and have a build-step for the bookmarklet.
what do you think if we add a grunt.js-file that concats and minifies everthing needed for the bookmarklet?
would be better to use minified script anyway if you load it from remote.

[ds300]

I think that's a splendid plan.
On 13 Mar 2014 22:22, "Johannes Hund" notifications@github.com wrote:

yes, the bookmarklet was also my concern.

But we can split up the code and have a build-step for the bookmarklet.
what do you think if we add a grunt.js-file that concats and minifies
everthing needed for the bookmarklet?
would be better to use minified script anyway if you load it from remote.

Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-37594296
.

[peteruithoven]

It's no problem for the bookmarklet to load multiple files, I added general addScript and addStyle functions.
For performance in general it's better to combine files, using Grunt could be a great solution. I'm also using it in another project. When you have the grunt project file it's really easy for people to use it.

Maybe we can even generate the bookmarklet with grunt, so that it doesn't even need to externally load files... (although the fact that loading the files results in a kind of autoupdate is kind of nice right now)

[h0ru5]

@peteruithoven yes, I thought to make it "solid", but that would also mean no updates. But at least we could pack everything into one minified script that the bookmarklet loads.

[h0ru5]

I will send in two PRs the, to keep it a bit more apart:

• one splitting the single jetzt.js into several js-files + gruntfile to "compile" it back into a single file for the bookmarklet
• one for a prototypical options page reusing the config functions and default options, based on the PR above (probably needs some beautification then)

I'll probably have it this weekend.

[ds300]

👍