* eventloop: Use eventloop namespace in cpp files
* changelog: Add missing deprecated hook message
* Make eventloop and ipc classes non-copyable and non-movable
* Remove functional.hpp
* eventloop: Don't close handles in error cases
Client should be responsible for closing handles.
* eventloop: Address invalidation of handle references
Deprecates not using `polybar-msg` for IPC.
Fixes#2532Closes#2465Fixes#2504
* Create FIFO specific NamedPipeHandle subclass to PipeHandle
* Prototype SocketHandle
* Move mainloop up to main.cpp
* Pass eventloop to ipc class
* Deprecate sending ipc over the named pipe
Unfortunately, we can only show the warning in the polybar log and not
give the user any feedback because the pipe is one-way
* Move eventloop into its own namespace
* Prototype ipc socket handling
* Remove handles from ipc_client
Should be independent from eventloop logic
* Remove ipc clients when finished
* Add tests for ipc_client decoding
* Add callback for complete ipc messages
* Remove template param from mixins
* Move signal handler to new callback system
* Move poll handle to new callback system
* Move FSEventHandle to new callback system
* Move TimerHandle and AsyncHandle to new callback system
* Move PipeHandle to new callback system
* Implement socket functionality in new callback system
* Correctly reset ipc named pipe handle
* Let client close handles in error callback
* Wrap client pipe and ipc::client in connection class
* Better decoder log messages
* Socket path logic
* Fix CI warnings
* Remove UVHandleGeneric
* Fix error when socket folder already exists
* Proof of concept message writeback
* Restructure ipc files
* polybar-msg: Use sockets
* polybar-msg: Better syntax for actions
* Fix memory leak with fifo
After EOF, the pipe wasn't closed and EOF was called all the time, each
time allocating a new pipe.
* Make polybar-msg compile on its own
* Rudimentary writeback for polybar-msg
* Fix payload reference going out of scope.
* Add IPC documentation
* Cleanup polybar-msg code
* Specify the v0 ipc message format
* Close ipc connection after message
* Fix ipc tests
* Properly close ipc connections
* Fix polybar-msg not working with action string
* Write polybar-msg manpage
* polybar-msg: Stop using exit()
* ipc: Print log message with PID
* Add tests for ipc util
* polybar-msg: Print PID with success message
* ipc: Propagate message errors
* Rename ipc::client to ipc::decoder
* Rename ipc.cpp to polybar-msg.cpp
* ipc: Write encoder function and fix decoder bugs
* ipc: Use message format for responses
* ipc: Handle wrong message types
* ipc: Write back error message if ipc message cannot be processed
This only happens for commands and empty actions.
Non-empty actions are not immediately executed, but deferred until the
next loop iteration.
* Remove TODO about deleting runtime directory
The socket file is not deleted after socket.close() is called, only
after libuv executes the close callback.
So we can't just call rmdir because it will probably always fail.
* CLeanup WriteRequest
* Update manpage authors
* Cleanup
* Remove DEBUG_SHADED
Was disabled by default AND behind an #if 0
* Make TimerHandle expose more libuv functions
* Prepare for moving double clicks into eventloop
* Make eventloop available to bar
* Remove bar mutex
Everything in the bar is now in the same thread
* Move double-click handling to eventloop
* Extract double click deferred function into method
* Stop throttling clicks
* Increase double click interval to 400 and add option
double-click-interval in the bar section
Closes#1441
* Implement dimming using timer handles
* Remove taskqueue
* Remove unused dependencies
* Cleanup & Comments
The renderer now only stores the positions of the actions because that
is specific to the renderer and because the actual position can only be
finalized after all the rendering is done because intitially the
positions are relative to the alignment and not the bar.
The variables storing the current colors, attribute activations and font
were only used in a single place and can easily also be read from the
context.
This allows us to remove a lot of the state of the renderer.
* build: Add -Wsuggest-override
We should always use the override specifier when overriding virtual
functions. This helps prevent errors when a subclass tries to create a
function with the same name as a virtual function in a super-class but
with a different purpose.
* clang-format
* Upload logs on failure
* Add override to unsupported.hpp
* cmake: Make -Wsuggest-override flag conditional
* 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 %{PR} tag is introduced for this. It resets all colors as well as
the activation of the underline and overline and font.
This has become necessary because we don't track what raw tags a user
injects into the formatting string and otherwise their raw tags could
bleed through.
This doesn't touch action tags because even before raw action tags
weren't being tracked. Action tags also have the requirement that they
have to be used in pairs, so closing them prematurely could break things
(for example with click actions for the entire bar)
If any signal receiver throws an exception for any reason after
receiving a signal, no one would find out about it because the signal
emitter just ignored exceptions
Also actually delivering the signal caused some exceptions because not
all signals have a receiver.
Resolves#1593
We now take the bar position that the window manager gives us instead of trying
to calculate it ourselves. This is more correct when multiple bars are attached
to the same edge, as the window manager may move some of them in that
case (assuming override redirect is not enabled)
