clayers - Update 1.1.0

Fri Jul 10 10:16:02 PDT 2015

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 the layer 
is moved/resized out of bounds? Throw or notify? I'm not sure. 
But if you feel that moving and resizing is something that should 
be added, then why not? I want clayers to be appealing to 
everbody ;).

> * Make writing to the window automatically go inside the 
> border.  This is actually why my BoxWin class wraps two ncurses 
> panels: one is a border pane and the other is a text pane so I 
> get trivial line wrapping (I have a small familiy of functions 
> for print modeled after the write() family in stdio).

Yes, as I mentioned before, I've never though about having 
multiple layers act as one like this. But I've also had thoughts 
and problems with writing to a layer. As of now, there is no 
wrapping. But if wrapping is to be implemented, how will it wrap? 
Most of time I'd want the text to wrap back to where the text 
started, but other times I'd just want it to wrap completely and 
start at the beginning. When I experimented with this, I had no 
clear idea of how wrapping should work (plus the fact that when 
wrapping was an issue, I still had borders which made everything 
more complicated).

-

I do appreciate all this feedback you've given me! It really 
helps and encourages, it really does. Many of the points you've 
brought up, I want to implement. However, since this is a one-man 
project it will take time. I don't want to be releasing some 
half-assed functions ;-).

If you want to talk more, make sure to send me an email, 
v at vladde.net !

Yoyo,
vladde