<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments for vizZzion.org :: sebas&#039; blog</title>
	<atom:link href="http://vizZzion.org/blog/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://vizZzion.org/blog</link>
	<description>Sebastian Kügler&#039;s web log</description>
	<lastBuildDate>Wed, 17 Apr 2013 11:42:34 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>Comment on Tokamak 6 Kicking Off: Why switch graphics stacks? by Wolfgang</title>
		<link>http://vizZzion.org/blog/2013/04/tokamak-6-kicking-off-why-switch-graphics-stacks/comment-page-1/#comment-19902</link>
		<dc:creator>Wolfgang</dc:creator>
		<pubDate>Wed, 17 Apr 2013 11:42:34 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2125#comment-19902</guid>
		<description><![CDATA[As a user I am looking really forward to this transition, and I am confident, given your track record, that the transition wil be smooth.]]></description>
		<content:encoded><![CDATA[<p>As a user I am looking really forward to this transition, and I am confident, given your track record, that the transition wil be smooth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by Anand</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19191</link>
		<dc:creator>Anand</dc:creator>
		<pubDate>Thu, 21 Mar 2013 03:17:44 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19191</guid>
		<description><![CDATA[Thanks for the reply. Yes, after my usage of Linux I realized that buying a system is not like any other electronic appliance and need to consider various options like compatibility, driver support, etc. Next time, I will try buying a Linux pre-installed laptop.

Sure, I want to contribute and give it back to community and am doing my bit (tiny) by hanging around in support forums and IRC channels of Linux Mint, promoting KDE and Linux amongst friends and social networks, raising bugs :-P, etc. But, yes I need to go beyond these and contribute in regular and proper fashion. I am not a programmer but can surely contribute in documentation part once I am comfortable with various aspects of the system.]]></description>
		<content:encoded><![CDATA[<p>Thanks for the reply. Yes, after my usage of Linux I realized that buying a system is not like any other electronic appliance and need to consider various options like compatibility, driver support, etc. Next time, I will try buying a Linux pre-installed laptop.</p>
<p>Sure, I want to contribute and give it back to community and am doing my bit (tiny) by hanging around in support forums and IRC channels of Linux Mint, promoting KDE and Linux amongst friends and social networks, raising bugs :-P, etc. But, yes I need to go beyond these and contribute in regular and proper fashion. I am not a programmer but can surely contribute in documentation part once I am comfortable with various aspects of the system.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by sebas</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19142</link>
		<dc:creator>sebas</dc:creator>
		<pubDate>Wed, 20 Mar 2013 13:51:32 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19142</guid>
		<description><![CDATA[Here&#039;s my recommendation (you might not like it): Next time, buy hardware that you can get Free drivers for.

I personally lost interest in the blobs of nvidia and AMD and am not using any of their drivers. If they don&#039;t work, that&#039;s bad, but it&#039;s not something I can change. The right address to complain is NVidia, and the right way to do it is to not buy their products.

As to your suggestions, maybe that&#039;s your chance to get involved and improve KDE in these areas? We simply can&#039;t do anything we&#039;d like, as we&#039;re still bound to those pesky 24 hours in a day, but with more people caring about different aspects, we can make our software and ecosystem more accessible to a larger group of people.]]></description>
		<content:encoded><![CDATA[<p>Here&#8217;s my recommendation (you might not like it): Next time, buy hardware that you can get Free drivers for.</p>
<p>I personally lost interest in the blobs of nvidia and AMD and am not using any of their drivers. If they don&#8217;t work, that&#8217;s bad, but it&#8217;s not something I can change. The right address to complain is NVidia, and the right way to do it is to not buy their products.</p>
<p>As to your suggestions, maybe that&#8217;s your chance to get involved and improve KDE in these areas? We simply can&#8217;t do anything we&#8217;d like, as we&#8217;re still bound to those pesky 24 hours in a day, but with more people caring about different aspects, we can make our software and ecosystem more accessible to a larger group of people.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by sebas</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19141</link>
		<dc:creator>sebas</dc:creator>
		<pubDate>Wed, 20 Mar 2013 13:47:01 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19141</guid>
		<description><![CDATA[Dataengines are shared across the whole system, so one dataengine can provide the data for multiple plasmoids. The other way round, it also works: You don&#039;t have to rewrite the dataengine if you want to put a new UI on top of that.

If you&#039;re missing a certain dataengine, maybe that&#039;s your opportunity to dip your feet into Plasma development? It&#039;s quite fun. :)

As to performance in general, I&#039;d recommend a read over: http://doc.qt.digia.com/4.7/qdeclarativeperformance.html

Yes, we&#039;re very aware of these things, in fact I spent most of last night on performance improvements in the containment shown. The result is massive, number of object is more than halved, less than half of the code is loaded initially, and more things are unloaded from memory once they&#039;re not used anymore.

As to delay loading ... that&#039;s exactly what we do in the Plasma 2 shell, pieces are loaded bit by bit, and you can actually see the elements appearing one by one. Startup of the shell itself is almost instant.]]></description>
		<content:encoded><![CDATA[<p>Dataengines are shared across the whole system, so one dataengine can provide the data for multiple plasmoids. The other way round, it also works: You don&#8217;t have to rewrite the dataengine if you want to put a new UI on top of that.</p>
<p>If you&#8217;re missing a certain dataengine, maybe that&#8217;s your opportunity to dip your feet into Plasma development? It&#8217;s quite fun. :)</p>
<p>As to performance in general, I&#8217;d recommend a read over: <a href="http://doc.qt.digia.com/4.7/qdeclarativeperformance.html" rel="nofollow">http://doc.qt.digia.com/4.7/qdeclarativeperformance.html</a></p>
<p>Yes, we&#8217;re very aware of these things, in fact I spent most of last night on performance improvements in the containment shown. The result is massive, number of object is more than halved, less than half of the code is loaded initially, and more things are unloaded from memory once they&#8217;re not used anymore.</p>
<p>As to delay loading &#8230; that&#8217;s exactly what we do in the Plasma 2 shell, pieces are loaded bit by bit, and you can actually see the elements appearing one by one. Startup of the shell itself is almost instant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by sebas</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19140</link>
		<dc:creator>sebas</dc:creator>
		<pubDate>Wed, 20 Mar 2013 13:42:30 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19140</guid>
		<description><![CDATA[...and thereby stabbling us, and our branding efforts in the back.

There&#039;s a reason why we do not call it KDE4 anymore. For your convenience, let&#039;s go over this once again:

The community has grown to big to put everything it does into one big release. We&#039;ve seen this tendency around KDE3 times with Extragear, 4.0 showed it in a very painful way: The platform was ready, many apps were fine, the desktop shell was not up to the task -- yet its bad quality made the whole of &quot;KDE&quot; look bad, while it was really Plasma that caused the uproar.

This is exactly what we&#039;re trying to fix, we&#039;re untangling the different products, so they are perceived as that. This is nothing more than bringing our naming in line with reality, with what makes sense, and clarifying our structure in our naming.

You can be all &quot;I&#039;ll keep doing it like I want&quot;, but that simply suggests to me that you&#039;re not understanding why we&#039;re are doing this, or, and that would be a lot worse, you get kicks out of throwing sticks into our wheels.

As to my example: You are sure you read *and* understood it? The development platform is at 4.x, and that&#039;s different from the program version. This is the same for many other apps (I&#039;ll leave it up to you to verify it, it&#039;s really easy!) and has been like that forever.

I realize that discussing version numbers are a fine way to spend your time, I don&#039;t consider it a productive way to spend my time over and over again. It&#039;s a shame you lack the respect for that.]]></description>
		<content:encoded><![CDATA[<p>&#8230;and thereby stabbling us, and our branding efforts in the back.</p>
<p>There&#8217;s a reason why we do not call it KDE4 anymore. For your convenience, let&#8217;s go over this once again:</p>
<p>The community has grown to big to put everything it does into one big release. We&#8217;ve seen this tendency around KDE3 times with Extragear, 4.0 showed it in a very painful way: The platform was ready, many apps were fine, the desktop shell was not up to the task &#8212; yet its bad quality made the whole of &#8220;KDE&#8221; look bad, while it was really Plasma that caused the uproar.</p>
<p>This is exactly what we&#8217;re trying to fix, we&#8217;re untangling the different products, so they are perceived as that. This is nothing more than bringing our naming in line with reality, with what makes sense, and clarifying our structure in our naming.</p>
<p>You can be all &#8220;I&#8217;ll keep doing it like I want&#8221;, but that simply suggests to me that you&#8217;re not understanding why we&#8217;re are doing this, or, and that would be a lot worse, you get kicks out of throwing sticks into our wheels.</p>
<p>As to my example: You are sure you read *and* understood it? The development platform is at 4.x, and that&#8217;s different from the program version. This is the same for many other apps (I&#8217;ll leave it up to you to verify it, it&#8217;s really easy!) and has been like that forever.</p>
<p>I realize that discussing version numbers are a fine way to spend your time, I don&#8217;t consider it a productive way to spend my time over and over again. It&#8217;s a shame you lack the respect for that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by Anand</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19100</link>
		<dc:creator>Anand</dc:creator>
		<pubDate>Wed, 20 Mar 2013 03:38:47 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19100</guid>
		<description><![CDATA[Good news. I am running 4.10.1 with Mint 13 and experience is greatly satisfactory (with Nepomuk changes, Dolphin integration, screenlocker widgets, etc) but i have few complaints as well. (Constructive feedback - this may not be the right but am in a mood to write ;-) now and here)
Firstly, I experienced few crashes when I change the theme (or add widgets. This really *should* not happen, i.e., A widget crashing desktop! And i cant even report bug because I could not successfully install those extra libraries required. I think the core KDE components should take some features from widgets developed by community and merge / replace them. Ex: Veromix - volume applet has amazing features compared to KMixer but hogs CPU. And to yaWP ( I just love it) i had to compile stuff and there were so many missing dependencies,etc but finally i got it to work. 

I have two laptops and one is an Optimus setup (screw Nvidia for their Linux support) and am missing those nice KWin effects which work perfectly in my other laptop. And I have not found an answer for making desktop effects work with Optimus laptops . (We thankfully have bumblebee for other applications to take advantage of graphics card)

I had a steep learning curve understanding desktop containments - workspaces, activities, desktop widgets, panel widgets. You guys are doing an amazing job in development and design but perhaps not adequate time for building tutorials / documentation. Why not a demo video included as part of KDE? My vision for KDE is to be idiot-proof desktop and you can already boast as am quite a living proof of it. :-)

Finally, one humble request - I know you development guys are very busy but please do spend some time on user forums and see for common issues that users face

Thanks for reading through. KDE rocks.]]></description>
		<content:encoded><![CDATA[<p>Good news. I am running 4.10.1 with Mint 13 and experience is greatly satisfactory (with Nepomuk changes, Dolphin integration, screenlocker widgets, etc) but i have few complaints as well. (Constructive feedback &#8211; this may not be the right but am in a mood to write ;-) now and here)<br />
Firstly, I experienced few crashes when I change the theme (or add widgets. This really *should* not happen, i.e., A widget crashing desktop! And i cant even report bug because I could not successfully install those extra libraries required. I think the core KDE components should take some features from widgets developed by community and merge / replace them. Ex: Veromix &#8211; volume applet has amazing features compared to KMixer but hogs CPU. And to yaWP ( I just love it) i had to compile stuff and there were so many missing dependencies,etc but finally i got it to work. </p>
<p>I have two laptops and one is an Optimus setup (screw Nvidia for their Linux support) and am missing those nice KWin effects which work perfectly in my other laptop. And I have not found an answer for making desktop effects work with Optimus laptops . (We thankfully have bumblebee for other applications to take advantage of graphics card)</p>
<p>I had a steep learning curve understanding desktop containments &#8211; workspaces, activities, desktop widgets, panel widgets. You guys are doing an amazing job in development and design but perhaps not adequate time for building tutorials / documentation. Why not a demo video included as part of KDE? My vision for KDE is to be idiot-proof desktop and you can already boast as am quite a living proof of it. :-)</p>
<p>Finally, one humble request &#8211; I know you development guys are very busy but please do spend some time on user forums and see for common issues that users face</p>
<p>Thanks for reading through. KDE rocks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by PuZZleDucK</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19088</link>
		<dc:creator>PuZZleDucK</dc:creator>
		<pubDate>Wed, 20 Mar 2013 01:04:53 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19088</guid>
		<description><![CDATA[Sebas, your example seems to be confirming what Kamikazow said, that the current version is 4, and your next (might) be two (but might report in the command line that it is 5).

You may call it Plasma 1, but the rest of the world calls it KDE4.]]></description>
		<content:encoded><![CDATA[<p>Sebas, your example seems to be confirming what Kamikazow said, that the current version is 4, and your next (might) be two (but might report in the command line that it is 5).</p>
<p>You may call it Plasma 1, but the rest of the world calls it KDE4.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by mgraesslin</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19043</link>
		<dc:creator>mgraesslin</dc:creator>
		<pubDate>Tue, 19 Mar 2013 18:30:34 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19043</guid>
		<description><![CDATA[You are mixing up a few things here. What you are talking about is compositing. In KWin it&#039;s possible to use OpenGL, XRender or no-compositing - that won&#039;t change.

The OpenGL need for QtQuick2 has nothing to do with compositing on the window manager level. That is KWin will require OpenGL due to QtQuick2, but doesn&#039;t require compositing. User interfaces like the one done with QtQuick2 are not as demanding to especially memory and bandwidth as compositing.

On the long run of course we will require compositing and OpenGL. We are getting more and more in a direction that even ten year old hardware is capable of running OpenGL. That&#039;s the point where one has to ask whether it&#039;s better to sacrifice for every user of modern hardware or sacriface for users of ancient hardware - who could as well just run the Qt4 or Qt3 based version. Nobody is forced to update to new software, but nobody should expect new software to run on old hardware. And as a matter of fact - facebook won&#039;t work on that either.]]></description>
		<content:encoded><![CDATA[<p>You are mixing up a few things here. What you are talking about is compositing. In KWin it&#8217;s possible to use OpenGL, XRender or no-compositing &#8211; that won&#8217;t change.</p>
<p>The OpenGL need for QtQuick2 has nothing to do with compositing on the window manager level. That is KWin will require OpenGL due to QtQuick2, but doesn&#8217;t require compositing. User interfaces like the one done with QtQuick2 are not as demanding to especially memory and bandwidth as compositing.</p>
<p>On the long run of course we will require compositing and OpenGL. We are getting more and more in a direction that even ten year old hardware is capable of running OpenGL. That&#8217;s the point where one has to ask whether it&#8217;s better to sacrifice for every user of modern hardware or sacriface for users of ancient hardware &#8211; who could as well just run the Qt4 or Qt3 based version. Nobody is forced to update to new software, but nobody should expect new software to run on old hardware. And as a matter of fact &#8211; facebook won&#8217;t work on that either.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by Rahim</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19035</link>
		<dc:creator>Rahim</dc:creator>
		<pubDate>Tue, 19 Mar 2013 17:19:42 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19035</guid>
		<description><![CDATA[Hi,

I have a question about KDE5. You say here KDE Framework 5 is &quot;on top of a hardware-accelerated graphics stack&quot;. Does this mean that KDE Framework 5 will require 3D accelerated graphics drivers to work? I currently really admire the current KDE 4 implementation, which can be configured to work with openGL if desired, but if not it runs fast and light using xrender without any special 3D drivers. Currently Gnome is virtually unusable without good 3D graphics drivers, despite the llvmpipe implementation that offloads the heavy work onto the CPU. I think it would be a major step backwards for KDE 5 to require 3D rendering and compositing.

Thanks!]]></description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I have a question about KDE5. You say here KDE Framework 5 is &#8220;on top of a hardware-accelerated graphics stack&#8221;. Does this mean that KDE Framework 5 will require 3D accelerated graphics drivers to work? I currently really admire the current KDE 4 implementation, which can be configured to work with openGL if desired, but if not it runs fast and light using xrender without any special 3D drivers. Currently Gnome is virtually unusable without good 3D graphics drivers, despite the llvmpipe implementation that offloads the heavy work onto the CPU. I think it would be a major step backwards for KDE 5 to require 3D rendering and compositing.</p>
<p>Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on What&#8217;s going on in Plasma Workspaces 2? by glad</title>
		<link>http://vizZzion.org/blog/2013/03/whats-going-on-in-plasma-workspaces-2/comment-page-1/#comment-19018</link>
		<dc:creator>glad</dc:creator>
		<pubDate>Tue, 19 Mar 2013 13:08:41 +0000</pubDate>
		<guid isPermaLink="false">http://vizZzion.org/blog/?p=2115#comment-19018</guid>
		<description><![CDATA[My experience with pure QML-plasmoids (pure = no C++ involved except in the data-engines they use) is that you can make them (almost) as fast as the C++ version. But you have to pay extra attention to optimize your code: you should delay loading any Item until it must be shown (for example in my AppMenu QML plasmoid, if the favorites are unlocked, an &quot;Add to favorites&quot;, &quot;Move favorite up&quot;, &quot;Move favorite down&quot;, ... button appears on the hovered menu-item; if the plasmoid would load those buttons on all menu-items even before they are shown, then my plasmoid would be slower; one can also notice a speed-up in loading the plasmoid and showing the submenus when the favorites are locked and thus those buttons are never loaded), you should avoid loading large images (for example in my Luna QML plasmoid, if I would load the luna.svgz file (which contains the images for all moon-phases) entirely and only show the correct element, then the plasmoid would start much slower than when I cut the svg-file in 28 svg-files (one file for each moon-phase) and only load the correct svg-file), you should also pay attention to your JavaScript code (there was one for-loop in the C++ code of the original Luna plasmoid which did a lot of superfluous calculations, that was not a big problem for the C++ plasmoid because C++ is fast, but after optimizing this for-loop for the QML+JavaScript version, the speed difference was noticeable), you should avoid JavaScript as much as possible and depend as much as possible on data-engines (which are written in C++). In kde-workspace trunk there are some hybrid QML/C++ plasmoids, where the heavy work is done in the C++-part. This is also a good idea to make the plasmoid fast, but I don&#039;t understand why the authors did not make a data-engine instead (for things like &quot;Recent Documents&quot;, &quot;List of places&quot;, taskbar with screenshots, ...; these are things that a 3rd-party plasmoid developer would also be interested in, now the 3rd-party developer has to reimplement all that stuff).]]></description>
		<content:encoded><![CDATA[<p>My experience with pure QML-plasmoids (pure = no C++ involved except in the data-engines they use) is that you can make them (almost) as fast as the C++ version. But you have to pay extra attention to optimize your code: you should delay loading any Item until it must be shown (for example in my AppMenu QML plasmoid, if the favorites are unlocked, an &#8220;Add to favorites&#8221;, &#8220;Move favorite up&#8221;, &#8220;Move favorite down&#8221;, &#8230; button appears on the hovered menu-item; if the plasmoid would load those buttons on all menu-items even before they are shown, then my plasmoid would be slower; one can also notice a speed-up in loading the plasmoid and showing the submenus when the favorites are locked and thus those buttons are never loaded), you should avoid loading large images (for example in my Luna QML plasmoid, if I would load the luna.svgz file (which contains the images for all moon-phases) entirely and only show the correct element, then the plasmoid would start much slower than when I cut the svg-file in 28 svg-files (one file for each moon-phase) and only load the correct svg-file), you should also pay attention to your JavaScript code (there was one for-loop in the C++ code of the original Luna plasmoid which did a lot of superfluous calculations, that was not a big problem for the C++ plasmoid because C++ is fast, but after optimizing this for-loop for the QML+JavaScript version, the speed difference was noticeable), you should avoid JavaScript as much as possible and depend as much as possible on data-engines (which are written in C++). In kde-workspace trunk there are some hybrid QML/C++ plasmoids, where the heavy work is done in the C++-part. This is also a good idea to make the plasmoid fast, but I don&#8217;t understand why the authors did not make a data-engine instead (for things like &#8220;Recent Documents&#8221;, &#8220;List of places&#8221;, taskbar with screenshots, &#8230;; these are things that a 3rd-party plasmoid developer would also be interested in, now the 3rd-party developer has to reimplement all that stuff).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
