The "town" I'm talking about is free graphics applications. Given the context of this story, on Linux, too.
Sure, Krita will work on Windows one day, and on OS X, too. It doesn't right now. But that's not relevant when when discussing free equivalents to proprietary applications to run on Linux, is it?
Besides, the Gimp isn't the only player in town... In eleven days (Feb. 27), we'll release the rc1 of KOffice 1.5, with Krita 1.5 in it. And Krita has already cmyk, 16 bit support, lab, raw import and lots of other fun features.
Nonsense. And I say this as a KOffice developer. KOffice slowed down because the students who started it graduated and got jobs; because the KOffice hackers started to work on KDE's core libraries; because (in case) a core KOffice developer wanted to code in Java, not C++, and because much of the urgency disappeared when OO got open-sourced.
Especially the latter.
Fortunately, nowdays, KOffice development is fast & healthy again. We're going to release 1.5 in early March and that release will show major progress in all applications. We're working hard on OpenDocument and OpenFormula support, cross-language scripting, application integration, user interface polishing... And we're having fun, something I doubt many StarOffice of OpenOffice developers have.
No, KOffice hasn't got the perfect filters for MS Office files -- and those are hard enough to make that even Microsoft uses RTF when exchanging documents between versions of Word. But -- and here another poster is completely right -- KOffice has a future. It's a small codebase, small enough for people to join development and be productive in a matter of days, not months.
KOffice has future; OpenOffice is a dead end. Unfortunately, the opening of StarOffice had the effect of draining interest from KOffice (and Gnome Office) for some time. Fortunately, KOffice development has picked up a lot recently and our 1.5 release will be a lot of fun.
Boudewijn Rempt
Whether language bindings are harder or not, is not important to you, as a language bindings user. (It's not true that bindings are harder for C++, but let that rest). So, if you want, you can code your application in Python, Ruby, Perl or Java -- and the Java can be compiled to native code or run on a jvm. I only mention these bindings because they are complete: there exist other bindings, but those are not complete -- just like most of the bindings to GTK are not complete.
Actually, the bindings maintainers for Qt and KDE are a bit surprised at the amount of manual work the GTK bindings people seem to have to do.
It's not "they" who would do this -- it's me... Anyway, the all elements in one panel was the situation when I took up maintainership, and it proved to be limiting. Not extensible, and not configurable by the user. Besides, it took up just a much space as the current configuration: about 200 pixels width and the whole window's height.
The next version of Krita will allow users to drag the tabs inside the dockers to other dockers, meaning that if you want to have everything in one window, you can do that.
Boudewijn Rempt
Well -- I do in fact agree with the above poster. I have tried various ways of making the widgets in the dockers smaller -- removing space between widgets, some bloody-minded code to ensure small, but readable fonts. But in the end, it's a problem with toolkit. Using a new Qt theme wouldn't help all the way, because the dialogs should still use the standard widget set.
So I just decided not to bother and use my precious time to create features and fix bugs.
I've tried it -- used OS X for half a year for lots of tasks, from Java development to writing a novel, and the only thing I really like to use it for over and above is grabbing pictures from my digital camera. And that may be a function of the hardware, the USB port on the powerbook being more accessible than the same on my server.
A well-configured KDE desktop is more productive and prettier than the unconfigurable mess of widget styles and fuzzy fonts Aqua is.
I've been using a powerbook for about half a year now, in addition to my Linux desktop at home and at work. I've been using Linux since 1993 (or 1994 -- it's been a long time, and I'm not terribly sure anymore).
At first, I really liked OS X. Cute, smooth, and great applications like iTunes and iPhoto. And a really good, smooth port of Emacs. Still like iPhoto a lot. But then the ui started to grate. The ugly, fuzzy fonts, the silly repeated pixmaps in the scrollbars. The lack of customizability. The spreading brushed metal look -- I mean, we've done the brushed metal thing with Enlightenment in 199-something already...
And running Debian on the powerbook just isn't as comfortable as it is on a X86. The jittery trackpad. The mouse button emulation. The lack of a delete key. (But suspend with pmud is heaven.) Anyway, I've done a write-up in a bit more detail at: http://www.valdyas.org/fading/index.cgi/software/l inuxosx.html?seemore=y.
Re:What does it do that's so special?
on
KDE 3.2.0 Released
·
· Score: 1
A minicli with autocompletion is what makes KDE more useful to me than WindowMaker, which _has_ a minicli but without autocompletion. Oh, and a whopping great framework that makes writing new apps a lot easier, and a filebrowser that can browse nearly anything and a host of other applications that work well together.
In 1996 Linux Journal published its first article on developing with Qt: http://www.linuxjournal.com/article.php?sid=0201. By that time, Qt had already been in development for four years, and Troll Tech was 2 1/2 years old.
That's why I found Accelerated C++ by Koenig and Moo such a good book. It teaches C++ as a coherent language, instead of C with knobs on. On the other hand, it also tries to teach programming an sich, and does that with examples for which Python is better suited.
The first edition of Practical C++ by Oualline is a prime example of a book that teaches C++ as a superset of C -- I don't know if the second edtion is as bad.
C++ in a Nutshell is perhaps a little too concerned with the pure syntax of C++, and not enough with the meaning of those syntactical constructs.
I'd be quite interested in using the GDK event loop for Krita because I could then with no hassle lift the bit of code that enables the Gimp to draw nice lines from the Gimp and import it in Krita. Now I will have to invent something similar myself:-).
> This gives you more choices than QT when programming.
No, it doesn't, because there are bindings for C, Python, Ruby, Java, Perl, Objective C. Choices enough, and that's without mentioning that coding to Qt in C++ is about as easy as using Java, if not easier. It all boils down to: you need less lines of code if you code in C++/Qt than if you use GTK/whatever -- and fewer lines of code means fewer bugs.
Children, mainly. Many parents in the Netherlands at least have a vague idea that while chatting in general is very dangerous for their children, MSN is safe. So my daughters friends are allowed to use MSN but not ICQ or AIM. I know it's silly, but they actually reason MSN == Microsoft == safe.
Slashdot Mirror
The "town" I'm talking about is free graphics applications. Given the context of this story, on Linux, too. Sure, Krita will work on Windows one day, and on OS X, too. It doesn't right now. But that's not relevant when when discussing free equivalents to proprietary applications to run on Linux, is it?
Besides, the Gimp isn't the only player in town... In eleven days (Feb. 27), we'll release the rc1 of KOffice 1.5, with Krita 1.5 in it. And Krita has already cmyk, 16 bit support, lab, raw import and lots of other fun features.
Nonsense. And I say this as a KOffice developer. KOffice slowed down because the students who started it graduated and got jobs; because the KOffice hackers started to work on KDE's core libraries; because (in case) a core KOffice developer wanted to code in Java, not C++, and because much of the urgency disappeared when OO got open-sourced. Especially the latter. Fortunately, nowdays, KOffice development is fast & healthy again. We're going to release 1.5 in early March and that release will show major progress in all applications. We're working hard on OpenDocument and OpenFormula support, cross-language scripting, application integration, user interface polishing... And we're having fun, something I doubt many StarOffice of OpenOffice developers have.
Large usage? Look at the facts of sloccount:
Totals grouped by language (dominant language first):
cpp: 4630794 (88.89)
java: 361396 (6.94)
ansic: 130206 (2.50)
About 7 percent is not "large usage"
No, KOffice hasn't got the perfect filters for MS Office files -- and those are hard enough to make that even Microsoft uses RTF when exchanging documents between versions of Word. But -- and here another poster is completely right -- KOffice has a future. It's a small codebase, small enough for people to join development and be productive in a matter of days, not months. KOffice has future; OpenOffice is a dead end. Unfortunately, the opening of StarOffice had the effect of draining interest from KOffice (and Gnome Office) for some time. Fortunately, KOffice development has picked up a lot recently and our 1.5 release will be a lot of fun. Boudewijn Rempt
Whether language bindings are harder or not, is not important to you, as a language bindings user. (It's not true that bindings are harder for C++, but let that rest). So, if you want, you can code your application in Python, Ruby, Perl or Java -- and the Java can be compiled to native code or run on a jvm. I only mention these bindings because they are complete: there exist other bindings, but those are not complete -- just like most of the bindings to GTK are not complete.
Actually, the bindings maintainers for Qt and KDE are a bit surprised at the amount of manual work the GTK bindings people seem to have to do.
You missed karbon, part of koffice: http://koffice.kde.org/karbon.
If you go to Trolltech and tell them you need 100 developer licenses, they'll cut you a very, very attractive deal.
Yes, that's right, that's what I'm working on. You did notice that you can alread collapse docked panels, did you?
It's not "they" who would do this -- it's me... Anyway, the all elements in one panel was the situation when I took up maintainership, and it proved to be limiting. Not extensible, and not configurable by the user. Besides, it took up just a much space as the current configuration: about 200 pixels width and the whole window's height. The next version of Krita will allow users to drag the tabs inside the dockers to other dockers, meaning that if you want to have everything in one window, you can do that. Boudewijn Rempt
Well -- I do in fact agree with the above poster. I have tried various ways of making the widgets in the dockers smaller -- removing space between widgets, some bloody-minded code to ensure small, but readable fonts. But in the end, it's a problem with toolkit. Using a new Qt theme wouldn't help all the way, because the dialogs should still use the standard widget set.
So I just decided not to bother and use my precious time to create features and fix bugs.
Boudewijn
Why? Why cannot a paint application be named for an ornamental flat braid or round cord used as a trimming? I think it fits perfectly.
i on ary&va=gimp
http://www.m-w.com/cgi-bin/dictionary?book=Dict
I've tried it -- used OS X for half a year for lots of tasks, from Java development to writing a novel, and the only thing I really like to use it for over and above is grabbing pictures from my digital camera. And that may be a function of the hardware, the USB port on the powerbook being more accessible than the same on my server.
A well-configured KDE desktop is more productive and prettier than the unconfigurable mess of widget styles and fuzzy fonts Aqua is.
I've been using a powerbook for about half a year now, in addition to my Linux desktop at home and at work. I've been using Linux since 1993 (or 1994 -- it's been a long time, and I'm not terribly sure anymore).
l inuxosx.html?seemore=y.
At first, I really liked OS X. Cute, smooth, and great applications like iTunes and iPhoto. And a really good, smooth port of Emacs. Still like iPhoto a lot. But then the ui started to grate. The ugly, fuzzy fonts, the silly repeated pixmaps in the scrollbars. The lack of customizability. The spreading brushed metal look -- I mean, we've done the brushed metal thing with Enlightenment in 199-something already...
And running Debian on the powerbook just isn't as comfortable as it is on a X86. The jittery trackpad. The mouse button emulation. The lack of a delete key. (But suspend with pmud is heaven.) Anyway, I've done a write-up in a bit more detail at: http://www.valdyas.org/fading/index.cgi/software/
A minicli with autocompletion is what makes KDE more useful to me than WindowMaker, which _has_ a minicli but without autocompletion. Oh, and a whopping great framework that makes writing new apps a lot easier, and a filebrowser that can browse nearly anything and a host of other applications that work well together.
In 1996 Linux Journal published its first article on developing with Qt: http://www.linuxjournal.com/article.php?sid=0201. By that time, Qt had already been in development for four years, and Troll Tech was 2 1/2 years old.
That's why I found Accelerated C++ by Koenig and Moo such a good book. It teaches C++ as a coherent language, instead of C with knobs on. On the other hand, it also tries to teach programming an sich, and does that with examples for which Python is better suited. The first edition of Practical C++ by Oualline is a prime example of a book that teaches C++ as a superset of C -- I don't know if the second edtion is as bad. C++ in a Nutshell is perhaps a little too concerned with the pure syntax of C++, and not enough with the meaning of those syntactical constructs.
I'd be quite interested in using the GDK event loop for Krita because I could then with no hassle lift the bit of code that enables the Gimp to draw nice lines from the Gimp and import it in Krita. Now I will have to invent something similar myself :-).
> This gives you more choices than QT when programming.
No, it doesn't, because there are bindings for C, Python, Ruby, Java, Perl, Objective C. Choices enough, and that's without mentioning that coding to Qt in C++ is about as easy as using Java, if not easier. It all boils down to: you need less lines of code if you code in C++/Qt than if you use GTK/whatever -- and fewer lines of code means fewer bugs.
Well, if she installs the kdesdk package she should expect that some development tools worm their way into her system. No kdesdk, no cervisia...
Not only that, but most of the goodness in OS X is much older. Say, 1986, the beginning of Next...
I you cannot affort to invest a measly $1500 in your business, you're sunk anyway. You don't have a business, you have a hobby.
Children, mainly. Many parents in the Netherlands at least have a vague idea that while chatting in general is very dangerous for their children, MSN is safe. So my daughters friends are allowed to use MSN but not ICQ or AIM. I know it's silly, but they actually reason MSN == Microsoft == safe.