Re: Re: [dev] [st][patch] more work on the XEmbed embedder
On Sun, Feb 04, 2024 at 06:29:40PM +0100, Страхиња Радић wrote:
>
> That is how it usually works. Users submit patches, which are provided on
>
> https://st.suckless.org/patches/
>
> and (depending on context) might get merged into the upstream. This
> particular
> patch doesn't look like it should be in the upstream, but might be listed on
> the above URL. In any case, you should format it according to
>
> https://suckless.org/hacking/
Alright, as I have pointed out earlier, these patches are NOT ready for
inclusion even in the wiki and will almost certainly have to be redone
anyway.
The first patch by Jochen and my second patch should eventually be squashed.
Still, here are the patch files. Even with the required file names, that do
not allow you to represent properly which one comes first and which one
later. But I am sure somebody will complain about the names, if I didn't do it.
>From cc593e750726df59f7af11a3a5596dd3d8b67e33 Mon Sep 17 00:00:00 2001
From: Jochen Sprickerhof
Date: Thu, 1 Feb 2024 06:16:04 +0300
Subject: [PATCH 1/3] Hi list,
I've implemented embedder support, i.e. the host part, for st. This
allows clients to embed into the st window and is useful if you start X
applications from the terminal. For example:
$ surf -e $WINDOWID
The behavior is similar to Plan 9 where applications can take over
windows.. as far as this is possible in X ;).
The attached patch is against git master and I intent to put it into the
wiki unless someone things it's worth for mainline.
Cheers Jochen
Source: https://lists.suckless.org/hackers/2001/17072.html
---
x.c | 82 -
1 file changed, 81 insertions(+), 1 deletion(-)
diff --git a/x.c b/x.c
index b36fb8c..aaa8139 100644
--- a/x.c
+++ b/x.c
@@ -66,6 +66,10 @@ static void ttysend(const Arg *);
/* XEMBED messages */
#define XEMBED_FOCUS_IN 4
#define XEMBED_FOCUS_OUT 5
+#define XEMBED_EMBEDDED_NOTIFY 0
+#define XEMBED_WINDOW_ACTIVATE 1
+#define XEMBED_FOCUS_CURRENT 0
+
/* macros */
#define IS_SET(flag) ((win.mode & (flag)) != 0)
@@ -185,6 +189,9 @@ static void mousesel(XEvent *, int);
static void mousereport(XEvent *);
static char *kmap(KeySym, uint);
static int match(uint, uint);
+static void createnotify(XEvent *e);
+static void destroynotify(XEvent *e);
+static void sendxembed(long msg, long detail, long d1, long d2);
static void run(void);
static void usage(void);
@@ -213,6 +220,8 @@ static void (*handler[LASTEvent])(XEvent *) = {
*/
[PropertyNotify] = propnotify,
[SelectionRequest] = selrequest,
+ [CreateNotify] = createnotify,
+ [DestroyNotify] = destroynotify,
};
/* Globals */
@@ -220,6 +229,7 @@ static DC dc;
static XWindow xw;
static XSelection xsel;
static TermWindow win;
+static Window embed;
/* Font Ring Cache */
enum {
@@ -744,6 +754,55 @@ cresize(int width, int height)
ttyresize(win.tw, win.th);
}
+void
+createnotify(XEvent *e)
+{
+ XWindowChanges wc;
+
+ if (embed || e->xcreatewindow.override_redirect)
+ return;
+
+ embed = e->xcreatewindow.window;
+
+ XReparentWindow(xw.dpy, embed, xw.win, 0, 0);
+ XSelectInput(xw.dpy, embed, PropertyChangeMask | StructureNotifyMask | EnterWindowMask);
+
+ XMapWindow(xw.dpy, embed);
+ sendxembed(XEMBED_EMBEDDED_NOTIFY, 0, xw.win, 0);
+
+ wc.width = win.w;
+ wc.height = win.h;
+ XConfigureWindow(xw.dpy, embed, CWWidth | CWHeight, &wc);
+
+ XSetInputFocus(xw.dpy, embed, RevertToParent, CurrentTime);
+}
+
+void
+destroynotify(XEvent *e)
+{
+ visibility(e);
+ if (embed == e->xdestroywindow.window) {
+ focus(e);
+ }
+}
+
+void
+sendxembed(long msg, long detail, long d1, long d2)
+{
+ XEvent e = { 0 };
+
+ e.xclient.window = embed;
+ e.xclient.type = ClientMessage;
+ e.xclient.message_type = xw.xembed;
+ e.xclient.format = 32;
+ e.xclient.data.l[0] = CurrentTime;
+ e.xclient.data.l[1] = msg;
+ e.xclient.data.l[2] = detail;
+ e.xclient.data.l[3] = d1;
+ e.xclient.data.l[4] = d2;
+ XSendEvent(xw.dpy, embed, False, NoEventMask, &e);
+}
+
void
xresize(int col, int row)
{
@@ -1165,7 +1224,8 @@ xinit(int cols, int rows)
xw.attrs.bit_gravity = NorthWestGravity;
xw.attrs.event_mask = FocusChangeMask | KeyPressMask | KeyReleaseMask
| ExposureMask | VisibilityChangeMask | StructureNotifyMask
- | ButtonMotionMask | ButtonPressMask | ButtonReleaseMask;
+ | ButtonMotionMask | ButtonPressMask | ButtonReleaseMask
+ | SubstructureNotifyMask | SubstructureRedirectMask;
xw.attrs.colormap = xw.cmap;
if (!(opt_embed && (parent = strtol(opt_embed, NULL, 0
@@ -1715,6 +1775,11 @@ visibility(XEvent *ev)
void
unmap(XEvent *ev)
{
+ if (embed == ev->xunmap.window) {
+ embed = 0;
+ XRaiseWindow(xw.dpy, xw.win);
+ XSetInputFocus(xw.dpy, xw.win, RevertToParent, CurrentTime);
+ }
win.mode &= ~MODE_VISIBLE;
}
@@ -1767,6 +1832,13 @@ focus(XEvent *ev)
{
XFocusChangeEvent *e = &ev->xfocus;
+ if (embed && ev->type == FocusIn) {
+ XRaiseWindow(xw.dpy, embed);
+ XSetInputFocus(xw.dpy, embe
Re: [dev] [st][patch] more work on the XEmbed embedder
On 24/02/04 03:22PM, Robin Haberkorn wrote: > Thirdly, I doubt that the maintainers would want to merge this into mainline. The essence of the suckless philosophy goes hand in hand with the Unix philosophy - programs that do one thing well and cooperate with other programs. st is and should remain a terminal emulator, nothing more. There is already a program called "tabbed" to manage multiple programs into tabs. From the description, it seems that the functionality of your patch is different than tabbed in presentation - it uses overlapping windows instead of tabs, so it can be a separate program. However, its functionality does overlap with dwm. So perhaps a patch for dwm would be better? Even then, the main idea of dwm and other tiling window managers is that of the tilled (not overlapping) windows. So this would go against that idea. > If you want to to try the patches in their current form, just build my version > or cherry-pick the commits into your own st-patch-branch. > Or does anybody insist I send them around in patch files? That is how it usually works. Users submit patches, which are provided on https://st.suckless.org/patches/ and (depending on context) might get merged into the upstream. This particular patch doesn't look like it should be in the upstream, but might be listed on the above URL. In any case, you should format it according to https://suckless.org/hacking/ signature.asc Description: PGP signature
Re: [dev] [st][patch] more work on the XEmbed embedder
04.02.24 12:52, Hiltjo Posthuma пишет: > Hi, > > If you want to contribute to upstream you need to rebase the patches on the > master version of st. > > Then you send the patches (git-format-patch) to the mailinglist. > Okay. But first of all, there are remaining problems. I would like to resolve the freeze-issue first. Secondly, this would be the wrong mailing list. Thirdly, I doubt that the maintainers would want to merge this into mainline. If you want to to try the patches in their current form, just build my version or cherry-pick the commits into your own st-patch-branch. Or does anybody insist I send them around in patch files?
Re: [dev] [st][patch] more work on the XEmbed embedder
On Sun, Feb 04, 2024 at 08:38:46AM +0300, Robin Haberkorn wrote: > Hello! > > I picked up the patch from Jochen Sprickerhof > that was posted on hack...@suckless.org a few years ago, allowing you to > embed applications into st via Xembed. So this is the _host_ side of > Xembed, very similar to what tabbed does. The thing is, you do not always > want to open apps in new tabs - I personally do not use tabbed > at all - but you just want it to cover your terminal window, so it behaves > more like a fullscreen terminal application and does not spawn a new X11 > window that may ruin your tiling layout etc. > > Check out to the last 3 patches on this branch: > https://github.com/rhaberkorn/st/commits/patches/ > (The others are really just patches I personally use for customization.) > > This has been tested with SciTECO (https://github.com/rhaberkorn/sciteco), > nsxiv and mpv (--wid). > Zathura unfortunately does not work flawlessly. It does not refresh its > window once embedded. And neither does Zathura work with tabbed. > > Also, st windows tend to freeze after resizing them a bit (but only while > a client is embedded). > > I am not very experienced in Xlib programming, so perhaps somebody else > could have a look. Somebody who knows tabbed better than I do. > > Another issue is that once an embedded app terminates, I try to remove > the icon from the st window. xprop confirms that this works. > But at least Awesome WM does not respect this change and continues > to display the old icon. > I suspect this is an Awesome WM bug. > Perhaps somebody could test with another WM. > > I like this feature so much, I also looked into whether it would be > possible to somehow hack Gtk (e.g. using LD_PRELOAD) so you can > embed most Gtk applications - after all they provide GtkPlug and it > also derives from GtkWindow. Unfortunately, this would not be trivial. > It might be easier to patch Gtk itself. > > All of this should perhaps eventually be part of the Wiki once > we fixed the remaining problems. > > Best regards, > Robin > Hi, If you want to contribute to upstream you need to rebase the patches on the master version of st. Then you send the patches (git-format-patch) to the mailinglist. -- Kind regards, Hiltjo
Re: [dev] dev
On Sat, Feb 03, 2024 at 09:04:04PM +, NRK wrote: > Having trouble unsubscribing? Worry not, coach NRK is at your service! > For a fair pay of 1337 XMR, you'll receive: > > ★★★ A comprehensive guide on how to unsubscribe from the suckless dev mailing > list ★★★ > > Offer available for a limited time only. > > - NRK > I heard the story about the early days, when mailing lists where new and shiny, they had a unsubscribe mailing list where they forwarded those unsubscribe emails. The sender address was subscribed to the unsubscribe list, so they could get in touch with other people interested in talking about unsubscribing mailing lists.
