Not to mention if you didn't use libc - and think of how many loc it'd need if you wanted to implement the kernel and userspace tools too!
Thankfully, we live in a world where libraries exist and we can use them to handle the low-level details, and then we only need to care about the 500 lines of meaningful application-specific logic :D
So explain the point? In several threads recently I've seen people say "The application's line count is higher if you also count the libraries as part of the application!" - I mean yeah, sure, that's a factually correct statement, but... so what?
The point is that this app is 500 lines of C but it'd be two lines of Python:
from wayland import solution_to_the_problem
solution_to_the_problem()
In this case, wlroots is literally a library for writing a compositor.
("A small demonstration of the wlroots API" would have been a fine title for this post. Pretending it's a small amount of code is silly.)
"I made a tiny webserver using only the Linux kernel" is impressive. "I made a tiny webserver using only the Golang webserver API" is not as impressive. "I made a tiny social networking website using the Golang webserver API" is heading back towards impressive.
You don't have to be impressed, but I don't necessarily think it's disingenuous. A "small" Wayland compositor which doesn't use a library like wlroots is nigh impossible. The code for handling DRM+KMS alone is over 2000 lines of code, and that's tangental to the goal of "make a Wayland compositor". I'd compare it to saying a game written with GLFW isn't impressive because they didn't do all of the work to set up an application window.
For a toy compositor, is there any reason not to just use SDL? The DRM and KMS side of things is interesting, but doesn't help much in understanding the Wayland protocol.
You certainly could make a compositor with SDL, but I don't think it would be any better than wlroots. We also provide an abstraction of the underlying window system, the same code which runs your compositor in an X11 window can also run it on KMS+DRM without any changes (the compositor in this very link can run on X11, Wayland, and DRM+KMS with no changes). It also gives you a number of useful things like an implementation[0] of xdg-shell, which alone can be a couple thousand lines long. Also, negotiating graphics resources with clients is going to require you to get into the gritty OpenGL details if you intend to be efficient (and some clients don't even support shared memory, so it's also a matter of compatability). You'd also need to implement the seat to have input support, which can be another ~1,000 lines of code. GTK+ requires the data device to be implemented as well - over 1,000 more lines of code in wlroots[2].
That being said, a simple compositor which only supports a subset of this stuff, uses SDL for rendering, doesn't support a lot of important features (like GTK+ dropdowns and context menus), and directly implements the Wayland protocols, could probably be done in one or two thoundand lines of code. In order to be equivalent in functionality to the TinyWL compositor I posted today, it would probably need to approach 5-6,000 lines.
>That being said, a simple compositor which only supports a subset of this stuff, uses SDL for rendering, doesn't support a lot of important features [...], and directly implements the Wayland protocols, could probably be done in one or two thoundand lines of code.
That's what I'm interested in. wlroots hides pretty much all of the details about what's going on. This would be more about producing an example than an actual functional compositor. My next Rust project, maybe. Or even C#, for that matter.
If you're producing an actual functioning compositor you should be using wlroots anyway. It's unopinionated, we call it "40,000 lines of code you were going to write anyway". It's not practical to make a compositor without leveraging wlroots unless you have a huge team like GNOME or KDE - this is advice from several compositors who tried and are now using wlroots.
Still, if you insist on making everything yourself, the wlroots code is pretty accessible and I've heard from people working on KDE and Mir that it's the best reference code to study for understanding how everything works and applying it to their own software.
I agree. It's a spectrum and my Python example is showing one extreme of obviously unimpressive. I was just trying to answer the comment I was responding to.
The line I'd draw is application logic (how the WM acts, how it reacts to user inputs, how it feels to the end user, the unique things which make it different to any other WM) vs library logic (the necessary groundwork which every WM is forced to implement in exactly the same way because of the protocol spec)
tinywl is 500 lines of application logic + 40,000 lines of library logic; compared to your example which is two lines, but doesn't include the application logic, which I think makes it an apples-to-oranges comparison.
I think in your rush to be sarcastic you forgot to read the part where I gave "application logic" and "library logic" some practical definitions :)
To clarify anyway - "tiling vs free-floating" is an application behaviour, "move window from (x1,y1) to (x2,y2)" is a library function; "focus follows mouse vs click-to-focus" is an application behaviour, "set_focus(window_id)" is a library function; "apps have icons vs apps have text labels" is an application behaviour, "render_icon()" and "render_text()" are library functions; etc.
As somebody who is interested in creating my own window manager, because none of the existing ones behave in the way that I want them to, I find the definition used by the author here to be very useful - the 500 lines are what I need to grok in order to build a WM which works in the way I want it to, and the 40,000 lines are what I can just call without needing to care about the internals. (To use parent's 2-line example as a counterexample - grokking those two lines is not sufficient to build the WM of my dreams)
Me too. It took a long time to update all of my account information for every website and service I use. It took me a long time to get all of my friends, colleagues, etc. notified that I had switched.
I now have a trail of being under my Lavabit account. Commits, patches, websites, services, friends all thinking I'm still under that account. Now I've got to do it once again, only a few weeks later.
Sigh. I can't blame Lavabit really. Just a situation I'd hope to avoid.
Actually, I don't think so, if he was a paying user. Everything on-disk was encrypted for paying users, and since lavabit had to shut down completely to not "be complicit in a crime against the American public", I assume that the NSL wanted them to make a change like Hushmail did in the past, to send the user's password to the server on the next login so that they can decrypt all emails.
I would assume that the NSA had already forcibly installed something that would compromise all further access to lavabit mail. Therefore the only option that doesn't reveal data is immediate shutdown.
I have my own domain name, currently hosting with Google Apps. If I get the motivation to move to another host like myself, I can do it without changing contact information.
Yeah, I thank my stars that I had the sense to do this almost 2 years ago. It really is much better. Another neat hack of using your custom domain is when people ask for your email address you can make one up without you appearing in their chat list. So for instance on Google Talk you're registered as iam@firstlastname.com, you could simply give them i@firstlastname.com so they can still converse with you (catch-alls ftw) yet they don't annoyingly appear on your Talk list.
And yeah, changing providers is just a matter of altering a field or two in the host records page.
At the moment, I accept the danger and resent myself for it. Moving to a custom domain is one step in the process, though.
And really, since all your email hops through relays constantly, the only truly effective anti-spy technology is message encryption, which wouldn't depend on where the messages end up.
