Re: Re: [dev] [st][patch] more work on the XEmbed embedder

[Robin Haberkorn]

 == FocusIn) {
+		XRaiseWindow(xw.dpy, embed);
+		XSetInputFocus(xw.dpy, embed, RevertToParent, CurrentTime);
+		sendxembed(XEMBED_FOCUS_IN, XEMBED_FOCUS_CURRENT, 0, 0);
+		sendxembed(XEMBED_WINDOW_ACTIVATE, 0, 0, 0);
+	}
+
 	if (e->mode == NotifyGrab)
 		return;
 
@@ -1905,9 +1977,17 @@ cmessage(XEvent *e)
 void
 resize(XEvent *e)
 {
+	XWindowChanges wc;
+
 	if (e->xconfigure.width == win.w && e->xconfigure.height == win.h)
 		return;
 
+	if (embed) {
+		wc.width = e->xconfigure.width;
+		wc.height = e->xconfigure.height;
+		XConfigureWindow(xw.dpy, embed, CWWidth | CWHeight, );
+	}
+
 	cresize(e->xconfigure.width, e->xconfigure.height);
 }
 
-- 
2.43.0

>From 4de1ba2a851515da01000f8ed7406d4669bdecc3 Mon Sep 17 00:00:00 2001
From: Robin Haberkorn 
Date: Thu, 1 Feb 2024 17:11:48 +0300
Subject: [PATCH 2/3] Embedder: This respects the embedded window's name/title

Imports gettextprop() from tabbed.c.
---
 x.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/x.c b/x.c
index aaa8139..6b3a8e1 100644
--- a/x.c
+++ b/x.c
@@ -192,6 +192,8 @@ 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 Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
+static void updatetitle(Window win);
 
 static void run(void);
 static void usage(void);
@@ -524,6 +526,9 @@ propnotify(XEvent *e)
 			(xpev->atom == XA_PRIMARY ||
 			 xpev->atom == clipboard)) {
 		selnotify(e);
+	} else if (xpev->state != PropertyDelete && xpev->atom == XA_WM_NAME &&
+	   embed == xpev->window) {
+		updatetitle(embed);
 	}
 }
 
@@ -767,6 +772,8 @@ createnotify(XEvent *e)
 	XReparentWindow(xw.dpy, embed, xw.win, 0, 0);
 	XSelectInput(xw.dpy, embed, PropertyChangeMask | StructureNotifyMask | EnterWindowMask);
 
+	updatetitle(embed);
+
 	XMapWindow(xw.dpy, embed);
 	sendxembed(XEMBED_EMBEDDED_NOTIFY, 0, xw.win, 0);
 
@@ -803,6 +810,44 @@ sendxembed(long msg, long detail, long d1, long d2)
 	XSendEvent(xw.dpy, embed, False, NoEventMask, );
 }
 
