Desktop Environments and File Uploads

I remember when I used to see web applications with forms that had up to ten file fields, you know, in case you wanted to be more productive and submit many files in the same post. I smile when I think about those forms, not just because they looked funny, what with the repeating vertically-stacked file inputs, but also because of the whole file upload concept. Beyond sharing images on social networks, the practical use of user-generated files on the web has it's limitations. Think about where most of our tools are located. We're generally not screaming for new desktop applications, unless we're part of a particular crowd — like developers, graphic designers, hardcore gamers. We need desktop applications for these purposes, and these applications deal with files. But the vast majority of internet use isn't to this degree of specialization. What use does the general internet population have for file?

Turning Off Desktop Innovation

An interesting entry brings up the always controversial discussion of innovation in the open source desktop domain. I'm not entirely convinced that this topic should be nearly as controversial as it seams to be. And who knows, maybe it isn't. Putting the desktop operating system environment aside for a moment, innovation in software as a whole is hard. It is also a requirement of doing software development. Do nothing, and nothing will happen. If there were no innovation in desktop computing environments, in open source Linux distributions specifically, the end users would be stuck in the same situation. However, as the entry asks this very question, perhaps the users are stuck where they are for a reason. Maybe they have zero need to innovation that would serve their particular purpose. They use what they are using because it helps them reach their ultimate goal. Sometimes with innovative software, users are presented with features they didn't no they needed until they became available. This, not always, but often enough, translates to they don't really need it at all. However, users aren't going to be able to use the same piece of software indefinitely in the majority of cases. So, it seems that the logical thing to strive for here is a balance between stability and new features (innovation).

When attempting to strike a balance between stability and new features, developers are faced with an additional challenge. Toward the tail end of this entry, the option of turning these new innovative features off entirely is mentioned. I think an important characteristic to think about when considering new innovative features. Think about it. You ship your existing stable features along with the brand new innovative stuff. If something blows up in the new feature set, the user simply turns it off. Simply of course not being quite accurate. This ability to turn features on and off is no easy feat. Consider the notion of extension modules. The whole idea behind them is that they extend some piece of core functionality. They can also be turned off. However, this is generally done with configuration files that a typical desktop end-user should never be expected to interface with. So, there is the the technical aspect of modularity of features.

Assuming there were a robust, modular desktop architecture that allowed developers to turn features on and off, how would the desktop compel the user to use the new "better" features? Do the new features default to "on"? There is the whole usability question in addition to a very challenging technical problem.

Qt-based Gnome a step closer

In a 2008 interview, Mark Shuttleworth spoke of the possibility of a Qt-based Gnome desktop. It looks like that possibility has moved a step forward with the Qt library now being available under the LGPL.

I think there is nothing wrong with the visual appeal of the current Gnome. I also really like Qt so it is a win-win for me.

Is javascript ready for the desktop?

The web browser has come a long way since its' inception. The first basic requirements of the web browser were to retrieve and format hypertext. Now, you can pragmatically display content within the browser using javascript. Firefox offers another level of programmatic customization using XUL.

This is nothing new. The web browser and javascript have both been around for some time now. Also not new is the fact that the web browser runs on the desktop. So the question is javascript ready for the desktop seems a little obvious at first glance or perhaps even just plain wrong. Another form of the question might be can javascript applications replace the majority of existing desktop applications. To most developers, or desktop users for that matter, this question of javascript desktop readiness simply leads to endless other questions.

The most important of course being why bother. If we already have all these applications that run perfectly well (and fast) on the desktop, why replace them? I would argue that as of right now, there probably is no reason to replace desktop applications. However, I would also argue that the possibility and feasibility of replacing certain desktop applications is certainly worth thinking about.

The speed argument may be a show-stopper in many cases. Especially when the latency involved arises as a result of loading the code that is the application. If a javascript application is running on the desktop, the javascript code already exists on the desktop and therefore the latency involved in delivering the application is removed. What about the data involved in application? If the data is remote, the same latency is going to be involved regardless of the client using the data. In fact, the tricky part is when the data resides on the same desktop as the javascript application.

Trying to perform read and write operations on the desktop hard drive using javascript is hopeless. So how do we make the hard drive operations available within javascript? My solution would be to create a simple HTTP data server that runs on the desktop. This server would provide only what is required to manipulate the hard drive. The server would not host the application code or any static files for that matter. It is not needed since all the application resources are local. The only need for the server would be raw data access.



Here, a simple node depicting the desktop computer contains the server component and the browser component.

Now suppose this worked (I have not actually tried it), that would mean it is possible to write javascript applications for the desktop. What now? We need some rationale for doing so. On the development end, productivity levels increase when building GUIs using a combination of javascript+HTML+CSS. In my opinion, as a developer (I'm by no means a GUI designer), I find writng javascript much simpler then trying to use a traditional GUI kit such as Qt. Especially given that talented CSS designer can create exceptionally beautiful work using only CSS.

The work is also simplified with javascript toolkits such as dojo. The dojo toolkit provides a multitude of GUI widgets that are already themed quite nicely. I also find interesting the fact that these toolkits have come into existence. It goes to show that there is a real desire to use the web browser as a platform.

Where to start? What would be the first desktop application to re-write in javascript? How about a file browser? It should be a fairly simple application to write and would serve as a useful proof of concept. Text editor? There are some reasonably powerful editor widgets which provide half the implementation.

So, as a quick summation, there is no real pressing reason to develop desktop applications using javascript. However, for the future, it may be worth exploring now. Especially considering the recent major speed enhancements made to the Firefox web browser. Opera is another quality in which to use this future platform. Although IE sucks, its' market share is currently a reality.