From: Eli Zaretskii <eliz@gnu.org>
To: "Pfrommer, Julius" <julius.pfrommer@web.de>
Cc: emacs-devel@gnu.org
Subject: Re: Unifying code for drawing on a cairo context
Date: Sat, 23 Apr 2022 12:18:13 +0300 [thread overview]
Message-ID: <837d7gp38q.fsf@gnu.org> (raw)
In-Reply-To: <f0dbf270-1515-e728-c6a8-b43ffe2761c7@web.de> (julius.pfrommer@web.de)
> Date: Sat, 23 Apr 2022 11:06:16 +0200
> From: "Pfrommer, Julius" <julius.pfrommer@web.de>
>
> Obviously maintaining duplicate code is an anti-pattern. I'd like to
> pull out common cairo functionality bit-by-bit into methods to be used
> by both the X and the PGTK toolkit.
>
> With the cairo primitives unified between X and PGTK, adding a cairo
> "glass" for more toolkits should also become easier as a future option
> (ns, haiku, w32).
In general, I don't think we'd object to having such Cairo-specific
code in one place. However, having GUI code common to all the GUI
backends in one place is more important, so if this Cairo-specific
module will make that common code less so, it would be a step
backward, IMO. IOW, as long as the effort to have Cairo-specific code
in one place doesn't "invade" on the common code, it is welcome, I
think.
> - Would the unified cairo function be called cairo_draw_horizontal_wave,
> establishing a new cairo_ prefix convention?
Yes, why not?
> - Should such functions generally take an immediate cairo_t context as
> input or some "larger" struct that includes that cairo_t and can be
> extended in the future (e.g. with foreground and background color
> information).
It could, if that leads to a clean code that is easy to understand and
maintain. I'm not sure why you are asking this, or what would be the
alternative.
> - Is it okay to create the files cairoterm.h/.c or can we expect
> functionality beyond "term" to be added over time as well?
Yes. But again, as long as this doesn't make the common GUI code we
already have less common.
Thank you for your interest in Emacs.
P.S. You don't seem to have copyright assignment on file. As I
presume this work will produce substantial changes in the code, I'd
encourage you to start your legal paperwork rolling at this time, so
that we could accept your contributions without any limitations. If
you agree, I will send you the form to start the paperwork.
next prev parent reply other threads:[~2022-04-23 9:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-23 9:06 Unifying code for drawing on a cairo context Pfrommer, Julius
2022-04-23 9:18 ` Eli Zaretskii [this message]
2022-04-23 11:58 ` Po Lu
2022-04-23 12:04 ` Eli Zaretskii
2022-04-29 8:01 ` Pfrommer, Julius
2022-04-29 8:33 ` Po Lu
2022-04-29 8:35 ` Po Lu
2022-04-29 9:07 ` Pfrommer, Julius
2022-04-29 9:20 ` Po Lu
2022-04-29 10:43 ` Eli Zaretskii
2022-04-23 11:51 ` Po Lu
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837d7gp38q.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=julius.pfrommer@web.de \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).