Today was finally the day of my PhD thesis defense! The defense went very well, the scientific council of my university approved my work with 10 votes "for" and 0 votes "against" and was overall pleased with my research :)
So now I need only to do nothing but wait for state examination board to approve the work and issue the PhD diploma.
12 November 2007
10 October 2007
Nostalgia for Kugar
It's been a long time since I last used Kugar. It's been even longer time since I last developed Kugar. But today was the Kugar day...
Yes, today I had to address 95 envelopes (I'm about to send printed abstracts of my PhD thesis). I had addresses written in the text file and I had to print them on envelopes. What was my solution? Of course to use the report generator and of course Kugar was that report generator ;)
2 minutes I spent writing a simple 10 line awk script that transformed text to Kugar xml format. 5 minutes were necessary to design the template in Kudesigner. And finally 10 more minutes I was figuring out how to properly insert the envelope to my printer ;) Overall, about 20 minutes for the task.
I remember my colleague telling me recently that he went to bed at about 5am because he was printing addresses. I can imagine him copying and pasting from one Word document with the list to another Word document with the envelope :) The fact is that it's only midnight here and I've already printed everything I wanted and can go to bed!
Anyway, I'd like to say that Kugar is pretty cool despite being unmaintained for 3 years. Yes, the software (especially Kudesigner) has now lots of bugs that weren't in the code 3 years ago, but it still remains highly usable.
Kugar's biggest problem is still actual though - nobody knows when to use it. So remember: If you have any data in the format translatable to xml and you want to print it using the template, Kugar is your tool. That simple! No databases (they are supported but completely optional), just two xml files - one with the data generated by you or your program and another one with the template generated by Kudesigner.
PS: if you would like to contribute to Kugar, kick me hard and ask for the recent sources. I've ported portions of the source code to Qt4 already. Also my own copies are more stable and usable than ones in KDE svn. I never committed them because they don't have dependency on KDE libs (they just depend on Qt)
Yes, today I had to address 95 envelopes (I'm about to send printed abstracts of my PhD thesis). I had addresses written in the text file and I had to print them on envelopes. What was my solution? Of course to use the report generator and of course Kugar was that report generator ;)
2 minutes I spent writing a simple 10 line awk script that transformed text to Kugar xml format. 5 minutes were necessary to design the template in Kudesigner. And finally 10 more minutes I was figuring out how to properly insert the envelope to my printer ;) Overall, about 20 minutes for the task.
I remember my colleague telling me recently that he went to bed at about 5am because he was printing addresses. I can imagine him copying and pasting from one Word document with the list to another Word document with the envelope :) The fact is that it's only midnight here and I've already printed everything I wanted and can go to bed!
Anyway, I'd like to say that Kugar is pretty cool despite being unmaintained for 3 years. Yes, the software (especially Kudesigner) has now lots of bugs that weren't in the code 3 years ago, but it still remains highly usable.
Kugar's biggest problem is still actual though - nobody knows when to use it. So remember: If you have any data in the format translatable to xml and you want to print it using the template, Kugar is your tool. That simple! No databases (they are supported but completely optional), just two xml files - one with the data generated by you or your program and another one with the template generated by Kudesigner.
PS: if you would like to contribute to Kugar, kick me hard and ask for the recent sources. I've ported portions of the source code to Qt4 already. Also my own copies are more stable and usable than ones in KDE svn. I never committed them because they don't have dependency on KDE libs (they just depend on Qt)
22 September 2007
Something is rotten in the state Ukraine
Maybe you know, maybe you don't, but Ukraine is approaching another round of parliament elections. As we didn't have enough elections recently! And once again, three major forces participate and again as arrogant and hostile they are, they try to be good now and evince at least some care about Ukraine and Ukrainians:
But look at the pictures, look carefully, look closely. Maybe you'll see what I can't see there. Maybe I'm blind, but what I see is only lots, lots of white, orange and blue flags that belong to our celebrated political parties. And what I don't see is Ukrainian flags! There're none. No flag of the country and people they are so selflessly fighting for.
These pictures alone clearly show how much our parties care about Ukraine... Imagine how many other proofs we have here ;) Do we need these guys in parliament? Several years in a row my answer was "no!". This year I say "stay away from this country!".
Photos are copyright UNIAN. Links: 1, 2, 3
But look at the pictures, look carefully, look closely. Maybe you'll see what I can't see there. Maybe I'm blind, but what I see is only lots, lots of white, orange and blue flags that belong to our celebrated political parties. And what I don't see is Ukrainian flags! There're none. No flag of the country and people they are so selflessly fighting for.
These pictures alone clearly show how much our parties care about Ukraine... Imagine how many other proofs we have here ;) Do we need these guys in parliament? Several years in a row my answer was "no!". This year I say "stay away from this country!".
Photos are copyright UNIAN. Links: 1, 2, 3
08 September 2007
Funny consequences of "functions are objects" rule in Scala
Sorry for another Scala-related post, but I simply couldn't stand. This language is an unique combination of interesting language features and clear and concise syntax which is so rare in the world of programming languages.
Scala is truly object-oriented. This does mean that everything is an object, even functions. Err, functions you'd ask? Yeah, functions are indeed objects but that wasn't a surprise for me because I've seen and used that in Javascript. But function inheritance indeed was a surprise.
How can that be possible? Martin Odersky gives an example that functions with one argument in Scala are objects that mix1
Here "-A" means that function that has AnyRef as an argument inherits a function that has a String argument. Take a look at this magical example: ;)
Isn't that cool, the function doSmthAny with AnyRef (aka Object in Java) argument inherits the function doSmthStr with String argument and therefore can be used whenever we need doSmthStr. Amazing!!!
Even more amazing is when the return types in those functions are different. For a function to be the subtype of another function we not only require its argument to be a supertype, but its return value to be a subtype. Citing "Scala by Example" book, function S=>T2 is a subtype of S'=>T' if S' is a subtype of S and T is a subtype of T'.
1
Traits are the Scala implementation of mixins. For C++ guys mixin is just a multiple inheritance. For Ruby guys trait is more like a module (the difference is that in Ruby you'd "include" the module into your class and in Scala you'd "extend" the class with a trait).
2
S=>T is a function defined as:
Scala is truly object-oriented. This does mean that everything is an object, even functions. Err, functions you'd ask? Yeah, functions are indeed objects but that wasn't a surprise for me because I've seen and used that in Javascript. But function inheritance indeed was a surprise.
How can that be possible? Martin Odersky gives an example that functions with one argument in Scala are objects that mix1
trait Function1[-A, +B] {
def apply(x: A): B
}
Here "-A" means that function that has AnyRef as an argument inherits a function that has a String argument. Take a look at this magical example: ;)
object MyProg {
def doSmthStr(a: String): Int = a.length
def doSmthAny(a: AnyRef): Int = a.hashCode
def compute(function: AnyRef => int) = {
function("Haha")
}
def compute2(function: String => int) = {
function("Haha")
}
def main = {
// not possible because doSmthStr is of type String => int
// which is supertype of AnyRef => int
compute(doSmthStr)
// possible because doSmthAny is exactly of type AnyRef => int
compute(doSmthAny)
// possible because doSmthStr is exactly of type String => int
compute2(doSmthStr)
// possible because doSmthAny is of type AnyRef => int
// which inherits String => int
compute2(doSmthAny)
}
}
MyProg.main
Isn't that cool, the function doSmthAny with AnyRef (aka Object in Java) argument inherits the function doSmthStr with String argument and therefore can be used whenever we need doSmthStr. Amazing!!!
Even more amazing is when the return types in those functions are different. For a function to be the subtype of another function we not only require its argument to be a supertype, but its return value to be a subtype. Citing "Scala by Example" book, function S=>T2 is a subtype of S'=>T' if S' is a subtype of S and T is a subtype of T'.
1
Traits are the Scala implementation of mixins. For C++ guys mixin is just a multiple inheritance. For Ruby guys trait is more like a module (the difference is that in Ruby you'd "include" the module into your class and in Scala you'd "extend" the class with a trait).
2
S=>T is a function defined as:
def function(arg: S): T
More surprises in Scala: covariance and contravariance
I've been reading more about Scala discovering more and more nice features the modern language with static typing can bring. Some of those features look to me just as an syntactic improvement over what we already can do with another statically typed languages like C++. For example, pattern matching example from my last blog is definitely what you can do with several AST classes (they need to have type() or rtti() method) and your own implementation of visitor pattern in C++.
But there're some language features in Scala I didn't expect and didn't think about before. The perfect example IMHO is covariant and contravariant subtyping I discovered for myself just a couple of days before.
Think about this example, if we have class B that inherits class A then we can use objects of type B whenever we need objects of type A. So far so good. But what if we have template class X with A and B as parameter types? C++ tells us X<A> and X<B> are unrelated:
Contrary to that, in Scala you can declare that X[B] inherits X[A] and have covariant subtyping or even declare that X[B] inherits X[A] and have contravariant subtyping:
Not that some elements of covariance and contravariance of types didn't exist before in familiar languages like C++ and Java. Contrary to that they did, but most likely I woulnd't have learned about them if I didn't start learning Scala which directly exposes those things as language features. Cool language Scala is... I must say, very cool ;)
But there're some language features in Scala I didn't expect and didn't think about before. The perfect example IMHO is covariant and contravariant subtyping I discovered for myself just a couple of days before.
Think about this example, if we have class B that inherits class A then we can use objects of type B whenever we need objects of type A. So far so good. But what if we have template class X with A and B as parameter types? C++ tells us X<A> and X<B> are unrelated:
class A {};
class B: public A {};
templateclass X {};
int main()
{
B *t1 = new B;
A *t2 = t1; //ok because B inherits A
X<B> *x1 = new X<B>;
//error!!! because C++ has non-variant subtyping
// so X<B> and X<A> are different types
X<A> *x2 = x1;
}
Contrary to that, in Scala you can declare that X[B] inherits X[A] and have covariant subtyping or even declare that X[B] inherits X[A] and have contravariant subtyping:
class A {}
class B {}
class X[+Type] {} // +Type means "covariant"
val t1 = new B
val t2 = t1 // ok, B inherits A
val x1 = new X[B]
val x2 = x1 // ok too because X[B] inherits X[A]
return
Not that some elements of covariance and contravariance of types didn't exist before in familiar languages like C++ and Java. Contrary to that they did, but most likely I woulnd't have learned about them if I didn't start learning Scala which directly exposes those things as language features. Cool language Scala is... I must say, very cool ;)
26 August 2007
Scala: a pleasant discovery
I've recently became quite confident that choosing programming language is a process that is very similar to choosing what to cook. First you taste something. If you like it, you eat it. If you really really like it you look for a recipe and try to cook it. Same for the programming language. First you see some code in that language. If you like it, you read more about the language, learn its concepts and ideas. If you really really like what you found, you start programming in that language.
What's interesting is that your consciousness is not usually involved in the tasting phase. On the surface it's simple - you either like new thing or not. But I do believe that there's a serious subconscious process involved here that takes into account all your previous experience and tells you "yes" or "no" to this new thing.
I've made several failed attempts to ignore this subconscious decision and force myself into learning things I don't like. Ironically, such first attempt was Lisp and the last one was Haskell. Needless to say that Lisp still means to me nothing more than lots of isolated, sil^^^... (you know what ;)) and Haskell is still for me nothing more than a pure product of pure mind. Once again, no offense to these languages and people using them. That's just my mind that doesn't allow me to like these great languages ;)
Contrary to that, I made quite a success learning languages I liked. The best examples would be Prolog and Ruby. And yesterday I discovered for me another language I liked from the first look - Scala. So instead of working hard on my projects and my PhD, I spent last two days reading about Scala.
And I should say the language is very cool. It implements an interesting mixture of functional and object-oriented programming paradigms but keeps static typing and very clean syntax. For those familiar with Ruby, I'd say Scala often feels like Ruby that is statically typed, has C-ish syntax and implements more functional programming goodies. I think next time I'll come up with a side-by-side Ruby vs Scala comparison.
And finally a little code snippet for you to taste ;) (from excellent Martin Odersky's "Scala by Example" book)
What's interesting is that your consciousness is not usually involved in the tasting phase. On the surface it's simple - you either like new thing or not. But I do believe that there's a serious subconscious process involved here that takes into account all your previous experience and tells you "yes" or "no" to this new thing.
I've made several failed attempts to ignore this subconscious decision and force myself into learning things I don't like. Ironically, such first attempt was Lisp and the last one was Haskell. Needless to say that Lisp still means to me nothing more than lots of isolated, sil^^^... (you know what ;)) and Haskell is still for me nothing more than a pure product of pure mind. Once again, no offense to these languages and people using them. That's just my mind that doesn't allow me to like these great languages ;)
Contrary to that, I made quite a success learning languages I liked. The best examples would be Prolog and Ruby. And yesterday I discovered for me another language I liked from the first look - Scala. So instead of working hard on my projects and my PhD, I spent last two days reading about Scala.
And I should say the language is very cool. It implements an interesting mixture of functional and object-oriented programming paradigms but keeps static typing and very clean syntax. For those familiar with Ruby, I'd say Scala often feels like Ruby that is statically typed, has C-ish syntax and implements more functional programming goodies. I think next time I'll come up with a side-by-side Ruby vs Scala comparison.
And finally a little code snippet for you to taste ;) (from excellent Martin Odersky's "Scala by Example" book)
abstract class Tree
case class Sum(l: Tree, r: Tree) extends Tree
case class Var(n: String) extends Tree
case class Const(v: int) extends Tree
type Environment = String => int
object MyProg {
//uses pattern matching to evaluate the expression
def eval(t: Tree, env: Environment): int = t match {
case Sum(l, r) => eval(l, env) + eval(r, env)
case Var(n) => env(n)
case Const(v) => v
}
def main {
val env: Environment = { case "x" => 5; case "y" => 10 }
//(x+x) + (7+y)
var expr: Tree = Sum (Sum(Var("x"), Var("x")), Sum(Const(7), Var("y")))
//(5+5) + (7+10)
println(eval(expr, env)) //prints: 27
}
}
MyProg.main
15 June 2007
PhD: T minus two...
Today the scientific council in my university approved my work for defense :) so I have only two steps left - defense itself and state examination board approval. Looks like the five-year work finally comes to its end. Whew :)
02 June 2007
RailsConf'07 post mortem
RailsConf this year was huge. About 1600 people were there who paid incredibly high amount of money for the entry. And (like last year) it was again a show with Chad Fowler playing balalaika (or what was that instrument), Ze Frank amusing auditorium with his keynote and of course Dave Thomas again talking nonsense ;)
What is really noticeable is that Rails community became bigger and more pragmatic. We've got only two talks of "is Rails ready for the Enterprise" kind and both of them were not really about the subject. That's surely a good sign, but that's also a sign that the whole Ruby/Rails grew and will start loosing this aura of cool hacker's toolchain.
Not that I care about that much because I still think Ruby and Rails are powerful technologies that allow us to enjoy what we're doing but... this year is about time to start looking at others. People following Reddit might already have the impression Haskell is going to be the new hacker's toy. And maybe it will, who knows... It looks like in the next year we'll see some articles about "is Haskell ready for the Enterprise?" :) Heh... I'd better start fighting with my distaste for functional programming ;)
What is really noticeable is that Rails community became bigger and more pragmatic. We've got only two talks of "is Rails ready for the Enterprise" kind and both of them were not really about the subject. That's surely a good sign, but that's also a sign that the whole Ruby/Rails grew and will start loosing this aura of cool hacker's toolchain.
Not that I care about that much because I still think Ruby and Rails are powerful technologies that allow us to enjoy what we're doing but... this year is about time to start looking at others. People following Reddit might already have the impression Haskell is going to be the new hacker's toy. And maybe it will, who knows... It looks like in the next year we'll see some articles about "is Haskell ready for the Enterprise?" :) Heh... I'd better start fighting with my distaste for functional programming ;)
21 May 2007
Domination
I'm sitting here at one of the boring talks at RailsConf and have nothing to do, so I decided to blog a bit :)
Basically Ruby/Rails people are great Mac fans (this Flickr picture). Some of them use Windows. But what's really interesting that there's a number of people who're using Linux here and all those people I've seen have KDE on their desktops. I don't know what is the most popular distro among them, but two Kubuntu addicts are sitting near me at this moment. And that's cool, isn't that :)
Basically Ruby/Rails people are great Mac fans (this Flickr picture). Some of them use Windows. But what's really interesting that there's a number of people who're using Linux here and all those people I've seen have KDE on their desktops. I don't know what is the most popular distro among them, but two Kubuntu addicts are sitting near me at this moment. And that's cool, isn't that :)
20 May 2007
Catching up
Uh, I have discovered I haven't blogged since March. Not that nothing happened, contrary a lot of cool things were in those two months.
First, there's a lot things done in KDevelop. I was overloaded with work and PhD so didn't do any hacking but other guys worked really hard. Dukju continued his crusade against svn ;) Andreas and Matthew dug into version control interfaces and infrastructure like mad.
In fact, they sent so many emails to the kdevelop-devel mailing list so I believe now we beat the nosiness record on what was renowned as a very silent list :) And that's actually great. It indirectly indicates the amount of energy and potential in KDevelop community. We're keen, we're eager and we're kicking :)
Oh, and there's one more thing I forgot to mention about. Andreas got KDevelop working on Windows (see the obligatory screenshot below). So KDevelop is now as multiplatform as possible. Unix, Mac OS native, Windows native is all possible with Qt4 and KDE4! So, if you're still using Eclipse or something like that just because it works for you on Windows, tune up and keep an eye on KDevelop4. We will be multiplatform once we release ;)
Among the cool things happened last time is that I finally visited US :) I never had the chance to go there before, but it looks like my chances grew a lot after I became Ruby/Rails developer at Pluron company. So now I'm sitting at the Oregon Convention Center in Portland listening to the one of the RailsConf 2007 talks! I think I'll blog about RailsConf soon.
Btw, have I already mentioned that Pluron is a cool place to work? ;) If you read this, live in Ukraine and is a cool programmer/sysadmin/designer/QA specialist, drop me a note, we're hiring.
First, there's a lot things done in KDevelop. I was overloaded with work and PhD so didn't do any hacking but other guys worked really hard. Dukju continued his crusade against svn ;) Andreas and Matthew dug into version control interfaces and infrastructure like mad.
In fact, they sent so many emails to the kdevelop-devel mailing list so I believe now we beat the nosiness record on what was renowned as a very silent list :) And that's actually great. It indirectly indicates the amount of energy and potential in KDevelop community. We're keen, we're eager and we're kicking :)
Oh, and there's one more thing I forgot to mention about. Andreas got KDevelop working on Windows (see the obligatory screenshot below). So KDevelop is now as multiplatform as possible. Unix, Mac OS native, Windows native is all possible with Qt4 and KDE4! So, if you're still using Eclipse or something like that just because it works for you on Windows, tune up and keep an eye on KDevelop4. We will be multiplatform once we release ;)
Among the cool things happened last time is that I finally visited US :) I never had the chance to go there before, but it looks like my chances grew a lot after I became Ruby/Rails developer at Pluron company. So now I'm sitting at the Oregon Convention Center in Portland listening to the one of the RailsConf 2007 talks! I think I'll blog about RailsConf soon.
Btw, have I already mentioned that Pluron is a cool place to work? ;) If you read this, live in Ukraine and is a cool programmer/sysadmin/designer/QA specialist, drop me a note, we're hiring.
20 March 2007
Yes, summer ends this week
As Thiago noted, the deadline for Google Summer of Code applications is approaching. And I'd like to note that we have not many applications for KDevelop related projects yet. Last year there were about 7-8 (or more), 3 of which were accepted. This year we have 2 applications filled and 1 pending. What does that mean? This means that you have a chance to get your KDevelop-related project accepted. Go ahead!
07 March 2007
KDevelop4 evolution: The application templates
IDE's are usually created to make things easier and faster for developers. And most of them achieve this goal to some extent. But there is one group of people that has always suffered from IDE's. Those people are application template developers.
Tons of subtle application template formats were invented to bend to submission those miserable souls who wanted to add their little template!
Anjuta requires you to write a nice xml file with template description including wizard page layout options, list of template files, directories and of rename rules. To do substitutions in the template files you have to spend a week learning extremely powerful but also extremely complicated autogen format so you could write something like this or this.
Eclipse makes the process even more interesting. There's no application wizard, there's no template format. When you want something like that, you just have to code it in Java by yourself. Easy, isn't it? Choose between org.eclipse.cdt.ui.wizards.NewCProjectWizard, org.eclipse.ui.wizards.newresource.BasicNewResourceWizard or org.eclipse.ui.INewWizard, subclass/implement, write everything else by hand and get something like I got for KDE-Eclipse
KDevelop3 was not really different. Our first template format required you to write a template description and a perl script with installation instructions. Our second template format combined descriptions with processing/installation instructions to the single file. To make things even more interesting, we did not allow to have subdirectories in the templates, so you had to write special subdirectory creation and file copy instructions when you wanted for example to put the main.cpp into /src.
I created several application templates for KDevelop by myself and found that process too complicated and annoying. So when I was working on KDE-Eclipse I thought of ideal template format and soon figured out that a simple tarball is the format of my dream.
Really, why don't application wizard just extract the tarball and so some variable substitutions? I implemented exactly that: extraction + substitution and that worked better than any of those sophisticated template systems I know about.
So when the time had come to implement the application wizard for KDevelop4 I didn't hesitate and did the same thing again. So from now to create an application template for KDevelop4 you just need to:
As an example, take a look at our Qt4 application template in the unpacked form.
Of course, the variables that are not known to the application wizard has still to be declared in .kdevtemplate so that user can be asked at project creation time. But the whole thing is still as simple as possible and I will make sure we will stick to KISS principle and won't harry apptemplate developers anymore ;)
Tons of subtle application template formats were invented to bend to submission those miserable souls who wanted to add their little template!
Anjuta requires you to write a nice xml file with template description including wizard page layout options, list of template files, directories and of rename rules. To do substitutions in the template files you have to spend a week learning extremely powerful but also extremely complicated autogen format so you could write something like this or this.
Eclipse makes the process even more interesting. There's no application wizard, there's no template format. When you want something like that, you just have to code it in Java by yourself. Easy, isn't it? Choose between org.eclipse.cdt.ui.wizards.NewCProjectWizard, org.eclipse.ui.wizards.newresource.BasicNewResourceWizard or org.eclipse.ui.INewWizard, subclass/implement, write everything else by hand and get something like I got for KDE-Eclipse
KDevelop3 was not really different. Our first template format required you to write a template description and a perl script with installation instructions. Our second template format combined descriptions with processing/installation instructions to the single file. To make things even more interesting, we did not allow to have subdirectories in the templates, so you had to write special subdirectory creation and file copy instructions when you wanted for example to put the main.cpp into /src.
I created several application templates for KDevelop by myself and found that process too complicated and annoying. So when I was working on KDE-Eclipse I thought of ideal template format and soon figured out that a simple tarball is the format of my dream.
Really, why don't application wizard just extract the tarball and so some variable substitutions? I implemented exactly that: extraction + substitution and that worked better than any of those sophisticated template systems I know about.
So when the time had come to implement the application wizard for KDevelop4 I didn't hesitate and did the same thing again. So from now to create an application template for KDevelop4 you just need to:
- have a directory with your project
- place variables in file names and contents
- write very simple .kdevtemplate file with a description like this one
- and pack it
As an example, take a look at our Qt4 application template in the unpacked form.
Of course, the variables that are not known to the application wizard has still to be declared in .kdevtemplate so that user can be asked at project creation time. But the whole thing is still as simple as possible and I will make sure we will stick to KISS principle and won't harry apptemplate developers anymore ;)
06 March 2007
KDevelop4 evolution: The project and buildsystem management
IDE's project management features are what everyone can see. Together with advanced language support features, proper build system support is the most prominent feature that differentiates IDE's from various editors, advanced and not.
And proper project management with proper buildsystem support is hard. KDevelop3 was very good at that. Anjuta only recently got close to what our Automake manager had for 4 years. My KDE-Eclipse autotools plugin did get some attention by RedHat guys after I stopped working on it, but I don't know what happened next. Seems like "fedora eclipse" project now superseded it. So even Eclipse doesn't have something on a par yet.
This all means KDevelop's features are still unique. Especially unique is QMake manager which has no alternatives I know about. After Andreas Pakulat took my qmake parser and vastly improved the manager in KDevelop 3.4, we can open and manage the most complex qmake project - the whole Qt library (both 3.x and 4.x versions).
But the time doesn't stop and KDevelop development doesn't stop either. We always wanted to change two things in 3.x - make it possible to open more than one project at a time and avoid code and UI duplication between buildsystem plugins.
As for today, in KDevelop4 we managed to realize our plan. First, Andreas Pakulat implemented support for opening several projects at a time. Second, we used Roberto Raggi's project management architecture with one user-visible "Project Management View" which displays information from various build system managers. That all grants the popular wish to open many projects and solves code maintainability and complexity issues at the same time!
You can see the current state of things in the screenshot below where I've opened two QMake projects using QMake Manager and KDevelop4 project using Generic Manager (CMake Manager is not yet ready). Looks cool, doesn't it? ;)
And proper project management with proper buildsystem support is hard. KDevelop3 was very good at that. Anjuta only recently got close to what our Automake manager had for 4 years. My KDE-Eclipse autotools plugin did get some attention by RedHat guys after I stopped working on it, but I don't know what happened next. Seems like "fedora eclipse" project now superseded it. So even Eclipse doesn't have something on a par yet.
This all means KDevelop's features are still unique. Especially unique is QMake manager which has no alternatives I know about. After Andreas Pakulat took my qmake parser and vastly improved the manager in KDevelop 3.4, we can open and manage the most complex qmake project - the whole Qt library (both 3.x and 4.x versions).
But the time doesn't stop and KDevelop development doesn't stop either. We always wanted to change two things in 3.x - make it possible to open more than one project at a time and avoid code and UI duplication between buildsystem plugins.
As for today, in KDevelop4 we managed to realize our plan. First, Andreas Pakulat implemented support for opening several projects at a time. Second, we used Roberto Raggi's project management architecture with one user-visible "Project Management View" which displays information from various build system managers. That all grants the popular wish to open many projects and solves code maintainability and complexity issues at the same time!
You can see the current state of things in the screenshot below where I've opened two QMake projects using QMake Manager and KDevelop4 project using Generic Manager (CMake Manager is not yet ready). Looks cool, doesn't it? ;)
24 February 2007
Scripting KDevelop3?
"Scripts" menu has been a dark horse of KDevelop since it first appeared. Almost nobody knew what it was and understood what hides beneath it (myself included until recently). But in fact the menu is the only visible hint KDevelop3 has some scripting features.
Those features are not so powerful as in Emacs, but they solve different problem. Emacs has Emacs Lisp to:
All modern IDE's I know about use different approach. They have:
You can write plugins in C++ for KDevelop and or course you can write scripts. KDevelop exposes its internals via DCOP therefore the choice of scripting language is virtually unlimited. Either your language has DCOP bindings (like Perl, Java, Python, Ruby, KJS) or it can execute dcop command via shell.
Imagine a C++ project with some parts written in Python or Ruby. You naturally want it to be opened as C++ project to have nice integration but you also want a way to easily run your Ruby and Python programs. When working on Ruby projects, you are able to run currently edited programs. But there's no such option when a C++ project is opened. So why don't we implement that with a script?
KDevelop automatically loads all scripts it can find into the "Scripts" menu. The search path by default is $KDEDIR/share/apps/kdevelop/scripts, $KDEDIR/share/apps/kate/scripts and their user-editable equivalents ~/.kde/share/apps/kdevelop/scripts and~/.kde/share/apps/kate/scripts.
Script has to be an executable file and needs to have a .desktop file with a short description. Our script menu item will be called "Run Ruby Program" and the actual script will be a shell script called runrubyprogram.sh. Below are the sources for runrubyprogram.desktop and runrubyprogram.sh I wrote today:
runrubyprogram.desktop
runrubyprogram.sh
As you can see, two DCOP calls are made to get the name of currently opened file and project directory and one DCOP call to execute a command inside KDevelop. Each DCOP call is a call to some part of KDevelop which exposes methods via interfaces. For example, startAppCommand is a method of KDevAppFrontend interface. There's no documentation about what is exposed, but just run kdcop tool to explore the complete list of interfaces and their methods and check how they work.
When you save your script in ~/.kde/share/apps/kdevelop/scripts and restart KDevelop, you'll be able to run your ruby programs having a C++ project opened like shown in the screenshot below.
PS: this post was inspired when I was reviewing the KDevelop wishlist named "Unable to execute Python scripts in a C/C++ project".
PPS: I do believe we can make scripting more powerful and easier with KDevelop4 and we have two great technologies - QtScript and Kross for that... but this is another story ;)
Those features are not so powerful as in Emacs, but they solve different problem. Emacs has Emacs Lisp to:
- extend the environment
- and automate common tasks.
All modern IDE's I know about use different approach. They have:
- extension system with plugins written usually in the same language IDE was created
- and scripting language or scenarios to automate tasks within the IDE.
You can write plugins in C++ for KDevelop and or course you can write scripts. KDevelop exposes its internals via DCOP therefore the choice of scripting language is virtually unlimited. Either your language has DCOP bindings (like Perl, Java, Python, Ruby, KJS) or it can execute dcop command via shell.
Imagine a C++ project with some parts written in Python or Ruby. You naturally want it to be opened as C++ project to have nice integration but you also want a way to easily run your Ruby and Python programs. When working on Ruby projects, you are able to run currently edited programs. But there's no such option when a C++ project is opened. So why don't we implement that with a script?
KDevelop automatically loads all scripts it can find into the "Scripts" menu. The search path by default is $KDEDIR/share/apps/kdevelop/scripts, $KDEDIR/share/apps/kate/scripts and their user-editable equivalents ~/.kde/share/apps/kdevelop/scripts and~/.kde/share/apps/kate/scripts.
Script has to be an executable file and needs to have a .desktop file with a short description. Our script menu item will be called "Run Ruby Program" and the actual script will be a shell script called runrubyprogram.sh. Below are the sources for runrubyprogram.desktop and runrubyprogram.sh I wrote today:
runrubyprogram.desktop
[Desktop Entry]
Encoding=UTF-8
Name=Run Ruby Program
Type=ShellScript/bash
X-KDE-ScriptName=runrubyprogram.sh
runrubyprogram.sh
#!/bin/bash
#get the name of active file and project
file=`dcop $1 SimpleMainWindow caption`
projectdir=`dcop $1 KDevProject projectDirectory`
#strip "KDevelop" from the window caption to get the real filename
file=`echo $file | sed 's/ - KDevelop//' | sed 's/file:\/\///'`
cwd=`pwd`
if [ ! -z $projectdir ]; then
#strip projectname
file=`echo $file | sed 's/^[^-]*- //'`
cwd=$projectdir
fi
#run current file with ruby in KDevelop
dcop $1 KDevAppFrontend startAppCommand "$cwd" "ruby $file" "false"
As you can see, two DCOP calls are made to get the name of currently opened file and project directory and one DCOP call to execute a command inside KDevelop. Each DCOP call is a call to some part of KDevelop which exposes methods via interfaces. For example, startAppCommand is a method of KDevAppFrontend interface. There's no documentation about what is exposed, but just run kdcop tool to explore the complete list of interfaces and their methods and check how they work.
When you save your script in ~/.kde/share/apps/kdevelop/scripts and restart KDevelop, you'll be able to run your ruby programs having a C++ project opened like shown in the screenshot below.
PS: this post was inspired when I was reviewing the KDevelop wishlist named "Unable to execute Python scripts in a C/C++ project".
PPS: I do believe we can make scripting more powerful and easier with KDevelop4 and we have two great technologies - QtScript and Kross for that... but this is another story ;)
22 February 2007
KDevelop4 evolution: The UI, part 2
I know I promised to blog often about KDevelop4 progress, but I did not intend to write one more post today ;) The reason I'm doing this is that someone came today to #kdevelop IRC channel and asked whether we can open more than one embedded Konsole toolview in KDevelop. Of course my answer was "no sorry" because in KDevelop3 the usual modus operandi is 1 plugin => 1 view.
But this is not the case in KDevelop4 anymore. During architecture rework that was done by yours trully and Andreas Pakulat we introduced so-called "toolview factories". So each KDevelop4 plugin now registers a toolview factory and then the shell application uses the factory to add toolviews when necessary.
Until today, factories were used by mainwindow only once and only one toolview was visible on the screenshots from my previous post. Today I though that nothing prevents me from implementing a nice dialog to add new toolviews. After several minutes of hacking (actual view creation is only 2 lines of code thanks to Sublime library, everything else I committed was the UI for the feature) I got this:
As you can see, there's no restriction anymore to the number of toolviews. You want 10 konsole's - you'll get them! Also Qt4 dockwidget management system allows to group dockwidgets in tabs so some toolviews can be nicely kept together.
Ok, that's all for today. Next time I'll leave UI and tell you about project management in KDevelop4. Stay tuned...
But this is not the case in KDevelop4 anymore. During architecture rework that was done by yours trully and Andreas Pakulat we introduced so-called "toolview factories". So each KDevelop4 plugin now registers a toolview factory and then the shell application uses the factory to add toolviews when necessary.
Until today, factories were used by mainwindow only once and only one toolview was visible on the screenshots from my previous post. Today I though that nothing prevents me from implementing a nice dialog to add new toolviews. After several minutes of hacking (actual view creation is only 2 lines of code thanks to Sublime library, everything else I committed was the UI for the feature) I got this:
As you can see, there's no restriction anymore to the number of toolviews. You want 10 konsole's - you'll get them! Also Qt4 dockwidget management system allows to group dockwidgets in tabs so some toolviews can be nicely kept together.
Ok, that's all for today. Next time I'll leave UI and tell you about project management in KDevelop4. Stay tuned...
20 February 2007
KDevelop4 evolution: The UI
It's been a long time since I last talked about the progress on KDevelop4. This has to change ;) I'll try to keep everyone informed about recent developments in KDevelop4.
Last time our new user interface concept ("Sublime") was covered in commit-digest article. At that time only the sublime user interface library code was available. Today we have two major UI design decisions implemented.
First was the support for areas (the KDevelop's name for perspectives). Area in KDevelop is the set of views (documents) and toolviews (docks). At this moment KDevelop has only "coding" area, debugger and design areas will be used once respective plugins are ported to KDevelop4.
Second major design decision was multi-mainwindow operation. KDevelop3 with its only one mainwindow and non-detacheable toolviews was hardly optimal for dual monitor setups. KDevelop4 allows to have as many mainwindows as necessary.
The interesting thing is how multiple mainwindows and areas work together. Of course, different mainwindows can have different areas. Basically opening one more window with "debug" area will be the default way to do debugging. Same for Qt UI design - you will have new mainwindow with "design" area to work on Qt .ui files.
But that's not all we can do. Eclipse pretends it can show one perspective in two or more mainwindows. KDevelop4 now does that as well, except that it doesn't pretend the area is the same in all those mainwindows. You can duplicate mainwindow with "coding" area but what you get is cloned area called "coding (copy)" shown in the new mainwindow. This means all view/toolview layout and settings belong to the new cloned area so no confusion happens when you close your windows and save areas.
In the screenshot below, you can see one KDevelop program with three mainwindows. The background window shows "coding" area, two topmost windows show the clones of "coding" area with different view/toolview layout. So nothing will prevent from using KDevelop in dual-monitor setups anymore. "New Window" action from the window menu will duplicate the mainwindow and clone its area as necessary. The cloning operation is relatively cheap, resources are used just to create a new mainwindow and views inside it. No KDevelop plugin is loaded for the second time.
Toolviews that use plain Qt4 dockwidgets with no hacks are handy as well. Unlike KDevelop3, you can dock/undock and close them completely.
Splitting is of course in place too, but with slightly different logic than in KDevelop3. Now it behaves more like Kate when current view under the cursor is splitted rather than the whole region with views.
Don't bother looking at combobox that we currently have as a way to switch between views because it's our temporary replacement for a tabwidget. Everybody knows that tabwidget doesn't scale when lots of files are opened and everybody hates QTabWidget for extra bevel and border. We hated tabwidget too so we had to avoid it ;)
All that is implemented in KDevelop4 shell in <200 lines of code ;) Ok, ok, another 3k loc reside in Sublime library :) Sublime is the fourth UI library KDevelop uses and the third one I wrote. And I do hope it will be the last one. This time I believe I got it right. At least the code is surely better than infamous KMDI library and Sublime certainly is more capable than my previous NewD aka SimpleIdeal and Ideal libraries. Also this time the I wrote an extensive test suite to guarantee that UI is stable and bug-free.
So, enjoy the screenshot and don't just wait for KDevelop4. It is high time to do an IDE right and we know how to do that this time. What we need is you :) Join us to create the IDE of your dream!
Last time our new user interface concept ("Sublime") was covered in commit-digest article. At that time only the sublime user interface library code was available. Today we have two major UI design decisions implemented.
First was the support for areas (the KDevelop's name for perspectives). Area in KDevelop is the set of views (documents) and toolviews (docks). At this moment KDevelop has only "coding" area, debugger and design areas will be used once respective plugins are ported to KDevelop4.
Second major design decision was multi-mainwindow operation. KDevelop3 with its only one mainwindow and non-detacheable toolviews was hardly optimal for dual monitor setups. KDevelop4 allows to have as many mainwindows as necessary.
The interesting thing is how multiple mainwindows and areas work together. Of course, different mainwindows can have different areas. Basically opening one more window with "debug" area will be the default way to do debugging. Same for Qt UI design - you will have new mainwindow with "design" area to work on Qt .ui files.
But that's not all we can do. Eclipse pretends it can show one perspective in two or more mainwindows. KDevelop4 now does that as well, except that it doesn't pretend the area is the same in all those mainwindows. You can duplicate mainwindow with "coding" area but what you get is cloned area called "coding (copy)" shown in the new mainwindow. This means all view/toolview layout and settings belong to the new cloned area so no confusion happens when you close your windows and save areas.
In the screenshot below, you can see one KDevelop program with three mainwindows. The background window shows "coding" area, two topmost windows show the clones of "coding" area with different view/toolview layout. So nothing will prevent from using KDevelop in dual-monitor setups anymore. "New Window" action from the window menu will duplicate the mainwindow and clone its area as necessary. The cloning operation is relatively cheap, resources are used just to create a new mainwindow and views inside it. No KDevelop plugin is loaded for the second time.
Toolviews that use plain Qt4 dockwidgets with no hacks are handy as well. Unlike KDevelop3, you can dock/undock and close them completely.
Splitting is of course in place too, but with slightly different logic than in KDevelop3. Now it behaves more like Kate when current view under the cursor is splitted rather than the whole region with views.
Don't bother looking at combobox that we currently have as a way to switch between views because it's our temporary replacement for a tabwidget. Everybody knows that tabwidget doesn't scale when lots of files are opened and everybody hates QTabWidget for extra bevel and border. We hated tabwidget too so we had to avoid it ;)
All that is implemented in KDevelop4 shell in <200 lines of code ;) Ok, ok, another 3k loc reside in Sublime library :) Sublime is the fourth UI library KDevelop uses and the third one I wrote. And I do hope it will be the last one. This time I believe I got it right. At least the code is surely better than infamous KMDI library and Sublime certainly is more capable than my previous NewD aka SimpleIdeal and Ideal libraries. Also this time the I wrote an extensive test suite to guarantee that UI is stable and bug-free.
So, enjoy the screenshot and don't just wait for KDevelop4. It is high time to do an IDE right and we know how to do that this time. What we need is you :) Join us to create the IDE of your dream!
Subscribe to:
Posts (Atom)