A window can have the urgent hint set while being in a focused tag if that
window is not in focus. As a result, the urgent state should overrule the
focused state.
I also added a pretty truth table.
Don't get the socket path from cmake or from an environment variable. Instead,
get it from the polybar config. If it's not specified, the default is
/tmp/dwm.sock which is default for the IPC patch.
This way is easier for the user to configure.
To keep consistency, use functions to update all labels. Since the labels have
tokens that have to be replaced, if this needed to be changed, or if the label
updating code needed to be changed, it could easily be done in one place without
having to scour the code for all places where the label is updated. It improves
refactorability.
This decouples the token replacement of labels from other functions and keeps
that code contained to the update label functions.
Since functions like update_title_label and update_floating_label already exist,
it makes sense to stick with this pattern of using functions to update the
labels. For updating the labels in different ways, overloaded functions can
simply be used.
This label is visible when the currently focused client is in floating mode and
detached from the layout. It uses the focused_state_change_event as well as the
focused_client_change_event to check if the focused client is floating and
updates m_is_floating accordingly which will enable/disbale the floating label
in the final output.
update_floating_label is called when the floating state of the client is not
known. The function queries dwm for the properties of the focused client and
sets m_is_floating accordingly.
This fixes issue #2.
Instead of defining the event name for each event, define the command name that
is to be called for that event. This simplifies the code since many events call
the same command. It is already clear from the cmd function which event is being
registered, so it is more clear to see the association between the command and
the event in the code this way.
Rename settings and allow more flexible configuration by allowing the user to
enable click handlers for the tags and the layout label separately.
Add a scroll handler for the layout label so the user can scroll through the
available layouts. Enabling layout-scroll-wrap allows wrapping back to the
beginning/end of the array of available layouts.
next_layout and prev_layout take the address of a layout and returns the
next/previous layout in the m_layouts array if possible, wrapping if specified,
otherwise returns the same layout. This is used to for the layout scroll
handlers to cycle through layouts.
secondary-layout-symbol is the symbol of the layout to switch to when the layout
symbol is left-clicked. This symbol is used to look up the memory address of the
layout to set. The default is the monocle layout.
setlayoutsafe is the dwm command name for setting layouts. The argument is the
layout memory address. Left-clicking switches to the layout represented by
secondary-layout-symbol, and right-clicking switches to the previous layout
(specified by an argument of 0).
To keep track of the different layouts, the layouts are retrieved in the
constructor if the layout label is included and stored in m_layouts.
m_current_layout is updated with the address of the current layout.
m_default_layout is updated in the constructor to the first layout in the array
which is the default layout in dwm. m_secondary_layout is updated to the address
of the layout identified by secondary-layout-symbol.
The builder adds click handlers (if layout label is included) to the layout
symbol as described above. Left-clicking toggles between the secondary layout
and the default layout. Right-clicking toggles between the previous layout and
the current layout.
find_layout are a pair of functions for finding a layout by address or symbol
from the m_layouts array.
build_cmd simplifies building a command string and helps avoid typo errors when
adding new commands since most commands follow the same format.
Rename EVENT_LCLICK and EVENT_RCLICK and to EVENT_TAG_LCLICK and
EVENT_TAG_RCLICK for clarity and to allow specifying multiple click commands in
the future without confusion.
Also remove std:: from vector since it is not needed.
If pin-tags is set, there is no format defined for tags that are not occupied.
However defining a format for unoccupied tags makes the pin-tags setting
redundant since then the label can just be set to empty to not show unoccupied
tags.
Following the above reasoning, the pin tags setting is removed, and
state_t::NONE is renamed to state_t::EMPTY. This way if a user wants to display
empty tags, they can specify the format, otherwise they can simply set the label
to an empty string.
The command strings were not updated since the event variable formats changed.
Also, the EVENT_PREFIX already contained a dash, so an extra character would be
erased when adding 1.
Don't move the cmd string into the check_send_cmd function since if the first
event doesn't match, the cmd string would have been modified when passed to
the function again to check if the second event matches.
Remove EVENT_SCROLL_{UP_DOWN} since it is not being used.
Change EVENT_PREFIX to include dash and event names to be just the name without
the prefix, for simplified parsing. Use check_send_cmd function to parse the
cmd, using the event name as the IPC command name, and the section after the
event name to be the argument. The format of a cmd would be "dwm-<event
name>-<arg>", so the cmd can easily be translated into an IPC command.
Call member functions for all dwmipc events for better organization and to avoid
cluttering the constructor. The dwmipc event functions are now just assigned to
a lambda that calls a member function.
Add update_tag_labels function for updating the tag labels based on their state
since this code is repetetive.
Add update_title_labels function since that code is also somewhat repetetive.
Move reconnect code to reconnect_dwm for better organization.
Use pointers to m_monitors array elements instead of holding onto indices, since
most of the time, a member of the Monitor element will need to be accessed.
These variables should always hold a valid address starting in the constructor,
so checks for nullptr should not be necessary. A monitor will always be active
and the bar will always be mapped onto a monitor.
Add some comments where needed.
Reorganize the constructor into a more logical format
Only subscribe to events if their labels are included in the default format.
Follow clang-tidy warnings and use trailing return types.
Move m_ipc->get_monitors to update_monitor_ref since in most cases where the
monitor references would need to be updated using geometry, m_ipc->get_monitors
would need to be called.
This fixes issue mihirlad55/polybar-dwm-module#4 where the title would not
update if the title of the currently focused window changed. The
focused_title_change_event is raised exactly when the focused window's
title changes, so this should automatically update the title using the callback
when necessary.
The module is currently working, but not fully stable. All tags specified in
config.cmake for internal/dwm are supported. This was implemented following the
i3 and bspwm modules. There is still some cleaning/refactoring to do to polish
the module up.
* refactor(color): Use enum class for color type
* Add testcases for tag parser
* Make tag parser a pull-style parser
Being able to parse single elements at a time gives us more fine-grained
error messages, we can also parse as much as possible and only stop
after an exception.
* fix(color): Parser did not check for invalid chars
* tag parser: First full implementation
* tag parser: Fix remaining failing tests
* tag parser: Replace old parser
* tag parser: Treat alignment as formatting tag
Makes the structure less complex and the alignment tags really are
formatting tags, they are structurally no different from the %{R} tag.
* tag parser: Cleanup type definitions
All type definitions for tags now live in tags/types.hpp, the parser.hpp
only contains the definitions necessary for actually calling the parser,
this shouldn't be included in many places (only places that actually do
parsing). But many places need the definitions for the tags themselves.
* Rename components/parser to tags/dispatch
* tag parser: Cleanup
* Add changelog
The change in #2270 accidentally broke how we access module types.
module<Impl>::TYPE always points to the module superclass and it thus
accesses its empty TYPE field.
This mainly broke legacy action handling.
Ref #2270
If two WM events arrive withing 25ms of one-another, the second one does
not trigger a bar update.
The module state is still correct, it is just not reflected in the bar.
This somehow caused updates being swallowed in fluxbox, but only after
PR #882 was merged, even though that 25ms restriction existed long
before that.
Fixes#2272
Since 3.5.0, we use m_interval for a modulo operation, this crashes the
bar if the interval is 0. A non-positive interval shouldn't be allowed
anyway, so we now throw an exception in that case.
Fixes#2273
* [Temperature, Ramp] fix wrong icon for temperatures near base and warn temps
* [Temperature, Ramp] fix wrong icon for temperatures near base and warn temps
* Fix minor error
* Added WARN state for cpu module
* Implement WARN state for CPU, Memory modules, working on fs module
* Implement WARN state for fs module
* Simplify WARN state implementation for cpu and memory
* explicitly check percentage in get_by_percentage_with_borders
* Fixed silly error
* implement warn state on battery module, standardize the implementation on other modules
* minor fixes
* fix annoying error
* use more intuitive param name
* Fix percentage with borders bug
* Make requested changes
Hide the effect of warn states when unused
* Backward Compat: use no format instead of fallback label
* Reformat
* Refactor
* Reformat
* Reformat: convert tabs to spaces
* Reformat
New config option `speed-unit = B/s` will be used to suffix the upload and download speeds.
* mod::network: udspeed-unit to set network speed unit suffix
* Changed udspeed-unit to speed-unit
Only modules can now be action handlers.
This also slightly simplifies the controller because we don't need to
keep track of input handlers, we can just use the module list.
All modules now expose their actions as public static constants
Issues: The menu module no longer closes when an item is clicked (before
it would intercept any executed command and look if it matches one of
its exec commands)
This allows us to identify module by their type and it is also better to
store the module type as part of the module instead of having it
hardcoded in factory.hpp
Action strings now have the form '#MODULE#ACTION'
For example to trigger the action 'toggle' in the 'module/date' module
one would now use '%{A1:#date#toggle:}'
With this action strings can now be uniquely assigned to one module.
Fixes#1172
Any timer_module based module would sleep for the set interval and then
continue running. Depending on the start time of polybar this
sleep pattern might not be aligned, which causes such modules to always
update in a shifted manner.
Consider the date module as an example. If the update interval is set to
60 seconds and polybar was started at 13:37:37, polybar would update the
clock at 13:38:37, 13:39:37 and so on.
To make matters worse, if a module would perform lengthy checks this
interval might drift over time, causing even more inconsistent updating.
This patch extends the base module with a sleep_until method that calls
the corresponding function on the sleephandler. Additionally the
timer_module is extended to compute the remaining time until the next
interval passes and sleep accordingly.
Closes#2064
Co-developed-by: Dominik Töllner <dominik.toellner@stud.uni-hannover.de>
Co-authored-by: Malte Bargholz <malte@screenri.de>
A warning implies something went wrong and (possibly) the user should do
something about it. However, warnings are not always used this way.
For example:
* When a fallback value for a `${..}` reference is used, this shouldn't
produce a warning (or notice) since using fallbacks is not something
bad.
* pulse telling you that it uses the default sink because no sink was
specified also does not warrant a warning (even notice may be too
high).
* Whenever polybar shuts down it produces a "Termination signal
received..." warning. Since there isn't a more proper way to shut down
polybar, it should not produce a warning. Same argument for a
`screenchange-reload`
