KDE 3.5.1 was released today, featuring fixes to over 150 reported bugs and many other small improvements making this the most stable and feature-rich Unix desktop ever. Konqueror, KMail, KPDF, Juk, Kopete, Kalzium and Quanta in particular saw a large number of improvements in stability and performance. Users are encouraged to upgrade when their distributor releases packages. There are updated packages available for Arch Linux, Gentoo, Kubuntu, Red Hat and Slackware or you can compile it yourself with Konstruct. See the 3.5.1 Release Announcement for full details and the Changelog for a full list of updates.
Dot Categories:
Comments
great! thank you all!
Thanks to the developers for making KDE even more stable. These updates are very useful while we're waiting for KDE 4. Does anyone know what happened to the Commit Digest or the "This month in SVN" series? Will they be continued?
"This month in SVN", not sure, I assume that it would resume when there's more to report than "Making this work better with Qt 4". ;)
There's a lot of rearchitecting and porting and breakage occuring all at once. Not much interesting for users quite yet in SVN.
As far as the Commit Digest, from my understanding the author has been very swamped for time and no one has stepped up to take his place. I think if anyone here with enough time for poring over even a few mailing lists would meet with the gratitude of thousands of people if they could step up and help Derek out.
Regards,
- Michael Pyne
hi ive seen theres no Roadmap for 4.0 - it was discussed @ core-devel that there will be some sort of techology preview , when the basic porting ist done.
Can one can please come up with a possible release plan ? someone has the courage ?
There's not a single roadmap but some roadmaps on several pages.
Take a look at:
- http://appeal.kde.org
- http://plasma.kde.org
- http://solid.kde.org
That might be interesting to you.
ok i see ,
for solid : http://solid.kde.org/cms/1002
and so on. perhaps you cant add dates now, but it would be nice to *have* dates.
eheheh , i just had the IDEA : we use Kplato (released with koffice 1.5) Project Management Application , and use the function "EXPORT to RoadMAP" :-)
The Technical Working Group is still being formed. Once it starts working coming up with a roadmap will very likely be one of its first tasks. Ask again in about a month.
http://slashdot.org/article.pl?sid=06/01/31/1519224
Why Google not use KDE and Kubuntu?
it's just another google-non-story. you know, like how they were going to release a web-based office suite? google is the Hot Commodity right now so every other story is "google is doing ! OMFG!"
wait all you want, i don't expect to see GoogleOS anytime soon.
They have denied it already. They do have a Ubuntu based distro they use internally, but they'll not be releasing it.
Read more here: http://slashdot.org/comments.pl?cid=14609148&sid=175746&tid=217
There's also an article on arstechnica.com
your not alowed to sware u said OMFG which means o my fucking god
god is a good man hehe
The KDE Internationalization and Translator Team must be the biggest and most reliable one of any of the Free and Open Software Projects!
Man... 63 languages!! That is certainly more than Microsoft and Apple and Sun can muster (maybe not even if they pool together all their languages).
Congratulations to that gigantic achievement. At least on _that_ field, KDE and the Unix desktop is ahead of all proprietary competition on its long road to world domination.
The only thing I wonder: didn't the newly installed KDE marketing group members know that X.Y.1 releases traditionally do feature translations, translations, translations?? It is hard to believe that they do so much underestimate the efforts of the many, many industrious translators making KDE the success it is around the world.
I agree, we should stress that much more. It's a great effort that is being made, and it cannot be underestimated.
Kudos to the translation teams making KDE happen in your language!
> The KDE Internationalization and Translator Team must be the biggest and
> most reliable one of any of the Free and Open Software Projects!
OK, I am not sure whether Debian is not complete in this respect, but
$ aptitude search openoffice.org-l10n | wc -l
gives me here 53, whereas
$ aptitude search kde-i18n | wc -l
gives 66.
So, maybe you are actually right. :-)
Matej
what about gnome?
I don't know what are the packages in Debian, but
http://www.gnome.org/i18n/ has also 52 supported and partially supported languages (supported is more than 80 % translated -- 39 languages, partially supported more than 50 % -- 13 languages). it seems that they are doing better than us.
I have downloaded whole similar data for KDE (of course, they are better presented :-); ) into OpenOffice (yeah, I know, but KSpread doesn't support this yet) and made a table . The table says that there are 25 languages supported above 80 %, and 12 languages above 50 %. It seems that in both aspects we are doing worse than Gnome.
Sorry,
Matej
GNOME is a lot smaller than KDE.
Hi all
I am still seeing kicker crashes on logout (3.5.1 for Kubuntu Dapper) ... am I the only one ?
This is the bug:
http://bugs.kde.org/show_bug.cgi?id=113242
Cheers!
there are several completely different crashes there. if you are suffering from the xim related crash, there is nothing i can do about it. get rid of libqxim from your system or move to a version of it that doesn't crash.
if it's a different crash, i'd love to hear about it.
Thanks a lot Aaron
I'll check and report in bugzilla if I find anything interesting
BTW, does Qt provide smart pointers ? It would be great to have
a solid smart pointer implementation in the kdelibs, right ? I do
lots of c++ programming for work, and if you ask me what's the
single most important missing feature in the STL, I would say
polymorphic smart pointers. Maybe a wrap around the boost reference
counting smart pointers would do. Maybe boost's work should become
part of the STL. But in any case, it would be greate to be able
to forget about deleteing NEW allocated memory, we'd gain a lot in terms
of robutness !
Cheers!
In kdelibs there is KSharedPtr:
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/ksharedptr.h?rev=501697&...
That's exactly it ! Thanks a lot for the pointer ;-)
Is it being used extensible ? It would make sense to _only_ use KSharedPtr's as a policy. The only drawback is you need to inherit from QSharedData in most of your classes, but the advantages are gigantic !
i'm using KSharedPtr quite a lot in kicker, though that's not the issue with the crashes people were seeing in 3.5.0 at all.
Oh, I see, I took a quick look at the patch you posted for the bug, and I got the impression that using a smart ptrs would have avoided the crash, but it was just a quick impression and obviously wrong. Cheers , and thanks for the great work !
:-)
Just for the record, yeah, I am having the XIM crash :-(
Thank you Aaron !
yahoo mail buttons works ok now again :)
Will Bluetooth be integrated ??? not in kdelibs but somewhere in the default release ????
^^^^^^^^^^ this is mostly std. and kde has superb bluetooth support (kde-bluetooth)...
chelcicky:~$ apt-cache search bluetooth kde
kdebluetooth - KDE Bluetooth Framework
kdebluetooth-irmcsync - IrMCSync Konnector for kitchensync
qobex - Swiss army knife for the OBject EXchange (obex) protocol
chelcicky:~$
What about this?
Matej
i know - i use both , but i think they are so handy they should be in the default install - or released as offical kde package
Well, the developers of KBluettooth have probably wanted to have different release cycle than the main KDE, and I think in KDE 4 many other apps are going to be extracted from the base release.
But something like : "Bluetooth Device found" (this solid stuff -(SOLID)), Would you like (mind) to install kde-bluetooth ? : kexecute call_distro_install kde-bluetooth.
(something like that is base functionality)
KDE Bluetooth Framework (http://kde-bluetooth.sourceforge.net/) still in beta-1 for nearly an year!
Nope, I am not starting a flamebait... but comparing the DPI used by KDE, GNOME, Openoffice, xfce.
Gnome uses 96dpi screen resolution, Openoffice.org uses 96dpi screen resolution, MS Windows uses 96dpi screen resolutions, but KDE uses 75x75 screen resolution or non-standard ones 84x84 etc.,
The fonts look 20% (twenty percent) smaller in KDE applications and Openoffice documents and kword documents look different (koffice documents being smaller font size due to small screen resolution)
Could we consider KDE's default Screen resolution to 96x96dpi for better visual compatibility with Gnome, XFCE, Openoffice and other websites which expects 96dpi as screen resolution (due to M$).
If we start KDE applications in XFCE then you can see *fonts* of KDE apps look *too big* (due to XFCE using 96dpi and KDE using 75dpi).
I wonder is there a freedesktop.org standard for screen resolution, which could make fonts look similar in all Desktop Environments?
DPI is a function of the X server. In fact, for a proper DPI setting, let X figure it out by asking your monitor. Mine's set at 90x84 which is correct, because X knows the size of my monitor and the resolution I'm running at.
Either way, though, you can run KDE at 96x96 if you want. There's nothing stopping you.
open an opendocument with kword and that same document with openoffice 2.0.x, you can see that document looks different... setting dpi to 96 makes kword and openoffice.org's document look same.
A document created should look same either or kde or gnome or ms windows. I am suggesting 96dpi as default for KDE (which can be configured from kcontrol to increase/decrease the dpi for BIG screens and Small Screen respectively.)
Actually, this is something that is very broken in Gnome -- which blithely disregards the dpi settings of X11 (which you can set yourself, in /etc/kde3/kdm/kdmrc (if you're using kdm and Kubuntu, at least):
ServerArgsLocal=-dpi 96 -nolisten tcp
Or which X11 can figure out from the size and resolution of your monitor. My laptop panel is 1680x1050 15", but there are also 21" monitors with that resolution. It stands to reason that pixels are differently sized on those examples, so if you want accurate font sizes (wysisyg, remember), your desktop environment needs to take that into account.
I've filed a bug about something that seems quite similar. Could you guys check this out and see if it also fails for you? If it doesn't, it's obviously something to do with my setup so I'll close the bug..
https://bugs.kde.org/show_bug.cgi?id=120061
You've got a minimum font size of 10 set in your konqueror settings. If you set that to two, everything is nicely scaled. And yes, this is a very welcome feature of konqueror.
How do you know what my minimum font size is set to? (It's NOT 10 btw!)
He (and you it seems) assumed the page you linked to was showing fonts' point size. It isn't, it is showing the pixel size. If you switch to point size (choose 'pt' next to 'font size') all the fonts size 8 and lower will be the same for you, exactly as one would expect from your konqueror settings.
Ok, can you explain to me why when my minimum font size is set to 8, and in KDE control centre my font selection is Tahoma 7, that that page displays font size 8 (8pt, not 8px) smaller than my Tahoma 7 fonts in my menus...?
I'm not being sarcastic here, I genuinely believe that something is wrong somewhere with how kde scales/displays fonts, but if it's my ignorance then I'd like it explained to me where I'm going wrong.....
Is it really broken in Gnome ?
IIRC in my case, in Gnome preferences, you can choose to keep what the X server says or choose your own.
As a matter of fact, I don't have the problem discussed here in Gnome nor in KDE at home (and I'm at 96 dpi at 1600x1200 on a CRT 22").
But perhaps that's because it was configured a long time ago in KDE, I don't know.
I disagree with this entirely. Windows is going to be changing this behavior with Vista to be the true DPI of the monitor instead of the hack they have now. I have no idea why gnome is using that stupid hack but I want the dpi to be set correctly. A 16pt font should be the same size on any size display regardless of resolution. Increased resolution gives greater accuracy in rendering it does not change the size of any element. KDE behaves correctly by default for this. I can run kde on a high dpi monitor and have no problems at all. However with windows you need special driver hacks to make it work. I expect you will need the same hacks on gnome to make it do the right thing.
Displays are getting higher rez and higher dpi all the time and so going back to a hack about the way people are used to is just a horrible idea. KDE needs to stay the way it is now and the problem will sort itself out over time. Actually if other systems did things correctly there would not be a good reason to run in anything other then the max resolution that the device you where using supports since that would give a better quality image.
> Displays are getting higher rez and higher dpi all the time and so going back to a hack about the way people are used to is just a horrible idea.
You are exactly right, but is there any free-standard for DPI (dots per inches) for free-desktops like KDE, GNome, XFCE?:
I can't find any at: http://freedesktop.org/wiki/Standards
perhaps freedesktop did not notice dpi issues with "font sizes" with different desktops.
There are millions of Monitors which will take another 5 years to change, till then KDE applications' documents and text look different from other desktops! and this is also a horrible idea!
Making 96dpi by default (with KDE) make font sizes in harmony with other desktops and applications (openoffice), consistency could be achieved.
Letting users decide to have (96 or Autodetected resolution) settings in kcontol will solve the issue for good.
> You are exactly right, but is there any free-standard for DPI (dots per inches) for free-desktops like KDE, GNome, XFCE?:
It seems you are totally confused. DPI isn't something you agree on. It's determined by dividing width (or height) of the display area in pixels, by width (or height) of the display area in inches.
So a 14.1 inches wide by 11.3 inches high monitor with a resultion of 1280x1024
has a dpi of 91x91.
> Making 96dpi by default (with KDE) make font sizes in harmony with other desktops and applications
No, it will make the font size wrong on many monitors.
> Letting users decide to have (96 or Autodetected resolution) settings in kcontol will solve the issue for good
Others should already how do achieve this.
On my system, KDE uses 96 DPI. Why? Because that's what my monitor is! If you're not getting the right DPI, it's because your X server is misconfigured. This isn't KDE's fault.
There is no standard DPI. It depends on your monitor.
DPI is an X Window System property and has nothing to do with KDE!
To setup the DPI to be precisely 96x96 dpi each time, you need to add a line into you xorg.conf
Locate Section "Monitor" and add the following lines before EndSection:
# DisplaySize 270 203 # 1024x768 96dpi
# DisplaySize 338 254 # 1280x960 96dpi
# DisplaySize 338 270 # 1280x1024 96dpi
# DisplaySize 370 277 # 1400x1050 96dpi
# DisplaySize 423 370 # 1600x1400 96dpi
Uncomment the resolution you normally use...
To get MS fonts working properly...try looking at the following guide:
http://www.ubuntuforums.org/showthread.php?t=20976&highlight=cleartype
It's Ubuntu(Debian) specific but the instructions for the DPI stuff can be carried out on any linux box.
By the way, if you're going to use the Virtual or Viewport keywords then the above DisplaySize will not take effect. Also, for Nvidia graphics card, there is an Option called "UseEdidDpi" which needs to be set to "FALSE" for your DisplaySize option to to take effect.
For more info see:
http://download.nvidia.com/XFree86/Linux-x86/1.0-8174/README/32bit_html/...
Hey man,
Long time!
Email me!
...from SuSE I never really figured out how is the best way to simply update only KDE. They say on Kubuntus download page to add the sources to
sources.list. But how do I go from there? If I click on Upgrade all in
Adept, everything is updated, not only KDE. And I dont want to select
each and every package and select update.