On Sat, Feb 14, 2015 at 03:50:11PM -0600, J Raynor wrote:
> > - I don't think you need to allocate the gc with malloc, just put it
> > inside the wp directly and initialize it to grid_default_cell.
>
> I do need to allocate it with malloc. If I don't, it's always there
> (not NULL), so it'll always have some value. That makes it impossible
> to tell what to do when wp->colgc == 8. Does that mean the pane's
> background should be the terminal default, or does that mean the user
> wanted this option unset, so that it takes the window's bg value?
>
> Note that wp->colgc does not always exist. It only exists (isn't
> NULL) if a user has explicitly set a color for a particular pane.
> Otherwise, it will be NULL, and the pane will get its color from the
> window, either w->apcolgc if the pane is the active pane and
> w->apcolgc isn't NULL, or just the window's default color (w->colgc),
> or the default terminal colors if w->colgc is NULL.
Yes panes should always have colours. If the pane is set to 8, it uses
the window, if the window is 8, it uses the default. It isn't necessary
to have a way to set the pane directly to default, we don't have that
for any other style - it always follows the hierarchy (like eg the status
line options).
>
>
> > You shouldn't need to change tty_draw_line except to take
> > a struct window_pane argument.
>
> No, I need the loop in tty_draw_line to modify the cells it pulls from
> grid_view_peek to have the pane's default colors. Otherwise, after a
> redraw, the text on a pane will have the terminal's default colors,
> and just the EL would get the pane's defaults.
No, I think you don't - tty_draw_line draws on screen using tty_cell and
that calls tty_attributes. There should be no way to get stuff on screen
that doesn't set colours via either tty_reset or tty_attributes. If you
change those two, it should be enough.
>
>
> > - I think the window colour can still be a window option but I would
> > drop it (or drop the pane colours and just do the window) for now and
> > add it as a separate change after one is working.
>
> Well, I suppose the window's color could be a window option. But the
> pane's color can't be, and it would be awkward for the active-pane's
> color to be one since it couldn't be a style. It'd have to be a
> string so you could set it to the empty string, otherwise it'd look
> like a style was always set. It seems odd to have different ways of
> setting the colors.
We have window options and I'd prefer to use them. Panes are a special
case, windows do not need to be.
>
>
> > - I would drop get_wp_default_grid_colours in favour of a function in
> > tty.c that did something like:
>
> Your function would only work if someone had set an explicit color for
> the pane. And to get it to take the window's color and active-pane
> color into account would make it look much like
> get_wp_default_grid_colours.
Not quite. get_wp_default_grid_colours returns a gc which you then apply
in the caller. I think you should have a function that updates a gc if
its fg or bg is set to 8.
>
> Based on what you've written, I wonder if you've got a different idea
> in mind on how setting a color works. Another way to do it (maybe
> what you had in mind?) would be to set the color for a pane when it is
> created. This way, a pane would always need wp->colgc, so it wouldn't
> make sense to malloc it. This could be updated when a user switches
> which pane is active, or explicitly sets a color. Also, if the pane
> stores its current color, you wouldn't have to figure it out with a
> function like get_wp_default_grid_colours. But you would need a flag
> to tell if the user had explicitly set the color or not, otherwise you
> wouldn't know if it was ok to update it when the window or active-pane
> colors were changed.
Almost. Panes should always have two colours - one for normal, one for
active. They may be 8 for the default colour. Both colours should start
with grid_default_cell and the user can change with display-panes. You
don't need a flag, the pane's colours are always there, the user sets
them to default to use the window's colours instead.
So your function actually looks something like:
void
tty_default_colours(struct grid_cell *gc, struct window_pane *wp)
{
const struct grid_cell *pgc, *wgc;
if (wp == NULL)
return;
if (wp == wp->window->active)
pgc = &wp->active_colgc;
else
pgc = &wp->colgc;
wgc = options_get_style(&wp->window->options, "window-style");
if (gc->fg == 8 && !(gc->flags & GRID_FLAG_FG256)) {
gc.flags &= ~GRID_FLAG_FG256;
if (pgc->fg == 8 && !(pgc->flags & GRID_FLAG_FG256)) {
gc.fg = wgc->fg;
gc.flags |= (wgc->flags & GRID_FLAG_FG256);
} else {
gc.fg = pgc->fg;
gc.flags |= (pgc->flags & GRID_FLAG_FG256);
}
}
if (gc->bg == 8 && !(gc->flags & GRID_FLAG_BG256)) {
gc.flags &= ~GRID_FLAG_BG256;
if (pgc->bg == 8 && !(pgc->flags & GRID_FLAG_BG256)) {
gc.bg = wgc->bg;
gc.flags |= (wgc->flags & GRID_FLAG_BG256);
} else {
gc.bg = pgc->bg;
gc.flags |= (pgc->flags & GRID_FLAG_BG256);
}
}
}
Then you can call this from tty_attributes and also change it to send
SGR0 directly rather than use tty_reset. After that, tty_reset can call
tty_attributes.
> Is that the model you had in mind? I think we have to make sure we're
> on the same page about this before I can proceed.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
