Reasoning: Since 2011 dmenu has been capable of working out which
monitor currently has focus in a Xinerama setup, making the use
of the -m flag more or less redundant.
This is easily demonstrated by using dmenu in any other window
manager.
There used to be a nodmenu patch that provided these
The purpose and reasoning behind the bar layout width (blw) variable
in dwm the way it is today may not be immediately obvious.
The use of the variable makes more sense when looking at commit
2ce37bc from 2009 where blw was initialised in the setup function
and it represented the maximum of all
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
This is a follow-up on this thread:
https://lists.suckless.org/hackers/2208/18462.html
The orginal code had constraints such that if a window's starting
attributes (position and size) were to place the window outside of
the edges of the monitor, then the window would be moved into view
at the
I think the whole block should signal the
intent that we want to have the window placed within the window
area, rather than within the monitor.
As-is if using a bottom bar then a window exceeding the bottom edge of the
monitor is allowed to cover the bar.
E.g. dwm with bottom bar and a rule to make
The reasoning behind the original line may be lost to time as
it does not make much sense checking the position on the x-axis
to determine how to position the client on the y-axis.
In the context of multi-monitor setups the monitor y position
(m->my) may be greater than 0 (say 500), in which case
This is in particular to avoid flickering in dwm (and high CPU usage)
when hovering the mouse over a tabbed window that was previously
managed by dwm.
Consider the following two scenarios:
1)
We start tabbed (window 0xc03), tabbed is managed by the
window manager.
We start st being embedded
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
it would probably make sense to only draw the
ellipsis if the available width is at least 2 * ellipsis width.
Thanks,
-Stein
On Fri, Mar 25, 2022 at 11:35 AM Quentin Rameau wrote:
> > Hi,
>
> Hi NRK,
>
> > Fixed a couple bugs/issues with the previous patches and attached
and simplify
the patch quite a bit. It would probably be best to rename the parameter in
that case.
For the third patch I didn't have anything to note, seemed pretty
straightforward.
Thanks,
-Stein
On Wed, Mar 23, 2022 at 9:14 AM Hiltjo Posthuma
wrote:
> On Wed, Mar 23, 2022 at 12:26
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
in a partly drawn
emoji for example when the ellipsis cuts it off (which I think is a fair
tradeoff).
Thanks,
-Stein
On Mon, Mar 21, 2022 at 8:15 PM NRK wrote:
> On Mon, Mar 21, 2022 at 07:00:32PM +0600, NRK wrote:
> > The only "issue" is that it doesn't render the el
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
sis should either simply be
dropped or a more simple solution should be found to indicate that the
string (typically window title) is cut.
Thanks,
-Stein
On Sat, Mar 19, 2022 at 9:09 AM NRK wrote:
> Hi all,
>
> Adding to this: I've been using this patch, both in dmenu and dwm,
mmand line you can change the cursor to a bar like this:
$ echo -ne "\e[6 q"
and I guess the expectation is that this sets the cursor what it is by default:
$ echo -ne "\e[ q"
In st the cursor becomes a block.
You can disregard this patch, it doesn't look correct in th
>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
t want it.
Best regards,
-Stein
On Thu, May 14, 2020 at 2:15 PM Jakub Leszczak wrote:
> Just to clarify. I don't mean "example" diff as the final thing that
> should be a part of mainline. It is just a draft so you could take a
> look and let me know if this is a direc
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
24 matches
Mail list logo
