Radically embrace the web
Please don't censor this again with a comment about crack cocaine. Integration of desktop apps with web is a real issue. Microsoft has a major project, XAML, aimed at web integration. A Mozilla/Gnome merger similar to this is also being proposed by Brendan Eich. If we don't start a civil discussion around this topic we will never come up with a solution so please add constructive comments below.
Comment by OlavVitters: This section seems to be missing the reasoning behind it (someone else doing it is not good enough, GNOME should aim higher). Also why is Glade not good enough? Changing something just because it is a change seems strange to me. What are the goals/benefits/intentions?
Why?
(from a post by Luis Villa)
Three big things:
- Web development/deployment is easy, and desktop is not.
- Web development makes certain things easy; primarily location independence and collaboration.
- Desktop development has advantages web devel does not (rich inter-app integration, localized search, etc.) but taking advantage of them is a PITA.
Or more simply- our biggest competition in the developer space is not Microsoft, and it isn’t Apple. Our biggest competition in the developer space is php, rails, and the web client-server paradigm. C# and Java are great, but as long as they are pretty wrappers on the same style of development we’ve always done, they are lipstick on a pig. We need to take the plunge and fundamentally make development more web-like while also leveraging the strengths of the client, or else we really are in trouble.
- So, what’s the constructive takeaway that became clear to me at GUADEC? Our developer platform (really, any developer platform that wants to be relevant in 3 years) needs to be:
braindead easy to start with: if you can’t have an app running in an hour, you’re in trouble. 80% principle applies here- the rails people say ‘we don’t care if you can’t build Amazon with rails’; we should probably say ‘we don’t care if you can’t build evo with g-rails.’ If we can’t make developing a desktop app as easy as a web app, people will develop web apps. Simple as that.
dead easy to ship, deploy, and update: probably impossible to be easier than the web here, but we keep saying ‘apt is better than windows install tools’, which isn’t relevant- that’s like saying your car is better than a horse and buggy. Might be true, but the web’s install/use experience is a formula one car. You must beat that, not the horse and buggy. This is something I’m sure others have realized forever but I never did.
building a collaborative app must be easy: I have been using writely instead of abi at work because I can trivially and transparently collaborate with my co-workers. The development platform must have collaboration as an easy-to-use part of the platform or the web will wipe us out on that feature alone.
easy/powerful integration with search: search is really just the canonical example, for me, of things that are easy do across a desktop but which are hard for, say, GoogleOS to do. Obviously google can make it easy for me to search across all google properties, but never (or at least painfully) across flickr, delicious, etc. Our development platform should make it trivial to automagically instrument your files and let beagle know about them.
easy/powerful integration with hardware: another thing desktops can do well and web apps can’t- our platform should make it easy to take full advantage of webcams, microphones, etc. Of course, like many of the other things on this list, this goes way beyond GNOME, but we’ve done that before, and must keep doing it. [Ed.: added later. I knew I’d forgotten something ;)]
identify the web’s weak points, and go after them: search is just one example of things that local, client apps can do easily that web apps cannot. Development platforms (and apps) should be brainstorming hard about all those things, prioritizing them by user impact, and doing them. Every advantage of things you can do that the web can’t should be made trivial to develop and brought to users quickly.
JonSmirl If Gnome 3.0 can truly change APIs, why not do something really radical?
Throw away GTK and gobject. Replace with the Mozilla widget set and XPCOM. Throw away the gnome theme engine and replace with CSS stylesheets. Gecko has both retained mode graphics (DOM) and immediate mode, an app can use either style. Mozilla engine has already been ported to Cairo and it also supports SVG. A lot of redundant work can be eliminated.
Comment by OlavVitters: How does gobject compare to XPCOM? I thought those where totally different things.
Gecko is already pretty close to being a decent widget/graphics toolkit. With some more work it could be a great toolkit. If CSS isn't enough to do theming, extend it. Unification of the web with the desktop is the future of computing.
I'm not talking about making XUL apps inside of Mozilla. These would be normal C apps that build their GUI by manipulating a DOM. An example of this is how gmail mail works. With gmail there is only an initial HTML page. Javascript is then used to manipulate the DOM to change the GUI appearance. Something like an existing word processor would only use the DOM for the frame/toolbar, the actual text could be painted in immediate mode.
Gecko can do most of this today without even being changed. What is missing is for someone to integrate gecko into the whole desktop. With some extra work it might even be possible to build a desktop that can run on multiple platforms.
References:
http://uk.builder.com/webdevelopment/design/0,39026630,20283575,00.htm
http://www.mozillazine.org/articles/article4584.html
http://mail.gnome.org/archives/foundation-list/2004-April/msg00008.html
An example application for this model would be the much talked about but non-existent Google Office. The apps in Google Office are split in half. The front half runs in the browser and the back half runs on a remote server. But you don't have to run the app this way, you could just as easily run both halves of the app on the local machine. Designing apps this way lets you achieve location transparency.
But I can build apps like that right now with GTK! Yes, but what about the 50,000,000 Firefox downloads? By switching to the standardized HTML widgets and integrating with Gecko Gnome apps can then participate in the Firefox revolution. Apps built to a merged Gnome/Gecko platform have the best of both worlds: web access and desktop integration.
Comment by OlavVitters: I still don't understand what part of Firefox having 50,000,000 downloads matters to us. I'm really not trolling, but it seems like a lot of work without any benefit. I could partly understand it if you want GNOME to use XUL (or something like that) / run by the browser, but you don't.. so I'm confused what benefit the 50,000,000 Firefox copies provide.
Re to OlavVitters: In a merged Gnome/Gecko environment a properly constructed app will both run locally and be web deployable. Web deployable means it will run inside of those 50M Firefoxes. Think of it this way, what if HTML/Firefox was based on the GTK toolkit instead of the HTML DOM? If that were true a properly constructed GTK app would run in any of those 50M copies of Firefox just like gmail does today. But that's not true and GTK apps are not web deployable and require you to download or have installed a GTK run-time. We could try and evangelize downloads of the GTK run-time, but why not join forces with Firefox, especially since they want to team up.
Don't get confused about "run in the browser". In a merged Gnome/Gecko world the desktop is "run in the browser" since everyone is using the same widgets and object model. The browser becomes just a thin veneer on top of the base libraries. You are not limited to the basic HTML widgets, XPCOM already supports building and deploying custom widgets. You can also say that this model is too slow or clunky, but the point of doing the merge is to fix those issues.
AlexGraveley: I've made it clear that I think this doesn't belong on this page. You are talking about a fork and complete rewrite of all Gnome code that exists today, which is simply not going to happen. This kind of talk clogs the only current vehicle for rational Gnome 3.0 discussion, and will lead to hackers ignoring it (which may have already happened). Please put this on a separate page and link to it if you want to keep it around.
SachaBerger: I do not have strong feelings about Gnome 3.0 (I can wait for Gnome 3+x.0 for this task) migrating to the Web, but the idea is more than worth to discuss. About having to migrate all Gnome code that exists today : there is a tool called webcream http://www.creamtec.com/webcream/ that helps with deployment of java Swing or AWT applications (ideally without change) as web application using plain HTML. Having a XUL/HTTP/HTML/... backend for GTK would at least be something really radical (citing JonSmirl) and a starting point for migration of existing/legacy Gnome applications.
ChristianSchaller: Ok, I moved this onto a separate page as I felt it is an interesting idea, but a XUL based desktop have to pop up as a new project on the side of GNOME as there is no natural migration route for any current apps or libraries. And as such it doesn't belong in its whole on the main 3.0 discussion wiki.
ClausSchwarm: Looks like something similar exists already SymphonyOS.
AjayShyanbhog: Libraries for rendering XUL apps can be added without the need to touch existing GTK libs. Two or three simple apps built to use these libs will help identify and resolve issues that may crop up with XUL. Maybe much of mozilla codebase can be resued for building the libs. If XUL is found delivering on its promise, it can be taken further.
JamesHutton: Wouldn't an eventual shift towards this possibly reduce the codebase for gnome? Not saying its big, but it would prevent you from having to reinvent the wheel. Also it would drastically increase the number of developers working on these libraries. If anything, it could be added, but not as a replacement in 3.0. This could expand the various apps that are developed towards the gnome desktop. Then after seeing where the additional feature brings gnome to, it can be reevaluated as to whether purge it or use it as a replacement.
LarsDuesing: Why not build gtk-to-xul wrapper libraries? That would be a charm, but I think it would be heavy work.
AndreyGavrilov: It would be very good if all themes would be defined in CSS, all user interface could be described in XML and all code could be written in JavaScript. But I think gtk-to-xul wrapper would be prefferable way of doing so. Once the GTK will have a sane object tree system and CSS-theming, it wouldn't be hard to add such wrapper.