the written word remains

Thanks to Adam and Ariya the topic is hot now so I couldn't resist commenting it :)
From what I can see, they're trying to:
1) get rid of menus
2) get rid of modal dialogs.
I completely support those two goals. Heh, I should have shown those of you who were in Malaga "kdevelop4geeks.ui" file that has been lying on my desktop for more than a month ;) That file is the concept of KDevelop4 user interface I created before I heard about MS Office 12. First version of it didn't contain menus at all and second included a "Menu" button just where the "File" menu is in MSO12. Other concepts I was playing with were different though. Anyway, most of them were efforts to move most of functionality from dialogs to views inside the main window which coincide with the second effort of MS guys.

Thus said, I have to admit that we should probably not copy their interface, at least not in KDevelop. I've only looked at screenshots so I can be wrong here, but it seems their interface is designed for mouse users. Contrary to that, I'd like to see KDevelop interface completely navigatable by keyboard. More, I'd like to make keyboard navigation the prefferred way over mousing. Therefore it's more likely we have to invent a different UI.

Anyway, I'll try to gather my UI ideas and blog more about them soon.

Those two words pretty much describe my experience of Malaga beach :) The sun was mostly under the clouds but still it was really hot ;) The Mediterranean Sea was great (warm and calm) but too salty to my taste. People, you should come to the Crimea (Ukraine) to the Black Sea cost. The water there is as warm but much cleaner (because there's no sand, only pebble) and also it contains twice less salt ;). Anyway, I enjoyed much swimming in the sea :)

This year KDE conference was harder to attend to but we got a series of nice talks. I particularly enjoyed Richard's talk about bindings and Mirko's walk on the dark side (but that's probably because I've been walking on that dark side for more than a month now). The build system BoF was surprisingly fruitful, there were no disagreements and build systems wars at all.

Today I was once again a tourist and woke up early for a city tour. The tour was pretty interesting but too short for my taste so I decided to continue being a tourist and visited Picasso museum. The museum was pretty impressive, lots of original Picasso's paintings are there. Cool! Also did I mentioned that all his paintings contain naked women? ;) Yes, they do, even on those paintings that at the first look contain only lines and triangles, naked women are drawn :)

Ok, enough blogging, shall get back to hacking because I haven't finished yet qmake support for eclipse. Really, I spend too much time talking, eating, drinking, whatever... The "drinking" part is so huge so I managed to got drunk the day before yesterday and forgot my hat and my bag with a bottle of beer (has anyone seen them?). Oh, shame... how much drunk was I to forget a bottle of beer? ;)

While writing our applications we do care about how we accomplish our programming tasks. We want to efficiently write code, easily debug, sync with the repository, etc. But does it really matter what kind of representation on disk our projects have? Let's just imagine a tool that allows you to write code, has code refactoring and completion, builds your projects and api documentation easily, whatever else you could imagine. And if we had this tool, would it be important that the tool stores its data on disk to files? I don't think it would be important. At least I wouldn't care.

The problem is only that we don't have such tool. Editors let you do all that stuff by hand. IDEs try to do that but usualy suck in several cases. And they don't suck because of plain file representation of the code. IDEs usually have several representations of code and project in memory in format that you mentioned (yep, smth like semantic networks, trees, whatever) and they can (and do) store that into disk in binary formats. So the problem is not having the representation but implementing things you're asking about. It just takes enormous amount of time and believe me, implementing source parsers is not the only task that takes that time.

Today I finally got back home. This time I was able to commit all my stuff to the SVN and prepare a little website for those who are curious about what is KDE-Eclipse. Visit http://kde-eclipse.pwsp.net and enjoy!

I've been working on my Google SOC KDE-Eclipse project for several weeks now and what I can tell you is that hacking on Eclipse is a cool experience :) I like that and I don't think I'll drop KDE-Eclipse after 1st of September.
Before I started I knew Eclipse is huge. In reality this doesn't hurt you IMHO just because it has good architecture and it is written in good language (yes, java is ok for me;)). The documentation doesn't help you much though. First, it is not sufficient and second (and importrant) you do not learn much from the documentation.

Thankfully, you have the source code and I really appreciate the source code of Eclipse is open. That's because only from source you can learn as much as necessary. And this fact leads me to think more and more that open source is not about "reusing software" (commercial companies do that as well) but about "reusing experience" which is hidden inside the source.
I have the strong belief that people who write the software are more important than the software itself and by looking to the source code you can gain at least part of experience of people who wrote it. That's the power of open source, that's "reusing experience" concept at work!

Speaking back about Eclipse, I noticed that it's not uncommon when you spend several hours digging into source and docs trying to figure out how things work, how things you have in mind should work and then you spend 15-30 minutes coding your stuff ;) In that respect KDevelop is much easier to hack on. Basically, if you have an idea how usual KDE comonent application works, you can hack on lot of things in KDevelop.

PS: in several days I will commit the stuff I wrote last week so everybody could at last try it in use (yes, it's usable enough now ;)).

Finally it looks like I'm good to go to aKademy. After 3 visits to Spanish embassy (which is 600 km away from my home), 4 days of making phone calls to the embassy trying just to arrange an interview and 2 days of calling to know the result, I was told that I have my visa. Whew :) Now I just need to go to the embassy and take my documents back.
Also thanks to Trolltech (thank you Harald! :)) and KDE-eV (thanks Mirko and other guys :)) my travel expenses will be reimbursed.
That's going to be cool :) I will be able to spend 5 days (till 1st September) hacking on KDE-Eclipse (I'm starting to like that job;) but that's another blog) and other 4 days hacking on KDevelop4.

