Slashdot Mirror
KDE Frameworks 5.0 In Development
An anonymous reader writes "In addition to bringing up the plans for KDE on Wayland, Aaron Seigo just announced at the 2011 Desktop Summit that the KDE 5.0 Frameworks libraries are being planned for development. This central code will be developed in parallel to future KDE SC 4.x releases until it is ready, as to not cause another KDE 4.0 mistake. When the code is ready, key applications will be ported to the new interfaces."
(There's another article at IT World.)
Feels actually very very early. After 4.6 being almost identical to 4.5 regarding workflow, bugs left unpatched, and all the little issues KDE4 still has, moving to 5?
Is there a new, breaking release of Qt to catch up with like with KDE4?
While I agree to some degree, that's hardly the way to put it.
Not everyone using Linux works in IT.
It is clearly time for yet another major API change. People have been writing way too many applications for KDE 4 and this must not be allowed to continue! Having millions of apps is such a waste of effort - we're the Linux Desktop, for heaven's sake, not some lame appstore. Surely everyone can agree that having KDE developers write all the key apps is the way to go. We are the most experienced and the most knowledgeable in using the KDE API, and dammit, WHY WON'T YOU LET US HELP YOU?
It would be awesome if 5.0 were more like 3.5 again (its behaviour and settings), but with the modern graphics features of 4.0 :)
So finally somebody admits to the mistake, till now users and distributions have been accused that they didn't understand that 4.0 (or for that matter 4.1, 4.2, 4.3...). didn't mean "stable".
"It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
Yeah, let's use a patent riddled shitty clone of something Microsoft themselves are dumping.
Brilliant!
The Desktop Summit 2011 includes both Gnome and KDE developers. Is there some reason Slashdot has posted two stories from KDE talks but none from Gnome?
I'm not trying to start a G vs. K war here, I'd just like to see coverage of both.
There's no -1 for "I don't get it."
There are still not all kde 3.5 key applications in kde4 ... and now 5 ?
Kitchensync anyone,.. or similar program? How long did it take until i had a bluetooth program in kde4?
Dark ages are coming to the Linux Desktop .. Gnome 3 .. KDE 5 .... so maybe the smaller ones will rise... Enlightenment (e17), XFCE, LXDE ?
Gnome 3 is a turd... at the bottom of the ocean... covered in little fishy turds...
What causes hesitation among commercial app developers is the absolutely atrocious state of application distribution and dependency resolution. Every distribution has their own package format (or at the very least, different package names and content) and a different set of dependencies are required for every single one.
It's just not practical to target Linux as a commercial developer when you have to generate and maintain several different types of packages, their dependency lists AND the software repositories to go with them.
On Windows, I can target the largest audience with a single executable file. On Linux, I can target an insignificant desktop audience by maintaining a package for every variant of the system. So who in their right mind would think it to be cost effective to target Linux for desktop software on a commercial basis?
It depends on perception.
I read dot.kde.org regularly, and Planet KDE. Every single KDE dev was quite clear that KDE 4.0 wasn't for everyone on day one, and it wouldn't have feature parity with KDE 3.5 on day one.
Yet every single tech blogger says they were lied to in this massive fiasco that KDE 4 would be perfect on day one. Where exactly was that statement? I think the problem is that a few distros were pushing KDE 4 as a default desktop before it was fully ready for primetime, and Kubuntu in particular was shipping really broken packages.
If you got a KDE 4 desktop before you personally wanted it, or if you had a buggy desktop, then KDE 4.0 was a disaster and the devs lied, even if that really isn't the case. So Aaron is justified in saying 4.0 wasn't a disaster from a developer standpoint. They needed to get a base release out there for people to test, and for developers to develop for. That didn't mean every user would be happy with it on day one. But since people did have bad experiences, you're not going to convince any of those users that it wasn't some unmitigated disaster.
Oddly enough, the Gnome devs have sworn that one of their biggest goals of Gnome 3.0 was to avoid the KDE 4.0 disaster, and they wouldn't push a massive change out the door on day one. And yet you can argue that the Gnome 3 shell is a bigger change, and a bigger removal of features than the KDE 4 launch. And with KDE, most of those features returned in time. They just hadn't been ported over yet. Gnome 3's shell removes many basic features as a fundamental design decision.
In the end, users should make informed decisions about what desktop works best for them be it KDE 4, Gnome 3, Unity, XFCE, etc.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Gnome's mom always posts AC.
There are many freedesktop standards that cross both Gnome and KDE. Sometimes they can both agree on something that makes life easy for everyone. And sometimes they disagree.
The KDE devs for instance came out with a new systray standard that they pushed for freedesktop inclusion, but the Gnome devs rejected it.
As far as theme support, I know in KDE, there are tools to make GTK apps look native in KDE. I don't know about vice-versa.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
If you have a schedule to keep and need a reliable build system, Windows is a nightmare. Not that it can't be configured, but the amount of upkeep and virus scanners and security vulnerabilities to plug in Windows to have a safe environment for a corporate system doesn't compare well to installing the latest long term support version of Ubuntu, popping open the terminal, and typing "sudo apt-get update && sudo apt-get upgrade && sudo apt-get install build-essential" In most cases with a machine that's not more than a few years old, it's about an hour to a respectable and stable platform that you can more-or-less trust completely.
;)
And Microsoft is/was the fifth largest contributor to Linux not too long ago, if you want to keep the Microsoft ego when you migrate
Been using 3.5 Quanta and still waiting...
I read of the problems/apathy integrating Quanta into Kdevelop4...
How about just fixing the libs in Quanta 3.5 to just work in 4 and 5??? Would that be more doable?
Either that or someone needs to make a suitable alternative.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
Yet every single tech blogger says they were lied to in this massive fiasco that KDE 4 would be perfect on day one. Where exactly was that statement? I think the problem is that a few distros were pushing KDE 4 as a default desktop before it was fully ready for primetime, and Kubuntu in particular was shipping really broken packages.
Most notably in the 4.0 release announcement. It didn't state it was perfect, but it sure didn't give the impression that it wasn't ready for normal users. see: http://www.kde.org/announcements/4.0
In addition, the KDE team had been pimping the 4.0 release for months prior to the actual release date. When the betas were released in a horrifically unfinished state, users were told to keep calm because they were just betas, not the final release. When the final release was released, users were told to keep calm because it was never meant to actually be used by users. When 4.1 was released, users were told to keep calm.... and so on.
I think what actually happened is that the KDE team was very rushed at the end as they neared the release date, and decided to just dump out what they had rather than delay. After all, the google kde4 release party had already been planned and scheduled.
So Aaron is justified in saying 4.0 wasn't a disaster from a developer standpoint.
No, he isn't. After taking a step back and looking at the whole debacle of 4.0, it's simply stubborn to claim that it wasn't a total disaster, or at the very least misguided.
Most notably in the 4.0 release announcement. It didn't state it was perfect, but it sure didn't give the impression that it wasn't ready for normal users. see: http://www.kde.org/announcements/4.0 [kde.org]
They made countless comments leading up the 4.0 release that it wouldn't have feature parity on day 1, and that it wouldn't be for everyone on day 1. Just because they didn't repeat those statements in the release announcement doesn't mean they lied.
In addition, the KDE team had been pimping the 4.0 release for months prior to the actual release date.
The KDE team was bragging that the 4.0 release would feature a lot of new tools under the hood like Solid, Phonon, Akondi, Nepomuk, Plasma, etc. Those tools would help developers make killer KDE apps. They didn't claim that everyone was already ported over. Claiming otherwise is the lie here.
No, he isn't. After taking a step back and looking at the whole debacle of 4.0, it's simply stubborn to claim that it wasn't a total disaster, or at the very least misguided.
You have to have a release for developers to build off of. Would you have preferred that they didn't release? It would have taken that much longer to reach feature parity then. And it wasn't like KDE 3.5 disappeared overnight. No one forced you to migrate any faster than you wanted to. In fact, KDE 3.x series is still maintained by others.
http://www.trinitydesktop.org/screenshots.php
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Qt has a -platform commandline arg to choose between X and Wayland. It can also be set globally. It is reasonable (given historical choices with regard to Qt and KDE) that KDE may well choose that same option as well.
Lots of fearmongering, and now you are greatly afeared. Might want to wait to see what develops rather than reflexively prognosticate doom.
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Many people have suggested what you just have. It's never worked before and there's no reason to think it will work now.
Your statement about running KDE apps on GNOME and vice-versa does puzzle me though. Right now I've got a complete mix of KDE/Qt and GNOME/GTK+ applications running on my KDE 4.6 desktop, and all is well. They may be using slightly more resources than strictly necessary, but I don't really care about that. Stuff like the Portland Project and the Tango Desktop Project seem to have done their work in making applications both function correctly and look right on my desktop, and Oxygen-Gtk is taking that even further by making GTK+ apps look nearly indistinguishable from Qt apps. Probably best to ask someone else what's going on with the GNOME/Xfce side though.
I really don't think a merger is possible or necessary, what is necessary is more communication and cooperation between developers of various desktop environments, and in the five years I've been using Linux (sorry, GNU/Linux, I am a Debianite now...) I've seen massive strides in this. I can comfortably use whatever applications seem best regardless of widget toolkit with no worries about whether it will all function correctly, and that's good enough for me.
Exactly. And not to even mention the constantly changing APIs and desktop environments. Linux is like in some kind of eternal R&D phase...
Would you have preferred that they didn't release?
I would have preferred they had waited a few more months and had plasma be *somewhat* ready for day to day use before they crept out of beta stage. There was tons of interest in KDE4 even at beta stages, and there was nothing stopping developers from getting a head start at that point. Six more months of baking in the oven in order to avoid tarnishing KDE's good name would have been well worth it in my opinion.
It was a mistake to rush it so, and frankly the premature release wasn't even as discouraging as the fact that lead developers like A. Seigo are still too stubborn to admit it was poor judgment. That doesn't bode well for design and release planning for the future of the project.
I don't understand why people is still trying to justify the official release of an unfinished software. If you know your software is unfinished (not ready for the users) you just continue publishing betas.
Do you really believe the users must read every developer blog for each piece of software in a distro upgrade looking for notes about a final release that at some point is no longer "for normal users"?
And then it would have taken that much longer for app developers to start developing for KDE 4.0 if they didn't have a development platform to work off of. Again, they repeatedly stated that KDE 4.0 would serve as a base for developers, and may not be ready for everyday users.
You claim developers would still develop apps while KDE on the whole was in beta, but that just isn't the case. KDE Planet showed the number of commits and new developers, which exploded after the 4.0 release. Many people were holding off for an official standard. If kdelibs, phonon, plasma, etc. hadn't matured to a 4.0 release state, then many developers would hold off, which is precisely what happened.
If you didn't like the Plasma desktop on day 1, you didn't have to use it. KDE 3 was still there. Slowing down the development of applications for KDE 4 wouldn't have improved anything.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
It wasn't unfinished. It just hadn't reached full feature parity with KDE 3.5 yet. Holding off on that would mean holding off for probably 2 more years, and holding up third-party development.
Kubuntu was the first distro to ship 4.0. Let's assume you're a Kubuntu user, and you upgrade to a new distro without checking out the changes. That in and of itself rarely is wise. But clearly that is the KDE developer's faults. And the Kubuntu forums, mailing list and website have also mentioned repeatedly what a huge change KDE 4.0 is. And everyone reviewing the distro release are mentioning this. But again, you upgraded to a new distro and never read any reviews, or information about your distro specifically.
That distro made the decision to push something exceedingly new and "unfinished" as the default desktop on day 1. Again, that is the fault of the KDE developers, who don't control distros.
In addition, that distro put out exceedingly broken packages (like openSUSE was putting out very stable packages). That too, is the fault of the KDE development team even though they don't control distros.
Your logic is that if you made no effort to find out any information on what you were installing, then someone else intentionally lied to you.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
You claim developers would still develop apps while KDE on the whole was in beta, but that just isn't the case. KDE Planet showed the number of commits and new developers, which exploded after the 4.0 release.
I never said there would the same number of developers working on KDE4 projects at that exact point in time, just that there was still a lot of interest at the beta stages. Exactly what was the massive drawback to waiting a few months until plasma was more mature and usable before release? I think avoiding the entire release debacle would have been far more beneficial in the long run versus being 2-3 months behind in development from where we are now. That's discounting that there may have been developers and users discouraged by the alpha quality of the 4.0 release and turned away from the project.
If kdelibs, phonon, plasma, etc. hadn't matured to a 4.0 release state
Plasma was no where near a release state with 4.0. It wasn't even beta quality.
I'd rather go from a fully patched Windows XP SP3 to release day Vista than from KDE 3.5.x to KDE 4.0.0, perfection has nothing to do with it. When you hit the big release drum you get compared to other big releases like Windows, OS X, Linux, OpenOffice, Firefox and so on, if OpenOffice 3.0 had been as buggy and lacked as many basic features as KDE 4.0 it'd be called a disaster too. Maybe they have the perception that through their blogging their major release should be held to a completely different standard than every other major release, but then their logic is sorely flawed. If you call it a release it will be judged by release standards, something it seems several developers still are in denial about.
Live today, because you never know what tomorrow brings
Your logic is that if you made no effort to find out any information on what you were installing, then someone else intentionally lied to you.
Your logic is that KDE wasn't intentionally trying to change the way software releases were labeled (alpha->beta->release) and used. Which they were. They moved out of the "beta" stage to a release that apparently wasn't actually supposed to be used by users. 4.1 either for that matter. Blaming the users for their lack of research on the topic is absurd.
You're missing the point.
The devs repeatedly said it wasn't for everyday use for everyone, and that it was mainly for developers to have a base to build from. No one said you had to use it at KDE 4.0.
The problem was Kubuntu shipping 4.0 when users weren't ready for it, and even worse, shipping a particularly poorly built/packaged version of 4.0.
Oddly enough, other distros didn't have that problem.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
The guy was referring to the Plasma libraries, not the Plasma desktop.
Mada mada dane.
Of course, yo could just do what Teamspeak, or Unigine or others do: Just release a tarball with the binary and most supporting files.
Any specific dependancies can be handled by the user, or in some cases, just allow the distros themselves to manage packaging your software up.
Seems to work well enough; Most Linux users don't need the hand-holding of Windows users.
And yet there are plenty of people who specifically suggest the unspoken rule of software is for end users not to use a .0 release and expect stability. I'll also note that I ran 4.0 even before the release, and didn't have issues. A big part of that was my distro. openSUSE was putting out very good KDE packages. There was a huge trend on bugs.kde.org of bugs submitted from Kubuntu that couldn't be reproduced elsewhere, and even the Kubuntu package maintainers admitted they screwed the pooch with their 4.0 packages. Kubuntu shipped a release without testing it much because the Ubuntu world loves pushing the absolute latest and greatest out before anyone else.
And KDE 4.0 did have alpha and beta releases that preceded it.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Both of those programs you listed are orientated towards developers / gamers which have a better understanding of how systems work and how to resolve dependencies than the average user. Hand-holding has nothing to do with it; it's just the target audience of those programs already knowing what they're doing.
The audience that the original post was talking about is your average user, maybe not even your average Linux user*. Software designed for the average user can't rely on them to run the program from the command line to see the "ld: library XYZ not found" message and then go hunting for dependencies. They're going to double-click the icon on the desktop and wonder like hell why the program is taking so long to start up. For an example of how confusing this is even for experienced users, you need to look no further than installing Google Chrome, only to find that you don't have libpng12 installed (but rather your distro provides libpng14 by default).
TL;DR It's a terrible installation experience when installing third-party software and average users aren't going to take the time to find out how to resolve dependencies. They just want it to work.
* Because by bringing commercial software to Linux you're increasing the number of potential Linux users as well; as an example, you only need to look at the people who are tied to Windows because a commercial or open source equivalent is not available for the software they use.
The guy was referring to the Plasma libraries, not the Plasma desktop.
Ah ok, my bad. Obviously I'm not a developer (just a finicky hyper-critical desktop linux user!), but doesn't having buggy crash-ridden software like 4.0 plasma make it difficult to develop and test your own add-ons and related software? If I want to develop desktop widgets but plasma itself was continually crashing and burning, doesn't that slow the process as well?
It very well may not if the libraries are "mature", just wondering.
You're missing the point. The devs repeatedly said it wasn't for everyday use for everyone
No, you are missing the point. What they said on their blog is almost irrelevant as long as they call it 4.0, then distros will ship it, users will use it, reviewers will review it as if it's a finished product. And then they go "you should not have shipped it", "you should not use KDE4 yet", "you should not have slaughtered it" when people do and pretend it's everyone's fault but their own. And I think you've drunk too much of the koolaid.
Live today, because you never know what tomorrow brings
It's not like having the libraries for both on your system is a huge space cost. And, quite frankly, no one does "just X" these days.
So what you're saying is that, despite the fact that proprietary vendors are NOT hesitating, that open source and free software projects need to STOP what they're doing for the sake of proprietary vendors. No. That's what Redhat, et. al. do. That's what an Ubuntu LTS is for. The greater community and the projects that distros are built upon should not be forced to bend to the desires of proprietary software vendors.
The Linux kernel sure as hell doesn't wait. And it's no worse off for it (even if you want to claim it is.)
But why should these projects go out of their way to make life easier for proprietary software vendors? Why?
Despite the fact that many vendors DO target Linux? Can you name anyone who has shied away due to the issues you describe?
Keep the ability to choose whether you want a tablet-oriented interface or not.
That's one of the reasons why many people don't consider Unity and Gnome 3 alternatives anymore.
GNOME is GNU Networked Object Model Environment. Once they dropped the goals of making it an Object Model Environment, they destroyed the rationale for it remaining in the first place. Even if the goal was to massage the ego of GNU, there was still GNUSTEP there to actually offer something that KDE doesn't, and be a viable alternative growing on the achievements of NEXTSTEP in the past. If GNUSTEP could run all GNOME and KDE applications, it would be perfect! It would offer all the features that NEXT offered, while avoiding the 'shiny' features that send some people scurrying to XFCE or TWM. Also, if GNUSTEP could be ported to Wayland, so that like the original NEXTSTEP, it has no X underpinnings or requirements, that would be even better.
On Linux, I target LSB and it just magically works with all the current major Linux distributions. I don't see what the problem is.
People who actually know how to target Linux as a whole. I don't think you qualify.
Change is certain; progress is not obligatory.
Does this, plus the previous KDE story, imply that KDE 5 will be the version that's based on Wayland, rather than X, and that any support for X apps on KDE will be via Wayland? And in the meantime, any improvements for KDE on X will be KDE 4.8 and 4.9? If that were the case, seems a good idea. Gnome was debating recently whether to support Linux-only: I think Gnome should support Minix and nothing else. Let GNUSTEP be GNU's approach to Linux, Hurd and if they wish, BSD, and let KDE cover Linux and BSD. Oh, and I hope Wayland gets ported to Minix as well. Incidentally, at what stage is Wayland currently? Will BSD be supporting it as well, or will Wayland be Linux only? Will Hurd refuse to touch it due to its use of LGPL, or will GNU try and come out w/ a variation of it that falls under GPL3? Looks like plenty of new ports & projects for the good people @ Debian - just these combos should have their hands full, let alone the various CPU architectures that'll then be thrown in.
Could you give examples of how the APIs were constantly changing in the minor versions of the major desktop environments, toolkits etc?
As hard as I look, I can't find KDE3, KDE4, GTK2, GTK3, Qt3, Qt4 changing existing APIs constantly any more than adding new API commands and fixing bugs.
If you're referring to the significant changes between the major versions, then I have to disagree there is anything in particular different going on here from other operating systems. Just look at how Microsoft changes their APIs significantly between their major versions (see Microsoft's .net technologies as an example of this).
Change is certain; progress is not obligatory.
You think that because Wayland is not networked that we're going to lose networked widgets, but that's not the case.
You see, for a long time X has become more and more client orientated. When 2D was getting replaced with compositing, the entire stream of new features actually made X.org more and more like Wayland.
Wayland is not realy what you probably think it is. Wayland is a Window Manager on top of OpenGL ES and other techniques like Gallium3D.
So where does the networking come from? Where it should have been in the first place: widget toolkits like GTK+ and Qt.
The first steps are already made: GTK+ can expose an HTML interface and KDE's Plasma desktop (which is totaly made out of widgets, including the tackbar ea.) is now networked. It will only be a matter of time before Qt becomes totaly networked. The ball is already rolling on that one.
-- conclusion --
Wayland is a Window Manager that moves beyond X.org in terms of using a modular and cleaner graphics architecture (Gallium3D shader based) and the networking goes to the widget toolkits.
Here be signatures
This is true. I read the same things and held off switching until around 4.3. By then things were mostly working pretty good. I still think that naming it 4.0 was a terrible idea. Any .0 release should not have to come with disclaimer that it really doesn't work.
User base. It's a wiki... if there is something missing, and you find out how to do it, add it.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Oh really? What package format are you using? I'd love to know as it would have to handle the resolution of dependencies regardless of what the packages were called or whether the package manager for said format was actually installed on the local system.
But why should these projects go out of their way to make life easier for proprietary software vendors? Why?
I didn't say they should. I just explained the reason, from personal experience no less, why you don't see a lot of commercial desktop software on Linux.
Despite the fact that many vendors DO target Linux? Can you name anyone who has shied away due to the issues you describe?
I think you're going to have to name a few, well-known desktop products that work on Linux, rather than the other way around (since there is no way I can determine whether other individuals or companies have been influenced for this reason).
I can tell you that I have personally though; it's not practical for a small-time developer to actually manage and maintain all of those packages in addition to providing support for Windows and Mac, especially when the Linux audience is much smaller.
To clarify this response,
You might be able to target the LSB for some essential components of Linux, like kernel interfaces and perhaps filesystem layout (and even that isn't 100% reliable between distributions)... but the moment you start calling upon dynamic libraries for image manipulation, event systems and various other functionality you run into trouble, because there's no mechanism in Linux to handle when a library file is non-existent beyond sending "ld: library XYZ not found" to stdout.
There's two ways to solve this problem essentially; design a package format which works across all distributions (can be done using a minimal bootstrap executable with the package data attached on the end) or modify the dynamic loader so that it calls upon package management to resolve the library dependencies at runtime, and prompt the user to install the designated packages (through the X server if it is running!)
I originally thought the former was a better option, but the latter seems to solve quite a few issues; third party developers can link against a dynamic library and not have to worry about whether or not it's currently installed on the system and you can easily distribute binaries without requiring any package wrapping at all. The only issue you might run into with this solution is non-native applications (such as those written in scripting languages) have no way of having their interpreter resolved since the system will treat the application as a text file until after installation.
Wayland is a Window Manager
So, what if I want to use my own window manager? I no longer get to use wayland apps? This is why the window manager and display server have been separate for so long. There's no reason to conflate the two now.
So where does the networking come from? Where it should have been in the first place: widget toolkits like GTK+ and Qt.
So every tool kit has to support networking itself, rather than just inheriting it from the display server? Why is that "where it should have been"? Every new tool kit is going to have to reinvent the wheel.
Nothing about Wayland sounds good at all to me.
Give me Classic Slashdot or give me death!
Wayland can suck it.
You think that because Wayland is not networked that we're going to lose networked widgets, but that's not the case.
It's a definite risk. However, there are many more things wrong with Wayland than just that.
You see, for a long time X has become more and more client orientated. When 2D was getting replaced with compositing, the entire stream of new features actually made X.org more and more like Wayland.
Yes: and that's not a good thing. I think personally that the new extensions are mis-designed. It would have made much more sense to keep font rendering on the server, but to update it. That is much better for remote clients.
Wayland is not realy what you probably think it is. Wayland is a Window Manager on top of OpenGL ES and other techniques like Gallium3D.
Yes, and it's not a terribly good one. For instance, using a number of tortured arguments, the geniuses behind Wayland have decided that the clients should be responsible for the window decorations. Now Linux will have the ALL the features of Windows and OSX like the one where broken applications can't be moved/resized etc. Or windows have inconsistenst snap-to-edge behaviour. And so on.
Some parts of the Wayland design are sensible: like using it top multiplex several X servers onto one physical screen. The parts where it is supposed to replace X are misdesigned by people who really ought to know better.
So where does the networking come from? Where it should have been in the first place: widget toolkits like GTK+ and Qt.
So everyone whould have to implement their own serialization, tunnelling, security and servers? Brilliant! Why didn't I think of that!
The first steps are already made: GTK+ can expose an HTML interface and KDE's Plasma desktop (which is totaly made out of widgets, including the tackbar ea.) is now networked. It will only be a matter of time before Qt becomes totaly networked. The ball is already rolling on that one.
It's astonishing that proponents of Wayland declare that it is so much better than X because for one, X is bloated and complex (yeah, maybe if you still use a Sun 3/60). Then on the other hand thay come out and suggest that the network bits should be replaced with HTML5! That is the most astonishing piece of doublethink.
Wayland is a Window Manager that moves beyond X.org in terms of using a modular and cleaner graphics architecture (Gallium3D shader based) and the networking goes to the widget toolkits
Conclusion: Wayland is a new low-level display system which is being used to replace a higher livel system (X11) in an ill-conceived and ill thought out manner that destroys many excellent features without replacing them with any credible alternative.
Wayland may look shinier, but in terms of actual usability for people like me, it will inevitably be a large step backwards.
SJW n. One who posts facts.
So, what if I want to use my own window manager? I no longer get to use wayland apps? This is why the window manager and display server have been separate for so long. There's no reason to conflate the two now.
Wayland is the compositor system. You write a wayland server in much the same way as you write a window manager, so they can be freely replaced. Apparently it takes about the same amount of code.
Which makes the claim that it is a better, simpler system rather curious.
Oh also, all the demos so far have had client-drawn decorations. Yay for broken programs having unmovable windows!
I also remember a blog post about how Wayland had got DnD working. I also find this rather shocking. I have written an implementation of XDnD which seemed able to interoperate with every client I tried it with. It is not very complex and there are some excellent example implementations out there to use as a guide. The fact that they assumed that it was blog worthy to implement DnD does not bode well for the vaunted "simplicity" of Wayland.
Nothing about Wayland sounds good at all to me.
But shiny?
SJW n. One who posts facts.
Point, however, remember that for newbies and such, installing and configuring Arch or Debian is also out of the question. So, just provide a package for recent Ubuntu releases, and a tarball for "others" if you don't want to keep sets for other distros around and tested.
Either an LSB-compliant installer or LSB-RPM (a very restricted version of the RPM format that works on every LSB compliant distribution).
LSB provides many common dependencies, any others you have require you to package the application in a similar way .app folders work on OS X and pretty much how you would provide a local library to an application on Windows.
Change is certain; progress is not obligatory.
LSB does far more than that. Just check out all the stuff you get in LSB-desktop. Everything from basic x11 libraries, widget systems like qt, gtk to advanced video manipulation libraries.
You're not following the LSB specification if you're doing it that way. You're meant to provide libraries that aren't part of the LSB with the application in question should it require one.
Using .desktop files that give the full path to the interpreter and script seems simple enough to me.
Change is certain; progress is not obligatory.
The team announced that they will be removing the mouse, instead of the mouse users are expected to use a tiny window on the screen called "the mouse", and the team said most users would not notice once they got used to it. In other news the team also announced they solved what some have perceived as annoying action where the controls for widgets would jump out like a light show.
Ya know 99% of the time all you have to do is a system restore and your back and running in less time than a smoke break, I just love it when people make out this HUGE deal with windows, like 90% of the world hasn't been using it for the last couple decades or anything.
You don't need the Plasma desktop to develop and test Plasma widgets, you only need the libraries. The Plasma desktop itself uses those libraries.
Mada mada dane.
Go back to your smartphone and leave the rest of us adults alone.
Don't developpers want a stable environment to test their (young and buggy) programs on ?
They want to debug their programs not Kwin !
What about slackware, the distro I am using did it push buggy compiles ?
... show us how to use it
The thing is i know KDE 4.x has a lot of workflow-improvements in store, but show us how to use it properly
have some podcasts set up to convert the dcop experienced guys and some for the people that really only use the bare
because that's what they have been comfortable with
You guys keep chanting the activities mantra over and over instead of virtual desktops well
The difference is with OS X they had to look for the comparatively subtle faults.
With KDE 4.0 the first release was like a schizophrenic autitistic kid that lost its memory from time to time.
Quite a number of the Debian-based systems do not include any form of RPM support (unless the user installs RPM from their repository, but in my experience it is very rarely installed by default).
Now maybe that's changed and the main Debian systems do; but that still only provides you a minimum. You can't specify package dependencies since packages are named differently between distributions (hell, they're named differently between RPM-based systems let alone Debian-based systems).
So where does that get you? You either need your package installer to know how to handle and invoke package management as well as the names that go along with it, or you bundle the libraries with your program itself. The latter is highly discouraged and frowned upon due to the conflict and library duplication that arises from it (as well as that LD_LIBRARY_PATH is considered a security issue). Even if the LSB defines that certain libraries should always exist on a Linux system, you can't guarantee that the provided libraries are of the correct version, haven't been patched by an upstream vendor (changing their external interfaces) or a variety of weird and wonderful things you can do to to make a library not work quite as it is expected to.
In the end, if you require any complex libraries (think UI), do you include their dependencies, and then those dependencies dependencies, and while you're at it, why not just ship an entire Linux distribution to make sure everything works right?
All the major debian-based ones are LSB compliant and use some RPM executable that's wrapped with 'alien' to convert the RPMs on the fly to deb and install it to non-interfering path as specified by the LSB.
I have no doubt there is some specialized distro that is meant to be a firewall only or some such and won't provide the LSB, but in those cases, you install the LSB manually and get your application magically working after it's installed. Not really a big deal.
That doesn't really matter, because LSB provides you with what you get minimum. No more, no less. If it's not provided in the LSB, you ship it with your application and it's self contained in your application path.
Very far actually, I have yet to hear anyone complain about issues with my past LSB packages.
Did you even bother reading what the LSB provides?
LSB provides an abundance of "complex libraries" to begin with. I'm not really seeing this endless amount of dependencies you're talking about, because most of the major ones are all in the LSB already and everything else generally relies on those major ones to begin with.
Change is certain; progress is not obligatory.
Looking at the LSB now, is specifies that "libpng12" should be available on a system out-of-the-box. In fact, I pointed out earlier that Google Chrome uses libpng12.
So that's at least OpenSUSE which is not LSB compliant as it provides libpng14, not libpng12 (and the difference is Chrome silently doesn't work after you install it).
So considering the second largest distribution is not LSB compliant out-of-the-box, the argument that the LSB provides everything you need is outright misleading. If all major and minor Linux distributions confirmed 100% to the LSB, you might have a point, but the fact is that they don't.
And don't say "you install the LSB manually" because the average user (not technical people) have no idea what the LSB even is or what it provides.
Well no shit, Chrome isn't compiled against the LSB. If the application isn't compiled against the LSB, it's not going to work with LSB.
If you want to compile Chromium against LSB, you would need to install the LSB development packages and enter the LSB building environment, where you build the application against the LSB libraries, the LSB glibc runtime etc.
OpenSuSE currently supports the latest LSB stable version, 4.1 fully.
Alright, then don't reference some obscure debian distributions without stating exactly which ones, where I could only assume the ones that I even knew of that were not LSB compliant, were not even used by the "average user" either (such as those debian-packaged distributions designed to be only a firewall).
Change is certain; progress is not obligatory.
The devs repeatedly said it wasn't for everyday use for everyone, and that it was mainly for developers to have a base to build from.
As both a developer and a picky user, perhaps the KDE team should NOT have called it a 4.0 release. Perhaps a 4.0-RTD or something (release to developers) -- make it obvious from the name that it's not for users. I know that KDE tried to do that with all the warnings and everything, but let's be honest... most users are stupid. Kubuntu made a hideous mistake by including it. Ubuntu's got this problem at a systemic level (ripping out perfectly good code/apps to try to establish new paradigms before they're ready to be used) so I guess it was inevitable, but perhaps if KDE 4.0 were named KDE-4DEVRELEASE or something...
I don't know. I hope that what happened with 4.x is never again repeated. 4.7 is almost out and it's still not where it was in 3.5. Lord knows software development ain't easy, and trying to write a desktop environment for a large and varied userbase is difficult to put it mildly, but I don't think KDE really helped themselves at all with 4.x. I'm your most loyal fan but even I'm starting to check out alternatives.
Did you not read what I said?
The LSB 4.1 specifies libpng12. OpenSUSE does not ship it by default (it ships libpng14). Ergo, OpenSUSE is not 100% LSB compliant.
Your assumption is that libpng12 would be exposed in the same way it would be exposed if the library was normally in OpenSuSE which is wrong. You'd need to enter the LSB environment, not OpenSuSE distribution's environment.
Change is certain; progress is not obligatory.
The real question is what happens to everybodies work when you do "a system restore" and you must have some sort of miracle network and hardware that can shove an entire image down to the disk, write it to the disk and restart in under 10 minutes. Yeah we know that 90% of the world uses windows and that's why we have so many problems with spam, ddos, virus etc, Please go back to restoring you systems in under ten minutes MULTIPLE TIMES a day because the average time that windows system remain uncompromised is about 10 minutes ( http://isc.sans.edu/survivaltime.html)
um I had to do it maybe once a month, and hey fucktard system restore doesn't wipe your work or your emails, you would know that if you got off your podium for a moment and I dunno tried it?
That's revisionist. I remember going to the KDE website when 4.0 was released, and the emphasis on KDE4 was all over the place. I was pretty naive about Desktop development, and I was confused about what was going on, and with my level of sophistication at the time, i couldn't find info on KDE3.
>>I read dot.kde.org regularly, and Planet KDE. Every single KDE dev was quite clear that KDE 4.0 wasn't for everyone on day one, and it wouldn't have feature parity with KDE 3.5 on day one. AHA! Now I get it. Go to dot.kde.org and planet KDE for information. I went to kde.org, and i got public relations hype.
This is still buggy and giving the same problems, [url]http://www.airportplus.co.uk[/url]
Airport Plus | Cheltenham Airport Transfers
Two points: Once, obvously you are still living in your mothers basement with your "dolls" given your use of foul language and likely don't have much experience dealing with hundreds of systems. Yes I mostly administer AIX/HPUX/Solaris/*BSD systems, but the MBA lusers insist on "real workstations" that run a "RealOS" Yes I have to restore these systems nearly daily because the "RealOS" is borken that they rarely get through a week without being so corrupted that I cann't let them on the network. These "real workstations" are new Dell Precision T3500's with the"latest RealOS" so don't try the get better hardware bovine excrement. Read what I wrote, "you must have some sort of miracle network and hardware that can shove an entire image down to the disk, write it to the disk and restart in under 10 minutes." Ask your System Administrator and the people that manage the network your toy sits what that means. That's what has to be done to "real workstations" running a "RealOS"
only 3 fucking days late, and you accuse me of living in mommy's basement fuck off
I am so glad you administer HPUX you must be stupid or old, are those "real worstations" some 1980's dec crap, oh no those "real" workstations are shit stain dells, I bow to your glory I really do
and when you decide to join us in year 2011 you will know there is ZERO reason to shove a full fucking disk down a network when the application is installed ON THE CLIENT already, unless your some mac fag who has to have the new X, you click 2 buttons and your horrible broken windows system unfucks itself in less than 10 min
people like you are quickly being replaced by scripts, and I thank every fucking day for that knowing there is some snide asshat self righteous sys admin looking for a fucking real job in the real world where you might get a clue
Yet another childish rant. Given that your sysadmin skill level is approaching that of a script-kidde, one day we'll meet when you and precious scripts screwup so badly I get hired to clean up your mess. Considering I get calls like that mutliple times a day from companies who's MCSA only knows a couple of buttons to press before panicing and really screwing the pooch, it won't be long