a brief reflection on balance
Contemplating things that are in a state of balance evokes serenity. It can also provide wonder and enjoyment, such as when watching someone walk a tightrope high above the ground or execute a particularly tricky bit of gymnastics in a game of sport. There is also an inherent sense of tension within systems in balance: the sweet spot that is neither too far one way or the other; a counterpoint found for every force that pulls or pushes.
Not only physical objects can be in balance, of course. Systems can be in balance, communities can show balance in their dynamics and people can demonstrate balance in their thoughts, actions and intentions. From such balance, great things can come forth.
on the morning that a release is made
Today the 4.10 releases of KDE's Platform, Workspaces and Applications were announced. People started sharing the link online and users of KDE software began downloading the anticipated release. I visited the release announcements and found myself staring at this gorgeous shot:
.. and it was only a few more minutes until I stumbled upon this funny bit of Onion-style satire: "Arch
Servers Went Down As KDE 4.10 Is Released" which caused me to, quite literally, laugh out loud.
We'd just put out a great release (after which one tends to feel something like this), I had been looking through a really well done set of release notes and then I was laughing along with others in our community ... which reminded me of something I love about KDE, something that keeps so many of us around through the years, something that powers the engines that make these releases and something that is really easy to forget because it's always there ...
counterpoints using "and"
KDE is often serious, and it is also often light-hearted. We're confident in decisions we make, and we're also keen for input from others. We love what we make, and we are never so satisfied as to think we're done. This gives us the drive necessary to keep pushing forward and improving.
We embrace the future in our plans and products, and we respect our roots and the present we live in. We have "big vision" projects that have equally large aspirations, and we also have stuff that's just plain fun and geeky. This allows us to build a future for KDE without losing touch with what we have.
We value and practice collaboration, and we encourage personal responsibility. We share successes and failures, and we highlight individual achievements. We cheer each other on, and we provide critical feedback. We support our successes loudly, and we acknowledge our failures. We're consistent on politically tinged issues that matter to us such as Freedom, and we maintain a pragmatic focus on technology. This grants us momentum and direction.
We've been a leader in the Free software ecosystem in terms community governance, and we're also a bit organizationally chaotic. We invent what we need, and borrow good ideas from where ever we can. We have large numbers of volunteers, and we have lots of entrepreneurs. We have people with lots of experience, and people who are looking for it. We celebrate diversity, and we value unity. This provides us with a rich melting pot of ideas and motivations to draw from.
the way you make me feel (and other 80s music)
None of the above are things I wish KDE did, or KDE should do, or KDE could do .. they are things KDE has been doing. KDE is not perfect nor perpetually in a state of unnaturally precise balance .. but it's hard to miss that 15 years on, through all sorts of maturing and meandering, we've just released a fantastic set of software with a shiny 4.10 sticker on it, we're working on a 5.0 inspired by where we see ourselves going and reflective of lessons we've learned, and we still manage to have a good laugh with each other, still ask and answer questions of each other, and still find reasons to come back and make another commit.
After all these years we're still one cohesive (meta-)community interacting with each other and working on an increasingly diverse set of projects that hold together thematically.
.. and that is what it meant to me when I saw "The KDE Community proudly announces the latest releases of .." appear on my laptop's screen this morning. You know, just another day at the office. :)
Thank you to everyone who made this release possible with efforts great and efforts small. I can't wait for the next one!
20 comments:
Now waiting for KDE 4.10 to pop up in the Kubuntu ppa...
With 4.10 KDE really shines! Thanks a lot to all the developers for all the effort you put in!
PS: Only hope FreeBSD support won't be dropped!!
Aaron, you made ME smile today. You're right, I'm happy and proud to be part of KDE!
Grouphug!
@Alliance: they are there now! :)
@P. Jay: FreeBSD support will be there for as long as people support it .. which I imagine will be quite some time yet.
@Jos: Aaaw :) Thanks for the eHug ..
@Aaron Seigo: Good to hear.
I am just a little worried when I read things like KDE devs not accepting patches from FreeBSD devs because they don't want too many ifdefs (though this was 2011:-)) in their code. Or using tech exclusive to linux (talking about systemd for example). I mean, do devs think of FreeBSD if they code for KDE or don't they care all too much and mosttly focus on linux nowadays?
Anyway, gotta go and upgrade my working machine to 4.10 now. Really looking forward to it! I simply love KDE!
@Alliance: Think packages are already in backports!
@P. Jay: patches do need to provide some level of cleanliness; but we still merge patches from various OSes (i know i have several times, in fact).
systemd: we're working on support for it in Plasma Active now. i really don't think we'll ever rely on it exclusively, however, particularly for Desktop.
@Aaron Seigo: Thanks a lot for clearing that up! It's much apprechiated!
RocK on!
@P.Jay: see my post about a recent breakage on Google+: https://plus.google.com/115606635748721265446/posts/9vz1YPf2HpT
There's a good comment from Albert there: "Maybe someone can provide a FreeBSD build bot for http://build.kde.org/ ..."
Help on that would be quite appreciated
@P.Jay: some more thoughts about "Only hope FreeBSD support won't be dropped!!"
The non-Linux OS need to fix their graphics stack and catch up. At least KWin will very soon start to require KMS and Wayland and I won't add ifdefs for it as Wayland will become our primary windowing system (I informed packagers about it some time ago).
In fact KWin already has for the free drivers a runtime requirement on KMS (if OpenGL compositing is used) as the behavior of a non-KMS driver is just undefined. Nobody has tested that for years as it just doesn't exist on Linux any more.
@Aaron: can you please get rid off the CAPTCHA?
@Martin Graßlin: I am sad to hear, that wayland will be the primary windowing system for KDE. In fact I think, that though I agree, there should be a modern successor to X, wayland is a dead end. At the moment, sinve there is no such modern successor available, I hope for KDE to be an X based system.
@Christof Donat: Wayland is a modern successor to X. You could just call it X12.
@Martin Graßlin: You might be true, that Wayland might become the successor of X11, but in my view it is not a modern one. There are aspects that Wayland is pretty good at - e.g. the handling of input devices, but the issues I have with it weigh heavier:
1. I think that compositing is just one minor aspect of a windowing system. Everything else is left for the applications and toolkits. Those toolkits will have very different rendering quality. I am sure, Qt will be top with its rendering quality and eventually GTK will compete, but there are quite some other toolkits out there. There is WxWidgets, Wine, does LibreOffice still have its own toolkit? etc. I don't expect all of these toolkits to come up with a consistent high quality rendering in all the applications.
2. Multiple screens and sub pixel hinting: If I have understood it correctly, the applications render their view and Wayland places that pixmap on the screen. Well, if we have multiple screens, these screens probably have different sub pixel layouts. So while the window is moved from one screen to the other, the fonts have colorful edges, or the application has to rerender all the time, resulting in a huge amount of round trip times between the application and Wayland. Some toolkits might be good at that, but others might simply resort to do no sub pixel hinting at all resulting in worse rendering quality.
3. Scalability: As far as I understood, Wayland works pixel based, meaning that everything the application delivers is a pixmap. With evolving high resolution displays (think of modern Macs, or the Nexus 10, e.g.) this means, that we will have to rely on the toolkits to be able to scale the application to a usable size. That will not be the case for all toolkits, though I am sure, Qt is good at handling that as well. the user experience will be inconsistent based on the toolkit his applications use - something a user is not and should not have to be interested in.
I think, there is a solution for most of that. That is to have a windowing system with an modern and extensible rendering engine and a modern compositor. In that case, the application only hands over vector information to the windowing system, just like e.g. Display PDF based applications do on MacOS X. The Windowing System then can implement a state of the art renderer and whenever that one gets updated, all applications profit from that, whichever toolkit they use. The Windowing System can take care of using the correct sub pixel hinting for every screen that a part of a window is currently displayed on. The windowing System can smoothly scale any application any time according to the current needs, even with different scaling on multiple screens.
@aaron: sorry for taking over your very positive post here. The Wayland issue just popped up here and I hope to have found someone in martin with the understanding and the influence to care of my issues with Wayland.
@Christoph Donat: yes, toolkits have to do a good job. that's been the reality for years now, as virtually all rendering now *is* done client side. what we have right now is that model already, but with x11 expecting a different model and mostly getting in the way.
as for providing an intermediary rendering system (the vector system you mention, e.g.) that could just as well be done on top of wayland fwiu.
which is good. making the solution part of the display system is a rather bad idea: once in there, you can't remove it until no applications are using it, or you break all such applications. assuming that needs shift over time, carrying that becomes deadweight baggage that requires more and more workarounds. that is exactly how we got the current state of x.org.
so what can we do for an extra-display system rendering target? well, we have in-application software rendering with all the usual and well known algorithms and we have openGL. that's really all that's needed for current needs.
with QML it's all sort of a moot point one way or the other: it has a declarative model for the application and then it renders it behind the scenes "some how". in QML2, that's openGL (for whatever isn't rendered in software client side), and it works really gorgeously. including on "retina" displays.
so i think we have all the tools there already. yes, toolkits need to use them, and that would also be the case with any new system provided with the windowing system.
there is no silver bullet for toolkits which aren't good, and it is not the windowing system's job to try and make such a thing.
one last note: vectors don't solve many problems when it comes to resolution independence, as we've found in Plasma :) for instance, icons. they will be pixel data for the long forseeable future. so handling icons across DPIs will always remain a job for non-vector code. we can mostly bury it in the toolkit, but even then it still pops out here and there in real world applications.
@Martin Gräßlin:
1) Thanks for the link, I will have a look at it.
2) I know it really is a sensible topic. But I am not sure from a User perspective depending on Wayland all too soon might be a good idea. I can see some problems with that:
a) Nvidia and ATI proprietary drivers don't work at the moment and I think the last statement from Nvidia was, that they won't support it as KMS would require them by design to open source some parts of their code. And Linux is definitly not usable with the open source drivers and I am pretty sure that won't change the next 20 years (except someone at Nvidia/ATI changes their mind, but highly unrealistic). So with Wayland depending on KMS I see big problems coming.
b) I am not sure how well tested Wayland is and what sort of problems with different usecases will come up when a broader audience will have access to it. You can read all kind of things here, but one will only know when time comes.
c) As Wayland depends on KMS it really makes it hard for non-Linux OS's to catch up. And that's one point I really have to criticize about Wayland: It seems to be designed with Linux only in mind and not involving others. It's really important to mantain portability for something like a display server. Especially if it wants to pull through. Hell, I am sure that not even the *biggest* Linux distributions were involved in the discussion. And I don't thing you can really pull through without a consensus of most distributions and non-Linux OS's.
Note, those points above only apply to "depending on Wayland soon" (meaning before it is very well integrated and maybe others had time to catch up; or if something different pulls through).
@Aaron Seigo: Sorry again to hijack your thread!
Best wishes,
Pj
@Aaron: Basically you are saying, that Wayland does not improve the situation on rendering compared to X11. There are still some old OpenView, Athena Widgets, Java AWT, Tk, Motif, etc. applications around that are actively used. AFAIK those toolkits do make use of the X11 rendering features. For those toolkits I would not expect them to provide a decent rendering engine in near future - eventually with Tk as an exception, but using a new one might be an option for them.
I agree, that the X11 rendering features are outdated and not of high quality by current standards. The rendering quality of the applications that use the named toolkits show that pretty well.
Anyway, setting up a renderer on top of Wayland looks like a good idea at first sight. It solves the mixed rendering quality issues. But it does not solve the issues around sub pixel hinting on multiple screens. In that case still Wayland has to tell the Renderer, which part of the window is on which screen and the renderer has to send back the rerendered pixmap. Whether that communication takes place between the application and Wayland or an intermediate renderer and Wayland does not improve things in any way. Only having the renderer and the compositor in the same process can solve that.
Eventually such a renderer could be some kind of exchangable plugin to Wayland.
With scaling I agree, that the intermediate renderer could do the scaling for the application, but it will e.g. not be able to scale parts of the application e.g. for a screen magnifyer without communication between the renderer and the magnifyer. A renderer integrated with the compositor can simply get the information from the magnifyer to e.g. render part XY of the screen magnified by Factor 4 into a given window.
About the Icons: of course the protocol should specify a function to render a pixel image to a given place at a given size. It could even include the option to have multiple images for different ranges of resolutions. The renderer would scale the image for the correct range, so that it fits the size, the application requested.
I am also not very happy for basic reasons with all the toolkits doing all the rendering themselves. That says, that there is at least as much code of rendering libraries in memory as toolkits used by running applications. I'd prefer to have one exchangable and extensible expert for rendering in the system.
For me the current state with x.org is, looking at its history, a not an undesirable one. If any software written today only reaches 50% of the lifetime of X11 an still be not completely fucked up compared to the newer competitors and keep up one or two noticeable USPs, that would be a very strong statement for the quality of that software.
There is another thing with centralized rendering. When we shortly can bring back the as it seems nowadays absurd idea of having a network transparent windowing system, such a system could have an efficient protocol like e.g. Nx. Then a simple application would not require much resources. You could have an embedded system, e.g. a router or a Home automation gedget with a GUI Application for configuration running on it. That applications would not have to do much for its GUI and could run on a pretty low end hardware.
With Wayland, even with the proposed remote desktop rake for simulating something that might at first sight feel a little bit like a network transparent windowing system, that would need too much resources on the embedded device.
@Christof Donat
Not that I really now anything about this but I saw this video from linu.xonf.au
http://mirror.linux.org.au/linux.conf.au/2013/mp4/The_real_story_behind_Wayland_and_X.mp4
I get the impression that the wayland dev don't like server side rendering and it was one of the main problem with xorg?
@Christof: "Wayland does not improve the situation on rendering compared to X11."
it improves the situation considerably: it gets out of the way. x11 gets in the way fairly regularly and applications spend time routing around it.
moreover, we have the rendering solutions we need for graphics, text, etc. and they are pretty well standardized at this point. graphics, video and text rendering are all "outsourced" already.
QML gives us non-imperative drawing (which is pretty much what you're asking for from what i can see)
the issue of sub-pixel rendering while crossing screens seems like an edge-case: if it is indeed wrong for part of the window while dragging it, we can live with that, i think. it's not a common case situation; there's no reason to invent a system to improve it.
"You could have an embedded system, e.g. a router or a Home automation gedget with a GUI Application for configuration running on it"
the time has passed on this kind of idea. what would be far more interesting is a network service that allows me to talk with it and render something on the client side to do so (or write my own thing if i wish).
Plasmoids are that thing. no need for rendering on either side of the network: push data, render locally.
data can be merged with other data; rendered GUIs can't.
@P.Jay: "So with Wayland depending on KMS I see big problems coming."
and Wayland does not depend on KMS. QtWayland runs on the raspberry pi - proprietary driver, no KMS and still: it works. Wayland is just a protocol to exchange buffers.
You are not the only one getting it wrong, there is lots of FUD around Wayland especially as people get confused about what Wayland allows and what Weston (reference implementation of a Wayland compositor) requires.
I don't see any reason why Wayland should not work with NVIDIA's driver and personally I'm sure that the driver already supports it in the NVIDIA labs.
@Aaron: Maybe I am not enough into toolkit development to understand in which way X stands in the way when you decide to do the rendering in den toolkit and only transfer images to the X Server.
Also I agree, that QML is really cool stuff, but it is on another layer in a complete software stack.
On the sub pixel rendering thing: yes, it is not a too big thing, but it does not allow for a perfect look and even when not currently dragging the window it might have parts on different screens, so the application must know and render its view accordingly. Every toolkit in every application needs to support that in order to have a decent look in the whole system. You might just recall how hard it seems to have been to move something like e.g. OpenOffice to a modernized toolkit some years ago.
The Router GUI: I see a different movement there. For me it looks like everyone is using a model similar to the one I have described, but with HTTP as protocol, HTML as content description, CSS as rendering information and JavaScript for more or less GUI logics.
Your approach would make at least three applications necessary: one for Unix/Linux, one for MacOS and one for Windows. Guess, which applications the router vendors will provide. I have such a managed switch, and am glad, that they still left the WebGUI available.
maybe our vision there even is not too much different. In my model rendering would happen on the Machine with the display as well, but the protocol and data structures would be standardized - similar to HTTP/HTML/CSS/JS, but better. Your model has many proprietary protocols with proprietary client applications for each of them.
@Josef: Yes, that dogmatism is a bit what scares my about the wayland hype. What scares me even more is how many people blindly follow that dogmas and repeat them as their mantra instead of questioning them in order to find out if they actually are an as good idea as they are sold to be.
@ Christof Donat
But as I understand it wayland is designed to work in a similar way they have forced xorg to work the last the ten years? I don't think real network tranpaens in the original way or server side rendering exist if you use a modern toolkit on xorg? Booth already work in a wayland way if you don't use xlib or motif or similar?
Post a Comment