From: Alex Gramiak <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 35468@debbugs.gnu.org
Subject: bug#35468: [PATCH] Refactor draw_glyph_string on X and w32
Date: Mon, 29 Apr 2019 11:43:23 -0600 [thread overview]
Message-ID: <877ebcogg4.fsf@gmail.com> (raw)
In-Reply-To: <87pnp5oqu1.fsf@gmail.com> (Alex Gramiak's message of "Sun, 28 Apr 2019 13:46:46 -0600")
>> The result of this refactoring should be more low-level and more
>> primitive interfaces, and they should each one make sense, not be
>> ad-hoc. It means the job becomes more complex, and you will probably
>> need to ask questions regarding the GUI systems you are less familiar
>> with. But the result will IMO much better and future-proof.
>
> I'll see what I can do.
Alright, for the first question may I ask if you're okay with the
following abstraction (which may be the start of a pattern)?
I'm in {x,w32}_draw_box_rect right now, trying to generalize both
versions. The issue is that the fill command in each accepts different
arguments; specifically the w32 version takes in the color explicitly
and uses s->hdc instead of s->gc. So I think there will have to be 2
different fill_rectangle interface procedures: one for glyph strings (so
that the w32 version can access s->hdc), and another for other
procedures like *_draw_bar_cursor.
void
gui_draw_glyph_string_box (struct glyph_string *s)
{
int width, left_x, right_x, top_y, bottom_y, last_x;
bool raised_p, left_p, right_p;
struct glyph *last_glyph;
last_x = ((s->row->full_width_p && !s->w->pseudo_window_p)
? WINDOW_RIGHT_EDGE_X (s->w)
: window_box_right (s->w, s->area));
/* The glyph that may have a right box line. */
last_glyph = (s->cmp || s->img
? s->first_glyph
: s->first_glyph + s->nchars - 1);
width = eabs (s->face->box_line_width);
raised_p = s->face->box == FACE_RAISED_BOX;
left_x = s->x;
right_x = (s->row->full_width_p && s->extends_to_end_of_line_p
? last_x - 1
: min (last_x, s->x + s->background_width) - 1);
top_y = s->y;
bottom_y = top_y + s->height - 1;
left_p = (s->first_glyph->left_box_line_p
|| (s->hl == DRAW_MOUSE_FACE
&& (s->prev == NULL
|| s->prev->hl != s->hl)));
right_p = (last_glyph->right_box_line_p
|| (s->hl == DRAW_MOUSE_FACE
&& (s->next == NULL
|| s->next->hl != s->hl)));
if (s->face->box == FACE_SIMPLE_BOX)
FRAME_GDIF (s->f)->draw_box_rect (s,
left_x,
top_y,
right_x,
bottom_y,
width,
left_p,
right_p);
else
{
FRAME_GDIF (s->f)->setup_relief_colors (s);
FRAME_GDIF (s->f)->draw_relief_rect (s->f,
left_x,
top_y,
right_x,
bottom_y,
width,
raised_p,
true,
true,
left_p,
right_p);
}
}
void
gui_draw_box_rect (struct glyph_string *s,
int left_x, int top_y, int right_x, int bottom_y, int width,
bool left_p, bool right_p)
{
struct graphical_drawing_interface *gdif = FRAME_GDIF (s->f);
gdif->save_context (s);
gdif->set_context_clip (s);
gdif->set_context_foreground (s, s->face->box_color);
/* Top. */
gdif->fill_rectangle (s, s->gc, left_x, top_y, right_x - left_x + 1, width);
/* Left. */
if (left_p)
{
gdif->fill_rectangle (s, s->gc,
left_x, top_y,
width, bottom_y - top_y + 1);
}
/* Bottom. */
gdif->fill_rectangle (s, s->gc,
left_x, bottom_y - width + 1,
right_x - left_x + 1, width);
/* Right. */
if (right_p)
{
gdif->fill_rectangle (s, s->gc,
right_x - width + 1, top_y,
width, bottom_y - top_y + 1);
}
gdif->reset_context (s);
}
It doesn't work for NS partially because of the following section only
present in the NS equivalent of gui_draw_glyph_string_box. Would you be
okay with putting this in the generic version inside a FRAME_NS_P (s->f)
check? I don't know why only NS has this, though...
if (s->hl == DRAW_MOUSE_FACE)
{
face = FACE_FROM_ID_OR_NULL (s->f,
MOUSE_HL_INFO (s->f)->mouse_face_face_id);
if (!face)
face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
}
else
face = s->face;
next prev parent reply other threads:[~2019-04-29 17:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-28 1:29 bug#35468: [PATCH] Refactor draw_glyph_string on X and w32 Alex Gramiak
2019-04-28 17:11 ` Eli Zaretskii
2019-04-28 19:46 ` Alex Gramiak
2019-04-29 17:43 ` Alex Gramiak [this message]
2019-04-30 4:59 ` Eli Zaretskii
2019-04-30 18:00 ` Alex Gramiak
2019-05-01 0:14 ` mituharu
2019-05-03 19:01 ` Alex Gramiak
2019-05-03 21:33 ` mituharu
2019-05-04 4:00 ` mituharu
2019-05-01 18:19 ` Eli Zaretskii
2019-05-02 19:41 ` Alex Gramiak
2019-05-02 20:14 ` Eli Zaretskii
2019-05-03 15:26 ` Basil L. Contovounesios
2019-05-04 8:17 ` Eli Zaretskii
2019-05-04 19:29 ` Alex Gramiak
2019-05-05 0:10 ` mituharu
2019-05-05 16:00 ` Eli Zaretskii
2019-05-05 2:34 ` Eli Zaretskii
2019-04-30 20:11 ` Alan Third
2019-05-01 17:38 ` Eli Zaretskii
2019-05-01 21:08 ` Alan Third
2019-05-02 18:14 ` Alex Gramiak
2019-05-03 21:12 ` Alan Third
2021-05-12 14:43 ` Lars Ingebrigtsen
2021-07-22 12:55 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ebcogg4.fsf@gmail.com \
--to=agrambot@gmail.com \
--cc=35468@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.