<?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"
	>
<channel>
	<title>Comments on: Presentation slides from ELC-2007 available</title>
	<atom:link href="http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/</link>
	<description>a hacker analysis of life</description>
	<pubDate>Thu, 20 Nov 2008 13:28:30 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Gustavo Sverzut Barbieri</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21094</link>
		<dc:creator>Gustavo Sverzut Barbieri</dc:creator>
		<pubDate>Sat, 12 Apr 2008 16:34:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21094</guid>
		<description>@Bauermann: As for X primitives, no, they're not good, but almost nobody uses them nowadays. The only thing we use from X is fill some region with solid colors and draw pixmaps, and really, I doubt we need more than that from such a low level engine as X11. What is missing is more hardware optimized support for these operations, in special drawing pixmaps: drawing alpha blended, scaled images, even with XRender extension is very slow (see expedite benchmarks).  Things like Vector graphics or Raster graphics should be handled in a higher level library, as Cairo or Evas. Even text is done at the client side (app) and exported to server as pixmaps.

About the protocol, it's very optimized and I really like it. TCP is just used for remote machine access, and it comes "for free". UNIX sockets are really fast and almost overhead free, the biggest overhead here is waking up the other process, but it's hard to do multi-application write/read access without a manager, so you often need this entity or you end with complex distributed systems that just don't work. X11 protocol is really simple, it's really optimized (common events, like mouse motion, have really small message). Also, remember that heavy data, such as pixmaps, are handled as shared memory (XSHM extension), not adding much overhead (just the allocation is a bit slower).

