Doesn't this affect readability? Would it be easier to make the layout
symbol size 15 (one less than the monitor symbol)?
On Sat, 13 Aug 2022, 05:00 NRK, wrote:
> the dwm source code somewhat silently assumes that the symbol will fit
> into 16 bytes. but this may not be the case since users can
Hi Hijito,
I wasn't sure how big of a wall of text to put in the commit comment. Let
me clarify this first.
We have a block of code adjusting the client's starting position for
floating windows where:
- if the window position and size exceeds the right hand side of the
monitor, then we move
How about an arbitrary default size of something like MIN(TEXTW("W") * 30,
mw / 3)?
On Sat, 30 Apr 2022, 13:46 NRK, wrote:
> On Sat, Apr 30, 2022 at 01:28:49PM +0200, Hiltjo Posthuma wrote:
> > Whats your monitor resolution width?
>
> I'm currently using 1366x768. Don't think it's worth
Yes I don't think this is correct.
All tabbed is doing here is receiving a FocusIn event for the main (parent)
window and giving focus to the window on the currently selected tab.
I believe this is more of an edge case that is specifically related to dwm
in relation to using tabbed and having
For 0002 how about leaving the ellipsis_width as 0 and do this?
if (!ellipsis_width && render)
ellipsis_width = drw_fontset_getwidth(drw, ellipsis);
Moving the "..." to a static(?) const variable named ellipsis would make it
easier to replace this with something else (like the ellipsis
That ellipsis_w guard makes sense to add.
You are right in that it is simpler to call drw_text. If we make another
call to XftDrawStringUtf8 then we also need to recalculate ty.
On Sun, Mar 27, 2022 at 8:52 PM NRK wrote:
> On Sat, Mar 26, 2022 at 12:02:12AM +0100, Stein Gunnar Bakkeby wr
Hi NRK,
for the first patch, what was the incentive for making a call to drw_text
to draw the ellipsis rather than making another call to XftDrawStringUtf8?
As-is, and I am primarily thinking of the bar in dwm in this case, if you
were to have limited space and there is only enough space to
:24AM +0600, NRK wrote:
> > On Tue, Mar 22, 2022 at 06:06:30PM +0100, Stein Gunnar Bakkeby wrote:
> > > With the first patch the text is still allowed to bleed into the right
> hand
> > > side padding as long as it fits.
> > >
> > > I worked around that
trings. The second one improves
> cacloffset()'s performance. And the third improves startup time with
> larger unicode strings.
>
> Additional detailed information are written on each commit message.
>
> - NRK
>
--
Stein Gunnar Bakkeby
OpenBet Developer
bakk...@gmail.com
an just move the ellipsis rendering if statement outside of the if
(utf8strlen) { block.
On Tue, Mar 22, 2022 at 6:54 AM NRK wrote:
> On Mon, Mar 21, 2022 at 10:35:21PM +0100, Stein Gunnar Bakkeby wrote:
> > you make some interesting points. I am curious as to what your queueing
> > approach
and avoid special casing, I think a good portion of drw_text() will need
> to be overhauled to use a queue like this:
>
> struct { const char *str; int len; Fnt *fnt; } q[32] = {0};
>
> I'm not sure if such overhaul is going to be welcome or not, but if all
> of this sound
ith.
I still don't like the amount of effort required for drawing an ellipsis
though so I attached another patch file that doesn't try to draw the
ellipsis for comparison.
-Stein
On Sat, Mar 19, 2022 at 5:18 PM Silvan Jegen wrote:
> Hi
>
> On Sat, Mar 19, 2022 at 12:59 PM Stein Gunnar B
for
> the past week or so and haven't run into any issues. If someone finds
> any, feel free to send some reproduction steps.
>
> Also noticed some small white-space issue in drw.h, don't think it's
> worth sending another mail for, so I've attached the patch for it in
> this mail.
&
is context.
Thanks,
-Stein
On Tue, May 11, 2021 at 2:39 PM Hiltjo Posthuma wrote:
>
> On Tue, May 11, 2021 at 10:41:29AM +0200, Stein Gunnar Bakkeby wrote:
> > From 7fa0a12281f4b595b75e40e497919076497281e8 Mon Sep 17 00:00:00 2001
> > From: bakkeby
> > Date: Tue, 11 May 2021
>From 7fa0a12281f4b595b75e40e497919076497281e8 Mon Sep 17 00:00:00 2001
From: bakkeby
Date: Tue, 11 May 2021 10:20:23 +0200
Subject: [PATCH] Restore cursor when exiting alt mode.
If the mouse cursor is changed to a bar or an underline then st will use that
when the terminal is first opened. When
t; Can you send the last version one more time? The last sent version seems
> to
> > have garbled white-space/TABS.
> >
> > Please also write a full commit message for the full patch itself.
> >
> > After this it can be applied.
> >
> > Thanks,
> >
> > --
> > Kind regards,
> > Hiltjo
> >
>
--
Stein Gunnar Bakkeby
OpenBet Developer
bakk...@gmail.com
tion you would like to go with.
> Since like I wrote applyrules() is not run on propertynotify() like
> updatewindowtype() is. So it is not clear if such patch is a step in
> right direction.
>
> Br,
> Jakub Leszczak
>
>
--
Stein Gunnar Bakkeby
OpenBet Developer
bakk...@gmail.com
ing on the primary monitors remaining where they were.
Granted there may very well be some gotchas that I haven't thought of when
it comes to detaching and attaching monitors. Just an idea.
Thanks,
-Stein
On Wed, Oct 23, 2019 at 9:06 AM Sebastian Sareyko wrote:
>
> On Mon, Oct 21 2019, Ste
want. I want
> to use more than one screen at a time. Also that would not resolve the
> issues in screen ordering with Xinerama.
>
> Thank you for the suggestion though.
>
> --
> Sebastian
>
>
--
Stein Gunnar Bakkeby
OpenBet Developer
bakk...@gmail.com
19 matches
Mail list logo
