SCP in the browser is something I don't want to do (command-line, always the command-line) ---------- I'm a CLI-whore too, but I don't use the CLI when I'd lose time by doing so. Having SCP supported in the file dialog is tremendously useful when you're already working in a GUI app. That way, you can save right to the remote dir, instead of saving locally, switching to a terminal, and then using scp.
KMail is(er.. was) possibly the worst core KDE application, IMO. I have used it pleny of times, and it always does something unexpected(deleting mail, crashes, etc.). --------- I've been using KMail since the 2.x days, and I've never had it lose email.
I also find the interface to be rather buggy and quirky. ---------- How so? KMail's interface is pretty straightforward. Folders on left, mail on top right, current message on bottom right. Toolbar buttons to compose, save, and print emails, as well as download new emails, reply and forward emails, iterate through unchecked mail, delete email, and search for emails. A lot of KDE apps are cluttered and have overly complex interfaces, but KMail is not one of them.
But what I think the other guy was getting at is that it lacks the huge number of features of most "modern" email clients. ------------- Like? Kmail has made enormous strides over the past year, because of the Kolab/Kontact work. By the time Kontact is mature (when the Kolab work gets integrated in a few months time), Kontact will most likely be more feature-complete than Evolution.
Personally, I use mutt these days, with vim as my pager and editor(you just can't beat that). ------------- Heh. Thanks to KParts, you can use vim in KMail too:) Its included in 3.2
False. Both use many GTK widgets now. Look at the buttons, text entry boxes, etc. Still not GTK menus though... --------- You're right, I hadn't looked at a recent Firebird release. Although, its really not a GTK app. It still uses XUL as its toolkit. You can get OpenOffice to use Qt to draw its buttons/menus/etc too, but that doesn't really make it a Qt app, does it?
No, he was correct. Ximian has been working with OO.o, and they have implemented GTK for nearly the entire app(using the GUI-independent framework? I don't know... but it is there). -------- No, I was correct:) The OOo situation is a bit complex. What Ximian is working on is a GTK+ version of OpenOffice's Native Widget Framework (NWF). Contrary to the name, the NWF is not a port of OOo to the native toolkit. Rather, it is a way to use the native toolkit to draw widgets for OOo. Its a cosmetic layer on top of the OOo VCL toolkit. KDE has an NWF implementation that's pretty far along as well. Of course, all of this is completely different from the new toolkit abstraction outlined in the Q Concept, which will have native ports for GTK+, Windows, Qt, and OS X.
This is a phenomenally useful feature. I used Kate to work on a website for school, and it was phenomenal how much more productive this is than the usual edit/upload cycle. Better yet, if I want to print a document to the central print office, I just save it to the remote ssh folder directly. If I want to save a powerpoint presentation onto my school account, I just save it there, no fussing with an FTP client.
He's right. You can change the color scheme. You can create a different gtkrc with different colors that uses the same theme engine, but thats a different theme. KDE lets you apply any color scheme to any theme.
Take a hard look at Windows apps like Office, Visual Studio, and Internet Explorer. Not only do they not look the same, but they do not behave the same. And these come from a single company!
First, that's not true. You can use any program in any window manager. Second, with these integration efforts, users probably won't even notice the difference. Certainly, most users don't notice a difference between all the Windows toolkits, even though basic applications like Office use their own toolkit.
For Novell the choice is allready made with their ownership of Ximian and Evolution. --------- They also own SuSE. SuSE is a larger company than Ximian, and have a much larger market presence (many of the big desktop rollouts so far have been KDE on SuSE). There is no reason to believe Novell will go with GNOME at this point.
And for the end user the technical differences between environments don't really matter. If the general feeling with the environment you are first provided with is good enough, you're pretty much stuck with that. -------- I don't disagree with you, but that doesn't make it a good thing. My original point was that if GNOME wins (in its current form), it would be another example of better technology being beat by more marketable marketable technology.
You don't really want to know about your options (not if you're normal anyway:). --------- Then we might as well rethink this whole capitalism thing, because capitalism is all about thinking about your options and picking the best one.
It depends on which the dominating desktop environment ends up being. If its GNOME (without a radical shift in design), then yes, it will be bad. Because it will be yet another example of superior technology being killed by a market that prefers mediocre technologies that preserve the status quo.
Most likely. Several GTK apps (Gimp, Evolution, Inkspace, notably) are better than their KDE counterparts. On the other hand, it also indicates another thing. If GTK+/GNOME apps are better, why do KDE users persist in using KDE? It's not like there is any real barrier to them switching (they run on the same platform, and are free). It most likely indicates that KDE users do not like GNOME as a platform, its lack of advanced technology, and its ultra-simplistic mindset.
Hyperthreading and dual core are two different things. Hyperthreading places no extra execution units within the same CPU core. It simply splits up the existing execution resources, and adds a few extra registers to keep track of two instruction pointers, etc. It works quite well, for what it does, which is to make better use of a CPU's existing parallel resources. It is not a replacement for SMP.
Its not a sign of GNOME's success, but an indication that GNOME has some great apps that KDE doesn't. Its actually an indication of GNOME's weaknesses as a platform. If GNOME was really comparable to KDE, the GNOME application base would have pulled them over long ago. But the sheer technical advantages of KDE make it worth it to build projects like these, to access GNOME's apps from within KDE.
It still is. We're talkling about people writing applications. Trolltech has a large list of customers, which includes many major companies. More importantly, not a single company has come forth and said they used GNOME for licensing reasons. Sun's choice of GNOME had much more to do with the fact that: a) Since GNOME 2.x was a total rewrite, they got to play a huge role in shaping it. Much of the HIG and the usability and accessibility work on GNOME was thanks to Sun. b) KDE wouldn't compile with Forte C++ (Sun's C++ compiler), which meant that no KDE apps would be developed with Forte C++, and Sun's engineers were much more comfortable with C. c) Sun's engineers were much more comfortable with existing standard technologies like CORBA, as opposed to KDE's new ones like DCOP. CORBA turned out to be more or less a failure on GNOME, but Sun didn't know that at the time.
"Sun-Gnome, IBM-Gnome(at least based on assumption that Suse and RH are it's distros), RH-Gnome, Novell-Gnome, Suse the major KDE player - Gnome"
Whoa. Neither SuSE nor Novell have comitted to GNOME. And neither has IBM. Its just Sun and RedHat. IBM is a mix of GNOME and KDE (because of RH and SuSE). And to this day, most of the major Linux desktop rollouts that have actually happend (the China rollout hasn't, yet) have been KDE.
"KDE is loosing ground in this field. Not gaining."
This is probably true. But its *very* early in the game, and it is these sorts of initiatives that could stem the tide.
"Phoenix and Thunderbird - GTK"
Neither are GTK+ apps. They use GDK to handle drawing and do fonts. They don't use any GTK+ dialogs, widgets, or any GNOME technologies.
"OpenOffice.org - Now native GTK planned for next release"
No, a GUI-independent framework is planned for next release.
"KDE release, well project is open but no one want's to do it"
I have yet to see any indication that "no one want's to do it." Hell, KDE's already ahead on this front. There is already a release that adopts OpenOffice to the native KDE theme. That's one step, anyway, ahead of OpenOffice's GTK+ support.
"Evolution - I can't remember any serious KDE mail client sorry (please no kmail)"
Kontact? KMail is a very seriousl mail client, and you provide no evidence to the contrary.
"Gimp - not Gnome but GTK it is"
This is probably the standard one. However, 2.0 has the GUI and core seperated, and a Kimp would not be out of the question.
"xmms - GTK"
XMMS is a GTK-1 app! It looks and feels nothing like a GNOME app! And KDE has many excellent media players, notably JuK and AmaroK.
"Time to smell the future, distro maybe but commercial apps are poping up"
And so far, very few of them have been based on either GTK+ *or* Qt. Most are Motif ports. And of the commercial apps that do use a modern toolkit, most of them have chosen Qt.
"btw. all this **look** hacks KDE producess, GTK look, OpenOffice look, KDE dialogs in GTK are just dust in your eyes."
Well, apparently dust works. Because GNOME has managed to convience a whole bunch of people that Mozilla and OpenOffice are GNOME apps! KDE should have done these hacks a long time ago. And note, Windows is entirely based on such **look** hacks, to make the many Windows toolkits look cohesive. Its a crappy solution, technically, but the market doesn't seem to care.
It might be simple, but its a really stupid question. This library links to the KDE libs. The KDE libs link to the Qt libs. Thus, your app links to the Qt libs. If you link to the Qt libs, then you have to follow the Qt license. We've been over this many times before.
Just because Qt forms a small piece of the used code doesn't change the licensing requirements.
This is true. When I referred to manual memory management, I was referring to malloc()/free() used like it is in most programs.
Now, there are a number of techniques that can be used to provide some of these benefits through compiler optimizations (region inference and automatic pool allocation, for example) but you are right that manual memory management will always be more efficient. The questions are: how easy is it to get efficiency to that level, how often you need that level of efficiency, and how often to people actually bother to reach optimal efficiency. The answers to those questions usually speak strongly for the benefits of GC.
and there is no such thing as private property ------ Yes, and under communism, the GPL would not be necessary, because all source would be free. Communism is not realistically implementable on a large scale, but it does have certain upsides.
Human (property) rights have never been terribly important in Asia ------ Property rights != Human rights. Property rights are critical for a quickly growing, free market economy, but there is a fundemental difference between something desireable like property rights and something absolutely necessary like human rights.
It wasn't the *right* design. If you come up with the exact perfect design every time, then yay for you. If the specifications given to you at the beginning of the project are 100% complete, and your requirements don't ever change, than you can probably get away with static typing.
99% of programmers will *not* come up with the perfect design the first time, certainly not when they are tackling a very difficult or new problems. Think about people in R&D fields. And unfortunately, in a fast-paced industry, requirements do change, and the design must be able to adapt. And in the long term, the design will certainly need to change to adapt changing requirements over the lifetime of the program.
I don't think Java or C# do this, but more advanced GC'ed languages (Lisp/ML) have advanced compiler algorithms that will stack-allocate any objects they can.
Its actually a pretty easy optimization: if a reference to a an object doesn't escape the current scope (which they can determine they usually analyze all or most of a program at the same time) then it can stack allocate the object.
First, unibody construction usually feels considerably *more* solid than the traditional two-part truck construction. It has a much greater rigidity.
Second, I think you are giving buyers far too much credit in appreciating the difference between rear-wheel and front-wheel drive. Its a rather subtle difference until you reach the limit of the front-tires' gripping ability. Most drivers, of course, do not do this. Plus, you ignore the fact that many of the cheaper SUVs that are so popular today are in fact front-wheel drive, because of the cost savings.
Well that's nice, but the technology still isn't called Hotspot. Hotspot has an optimization technique that mitigates some of the traditional disadvantages of JIT. Most modern JIT compilers work this way too. In either case,t he performance property to which I was originally referring is not specific to Sun's Hotspot VM, but characteristic of *all* JIT virtual machines.
Slashdot Mirror
SCP in the browser is something I don't want to do (command-line, always the command-line)
----------
I'm a CLI-whore too, but I don't use the CLI when I'd lose time by doing so. Having SCP supported in the file dialog is tremendously useful when you're already working in a GUI app. That way, you can save right to the remote dir, instead of saving locally, switching to a terminal, and then using scp.
Dude! I didn't know KDE did man and info! Konqueror might be the best GUI info browser out there :)
You learn something new every day!
KMail is(er.. was) possibly the worst core KDE application, IMO. I have used it pleny of times, and it always does something unexpected(deleting mail, crashes, etc.).
:) Its included in 3.2
:) The OOo situation is a bit complex. What Ximian is working on is a GTK+ version of OpenOffice's Native Widget Framework (NWF). Contrary to the name, the NWF is not a port of OOo to the native toolkit. Rather, it is a way to use the native toolkit to draw widgets for OOo. Its a cosmetic layer on top of the OOo VCL toolkit. KDE has an NWF implementation that's pretty far along as well. Of course, all of this is completely different from the new toolkit abstraction outlined in the Q Concept, which will have native ports for GTK+, Windows, Qt, and OS X.
---------
I've been using KMail since the 2.x days, and I've never had it lose email.
I also find the interface to be rather buggy and quirky.
----------
How so? KMail's interface is pretty straightforward. Folders on left, mail on top right, current message on bottom right. Toolbar buttons to compose, save, and print emails, as well as download new emails, reply and forward emails, iterate through unchecked mail, delete email, and search for emails. A lot of KDE apps are cluttered and have overly complex interfaces, but KMail is not one of them.
But what I think the other guy was getting at is that it lacks the huge number of features of most "modern" email clients.
-------------
Like? Kmail has made enormous strides over the past year, because of the Kolab/Kontact work. By the time Kontact is mature (when the Kolab work gets integrated in a few months time), Kontact will most likely be more feature-complete than Evolution.
Personally, I use mutt these days, with vim as my pager and editor(you just can't beat that).
-------------
Heh. Thanks to KParts, you can use vim in KMail too
False. Both use many GTK widgets now. Look at the buttons, text entry boxes, etc. Still not GTK menus though...
---------
You're right, I hadn't looked at a recent Firebird release. Although, its really not a GTK app. It still uses XUL as its toolkit. You can get OpenOffice to use Qt to draw its buttons/menus/etc too, but that doesn't really make it a Qt app, does it?
No, he was correct. Ximian has been working with OO.o, and they have implemented GTK for nearly the entire app(using the GUI-independent framework? I don't know... but it is there).
--------
No, I was correct
Qt is GPL'ed on Linux and Mac OS X, and a GPL'ed Qt port for Windows is about 80% complete.
This is a phenomenally useful feature. I used Kate to work on a website for school, and it was phenomenal how much more productive this is than the usual edit/upload cycle. Better yet, if I want to print a document to the central print office, I just save it to the remote ssh folder directly. If I want to save a powerpoint presentation onto my school account, I just save it there, no fussing with an FTP client.
He's right. You can change the color scheme. You can create a different gtkrc with different colors that uses the same theme engine, but thats a different theme. KDE lets you apply any color scheme to any theme.
Take a hard look at Windows apps like Office, Visual Studio, and Internet Explorer. Not only do they not look the same, but they do not behave the same. And these come from a single company!
First, that's not true. You can use any program in any window manager. Second, with these integration efforts, users probably won't even notice the difference. Certainly, most users don't notice a difference between all the Windows toolkits, even though basic applications like Office use their own toolkit.
For Novell the choice is allready made with their ownership of Ximian and Evolution.
:).
---------
They also own SuSE. SuSE is a larger company than Ximian, and have a much larger market presence (many of the big desktop rollouts so far have been KDE on SuSE). There is no reason to believe Novell will go with GNOME at this point.
And for the end user the technical differences between environments don't really matter. If the general feeling with the environment you are first provided with is good enough, you're pretty much stuck with that.
--------
I don't disagree with you, but that doesn't make it a good thing. My original point was that if GNOME wins (in its current form), it would be another example of better technology being beat by more marketable marketable technology.
You don't really want to know about your options (not if you're normal anyway
---------
Then we might as well rethink this whole capitalism thing, because capitalism is all about thinking about your options and picking the best one.
It depends on which the dominating desktop environment ends up being. If its GNOME (without a radical shift in design), then yes, it will be bad. Because it will be yet another example of superior technology being killed by a market that prefers mediocre technologies that preserve the status quo.
Most likely. Several GTK apps (Gimp, Evolution, Inkspace, notably) are better than their KDE counterparts. On the other hand, it also indicates another thing. If GTK+/GNOME apps are better, why do KDE users persist in using KDE? It's not like there is any real barrier to them switching (they run on the same platform, and are free). It most likely indicates that KDE users do not like GNOME as a platform, its lack of advanced technology, and its ultra-simplistic mindset.
57 watts for the current 2GHz G5. The new 90um G5s will use 71 watts at 3.2GHz.
Mod parent as stupid.
Hyperthreading and dual core are two different things. Hyperthreading places no extra execution units within the same CPU core. It simply splits up the existing execution resources, and adds a few extra registers to keep track of two instruction pointers, etc. It works quite well, for what it does, which is to make better use of a CPU's existing parallel resources. It is not a replacement for SMP.
Its not a sign of GNOME's success, but an indication that GNOME has some great apps that KDE doesn't. Its actually an indication of GNOME's weaknesses as a platform. If GNOME was really comparable to KDE, the GNOME application base would have pulled them over long ago. But the sheer technical advantages of KDE make it worth it to build projects like these, to access GNOME's apps from within KDE.
"Not true. It was sometimes,"
It still is. We're talkling about people writing applications. Trolltech has a large list of customers, which includes many major companies. More importantly, not a single company has come forth and said they used GNOME for licensing reasons. Sun's choice of GNOME had much more to do with the fact that:
a) Since GNOME 2.x was a total rewrite, they got to play a huge role in shaping it. Much of the HIG and the usability and accessibility work on GNOME was thanks to Sun.
b) KDE wouldn't compile with Forte C++ (Sun's C++ compiler), which meant that no KDE apps would be developed with Forte C++, and Sun's engineers were much more comfortable with C.
c) Sun's engineers were much more comfortable with existing standard technologies like CORBA, as opposed to KDE's new ones like DCOP. CORBA turned out to be more or less a failure on GNOME, but Sun didn't know that at the time.
"Sun-Gnome, IBM-Gnome(at least based on assumption that Suse and RH are it's distros), RH-Gnome, Novell-Gnome, Suse the major KDE player - Gnome"
Whoa. Neither SuSE nor Novell have comitted to GNOME. And neither has IBM. Its just Sun and RedHat. IBM is a mix of GNOME and KDE (because of RH and SuSE). And to this day, most of the major Linux desktop rollouts that have actually happend (the China rollout hasn't, yet) have been KDE.
"KDE is loosing ground in this field. Not gaining."
This is probably true. But its *very* early in the game, and it is these sorts of initiatives that could stem the tide.
"Phoenix and Thunderbird - GTK"
Neither are GTK+ apps. They use GDK to handle drawing and do fonts. They don't use any GTK+ dialogs, widgets, or any GNOME technologies.
"OpenOffice.org - Now native GTK planned for next release"
No, a GUI-independent framework is planned for next release.
"KDE release, well project is open but no one want's to do it"
I have yet to see any indication that "no one want's to do it." Hell, KDE's already ahead on this front. There is already a release that adopts OpenOffice to the native KDE theme. That's one step, anyway, ahead of OpenOffice's GTK+ support.
"Evolution - I can't remember any serious KDE mail client sorry (please no kmail)"
Kontact? KMail is a very seriousl mail client, and you provide no evidence to the contrary.
"Gimp - not Gnome but GTK it is"
This is probably the standard one. However, 2.0 has the GUI and core seperated, and a Kimp would not be out of the question.
"xmms - GTK"
XMMS is a GTK-1 app! It looks and feels nothing like a GNOME app! And KDE has many excellent media players, notably JuK and AmaroK.
"Time to smell the future, distro maybe but commercial apps are poping up"
And so far, very few of them have been based on either GTK+ *or* Qt. Most are Motif ports. And of the commercial apps that do use a modern toolkit, most of them have chosen Qt.
"btw. all this **look** hacks KDE producess, GTK look, OpenOffice look, KDE dialogs in GTK are just dust in your eyes."
Well, apparently dust works. Because GNOME has managed to convience a whole bunch of people that Mozilla and OpenOffice are GNOME apps! KDE should have done these hacks a long time ago. And note, Windows is entirely based on such **look** hacks, to make the many Windows toolkits look cohesive. Its a crappy solution, technically, but the market doesn't seem to care.
It might be simple, but its a really stupid question. This library links to the KDE libs. The KDE libs link to the Qt libs. Thus, your app links to the Qt libs. If you link to the Qt libs, then you have to follow the Qt license. We've been over this many times before.
Just because Qt forms a small piece of the used code doesn't change the licensing requirements.
That's wrong. If you license your copy of Qt under GPL, you can use it with any GPL-compatible license (BSD, MIT, etc).
Your app doesn't have to be GPL to use Qt. The GPL allows it to be BSD, MIT, etc, while the QPL just requires that it be open source.
This is true. When I referred to manual memory management, I was referring to malloc()/free() used like it is in most programs.
Now, there are a number of techniques that can be used to provide some of these benefits through compiler optimizations (region inference and automatic pool allocation, for example) but you are right that manual memory management will always be more efficient. The questions are: how easy is it to get efficiency to that level, how often you need that level of efficiency, and how often to people actually bother to reach optimal efficiency. The answers to those questions usually speak strongly for the benefits of GC.
Its not just a matter of changing class and method signatures. What about intermediate variables?
and there is no such thing as private property
------
Yes, and under communism, the GPL would not be necessary, because all source would be free. Communism is not realistically implementable on a large scale, but it does have certain upsides.
Human (property) rights have never been terribly important in Asia
------
Property rights != Human rights. Property rights are critical for a quickly growing, free market economy, but there is a fundemental difference between something desireable like property rights and something absolutely necessary like human rights.
It wasn't the *right* design. If you come up with the exact perfect design every time, then yay for you. If the specifications given to you at the beginning of the project are 100% complete, and your requirements don't ever change, than you can probably get away with static typing.
99% of programmers will *not* come up with the perfect design the first time, certainly not when they are tackling a very difficult or new problems. Think about people in R&D fields. And unfortunately, in a fast-paced industry, requirements do change, and the design must be able to adapt. And in the long term, the design will certainly need to change to adapt changing requirements over the lifetime of the program.
I don't think Java or C# do this, but more advanced GC'ed languages (Lisp/ML) have advanced compiler algorithms that will stack-allocate any objects they can.
Its actually a pretty easy optimization: if a reference to a an object doesn't escape the current scope (which they can determine they usually analyze all or most of a program at the same time) then it can stack allocate the object.
First, unibody construction usually feels considerably *more* solid than the traditional two-part truck construction. It has a much greater rigidity.
Second, I think you are giving buyers far too much credit in appreciating the difference between rear-wheel and front-wheel drive. Its a rather subtle difference until you reach the limit of the front-tires' gripping ability. Most drivers, of course, do not do this. Plus, you ignore the fact that many of the cheaper SUVs that are so popular today are in fact front-wheel drive, because of the cost savings.
Well that's nice, but the technology still isn't called Hotspot. Hotspot has an optimization technique that mitigates some of the traditional disadvantages of JIT. Most modern JIT compilers work this way too. In either case,t he performance property to which I was originally referring is not specific to Sun's Hotspot VM, but characteristic of *all* JIT virtual machines.