Well, don't take this as the official KDE position (I doubt there is one anyway, apart from what it has always been) but what you are saying is SPOT ON.
QPL _means_ open-source, which means free. IMHO it gives even more freedom to those who use it than the GPL (instead of forbidding closed-source derivatives, it allows it but with a fee).
Requiring 1000 authors to state the obvious (that they have no problem with their code being linked to Qt... why would they, given that it's as free as the GPL if not more?) is just stupid.
Too bad. $3000 would have got KDE a nice server I guess....
Ah ah ah. I can guarantee you the kspread author really doesn't care about screenshots. The code was surely not where it is now, granted, but it wasn't written to make screenshots, that's for sure !
"just like if they were already there". You didn't try konqueror. The features are already there. This is not an annoucement about vaporware at all. The stuff is there, it just needs a bit more polishing. Feel free to try it first.
KOM/OP was a failure, yes, and we've been mature enough to admit it and fix the situation. Others are still stuck with a dream about what CORBA can do for them... And tell me how do you "wait for the right technology" ? Nobody can read the future... It was some early communication, right. So what ? A bit of communication never hurts, on the contrary.
"the code was written in order to produce screenshots".
Well this is just 100% wrong. What can I say to prove it to you ? Nothing I'm afraid. But that's the truth: the KOffice code has NEVER been written to make screenshots only - but to produce a useable GPL'ed Office suite.
The delay between the early shots and the release is mainly due to the lack of developers. Feel free to give a hand (or both).
"If I had looked" ? Well, I have looked, mind you. I'm even responsible for a small part of it.
What pisses ME off is that someone can think that code could be written only to show impressive screenshots. That kind of nonsense doesn't exist here.
Once again, this is about choice. People who prefer multiple toplevel windows can do that with konqueror, no problem. Those who prefer splitting one window so that it shows 2 or 3 directories (local or remote) can do so. IMHO it helps a lot to reduce the number of windows opened (and you can drag-and-drop without having to worry about "how to reach that window hidden behind the current one"). But that's just me. If you prefer separate windows, you can do that. You can even choose to launch several processes if you want.
"I have recently read that KDE 2.0 is suppposed to be highly componentilized also. Is KDE using something like bonobo? " Yes indeed, KDE uses the very powerful component technology called KParts. It's mentionned on www.konqueror.org - you should really read it:-) As to being a threat to Mozilla, that is certainly not the goal. Providing something that works well (in terms of rendering, memory usage, stability etc.), and providing a choice, are more the goals. And konqueror is much more than 'just' a web browser...
Nobody said it was released. konqueror is still under development, though already useable. What is released today is the web site, to let people know about the cool stuff going on. Note that you don't have to run it under "a pre-alpha WM". Install KDE-2.x from snapshots or cvsup, and run konqueror under any WM you prefer.
ok, make that "left click menu", for KDE 1.x, as you can guess from the key "Left" in the config file.
I've just implemented it in kdesktop (the one for KDE 2.0), this way : you can assign ANY menu to ANY mouse button, the possible menus being : the applications menu, the window-list menu, the usual desktop menu or nothing. Happy ?:-)
(The apps menu showing up in kdesktop doesn't work yet though)
Interesting. It means it will take ages to be really used, because porting existing widget toolkits and applications is going to take a very long and painful time. What a waste of effort.
Unless the plan is to restart everything from scratch, and this time we'll start an unified project called knome or gde:)
You completely missed the point. Don't confuse HTML widget and web browser. The point here is that you can very easily use an HTML widget in your application, be it a mail reader, a text file (help files, man pages,....) viewer, or whatever else. A stupid example : want to add a 'credits' page to your app written in HTML ? Use KHTMLWidget.
libICE exists on your system. No need to use X in order to use it. You can even write text-based DCOP clients !
BUT : if you want to port Qt and KDE to something else than X, good luck. If we convert one day, well we'll have to convert a lot of things in all X-based programs out there, and that's not only Qt and KDE !!! Whatever other project takes off, I hope they keep an X-compatible API.
Nothing's mad here. Open the source code of any GUI program, you'll see that currently it uses X. It has, we all run X.
Re:KDE doomed to repeat Windows's mistakes
on
KDE 2.0 in Action
·
· Score: 1
Report KDE bugs to http://bugs.kde.org, not to slashdot. Cute animation : you can disable them. File dialog : most people complain it's too big and you find it too tiny ? interesting:-) And it DOES save its size. XEmacs : it pops up nicely for me. Check your XEmacs;-) And btw, most of this has NOTHING to do with Windows. Ever tried to resize the file dialog under windows ?
Re:NO CORBA !!! what where they thinking
on
KDE 2.0 in Action
·
· Score: 1
Yes you are wrong. Or at least you don't get the full picture. DCOP isn't a stupid IPC like X atoms or other old stuff. DCOP works with your server in hong kong, since it uses TCP/IP when talking to remote computers. It is object oriented, has an IDL compiler like CORBA (but much simpler to use since the IDL is generated from standard header files), and most importantly DCOP is very very lightweight. All KDE apps benefit from being able to use DCOP, whereas in the old days of using CORBA they couldn't afford the memory and speed issues. Please read http://www.kde.org/technology.html Or even best : try the current KDE and compare with the previous CORBA-based one. Facts speak for themselves.
Good news for you : KDE 1.x already does. Edit krootwmrc, go to (or create) group [MouseButtons] and add Left=Menu I know, I know, there should have been a dialog box for this. But that's the way you like, no ?;-) And I need to port that to kdesktop. Will do in a second:-)
Slashdot Mirror
QPL _means_ open-source, which means free. IMHO it gives even more freedom to those who use it than the GPL (instead of forbidding closed-source derivatives, it allows it but with a fee).
Requiring 1000 authors to state the obvious (that they have no problem with their code being linked to Qt... why would they, given that it's as free as the GPL if not more?) is just stupid.
Too bad. $3000 would have got KDE a nice server I guess....
You got KParts and DCOP right, though ;)
"just like if they were already there". You didn't try konqueror. The features are already there. This is not an annoucement about vaporware at all. The stuff is there, it just needs a bit more polishing. Feel free to try it first.
KOM/OP was a failure, yes, and we've been mature enough to admit it and fix the situation. Others are still stuck with a dream about what CORBA can do for them... And tell me how do you "wait for the right technology" ? Nobody can read the future... It was some early communication, right. So what ? A bit of communication never hurts, on the contrary.
Well this is just 100% wrong. What can I say to prove it to you ? Nothing I'm afraid. But that's the truth: the KOffice code has NEVER been written to make screenshots only - but to produce a useable GPL'ed Office suite.
The delay between the early shots and the release is mainly due to the lack of developers. Feel free to give a hand (or both).
"If I had looked" ? Well, I have looked, mind you. I'm even responsible for a small part of it.
What pisses ME off is that someone can think that code could be written only to show impressive screenshots. That kind of nonsense doesn't exist here.
Once again, this is about choice. People who prefer multiple toplevel windows can do that with konqueror, no problem. Those who prefer splitting one window so that it shows 2 or 3 directories (local or remote) can do so. IMHO it helps a lot to reduce the number of windows opened (and you can drag-and-drop without having to worry about "how to reach that window hidden behind the current one"). But that's just me. If you prefer separate windows, you can do that. You can even choose to launch several processes if you want.
kfm already had that feature !
And konqueror too, of course.
Hmm, kfm does FTP downloads just fine :-)
Drag a file from a FTP site, and drop it on
the desktop or any other local directory.
"I have recently read that KDE 2.0 is suppposed to be highly componentilized also. Is KDE using something like bonobo? " :-)
Yes indeed, KDE uses the very powerful component technology called KParts. It's mentionned on www.konqueror.org - you should really read it
As to being a threat to Mozilla, that is certainly not the goal. Providing something that works well (in terms of rendering, memory usage, stability etc.), and providing a choice, are more the goals. And konqueror is much more than 'just' a web browser...
SSL support is there, indeed.
(Requires openSSL installed, AFAIK.)
Nobody said it was released. konqueror is still under development, though already useable.
What is released today is the web site, to let people know about the cool stuff going on.
Note that you don't have to run it under "a pre-alpha WM". Install KDE-2.x from snapshots or cvsup, and run konqueror under any WM you prefer.
ok, make that "left click menu", for KDE 1.x,
:-)
as you can guess from the key "Left" in the config file.
I've just implemented it in kdesktop (the one for KDE 2.0), this way :
you can assign ANY menu to ANY mouse button,
the possible menus being : the applications menu,
the window-list menu, the usual desktop menu or nothing.
Happy ?
(The apps menu showing up in kdesktop doesn't work yet though)
Interesting.
:)
It means it will take ages to be really used,
because porting existing widget toolkits and applications is going to take a very long and painful time. What a waste of effort.
Unless the plan is to restart everything from scratch, and this time we'll start an unified project called knome or gde
You completely missed the point.
Don't confuse HTML widget and web browser.
The point here is that you can very easily use an HTML widget in your application, be it a mail reader, a text file (help files, man pages,....) viewer, or whatever else.
A stupid example : want to add a 'credits' page to your app written in HTML ? Use KHTMLWidget.
How can you do that with netscape ?
libICE exists on your system. No need to use X in order to use it. You can even write text-based DCOP clients !
BUT : if you want to port Qt and KDE to something else than X, good luck. If we convert one day, well we'll have to convert a lot of things in all X-based programs out there, and that's not only Qt and KDE !!! Whatever other project takes off, I hope they keep an X-compatible API.
Nothing's mad here. Open the source code of any GUI program, you'll see that currently it uses X. It has, we all run X.
Report KDE bugs to http://bugs.kde.org, not to slashdot. Cute animation : you can disable them. File dialog : most people complain it's too big and you find it too tiny ? interesting :-) And it DOES save its size. XEmacs : it pops up nicely for me. Check your XEmacs ;-) And btw, most of this has NOTHING to do with Windows. Ever tried to resize the file dialog under windows ?
Yes you are wrong. Or at least you don't get the full picture. DCOP isn't a stupid IPC like X atoms or other old stuff. DCOP works with your server in hong kong, since it uses TCP/IP when talking to remote computers. It is object oriented, has an IDL compiler like CORBA (but much simpler to use since the IDL is generated from standard header files), and most importantly DCOP is very very lightweight. All KDE apps benefit from being able to use DCOP, whereas in the old days of using CORBA they couldn't afford the memory and speed issues. Please read http://www.kde.org/technology.html Or even best : try the current KDE and compare with the previous CORBA-based one. Facts speak for themselves.
Good news for you : KDE 1.x already does. Edit krootwmrc, go to (or create) group [MouseButtons] and add Left=Menu I know, I know, there should have been a dialog box for this. But that's the way you like, no ? ;-) And I need to port that to kdesktop. Will do in a second :-)