On Tuesday, 7 July 2015 at 19:09:05 UTC, Wyatt wrote:
Hey! I appreciate the feedback you've given!
Thoughts/ideas/suggestions:
* I think everyone working on this problem ends up making
coordinate types. ~_~;; I definitely recommend defining XCoord
and YCoord as separate types so a common inversion bug is
prevented-- that's saved me a number of times. In my
experience, a straight alias was vexingly insufficient so I use
a struct (though it's still not where I want it).
I don't really understand what you mean by this point, could you
elaborate?
The reason to why I have my own XY struct is mainly because I
often felt like I needed two varaibles, so simply making one felt
like an good idea.
* Make a no-args init that detects terminal dimensions. It's
just nicer that way.
Yes, I totally agree. Before I even released v1.0.0 this was how
the program functioned... until I tested it on OS X. For some
reason, there standard way on POSIX didn't work on OS X (see
https://github.com/vladdeSV/clayers/issues/2). And while I would
want an auto-size to be, it could be hard for developers to make
a game where the window size is relative. (Come to think of it,
it might actually not be.)
But yeah, the dimensions should be auto-set!
* I like the two-corner constructor for ConsoleLayer. I can't
remember why I didn't go that route myself. It may have been
that I was just trying to make it work instead of make it
nice, but there could be something more. I forget.
If I understood you correctly, you are wrong :P. If you mean I
set location (5,0) and size(10,10), it doesn't create a layer
with those two as corners, rather the size adds to the location,
so the rightmost location is at (15, 0 .. 10). A two point corner
system would be very nice though, and it might happen in the
future.
* Relative (percentage-based) dimensions seem like they could
be really handy, but I've never figured out how to make them
feel good. Maybe you can do better.
I've never really tried with relative dimensions, just a hard set
that main window goes to 50, and sidebar starts at 50. If you
would like to expand on feel good that'd be very much
appreciated. (I know my self that the feel often can't be
explained, so no worries if you don't :) )
* Simplify bordered windows. I feel pretty strongly that that
should be abstracted into the ConsoleLayer, honestly. If not
as part of the constructor, then as a property you can set.
Default to nothing and allow setting it to a character (#) or
to a manifest constant that tells it to use unicode box drawing
characters. (Or maybe the property is an enum BORDER {NONE,
UNICODE, CHAR}, and the character is separate? I don't know.)
Oh my, you don't know how much problems I've had with borders.
Buggy borders have been in the code pre-v1 (introduced here:
https://github.com/vladdeSV/clayers/commit/70a0547288aec8008d033c419ad3c387315c2125 and removed here: https://github.com/vladdeSV/clayers/commit/7249b9ed2a00a59a2867dd79861cf4bdee580f64). I've had many thoughts about borders, and to be honest, I didn't quite get how to make border work properly while at the same time make it user friendly. I had problems with writing to the layers as well, where text would overwrite borders and what not.
And if I made a layer 10x10 with a border, could I then write at
(0,0)? Would that be at the border, or the position inside the
border? And then the width/height? Would it return the whole
width, or the width where you could write. And then, what if
someone wants a border that is two characters wide, how would
that work? At the time I had no idea, and with the code I had
then, I felt it was more worth it to get a working engine rather
than fancy borders.
Generally speaking, they did less good than bad.
However, as you mention below, adding a second layer that is
inside the border would actually work, since my code (currently)
allows layers to have sub-layers (which can have more sub-layers,
which in turn can have... you get the idea. That's why sub-layers
still are a maybe).
* A method to get the current layer order is probably worth
considering. And a way to get the priority index for a layer.
And even relative reordering; e.g. layerA.moveAbove(layerB);
I have also considered getting the layer order, but ,how,
exactly? Would I get an ID of some sort? Would I need to set a
custom ID for each layer? What happens if two layers have the
same ID? Relative layers however seem like a nice thing to have,
and I'm pretty sure I could add that with little to no problems
:).
* There's no way to move or resize a layer? Is the the idea to
just destroy and recreate the layer with the new origin/size?
Resize and moving layers are things I've never though about. As
I've developed clayers, I've never once felt the need to move or
resize a layer. It is definitely possible to add these features,
however, things I do not know how to handle, such as if
