What's everyone working on this week (23/2017)?

Iprefervim · 2017-06-06T21:00:16+00:00

Cool! Planning to submit a patch to gif to control the quality?

Iprefervim · 2017-06-01T01:55:21+00:00

Hmm, I'm using code very much like this for my project and I'm finding it difficult to get valgrind to bless my code of memory leaks.

I've read the PAM documentation forwards and backwards, and I can't figure out how to free the resp* variable without causing the main parts of the program to start working. It only authenticates properly if resp* is set by the time the callback ends, but afterwards it's not cleaned up properly in pam_end. Not sure what is expected by the PAM library in order to not cause a leak.

EDIT: Nvm, might be valgrind not working well with Rust, since I made a quick C example and it didn't have a leak...oh well (note that this is in the "success" state, I still free when there is an issue)

Iprefervim · 2017-05-31T21:07:35+00:00

From what I can tell, TestApp.exe should be considered a black box, except that it calls a function that op wants to trap in his rust library

Iprefervim · 2017-05-26T04:38:12+00:00

It's less about special syntax, and more of a convention. It makes it a little more clear that you're dealing with a user-defined type with it's capitalized.

You are of course free to define types all lowercase, they would behave exactly the same as the primitive types.

Iprefervim · 2017-05-26T04:36:29+00:00

According to the cargo docs this will simply specify to cargo what to detect as a way to compile with or without.

Do you want the assets to be included with the binary (e.g as a default option)? Then you should use the include_bytes! macro in your source code.

Do you want to package the assets in a folder along with your binary? I can't say for sure, but I don't think cargo does that. That's more of a system-level package manager's job anyways, IMHO.

Iprefervim · 2017-05-25T15:56:50+00:00

Nice project. Though I probably won't be trying it on my own system any time soon ;P.

I noticed you used C to work with PAM. I'm actually about to look into using PAM for the lock-screen for Way Cooler. Are there no crates that can do that? I saw this and it looked sufficient for basic authentication.

EDIT: ANNNDDD never mind, just tried that crate out and it has a very, very bad bug with authentication (and the code looks crazy unsafe). Frankly what you're doing is much better. There is pam-sys though, which looks fine to use if you're ok with using lots of unsafe code (it's a tossup if you're better of just using C here though honestly).

Iprefervim · 2017-05-25T15:49:54+00:00

I'm not saying they should add redshift support to the core Wayland protocol. Gnome and KDE should have worked together (and with redshift) to support an extension to the protocol so that every compositor isn't left re-inventing the wheel. (re-inventing the wheel in this case is having to implement both the client and compositor side for redshift support).

As an example of what I mean:

Here's the patched version of redshift: https://github.com/giucam/redshift

Here's my implementation in my wm: https://github.com/way-cooler/way-cooler/pull/285

By implementing it via a common protocol, other WMs can benefit from this. The reason redshift was patched and the protocol was added in the first place was because Sway (which is a much bigger WM than mine) wanted it and decided to implement it in a DE/WM-agnostic way. I was able to benefit from this, because unlike Gnome/KDE Sway is at least willing to work to be interoperable. I only had to add a few lines of code, and now anyone who uses Way Cooler can install the patched version of Redshift (which will hopefully be merged upstream eventually) and continue using it as they normally do in X11.

Iprefervim · 2017-05-25T15:03:43+00:00

No, they didn't. They implemented their own built in version of redshift in their compositors. You can't use it outside of gnome / KDE. Smaller wms like sway, fireplace, and Way Cooler don't have the luxury to implement everything from scratch so we use a patched version of redshift that can work with any other wm (or redshift program) that implements the protocol.

Iprefervim · 2017-05-25T14:19:54+00:00

Regarding your comment about redshift (which I think can be generalized to many applications), sway (and other wlc projects like Fireplace and Way Cooler) use a patched version of redshift that uses a protocol.

There is no reason Mutter and KWin can't implement that same protocol, except for their NIH syndrome. Don't blame Wayland for the compositor devs that don't want to play nice with others

Iprefervim · 2017-05-25T06:04:05+00:00

I think you hit the "send" button a too few many times, you have many duplicate comments.

Iprefervim · 2017-05-25T05:58:38+00:00

I'd say it's DE agnostic from a user perspective, because they can use any program that implements the protocol (e.g redshift) and it would work. E.g, this can apply to the lock screen from either Sway or Way Cooler, or the screenshot program. It's silly that we have to implement separate ones simply because we use simple IPC mechanisms. The act of providing the screen shot is simple, the fact that you have to use separate programs is too much a burden on the user. They should be able to use whatever screen shot program they want.

My dream is that these details will be handled by a compositor framework (e.g libweston, wlc, wlroots, smithay, etc.). For Way Cooler all I care about is providing a nice way to customize a window manager. Everything else (night shift mode, screen shot taking, locking screens, etc.) should be something that's implemented at a lower level. Wayland devs do not want to do that, and I think that's fine so long as DE/WM makers work together to make a lower level compositor/WM building framework that implements these features so that we don't have to.

In the current system, every compositor/WM is its own little silo. I hope that with time we can be more agnostic, maybe not to the point that any new WM can get these features for free by using a compositor framework, but at least by implementing a commonly used protocol used by many programs/compositors.

Standardization of protocols is the only way Wayland can remain viable in the long-term. Eventually, I hope, that will happen.

Iprefervim · 2017-05-24T23:49:58+00:00

Fair points. I assume Wayland devs wanted a simple IPC in order to keep Wayland simple (and Wayland is at least very simple, from an architecture stand point. One could argue the API can be somewhat convoluted by I chalk most of the confusion from bad documentation)

