"True innovation would be to provide a script-based approach to most of the GUI stuff, e.g. nodejs/browser API.. and then provide native code layer"
We started working on exactly that ~5 years ago and the result is QML2 and Plasma (two separate things, but they work wonderfully together). As the node.js project founder said when he saw QML for the first time: "Wow, it's HTML5 done right."
So KDE is truly innovative, you're just too uninformed to have known and ~5 years too late to the suggestion table. (I'm not entirely sure how the/. smarminess works, but I gave it my best try with that last sentence.. did I succeed?;)
No, translation "we've been working very hard on this device, and will be releasing them at shipping time". We've put the Open Hardware Logo on the feature board and everyone who has participated in this project has licensed their contributions under the GPL. We're not about to start our first product by violating each other's licenses. Please, give us a bit more credit than that. Most of the people involved have been releasing things far more valuable and work intensive than this as Free software/hardware over the years, after all.
" Of course if you believe this thing will appear on time, work and ever see another module which is compatible with it I have a nice bridge here to sell you"
So, it works. How do we know? We already have finished pieces in hand and use them.
Other modules: are alread add-ons such as VGA connectors and keyboard kits in prototyping; I've already seen two more feature boards; as for other CPU cards, those are further away but on the roadmap.
Who peed in your cereal?
I know it's easier to be cynical than to be helpful, but if you support projects like this they actually do go further.
This is an engineering board, not a smartphone. If you look around what is available for prototyping and developing projects, you'll find that single core ARM is actually the common case. This is a significant amount of hardware for the market category. This is also considerably more powerful than what smartphones were shipping with 3 years ago, though today's high end phones do come with more cores.
They are similar in hardware capacity, except that Improv is modular (not everything is hardwired on one board) and is not a sold-and-forgotten piece of hardware but has an active Free software and hardware devel community around it.
> How is this thing compared (hardware wise) to Raspberry Pi ?
RPi is a single core 7o0 MHz ARM11 with 512 MB RAM and no on-board storage; Improv is a dual core 1Ghz Cortex-A7 with 1GB RAM, 4GB NAND flash and a more powerful GPU. Improv is also modular so you can swap out the CPU card as well get feature boards with additional features in future. So Improv is several times more powerful and quite a bit more flexible. You also get things like SATA with the Improv.
As for software, anything that runs on the RPi run on Improv, while the reverse is not true. Some ARM Linux OSes require hard float, such as Ubuntu, which RPi does not provide but Improv does
The announcement and website clearly state that the feature board which the EOMA68 docks to is open hardware; yes the A20 is not open hardware, and that was never stated otherwise.
That's like saying you fear Qt becoming dependent on BlueZ because some applications need some bluetooth specific features and use libbluez. Which is to say: your fear makes zero sense. Which is good, as that means you can stop being worried.
It's not either/or, but both/and. Bugs are fixed, usability is improved.. AND work is ongoing at making necessary infrastructural improvements.
If what you got from this article was "new colors! new shapes!" you have somehow misunderstood what you were seeing. The colors and shapes are completely secondary to the work being done to modularize the existing libraries and have support for hardware accelerated rendering for the entire desktop shell. The colors and shapes are parts of a test framework designed to, well, test the underlying framework; they are not a user-facing product.
Perhaps/. isn't the best place for topics that aren't about cosmetics.
As Sebastian has noted clearly time and again, the effects shown in the demo are what are used to test the framework. They are not the default effects that will be part of the actually released product. It is not unusual for framework test applications to look odd or even plain out ugly as their job is to push the framework and test the various capabilities.
So, no.. this isn't about wobbling things. It's about having a working hardware accelerated canvas that can be extended in several ways, one of which includes OpenGL shaders...
* you can rubber band in the file manager * weather works just fine with European cities. i live in one, so i know. * graphics glitches are usually driver related, but we've also fixed a lot of issues (small and large) in the least couple of years * creating a launcher -> drag it from the file manager, the launcher, from a search in krunner,... yeah, not hard.
i realize that reality often does not come into play much when people create and then post again and again these kinds of lists. really it comes down to your last point, doesn't it: you have a highly personal preference for 3.5 (which is fine) and you work backwards from that to justify it. your points, however, are outdated or were never correct.
but that's alright. one can't please everyone all the time, of course. we do have many users who are quite happy, and both sides of that (number of users and average satisfaction) appears to be growing with each release. perhaps not amazingly, it is those people, not those who generate lists for re-posting on every article they can find, who get developer focus.
We're already working on it: http://www.notmart.org/index.php/Software/KDE_on_MeeGo
We had been working previously with both Maemo and Moblin, so this in a way simplifies things a bit for us. It's early days yet, but we're making great progress. The more the merrier, so feel free to join us (you can find us in #plasma on irc.freenode.net)
it wasn't talled "the taskbar" in KDE 2 or KDE 3 either.:) in fact, Plasma calls them exactly what they were called in KDE 2 and 3: panels. the "taskbar" has always referred to the windows picker/manager. personally, i wish we'd always called it something like "windows" that was a bit more obvious.
but yes, in this case it's actually completely consistent with what's always been there.
> it started around 4.0 and 4.1, back when it was not possible to have good KDE releases
KDE specifically stated that 4.0 should not be used in production, and yet that's what a number of distributions rushed to do: place it as the default their users got when installing an OS that was intended for production use. i understand why distributions did what they did, but those are reasons not justificatons. i think a lot has been sorted out on all sides since then, and things are improving in general (though we saw a repeat of the same with pulseaudio, sadly)
we used to have that in the form of the commit digest. would be nice to see that revived by people with interest and the time.
> I want a website which displays the reported recent plasma crashes.
easily available with a query (which you can save, btw) on bugs.kde.org
> I want a website that explains me a single working methods how to set up a built environment on a free machine.
techbase.kde.org, which is linked to from kde.org
> I want an idea torrent set up for KDE.
brainstorm.forum.kde.org
> I want to see the users get involved to discuss KDE in a open and honest way.
i would, too. unfortunately that seems to require more time for research and patience for careful analysis than most computer users can manage. just because it's a GUI that you can see with your eyes and manipulate with your mouse doesn't make the topics of design immediately accessible.
> I don't want slogans and empty marketing gibberish. I want better code.
would you take both? or rather, ignore the former as they are evidently not for you and revel instead in the latter.
> I don't want a code of conduct bullshit,
i'm sorry to hear you think agreeing to treat others with reasonable levels of common-sense care is bullshit. those who spend their time working on KDE tend to feel differently about that.
> I want management by geeks and hacker ethics.
the two aren't mutually exclusive.
> I want to praise the artists which make KDE great.
> desktop widgets are basically small applications that don't scale
they scale visually, and they scale to different device form factors. if you are looking for them to scale in functionality to, say, replace Digikam or Kdenlive, that won't happen. they are helpers and quick tools. they aren't supposed to replace applications on their own, just as an application like Digikam is never going to be something you'd put in a nice photo frame device to show some photo collection:)
> use a different window manager
they aren't windows in form or function. unless you consider the objects in inkscape, oo impress, etc. to be windows as well.
> WHO WANTS TO ROTATE A FUCKING WIDGET?
while many seem to enjoy positioning photos just as they'd like on their desktop (which is a fairly minimal reason for rotation), it's actually rather useful when you have a large flat surface that lays horizontally.
given that rotation is couple of lines of code and has resulted in ~zero maintenance overhead and does not impact your usage if you don't care about rotation, this seems like a molehill rather than a mountain.
> At least with Gnome every panel and panel applet is optional
it is the same with KDE Plasma Desktop.
in KDE 3 you were always stuck with a minimum of one panel, actually, and that is gone with Plasma Desktop where you can remove all the panels if you wish.
> Context menu items, keyboard shortcuts, and drop behaviors were broken and/or different from what konq or dolphin did.
little of that was easily sharable when folderview was started. with each release, the people working on the file management components (konq, dolphin, file open/save, folderview) have been pulling this kind of code out into libkonq (in kdebase-apps) and libkfile (in kdelibs; this is actually where most of this stuff exists now).
the was pretty much the same for kdesktop in kde 3, as well. it reimplemented a lot of interaction and functionality itself, but had a number of years to get there. folderview is already more advanced at this point, which is promising.
between the modularization of these file management bits into more easily sharable libraries and the more component-centric model of plasma, i really hope we don't have to go through a similar process again for many, many years (i won't tempt fate and add "if at all";)
"What I do need is for firefox to pick up on my application preferences"
OpenSuse has this; hopefully other distros will pick this up, or maybe even firefox itself will.
"for drag and drop to be snappy and accurate and always work,"
lots of improvements have been made in various places for d'n'd.
"for ark to not suck so hard,"
it actually works very nicely in 4.4
"for my folderviews on my desktop to always be up to date, look good, not pile up icons in weird ways"
if your folderviews aren't up to date, then there's a bug in the IO plugin (or it simply doesn't support automatic updates; some network IO plugins don't)
piling up icons in weird ways sounds like a bug; hopefully you've submitted a report for it with details.
as for the semantic desktop, don't use it if it isn't useful to you. it's that simple. however, with apps starting to use it behind the scenes, you'll likely be using it without even knowing it. you'll just be finding that things work nicely and wondering how all that information gets shuttled about. an interesting use case is the groupware system (akonadi) is now using the semantic framework (nepomuk) extensively.
skanlite is what ships with KDE 4, and there recently was work started to ressurect a full "scanning workflow manager" type app (kooka+ style). aside from batch processing and OCR, skanlite does what kooka did with a rather more streamlined interface.
i can see you haven't done much porting to Qt 4, at least not of any apps with serious amounts of code in them.
"and merging fixes (tedious), but maintaining compatibility with the existing installs."
that part would be doable, yes. some people want others to do it, nobody wants to do it, however. funny that.
"Having set up family and friends with (then-latest) KDE-3.x, and all of us using customized desktops, menus, and shortcuts, we don't want to start all that from scratch. No way, no how... "
i honestly doubt that your desktop is so customized, given what was possible with KDE 3, that a transition would be painful. your shortcuts on the desktop will show up in folderview just fine; your keyboard shortcuts will continue to work; your panel layout will need to be re-worked. in the meantime you get a whole lot of new functionality. many of the apps in KDE 4 are also mostly or completely backwards compat configuration wise. we kept compat in our dev branch for ~8 years with KDE2 an KDE 3 (note that KDE 2 was a similar break with KDE 1, though); in some places in the infrastructure it was time to move on so we could achieve things we needed to rather than be held hostage to old design choices.
Slashdot Mirror
"True innovation would be to provide a script-based approach to most of the GUI stuff, e.g. nodejs/browser API .. and then provide native code layer"
We started working on exactly that ~5 years ago and the result is QML2 and Plasma (two separate things, but they work wonderfully together). As the node.js project founder said when he saw QML for the first time: "Wow, it's HTML5 done right."
So KDE is truly innovative, you're just too uninformed to have known and ~5 years too late to the suggestion table. (I'm not entirely sure how the /. smarminess works, but I gave it my best try with that last sentence .. did I succeed? ;)
No, translation "we've been working very hard on this device, and will be releasing them at shipping time". We've put the Open Hardware Logo on the feature board and everyone who has participated in this project has licensed their contributions under the GPL. We're not about to start our first product by violating each other's licenses. Please, give us a bit more credit than that. Most of the people involved have been releasing things far more valuable and work intensive than this as Free software/hardware over the years, after all.
" Of course if you believe this thing will appear on time, work and ever see another module which is compatible with it I have a nice bridge here to sell you"
So, it works. How do we know? We already have finished pieces in hand and use them.
Other modules: are alread add-ons such as VGA connectors and keyboard kits in prototyping; I've already seen two more feature boards; as for other CPU cards, those are further away but on the roadmap.
Who peed in your cereal?
I know it's easier to be cynical than to be helpful, but if you support projects like this they actually do go further.
There is HDMI out, which is digital.
This is an engineering board, not a smartphone. If you look around what is available for prototyping and developing projects, you'll find that single core ARM is actually the common case. This is a significant amount of hardware for the market category. This is also considerably more powerful than what smartphones were shipping with 3 years ago, though today's high end phones do come with more cores.
What makes you think this is a tablet? It isn't. It's an engineering board.
They are similar in hardware capacity, except that Improv is modular (not everything is hardwired on one board) and is not a sold-and-forgotten piece of hardware but has an active Free software and hardware devel community around it.
> How is this thing compared (hardware wise) to Raspberry Pi ?
RPi is a single core 7o0 MHz ARM11 with 512 MB RAM and no on-board storage; Improv is a dual core 1Ghz Cortex-A7 with 1GB RAM, 4GB NAND flash and a more powerful GPU. Improv is also modular so you can swap out the CPU card as well get feature boards with additional features in future. So Improv is several times more powerful and quite a bit more flexible. You also get things like SATA with the Improv.
As for software, anything that runs on the RPi run on Improv, while the reverse is not true. Some ARM Linux OSes require hard float, such as Ubuntu, which RPi does not provide but Improv does
The announcement and website clearly state that the feature board which the EOMA68 docks to is open hardware; yes the A20 is not open hardware, and that was never stated otherwise.
That's like saying you fear Qt becoming dependent on BlueZ because some applications need some bluetooth specific features and use libbluez. Which is to say: your fear makes zero sense. Which is good, as that means you can stop being worried.
> hiding the cursor when it's over a text field that's being typed in
This works perfectly here.
> allowing for pure alphabetical sorting in file dialogs (not by-inode-type, then alphabetical)
Click on the configure menu (wrench icon), go to sorting, deselect "Fodlers First".
And if someone thinks of complaining that that should be the default: it's what people are used to. At least it is configurable to your liking.
You're welcome :)
It's not either/or, but both/and. Bugs are fixed, usability is improved .. AND work is ongoing at making necessary infrastructural improvements.
If what you got from this article was "new colors! new shapes!" you have somehow misunderstood what you were seeing. The colors and shapes are completely secondary to the work being done to modularize the existing libraries and have support for hardware accelerated rendering for the entire desktop shell. The colors and shapes are parts of a test framework designed to, well, test the underlying framework; they are not a user-facing product.
Perhaps /. isn't the best place for topics that aren't about cosmetics.
As Sebastian has noted clearly time and again, the effects shown in the demo are what are used to test the framework. They are not the default effects that will be part of the actually released product. It is not unusual for framework test applications to look odd or even plain out ugly as their job is to push the framework and test the various capabilities.
So, no .. this isn't about wobbling things. It's about having a working hardware accelerated canvas that can be extended in several ways, one of which includes OpenGL shaders...
Those aren't windows, those are desktop widgets. Nice try, though.
* you can rubber band in the file manager ... yeah, not hard.
* weather works just fine with European cities. i live in one, so i know.
* graphics glitches are usually driver related, but we've also fixed a lot of issues (small and large) in the least couple of years
* creating a launcher -> drag it from the file manager, the launcher, from a search in krunner,
i realize that reality often does not come into play much when people create and then post again and again these kinds of lists. really it comes down to your last point, doesn't it: you have a highly personal preference for 3.5 (which is fine) and you work backwards from that to justify it. your points, however, are outdated or were never correct.
but that's alright. one can't please everyone all the time, of course. we do have many users who are quite happy, and both sides of that (number of users and average satisfaction) appears to be growing with each release. perhaps not amazingly, it is those people, not those who generate lists for re-posting on every article they can find, who get developer focus.
We're already working on it: http://www.notmart.org/index.php/Software/KDE_on_MeeGo
We had been working previously with both Maemo and Moblin, so this in a way simplifies things a bit for us. It's early days yet, but we're making great progress. The more the merrier, so feel free to join us (you can find us in #plasma on irc.freenode.net)
it wasn't talled "the taskbar" in KDE 2 or KDE 3 either. :) in fact, Plasma calls them exactly what they were called in KDE 2 and 3: panels. the "taskbar" has always referred to the windows picker/manager. personally, i wish we'd always called it something like "windows" that was a bit more obvious.
but yes, in this case it's actually completely consistent with what's always been there.
sorry to burst your bubble.
> I'm just asking for a tiny fraction of that effort put toward helping me understand how to develop apps for it.
techbase.kde.org
and it's an open wiki with a large number of people contributing to it.
> I'd be happy to help with docs, but I need some guidance.
you can find many of us on irc.freenode.net in #kde-devel and there are all the mailing lists.
> it started around 4.0 and 4.1, back when it was not possible to have good KDE releases
KDE specifically stated that 4.0 should not be used in production, and yet that's what a number of distributions rushed to do: place it as the default their users got when installing an OS that was intended for production use. i understand why distributions did what they did, but those are reasons not justificatons. i think a lot has been sorted out on all sides since then, and things are improving in general (though we saw a repeat of the same with pulseaudio, sadly)
> I want to know how development progresses,
we used to have that in the form of the commit digest. would be nice to see that revived by people with interest and the time.
> I want a website which displays the reported recent plasma crashes.
easily available with a query (which you can save, btw) on bugs.kde.org
> I want a website that explains me a single working methods how to set up a built environment on a free machine.
techbase.kde.org, which is linked to from kde.org
> I want an idea torrent set up for KDE.
brainstorm.forum.kde.org
> I want to see the users get involved to discuss KDE in a open and honest way.
i would, too. unfortunately that seems to require more time for research and patience for careful analysis than most computer users can manage. just because it's a GUI that you can see with your eyes and manipulate with your mouse doesn't make the topics of design immediately accessible.
> I don't want slogans and empty marketing gibberish. I want better code.
would you take both? or rather, ignore the former as they are evidently not for you and revel instead in the latter.
> I don't want a code of conduct bullshit,
i'm sorry to hear you think agreeing to treat others with reasonable levels of common-sense care is bullshit. those who spend their time working on KDE tend to feel differently about that.
> I want management by geeks and hacker ethics.
the two aren't mutually exclusive.
> I want to praise the artists which make KDE great.
kde-artists@kde.org
> desktop widgets are basically small applications that don't scale
they scale visually, and they scale to different device form factors. if you are looking for them to scale in functionality to, say, replace Digikam or Kdenlive, that won't happen. they are helpers and quick tools. they aren't supposed to replace applications on their own, just as an application like Digikam is never going to be something you'd put in a nice photo frame device to show some photo collection :)
> use a different window manager
they aren't windows in form or function. unless you consider the objects in inkscape, oo impress, etc. to be windows as well.
> WHO WANTS TO ROTATE A FUCKING WIDGET?
while many seem to enjoy positioning photos just as they'd like on their desktop (which is a fairly minimal reason for rotation), it's actually rather useful when you have a large flat surface that lays horizontally.
given that rotation is couple of lines of code and has resulted in ~zero maintenance overhead and does not impact your usage if you don't care about rotation, this seems like a molehill rather than a mountain.
> At least with Gnome every panel and panel applet is optional
it is the same with KDE Plasma Desktop.
in KDE 3 you were always stuck with a minimum of one panel, actually, and that is gone with Plasma Desktop where you can remove all the panels if you wish.
> Context menu items, keyboard shortcuts, and drop behaviors were broken and/or different from what konq or dolphin did.
little of that was easily sharable when folderview was started. with each release, the people working on the file management components (konq, dolphin, file open/save, folderview) have been pulling this kind of code out into libkonq (in kdebase-apps) and libkfile (in kdelibs; this is actually where most of this stuff exists now).
the was pretty much the same for kdesktop in kde 3, as well. it reimplemented a lot of interaction and functionality itself, but had a number of years to get there. folderview is already more advanced at this point, which is promising.
between the modularization of these file management bits into more easily sharable libraries and the more component-centric model of plasma, i really hope we don't have to go through a similar process again for many, many years (i won't tempt fate and add "if at all" ;)
"What I do need is for firefox to pick up on my application preferences"
OpenSuse has this; hopefully other distros will pick this up, or maybe even firefox itself will.
"for drag and drop to be snappy and accurate and always work,"
lots of improvements have been made in various places for d'n'd.
"for ark to not suck so hard,"
it actually works very nicely in 4.4
"for my folderviews on my desktop to always be up to date, look good, not pile up icons in weird ways"
if your folderviews aren't up to date, then there's a bug in the IO plugin (or it simply doesn't support automatic updates; some network IO plugins don't)
piling up icons in weird ways sounds like a bug; hopefully you've submitted a report for it with details.
as for the semantic desktop, don't use it if it isn't useful to you. it's that simple. however, with apps starting to use it behind the scenes, you'll likely be using it without even knowing it. you'll just be finding that things work nicely and wondering how all that information gets shuttled about. an interesting use case is the groupware system (akonadi) is now using the semantic framework (nepomuk) extensively.
"Kooka"
skanlite is what ships with KDE 4, and there recently was work started to ressurect a full "scanning workflow manager" type app (kooka+ style). aside from batch processing and OCR, skanlite does what kooka did with a rather more streamlined interface.
"porting to Qt-4.x (easy)"
i can see you haven't done much porting to Qt 4, at least not of any apps with serious amounts of code in them.
"and merging fixes (tedious), but maintaining compatibility with the existing installs."
that part would be doable, yes. some people want others to do it, nobody wants to do it, however. funny that.
"Having set up family and friends with (then-latest) KDE-3.x, and all of us using customized desktops, menus, and shortcuts, we don't want to start all that from scratch. No way, no how... "
i honestly doubt that your desktop is so customized, given what was possible with KDE 3, that a transition would be painful. your shortcuts on the desktop will show up in folderview just fine; your keyboard shortcuts will continue to work; your panel layout will need to be re-worked. in the meantime you get a whole lot of new functionality. many of the apps in KDE 4 are also mostly or completely backwards compat configuration wise. we kept compat in our dev branch for ~8 years with KDE2 an KDE 3 (note that KDE 2 was a similar break with KDE 1, though); in some places in the infrastructure it was time to move on so we could achieve things we needed to rather than be held hostage to old design choices.
in any case, mountain, meet molehill.