Re:do not stop progress by not wanting 'bloat'...
on
KDE 4.0 RC 1 Released
·
· Score: 2, Informative
You can verify the numbers yourself, there are instructions included. Or rather you can find out the current state, since the article is more than a year old. As for something done by somebody from GNOME, there is http://spooky-possum.org/cgi-bin/pyblosxom.cgi/kdevsgnome.html, written later, that says the usage is roughly the same. Note however that despite being some kind of a response to the first comparison this one measures the numbers in a way that is not recommended by it, and it even admits so in the 3rd paragraph (go figure). Not that I have any real reason to disprove the numbers though, it may very well be that in that specific configuration the usage was roughly the same, within the noise caused by the measurement method.
So yes, to sum it up, just generally claiming that KDE is more bloated than GNOME is a nonsense and has been for a long time (and maybe even that's never been true, for fair comparisons, but I don't remember anybody doing one in the long past, at most various flawed comparisons).
PS: And, just in case you find some similarity between my nick and the URL of the first comparison, it is not incidental.
Re:do not stop progress by not wanting 'bloat'...
on
KDE 4.0 RC 1 Released
·
· Score: 1
We've decided that cube and wobbly score quite low on the gain/effort scale and they won't be in 4.0 (but somewhen later when somebody will feel like writing them). For virtual desktops there is a different effect and there's only a silly wobbly-like demo effect showing it's possible.
> Its really sad that Windows with all its services and stuff uses 1/2 the RAM of KDE alone.
Does it? How do you know? Sorry, but this looks exactly like a yet another clueless post from somebody who doesn't even know how to actually measure memory usage on Linux (http://www.kdedevelopers.org/node/1445). Your claim lacks some important numbers, Windows version to start with (ok, XP is not exactly a number) or the memory usage numbers themselves.
> unfortunately, everything in kde is a little too self contained. as in it doesn't launch the 'default' browser (sensible-browser) that you set. there's not even a simple config/dialog where you can choose to run firefox/mozilla instead of konqueror whenever you click on links on other "K" apps.
It does launch the default sensible browser for me. And in case such browser is not Konqueror in your case, that non-existent config dialog is in KControl - KDE Components - Component chooser - Web browser.
First of all, I suggest you find out what the difference between a desktop environment and a window manager is.
I wonder, what exactly are you trying to say with the title "Real window managers"? That KDE doesn't have a real (whatever that is supposed to mean) window manager? How comes then users of all those real window managers moan (http://developers.slashdot.org/article.pl?sid=04/ 11/29/171204 - search for not stealing focus or opening new applications on the virtual desktop they were started on) about (lack of) window manager features KDE's window manager has had since some time already?
And, you know, features have their costs. Imagining my mum or sister using EvilWM (presumably together with xterm, right?), that's not even funny... that's cruel.
Re:why do you use gnome?
on
GNOME 2.8 Released
·
· Score: 1, Informative
If you really want to switch just a window manager, and aren't confusing window managers and desktops, you can do that in KDE too.
Sorry, but the things claimed in the article about the interview somehow don't quite match what google search for "miguel icaza microsoft visa" gives.
http://www.theregister.co.uk/2002/02/05/explain_ yo urself_miguel_demands_rms/ or http://www.mexicobusiness.com/archives/julaug00/ed itorial/icaza.htm claim wasn't hired by Microsoft only because he would get the necessary visa.
I somehow doubt Microsoft would be willing to hire (and probably would, if it wasn't for the visa) somebody for who the interview was "an opportunity to lecture managers on why Microsoft should abandon its multibillion-dollar business model and embrace open-source programming".
Keyboard shortcuts for switching between virtual desktops are Ctrl+F (really difficult to find in the keyboard shortcuts KControl module, right?). Alt+Tab not being restricted to current virtual desktop can be changed in the window manager focus KControl module (really difficult as well).
As for the suggestion: It'd be noticeably faster and simpler if you bothered to find it out yourself.
Actually I didn't intend to wink, that was supposed to be normal smiley. I think KDE was the first usable Linux GUI, and keeps being the best. YMMV
As for the usability problem, if the dialog has 'apply' button, then common sense says the settings will be applied after you click that button. I don't see any problem with that.
"Qt is GPLed, and as such, prevents FOSS developers from using any OSS licenses that are not compatible with the GPL. Ironically enough, XFree86's license is not compatible with the GPL, and hence XFree86 could not include a Qt configuration utility."
Your first statement is wrong. Should I bother reading the rest?
Actually Konqueror/KHTML and Kontact are not really reinventing the wheel.
The work on KDE's filemanager and HTML engine dates back to the days when the only usable *cough* browser was Netscape4.x and Mozilla seemed only like a great failure.
Kontact is basically an aggregation of long time existing KDE applications like KMail, KNode, KNotes etc., pre-dating e.g. Evolution.
That said, this question about reinventing the wheel is stupid anyway. First, there are many things about KDE that KDE has had first (like, the first usable Linux GUI;) ), and second, everybody is reinventing the wheel all the time anyway, so what?
Re:Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 1
> "signals", "slots", "foreach" etc. are just #define's, there's nothing special about them from this point of view.
("this point of view" being talking about how Qt.h files can be normally compiled).
$ cat qobjectdefs.h | grep -e slots -e signals #define slots slots #define signals signals #define slots// slots: in class #define signals protected// signals: in class
The second pair gets used when normally compiling.
Re:Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 1
No,.h files using Qt are normal.h files, and can be normally compiled (after being included in.cpp files and preprocessed by the C++ preprocessor, of course, just like all.h files). "signals", "slots", "foreach" etc. are just #define's, there's nothing special about them from this point of view.
BTW, moc is not a preprocessor when using your definition either:), at least I don't think the moc output can be considered a subset of the.h file. That'd be like claiming doxygen is a preprocessor.
Not that this playing with words matters actually. What matters is that people using Qt are quite happy with it and don't think there's anything seriously wrong with it (well, everything has its disadvantages indeed, but Qt without moc would be a noticeably worse toolkit).
Re:Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 1
There might be something wrong with my definition of "preprocessor", but AFAIK preprocessor is a tool which transforms its source to another form, which is further processed, and the original form (source) is no longer used.
E.g. with C++ compilation, the.cpp is preprocessed by the C/C++ preprocessor, which results in the.ii file, which is futher compiled by the actual C++ compiler (this is usually handled by g++ as one step, so the.ii is not visible to the developer unless the steps are explicitly done separately). The source.cpp file is not used for the actual compiling, and in fact even cannot be compiled by the actual C++ compiler (just try to rename a.cpp file to.ii and compile it).
In this sense of the word "preprocessor", moc is not a preprocessor. All.h files passed to moc can be normally compiled (#included in.cpp files indeed) using g++ just like other non-Qt.h files. All moc does is it analyzes the.h file, and creates additional C++ code (which would have to be written manually otherwise), and this additional C++ code is used for the before-mentioned features which are not available directly in the C++ language.
But maybe it's just that there's really something wrong with my definition...
Also, while I'm at it, http://doc.trolltech.com/3.3/templates.html calls moc a precompiler, and explains some reasons for moc's existence even today, when templates finally have a decent support in available C++ compilers.
Re:Qt is almost a like a language
on
A Taste of Qt 4
·
· Score: 3, Insightful
Let's try it once again for for those who are a bit slow: - moc is not a preprocessor (funny that this slashdot story says so right next to the link where Havoc says it's not) - moc fills in features that are not already in the language; how exactly does gtkmm do dynamic introspection (properties, finding out which signals/slots are available at runtime, etc.) in the "right way" ? - just like most of the Qt bashers, you're a moron talking about something you have no clue about
It's strange the article mentions unsermake but not icecream, which IMHO beats distcc, despite not being officially called stable. Icecream has a scheduler and is therefore noticeably less stupid with distributing the builds (it happened to me repeatedly with distcc that it sent the first job to the most loaded node, which kind of sucks if you just changed one file). Icecream can be obtained the same way like unsermake, it's located in kdenonbeta/icecream.
> - For whatever reason, my desktop occasionally gets switched to a Firefox virtual desktop I often keep open. Probably due to some javascript/focus thing with Firefox, but I hadn't noticed it before. Of course, somewhere along the line I upgraded Firefox, but I don't have the problem on a RH 8 system.
Could you find a way how to reproduce the problem and report this as a kwin bug? The new focus stealing prevention should prevent this.
You can run KDE even with other window manager than KWin, as long as that window manager has decent support for the EWMH (aka NETWM) specification. Which I'm afraid AfterStep or WindowMaker don't.
Klipper in KDE3.2 should be much better than it used to be.
Re:Dont forget to check the Window Manager.
on
Review: KDE 3.2
·
· Score: 1
Yes, KWin (KDE's window manager) can run standalone. However, unlike most other WMs, KWin is a pure window manager, and does only that - it manages windows, and that's about it. So there's probably not much point in running it standalone, and most people need also panel, background, etc. (which are provided by other KDE components).
On a slightly related (in fact, opposite) note, one can try running other WMs with KDE. Currently not much tested, as somebody has to try it first for for real to find out the problems:).
Slashdot Mirror
You can verify the numbers yourself, there are instructions included. Or rather you can find out the current state, since the article is more than a year old. As for something done by somebody from GNOME, there is http://spooky-possum.org/cgi-bin/pyblosxom.cgi/kdevsgnome.html, written later, that says the usage is roughly the same. Note however that despite being some kind of a response to the first comparison this one measures the numbers in a way that is not recommended by it, and it even admits so in the 3rd paragraph (go figure). Not that I have any real reason to disprove the numbers though, it may very well be that in that specific configuration the usage was roughly the same, within the noise caused by the measurement method.
So yes, to sum it up, just generally claiming that KDE is more bloated than GNOME is a nonsense and has been for a long time (and maybe even that's never been true, for fair comparisons, but I don't remember anybody doing one in the long past, at most various flawed comparisons).
PS: And, just in case you find some similarity between my nick and the URL of the first comparison, it is not incidental.
How about e.g. http://ktown.kde.org/~seli/memory/?
We've decided that cube and wobbly score quite low on the gain/effort scale and they won't be in 4.0 (but somewhen later when somebody will feel like writing them). For virtual desktops there is a different effect and there's only a silly wobbly-like demo effect showing it's possible.
Plasma has nothing to do with compositing in KWin - KWin's compositing is, well, KWin's.
Krita
http://wiki.kde.org/tiki-index.php?page=Performanc e%20Tips
> Its really sad that Windows with all its services and stuff uses 1/2 the RAM of KDE alone.
Does it? How do you know? Sorry, but this looks exactly like a yet another clueless post from somebody who doesn't even know how to actually measure memory usage on Linux (http://www.kdedevelopers.org/node/1445). Your claim lacks some important numbers, Windows version to start with (ok, XP is not exactly a number) or the memory usage numbers themselves.
> unfortunately, everything in kde is a little too self contained. as in it doesn't launch the 'default' browser (sensible-browser) that you set. there's not even a simple config/dialog where you can choose to run firefox/mozilla instead of konqueror whenever you click on links on other "K" apps.
It does launch the default sensible browser for me. And in case such browser is not Konqueror in your case, that non-existent config dialog is in KControl - KDE Components - Component chooser - Web browser.
First of all, I suggest you find out what the difference between a desktop environment and a window manager is.
/ 11/29/171204 - search for not stealing focus or opening new applications on the virtual desktop they were started on) about (lack of) window manager features KDE's window manager has had since some time already?
... that's cruel.
I wonder, what exactly are you trying to say with the title "Real window managers"? That KDE doesn't have a real (whatever that is supposed to mean) window manager? How comes then users of all those real window managers moan (http://developers.slashdot.org/article.pl?sid=04
And, you know, features have their costs. Imagining my mum or sister using EvilWM (presumably together with xterm, right?), that's not even funny
If you really want to switch just a window manager, and aren't confusing window managers and desktops, you can do that in KDE too.
Sorry, but the things claimed in the article about the interview somehow don't quite match what google search for "miguel icaza microsoft visa" gives.
_ yo urself_miguel_demands_rms/ or http://www.mexicobusiness.com/archives/julaug00/ed itorial/icaza.htm claim wasn't hired by Microsoft only because he would get the necessary visa.
http://www.theregister.co.uk/2002/02/05/explain
I somehow doubt Microsoft would be willing to hire (and probably would, if it wasn't for the visa) somebody for who the interview was "an opportunity to lecture managers on why Microsoft should abandon its multibillion-dollar business model and embrace open-source programming".
Keyboard shortcuts for switching between virtual desktops are Ctrl+F (really difficult to find in the keyboard shortcuts KControl module, right?). Alt+Tab not being restricted to current virtual desktop can be changed in the window manager focus KControl module (really difficult as well).
As for the suggestion: It'd be noticeably faster and simpler if you bothered to find it out yourself.
Actually I didn't intend to wink, that was supposed to be normal smiley. I think KDE was the first usable Linux GUI, and keeps being the best. YMMV
As for the usability problem, if the dialog has 'apply' button, then common sense says the settings will be applied after you click that button. I don't see any problem with that.
"Qt is GPLed, and as such, prevents FOSS developers from using any OSS licenses that are not compatible with the GPL. Ironically enough, XFree86's license is not compatible with the GPL, and hence XFree86 could not include a Qt configuration utility."
Your first statement is wrong. Should I bother reading the rest?
http://www.trolltech.com/developer/faqs/license_gp l.html#q19
http://www.trolltech.com/developer/faqs/license_gp l.html#q114
Actually Konqueror/KHTML and Kontact are not really reinventing the wheel.
;) ), and second, everybody is reinventing the wheel all the time anyway, so what?
The work on KDE's filemanager and HTML engine dates back to the days when the only usable *cough* browser was Netscape4.x and Mozilla seemed only like a great failure.
Kontact is basically an aggregation of long time existing KDE applications like KMail, KNode, KNotes etc., pre-dating e.g. Evolution.
That said, this question about reinventing the wheel is stupid anyway. First, there are many things about KDE that KDE has had first (like, the first usable Linux GUI
> "signals", "slots", "foreach" etc. are just #define's, there's nothing special about them from this point of view.
.h files can be normally compiled).
// slots: in class // signals: in class
("this point of view" being talking about how Qt
$ cat qobjectdefs.h | grep -e slots -e signals
#define slots slots
#define signals signals
#define slots
#define signals protected
The second pair gets used when normally compiling.
No, .h files using Qt are normal .h files, and can be normally compiled (after being included in .cpp files and preprocessed by the C++ preprocessor, of course, just like all .h files). "signals", "slots", "foreach" etc. are just #define's, there's nothing special about them from this point of view.
:), at least I don't think the moc output can be considered a subset of the .h file. That'd be like claiming doxygen is a preprocessor.
BTW, moc is not a preprocessor when using your definition either
Not that this playing with words matters actually. What matters is that people using Qt are quite happy with it and don't think there's anything seriously wrong with it (well, everything has its disadvantages indeed, but Qt without moc would be a noticeably worse toolkit).
There might be something wrong with my definition of "preprocessor", but AFAIK preprocessor is a tool which transforms its source to another form, which is further processed, and the original form (source) is no longer used.
.cpp is preprocessed by the C/C++ preprocessor, which results in the .ii file, which is futher compiled by the actual C++ compiler (this is usually handled by g++ as one step, so the .ii is not visible to the developer unless the steps are explicitly done separately). The source .cpp file is not used for the actual compiling, and in fact even cannot be compiled by the actual C++ compiler (just try to rename a .cpp file to .ii and compile it).
.h files passed to moc can be normally compiled (#included in .cpp files indeed) using g++ just like other non-Qt .h files. All moc does is it analyzes the .h file, and creates additional C++ code (which would have to be written manually otherwise), and this additional C++ code is used for the before-mentioned features which are not available directly in the C++ language.
E.g. with C++ compilation, the
In this sense of the word "preprocessor", moc is not a preprocessor. All
But maybe it's just that there's really something wrong with my definition...
Also, while I'm at it, http://doc.trolltech.com/3.3/templates.html calls moc a precompiler, and explains some reasons for moc's existence even today, when templates finally have a decent support in available C++ compilers.
Let's try it once again for for those who are a bit slow:
- moc is not a preprocessor (funny that this slashdot story says so right next to the link where Havoc says it's not)
- moc fills in features that are not already in the language; how exactly does gtkmm do dynamic introspection (properties, finding out which signals/slots are available at runtime, etc.) in the "right way" ?
- just like most of the Qt bashers, you're a moron talking about something you have no clue about
It's strange the article mentions unsermake but not icecream, which IMHO beats distcc, despite not being officially called stable. Icecream has a scheduler and is therefore noticeably less stupid with distributing the builds (it happened to me repeatedly with distcc that it sent the first job to the most loaded node, which kind of sucks if you just changed one file).
Icecream can be obtained the same way like unsermake, it's located in kdenonbeta/icecream.
> - For whatever reason, my desktop occasionally gets switched to a Firefox virtual desktop I often keep open. Probably due to some javascript/focus thing with Firefox, but I hadn't noticed it before. Of course, somewhere along the line I upgraded Firefox, but I don't have the problem on a RH 8 system.
Could you find a way how to reproduce the problem and report this as a kwin bug? The new focus stealing prevention should prevent this.
You can run KDE even with other window manager than KWin, as long as that window manager has decent support for the EWMH (aka NETWM) specification. Which I'm afraid AfterStep or WindowMaker don't.
Klipper in KDE3.2 should be much better than it used to be.
Yes, KWin (KDE's window manager) can run standalone. However, unlike most other WMs, KWin is a pure window manager, and does only that - it manages windows, and that's about it. So there's probably not much point in running it standalone, and most people need also panel, background, etc. (which are provided by other KDE components).
On a slightly related (in fact, opposite) note, one can try running other WMs with KDE. Currently not much tested, as somebody has to try it first for for real to find out the problems :).