Commit graph

1892 commits

Author SHA1 Message Date
4cf5dccdf0 ci(Mergify): configuration update
Signed-off-by: Anas Elgarhy <anas.elgarhy.dev@gmail.com>
2023-01-29 00:25:59 +02:00
e18c162967 Fix some worinnigs 2022-11-01 19:48:08 +02:00
989751701d Improve the keybindings :} 2022-11-01 19:47:19 +02:00
37ce41dd6d Add more rules :n 2022-11-01 18:26:31 +02:00
5bb7487b40 Remove unused keys :) 2022-11-01 14:09:23 +02:00
20b68c338c Add spotify rule 2022-11-01 14:08:42 +02:00
Anas Elgarhy
0f72e5c31c
Merge pull request #13 from anas-elgarhy/improve-code
Improve the code and re format it :]
2022-10-31 19:29:07 +02:00
66047b2404 Remove the webbrowser macro 2022-10-31 19:25:39 +02:00
40b65a0171 Fixx the rules :P 2022-10-31 19:10:19 +02:00
5c398adf74 Remove garbage files 2022-10-31 17:19:51 +02:00
a7d9d11968 Add dracula theme and fix the rules 2022-10-31 17:08:04 +02:00
99f899be42 Create a basice run configration 2022-10-31 16:05:04 +02:00
50e80e07ed :\ 2022-10-31 15:44:30 +02:00
46dc9cead8 Create git ignore file :U 2022-10-31 15:40:19 +02:00
6eb5fee7de Remove the garbage files :) 2022-10-31 15:35:46 +02:00
6099f19a49 More format and more improve :D 2022-10-31 15:25:39 +02:00
44f85c76ec Improve yoo 2022-10-31 13:32:01 +02:00
0f156ff3a9 Improve the code and reformat it 2022-10-31 07:53:51 +02:00
59fa9423b5 Update stuff :) 2022-10-27 19:34:21 +02:00
c3cc2c4567 Remove the garbage files 2022-10-27 17:57:09 +02:00
b1e403689f Merge branch 'master' of git://git.suckless.org/dwm 2022-10-27 17:54:10 +02:00
Hiltjo Posthuma
50ad171eea bump version to 6.4 2022-10-04 19:35:13 +02:00
9cf8ec6fa8 Merge branch 'master' of git://git.suckless.org/dwm 2022-09-26 16:36:10 +02:00
Hiltjo Posthuma
970f376973 remove workaround for a crash with color emojis on some systems, now fixed in libXft 2.3.5
https://gitlab.freedesktop.org/xorg/lib/libxft/-/blob/libXft-2.3.5/NEWS
2022-09-17 15:32:41 +02:00
3d6ccec653 Use cmus-rpc-rs yoo 🥰 2022-08-31 16:12:07 +02:00
Stein
c2b748e793 Remove dmenumon variable
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 changes:
https://git.suckless.org/sites/commit/ed68e3629de4ef2ca2d3f8893a79fb570b4c0cbc.html

but this was removed on the basis that it was very easy to work
out and apply manually if needed.

The proposal here is to remove this dependency from dwm. The
mechanism of the dmenumon variable could be provided via a patch
if need be.

The edge case scenario that dmenu does not handle on its own, and
the effect of removing this mechanism, is that if the user trigger
focusmon via keybindings to change focus to another monitor that
has no clients, then dmenu will open on the monitor containing the
window with input focus (or the monitor with the mouse cursor if
no windows have input focus).

If this edge case is important to cover then this can be addressed
by setting input focus to selmon->barwin in the focus function if
there is no client to give focus to (rather than giving focus back
to the root window).
2022-08-28 11:39:43 +02:00
NRK
84d7322113 config.def.h: make keys and buttons const
pretty much all other variables are declared as const when they're not
modified.
2022-08-19 11:47:22 +02:00
Stein
5799dd1fca Remove blw variable in favour of calculating the value when needed
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 available layout symbols.

	for(blw = i = 0; LENGTH(layouts) > 1 && i < LENGTH(layouts); i++) {
		w = TEXTW(layouts[i].symbol);
		blw = MAX(blw, w);
	}

As such the layout symbol back then was fixed in size and both drawbar
and buttonpress depended on this variable.

The the way the blw variable is set today in drawbar means that it
merely caches the size of the layout symbol for the last bar drawn.

While unlikely to happen in practice it is possible that the last bar
drawn is not that of the currently selected monitor, which can result
in misaligned button clicks if there is a difference in layout symbol
width between monitors.
2022-08-17 13:33:57 +02:00
Stein
44adafe006 Make floating windows spawn within the monitor's window area
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 closest monitor edge.

There was an exception to this where if a top bar is used then the
window should not obscure the bar if present, which meant to place
the window within the window area instead.

The proposed change here makes it the general rule that floating
windows should spawn within the window area rather than within the
monitor area. This makes it simple and consistent with no
exceptions and it makes the intention of the code clear.

This has the benefit of making the behaviour consistent regardless
of whether the user is using a top bar or a bottom bar.

Additionally this will have an effect on patches that modify the
size of the window area. For example if the insets patch is used to
reserve space on the left hand side of the monitor for a dock or a
vertical bar then new floating clients will not obscure that area.
2022-08-12 09:02:34 +02:00
Stein
a859676ead Simplify client y-offset correction
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 the window
could be placed out of view if:
   - the window attributes have a 0 value for the y position and
   - we end up using the y position of bh (e.g. 22)

