Re: [dev] I made a bluetooth-control-thing

[Ethan Marshall]

On 16/06/22 04:33pm, David Demelier wrote:
>
> Hi,
>
> There is something wrong with the makefile because each time I type
> make it keeps rebuilding everything.

From having built it myself, I can confirm that change detection seems
to be broken for libsl/drw.c and all files in the libwdgt and sdb_bt.
Everything else seems to be working correctly.

> $ lbm
> X Error of failed request:  BadWindow (invalid Window parameter)
>   Major opcode of failed request:  15 (X_QueryTree)
>   Resource id in failed request:  0x0
>   Serial number of failed request:  12
>   Current serial number in output stream:  12

When I tried to auto-launch using .xprofile (which is ran before the
windowmanager but after xorg starts), I got the exact same error.
However, when I changed this in order to launch after the window manager
which runs the system tray, this error does not appear and everything
works as expected. Could this be something to do with incorrectly
waiting for a system tray to be available? Do you definitely have a
window manager which supports a system tray running?

Ethan


signature.asc
Description: PGP signature

Re: [dev] I made a bluetooth-control-thing

[Ethan Marshall]

Thanks a lot for this! I have switched to using it instead of
blueman-applet and it works great so far. The simple UI is so much
better than the maze of a menu that blueman seems to have. I love it!

Other than the criticisms mentioned by the other guy in the first reply,
I would ask if there is a way I can enlarge the icon in my system tray
slightly. Currently, I can only just about see it, which is fine, but it
would be nice if I could see it more easily.

Thanks again, this is a fantastic tool.

Ethan

On 15/06/22 05:30pm, Stefan Mark wrote:
> I was always a bit annoyed by the lack of a simple, gui-based bluetooth
> control thing. Like blueman, but not in a scripting language. And maybe
> with somewhat simpler interface.
> 
> Thus i did this:
> https://git.weitnahbei.de/nullmark/little_blue_man
> 
> Its written in C, uses drw and dbus and it works. At least for me. It
> lacks many features and proper testing. And i got somewhat carried
> away and dabbled with ideas of starting my own toolkit. Turned out,
> such a thing is quite big a thing, thus there is no toolkit, but the
> code is somewhat more complicated than it has to. 
> 
> Anyway, i would like to hear some opinions :)
> 
> Sidenote and a warning: i am not a good c programmer. I just like to
> use it :)




signature.asc
Description: PGP signature

Re: [dev] [dwm] possible regression in 8806b6e

[Ethan Marshall]

Completely fixed. All affected windows now behave as they did before the
patch - so, problem solved on my end.

Thanks for all your help Chris.

Ethan

Re: [dev] [dwm] possible regression in 8806b6e

[Ethan Marshall]

Just re-ran the bisection and got 8806b6e on both stock dwm and my
build. Reverting this commit fixes this change in both. Reverting
bece862 has no change in either, so I would assume we can eliminate that
commit as the issue.

Could this be related to the handling of fixed-size windows? I was under
the impression that windows of a fixed size are treated as automatically
floating by dwm. Could that have been thrown off by this new size logic?

Ethan