As for XCB, I have not looked at it, but lots of friends from E do, they have XCB working for all the libraries and seems it works fine. The idea is good and shows how great is the X protocol: we can have both Xlib and Xcb working, the same protocol! :-)</description>
		<content:encoded><![CDATA[<p>@Bauermann: As for X primitives, no, they&#8217;re not good, but almost nobody uses them nowadays. The only thing we use from X is fill some region with solid colors and draw pixmaps, and really, I doubt we need more than that from such a low level engine as X11. What is missing is more hardware optimized support for these operations, in special drawing pixmaps: drawing alpha blended, scaled images, even with XRender extension is very slow (see expedite benchmarks).  Things like Vector graphics or Raster graphics should be handled in a higher level library, as Cairo or Evas. Even text is done at the client side (app) and exported to server as pixmaps.</p>
<p>About the protocol, it&#8217;s very optimized and I really like it. TCP is just used for remote machine access, and it comes &#8220;for free&#8221;. UNIX sockets are really fast and almost overhead free, the biggest overhead here is waking up the other process, but it&#8217;s hard to do multi-application write/read access without a manager, so you often need this entity or you end with complex distributed systems that just don&#8217;t work. X11 protocol is really simple, it&#8217;s really optimized (common events, like mouse motion, have really small message). Also, remember that heavy data, such as pixmaps, are handled as shared memory (XSHM extension), not adding much overhead (just the allocation is a bit slower).</p>
<p>As for XCB, I have not looked at it, but lots of friends from E do, they have XCB working for all the libraries and seems it works fine. The idea is good and shows how great is the X protocol: we can have both Xlib and Xcb working, the same protocol! <img src='http://blog.gustavobarbieri.com.br/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thiago Bauermann</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21093</link>
		<dc:creator>Thiago Bauermann</dc:creator>
		<pubDate>Fri, 11 Apr 2008 03:45:14 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21093</guid>
		<description>Do you think X's primitives are adequate for doing modern graphics? I have done some X programming using nothing but the X lib, and all I remember using in terms of graphics primitives was drawing text and using pixmaps. Points, lines, rectangles, arcs... none of that was used in my program (a window manager).

Also, the model of sending commands via a connection (either TCP or UNIX pipe) seems cumbersome when all you are interested in is local graphics done as fast as possible...

Also, did you have a chance to examine XCB? Do you have any opinion about it? It seems a very interesting project.</description>
		<content:encoded><![CDATA[<p>Do you think X&#8217;s primitives are adequate for doing modern graphics? I have done some X programming using nothing but the X lib, and all I remember using in terms of graphics primitives was drawing text and using pixmaps. Points, lines, rectangles, arcs&#8230; none of that was used in my program (a window manager).</p>
<p>Also, the model of sending commands via a connection (either TCP or UNIX pipe) seems cumbersome when all you are interested in is local graphics done as fast as possible&#8230;</p>
<p>Also, did you have a chance to examine XCB? Do you have any opinion about it? It seems a very interesting project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gustavo Sverzut Barbieri</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21062</link>
		<dc:creator>Gustavo Sverzut Barbieri</dc:creator>
		<pubDate>Thu, 06 Dec 2007 03:33:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21062</guid>
		<description>@Razvan: about the layout manager, you're quite wrong. On open source front, Qt layout manager is more powerful and yet easier to use, but nothing beats Apple there: they even have layout managers capable of aligning things based on text baseline, so you get labels aligned to text entry contents... :-/

As for x11, I'm not against of it, I actually like it and it is capable of "bling", you just have to use the right tools.

As for OpenGL, I never said we require it, it's just something great to benefit when you have... Evas can make use of this, as Clutter or Trolltech's Qt (QGraphicsView).</description>
		<content:encoded><![CDATA[<p>@Razvan: about the layout manager, you&#8217;re quite wrong. On open source front, Qt layout manager is more powerful and yet easier to use, but nothing beats Apple there: they even have layout managers capable of aligning things based on text baseline, so you get labels aligned to text entry contents&#8230; :-/</p>
<p>As for x11, I&#8217;m not against of it, I actually like it and it is capable of &#8220;bling&#8221;, you just have to use the right tools.</p>
<p>As for OpenGL, I never said we require it, it&#8217;s just something great to benefit when you have&#8230; Evas can make use of this, as Clutter or Trolltech&#8217;s Qt (QGraphicsView).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Razvan Vilt</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21061</link>
		<dc:creator>Razvan Vilt</dc:creator>
		<pubDate>Wed, 05 Dec 2007 23:05:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21061</guid>
		<description>I think that changing the layout of an app by theming is a really bad idea. Changing the looks and sizes of widgets is ok, but the layout is plain evil. Not all apps are intuitive (and you shouldn't expect them to be in an not-so-perfect world), and changing the layout of a 3rd party app, that the developer of the theme might not even know about, using theming can wreck usability havoc on the app. Think of grandma, who still doesn't comprehend the concepts of Windows, mouse and especially window focus, and knows little non-technical English, having to learn everything all over again. Furthermore, think of that poor bastard who has to explain everything all over again to her. He should be allowed to have a life.
With power, comes abuse. A theme in which you can move stuff around in _ALL_ the apps, means that something will break, and occasionally it might actually be the hardware because of some poor soul that hates his computer (instead of hating his lack of knowledge).

I am not a developer. I am a network administrator, and I also have to teach my 70+ years old grandma how to read her email and how to type a document. Usability is under-rated, and I think that some concepts of EFL can help it, some can really break-it.
Whenever you design something, try to avoid giving developers the power of breaking things. This is a concept that is in direct opposition with a quote that I kinda remember, that proves to be true everywhere. It's a fragile balance that you need to achieve between power to do cool and impressive stuff easily, an power to wreck havoc. The quote goes something like this:
"UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things."
--Doug Gwyn</description>
		<content:encoded><![CDATA[<p>I think that changing the layout of an app by theming is a really bad idea. Changing the looks and sizes of widgets is ok, but the layout is plain evil. Not all apps are intuitive (and you shouldn&#8217;t expect them to be in an not-so-perfect world), and changing the layout of a 3rd party app, that the developer of the theme might not even know about, using theming can wreck usability havoc on the app. Think of grandma, who still doesn&#8217;t comprehend the concepts of Windows, mouse and especially window focus, and knows little non-technical English, having to learn everything all over again. Furthermore, think of that poor bastard who has to explain everything all over again to her. He should be allowed to have a life.<br />
With power, comes abuse. A theme in which you can move stuff around in _ALL_ the apps, means that something will break, and occasionally it might actually be the hardware because of some poor soul that hates his computer (instead of hating his lack of knowledge).</p>
<p>I am not a developer. I am a network administrator, and I also have to teach my 70+ years old grandma how to read her email and how to type a document. Usability is under-rated, and I think that some concepts of EFL can help it, some can really break-it.<br />
Whenever you design something, try to avoid giving developers the power of breaking things. This is a concept that is in direct opposition with a quote that I kinda remember, that proves to be true everywhere. It&#8217;s a fragile balance that you need to achieve between power to do cool and impressive stuff easily, an power to wreck havoc. The quote goes something like this:<br />
&#8220;UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things.&#8221;<br />
&#8211;Doug Gwyn</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Razvan Vilt</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21060</link>
		<dc:creator>Razvan Vilt</dc:creator>
		<pubDate>Wed, 05 Dec 2007 22:43:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21060</guid>
		<description>I agree that GTK+ has some limitations, but it was thought of with normal UIs in mind. Furthermore, there is one aspect in which GTK+ is still the best: Layout. While you complain about the layout, here are some scenarios in which GTK's layout manager rocks the hell out of anything else on the market (FLOSS or not):
- L18N. In GTK there is no form resizing. You don't need-it. If you localize a Windows app or a web app (most of them at least), you will see cut strings and many other problems. Even if you do the "form resizing" manually (as you would do on Windows, mistakes can still creep in. There is no such thing on GTK.
- DPI independance. Try changing the DPI in GNOME in the advanced font settings, and see if you get any problems. Now, do the same on Windows.
- One XML to rule them all. Having the UI out in an XML file means that the UI designers don't really care about the programming language at all. Furthermore, you can change that XML without having to recompile the application.

I must confess that I don't know anything about EFL, but I assume that the incredible layout manager that GTK offers is still unique.

From what I can understand, you want to do to theming in EFL what js and css did to HTML. While both can be used in a right way, they are abused in most cases and to get a working result you need a lot of hacks. I am a little reticent on whether this is feasible in real life.

The OpenGL support thing in GTK can refer to two things:
1) Use it in the UI and theming. That is generally a bad idea from my point of view, because it's slow as hell on a non-accelerated system. Using it optionally with a wrapper such as Cairo that can use many alternate backends, is reasonable. You don't yet have OpenGL in POS systems, on cell phones, and in some computers.
2) Use it in the app as a widget, and GTK has an OpenGL widget.

Now related to X11. Here, I'm going to quote myself from a thread of Y versus X11 on /.:
"X11 should NOT have an integrated widget set in it. That is because, it's multi-os, multi-platform, you can't expect all the platforms to have the same widget set, toolkit, just think embedded devices here."
"One of the greatest things about it is it's network transparency. X-Windows, is still ahead of it's time. Microsoft introduced Terminal Services back in 97 or 98 for Windows NT Server TSE, long time after X-Windows existed, and it still is not as powerful as X11, it only draws the whole screen through a pipe, compresses it and sends-it to a client. X11 does a lot more than that, it has security is a number of forms (e.g. ACL based), it has support for extensions - which is soo great, and it tells the client which extensions it supports, it has speed (when not over the network) using UNIX Sockets instead of TCP. Even over the network it's fast. If you think that running Mozilla remotely on a 56k is slow, think of the alternatives."
"X11, contrarily to a very popular opinion doesn't look, it shows."
X11 wasn't designed to be something that has bling in it. It's up to the application to do that. Directly of you are masochistic, or using one of the many widget sets out there.</description>
		<content:encoded><![CDATA[<p>I agree that GTK+ has some limitations, but it was thought of with normal UIs in mind. Furthermore, there is one aspect in which GTK+ is still the best: Layout. While you complain about the layout, here are some scenarios in which GTK&#8217;s layout manager rocks the hell out of anything else on the market (FLOSS or not):<br />
- L18N. In GTK there is no form resizing. You don&#8217;t need-it. If you localize a Windows app or a web app (most of them at least), you will see cut strings and many other problems. Even if you do the &#8220;form resizing&#8221; manually (as you would do on Windows, mistakes can still creep in. There is no such thing on GTK.<br />
- DPI independance. Try changing the DPI in GNOME in the advanced font settings, and see if you get any problems. Now, do the same on Windows.<br />
- One XML to rule them all. Having the UI out in an XML file means that the UI designers don&#8217;t really care about the programming language at all. Furthermore, you can change that XML without having to recompile the application.</p>
<p>I must confess that I don&#8217;t know anything about EFL, but I assume that the incredible layout manager that GTK offers is still unique.</p>
<p>From what I can understand, you want to do to theming in EFL what js and css did to HTML. While both can be used in a right way, they are abused in most cases and to get a working result you need a lot of hacks. I am a little reticent on whether this is feasible in real life.</p>
<p>The OpenGL support thing in GTK can refer to two things:<br />
1) Use it in the UI and theming. That is generally a bad idea from my point of view, because it&#8217;s slow as hell on a non-accelerated system. Using it optionally with a wrapper such as Cairo that can use many alternate backends, is reasonable. You don&#8217;t yet have OpenGL in POS systems, on cell phones, and in some computers.<br />
2) Use it in the app as a widget, and GTK has an OpenGL widget.</p>
<p>Now related to X11. Here, I&#8217;m going to quote myself from a thread of Y versus X11 on /.:<br />
&#8220;X11 should NOT have an integrated widget set in it. That is because, it&#8217;s multi-os, multi-platform, you can&#8217;t expect all the platforms to have the same widget set, toolkit, just think embedded devices here.&#8221;<br />
&#8220;One of the greatest things about it is it&#8217;s network transparency. X-Windows, is still ahead of it&#8217;s time. Microsoft introduced Terminal Services back in 97 or 98 for Windows NT Server TSE, long time after X-Windows existed, and it still is not as powerful as X11, it only draws the whole screen through a pipe, compresses it and sends-it to a client. X11 does a lot more than that, it has security is a number of forms (e.g. ACL based), it has support for extensions - which is soo great, and it tells the client which extensions it supports, it has speed (when not over the network) using UNIX Sockets instead of TCP. Even over the network it&#8217;s fast. If you think that running Mozilla remotely on a 56k is slow, think of the alternatives.&#8221;<br />
&#8220;X11, contrarily to a very popular opinion doesn&#8217;t look, it shows.&#8221;<br />
X11 wasn&#8217;t designed to be something that has bling in it. It&#8217;s up to the application to do that. Directly of you are masochistic, or using one of the many widget sets out there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jayvaughan</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21059</link>
		<dc:creator>jayvaughan</dc:creator>
		<pubDate>Wed, 05 Dec 2007 17:03:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21059</guid>
		<description>This is great stuff .. 

A couple of weeks ago I ported bling-it-up to OpenMoko:

http://w1xer.de/bling.html

This is a pretty dirty port - a few things are not working quite properly yet (because of blings hardcodedness around the .pngs) but it certainly shows you how easy it is to do nice graphics stuff, already, on the OpenMoko handheld ..

With a bit of work, the techniques that mirco (macslow) shows us, namely SVG sourced graphics, judicious buffer handling, and some cairo rendering, could be used to build a nice and fancy app for OpenMoko (and other linux) platforms ..</description>
		<content:encoded><![CDATA[<p>This is great stuff .. </p>
<p>A couple of weeks ago I ported bling-it-up to OpenMoko:</p>
<p><a href="http://w1xer.de/bling.html" rel="nofollow">http://w1xer.de/bling.html</a></p>
<p>This is a pretty dirty port - a few things are not working quite properly yet (because of blings hardcodedness around the .pngs) but it certainly shows you how easy it is to do nice graphics stuff, already, on the OpenMoko handheld ..</p>
<p>With a bit of work, the techniques that mirco (macslow) shows us, namely SVG sourced graphics, judicious buffer handling, and some cairo rendering, could be used to build a nice and fancy app for OpenMoko (and other linux) platforms ..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Lauer - Freelancer / Usability through Bling</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21058</link>
		<dc:creator>Michael Lauer - Freelancer / Usability through Bling</dc:creator>
		<pubDate>Wed, 05 Dec 2007 13:24:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21058</guid>
		<description>[...] Gustavo Sverzut Barbieri compares UI toolkits for Linux: http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/ [...]</description>
		<content:encoded><![CDATA[<p>[...] Gustavo Sverzut Barbieri compares UI toolkits for Linux: <a href="http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/" rel="nofollow">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/</a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21042</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Mon, 05 Nov 2007 08:44:09 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21042</guid>
		<description>Yeah, the talk was great and it definitely shows the way embedded linux device UIs should be heading. With OpenMoko heading that direction it'll hopefully be only a matter of time until we see more fancy UIs on nokia tablets.

Btw. many people in the audience were impressed by the possibilities and it was really unfortunate that the timetable could not allow more demos and Q/A.</description>
		<content:encoded><![CDATA[<p>Yeah, the talk was great and it definitely shows the way embedded linux device UIs should be heading. With OpenMoko heading that direction it&#8217;ll hopefully be only a matter of time until we see more fancy UIs on nokia tablets.</p>
<p>Btw. many people in the audience were impressed by the possibilities and it was really unfortunate that the timetable could not allow more demos and Q/A.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fabien Penso</title>
		<link>http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21041</link>
		<dc:creator>Fabien Penso</dc:creator>
		<pubDate>Sun, 04 Nov 2007 09:26:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.gustavobarbieri.com.br/2007/11/03/presentation-slides-from-elc-2007-available/#comment-21041</guid>
		<description>As for me, I just bought an iPod Touch and it confirms what I already felt for months, the N800 is *really* lacking UI. The GTK menus sucks so bad for small devices, no drag&#38;drop, etc. Exactly the opposite of what should have been done. 

I don't see how Nokia could have gone more the wrong way than what they had. Too bad as the hardware is good, except for that not centered webcam.

I like the Canola interface better, but it's still not as good as the iPod Touch's one. Still it's the best N800 software as for the interface. I hope they would just fire the whole N800 UI's software developers and hire other ones.</description>
		<content:encoded><![CDATA[<p>As for me, I just bought an iPod Touch and it confirms what I already felt for months, the N800 is *really* lacking UI. The GTK menus sucks so bad for small devices, no drag&amp;drop, etc. Exactly the opposite of what should have been done. </p>
<p>I don&#8217;t see how Nokia could have gone more the wrong way than what they had. Too bad as the hardware is good, except for that not centered webcam.</p>
<p>I like the Canola interface better, but it&#8217;s still not as good as the iPod Touch&#8217;s one. Still it&#8217;s the best N800 software as for the interface. I hope they would just fire the whole N800 UI&#8217;s software developers and hire other ones.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.313 seconds -->
