Gui code changes..

[ddurant]

I've been thinking about making an abstract GuiPage (or whatever) base
class and rewriting stuff so that each page has its own subclass and
draws itself. That and having something like an arraylist to hold all
the pages (which is just 2 for now) to make it easier to add new pages
for profile settings or whatever.

Any objections to this?

[Allan Ecker]

Nope-- anything that makes the system more modular and navigable is a plus!

Lately the only thing I've really been thinking about the GUI is, how
am I going to speed it up? I think the threads are the real issue
there, so adding more OOP to the mix probably isn't going to prevent
any performance work.

[ddurant]

Great!

The past week has been all family & work stuff. I'll see if I can put
a dent in this next week..

> > Any objections to this?- Hide quoted text -
>
> - Show quoted text -

[ddurant]

I can get pretty OCD when I'm writing code. I've resisted the urge to
reformat everything so {'s are on their own line (where they
belong!! :) ) but every time I try to attack the GUI code, I find
myself in Configuration.pde, poking at that. So, I've embraced my
madness and attacked Configuration.pde instead.

The short story is that I've prototyped a version where Configuration
now only contains a Hashtable of settings. Load() and Save() no longer
know anything about various settings - Load() just sucks in whatever
happens to be in the config file into the hash table and Save() just
dumps whatever's in the hash table back out to the config.txt file.

Upsides are that this allows the trimming down of the number of
globals and that it lets new code get access to persistant storage
without having to poke at configuration.pde. Though I haven't done
anything like this yet, I think it'll also make it easier to move to
some sort of hierarchacal storage with multiple configs and maybe
rhyming a lot with XML.

Downside is that it's a bit of a wide-spread change and that it's not
quite as easy to use.. EG: a global "string SomeVar" can today just be
accessed and set via it's name from anywhere in the code. With my
changes, you'd have to do something like 'string x = config.String
("SomeVar");' to get it and 'config.Set ("SomeVar", val);' to set it.

> Any objections to this?

Same question as before!

> > - Show quoted text -- Hide quoted text -

[Allan Ecker]

I don't mind alterations that make adding new config variables a
little tougher-- kind of a code-native "do you really mean it" when
adding more settings. It's certainly preferable that the config file
be human-readable so users can see what's going on and if necessary
bypass the GUI entirely, but if we can speed up this terribly slow
code that part will be a lot easier...

So no objections, unless you count my vague worries about not being
able to read the config file by eye...

~Allan

[ddurant]

> So no objections, unless you count my vague worries about not being
> able to read the config file by eye...

I don't think that'll be an issue.. At least for now (until I can
convert you to being an XML fan, which can happen at a later date) the
config will probably look something like...

Object.FeedRate \t 30.0
Object.FlowRate \t 255
Object.LayerHeight \t 0.3
Raft.FeedRate \t 20.0
Raft.FlowRate \t 255
Raft.LayerHeight \t 0.5
Support.FeedRate \t 20.0
Support.FlowRate \t 200
.
.
...though, of course, raft & support aren't implemented yet.

I've also added a defaults.txt that it will read if there is no
config.txt present. That'll let people reset back to the default
config pretty easily (just delete config.txt) and there'll be less
chance of somebody pushing a funky version back to git by mistake.

[ddurant]

Also, I think a lot of GUI performance issues are due to calling
loadFont() in display() in the GUI* classes.. I just reworked that and
it seems a LOT more responsive now.

Beware changing this in your local branch and trying to move it to a
constructor, which is where I wanted to put it, to test it out - that
seems to throw null pointer exceptions, which I think is a Processing
bug. I moved it to load only the first time display() is called which
isn't the most efficient way to do it but it's not too bad..