Today and yesterday I was doing like a real tourist. I visited lots of places in the city, walked tons of kilometers. At the end I got tired but very pleased. Ottawa is a really beautiful city and it doesn't look as other cities I visited :) Cool!

I finally visited America :) Look's like it's a cool place but anyway it's a lot different from Europe. Especially the wet climate makes me feel that the weather in Ukraine is not so bad ;)

I had two talks - one at the DesktopCon and one at LinuxSymposium today. Looks like the one at DesktopCon took more attention. At LinuxSymposium I had two hours for the tutorial. At the first hour I was talking about KDevelop Platform mostly and I had some people interested in the platform stuff we have. Looks like we have to promote it more and try to get more applications written for the platform just to make a really good showcase. The second hour was scheduled after the lunch break and I spent it mostly discussing technical issues with the Eclipse guy (who was KDE developer some time ago btw :)). Other people were not interested in the talk.

Commenting Mathieu's blog, I have to disagree on some things with him. The organization of the conference is ok. I had my two tutorials accepted and we could have more KDE talks accepted if we sent our proposals. But I also have to agree with Mathieu that people who attend this conference are not really interested in KDE technologies. I don't know why - that's probably beyond my understanding. Anyway, there were some cool talks about Eclipse, Kernel (today) and even some X-related talks were ok ;) (we had lots, lots of X talks).

Today my trip to Ottawa is starting. I will give two tutorials - one at DesktopCon (19th) and another at LinuxSymposium (20th). Guys from Xandros were so kind to make this possible by sponsoring me :)

PS: Another thing everybody is wondering about is where is KDevelop Conference dot story. Well, once KDevelop4 is commited to svn, the story will be there ;)

The conference is over now. I'm sitting at home and writing this blog atm. Hope others got to their destinations without problems. I spent great time in Kiev, too bad we had only one week.
The next step will be writing a dot story covering our achievements during the week, I'll do it a bit later after I recover ;)

Despite the conference day started very early we still couldn't start the event in time. Approximately at 10:00 we started. We was torturing our visitors till 18:00 and finished almost in time. Before we finished Ian got his luggage therefore we were able to finish the rest of day drinking Tequila. I think Ian has some really embarrassing pictures of me and Roberto taken during this process :)

Next day we went to the hacking session place, downloaded qt4 and kdelibs4 and started porting kdevelop. This process in ended in the night with KDevelop4 running without any plugins on KDE4. This was quite an achievement so we decided not to continue hacking and spent the rest of the night drinking vodka.

Getting up in the morning was really hard on the third day but we managed to do that and continue porting. This day KDevelop had several plugins ported, Roberto continued working on his parser generator (which is a really cool thing btw ;)). I got kyzis running in KDevelop4. Richard had fun with Ruby grammar and Jens finally made us discuss Quanta/KDevelop integration issues.

Next day I was serving as a city guide :) We walked over almost all cool places in Kiev, visited lots of places and finally about 20:00 we ended up hacking on KDevelop again :) The day was really productive. Roberto wrote ast generator and refactoring engine for his parser generator. Ian started to provide support for qmake from Qt4 in KDevelop3. I updated the documentation plugin to support Qt4 documentation and joined Ian in his effort to improve qmake support.

The fifth day was taxing. I and Jens went to the train station to buy tickets for us. We spent more than an hour waiting in two queues but finally we got our tickets. This day we spent on porting more parts of KDevelop and Roberto and Harald started to improve our projectmanager and other plugins using model/view architecture. At the late night Ian got his improved qmake manager running and said we should have more such meetings. I couldn't disagree with him ;)