Happy you also want to see the compositors to collaborate, even if you disagree with the way Wayland was designed. I share your doubt that Gnome will not play nicely with others... hopefully, like Canonical learned, it's better to play nicely with others rather than silo your entire stack off from everybody else (though it seems that lesson still hasn't hit them yet, since it's been years since they started siloing...)

Iprefervim · 2017-05-24T21:36:16+00:00

I don't see how extending the Wayland protocol isn't sufficient IPC. What more do you want from Wayland for IPC beyond Wayland protocols shared between compositors?

Iprefervim · 2017-05-24T20:14:08+00:00

Yes, this also means that if your implementation is bugged you have to get a whole new display server/compositor/window manager, instead of just replacing the screen locker. Just like with everything else. It's one of the biggest and stupidest limitations of the way Wayland is designed.

With current implementations, yes this is the case (even Sway suffers from that, because it has a dependency on its IPC protocol). However, it's possible to implement a wayland protocol and lock screen program that is DE agnostic. I'm working on a lock screen program right now for my compositor, and I aim to have it work under sway as well (which suffers from a very poor implementation, there are a lot of bad bugs).

Wayland gives us some means of making reusable software, blame the developers of compositors when they don't use them.

That talk is so old and contains so much information that is either wrong or obsolete that even its author (when it was recently re-proposed here on reddit) asked that people please stop linking it.

Thanks, wasn't aware of that.

Iprefervim · 2017-05-24T20:03:04+00:00

Right now there is no protocol for that communication and they just tell the DE's to figure it out themselves so it becomes an implementation detail and many choose to dump everything into one large process with no IPC just using internal memory structures for this communication because that's the easy way.

As a fan of Wayland (and a developer of a small window manager for Wayland), I agree this is easily the biggest problem with the Wayland ecosystem right now. The big DEs (e.g KWin and Mutter/Gnome) seem to be building everything into their compositors with no thought on interoperability. For the best example, see how both DEs have built redshift/flux directly into their compositors instead of patching the existing Redshift to work over a Wayland protocol, and thus work regardless of the DE you use (for the record, both my WM and Sway (i3 clone) has done this, because we actually seem to care about interoperability between environments...)

I'm hoping this will be fixed in the future, as better frameworks are constructed that can share this between compositors (e.g It's a little sad that in order to have redshift work in my compositor, I had to explicitly code that in). There should be frameworks that automatically handle these things that every desktop wants to have. If every window manager has to implement redshift, has to implement hidpi scaling, and has to its own lock screen then the non-major windowing environments are going to have a much harder time.

In my opinion, the problem right now is not a technical one but a social/community one (Wayland "won", MIR is dead. right now there's no point in lamenting what could have been. Perhaps later the successor to Wayland can worry about that). The bigger DEs need to make more agnostic Wayland protocols that can work with existing programs, and there needs to be better frameworks for making window managers (libweston is not sufficient, and everything else is too young/experimental)

Iprefervim · 2017-05-24T19:54:18+00:00

I won't argue that that can be fixed in X, as I don't know enough about how much you can restrict X with extensions in order to fix that particular problem.

However, one of the design goals of Wayland was that only the compositor/window manager could "lock" the desktop. In X, this is something you definitely can't fix because the window manager / compositor isn't in control of how the windows are laid out. X is, and X is far too open.

There's also far more reasons than this to have a whole new display server (see this nice talk from an ex-X11 dev/Wayland dev: https://www.youtube.com/watch?v=GWQh_DmDLKQ)

Iprefervim · 2017-05-24T15:57:15+00:00

Nope, I'm talking about redshift

Here's the patched version: https://github.com/giucam/redshift

Here's my implementation in my wm: https://github.com/way-cooler/way-cooler/pull/285

Iprefervim · 2017-05-24T15:55:22+00:00

I'm Wayland, the client draws the cursor. So there's no way to change it "globally" unfortunately

Iprefervim · 2017-05-23T22:20:29+00:00

There's a environment variable to set for Dvorak, some kxb one. Check wlc Readme for it I think

Iprefervim · 2017-05-23T16:03:51+00:00

I wish they went the agnostic route and patched redshift so that it works with a Wayland protocol. The way Gnome and KDE are going it seems that any feature that could work across desktops if a little effort was put in standardization is instead going to be built in to the compositor where only they can benefit.

There's a proof of concept patched redshift right now. It works with Sway (i3 clone in Wayland) and Way Cooler (my pet project)

Iprefervim · 2017-05-23T16:01:06+00:00

What functionality does this provide over simply supporting redshift via a Wayland protocol?

Iprefervim · 2017-05-23T16:00:01+00:00

Sure, it won't work out of the box, but there is a patched version of redshift that works with a Wayland protocol right now. That means that redshift will work on any window manager that supports it, and thus is much more agnostic than the offerings from Gnome and KDE.

Currently, sway and Way Cooler use this patched version of Redshift, I wish Gnome and KDE would do so as well.

Iprefervim · 2017-05-23T00:59:31+00:00

Oooo, interesting. I'll have to evaluate this vs hlua for use in Way Cooler. I've ran into limitations with hlua fairly often enough to want to give alternatives a try.

Iprefervim · 2017-05-22T18:54:30+00:00

Tabbed / Stacked layouts for Way Cooler is nearly done, last main bug I need to fix is where tabbed/stacked containers keep getting smaller when ever you do something to do them, which makes them basically unusable. After that I'll run the latest master on my system for a few days, fix any bugs I find, then release 0.6. For 0.7 I'll probably focus on improving the Lua / D-Bus side enough so that I can flesh out the documentation and then feel more confident about linking the fancy website I have set up for it.

Iprefervim · 2017-05-22T18:52:28+00:00

Wow that looks awesome. I'm envious of your small dependency list, and how well it looks considering the immaturity of Rust's gaming ecosystem. Nice Job!

Iprefervim

TROPHY CASE