On 23/04/22 10:16am, Chris Down wrote:
> Hi Ethan,
> 
> Just checking, are you sure this bisects to 8806b6e23793 ("manage:
> propertynotify: Reduce cost of unused size hints")? I saw this issue prior
> to making this patch and bisected to bece862a0fc4 ("manage: For
> isfloating/oldstate check/set, ensure trans client actually exists"). I
> reported this last month here[0].
> 
> I would be surprised if this commit is the cause because I use gpg-askpass
> and the Chromium system printing dialog fairly regularly, although of course
> anything is possible.
> 
> If you're sure it bisects to this commit and not bece862a0fc4, let me know.
> Thanks!
> 
> Chris
> 
> 0: https://lists.suckless.org/hackers/2203/18220.html
> 

[dev] [dwm] possible regression in 8806b6e

[Ethan Marshall]

Hi all,

I recently noticed that certain dialog windows (such as the Chromium
system printing dialog and gpg-askpass popups) were being managed as
tiled windows, rather than floating. This changed recently, so I
bisected down to this commit:

8806b6e2379372900e3d9e0bf6604bc7f727350b is the first bad commit
commit 8806b6e2379372900e3d9e0bf6604bc7f727350b
Author: Chris Down 
Date:   Thu Mar 17 15:56:13 2022 +

manage: propertynotify: Reduce cost of unused size hints
...

dwm/dwm.c | 8 +---

Is this intended behavior? Or is this a bug introduced by this patch?

Thanks
Ethan

Re: [dev] st crashes with aerc

[Ethan Marshall]

Do the subjects of your emails contain any emoji characters by any
chance? If so, see 

Ethan

Re: [dev] [dwm] hardcoded dmenucmd && dmenumon

[Ethan Marshall]

> I agree, some advantage I can think of is it would support on a multi-monitor
> support with 10 or more monitors. Otherwise I prefer the current code.

I would suggest that the support of 10 or more monitors is not worth
the added complexity, given how small the proportion of people will be
with such hardware. Part of writing software is making compromise. For
the same reason why it is often better to use fixed-size input buffers
in C, with the risk of cutting off attempts at passing huge inputs, it
is similarly fine to assume that ten monitors is a good maximum - in
this case, anyway. Incorrect behaviour is tolerated if such behaviour
exceeds software design parameters. GIGO.

I do agree that special cases are best to be avoided, but there's
nothing really stopping you from creating another special case for
whatever applications you want to spawn on a specific monitor, passing
such a parameter.

Ethan

Re: [dev] Is there a text editor following the UNIX philosophy?

[Ethan Marshall]

> Acme looks extremely neat. Mouse
> chording is a strange concept (which doesn't play nicely with my
> laptop mouse)

This is something that I fundamentally disagree with the designers of
acme on, actually. I think that mouse "chording" or mouse-based
shortcuts of any kind are slow and wasteful of precious time.

When entering text, you keep your hands on the keyboard. I see no reason
why we should introduce yet another input device for simply editing or
transforming the text. This is why so many programs naturally gravitate
toward cursor-addressed, textual editing. vi is designed to keep your
fingers on the home row when moving the cursor, so touch typing is meant
to be easier. Not only is this a stroke of genius (something that I feel
Emacs never succeeded in), it also has wide, practical implications on
your editing of text. Why should I reach for a mouse to cut the previous
section of text when I can keep using the current input device? Rather
than moving my hands over an inch, instead I can not move them at all
and get the same result, the only requirement being that I press escape
first.

The usual counter-argument for this is that the keyboard is an imperfect
device for this situation, as it was not designed for anything but
inputting characters. So - in theory - the time saved from using a
device meant for this purpose should be better. However, practice again
teaches us that this is not the case. Mice are the bane of most users'
lives when they are forced to use them for editing text. You have to
take your hand off the keyboard, move them to some arbitrary location,
correctly manoeuvre the mouse, move back to the initial position and
finally edit your text. After all this, you may have to repeat the
process to navigate to the end of the text.

Even if the mouse were, in fact, the perfect time-saver that we are
told, it is not designed for such shortcuts and chording. The mouse has
three buttons. These were intended with three very clear purposes. The
keyboard usually has 104+ keys on it for usage in key shortcuts. The
mouse? Three. If we assume chording, a theoretical maximum of nine
shortcuts. However, to access them, you have to memorize a nonsensical
pattern of M1-M2 (Emacs style). Instead, to delete text in my silly,
inefficient visual editor, I just press d on my keyboard.

This may just be me being a perfectionist who likes to edit back what he
has just written, or it may just be something that I feel personally
about mice, but I cannot understand why you would build an editor for
programmers which does not use keyboard bindings. 

I have tried acme and sam. Both have their benefits, and I like the some
of their ideas. I tried acme for equal to or greater than the amount of
time which I spent learning vi(m) - and I just cannot like it.

Ethan