+Bool
+gettextprop(Window w, Atom atom, char *text, unsigned int size)
+{
+	char **list = NULL;
+	int n;
+	XTextProperty name;
+
+	if (!text || size == 0)
+		return False;
+
+	text[0] = '\0';
+	XGetTextProperty(xw.dpy, w, , atom);
+	if (!name.nitems)
+		return False;
+
+	if (name.encoding == XA_STRING) {
+		strncpy(text, (char *)name.value, size - 1);
+	} else if (XmbTextPropertyToTextList(xw.dpy, , , ) >= Success
+	   && n > 0 && *list) {
+		strncpy(text, *list, size - 1);
+		XFreeStringList(list);
+	}
+	text[size - 1] = '\0';
+	XFree(name.value);
+
+	return True;
+}
+
+void
+updatetitle(Window win)
+{
+	char name[256];
+
+	if (!gettextprop(win, xw.netwmname, name, sizeof(name)))
+		gettextprop(win, XA_WM_NAME, name, sizeof(name));
+	xsettitle(name);
+}
+
 void
 xresize(int col, int row)
 {
-- 
2.43.0

>From 73028d36e877c3c918ba96ffc95a3cc2a1b710b2 Mon Sep 17 00:00:00 2001
From: Robin Haberkorn 
Date: Sat, 3 Feb 2024 03:36:47 +0300
Subject: [PATCH 3/3] inherit window icon from embedded (Xembed) application

* This is largely taken from tabbed's "icon" patch (cf. xseticon()):
  https://tools.suckless.org/tabbed/patches/icon/
* I found that some applications that show their icon flawlessly in the WM
  won't work (neither in st, nor in tabbed).
  This was the case with SciTECO, but it could be resolved
  by reordering some statements.
* Once the embedded application terminates, we try to remove the icon again.
  `xprop` confirms that this worked.
  Unfortunately, Awesome WM will continue to show the old icon, which
  is probably an Awesome WM bug.
  Perhaps we should therefore apply this patch on top of netwmicon (FIXME):
  https://st.suckless.org/patches/netwmicon/
---
 x.c | 49 +
 1 file changed, 49 insertions(+)

diff --git a/x.c b/x.c
index 6b3a8e1..66dccc4 100644
--- a/x.c
+++ b/x.c
@@ -194,6 +194,7 @@ static void destroynotify(XEvent *e);
 static void sendxembed(long msg, long detail, long d1, long d2);
 static Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
 static void updatetitle(Window win);
+static void updateicon(Window win);
 
 static void run(void);
 static void usage(void);
@@ -520,6 +521,7 @@ propnotify(XEvent *e)
 {
 	XPropertyEvent *xpev;
 	Atom clipboard = XInternAtom(xw.dpy, "CLIPBOARD", 0);
+	Atom wmicon = XInternAtom(xw.dpy, "_NET_WM_ICON", 0);
 
 	xpev = >xproperty;
 	if (xpev->state == PropertyNewValue &&
@@ -529,6 +531,9 @@ propnotify(XEvent *e)
 	} else if (xpev->state != PropertyDelete && xpev->atom == XA_WM_NAME &&
 	   embed == xpev->window) {
 		updatetitle(embed);
+	} else if ((xpev->atom == wmicon || xpev->state == PropertyNewValue && xpev-&

Re: [dev] [st][patch] more work on the XEmbed embedder

[Robin Haberkorn]

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?

[dev] [st][patch] more work on the XEmbed embedder

[Robin Haberkorn]

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

Re: [dev] Learn C

[Robin Pedersen]

Yo.

Maybe you wanna read this?
https://git.suckless.org/
https://9p.io/sources/plan9/sys/src/cmd/

Regards Robin.

On Sun, 24 Mar 2019 at 11:29, Thuban  wrote:
>
> Hi,
> I want to learn C. I mean, sane C.
> What i read before was based on big IDE such as codeblocks. So, I don't
> know how to write Makefiles from scratch. (just an example).
> As an example, I found gobyexample [1] great. But it's go.
> Any reading advice?
>
> Thanks.
> Regards
>
> [1] : https://gobyexample.com/
> --
> thuban
>

Re: [dev] [surf] copying to clipboard instead of primary

[Robin Pedersen]

Hi.

Does this help?
https://developer.gnome.org/gdk3/stable/gdk3-Selections.html
https://git.suckless.org/surf/file/surf.c.html#l1817

Regards Robin.


On Tue, 8 Jan 2019 at 18:37, Caio Barros  wrote:
>
> Hello,
>
> For some time I've been struggling with clipboard selection on surf.
> It seemed to me that it was inconsistent: if i used the mouse do copy
> text it worked, but Ctrl-c didn't seem to always work. After trying to
> use Ctrl-y to copy the current URL I noticed that I could paste it
> using the middle mouse click, but not using, for instance Ctrl-Shift-V
> in st.
>
> After digging a little bit I finally discovered the difference of
> PRIMARY and CLIPBOARD selections in X[1]. So, if I understand
> correctly, using Ctrl-C or Ctrl-y in surf copies text to PRIMARY, is
> that right? If so, my question is how to either change this behavior
> of surf or consistently paste text copied to the PRIMARY selection
> using the keyboard instead of the middle mouse click?
>
> If what I'm seeing is not the expected behavior, then what should it
> be? I'm not sure if this is related but I noticed that if I type
> Ctrl-Shift-o to open the Inspector nothing happens.
>
> Thanks!
> Caio
>
> [1] https://wiki.archlinux.org/index.php/Clipboard
>

[dev] [announcement] jack_patchbay: ncurses patchbay for jack

[Robin Pedersen]

Hi.

I made a software: https://gitlab.com/byllgrim/jack_patchbay
"Terminal (ncurses) patchbay for jack audio connection kit, written in C89, used
to connect ports of jack clients."
It's very minimal so maybe some of you people are interested.

Regards Robin.

Re: [dev] Coding style: why /* */ and not //?

[Robin Pedersen]

That is a rather bold sentiment.
At uni the attitude is opposite - I actually saw home assignments
stating "remember to use many comments to make the code more
readable".
I actually agree with you; there is much less clutter if the comments
don't duplicate that which is already communicated through good
naming, and the code is more readable when good naming makes comments
superfluous.

On Wed, 26 Dec 2018 at 21:57, Bobby Powers  wrote:
>
> On Wed, Dec 26, 2018 at 10:44 AM  wrote:
> > Preprocessor. I guess having 2 ways to define comments is not significant,
> > then better stick to one and the historical one.
>
> Better than one way is zero ways -- comments are not semantically
> significant, so rather than argue about which standards-defined
> comment style to use it would better to ban them all.
>

Re: [dev] Xorg implementations

[robin]

On Tue, Jul 04, 2017 at 01:13:21AM +, sylvain.bertr...@gmail.com wrote:
> I did check alpine package web browsers: it's full of libgcc_s deps.
> 
> You can forget alpine as a no libgcc_s distro. At least, they do maintain the
> patches required in order to compile many software packages with the musl
> libc.

Patching the shit out of everything...
I don't like this. It seems like a hassle and it only treats symptoms
while the cause is still poisoning the forest.
I'd rather live in shit-world until a proper solution exist.

Re: [dev] [announce] mle: a small terminal-based text editor

[robin]

On Wed, Mar 29, 2017 at 07:00:03PM +, Cág wrote:
> 
> Personally I'd like to see more of something like mg or busybox' vi.
> Unfortunately they both don't support UTF-8. nvi is pretty good as
> well.
> 
> -- 
> caóc
> 

I wrote a vi like editor in <1k lines.
Fairly shitty, but maybe it inspires to something.

https://github.com/byllgrim/svi

Re: [dev] [announce] ff2sixel: view farbfeld images in terminal

[robin]

On Mon, Mar 20, 2017 at 11:16:58AM +0100, hiro wrote:
> there's nothing convenient in your pityful setup.
> 
> "won't disturb any window layout I had open already"
> fix your window manager, seems it's not able to manage shit.
> 
> that escape you're talking about is called execve and it works just fine.

Man, I love the spirit of suckless (subset of suckless).
If only the same honesty could be applied throughout life without bad outcome.

Re: [dev] [ubase] pager

[robin]

On Thu, Feb 09, 2017 at 07:09:23PM +0100, Josuah Demangeon wrote:
> roqbin.a.t.peder...@gmail.com:
> 
> > I vaguely remember pagers discussed in a thread, and the conclusion was
> > that pagers are unecessary because its the job of something like dvtm or
> > tmux.
> 
> I also like to have the multiplexer managing the scrolling, but for dvtm, 
> what provides the scrolling (and copy) is the $PAGER (and the $EDITOR) itself.
> 

Maybe that makes more sense, to separate concern even further by letting the
muxer only mux, and let the pager only... page?

I usually pipe into less whenever something overflows the terminal height,
but having to type 2>&1 to see stderr is a bit cumbersome.
In dvtm Shift-PageUp is much easier.

Re: [dev] [ubase] pager

[robin]

On Thu, Feb 02, 2017 at 07:45:28PM +0100, Mattias Andrée wrote:
> Hi!
> 
> I'm going to write a pager for ubase, and, because
> it is a necessary component of the pager, I will
> also implement ul(1). ul(1) will be used by the
> pager which is necessary to get properly formatted
> output when piping man(1) or groff(1) to the pager.
> 
> 
> Mattias Andrée

I vaguely remember pagers discussed in a thread, and the conclusion was
that pagers are unecessary because its the job of something like dvtm or tmux.

Re: [dev] Suckless font rendering library

[robin]

On Sat, May 14, 2016 at 11:31:13PM +0300, ilab...@yandex.ru wrote:
> On Sat, May 14, 2016 at 11:23:08PM +0300, Alexander Krotov wrote:
> > On Sat, May 14, 2016 at 09:03:44PM +0200, robin wrote:
> > > So i took up the challenge of making a suckless font rendering library.
> > > The problem: my lvl is barely above noob.
> > > Maybe it will spark some motivation in someone more talented.
> > > 
> > > https://github.com/byllgrim/tinyfont
> > > 
> > 
> > Does not compile.  Where do I get utf.h?
> > 
> Looks like it is http://git.suckless.org/libutf/, add a link to it
> somewhere in the README.
> 

Indeed, i had forgotten. Suckless libutf is the right library.

[dev] Suckless font rendering library

[robin]

So i took up the challenge of making a suckless font rendering library.
The problem: my lvl is barely above noob.
Maybe it will spark some motivation in someone more talented.

https://github.com/byllgrim/tinyfont

Re: [dev] [scc] issues with invoking

[robin]

> Yes, it is in a very early stage.  Cc1 is really advanced, and it can
> parse and generate intermediate code for almost all C90, and about a
> 90% of C99.  Cc2 is only a draft.  I had an advanced version of cc2
> for z80, but I discarded it and I began from the beginning with the
> idea of having a multitargered compiler.  Patches are welcome ;)

I think compilers are way over my level, but it's a subject that interest me and
clang is massive c++, gcc is nonstandard bloat, tcc doesnt seem sufficient,
so I wanna help.

Where would be a good place to start learning?

I have a book called "Compiler Construction: Principles and Practice", but I
find it very tedious.
If you know this book, would you say my impression is correct or am I just too
stupid yet for such an advanced subject?

Re: [dev] Lessons Learned from 30 Years of MINIX

[robin]

On Fri, Mar 04, 2016 at 11:47:48PM +0100, FRIGN wrote:
> On Fri, 4 Mar 2016 14:43:40 -0500
> Greg Reagle  wrote:
> 
> > The connection to suckless is that the author has strong minimalist and 
> > anti-bloat tendencies.
> 
> when did this turn into a Hacker News here?
> 
> -- 
> FRIGN 

It seems relevant to me. Suckless tries to replace sucky software and its worth
a debate wether microkernels are less sucky.

Microkernels defenitely resonates with the unix philosophy "do one thing and
do it well".
Having everything, except FUSE and such, in the kernel is doing more than
one thing.

To haphazardly opt for linux isnt good. Think about how it uses gnu
extensions to C instead of following standards.
Linux built with 'allnoconfig', a kernel that does nothing, takes 516K.
You can also compare the number of system calls in linux vs plan9.

Re: [dev] suckless shared tools

[robin]

> I noticed there's libsl on git.suckless.org
Why not have a makefile in libsl?
It could install to /usr/local/include/arg.h and so on.
All projects using arg.h can #include .

> Send patches
I wouldnt know if its a good idea to have .a files such as 9base lib9.a.

On Sat, Feb 27, 2016 at 05:14:47PM -0300, Marc Collin wrote:
> So the idea is to send patches to all arg.h files on different
> suckless projects when one of them is modified?
> Wouldn't it be easier to have a more centralized arg.h (and similar tools)?
> I'm not complaining, I just want to understand the idea you guys have.
> I noticed there's libsl on git.suckless.org that attempts to unite
> suckless files many suckless projects use at the same place but it
> seems this didn't take off.
> 
> On Sat, Feb 27, 2016 at 5:01 PM, Dimitris Papastamos  wrote:
> > On Sat, Feb 27, 2016 at 03:56:25PM -0300, Marc Collin wrote:
> >> Hello,
> >> A few days ago arg.h was update on sbase to fix an out-of bounds error.
> >> After that the same error was fixed (some sooner some later) on lots
> >> of other projects that also have arg.h like ubase, slock, dmenu, st,
> >> and others. And many tools that use arg.h are still not fixed. Isn't
> >> this bad for maintenance? Couldn't projects import arg.h and similar
> >> tools from another repository and then only 1 place have to be fixed
> >> to everyone benefit? Or a script that can be run to automatically sync
> >> all arg.h on git.suckless.org with the master version?
> >> Thanks.
> >
> > Send patches.
> >
> 

Re: [dev] [surf][bug] segmentation fault

[robin]

On Tue, Feb 09, 2016 at 10:01:30PM +0100, FRIGN wrote:
> On Tue, 09 Feb 2016 21:49:17 +0100
> Christoph Lohmann <2...@r-36.net> wrote:
> 
> > Which OS are you using?
> > Which distribution of this OS are you using?
> > Which webkit version are you using?
> > Have you compiled webkit on your own?
> > If not: Why not?
> 
> Most importantly: Which version of surf is he running?
> 
> Cheers
> 
> FRIGN
> 
> -- 
> FRIGN 
> 

Allright! Thanks guys.
I tried the webkit2 branch and there's no problem there.

In case you are still curious:
Debian testing.
Did not compile wekkit myself because last time i did, it was tedious.

[dev] [surf][bug] segmentation fault

[robin]

# Crash
surf crashes with a segmentation fault.
It seems to happen when scrolling, but
only on certain sites or at certain times.

If the window crashing was opened from another surf window,
they both crash.

# Sites that crash
http://www.mkyong.com/java8/java-8-stream-read-a-file-line-by-line/
/* when scrolling loaded page */

gmail.com
/* when uploading image to hangouts chat */

http://www.express.co.uk/news/world/641884/China-heats-hyrdogen-gas-three-times-hotter-than-sun-limitless-energy

http://forum.allaboutcircuits.com/threads/pspice-cutoff-frequency.117073/
/* when going back to previous page */

# Sites that seem to work
suckless.org
kernel.org
packages.debian.org
vg.no
facebook.com

# Error message
** Message: console message:  @0: Blocked a frame with origin 
"https://googleads.g.doubleclick.net; from accessing a frame with origin 
"http://www.mkyong.com;.  The frame
 requesting access has a protocol of "https", the frame being accessed has a 
protocol of "http". Protocols must match.

** Message: console message:  @0: Blocked a frame with origin 
"http://tpc.googlesyndication.com; from accessing a frame with origin 
"http://www.express.co.uk;. Protocols,
 domains, and ports must match.

^a thousand of these ad related messages^

Segmentation fault

# What ive tried
git pull origin master
make clean
make
sudo make install

[dev] [surf] Why yank to primary instead of clipboard?

[robin]

The function clipboard(Client *c, const Arg *arg)
uses GDK_SELECTION_PRIMARY instead of GDK_SELECTION_CLIPBOARD.

For me, thats a hassle.
How do i copy a uri to send to a friend?

I changed it to use CLIPBOARD, but I am wondering:
Is there any good reason to use PRIMARY?