Comments for Colin Walters

Comment on Platforms as a side effect by Steve G

Steve G — Tue, 07 Feb 2012 17:10:08 +0000

“Now, I’ve never written a Rails app either, but it’s pretty clear from the Internet which one of these wins”.

To me too… having used both of them, J2EE is better designed and better documented. Win.

Comment on GNOME as a platform by Jimmy Smiths

Jimmy Smiths — Thu, 02 Feb 2012 15:49:15 +0000

I, on the contrary, argue that Gnome SHOULD be a platform first, since it already acts like one.

When I started running Cinnamon, I finally saw the potential of Gnome-Shell start to materialize – because it was made by people who cared so much about users they actually LISTENED to their feedback, as opposed to working like a cabal in IRC covens and disregarding any opinion that did not come from @gnome.org (or @fedora.org, but that difference is academic at best)

Comment on GNOME as a platform by Mairin Duffy

Mairin Duffy — Thu, 02 Feb 2012 02:20:42 +0000

But while you make this awesome thing from which a platform appears, you do need to support the people who use said platform to develop things that are not the awesome thing. Not sure how you do that while continuing to focus on the awesome thing.

Comment on GNOME as a platform by Frederik Hertzum

Frederik Hertzum — Wed, 01 Feb 2012 10:04:36 +0000

I generally agree with you that GNOME should not -just- be a bucket of parts, I do believe that any project which is suffeciently complex should be structured as a bucket of parts however — effectively GNOME should be the first downstream sink of those bucket of parts (meaning that there would be a GNOME-parts project and a GNOME-desktop project).

Comment on Platforms as a side effect by GNOME as a platform « Colin Walters

GNOME as a platform « Colin Walters — Wed, 01 Feb 2012 01:00:42 +0000

[...] « Platforms as a side effect [...]

Comment on Platforms as a side effect by Ole Laursen

Ole Laursen — Mon, 30 Jan 2012 16:14:26 +0000

Havoc Pennington talked about this many years ago, on one of the GNOME mailing lists I believe. Maybe it was desktop-devel. Something about not accepting new API that hadn’t been in use yet. I still think about it from time to time.

Hm, Google wasn’t of much help there.

Qt vs. GTK+ – one big difference is that C++ has much more in-language support for extending the language. A more fair comparison would be of gtkmm and Qt.

But honestly, after having worked with HTML + JS for some years, I think the simple-building-blocks-and-powerful-styling approach of HTML is actually superior, despite browser incompatibilities. Sure, it’s faster to slam a simple UI together with GTK+. But not many problems actually fit well into that simple UI thinking.

Comment on Platforms as a side effect by Rahul Sundaram

Rahul Sundaram — Sun, 29 Jan 2012 05:40:02 +0000

“Yet Qt was designed as a toolkit from the start and people who tried both Qt and GTK+ tend to find Qt the better toolkit to work with”

I don’t think this is universally true if at all and I don’t think you have any data to support your claim but even if true doesn’t disprove what he said because Qt was written to solve real world problems and not developed in a vacuum.

Comment on Platforms as a side effect by eric-yorba

eric-yorba — Sat, 28 Jan 2012 23:48:41 +0000

But you have to be careful and sensible when you build a new platform. Otherwise you end up with something like this.

Comment on Platforms as a side effect by Jeff Walden

Jeff Walden — Sat, 28 Jan 2012 09:03:28 +0000

Hmm. Having users you're designing for certainly helps. That said, I'm not convinced it's absolutely necessary, nor of course is it sufficient. JavaScript succeeded for a bunch of different reasons, but it certainly didn't succeed because it was forced into existence by Netscape's needs in creating their product, in the sense you mean it. And in sort of a contrast, XUL has enjoyed rather less success despite Netscape forcing themselves into it to ship a product. It seems to me you need at least two more things for a platform-extracted-from-a-product to work. One, as Joshua notes above, you need people who care about the platform, who put work into it. At Netscape (and Mozilla after, pretty much), people worked on the web parts, but the platform parts like XUL received less attention. (Probably even more or less justly.) It's at least partly for that reason that Gecko disabled XUL on the web. Two, you need people who take the broader view, so you don't end up designing only for your own use cases. These might be the same people as the platform people. Or it might be a subset of them. But when your only use is a mail client's tree view of email, you end up designing an awful lot around that and neglecting things you don't need (even things you might later decide you need, like inline-editable folder names in a mailbox tree). Everything I've heard says this goes a long way to explaining why nsITreeView is the huge monstrosity it is, for example. And it goes a long way to explaining why most XUL-based projects end up feeling a lot like web browsers.

Comment on Platforms as a side effect by Benjamin Otte

Benjamin Otte — Sat, 28 Jan 2012 03:11:40 +0000

This is not something I’d put on the “platform” level, I’d put it on the API level. – In fact, people that invent any API should be made to port at least 3 different applications to that API so they see how it works.
For example, porting a bunch of apps to Cairo from GDK drawing taught me a lot about missing convenience APIs or functions that didn’t make sense.

And I agree: If you ever made me write an application, I’d probably turn it into a platform. At least that’s what’s happening to all the code I’ve written so far.