If the aim is to avoid a new floating client covering the bar then
restricting y position to be at least that of the window area
(m->wy) should cover the two cases of using a top bar and using a
bottom bar.
2022-08-10 15:31:21 +02:00
Hiltjo Posthuma
e0dee91145 sync code-style patch from libsl 2022-08-08 10:43:09 +02:00
NRK
5e76e7e21d code-style: simplify some checks
main change here is making the `zoom()` logic saner. the rest of the
changes are just small stuff which accumulated on my local branch.

pop() must not be called with NULL. and `zoom()` achieves this, but in a
very (unnecessarily) complicated way:

if c == NULL then nexttiled() will return NULL as well, so we enter this
branch:

	if (c == nexttiled(selmon->clients))

in here the !c check fails and the function returns before calling pop()

		if (!c || !(c = nexttiled(c->next)))
			return;

however, none of this was needed. we can simply return early if c was NULL.
Also `c` is set to `selmon->sel` so we can use `c` in the first check
instead which makes things shorter.
2022-08-06 16:09:01 +02:00
eb4c01d478 Change the main terminal from alacritty -> kitty 🥰 2022-08-05 21:44:03 +02:00
explosion-mental
5b2e5e7a40 spawn: reduce 2 lines, change fprintf() + perror() + exit() to die("... :")
when calling die and the last character of the string corresponds to
':', die() will call perror(). See util.c

Also change EXIT_SUCCESS to EXIT_FAILURE
2022-08-02 18:08:51 +02:00
Stein
786f6e2a6f unmanage: stop listening for events for unmanaged windows
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 0xc000003), tabbed is managed by the
window manager.
We start st being embedded into tabbed.

$ st -w 0xc000003

What happens here is that:
   - tabbed gets a MapRequest for the st window
   - tabbed reparents the st window
   - tabbed will receive X events for the window

The window manager will have no awareness of the st window and the
X server will not send X events to the window manager relating to
the st window.

There is no flickering or any other issues relating to focus.

2)

We start tabbed (window 0xc000003), tabbed is managed by the
window manager.
We start st as normal (window 0xd400005).

What happens here is that:
   - the window manager gets a MapRequest for the st window
   - dwm manages the st window as a normal client
   - dwm will receive X events for the window

Now we use xdotool to trigger a reparenting of the st window into
tabbed.

$ xdotool windowreparent 0xd400005 0xc000003

What happens here is that:
   - tabbed gets a MapRequest for the st window
   - tabbed reparents the st window
   - the window manager gets an UnmapNotify
   - the window manager no longer manages the st window
   - both the window manager and tabbed will receive X events
     for the st window

In dwm move the mouse cursor over the tabbed window.

What happens now is that:
   - dwm will receive a FocusIn event for the tabbed window
   - dwm will set input focus for the tabbed window
   - tabbed will receive a FocusIn event for the main window
   - tabbed will give focus to the window on the currently selected
     tab
   - which again triggers a FocusIn event which dwm receives
   - dwm determines that the window that the FocusIn event is for
     (0xd400005) is not the currently selected client (tabbed)
   - dwm sets input focus for the tabbed window
   - this causes an infinite loop as long as the mouse cursor hovers
     the tabbed window, resulting in flickering and high CPU usage

The fix here is to tell the X server that we are no longer interested
in receiving events for this window when the window manager stops
managing the window.
2022-08-02 18:04:56 +02:00
202d939a66
Merge pull request #11 from anas-elgarhy/fix-freez-issue
Fix freez issue
2022-08-02 12:00:52 +02:00
4ecc0d3c9e
Merge pull request #12 from anas-elgarhy/revert-9-revert-8-fix-freez-issue
Revert "Revert "Fix freez issue""
2022-08-02 12:00:18 +02:00
Anas Elgarhy
d1afe016d7
Revert "Revert "Fix freez issue"" 2022-08-02 11:59:09 +02:00
Anas Elgarhy
55e33220a7
Merge pull request #10 from anas-elgarhy/applay-keychain-patch
Fix the table
2022-08-02 11:56:36 +02:00
9260a252e1 Fix table 🥰 2022-08-02 11:51:05 +02:00
e19cff5a96
Merge pull request #9 from anas-elgarhy/revert-8-fix-freez-issue
Revert "Fix freez issue"
2022-08-01 18:58:25 +02:00
Anas Elgarhy
1ef2014240
Revert "Fix freez issue" 2022-08-01 18:58:03 +02:00
1e36145313
Merge pull request #8 from anas-elgarhy/fix-freez-issue
Fix freez issue
2022-08-01 18:56:42 +02:00
c3c5da0ae4
Merge pull request #7 from anas-elgarhy/applay-keychain-patch
Replace the keychord patch with keychain patch
2022-08-01 18:50:57 +02:00
0d2fe14e25 Test only 2022-07-31 12:48:12 +02:00
fbaab1bbe3 Up the version 🥰 2022-07-31 05:52:37 +02:00
aa5d8a8c22 🥰 2022-07-30 17:42:37 +02:00
5d3af206be Delete keychord diff file 🗑 2022-07-28 12:22:42 +02:00
b726853f33 Applay applay keychain patch 🥰 2022-07-28 12:04:30 +02:00
138bb0bb41 Merge branch 'fix-freez-issue' into applay-keychain-patch 2022-07-28 09:36:17 +02:00