search

cpjreynolds / rustty

A terminal UI library
https://docs.rs/rustty
MIT License
153 stars 14 forks source link

First draft of a new "ui" module (WIP) #15

Closed ghost closed 8 years ago

ghost commented 9 years ago

This module contains a convenience layer to display various widgets, such as windows, buttons etc. It also manages these elements' alignment, size and all.

This is a squash commit of a WIP branch I have been maintaining for a couple of weeks to support the development of another projet. Until now, I had no idea where I was going with the UI module, but now things are starting to take shape and I'm gearing up for a first PR.

In addition to the new UI modules, a couple of changes have been made to core:

Coordinate removal: The purpose of Coordinate was exactly the same as Option. Replaced usage of Coordinate with Option.

Cursor un-traiting: The Cursor struct had an overly complex trait structure that it was te only one to use. I moved in all directly in Cursor.

Positioning and size consolidation: With the UI module, position and size take a new, heightened importance. I renamed Pair type to Pos, added a new Size type and added HasSize and HasPosition traits. Only HasSize is used in core (HasPosition is used in ui), but it felt weird to have both these traits at difference places, so all in core...

New CellAccessor trait: With the new ui module, we need a common interface to "write cells to an arbitrary surface", with that surface being either a sub-window or the terminal itself.

On the "ui" side, we have (for now):

widget: a surface with a size and position in an arbitrary parent. We draw in it like we would in a terminal, and then draw the widget itself in another CellAccessor.

painter: A convenience trait that applies to any CellAccessor with useful methods for easily painting multiple cells, such a printline() or draw_box().

button: a widget that draws its text wrapped around <> brackets and highlights a chosen accel char.

layout: Helpers to easily align widgets inside each other.

All of this is heavily WIP, but I think it's advanced enough to open a PR to start a discussion about the API design.

ghost commented 9 years ago

(I'm working on new examples right now to showcase the new module)

ghost commented 9 years ago

I think I have to insist that this is very much a work in progress and that I don't find the API particularly elegant. I'm just banging around some code to make my things work and, being relatively new to Rust, I often fight the borrow checker which in turn influence the way I design the API.

The reason I open this PR is to get a first impression from you, @cpjreynolds and see what we can do to improve it for an eventual merge upstream.

cpjreynolds commented 9 years ago

This is fantastic, thank you so much for the time you have put into this! I have to admit I haven't been able to give this project as much attention as I would like as of late, college applications have been taking up almost all of my time. As soon as the rush is over I should be able to devote a more significant proportion of my time working on this.

Abstracting over any drawable surface (like windows, panels, screens etc) will be great, and allow us to implement the same painting algorithms/logic for all surfaces.

This PR looks great, I like a lot of what you have done. The biggest issues we're going to encounter in getting this merged upstream are merge conflicts from my own local changes. In the coming week or so there will most likely be some internal api changes that affect this PR. Apart from that, this looks like a good direction to be going in. Thanks again for your work!

Syntaf commented 8 years ago

Is there any movement to get this merged soon? I just submitted https://github.com/cpjreynolds/rustty/pull/18 , which can be rewritten with these new features if it makes it into rustty

ghost commented 8 years ago

I'm wondering if we should not be more liberal with merging unfinished stuff to master. @cpjreynolds seems to have little time to devote to rustty lately and PRs are blocking each other (I myself have other ideas of stuff to implement, but I'm kind of lost in WIP branches). This is a very young library, maybe we shouldn't needlessly stifle its development with premature quality standards.

Syntaf commented 8 years ago

Agreed @hsoft , this library is really cool and I'd love to see it develop. Introducing widgets is a big setup up and would be super beneficial imo. This should be merged asap, otherwise I'll be forced to use hsoft's fork for my projects

cpjreynolds commented 8 years ago

@hsoft and @Syntaf, the more I think about it the more I agree with you. There's no reason not to get beneficial patches like this and others merged in a faster manner. Apologies for my relative absence, and thank you for the PR!