digitalmars.D.announce - clayers - Update 1.1.0
- Vladde Nordholm (10/10) Jul 01 2015 So today I released version 1.1.0 of my console rendering library
- Taylor Hillegeist (2/2) Jul 06 2015 Thanks! This is really great. Many people under estimate the
- Wyatt (44/54) Jul 07 2015 I saw this when you first announced it and have been meaning to
- Vladde Nordholm (77/110) Jul 10 2015 I don't really understand what you mean by this point, could you
So today I released version 1.1.0 of my console rendering library clayers! What this new update offers is support for colors, where you can set the text- and background-color! This is thanks to the library 'colorize' (d-colorize on GH). In case you don't know what clayers is (which you most likely don't), it's a console rendering library aimed at console games. It currently supports layer handling and colors. clayers on GitHub: https://github.com/vladdeSV/clayers clayers on dub: http://code.dlang.org/packages/clayers
Jul 01 2015
"Taylor Hillegeist" <taylorh140 gmail.com> Thanks! This is really great. Many people under estimate the usefulness of command line graphics.
Jul 06 2015
On Wednesday, 1 July 2015 at 19:16:28 UTC, Vladde Nordholm wrote:So today I released version 1.1.0 of my console rendering library clayers! What this new update offers is support for colors, where you can set the text- and background-color! This is thanks to the library 'colorize' (d-colorize on GH). In case you don't know what clayers is (which you most likely don't), it's a console rendering library aimed at console games. It currently supports layer handling and colors. clayers on GitHub: https://github.com/vladdeSV/clayers clayers on dub: http://code.dlang.org/packages/clayersI saw this when you first announced it and have been meaning to write you about it. In some ways, it reminds me of a greenfield implementation of what I was getting into with the ncurses backend of my engine. When I come back to that (Some day! Soon! Maybe!), I was thinking of pulling in Adam's terminal.d; this might make a good companion to that? I certainly wouldn't lose any sleep at night to replace ncurses entirely and I look forward to seeing what you come up with. 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). * Make a no-args init that detects terminal dimensions. It's just nicer that way. * 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. * 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. * 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 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.) * 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); * 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? * 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). -Wyatt
Jul 07 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. 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/70a0547288aec8008d03 c419ad3c387315c2125 and removed here: https://github.com/vladdeSV/clayers/commit/7249b9ed2a00a59a2867dd 9861cf4bdee580f64). 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 vladde.net ! Yoyo, vladde
Jul 10 2015