And as soon as everyone starts using s/he, bigender people get annoyed that heshe wasn't used. It's language...it's difficult to get everyday usage "normalized" into a different direction.
I can only speak about the Rust side. Seriously, pick it up. It is more than a replacement for C. You get a total replacement of C + a loooot of extra stuff, like no null pointers, memory safety, C compatibility for FFI, iterator and list comprehension goodness, and just a lot of good practices. At least for me, Rust is the perfect mix between C and Haskell. YOu get the low level stuff of C, and the expressiveness and joy of Haskell, without all the brain-hurt from Haskell.
Side note: I do love Haskell, but let's admit it, the learning curve is pretty steep once you hit monads/comonads.
Except for 2 exceptions, only for interfacing with xlib, as the calls to rust-xlib involve raw pointers (because rust-xlib is just a plain c-binding wrapper around xlib).
The 2 exceptions are: loading of the config library. The config file is compiled to a dynamic lib at startup, and I need to read the symbol out of that library to access the configure function. The DynamicLibrary module is unfortunately unsafe. The second exception is in one of the default handler methods, managing the on-the-fly restart of the WM (akin to xmonad). This involves a call to execvp in the libc:: module, and therefore also unfortunately requiring an unsafe block (split into 2 unsafe block, for pointer handling and calling).
Xephyr is just for testing. You can run wtftw completely standalone when you use it in your .xinitrc for example.
It's still a bit buggy though. Works perfectly fine here. Been using it as my default WM for 2 weeks straight now. But some bugs do seem to creep up on other machines.
As for the xlib stuff, I can't really write tests for that. But I will write a more extensive test suite for the core components, especially the ones in src/core.rs
For the methods in window_manager.rs, they often depend on the window system, but that shouldn't be a problem as I could simply insert a dummy interface.
Tests will follow. Last weeks were just filled with thesis and preparations for my last exam. So I used the coding for relaxation and kinda omitted the tests. I know, I know...behaviour.
> As for the xlib stuff, I can't really write tests for that.
I do that by wrapping the C APIs into traits. I have some macros that generate both the proper implementations with ffi calls and mock implementations. Then I can write extensive tests for the high level binding's low level behavior using properly set up mocks.
Ok, for the dragging part I would have to come up with something, but theoretically, your desired features are possible. I just need some spare time to implement the layout plugins and come up with a good way to handle keyboard shortcuts in nested splits.
Author here. I am sorry about the confusion. It happened later in the project when I split it into 3 components (4 as soon as I add Wayland support). I should probably mention that in the Readme.
Is it really helpful to have different components of the same project in separate repositories? Are they really that independent? Four independent components for a single window manager seems a bit high to me.
Regarding modularization, I tend to prefer Fowler's criterium that a component should contain code which is usually changed together. So, if you have one component where 95% change slowly and 5% change often, you should split it. However, if you have two components that you almost always have to change at the same time, you should merge them.
You could take advantage of having a single git repo for multiple cargo packages. This has worked extremely well for me. It was a lot easier having a single git repo to manage and control but still have separate packages for each of the different pieces. You could have the main package become the executable and have the core and various other packages in there, too.
As soon as I figure out how to do that. But I need only minimal functionality, so I don't expect it to be _too_ difficult. I figured I should start with the Weston shell and figure it out from there.
The first part is merely a rough setup. Tutorial is unfinished. At the moment I am writing my thesis, but I'll try to do a few parts over the holidays.
Well, $100 million of apprenticeship grants isn't gonna cut it. The money would be better spent in developing the needed infrastructure to adopt the system. Skip state wide systems and adopt a nation wide system.
As for the "cost factor" for the companies...even if still at apprenticeship level, the people are working, even if it's just minor tasks in the first few months, so give them a damn salary. Here in Germany the average is about 700$/month on average, with salary increasing by about 50$ each year. Plus a decent chance to get a full time job at the same company after your apprenticeship is done.
The firms won't need to establish programs. The states will have to establish schools for that, not the firms.
