way-cooler / way-cooler Goto Github PK
View Code? Open in Web Editor NEWWayland compositor for AwesomeWM
Home Page: http://way-cooler.org
License: MIT License
Wayland compositor for AwesomeWM
Home Page: http://way-cooler.org
License: MIT License
At the moment we rely on error logs for debugging and to provide feedback to users. @vinipsmaker has suggested removing any personal or specific information from these logs so users don't feel they have to comb through them and we don't leak any unnecessary information. He specifically pointed out the home directory/user name in the init file logs. They look something like this right now:
WARN [lua::init_path] src/lua/init_path.rs:42 $XDG_CONFIG_HOME=/home/snirk/.config, was not a valid path to a config file. Defaulting ...
TRACE [lua::init_path] src/lua/init_path.rs:47 Looking at "/home/snirk/.config/way-cooler/init.lua"
INFO [lua::init_path] src/lua/init_path.rs:49 Reading init file from "/home/snirk/.config/way-cooler/init.lua"
The logs when searching for the init file should also be improved, as this is a very common mistake that we need to be more explicit about. Logs should instead look more like:
INFO [lua::init_path] init_path.rs:40 Will search for config file at (1) $WAY_COOLER_INIT, (2) $XDG_CONFIG_HOME/way-cooler/init.lua, (3) ~/.config/way-cooler/init.lua, and default to /etc/way-cooler/init.lua
INFO [lua::init_path] init_path.rs:40 $WAY_COOLER_INIT not defined, looking in regular directories... (1)
INFO [lua::init_path] init_path.rs:42 Found environment variable $XDG_CONFIG_HOME=~/.config, but did not find ~/.config/way-cooler/init.lua (2)
WARN [lua::init_path] init_path.rs:47 The user config file ~/.config/way-cooler/init.lua was not found. Will default to /etc/way-cooler/init.lua (3)
ERROR [lua::init_path] init_path.rs:48 Could not find /etc/way-cooler/init.lua - you need the way-cooler init file to use way-cooler!
way-cooler could not find an init.lua to use. We have looked for it {list of places}. You need an init.lua file to use way-cooler.
We supply a default init.lua in our GitHub releases:
<link to this version's GitHub init file>
You should install that to /etc/way-cooler/init.lua as a backup, and copy it to your config folder {~/.config or $XDG_CONFIG_DIR if it was defined before}/way-cooler/init.lua and do your modifications there.
Alternatively, you can use the $WAY_COOLER_INIT variable when running way-cooler to point directly at the file way-cooler should use.
Those last couple of lines would be printed directly to stdout.
We should also consider compiling the default init file into way-cooler (to be used after /etc/way-cooler/init.lua
- but this raises more questions and prompts more discussion (is this a good idea for when we release different "styles"? Does this affect the discoverability of the init file? When we have more standard methods of distribution will this be a problem?)
Also, having Lua restart with a different init file during the initialization phase (i.e. "default to /etc/way-cooler/init.lua") is a separate issue.
The background image is loaded up, and then mysteriously destroyed just a moment later. This causes a segfault, and Way Cooler terminates. Tested as of 034dcbe (current master), on Arch Linux 64bit.
WORKAROUND: Set the color in the configuration file to be empty, and it should work as the background will then not load.
With Tree Paths finally merged in, containers now have the necessary information to determine which container was last active. This means switching focus will feel much more natural, as switching between different views that are children of container (or between different workspaces) will go the last active one.
Right now the only modification you can do to the placement of views is move them between workspaces. This is not entirely helpful for when you want to move them around with their other siblings or move them into sub containers.
There are some edge cases that need to be considered, but most of them should be pretty easy. We are not looking for complete feature parity with i3, but just what makes sense in this context. If it would make more sense to move it into a separate keybinding, it can be changed. For now though it will be very similar, if not identical, to how i3 works.
This will not add support for moving containers, as that requires having some visual way to view containers (#72) and some way to select parent/child containers as the active container (#73)
These are the list of features we expect to support prior to a 1.0 release:&
In addition, these external programs are needed:
Also, it would be good to have libraries for using way-cooler IPC from these languages:
Finally, although it will be a difficult undertaking, we would like to provide way-cooler compatible versions of existing X programs/configuration:
Instead of i3-style workspaces, did you consider using awesome-style tags? I found them much more useful, and workspaces can be "emulated" using tags. It's why I stick to Awesome instead of workspace-based managers.
Right now this happens because when you're not focused on a window the WM does't know which workspace to tear down before drawning the next workspace. This can be solved for now with simple boolean flags on the Workspaces to indicate if they are visible, but will be replaced with a pathing system in a couple updates.
Right now the active container will only point to view containers, which is sufficient for basic use of the tiling aspects, but we need a way for the user to select multiple containers. While easy to implement in the back end, it is blocked by #72 since we need a way to give visual feedback to the user on which windows are currently selected.
Way Cooler and rustwlc both have somewhat poor code formatting standards. While I am personally somewhat opposed to rustfmt and similar projects which limit the shape of source code, what we have right now is not very unified. We need a solid list of rules that we can point new contributors to that will be definitive. We also need to hold ourselves to these standards!
\t
, this is final.use
statements, but I've left a lot of newlines between them. Perhaps these should be cleaned up. Hopefully this becomes easier as editor support increases and we can stop typing them ourselves.use
within methods - In a couple of places where we have an import with a narrow scope, it has been nice to have a use
statement there and not at the top of the file. Should this be avoided or discouraged?mod.rs
. We should look at other crates and come up with a scheme of when to split modules into multiple files.clippy
or rustfmt
config, prevent badly-formatted code from being pushed via travis? Too extreme? I'd rather have an automated service say no than nit through a PR for formatting the way they do in wlc. This would be cool for GitHub integration (i.e. the rustwlc bot from before)#![deny(missing_docs)]
?.unrap()
and replace with a (not always helpful) .expect(message)
. Should this stay? Can we standardize error messages so there isn't as much overhead of calling .expect()
?Error
type and including messages?registry
, ipc
, lua
, and probably commands
and keys
to use a struct instead of global methods. How should we consider this for other parts of way-cooler?quickerror
or tempfile
, as we can just write impl Error for MyErrorType
ourselves, thanks, and tempfile
is std::fs::temp_path
. But I do love the json!
macro because it makes code across the IPC a lot more concise.unix_socket
stuff is in std
by now, we should get rid of thatcargo doc
with fancy flags so that non-exported code (i.e. all of it) is documented?Feel free to comment with anything I should add (or insert directly into this @Timidger)
However, app seems to be responsive. If I type Alt + Shift + Esc
it closes.
From the docker build I learned I should see a mouse pointer. Is the graphics for that mouse pointer not included in the repos or something like that? sway
works on my system and it also makes use of wlc
. So I think the error is not on wlc
. Ideas?
Just open any video (mpv -vo=wayland video_file
) and wait until finishes (or press q
) and way-cooler
crashes. If you cannot reproduce the issue just with just this info, I can look more into it (share video file, get logs, and so on).
In order to release new versions of Way Cooler quickly and efficiently (including hotfixes), and to enable releasing binaries, we should use Travis to deploy releases to GitHub. The new release cycle would look like:
init.lua
to GitHub releasecrates.io
It would be nice if Travis could also handle updating packages or other boilerplate that could accidentally be forgotten as well.
We could go all out and use some scripts to update the readme/etc with version numbers but that's not needed. Statically linking binaries is another issue so we can wait for that.
For version 0.3.3, I suggest we have:
init.lua
and maybe the basic unlinked way-cooler x86_64 linux
to the GitHub releaseIf we don't use Travis to automate anything else about our releases (like some kind of non-obsessive person), we should at least have a specific "playbook" for how we release: making a release branch, specific commits for updating the readme/docs/etc., and a specific order of running cargo publish
, etc.
After running way-cooler, I get a segmentation fault when I try to run weston-terminal
with Alt-Return
INFO [way_cooler] wlc: Activating tty [123/138]
INFO [way_cooler] wlc: WLC-1 Chose mode (0) 1920x1080 [122/138]
TRACE [callbacks] output_resolution: WlcOutput(1) from Size { w: 0, h: 0 } to Size { w: 1920, h: 1080 } [121/138]
INFO [way_cooler] wlc: EGL context is double buffered [120/138]
INFO [way_cooler] wlc: EGL version: 1.4 (DRI2) [119/138]
INFO [way_cooler] wlc: EGL vendor: Mesa Project [118/138]
INFO [way_cooler] wlc: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 [117/138]
INFO [way_cooler] wlc: EGL context (RGB888) [116/138]
INFO [way_cooler] wlc: EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR[115/138]
proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EG[114/138]
faceless_context EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_NOK_swap_region EGL_NOK_texture_from_pixmap EG[113/138]
_sub_buffer EGL_WL_bind_wayland_display [112/138]
INFO [way_cooler] wlc: GL version: OpenGL ES 3.1 Mesa 11.2.2 [111/138]
INFO [way_cooler] wlc: GL vendor: Intel Open Source Technology Center [110/138]
INFO [way_cooler] wlc: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8[109/138]
S_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL[108/138]
cil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_EGL_[107/138]
OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer G[106/138]
d_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_[105/138]
on_dxt5 GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buf[104/138]
XT_map_buffer_range GL_KHR_debug GL_OES_depth_texture_cube_map GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_separate_shader_objects GL_EXT_shader_i[103/138]
x GL_EXT_draw_elements_base_vertex GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_storage_multisample_2d_array GL_EXT_blend_func_ext[102/138]
EXT_buffer_storage GL_EXT_shader_samples_identical [101/138]
INFO [way_cooler] wlc: GLES2 renderer initialized [100/138]
INFO [way_cooler] wlc: Set new bsurface to output (1) [99/138]
TRACE [callbacks] output_created: WlcOutput(1): WLC-1 [98/138]
TRACE [layout::tree] Adding new workspace to root [97/138]
TRACE [layout::tree] Switching to workspace 1 [96/138]
TRACE [layout::tree] Found workspace 1
TRACE [callbacks] output_focus: WlcOutput(1) focus=true
INFO [way_cooler] wlc: Added output (1)
INFO [way_cooler] wlc: become active
TRACE [callbacks] output_resolution: WlcOutput(1) from Size { w: 1920, h: 1080 } to Size { w: 800, h: 480 }
TRACE [callbacks] output_resolution: WlcOutput(1) from Size { w: 800, h: 480 } to Size { w: 1920, h: 1058 }
INFO [way_cooler] wlc: Xwayland started (DISPLAY :1)
INFO [way_cooler] wlc: xfixes (5.0)
INFO [callbacks] Preparing compositor!
INFO [callbacks] Initializing Lua...
TRACE [lua] Initializing...
TRACE [lua] Lua initialization finished.
TRACE [lua::thread] Initializing...
DEBUG [lua::thread] Loading Lua libraries...
TRACE [lua::thread] Loading way-cooler lua extensions...
TRACE [lua::thread] Loading way-cooler libraries...
DEBUG [lua::thread] Entering main loop...
TRACE [lua::thread] Lua: awaiting request
INFO [callbacks] [key] Found an action for KeyPress { modifiers: MOD_ALT, keys: [Keysym(65293)] }
TRACE [callbacks] view_created: WlcView(2): "Wayland Terminal"
TRACE [layout::tree] Adding view WlcView(2) to Node { parent: 0x7f8cc8cb6bc0, val: Workspace { name: "1", focused: false }, children: [] }
TRACE [callbacks] view_focus: WlcView(2) true
TRACE [callbacks] view_request_geometry: WlcView(2) wants Geometry { origin: Point { x: 0, y: 0 }, size: Size { w: 742, h: 392 } }
TRACE [callbacks] view_focus: WlcView(2) true
...
TRACE [callbacks] view_request_geometry: WlcView(2) wants Geometry { origin: Point { x: 0, y: 0 }, size: Size { w: 742, h: 28840 } }
ERROR [way_cooler] wlc: gles2: function shm_attach at line 541: glTexImage2D(0x0DE1, 0, gl_format, pitch, buffer->size.h, 0, gl_format, gl_pixel_type, data) == GL_INVALID_VALUE
TRACE [callbacks] view_request_geometry: WlcView(2) wants Geometry { origin: Point { x: 0, y: 0 }, size: Size { w: 742, h: 31052 } }
INFO [way_cooler] wlc: Terminating wlc...
INFO [way_cooler] wlc: Terminating compositor...
INFO [callbacks] Compositor terminating!
INFO [way_cooler] wlc: Output (1) terminated...
TRACE [callbacks] output_destroyed: WlcOutput(1)
TRACE [lua::thread] Handling a request
TRACE [lua::thread] Received terminate signal
INFO [lua::thread] Lua thread terminating!
thread 'Lua thread' panicked at 'Lua thread received termination request.', lua/thread.rs:153
note: Run with `RUST_BACKTRACE=1` for a backtrace.
INFO [way_cooler] wlc: Removed bsurface from output (1)
INFO [way_cooler] wlc: Removed output (1)
INFO [way_cooler] wlc: Compositor terminated...
INFO [way_cooler] wlc: Cleanup wlc
INFO [way_cooler] wlc: Closing Xwayland
TRACE [callbacks] view_destroyed: WlcView(2)
INFO [way_cooler] wlc: Parent exit (3072)
This does not seem to be an issue specific to your project, as rust-wlc's sample project Give similar issues.
System info: Linux 4.6.3-1-ARCH, Lenovo T450s. Issue persists whether run from login shell or from an X graphical environment
We want to allow the Tree
to have a bunch of options associated with it. An extensible struct that keeps track of that would be really nice to have. It could be populated at startup by the config file and then updated through the IPC or Lua thread as needed via a Command/Property.
In order to make it extendable we probably should just not list each individual field. @SnirkImmington do you have any ideas? A HashMap
would be the easiest way to do that, though there might be a better way, especially in order to ensure that all options are set properly and that there are sane defaults.
We could make the entire struct via fancy macro that lets you specify a new option, it's type, and whether or not it's optional. Then expose a builder that fails if you try to compile it without setting one of the non-optional types. (The optional types would wrap the type in an Option
).
As of now, there is no way to restart the Lua thread or reload the config. These should both be merged into the same change.
We also need to take #57 (data race between Lua, commands, wlc) into account.
Let's keep -v
for a verbose mode
These features are needed for the Lua thread:
Arc
values from the registry to prevent some copyingMost of the value of the Lua thread comes from compatibility with the configuration, commands, keybindings, etc.
This will allow users to hide some client side borders (since clients hide them when they go fullscreen) and be sure that some client can't suddenly take control of their screen. The keybinding/command to make a view go fullscreen will still work if this is enabled, Way Cooler will just ignore the fullscreen bit on the view. This might cause issues with browser video players (i.e Youtube) if enabled.
Since the tree requires a bunch of configuration options, some struct to keep track of this, e.g TreeOptions
or something should be integrated so that these options can be added on in a non-hacky manner, see #76.
ignore_client_fullscreen_request
Our ad-hoc IPC socket does not look like it will scale well for our needs. Lets look into moving over to dbus, this crate looks mature enough to use.
Not sure what will be needed from Wayland/wlc in order to accommodate this, but it would be nice if they keys on mice could be used in Way Cooler.
This is a very sought after feature, and will need to be broken down into different tasks in order to achieve it.
This will be slightly more complicated than it is in the simple example for rust-wlc. You need to shrink the neighbors as much as you grow the window, in order to not expose the background at all. For floating windows they will be freely resizable.
To fix: if no active container, use the path to locate the place to put the window (i.e: treat the end of the path as the active container)
Right now Way Cooler only supports solid color background images. There is strange behavior when attempting to write out the image buffer after reading it from an image surface.
Weird black lines appear on the image, and the color saturation seems to be depleted though the image is discernible.
Here's an example of what the output looks like:
and here's what it's supposed to look like:
These are some features we want in the config:
$HOME/.config/way-cooler
, etc.Hey, it'd be useful for me to package this software for ArchLinux if git tags are provided. If you care about preserving the history of the project, tags are useful too.
Right now there are several niceties that can't be implemented because the way Way Cooler remembers the active container is "dumb". It's essentially just an index into the Node
, and as soon as it is removed or switches it completely forgets it.
If we promote the edge weights to be more than simple u32
s and instead complex structs that remember which of their children were accessed last we can have a far more sophisticated concept of what Node
was used last. This will allow Way Cooler to switch between containers and go back the last view that was used in that Container. It will also allow us to many more actions even if we don't have an active container but only a general path to one.
It should be possible to set windows to be floating. Floating windows are bound to the root container, and their weight is not taken into account while tiling.
Default keybinding will be alt+space
to send to floating, like it is in i3
.
This is based on the discussion in #48.
Right now it is assumed only one workspace is active at a time. In other window manangers, such as i3
and awesome
it is possible to have views not associated with the current workspace active and on the screen. i3
uses a scratch pad which essentially dissociates a view with any workspace allowing it to always be present, while awesome
enhances the concept of a workspace into the idea of a tag.
With tags, the relationship is reversed: tags are associated with views, and multiple tags can be associated with views (as opposed to a view being a child of one and only one workspace). With this relationship, you simply have to activate multiple tags and the views related to those tags will be visible on the screen. A tag is considered a super set of workspaces.
Currently, workspaces are good enough for Way Cooler, but there is interest in having a mechanism to enable views not on the workspace to be visible. In order to keep the option of tags open for the future, we'll implement an awesome-like solution as opposed to the i3 one.
Workspaces will continue to exist as they normally do, but you can have multiple of them active at a time (similar to how you can have multiple tags active at a time). You can not associate multiple workspaces to a view, you can only have multiple workspaces active (and they will continue to be called workspaces).
Hi, our projects were mentioned together here (reddit discussion). Do you want to work together on using StableGraph
instead? It's a wrapper around Graph
. Being a data structure with holes, its safe code maps somewhat less nicely to to vectors and indices (performance wise: in Graph, the bounds check is the existence check, in Stable Graph you need both the bounds check and a check on an Option).
I've already started adding some more methods for being closer to parity with Graph.
I noticed some commands don't seem to be working now (such as close window, normally alt+q) does this have to do with changes made in xkb @SnirkImmington? This also changes depending on whether running with cargo run
or cargo build
. While debugging #52 I came across this issue, so it may have to do with that as well.
Here's a list of apps that don't currently work (and any solutions to fix them, if possible). Note that these issues are probably from upstream and we can't fix them, they are simply listed here for visibility.
Please report any misbehaving apps in this thread.
TypeError: OS is null
, looks like a JavaScript error.GDK_BACKEND=x11 d-feet
(see bug report here)We should also list easy things that others can do, for example:
Result<_, GraphError::MissingParent(node)>
There have been issues when the wrong version wlc is used, and there are confused users such as #84. This could also help later with packaging Way Cooler, because we could distribute as a single binary.
This might bloat up the size of it a bit more, but it should be able to work. Do you have any strong thoughts on this @SnirkImmington?
These are the planned features for inter-process communication with way-cooler:
/tmp/way-cooler/socket
/run/way-cooler/<ID>/socket
<ID>
is.get
get values from registryset
set values in the registryexists
see if a value existsrun
to run a commandversion
to query versioncommands
to list commandsIn addition, we need an event API.
Greetings,
been itching to go wayland for so long now and when I saw something awesomewm-inspired my heart skipped a beat. I am burning to play with this thing.
For the moment, though, if I try running it on both of my up to date arch boxes, only the (purple) background shows. No other functionalities/hotkeys appear to work besides my custom cursors being used and Alt+Shift+Esc actually exiting.
This, and no discernibly different, behaviour shows whether I install from aur or via
cargo install way-cooler,
and whether run from within an x-session or on a separate tty.
Since it showed some similarity to #52 I tried with wlc versions 0.0.6 through 0.0.3 as well, no difference.
I would have tried "removing dlopen from Cargo.toml". which I interpreted as, roughly, cloning the repo,
taking things like ["client", "dlopen"]
to ["client"]
inside Cargo.toml and then doing
cargo install --path <pathtorepo>
, but the ensuing compilation fails with
Compiling way-cooler v0.3.2 (file:///home/ulmeyda/repositories/way-cooler) error:
no method named "has_parent" found for type "&mut layout::core::graph_tree::InnerTree" in the current scope --> src/layout/core/graph_tree.rs:186:43
186 | if cfg!(debug_assertions) && self.has_parent(child_ix) {
which, understandably, is what currently happens when installing from the git version aur package, as well.
Would appreciate some leads to resolve it. Am still hyped.
Many kisses
Users of proprietary Nvidia drivers will not be able to use Way Cooler. Nvidia has not released support for Wayland in their drivers, and so nouveau will need to be used. Sway does something similar already, and it would benefit debugging user issues if we include this kind of check as well.
These features are needed to use commands and keybindings (see way-cooler/tree/registry-rejson):
> ~/Development/rust/way-cooler [master] cargo build
Compiling way-cooler v0.3.1 (file:///home/leshow/Development/rust/way-cooler)
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/leshow/Development/rust/way-cooler/target/debug/way_cooler.0.o" "-o" "/home/leshow/Development/rust/way-cooler/target/debug/way_cooler" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/leshow/Development/rust/way-cooler/target/debug" "-L" "/home/leshow/Development/rust/way-cooler/target/debug/deps" "-L" "/home/leshow/Development/rust/way-cooler/target/debug/build/lua52-sys-aa34817026bf3754/out" "-L" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libunix_socket-f57ceccd621da067.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libjson_macro-c5250c7eaafd504c.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libenv_logger-bf2abd6bc9475582.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libtempfile-7cea1a50ab366cea.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblog-bf16bb9a4912b11d.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libpetgraph-ecccc010e64842ee.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libregex-9bb42fd004f4f034.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libthread_local-e5ce0d44bcaf00e6.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libfixedbitset-0ba3fe99bd419295.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libhlua-57b40b3f2598625e.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libthread_id-bcd46c79a620a618.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libwayland_client-863352c3ba8be54e.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbitflags-b8c7fb7df9b2bc2e.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libregex_syntax-6ded9701a0454251.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libnix-c1e6d03f33fcdbb4.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libcfg_if-72c1f992b13d5087.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libvoid-2cc31605fcb01ba1.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/librustwlc-102404df61ba3682.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbitflags-0e272044714c8076.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libuuid-07cb77d7842354e7.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/librand-49a08859d086fffe.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/librustc_serialize-3561541d79c18212.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblua52_sys-4555b89660e7fe43.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libaho_corasick-e528bf4fdf3954ff.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libmemchr-c555f740a543880f.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblibc-30d46fdd62f8c2eb.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libutf8_ranges-5c6a6dacba3be7ce.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libwayland_sys-a76d565bcb2f450c.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblazy_static-3a04918be71c80ee.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libdlib-2029350dd34cb019.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblibloading-ff9323b73f47a6f4.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblazy_static-359f5533c970cd71.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbitflags-75746cc7f0e9d928.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-e8edd0fd.rlib" "-l" "wlc" "-l" "wlc" "-l" "wlc" "-l" "xkbcommon" "-l" "wlc" "-l" "util" "-l" "dl" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt"
note: /usr/bin/ld: cannot find -lwlc
/usr/bin/ld: cannot find -lwlc
/usr/bin/ld: cannot find -lwlc
/usr/bin/ld: cannot find -lwlc
collect2: error: ld returned 1 exit status
error: aborting due to previous error
error: Could not compile `way-cooler`.
To learn more, run the command again with --verbose.
Pains with the init file is one of the biggest issues new users run into. If init.lua
is missing, or invalid in some way, way-cooler will crash somewhat unhelpfully. I have many ideas about making the process smother and robust that I had put off, that need to be implemented.
Included default init file
config/init.lua
into way-cooler
to use as the default init file.--default-init
flag to force using this "internal" init file (i.e. for developers, and as a first suggestion in bug reports...)--init-file=<path>
arg as an alternative to setting$WAY_COOLER_INIT_FILE
(if both are specified, only look at the command line)export-init <path>
to save this init file to disk (and consider doing it during first run/etc). Executing way-cooler export-init <path>
should not run the wm, and should be used in install scripts.--print-init
? To print directly to stdout? way-cooler export-init [-o <path>]
?way-cooler
may be provided with different default init files.Selecting the init file
stdout
if it cannot find an init file instead of logs (and use the default one anyway).XDG_CONFIG_DIR
) but cannot find init.lua
.Running initialization
format!
flag to disable it?)Because we are being called from C, we should abort instead of panic. Panicking unwinds the stack, which has undefined behavior on a stack made by C.
Fix should be bundled with #98
I'll use emacs as an example. If you edit a open file buffer in emacs, but don't save your changes, if you try to close the window (i.e with alt+q
) then a dialog box opens asking you questions on how it should deal with the file.
Here, different things can happen:
pkill emacs
, and wait for the buffer to be garbage collected.We need much more structured logging, slog looks like it has the features we want (filtering based on some meta-data, multiple-outputs so we can log to a file and keep it around if it crashes.
We should write the log output to a file, which makes it easier to see what went wrong and let us pretty print some more.
We should also make it possible to clear log output automatically if Way Cooler quit successfully, and otherwise keep it around. We can do this by stamping out /var/log/way-cooler-<timestamp>
, which will make each one unique.
This can remain configurable, in order to not chew up people's disks, or if we want to keep log output even if we successfully quit.
A status bar is needed for Way Cooler. The design is still up in the air, and this will be updated when there is more information...
These features are desired of the way-cooler tiling algorithm (see way-cooler/tree/tiling):
The code that currently deals with drawing the background (background.rs
) should be relegated to a different program/repo. Since it is dealt with as its own surface, it's best dealt as a separate client program.
There are difficulties with how to integrate this in terms of packaging with Way Cooler, but this is a discussion that would have come up sooner or later as our client programs improved.
@SnirkImmington, is there anything we can/should do now, or should we put this off until we start doing binary distributions. One immediate solution we can do, at least for Arch, is to have another package for this and mark it as "optional" for Way Cooler.
The only decorations used in Way Cooler now are drawn by client applications. This is not only looks ugly, but is a blocker for #73, which requires a visible way to show how many containers you are selecting.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.