When I came to Kiev I didn't realise how much stuff I have to do. The conference preparations took all my time which was spent on arranging meetings with people, printing booklets, announcements and badges. That was really interesting experience for me but now I wouldn't reccommend anybody to undertake such things like conference (especially when you're the only person responsible for that ;) ).

Now I can imagine how much stuff is being done by people working on organizing Kastle/aKademy meetings :) Those guys should really be busy preparing such cool events.
So, talking about the "day-2". I didn't notice it ended because I fall asleep probably just after going back from the city to the place I'm living ;).

Next day in the morning I had an interview at the Canadian embassy. I was applying for visa because I was accepted as a speaker on DesktopCon and LinuxSymposium (17-24 July). Of course, I will be speaking about KDevelop - what else can be expected from me? :)

Canadian embassy impressed me much - I got a visa just in one day. That never happened to me before :). I mean other embassies used to process my application one-two weeks and I was forced to come two-three times.

After I got my visa, I started arranging other conference-related things. That took too much time and therefore I was late to the airport to meet Harald Fernengel and Roberto Raggi. Thankfully, the arrivals queue was really large in the airport and Harald and Roberto managed to get through it only after 1.5 hours waiting. Ian Geiser had more interesting experience of arriving with the wrong flight without his luggage. I must admit he was ok even without the luggage. The only thing he missed was the bottle of Tequilla that was somewhere in his luggage :) Only Richard Dale arrived without problems.

Despite everybody was tired, it was decided to replace Tequilla with a Vodka and that helped a lot to overcome the "tired" state :) The only side-effect Vodka had was that we had 3 hours to sleep before the conference. Of course we could sleep two hours more but nobody had even started their presentations that time ;) So we woke up at 6:00, prepared our presentations and went to the conference place but... that's another story...

Today I was working on a specific part of pretty large project. The goal of that part is to help the user to organize information which he is looking for. Workflow for that user was designed in a way to prevent him from searching randomly in web browsers or local (network) disks. Each time the information (web or local resource) is found it should be categorized automatically (depending on a current search "context").

An application I develop is ought to force that kind of workflow. Obviously I need to have a "restricted" web browser and file manager. I'm quite confident that it's easy to do with KDE libraries. It's just a matter of embedding corresponding parts. But at the same time I though that it's too boring to develop main window for the application and other stuff which is related to browsing (like tabs).

I had been thinking how to make the application prototype faster for less than a minute when a sudden and cool idea came to my mind. KDevelop Platform! What else can make me feel happy and let me finish my prototype in few minutes?

Indeed, I have been working on transformation of KDevelop IDE to the Platform to build new applications for quite some time. I put some efforts to make sure that two current platform applications (IDE and Assistant) use the same plugins and architecture. And it seems that the time has come for me to benefit from that effort.

I'll make a little overview for those who haven't heard of KDevelop Platform so far. The clean platform application (built by just copy-n-paste method using docs) is a main window (shell) with two major capabilities. It is able to
1) load and embed parts by mime type (or manually)
2) load and embed KDevelop plugins.
An amount of plugins loaded is defined by so-called "profile" which (roughly) specifies a list of plugins.
Ok, back to the application. Copy-n-paste method worked and after several minutes spent on creating makefiles I had my application running. I defined "GlobalFileManagement" and "UISwitching" in my profile and got the file manager and UI settings page for free by less than a second.

Then I wrote KDevelop plugin (using KDevelop application wizard, of course ;)) that added a URL requester combo on the toolbar to let the user open web pages in embedded khtml part. That took another couple of minutes (mostly spent on compilation and makefile.am hacking).

As a result, I had a feature-rich application protorype in less than an hour thanks to the KDevelop Platform. Despite the platform is being positioned as a way to build IDE-like applications, my application is not an IDE, it's like a web browser and file manager and (thanks again to the platform architecture) a universal file viewer. I wrote only 35 lines of code to do that. Another 678 lines was either generated by kdevelop application wizard or copied and pasted from the docs.

What can I say after that? KDevelop Platform is cool :) but there are few things to work on.
First, it takes too much time to set up and compile a platform application. We need to provide platform application template for KDevelop application wizard.
Second, it would be cool to do things described above in one of scripting languages to avoid makefile hacking and compilation. I'm confident that platform application in Ruby could have been written in ~10 minutes. Heh, I need to work on Ruby bindings probably.

PS: screenshot.

I always hear how great VMs are, how great is to write programs for VMs, how easy those programs are executed, how efficient they are and so on... That always sounds cool, but I always have a strong feeling that it only sounds such.

Ok, let's consider known "good things" about VM.

