<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Disqus - Latest Comments for megatux</title><link>http://disqus.com/by/megatux/</link><description></description><atom:link href="http://disqus.com/megatux/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Tue, 22 Jul 2008 00:37:28 -0000</lastBuildDate><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-963351</link><description>&lt;p&gt;I meant trial and error in the large scale -- the kind of inevitable side effect of technological progress and market competition.  People try different approaches to the same problem and the best ones survive.  By no means do I believe that API design should be a careless free-for-all.  You do the best job you can given the situation at hand and adapt as future needs change.  Nobody gets it right the first time.  But, on the other hand, progress is never made if nobody tries something new.  In the case of an API, maybe you add some branch of features and nobody likes it.. so you prune it back off later or refactor it into a separate API.  No harm done. The same argument made today against 3D widgets could just as easily have been made against 2D canvas elements.  Maybe people will use it, maybe they won't.  But having the extra feature doesn't hurt those who don't need it as long as developer resources aren't diluted excessively.  (but usually with such new features, you get new developers willing to take responsibility for them)&lt;/p&gt;&lt;p&gt;I very much agree with that old article, by the way. Indeed, 3D is too often a gimmick.  Personally, I think most of those 3D photo browser demos so popular today are cheesy and impractical -- a bunch of 2D photographs floating aimlessly around empty space!   On the other hand, compare a geo-browser application like Google Earth, where visualization is central.  Now you have a sense of physical context from the 3D view, with 2D and 2.5D objects mixed into it seamlessly.  So if your vacation pictures to Yosemite Park are geo-tagged, you can explore them in the *context* of a 3D environment with auxiliary information dynamically present -- maybe other peoples photos from Flickr, maybe Wikipedia articles on landmarks, etc. Could you do this all from a 2D view?  Sure, but an overhead map wouldn't give you the full context of the data.  As a good example, find a Gigapixel image on Google Earth and notice how the transition from 3D to wrapped 2D gives you a better idea of what you are actually looking at.&lt;/p&gt;&lt;p&gt;For line of business apps, different story entirely.. and that's why nobody (sane) is trying to force change upon what already works here.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Tue, 22 Jul 2008 00:37:28 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-940253</link><description>&lt;p&gt;"The apps I'm using now look very similair to the apps I was using 20 years ago"&lt;/p&gt;&lt;p&gt;The primary reason is that it took hardware a long time to catch up.  It was only in the last few years that we could truly say adequate 3D acceleration is ubiquitous. Now that this point has arrived, it's time to think creatively again.  As I've mentioned before, apps like Google Earth are a good demonstration of practical (non-game) uses of 3D interfaces.  It's all about visualization of massive data sets.  Again, something we didn't have 20 years ago.&lt;/p&gt;&lt;p&gt;"Do users really want such things? I doubt it."&lt;/p&gt;&lt;p&gt;For daily use, no, the extreme examples won't become the norm.  Nobody is going to constantly talk to their computer or wave their arms at a screen all day.  However, there are cases where these models work well and we need to design our toolkits to make these accessible to developers.  For example, multi-touch interfaces are superior both for mobile applications (ex. iPhone) and for manipulation of 3D data sets on any size screen -- gestures simulate greater than 2 degrees of freedom in a way that feels far natural compared to a mouse.  For voice, hands-free operation is essential for many mobile applications.  Perhaps the most practical example, Zoomable User Interfaces, enables a very natural "drill down" design that allows better navigation of large data sets of any dimensionality. (and not just photo collections.. hehe)  So it's not about eliminating old UI designs that still work but enabling new designs that work better in some circumstances.  There is also a lot to be said for usability improvements that come with certain graphical effects.. smooth transitions, cleaner rendering using vector graphics, ability to zoom in on details, etc.&lt;/p&gt;&lt;p&gt;"I've got Vista and Mac OS/X boxes, I see nothing revolutionary."&lt;/p&gt;&lt;p&gt;Correct, because the new graphics frameworks they ship with are not being used by mainstream applications yet.  That's good in that it buys us some time.  But, do a search on YouTube for demos of stuff people are now trying out with WPF and OSX Quartz Extreme. You'll find plenty of revolutionary stuff...&lt;/p&gt;&lt;p&gt;"If that is all we are talking about then why is an API break required?"&lt;/p&gt;&lt;p&gt;Things like resolution independence, 3D primitives and effects, and time-based animation need to be toolkit-wide so that they become the default, not reserved for an optional canvas element that few apps will actually use.&lt;/p&gt;&lt;p&gt;"Why does that break the API for the widgets? A button is a button, and gets clicked, regardless of how you paint the thing."&lt;/p&gt;&lt;p&gt;We need to standardize the availability of new, graphically-richer widgets, so that developers will feel free to use them. And if richer widgets become standard, non-GL-accelerated rendering will not suffice.  I know this is the big sticky point with people, but it has to happen at some point. There can always be fall-back software GL renderers or a "degraded mode" which displays a simplistic version of the widgets.  Some software renderers are actually quite performant today..&lt;/p&gt;&lt;p&gt;"Sure there are better ways. But I'm not going to accept something as better just because it is new or "hip"."&lt;/p&gt;&lt;p&gt;I'm in total agreement there.  I don't welcome technology for the sake of technology or eye candy for the sake of glamor.  There has to be a practical benefit.  I used to be in the camp that said there was none to be found, but I've since seen too many good examples that have matured out of the initial glitz fest of tech demos.&lt;/p&gt;&lt;p&gt;"XGL does the same thing. My desktop is more usable with it than without. And adding it didn't break any apps."&lt;/p&gt;&lt;p&gt;What XGL+Compiz cannot do, of course, is enable the same visual effects *within* applications.  This is where MS and Apple's new standard toolkits are far ahead.  Sure, we can do the same with various OpenGL libraries, such as Clutter, but these are not the "platform standard" for most applications and there is no upgrade path for existing applications.&lt;/p&gt;&lt;p&gt;Just to throw out one more idea at the end here.. If we cannot yet convince people to standardize on resolution independence + scene-graph + 3D effects, we ought to at least add a standard layer of abstraction between GNOME apps and the graphics toolkit.  XAML / XUL / other declarative languages are good candidate examples. This way, we can render apps using the best methods available on the system they run on.  Obviously this would involve new data binding libraries and quite a bit of refactoring, but it would actually be the most feature-scalable, future-proof direction to go!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Sat, 19 Jul 2008 03:36:53 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-940025</link><description>&lt;p&gt;1.) Gtk# has additional abstractions beyond being a simple language binding to Gtk+, so there is some additional isolation from low-level ABI changes.  In addition, yes, I maintain my stance that end-user desktop application development in C/C++ is inappropriate today in most cases.  Productivity, portability, and code quality are significantly better with higher level managed languages.  This is well demonstrated and not a debatable point.&lt;/p&gt;&lt;p&gt;2.) I never claimed we need to design 50 years into the future.  I said 50 years from now our user interfaces will look nothing like they do today and yet it won't happen overnight.  In other words, steady progress will happen regardless, whether it comes from MS or Apple or the OSS community, so lets all stop trying to halt it just because we're afraid of trial and error in the process.  And yes, there is an enormous amount of published UI research in the areas of zoomable user interfaces, natural user interfaces (touch, haptic, holographic, multi-user, etc.), etc. which go well beyond the aging W.I.M.P paradigm that Xerox invented. I've read quite a bit of it. I suggest you do the same and see if you come to the same conclusions.&lt;/p&gt;&lt;p&gt;3.) To be realistic, you are an extreme minority to be using such an old system. (and very lucky, as most PCs break down well before 7 years)  Shall the rest of us stop innovating so that your end-of-life PC will remain useful another year or two?&lt;/p&gt;&lt;p&gt; Energy efficiency is by no means a ridiculous argument because it effects both electrical usage at the plug *and* building cooling requirements. This is most noticeable in the server room, but many companies have seen enormous savings by upgrading to newer energy efficient desktops as well.  As for e-waste, this is a separate issue.  All responsible companies (Dell, etc.) send their old machines to recycling centers today. As for the energy requirement of building new systems, this is not something we would expect to continue at current rate much longer.  The trend is heavily towards smaller, simpler, more solid-state systems with drastically lower metal content and shipping weight. The free market will continue optimize out such inefficiencies. If you want to crusade for something, take a look at automobiles instead.  As for me, my cheap 3 year old PC runs all the "useless glitz" just fine and uses less power when idle than the recycled P3-700 desktop I used to use as a web server.  Plus it suspends/hibernates without issue, which few 7+ year old computers can claim.&lt;/p&gt;&lt;p&gt;4.) "That's because Apple gave up usability engineering years ago."&lt;br&gt;Seriously, now who sounds like a troll?  :-P&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Sat, 19 Jul 2008 02:24:48 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-930285</link><description>&lt;p&gt;Apologies.. my wording (ie. "disaster") was too inflammatory.  I understand the points regarding 4.0 vs. 4.x and I'm aware of the new technologies coming forth, as I casually watched KDE 4 development for over a year.  However, for a release tree that will probably be around for a good 5-6 years, it still seems insufficient.  There are certain "must have" features for future-proofing that are not found in this round and would be difficult to "bolt on" later without first moving to a 5.0 API break.  I should have pointed these out more specifically, for this is why it is relevant to the planning of Gtk / GNOME 3.x. I'd have to say the biggest (and most practical) feature missing is that KDE 4 was not architected as a true resolution-independent desktop. I see this as a non-negotiable item for the coming wave of mobile computing where screen DPI varies wildly anywhere from about 100 dpi to over 200.  I'm aware that there are difficulties accelerating all vector graphics with consistent quality on current hardware, but it would have been better to plan for this possibility in the near future.&lt;/p&gt;&lt;p&gt;I should say also that I don't believe the desktop paradigm has much life left to it and therefore any *new* technologies which are inherently desktop-centric are, IMO, not revolutionary enough.  So, for instance, folderview and semantic desktop are slick, but I'd rather move on to web/network/database-centric paradigms that replace local folders/files as the primary units of high-level data organization seen by the user.  (think documents that live in a metadata-rich network "cloud" versis in a folder with a "physical" location)  I really have no desire to tag my files with metadata that is limited to a particular desktop environment. (in the same way it is frustrating to have track ratings jailed by iTunes or Amarok's "proprietary" internal database) However, I will say that if KDE 4's semantic desktop efforts translate to GNOME via proper use of RDF, at least it would be a transition plan to future "rich semantic web" applications which are desktop agnostic.  Nevertheless, it bothers me to see KDE 4 going in the direction of new features that further tie users down to the desktop paradigm.  I'd rather leave the desktop as it is today and work on completely different paradigms.  Of course, the same criticism goes for the other major desktop platforms these days, so I suppose can't knock KDE too badly there! :)&lt;/p&gt;&lt;p&gt;I surely hope Nokia decides one day to switch Qt to LGPL.  That could breath a whole lot of life back into the project from the commercial side of things...&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Fri, 18 Jul 2008 04:38:48 -0000</pubDate></item><item><title>Re: Gtk+ 3.0 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-14.html#comment-930109</link><description>&lt;p&gt;I see your point with respect to current architecture. (apparently, even WPF is just a DirectX app that eventually gets painted to a texture managed by a window manager)  I suppose the question is how we might (in the future) get to a point where *everything* is drawn within a 3D scene graph, rather than just having a scene graph API for individual applications using a particular graphics toolkit.  This is extremely futuristic, but I'm actually talking as far as being able to eliminate the concept of the "application window" as the primary container of the desktop metaphor. But I'll reserve those ideas for a proper research paper on the topic.. :)&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Fri, 18 Jul 2008 03:46:35 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-926188</link><description>&lt;p&gt;The primary reason KDE 4 is a disaster is that it breaks everything for little benefit.  As you say, "What matters is what they can do with the desktop."  KDE 4 doesn't change what you can do.. it just adds some (very ugly) UI gimmicks and provides some cleaner APIs for common stuff.  None of its new features are revolutionary, on the order of "Wow.. I have to have that feature.. this new thing is worthwhile to port to."  Nothing about it seems technologically future-proof for the next 5 years, as such a major release should offer.&lt;/p&gt;&lt;p&gt;Gtk+ 3.0 / GNOME 3.0 need to be revolutionary and a clear path towards the future.  There needs to be a parallel development effort, starting now in a sandbox and continuing until it is fully mature (unlike kde 4.0 was).  They need to be what .NET was for Windows -- a whole new platform, while leaving the old stuff around for legacy applications.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Thu, 17 Jul 2008 17:38:29 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-926058</link><description>&lt;p&gt;To the contrary, Sun had to go start developing JavaFX because our free software graphics stuff was not moving fast enough.  Java was becoming entrenched as a "platform that sucks for doing any kind of rich graphics or multimedia" while .NET was making huge strides forward with WPF and Silverlight.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Thu, 17 Jul 2008 17:23:52 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-925988</link><description>&lt;p&gt;"I create applications for users to interact with boring old data, and Gtk# and monodevelop (Stetic) work pretty darn well."&lt;/p&gt;&lt;p&gt;If you use Gtk#, nothing should change for you, even if Gtk 3.0 is a radical ABI change to scene graph + 3D + effects + whatever.  That's the beauty of working with higher level languages / libraries and it should serve as an example to the poor saps wasting their time with C/C++ today for end-user apps.&lt;br&gt;--&lt;br&gt;"If I wanted to develop Web/AJAX/Flex/Silverlight/JavaFX/Flash applications then I'd do that"&lt;/p&gt;&lt;p&gt;Think of it this way:  can you imagine people using apps that look like the ones you create today, say 50 years from now?   Well, change has to happen at some point.  We won't just magically wake up one day with computers that understand our voice and immerse us in some sort of 3D holodeck type interface.  But if we all say "No, I'm comfortable with how things are today" we will never get there.  Meanwhile, MS and Apple are moving forward with these sorts of things.&lt;br&gt;--&lt;br&gt;"But I don't think I should need a $400 GPU in order to edit my word processing files and read my e-mail."&lt;/p&gt;&lt;p&gt;That's a severe exaggeration.  Any OpenGL 2.0 level GPU would be sufficient for the advanced features people are proposing.  Such GPUs are effectively free today, due to integrated graphics chipsets.  Any PC manufactured in the last 4-5 or so years would be sufficient.  PCs older than that aren't worth keeping around due to their enormous energy inefficiency.  PCs are dirt cheap today (far cheaper than software) and we should not be designing for outdated hardware.&lt;br&gt;--&lt;br&gt;"I don't want to build swishy swooshy colorful screenlet type applications that tell me the time of day just like the panel widget does, and in general I don't even want such things on my desktop."&lt;/p&gt;&lt;p&gt;There is a terrible misconception that advanced graphic features must be used to make "swooshy eye candy stuff".  This is not even remotely the case.  Things like resolution independence, smoother scrolling and transitions, and anti-aliased vector graphics apply to any application, even simple 2D form-based business apps.  But they are only achievable by switching to GL-accelerated rendering backends which take advantage of modern video hardware.  Furthermore, don't assume that there are no better ways of doing things than the "standard conventions" you are comfortable with.  Apple has proven again and again that certain "eye candy" actually improves usability.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Thu, 17 Jul 2008 17:16:04 -0000</pubDate></item><item><title>Re: Gtk+ 3.0 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-14.html#comment-904789</link><description>&lt;p&gt;Thanks for responding,&lt;/p&gt;&lt;p&gt;* You are right that many of the effects people are interested in today are 2.5D only. Cube, spheres, and other 3D primitives however would allow much more flexibility in novel widget design. I gave the example of Google Earth style widgets, for instance.&lt;/p&gt;&lt;p&gt;* It's probably only a few years off.  HDTV sets supporting higher color depths are already on the market, supported by the new HDMI revision, and recent video cards also support it.  There's no reason not to build in the functionality now, even if it lies dormant for a short time. (ie. just make the pixel format not static)&lt;/p&gt;&lt;p&gt;* This is not entirely clear from the docs or the descriptions.  I see plenty of references to setting FPS manually, but I'll take your word for it.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Tue, 15 Jul 2008 18:59:45 -0000</pubDate></item><item><title>Re: Gtk+ 3.0, take 2 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-15.html#comment-904617</link><description>&lt;p&gt;"These are great developers, but for their day-to-day activities, they have given up on the Linux/Gnome desktop."&lt;/p&gt;&lt;p&gt;Sadly, I can't tell you how many people I know who this applies to.  Among my developer friends, Linux desktop is widely perceived as a failure on pragmatic grounds. Despite the fact that I still like it, to be honest, it is a failure for the vast majority of the market.  Almost all the action (and commerce) in Linux today is dynamic web languages, Java, big iron, and mobile. Most commercial developers using Linux desktop today just use it as a no-frills way to run Firefox and Eclipse on cheap PCs. And most of those same developers have Macs at home. I'm sure you are aware of more counter-examples than I am, but it doesn't change the larger reality of the market. (See also RedHat statements about how the Linux desktop is not lucrative enough to pursue seriously.)&lt;/p&gt;&lt;p&gt;"Having an "abandoned Gtk 2.x" and a "maintained, but API and ABI incompatible 3.x"Having an "abandoned Gtk 2.x" and a "maintained, but API and ABI incompatible 3.x" which will not be available everywhere at the same time is a major turn off for ISVs.  which will not be available everywhere at the same time is a major turn off for ISVs."&lt;/p&gt;&lt;p&gt;Having a dinosaur graphics toolkit and lousy IDE tooling is a major turn off for the 99% of the market who we will never reach.  What's more important?  I'm not saying that existing ISVs should be cut from the picture, but if they are not willing to move forward after open discussion, we have to play benevolent dictator and leave them behind.  Those who resist change in any business arena don't tend to survive anyhow. It's not our fault if that happens.&lt;/p&gt;&lt;p&gt;"Creating an ISV ecosystem is incredibly hard, and somehow the new generation of Gtk+ developers is now OK to throw away years of work of those that had to work with fewer resources than Gnome has today, fewer developers, a smaller community, slower computers, bigger challenges and yet, managed to keep Gtk+ 2.0 API compatible."&lt;/p&gt;&lt;p&gt;If the resource situation is different today, we should expect change. The new generation of developers, myself included, are OK with throwing away years of work because clinging to that old work is killing us slowly. Progress has to happen at some point. I guarantee that we are collectively losing far more developers due to inadequate progress than those we *might* lose if we just stay entrenched with outdated technology. Any decision has trade offs. You have to choose based on maximum benefit.&lt;/p&gt;&lt;p&gt;The software industry has changed dramatically in its alignment to OSS.  We don't need to rely entirely on the small vendor mentality anymore.  The ones who matter most today are RedHat, Google, Novell, HP, Intel, Adobe, Motorola, Nokia, IBM, etc. because they have the big resources to back us up if we have a good vision on how to move forward.  Back in the day, those companies (besides RedHat) were not on board with us and we had to scrape along with stuff that could be developed with minimal resources.  What we need today is a movement to bring together all the big players and top developers and chart a path for future development, fully taking into account the competition and holding nothing back.  If we do this, we all win.  If we just keep up the infighting and wheel spinning, Unix history repeats itself once again and we all lose.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Tue, 15 Jul 2008 18:39:47 -0000</pubDate></item><item><title>Re: Gtk+ 3.0 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-14.html#comment-903917</link><description>&lt;p&gt;Hm.. This is a rather radical idea, but what if the 2.5D/3D scene graph was instead provided by Xorg as its "root window".  Then Gtk+ (and Qt, etc.) would just be a thin widget layer on top of it.  This way, Gtk+ could use "X12" in *nix and WPF in Windows and Quartz in OSX, as a level playing field, and not have to fill in the gaps with its own engine on *nix.  Legacy X11 apps would display as 2D windows and this could be deprecated over a decade or so. (similar to X11 support in OSX)  We've had a heck of a time getting those quirky X extensions properly accelerated anyhow, compared to excellent GL support.&lt;/p&gt;&lt;p&gt;Ultimately, we could throw out a whole lot of extraneous libraries by standardizing this way and moving completely away from the X11 model. It would also do enormous good for X network transparency compared to crufty Xlib.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Tue, 15 Jul 2008 17:28:46 -0000</pubDate></item><item><title>Re: Gtk+ 3.0 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-14.html#comment-903636</link><description>&lt;p&gt;mallum, I actually have read the docs.  If you are aware of something in development, please let us know.  Otherwise, from everything I see:&lt;/p&gt;&lt;p&gt;* There is no support for true 3D widgets. (think 3d models which are interactive, like a 3D Google-Earth-style globe that can be rotated, etc.)  Clutter is currently focused on manipulation of 2D planes.  From the front page: "Scene-graph of layered 2D interface elements manipulated in 3D space via position, grouping, transparency, scaling, clipping and rotation." This assessment also agrees with the API docs.&lt;/p&gt;&lt;p&gt;* It does not support higher color depths:  (hard-coded to 8-bits per channel)&lt;br&gt;&lt;a href="http://clutter-project.org/docs/clutter/0.8/clutter-Colors.html#ClutterColor" rel="nofollow noopener" target="_blank" title="http://clutter-project.org/docs/clutter/0.8/clutter-Colors.html#ClutterColor"&gt;http://clutter-project.org/...&lt;/a&gt;&lt;br&gt;What we needs is flexibility to do 16-bit and floating point color in the future.&lt;/p&gt;&lt;p&gt;* The animation system is entirely frame-based.&lt;br&gt;&lt;a href="http://clutter-project.org/docs/clutter/0.8/ClutterTimeline.html" rel="nofollow noopener" target="_blank" title="http://clutter-project.org/docs/clutter/0.8/ClutterTimeline.html"&gt;http://clutter-project.org/...&lt;/a&gt;&lt;br&gt;This is dramatically inferior to time-based systems where the FPS is variable such that on a slower system, the animations take the same amount of time and just aren't as smooth.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Tue, 15 Jul 2008 16:56:27 -0000</pubDate></item><item><title>Re: Gtk+ 3.0 - Miguel de Icaza</title><link>http://tirania.org/blog/archive/2008/Jul-14.html#comment-894978</link><description>&lt;p&gt;Hi Miguel,&lt;/p&gt;&lt;p&gt;Given your .NET / Mono experience, you know as well as anyone that Windows Presentation Framework is a very significant advance in graphics technology on the Windows platform -- equal or better than OSX Quartz and light years ahead of what we have today on the scrappy Free Desktop. I know from your past posts / interviews that you think WPF is perhaps overcomplicated and inelegant and it may well be, especially given that it is an initial release. Nevertheless, it massively raises the bar on what developers are going to expect out of a graphics framework in the near future. Once the tooling is worked out and Vista gains more market share (if only because PCs have a short lifespan), Win apps that take advantage of WPF are going to be putting all of us *nix folks to shame. Certainly, none of us want to see that happen. :)  Furthermore, I would imagine at some point the Mono Project is going to need to start implementing WPF features to a greater degree.  To do this, Gtk+ 3.x will need a lot of new features. Perhaps you can weigh in on this all, in light of Havoc's proposal and recent talk of using Clutter as a prototype for Gtk+ 3.0.&lt;/p&gt;&lt;p&gt;Off-hand, I think that Clutter as of 0.8 is a great start but still not quite enough.  Clutter's scene graph lacks the capability of full 3D widgets without a containing window, a feature now standard on both OSX and Vista. Think of Cover Flow and Time Machine.  There is no doubt by now that 2.5D applications + 3D window-less widgets are the way of the future, because this allows the best of both worlds and a completely flexible canvas for developers to dream upon.  It's one of those "obvious next steps" for which the time has come. (Effectively, all PCs now have reasonable 3D w/shaders capability and those that don't are so old they can't even run Gnome 2.24 very well today, due to memory requirements!)  Another point -- unless I'm missing something, we are missing a roadmap for high-definition color standards (ie. beyond 8-bit per RGB channel) which will be needed for the coming generation of display devices and video formats.  Smaller point: Clutter is still doing frame instead of time-based animation.  That probably needs to change as well to maintain feature parity with the other platforms.&lt;/p&gt;&lt;p&gt;My personal take: Break it all!!  We are way too far behind to worry about cleanly preserving relics of our past. Gtk 2.x served us well, but it's really time to make a clean break towards the future and not have to worry about backwards compatibility and easy refactoring.  Let 2.x and 3.x exist side by side until all apps are ported.  I wholeheartedly agree with you that multiple ABI breaks are definitely not the answer.  Lets do it once, do it soon, and do it right!&lt;/p&gt;&lt;p&gt;.. Incidentally, Sun is also working on a WPF competitor called JavaFX. However, last I heard, its graphics engine was not going to be open sourced, so this is irrelevant to GNOME and Mono.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">megatux</dc:creator><pubDate>Tue, 15 Jul 2008 05:12:37 -0000</pubDate></item></channel></rss>