Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
KDE GUI Operating Systems Software Unix Linux

KDE 3.3.2 Released 41

Posted by timothy from the maintain-low-tones dept.
MROD writes "The KDE Project has announced the release of KDE 3.3.2 with what looks like lots of fixes for the HTML engine and kmail. So, it looks like the Sun SPARC machines at work will be chewing on the source for the next week or so to get a running version."
This discussion has been archived. No new comments can be posted.

KDE 3.3.2 Released More

KDE 3.3.2 Released

Comments Filter:

  • Damnit (Score:1, Redundant)

    by FLAGGR ( 800770 )
    I just upgraded for craps sakes.
    /me Heads to the changelog to see if anything makes it worth upgrading

    • Re:Damnit (Score:3, Funny)

      by dn15 ( 735502 )
      I just upgraded for craps sakes.
      That's nothing, I just finished compiling the previous release on Gentoo. :P
  • Did they fix that bug? You know, the one when you loaded KDE your computer got real slow?

    All kidding aside I am really looking foward to KDE 4. Dropping artsd, the new QT widgets (which I know are not qt but deal) which will have much more .Net / J2EE style connectivity and functionality (I think they were branded data aware). Just want to know how much longer until I can get a fully working win32 binary release so I can drop explorer.exe but keep my win32 apps (such as virtual dub).
      1. Just want to know how much longer until I can get a fully working win32 binary release so I can drop explorer.exe but keep my win32 apps (such as virtual dub).

      I don't know what Windows has to do with KDE, though Virtual Dub works fine under Wine. [winehq.org] Also, if you need .Net (CLR) support, the folks working on the Gnome project are integrating Mono.

      • Some people prefer KDE to the standard "explorer" shell*, but would rather run in Windows to get the increased compatibility with programs (most likely games). Maybe there are only two people that want this, though...(me and the GP).

        *Yes yes, shell != window manager, etc etc. You know what I mean. :)
        • *Yes yes, shell != window manager, etc etc. You know what I mean. :)

          Don't count on it. Many "geeks" don't know the difference between firmware and drivers. Just have a look on the Slashdot stories on OpenBSD activism to get wireless chipset makers to have a free disitribution of binary firmware.

  • Do I sense a troll in the parent post? I mean... come on! Even on a low level machine (1 Ghz) the compilation of Qt+KDE will be done at the most in 24 hours
    • Do I sense a troll in the parent post? I mean... come on! Even on a low level machine (1 Ghz) the compilation of Qt+KDE will be done at the most in 24 hours

      Well, SPARC's aren't very fast CPU wise. If it's an older SPARC with a slow SCSI disk, it could take over 24 hours to compile. Let me tell you about compiling NetBSD on a DecStation 3100, that's a long wait. x86 has really pushed past the RISC workstations in raw speed, there's a reason why even Sun is trying out Opteron workstations.
      • I agree we have ultra 5's and 10's running gnome on solaris 9. No need to upgrade but I believe the fastest we have is around 500mhz. It works so why do we need more speed. We do however have a nice server to run all our compiles on. But even the simplest program compiled locally can take a few seconds. What really is the need for all the speed anyway. Alot of multimedia usually. Of which the sparc do not really have a good array of applications to help with that.

    • VAX 782 trivia (Score:4, Interesting)

      by bm17 ( 834529 ) * <brm@yoyodyne.com> on Wednesday December 08, 2004 @12:17PM (#11033396)
      I have heard that the Vax 782 was designed so that the VMS engineers could still build the entire OS in under a day. The 782 was basically a dual processor VAX-11/780. I don't know how true it is, but it was a good story.
    • Takes me 4 hours to compile the whole thing. Dual Athlon 2400
    • I guess the poster was referring to the conversion of kde to run on Solaris.
      If the source code has to be scanned and modified in order to be compiled for Solaris on sparc that could take weeks!
  • Remember the recent Slashdot article wherein a security researcher demonstrated that Konqueror, Mozilla and Opera were bug-ridden security time-bombs waiting to happen? The Mozilla team took it to heart and quickly fixed the bugs he found, and started using his tool to check for bugs.

    Anyone know if the Konqueror team did the same? I've Switched to Firefox because of this issue, but I really prefer Konqueror, and if I knew that they were being proactive with security I would switch back.

    • it's been fixed in safari so it is likely it's been fixed in konq as well
    • ASFAI can remember he only demonstrated it with Mozilla, Opera and IE. Konqueror did fine when later submitted to the same tests.

      Firefox is Mozilla in a different shell. You haven't escaped any problems
      • Konqueror and Opera were affected by different vulnerabilities than Mozilla, but he demonstrated several in each browser. IE was the only browser not affected, indicating that it was the only browser getting basic testing for security.

        The Mozilla team quickly corrected the issues he found with Mozilla, and started using his tool to perform basic security testing. Those bug fixes are in place for the Firefox 1.0 release, which is what I'm using on Linux.

    • I don't know but Konq is definatly the most bugging browser I've used.
      What they need to do is fully encapsulate the components in seperate threads so that when KHTML crashes it doesn't take out all my Konq windows.

      Threading apart from the obvious benifits to be gained from hypetthreading and multi-core processors that are going to hit the desktop in the next couple of years, would also enable pooling which would mand you could have 50 konq windows open, but only a couple of khtml parts doing the work, givi
  • I ran into quite a strange bug on a website where an image map worked fine in ie windows and mozilla, but wasn't working in safari on mac and konqueror in linux. Which makes sense since they both use the same html rendering engine. Apparently IE for mac has exactly the same issue (I tested it to make sure). Is it possible that Microsoft used a bit of linux in their browser for mac?
  • I wish that the KDE team supplied different programs for file browsing and internet browsing. Modularity/specialization is the answer to produce good software and it is a shame that this lesson is being forgotten. The KDE team is taking konqueror (among others) in the opposite direction, which is a shame, really.

    • Re:Konqueror: the file and internet browser (Score:4, Informative)

      by m50d ( 797211 ) on Thursday December 09, 2004 @06:49AM (#11040805) Homepage Journal
      I disagree with you there. The KDE team are very much into modularity; what they are doing is making their applications modular. Konqueror is mostly a shell for khtml and their file rendering code. Everything's in kparts. Kontact works similarly. I think this is a great way to do things, because it means true frontend/backend separation - a frontend is just a shell for kparts, a backend is just a kpart, and both are interchangeable with others.
      • KDE and it's applications can be very modular but konqueror isn't one example of it. It is an application which is written to serve multiple purposes in a non-modular way, using KDE widgets. It isn't at all like Kontact, where it uses existing applications (Kmail, KNode, KOrganizer, etc etc etc...) as it's components.

        If someone wants to use only a mail client, it can ditch Kontact and use only KMail. If someone wants a newsreader but doesn't want all the clutter, then use KNode. What do I have to ditch in
        • No. Konqueror is just the shell. khtml supports HTML rendering, cookies, Java applets, CSS and so on. When you use Konqueror as a web browser, it's just a wrapper with a toolbar around khtml. Similarly, when you're browsing your local disk, Konqueror is just a shell for the KDE file browsing part (kfmclient?).

          In fact, if and whenever the Gecko kpart gets approved for inclusion into the standard KDE distribution, it's quite likely that you'll be able to compile KDE without khtml at all. Then you'll have Gec
        • You need to write an alternative wrapper around konq_dirpart. Alternatively, you can certainly build konqueror without some of the things you mention, although I suspect the basic html rendering may be essential without some severe hacking. OK so there's no easy way to do it right now that I know of, but konq_dirpart.h is there for anyone who wants to write a separate file browser
        • While it's not exactly the same (commander-style as opposed to explorer/finder-style), give Krusader a try.
  • im emerging it now as part of emerge -uDn world (after ive emerged gcc first) as part of my now ~x86 system - woo!
  • im really glad that slashdot has picked up again recently. 6 months ago, discussions like this would be like this:

    1) kde r0x
    2) no, kde sux! gnome r0x
    3) no, your sh1t! the cli is enough for everybody, gui's are for p00fs
    4) blackbox is l33t, everything else sux!

    etc.

    Or is it that the penguins at the south pole are the arseholes, but they only post in the night?

Slashdot Top Deals

"Trust me. I know what I'm doing." -- Sledge Hammer

Close