1. Programs written for VM are easily portable
   
   Yes, of course. A program compiled into, for example, java VM bytecode can be run everywhere the VM exists. This assumes that no external stuff is used. Yes, no external libraries, no external programs written not for VM. How often can the external stuff be useful? I'd answer - very often. Even if you a volunteer programmer and work times to times on several tasks you will gather a collection of development tools (libs, programs, etc.) you're using. And you're lucky if you started the development for a VM and you're in trouble if you did not. A commercial company would have even more troubles with reusing available stuff.
   
   



2. "Write once - run everywhere"
   
   Yes, it's quite cool to compile program only once and to be able to execute it on different platforms. But the question here is whether testing can be avoided on several target platforms. For example, a company could decide that AIX is too expensive to buy and testing on that platform is not necessary. In ideal world, the company made right decision, in real - it will fail! Even UI will not look the same on different problems. And who knows how much issues with program execution can happen on a different platform?
   
   One can argue that recompilation on different platforms can be enormously hard. Yes, I agree but the problem is not the recompilation itself. The source of a platform are development tools (like different c/c++ compilers, different build systems, etc.).
   
   



3. Modern computers have a lot of spare time - it can be spent for garbage collection and/or JIT compilation
   
   Heh, yes, computers waste a lot of CPU cycles. But why the hell they try to spend those CPU cycles on garbage collection and/or compilation at the same time I try do do something with a program (remember java's "adaptive mark-and-sweep stop-and-copy gc" that makes large java programs so unresponsive?).
   
   I'd say that if I have spare CPU cycles, I'd better spend them on interpreting the program (like python interpreter does) and not on trying to do the "background" magic. Real world proves that the later approach which in theory is slower turns out to be much faster (compare Java/SWT programs to Python/GTK or Python/Qt).
   
   Bear in mind also that python interpreter uses GC with reference counting which should be "much slower".
   
   



4. It's easier to write programs for VM
   
   Huh? It's easier to write programs in java and/or c# but that has nothing to do with a VM. Don't remember that GCJ compiler exists to compile java code into native executables. Similar compiler for c# can be implemented as well.
   
   



5. VM allows reflection
   
   Ok, two questions. How often reflection is used? And isn't reflection available with interpreted languages? My answers are: "rare" and "yes". If you need reflection, use interpreted languages, they can do it easier. Most problems can be solved using some kind of "eval" statement (in ruby, for example, you can even add/modify class definitions using "eval").
   
   



6. It's easy to distribute programs for VM
   
   Ok, now I'm bailing out. This is not a myth - it's a reality. For example, java web start (JNLP) has always attracted me a lot. It's also easy to write and distribute plugins for applications. Anyways, with interpreted languages you can do the same thing and VM is not necessary. And let's consider for a minute troubles with distribution of native-compiled programs for Windows. Most of them are connected to the distribution of dll's which have no versioning information.
   But besides that it's relatively easy to distribute compiled plugins for applications. On UNIX distribution of binaries was always a problem mostly due to binary incompatible libc/etc in dozens of distributions.
   
   

PS: As a postscript I will raise one question. Can aforementioned "good things" be said about a development platform with a compiled language?

And here my answers:

1. Programs written for VM are easily portable
   
   "Write once - compile everywhere" _can_ be achieved. There's no technical problem with that. It's a question of development tools - a compiler, standard library and build system.
   
   



2. "Write once - run everywhere"
   
   "Write once - compile everywhere" can be considered as the same. Testing is always necessary so if a compilation can be made easier and straightforward then those statements become equal.
   
   



3. Modern computers have a lot of spare time - it can be spent for garbage collection and/or JIT compilation
   
   There's no problem in having GC in compiled language. GC with reference counting can be used to avoid stops during program execution. The program will be slower (due to reference counting) but the overall program flow would be perceived as more "natural". For example, everybody knows that python programs are slow - each test shows their slowness, but at the same time python programs do not feel slow. They run smoothly.
   
   



4. It's easier to write programs for VM
   
   For any modern language (java, c#, etc.) a native compiler can be created. If java/c# are not so good, it's always possible to create a better language ;)
   
   



5. VM allows reflection
   
   Interpreter for a language can be created among with native compiler. Developers who need reflection could make use of such interpreter. Or vise versa, a compiler for an interpreted language can be created. The only technical problem to solve here is to allow easy interaction between interpreted and compiled code.
   
   



6. It's easy to distribute programs for VM
   
   If BC is kept for the development platform then it is always possible to distribute binaries and plugins in binary form. A number of rules exists (see, for example, "parallel installation" document for GTK) to ensure the libraries do not clash and old programs can be run on newer platforms. It's just a matter of installing old and new binaries in parallel. Exactly the same thing should be done with VMs. Different versions of VMs can be incompatible so parallel installation is a must.
   
   

And now I'm curious what to write here. Well, time will tell... I hope ;)