More KDE development news in the August edition of This Month in SVN. This issue packs in twice as much content as the previous one, with new features covered in Konqueror, Kicker, KDesktop, amaroK, Konversation and more: "This month has seen some drastic changes in SVN, with KDE4 development moved to trunk and KDE 3.5 gearing up for a stable release sometime after this year's KDE conference."
Dot Categories:
Comments
Back in June there was a story about a firefox plugin http://dot.kde.org/1119705193/ that would allow firefox to embed kparts. I looked through websvn last night but could not find it.... Anyone know where I might find it...
Thanks
Ruairi
playground/utils/dragonegg
Why
KViewShell
KPdf
Kghostview
?
Why not one single tool?
One problem is that you have to get rid of too much similar tools.
Kedit
Kate
kwrite
was a longterm example. This is bad usability.
Most applications use katepart internally (kate, kdevelop, quanta and so on). So the code is shared. In KDE 4 there will only be one editor around.
The other apps share or will share code in the near future. There is even a SOC-project for this.
Hmmm, but both KViewShell and oKular (the Google SoC project) seem to be thriving. Are you sure there will only be one unified document viewer? I think it would be a good thing but I'm not convinced it will happen...
IIRC, Kedit is only kept because katepart has some problems with BiDi support. Kedit will be removed once katepart handles BiDi to the same degree. Kwrite and Kate are pretty much the same, both use katepart, Kate only adds some advanced tools and functions for coders and the like, while Kwrite uses a basic interface that should be less distracting for the user. I think this is, in fact, good usability, and even I use both flavors (Kwrite for single files, Kate for C++ stuff). A single application with a first-start dialog to set the default behavior (Kate or Kwrite) might be OK, if there was also a command line switch to set the behavior (to use Kwrite as the default, and add a menu item to start it in Kate mode).
The problem is: bidi is only needed for bidi languages. so i understand when hebrew kde users get it installed. but I do not need it.
the story that kedit will get removed is old. too old.
If you don't need bidi and KEdit, why do you install it then? Nearly all modern distributions install it as a separate package, so you don't have to have it installed if you don't want to. And if you install from source it's even less excuses, why waste CPU cycles on compiling it if you don't want it installed.
And the story never gets too old as it is simple truth. When katepart supports bidi, KEdit will be removed. Since it does not do that presently KEdit stays.
The problem is that nobody is working on getting BiDi-support, so KEdit will stay forever ...
BiDi implementation is only delayed for KDE 4 because it's much easier to implement with Qt 4.
The experience with KWord has shown that using Qt3's Bidi code for making something else is very difficult, i.e. you have to re-implemt everything. (KOffice has chosen the way to duplicate Qt's code.)
Qt4 was modified from this experience, to allow such uses.
Have a nice day!
Great, thank you!
Have a nice day too :-)
If you don't need it, don't install it. Very simple! No-one forces you to install every extragear and toy and utils package ;)
KEdit is the only Bidi-aware editor of KDE and will be kept as long as Kate is not Bidi-aware.
As for KWrite, it is not more than a simple skin for Kate.
Have a nice day!
kghostview will probably go away as soon as something else can handle postscript files. And then there's okular which aims to unify kviewshell and kpdf:
http://developer.kde.org/summerofcode/okular.html
And, as other people have said, kedit is around for bidi text, so it will be gone when the kate part can do that. Kate and kwrite are mostly the same code, although the kate interface is half way between a text editor and an IDE, so how anyone could think it's exactly the same as kwrite is beyond me.
In other words, pretty much everything you mentioned is being worked on. I'm sure the KDE developers would appreciate it if you wanted to chip in to make it happen faster.
It was said kedit will go away years ago. Can we expect kedit to get dropped at KDE 4? At least I do not need biDi
If Kate(katepart) supports bidi KEdit will go away in KDE 4, if not it will stay. But if you don't need bidi you are actually not forced to install KEdit, so I can't say why it should bother you anyway.
Bertram: "At least I do not need biDi"
That's not an argument for dropping KEdit. But yes, I expect KEdit to be dropped at KDE 4.
I could be mistaken, but I believe that kedit is the editor widget used in kmail's composer. If so this is probably another reason it's survived the whole 3 series.
Don't mix KEdit, the application, with KEdit, the class.
> And then there's okular which aims to unify kviewshell and kpdf:
> http://developer.kde.org/summerofcode/okular.html
Ah, I guess I got that wrong some posts further up then...
Finally, we have our own translation of "This month in SVN" series, you can found every month in KDE-Hispano.
This month translation is now avaliable http://www.kdehispano.org/svn-agosto-2005
It's really great to hear that another team has picked up the translation of these excellent articles. Keep up the good work!.