not that matters, really, but Linus has submitted a few bug reports to KDE. he apparently uses KDE from CVS HEAD more often than not (from a bug report against a pre-3.0 code base). so Linus does indeed use KDE.
on the other hand, Alan Cox primarily uses XFCE, last I heard. previous to that was a GNOMEr.
*shrug* interesting, but who really cares. =)
Re:Interaction, not Merging
on
Phoenix 0.3 Is Out
·
· Score: 4, Insightful
dcop is not tied to Qt. there is a C implementation of dcop that has nary a trace of Qt in it distributed with kdelibs.
and while you are correct that DCOP is fairly simple and less featureful than something like CORBA (which, given the context for DCOP isn't necessarily a bad thing), it can and does send/recv binary data
what flashy extras, prey tell? i don't know where KDE got this "it's just pretty" thing from since it is one of the most useful environments around. in fact, i seem to remember in the days of kde1 that it was heralded as "ugly but at least it works". now that its not butt-ugly it gets thrashed for that. heh... ingrates.
and if you are serious about the CLI, then take the other replier's suggestion: use something truly minimal. recent blackbox builds are very nice, and the bb* tools are keeping pace as well.
good thing that isn't KDE's default look, then. we'd be pretty stupid to released a centered panel as default, since that would rob us of using the corners ala Fitt's Law. no, what you have there is a screenshot full of optional stuff (keramik, translucent menus, centered panel, etc..) not the default set-up.
well, to be fair, i didn't "start up" the KDE usability project. it just wasn't very active before i and a few others descended upon it and decided to get some actual reports written and some actual coding done.
i believe jono started the project and others such as chris howells were involved early on.
the time and effort of everyone who took the initiative has resulted in more and more of the KDE developers and users (along with some new devels and usability people) getting on the list and getting involved.
it's fun to be part of something positive and intense as it unfolds...
yeah, well... too late for that. an "all in one page" option was slated for this weekend and the official release of the site was for next week. i even stated on a public list where it was discussed that bandwidth was an issue ATM on the server it is currently sitting on. but i suppose someone just had to post it to slashdot, didn't they. *sigh*
AJS
Re:Splash Screen Segfault...
on
KDE 3.0.1 Ships
·
· Score: 1
a division by zero bug in the qprogress widget, which ksplash managed to trigger. it has since been fixed in qt.
Re:GCC3 Support?
on
KDE 3.0.1 Ships
·
· Score: 2, Informative
i can attest that it does indeed compile properly with gcc versions earlier than gcc-2.95 as i build it daily on a box with egcs 1.1.2. there are no guarentees it will remain compileable with egcs 1.1.2 in the future, though it probably will at least until i upgrade this machine here;-)
yes, that is exactly what it is. you can grab it from cervisia's website or you can get the kdesdk package from KDE's CVS which, as of the KDE3 development branch, includes cervisia
Re:KParts won't dominate
on
Coding with KParts
·
· Score: 3, Informative
kparts is licensed under the LGPL. you can link to it even from commercial applications, just like the rest of the kde libraries.
Xt is not the same sort of "component architecture" that kparts is. Xt is for X Window widgets, kparts is for generically embedding entire applications (or parts of applications) within other applications (or kparts). this embedding includes things like transparently merging menu and toolbar entries. it goes far beyond Xt.
there is very little obsolete legacy code in KDE3. that was one of the big pushes for 3.0: to remove/improve all the items that couldn't be touched during KDE2 due to the requirement of keeping binary compatibility.
first of all, there are style guidelines that KDE apps are to follow. this keeps most problems at bay.
second, there is a mailing list and a web site for the kde usability project, which is basically a group of usability pros, hackers and general users who are interested in improving the usability of KDE
finally, beta testers and even users of stable releases are an extremeley important resource for usability and quality feedback for the KDE project.
so its a little bit of everything, really =) it just requires that people get involved, which thankfully many do.
this is a great example of how open source is supposed to work. the developers were busy fixing other bugs when a user/tester trying out a beta release noticed that their old address book didn't import and complains very loudly about it. so what happened next? it got fixed. your old addy book will indeed get imported automagically for you in 3.0.
this is exactly why there are beta and RC releases: so testers can spot problems, report them, and get them fixed.
besides Qt3 (which others have pointed out) there are a number of new features and general improvements. for example the javascript and html engines are both much better/faster than what was in kde2. directory listing is much faster, the file dialog has been spiffed up a bit more, there is support for file information plugins that appear on mouse over (not to mention animated icons), improved imap and gpg support in kmail, dcop has been improved tremendously from the viewpoint of scripting, aRts is much improved with the new GSL engine (cooperation with GNOME!), some new eye-candy like animated window decorations and new thumbnail types, tons of bug fixes and speed ups etc.. etc.. etc...
this is very much an evolutionary release as opposed to a revolutionary one (as KDE2.0 was), but the changes are quite noticeable. they make the general kde experience smoother and more useful IMO. one nice thing about it being evolutionary is that it is immediately stable and familiar...
check out the agypten project, they are busy finishing up ldap support (among other things) for kmail. the merge between their devel branch and the main kmail devel branch is scehduled to occur between the 3.0 and 3.1 releases of KDE.
if you do decide to make this part of your platform, why not talk about it from the standpoint of it benefiting the local economy? reduced expenditures due to saving on both software licensing and hardware upgrades means less taxpayer money spent on infrastructure. it could also level the playing field between large software companies and local consulting firms, encouraging more technology money to be spent locally instead of funelled outside the City's economy. finally, by investing in open solutions the government retains control over its information systems and will not be at the whim or mercy of a corporation who owns the intellectual property rights to and controls the future of those technologies.
but how long does it take to do the planning? obviously that is part of the time to complete the project, so can you tell how long such planning will take for a given scenario?
this also assumes nothing changes after "planning" is done. heh. yeah, sure.
you are mixing two different applications of patents rather freely and without discrimination.
placing a patent on a physical device that is the result of research obviously benefits business and mankind at large. however, when one applies a patent to a protocol that is intended to be part of the fabric that allows the global human community to communicate it hinders not only that communication but other business interests from using it.
you seem to forget that the very web board you are reading and commenting on would not exist, along with 99% of the rest of the internet, were patents accepted and applied on standard internet technologies. patents do have their place, but open network standards is not one of them.
Slashdot Mirror
not that matters, really, but Linus has submitted a few bug reports to KDE. he apparently uses KDE from CVS HEAD more often than not (from a bug report against a pre-3.0 code base). so Linus does indeed use KDE.
on the other hand, Alan Cox primarily uses XFCE, last I heard. previous to that was a GNOMEr.
*shrug* interesting, but who really cares. =)
dcop is not tied to Qt. there is a C implementation of dcop that has nary a trace of Qt in it distributed with kdelibs.
and while you are correct that DCOP is fairly simple and less featureful than something like CORBA (which, given the context for DCOP isn't necessarily a bad thing), it can and does send/recv binary data
and if you are serious about the CLI, then take the other replier's suggestion: use something truly minimal. recent blackbox builds are very nice, and the bb* tools are keeping pace as well.
nice attempt at trolling though.
hmm... those are exactly the same reasons i use linux. funny that. =)
you may find that reading
this and
this helps you understand kde development issues a bit better.
right click on the panel (kicker), select Add -> Special Button -> Window List ... tada! a button with a menu that shows you your tasks!
well, to be fair, i didn't "start up" the KDE usability project. it just wasn't very active before i and a few others descended upon it and decided to get some actual reports written and some actual coding done.
...
i believe jono started the project and others such as chris howells were involved early on.
the time and effort of everyone who took the initiative has resulted in more and more of the KDE developers and users (along with some new devels and usability people) getting on the list and getting involved.
it's fun to be part of something positive and intense as it unfolds
AJS
yeah, well ... too late for that. an "all in one page" option was slated for this weekend and the official release of the site was for next week. i even stated on a public list where it was discussed that bandwidth was an issue ATM on the server it is currently sitting on. but i suppose someone just had to post it to slashdot, didn't they. *sigh*
AJS
a division by zero bug in the qprogress widget, which ksplash managed to trigger. it has since been fixed in qt.
i can attest that it does indeed compile properly with gcc versions earlier than gcc-2.95 as i build it daily on a box with egcs 1.1.2. there are no guarentees it will remain compileable with egcs 1.1.2 in the future, though it probably will at least until i upgrade this machine here ;-)
yes, that is exactly what it is. you can grab it from cervisia's website or you can get the kdesdk package from KDE's CVS which, as of the KDE3 development branch, includes cervisia
kparts is licensed under the LGPL. you can link to it even from commercial applications, just like the rest of the kde libraries.
Xt is not the same sort of "component architecture" that kparts is. Xt is for X Window widgets, kparts is for generically embedding entire applications (or parts of applications) within other applications (or kparts). this embedding includes things like transparently merging menu and toolbar entries. it goes far beyond Xt.
in the control center, go to Periferals -> Mouse and look in the Icons area ... it has been there since KDE2
just keep your qt2/kde2 libs around. that way apps that link to qt2/kde2 will continue to work.
there is very little obsolete legacy code in KDE3. that was one of the big pushes for 3.0: to remove/improve all the items that couldn't be touched during KDE2 due to the requirement of keeping binary compatibility.
second, there is a mailing list and a web site for the kde usability project, which is basically a group of usability pros, hackers and general users who are interested in improving the usability of KDE
finally, beta testers and even users of stable releases are an extremeley important resource for usability and quality feedback for the KDE project.
so its a little bit of everything, really =) it just requires that people get involved, which thankfully many do.
this is exactly why there are beta and RC releases: so testers can spot problems, report them, and get them fixed.
this is very much an evolutionary release as opposed to a revolutionary one (as KDE2.0 was), but the changes are quite noticeable. they make the general kde experience smoother and more useful IMO. one nice thing about it being evolutionary is that it is immediately stable and familiar ...
check out the agypten project, they are busy finishing up ldap support (among other things) for kmail. the merge between their devel branch and the main kmail devel branch is scehduled to occur between the 3.0 and 3.1 releases of KDE.
if you do decide to make this part of your platform, why not talk about it from the standpoint of it benefiting the local economy? reduced expenditures due to saving on both software licensing and hardware upgrades means less taxpayer money spent on infrastructure. it could also level the playing field between large software companies and local consulting firms, encouraging more technology money to be spent locally instead of funelled outside the City's economy. finally, by investing in open solutions the government retains control over its information systems and will not be at the whim or mercy of a corporation who owns the intellectual property rights to and controls the future of those technologies.
just a thought.
but how long does it take to do the planning? obviously that is part of the time to complete the project, so can you tell how long such planning will take for a given scenario?
this also assumes nothing changes after "planning" is done. heh. yeah, sure.
well, as the author of KC KDE i can tell you that no such thing was ever in any issue of KC KDE.
besides, KDE already runs on Solaris. oh, and Sun would only need to pay Qt if they wrote closed source applications.
troll. *sigh*
placing a patent on a physical device that is the result of research obviously benefits business and mankind at large. however, when one applies a patent to a protocol that is intended to be part of the fabric that allows the global human community to communicate it hinders not only that communication but other business interests from using it.
you seem to forget that the very web board you are reading and commenting on would not exist, along with 99% of the rest of the internet, were patents accepted and applied on standard internet technologies. patents do have their place, but open network standards is not one of them.