"Heck, can kpanels (or whatever they are) stretch across xinerama/twinview screens yet?"
no, and since screens can be different resolutions, there's no plans to do so either. this feature in kicker broke on many people's systems and gives no real benefit over a panel per screen, though it did mean more config UI.
"BTW, has KDE4 finally gotten the useful 'run command' in whatever they call kpanel now?"
the panel is part of Plasma Desktop (and it hasn't been called kpanel since KDE 1; where have you been the last 10 years?). anyways, alt+f2 does a lot more than KDE 3's "run command" ever did, including all the things you mentioned. it's also integrated into kickoff now too. there isn't a stand-alone Plasma widget that's included, though writing one shouldn't be very hard. just takes someone motivated to do so. there are a lot of things that are possible, but they all take a little bit of effort. thankfully, less effort than they did in KDE 3, but still some effort.
gwenview is the default image viewer in the KDE 4 software distribution, and the only one included as part of it. other image viewers are available as add ons as part of KDE Extra Gear.
the only time i delete comments on my blog is when someone steps over the line and starts being overtly rude, and then only after i've asked them to be constructive versus non-constructive. it had nothing to do with the idea of using multitouch (which has issues on non-multitouch devices, but anyways..).
Re:Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 3, Insightful
"I wasn't necessarily saying Vala was an app development language (although it could be)."
GNOME devs are already writing full apps with it, so it is being used as such.
"If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components?"
yes, i understand that is what has driven Vala's design and implementation. i just don't agree with the "we'll wedge another home grown language in between the C and the other languages" approach. i think it's overly complicated and limits the number of people who can (and will) hack on it.
time will tell if i'm smoking crack or not, of course.. =)
"Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code."
that is produces C is both a feature and a bug. it makes debugging much more awkward (and for a while wasn't even possible at all! how do you go from your generated C to your Vala code in gdb? there's a plugin now for gdb, but really.. oy vey!) and you lose all the interesting security possibilities of managed code.
"How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach?"
it's simply a language that is well known. pick a different well known language if you wish. make your own runtime if you wish. certainly add your own sugar on top (see QScript for a really nice example of how that can all be done with JavaScript). there's nothing particularly magical about the Vala syntax, except that it's a new language specific to one toolkit.
which is precisely my point.
"it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding."
let's do this then: let's come back to this in 2-3 years (it takes time to get these things going, i know) and see if that theory works out.
my theory is that it will just be one more baroque tool that people working with Gtk will have to get their head around (and people complained about moc with Qt; they ain't seen nothing yet;) thereby limiting the pool of candidate developers. as a non-transferable skill it won't gain much in the way of value that might cause people to learn it "just because", and yet people will write applications with it. i expect to see more and more vala usage in Gtk+/GNOME (because, well, that's already happening =) and it will cause the project to become more insular rather than less.
i do expect that those using it will get more done with vala than with plain C, but not to an extent that will make up for the number of people lost by not choosing a language syntax that is already widely known or a language that avoids compile cycles, dealing with the intricacies of C debuging, etc.
given that it's homegrown, it will also soak up resources maintaining and extending vala itself that could be put elsewhere.
combined, i expect individual efficiency of existing contributors to increase due to vala, but the overall effect on the project to be a net negative. i predict that in a few years vala will get quietly binned. bonobo 2.0 if you will: a cool idea that "just has to work, it's so well designed and advanced!" but which just didn't pan out in reality.
again, i could be wrong. and i certainly don't want to see the GNOME team falter. but vala gives me the heebie-jeebies.
"Isn't KDE4 the advanced desktop that just recently implemented the revolutionary feature of hiding panels?"
ha. ha.
yes, panel hiding was recently implemented (and with a neat hover-on-approach feature if you have a compositing window manager), but it also had a dashboard (where's that in anything not-MacOS?), multiple widget layouts on desktop, zooming and various other features you won't find most other places, or in some cases, anywhere else right now. take the whole picture in and it's a different story.
add in google gadgets, enlightenment 17 edje content support, ruby/python/javascript bindings, the krunner search plugins, the wallpaper plugins, the beautiful artwork, the general flexibility and the large number of widgets that come with it.. it's pretty compelling in 4.2 indeed.
and we have plans for much, much, much more.
as for kwin, it too has comes leaps and bounds. the number of effects have risen dramatically and the quality of the effects is quite high. the focus is on usefulness and beauty combined for kwin's effects, so you won't find the more silly effects you can in compiz, but you will find high quality, fast, functional ones. that includes the cube, cylinder and sphere as well as wobbling windows, if you're into that. =)
"but I think KDE4 has a ways to go"
check out 4.2. i don't think we have a ways to go at all, and currently about to start lapping both kde3 and the other desktop environments out there as we move on to yet further adventures =)
Re:That would be a disaster
on
Qt Becomes LGPL
·
· Score: 2, Informative
"The desktop should absolutely be configurable to the point where it could look like either GNOME or KDE"
that desktop is called "plasma". we'll be introducing layout switching for plasma in kde 4.3 letting you change between (or add to existing) layouts with the click of a button. you can already swap things about by hand, since the support for this was built into the design from the start, but making that part of the machine user accessible is kde 4.3 material.
plasma itself has no assumptions (or, really, knowledge) about what "must" be there. you can have 0, 1, 2, or N panels; any number of desktop activity layouts; even per-virtual-desktop layouts (experimental feature in 4.2; we hope to iron out the wrinkles and then expose it in the UI for 4.3)..
so.. yes. we're going there. =)
Re:Vala makes the creating widgets argument moot
on
Qt Becomes LGPL
·
· Score: 1
i think it goes a bit deeper than the language choice, and the post you are replying to is probably talking about completely custom widgets vs customizing existing ones. that customizing existing ones is already not streamlined is a bit shocking, but ok, as you say, they are working on Vala.
the problem with Vala is the same problem with any niche language: nobody knows it. yes, i know, it's C#-ish. but it's not C#, and people will have to be taught that it is "like C#" first. creating and then supporting an entire language and its runtime just to make a toolkit easy to use is, to be frank, insane.
i completely understand why people make new languages, but the reason for Vala is one of the most absurd things i have ever come across. really, GNOME should just have picked something that already existed and leveraged the developer base already familiar with it.
instead they are creating a separate silo of code called Vala that will only raise the barrier to entry due to the solution applied in an attempt to lower it.
the gnome-shell team's adoption of javascript is much more sane and well thought out. GNOME users and developers really ought to hope that the rest of project takes a cue from gnome-shell and does something similarly pragmatic on the language choice front.
Re:KDE 4 has major UI issues
on
Qt Becomes LGPL
·
· Score: 2, Informative
"rather will use it as the desktop containment"
having actually seen packages of 4.2, i can tell you that this is incorrect. i do expect *some* distros out there to do this, however. that's sort of why we have the feature there, of course. =)
"it takes time to rewrite the entire KDE project. "
just to put this into perspective, the only full rewrite is of the desktop shell. we added a lot of new library frameworks (Phonon, Solid, ThreadWeaver, Nepomuk, etc, etc.) did a massive amount of work on the existing libraries (particularly so that libkdecore doesn't require a GUI, sorted the functionality out properly so that they aren't massive globs of semi-random class collections, etc), introduced a number of new apps (akonadi, dolphin, the new printer configuration tool, numerous games, some edu apps..) and obviously ported everything to Qt4. massive, massive effort, but it wasn't technically a rewrite, with the exception of the desktop shell.
Re:Yeah but KDE doesn't work.
on
Qt Becomes LGPL
·
· Score: 1
which is why we didn't stop at 4.0 or 4.1. 4.2 brings ark back to usefulness, SSL cert config is there, etc.. i'm pretty sure i've even told you this previously on a different web board. *raises eyebrows* so let's not beat dead horses. =)
of course, we're not stopping with 4.2 either. stopping isn't in our plan at all, in fact. just better and better releases...
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
your entire post is moot, as there are high quality Python, Ruby and Java bindings for Qt and KDE. in-application scripting with JavaScript is also fairly common now as well, though that's a bit of a different topic. bindings for Perl and other languages also exist, but the Ruby and Python bindings are the ones i recommend to people doing application development.
heck, KDE even ships an app written in python (the printer manager) these days.
so whether or not C++ is a good language, not a good language, easier or harder to bind compared to C or not is neither here nor there. bindings exist for "better" (according to your metrics) languages and work damn well. use them, be happy and step off the rather irrelevant soapbox.
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
"the noteworthy long start up times of Qt apps compared to say Gtk"
take today's Qt (e.g. 4.4 or the upcoming 4.5) built with a modern c++ toolchain (e.g. something from the last year or two) and compare it with Gtk (or any other toolkit). you'll find that start up times are really not an issue anymore. if the app is starting slowly, it's not because of Qt.
"Many don't like the need for obtuse tools like SIP"
SIP is used to do bindings. unless you are making bindings, you never see or use SIP. if writing in C++, that statement about SIP becomes even more absurd.
perhaps you were thinking of moc, which adds introspection and signal/slot glue to C++ classes. that, also, is never seen. the build system handles it transparently for you.
That is factually incorrect: KDE applications can be (and are) released under a number of Free software licenses, including the BSD license, LGPL, GPL, MIT, X11, etc... you can see the licensing policy here: http://techbase.kde.org/Policies/Licensing_Policy... you can also purchase a license from Qt Software and build proprietary applications. Qt itself has quite a permissive set of license exceptions as well: http://doc.trolltech.com/4.4/license-gpl-exceptions.html
So what really changes here is people not being required to purchase a license to do proprietary development and the people in the FOSS world who felt that was such a problem that they wouldn't touch Qt can now rest easy and use it.
in 4.1 is was rather "hidden": there's a little strip at the top of the panel controller (right click on the panel -> Panel Settings, or click the toolbox button on the far right of the panel) that you can click and drag on. in 4.2 there's a nice obvious button that says "Height" (or "Width" if it's a vertical panel)
" How do I adjust its translucency"
select a Plasma theme that provides a translucent panel, which the default theme does. it requires compositing (aka "desktop effects") to be working, however.
the fake translucency in kicker was an insane hack (trust me, i did the bulk of the coding to get it to work;) and it of course wasn't perfect: it only showed your wallpaper, not windows and heaven forbid if the wallpaper was animated or anything like that.
"-- how do I give it a completely transparent background, but solid foreground?:"
use a completely transparent SVG. =) in 4.2 there is a control panel in system settings (in the Advanced area) that lets you mix and match individual SVGs should you wish to.
"Yet the KDE4 version of AmaroK doesn't yet support encoding scripts in any way, so my choice is mp3s, or no encoding at all. WTF?"
yes, there are some features missing in the first "dot-oh" release of Amarok2. there's an Amarok release coming in January that covers a lot of these (rather amazing how fast that goes, really), though i don't know if this is one of them. i do hope you've filed a feature request on bugs.kde.org.
oh, and if you're tempted to say "they should have just held 2.0 until January, then", don't bother: making releases from the code repository is an absolutely requirement to keep open source projects moving, and one of the downsides of that is that often a first release of a new series isn't what a consumer-grade user is going to what to cut their teeth on. that's why there is another step in row, e.g. distributions. not that they seem to always be doing their users the best favours lately in that regard. *shrug*
"3.5 derived a lot of its power from a very solid, well refined OLE framework, and 4.1 has yet to even approach that"
the "OLE framework" in KDE is called KParts, and the infrastructure hasn't changed one bit between KDE3 and KDE4.
"ArK does not embed into Dolphin or Konqueror in 4.1"
it doesn't embed into Dolphin, no, because that's not Dolphin's design goal. i don't have 4.1 nearby to test this on, but in 4.2 you can navigate directly into tarballs seamlessly in Konqueror.
"you cannot open most files without extracting"
currently Ark relies on KParts for previewing files without extracting. an "open with" that would extract to a temporary location and launch the app would be nice, though.
"some application shortcuts are broken if you run the application with KDE as the WM,"
which shortcuts would those be? actually, better yet, go to bugs.kde.org and report it there so it can be handled.
3.5 is the version recommended currently for production installations such as this, with 4.1 being ready for general deployment. Very large or more conservative installations will likely not move over until 4.2 (or even later) due to their usual uptake cycles for any new technology.
And perhaps when KDE4 is ready for production and you get over your bitterness, you can post a similarly frank "thank you" to the people in the project who made it possible.
~35% of the Brazillian population is under the age of 19. As for computers in Brazillian homes, that's completely irrelevant: this is about schools, not private homes.
> just look at that krunner screenshot again. What is that thing?
uh.. a composited ARGB window using an svg not designed for that since i'm waiting on the artists to finish.
that's right, you just commented on the look of a test svg and overlooked every bit of interesting tech that actually makes it possible have krunner look better than pretty much anything out there. what an idiot. oh, wait, i'm on slashdot, i forgot;)
> I haven't seen anyone saying they'd be happy with GNOME implementing OOXML > support while not sitting on the ECMA.
i have in previous conversations about this topic. so unless i'm a nobody or we're restricting the scope to just this thread, this isn't accurate =)
> Implementing something so large is not an easy process.
indeed
> Without milking out all the extra details to make life easier for the developers > this kind of job would be a very long, very annoying pain in the neck.
this doesn't require being part of an ECMA group. it's like suggesting that to implement an html renderer effectively you need to be in the appropriate w3c working groups.
> We really shouldn't be in positions where we put our volunteers in tight > spots because we're afraid "of what they might say".
i would agree; nothing i've said is in this spirit. this is about IOS committee machinations and the future of ODF and OOXML in those arenas, not what people on slashdot post in their comments.
all *that* said, this is way more of a molehill than the mountain it's become due to communication mismanagement by the various involved parties. =(
the link in the comment above explains exactly where the code was: a small bit of code in kmidi and an even smaller chunk (a few lines) of rather inconsequential code in kghostview. all of it was replaced as soon as it was noticed, none of it was intentional/malicious, and it certainly wasn't a substantial part of even a single application.
i'm guessing it's kghostview that you were thinking of when you wrote, "there was a PDF viewer or something similar that used third party GPL'd code". which, in light of the actuality of the problem, seems a little bit of an overstatement of the situation. =)
it's all moot at this point, however, with Qt freely available under the GPL and the FreeQt Foundation standing in as an additional guarantee.
Slashdot Mirror
"Heck, can kpanels (or whatever they are) stretch across xinerama/twinview screens yet?"
no, and since screens can be different resolutions, there's no plans to do so either. this feature in kicker broke on many people's systems and gives no real benefit over a panel per screen, though it did mean more config UI.
"BTW, has KDE4 finally gotten the useful 'run command' in whatever they call kpanel now?"
the panel is part of Plasma Desktop (and it hasn't been called kpanel since KDE 1; where have you been the last 10 years?). anyways, alt+f2 does a lot more than KDE 3's "run command" ever did, including all the things you mentioned. it's also integrated into kickoff now too. there isn't a stand-alone Plasma widget that's included, though writing one shouldn't be very hard. just takes someone motivated to do so. there are a lot of things that are possible, but they all take a little bit of effort. thankfully, less effort than they did in KDE 3, but still some effort.
gwenview is the default image viewer in the KDE 4 software distribution, and the only one included as part of it. other image viewers are available as add ons as part of KDE Extra Gear.
"rather than hiding this info in a tool tip on mouse over it would be nice to see it in it's own column"
you can right click on the table headers and select PID as a column. it's not shown by default, true, but it is there.
> I thought Dolphin was getting a tree view.
it did. system settings did too. just turn them on in the view options.
the only time i delete comments on my blog is when someone steps over the line and starts being overtly rude, and then only after i've asked them to be constructive versus non-constructive. it had nothing to do with the idea of using multitouch (which has issues on non-multitouch devices, but anyways..).
"I wasn't necessarily saying Vala was an app development language (although it could be)."
GNOME devs are already writing full apps with it, so it is being used as such.
"If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components?"
yes, i understand that is what has driven Vala's design and implementation. i just don't agree with the "we'll wedge another home grown language in between the C and the other languages" approach. i think it's overly complicated and limits the number of people who can (and will) hack on it.
time will tell if i'm smoking crack or not, of course .. =)
"Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code."
that is produces C is both a feature and a bug. it makes debugging much more awkward (and for a while wasn't even possible at all! how do you go from your generated C to your Vala code in gdb? there's a plugin now for gdb, but really .. oy vey!) and you lose all the interesting security possibilities of managed code.
"How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach?"
it's simply a language that is well known. pick a different well known language if you wish. make your own runtime if you wish. certainly add your own sugar on top (see QScript for a really nice example of how that can all be done with JavaScript). there's nothing particularly magical about the Vala syntax, except that it's a new language specific to one toolkit.
which is precisely my point.
"it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding."
let's do this then: let's come back to this in 2-3 years (it takes time to get these things going, i know) and see if that theory works out.
my theory is that it will just be one more baroque tool that people working with Gtk will have to get their head around (and people complained about moc with Qt; they ain't seen nothing yet ;) thereby limiting the pool of candidate developers. as a non-transferable skill it won't gain much in the way of value that might cause people to learn it "just because", and yet people will write applications with it. i expect to see more and more vala usage in Gtk+/GNOME (because, well, that's already happening =) and it will cause the project to become more insular rather than less.
i do expect that those using it will get more done with vala than with plain C, but not to an extent that will make up for the number of people lost by not choosing a language syntax that is already widely known or a language that avoids compile cycles, dealing with the intricacies of C debuging, etc.
given that it's homegrown, it will also soak up resources maintaining and extending vala itself that could be put elsewhere.
combined, i expect individual efficiency of existing contributors to increase due to vala, but the overall effect on the project to be a net negative. i predict that in a few years vala will get quietly binned. bonobo 2.0 if you will: a cool idea that "just has to work, it's so well designed and advanced!" but which just didn't pan out in reality.
again, i could be wrong. and i certainly don't want to see the GNOME team falter. but vala gives me the heebie-jeebies.
"Isn't KDE4 the advanced desktop that just recently implemented the revolutionary feature of hiding panels?"
ha. ha.
yes, panel hiding was recently implemented (and with a neat hover-on-approach feature if you have a compositing window manager), but it also had a dashboard (where's that in anything not-MacOS?), multiple widget layouts on desktop, zooming and various other features you won't find most other places, or in some cases, anywhere else right now. take the whole picture in and it's a different story.
add in google gadgets, enlightenment 17 edje content support, ruby/python/javascript bindings, the krunner search plugins, the wallpaper plugins, the beautiful artwork, the general flexibility and the large number of widgets that come with it .. it's pretty compelling in 4.2 indeed.
and we have plans for much, much, much more.
as for kwin, it too has comes leaps and bounds. the number of effects have risen dramatically and the quality of the effects is quite high. the focus is on usefulness and beauty combined for kwin's effects, so you won't find the more silly effects you can in compiz, but you will find high quality, fast, functional ones. that includes the cube, cylinder and sphere as well as wobbling windows, if you're into that. =)
"but I think KDE4 has a ways to go"
check out 4.2. i don't think we have a ways to go at all, and currently about to start lapping both kde3 and the other desktop environments out there as we move on to yet further adventures =)
afaik, in Norway trolls are traditionally lucky creatures that live in the forests. so culturally it makes more sense. ;)
similar in that they are both canvases, but not similar in functionality or scope at all. check out this blog post:
http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/
it's pretty insane. =)
"The desktop should absolutely be configurable to the point where it could look like either GNOME or KDE"
that desktop is called "plasma". we'll be introducing layout switching for plasma in kde 4.3 letting you change between (or add to existing) layouts with the click of a button. you can already swap things about by hand, since the support for this was built into the design from the start, but making that part of the machine user accessible is kde 4.3 material.
plasma itself has no assumptions (or, really, knowledge) about what "must" be there. you can have 0, 1, 2, or N panels; any number of desktop activity layouts; even per-virtual-desktop layouts (experimental feature in 4.2; we hope to iron out the wrinkles and then expose it in the UI for 4.3) ..
so .. yes. we're going there. =)
i think it goes a bit deeper than the language choice, and the post you are replying to is probably talking about completely custom widgets vs customizing existing ones. that customizing existing ones is already not streamlined is a bit shocking, but ok, as you say, they are working on Vala.
the problem with Vala is the same problem with any niche language: nobody knows it. yes, i know, it's C#-ish. but it's not C#, and people will have to be taught that it is "like C#" first. creating and then supporting an entire language and its runtime just to make a toolkit easy to use is, to be frank, insane.
i completely understand why people make new languages, but the reason for Vala is one of the most absurd things i have ever come across. really, GNOME should just have picked something that already existed and leveraged the developer base already familiar with it.
instead they are creating a separate silo of code called Vala that will only raise the barrier to entry due to the solution applied in an attempt to lower it.
the gnome-shell team's adoption of javascript is much more sane and well thought out. GNOME users and developers really ought to hope that the rest of project takes a cue from gnome-shell and does something similarly pragmatic on the language choice front.
"rather will use it as the desktop containment"
having actually seen packages of 4.2, i can tell you that this is incorrect. i do expect *some* distros out there to do this, however. that's sort of why we have the feature there, of course. =)
"it takes time to rewrite the entire KDE project. "
just to put this into perspective, the only full rewrite is of the desktop shell. we added a lot of new library frameworks (Phonon, Solid, ThreadWeaver, Nepomuk, etc, etc.) did a massive amount of work on the existing libraries (particularly so that libkdecore doesn't require a GUI, sorted the functionality out properly so that they aren't massive globs of semi-random class collections, etc), introduced a number of new apps (akonadi, dolphin, the new printer configuration tool, numerous games, some edu apps ..) and obviously ported everything to Qt4. massive, massive effort, but it wasn't technically a rewrite, with the exception of the desktop shell.
which is why we didn't stop at 4.0 or 4.1. 4.2 brings ark back to usefulness, SSL cert config is there, etc.. i'm pretty sure i've even told you this previously on a different web board. *raises eyebrows* so let's not beat dead horses. =)
of course, we're not stopping with 4.2 either. stopping isn't in our plan at all, in fact. just better and better releases ...
your entire post is moot, as there are high quality Python, Ruby and Java bindings for Qt and KDE. in-application scripting with JavaScript is also fairly common now as well, though that's a bit of a different topic. bindings for Perl and other languages also exist, but the Ruby and Python bindings are the ones i recommend to people doing application development.
heck, KDE even ships an app written in python (the printer manager) these days.
so whether or not C++ is a good language, not a good language, easier or harder to bind compared to C or not is neither here nor there. bindings exist for "better" (according to your metrics) languages and work damn well. use them, be happy and step off the rather irrelevant soapbox.
"the noteworthy long start up times of Qt apps compared to say Gtk"
take today's Qt (e.g. 4.4 or the upcoming 4.5) built with a modern c++ toolchain (e.g. something from the last year or two) and compare it with Gtk (or any other toolkit). you'll find that start up times are really not an issue anymore. if the app is starting slowly, it's not because of Qt.
"Many don't like the need for obtuse tools like SIP"
SIP is used to do bindings. unless you are making bindings, you never see or use SIP. if writing in C++, that statement about SIP becomes even more absurd.
perhaps you were thinking of moc, which adds introspection and signal/slot glue to C++ classes. that, also, is never seen. the build system handles it transparently for you.
class MyObject : public QObject ....
{
Q_OBJECT
};
is all you do.
That is factually incorrect: KDE applications can be (and are) released under a number of Free software licenses, including the BSD license, LGPL, GPL, MIT, X11, etc... you can see the licensing policy here: http://techbase.kde.org/Policies/Licensing_Policy ... you can also purchase a license from Qt Software and build proprietary applications. Qt itself has quite a permissive set of license exceptions as well: http://doc.trolltech.com/4.4/license-gpl-exceptions.html
So what really changes here is people not being required to purchase a license to do proprietary development and the people in the FOSS world who felt that was such a problem that they wouldn't touch Qt can now rest easy and use it.
"Oh, and before some idiot comes in with "hurf durf we don't want your PROPRIETAAAAAAAARY code!!!111""
the worst thing that can happen when you pre-emptively call other people idiots is showing that you're not so much better yourself in the process.
as you can see here:
http://doc.trolltech.com/4.4/license-gpl-exceptions.html
all the licenses you list are just fine, and then some. enjoy.
"KDE has no working version."
3.5 is still out there and used by millions.
"How do I make the panel thinner vertically?"
in 4.1 is was rather "hidden": there's a little strip at the top of the panel controller (right click on the panel -> Panel Settings, or click the toolbox button on the far right of the panel) that you can click and drag on. in 4.2 there's a nice obvious button that says "Height" (or "Width" if it's a vertical panel)
" How do I adjust its translucency"
select a Plasma theme that provides a translucent panel, which the default theme does. it requires compositing (aka "desktop effects") to be working, however.
the fake translucency in kicker was an insane hack (trust me, i did the bulk of the coding to get it to work ;) and it of course wasn't perfect: it only showed your wallpaper, not windows and heaven forbid if the wallpaper was animated or anything like that.
"-- how do I give it a completely transparent background, but solid foreground?:"
use a completely transparent SVG. =) in 4.2 there is a control panel in system settings (in the Advanced area) that lets you mix and match individual SVGs should you wish to.
"Yet the KDE4 version of AmaroK doesn't yet support encoding scripts in any way, so my choice is mp3s, or no encoding at all. WTF?"
yes, there are some features missing in the first "dot-oh" release of Amarok2. there's an Amarok release coming in January that covers a lot of these (rather amazing how fast that goes, really), though i don't know if this is one of them. i do hope you've filed a feature request on bugs.kde.org.
oh, and if you're tempted to say "they should have just held 2.0 until January, then", don't bother: making releases from the code repository is an absolutely requirement to keep open source projects moving, and one of the downsides of that is that often a first release of a new series isn't what a consumer-grade user is going to what to cut their teeth on. that's why there is another step in row, e.g. distributions. not that they seem to always be doing their users the best favours lately in that regard. *shrug*
"I needed to import a CA public key for use in all my KDE apps"
Konqueror -> Settings -> Configure Konqueror -> Crypto -> SSL Signers -> Import.
"That is an embarrassing oversight,"
*cough*
"3.5 derived a lot of its power from a very solid, well refined OLE framework, and 4.1 has yet to even approach that"
the "OLE framework" in KDE is called KParts, and the infrastructure hasn't changed one bit between KDE3 and KDE4.
"ArK does not embed into Dolphin or Konqueror in 4.1"
it doesn't embed into Dolphin, no, because that's not Dolphin's design goal. i don't have 4.1 nearby to test this on, but in 4.2 you can navigate directly into tarballs seamlessly in Konqueror.
"you cannot open most files without extracting"
currently Ark relies on KParts for previewing files without extracting. an "open with" that would extract to a temporary location and launch the app would be nice, though.
"some application shortcuts are broken if you run the application with KDE as the WM,"
which shortcuts would those be? actually, better yet, go to bugs.kde.org and report it there so it can be handled.
Of course they are using 3.5.
3.5 is the version recommended currently for production installations such as this, with 4.1 being ready for general deployment. Very large or more conservative installations will likely not move over until 4.2 (or even later) due to their usual uptake cycles for any new technology.
And perhaps when KDE4 is ready for production and you get over your bitterness, you can post a similarly frank "thank you" to the people in the project who made it possible.
~35% of the Brazillian population is under the age of 19. As for computers in Brazillian homes, that's completely irrelevant: this is about schools, not private homes.
> just look at that krunner screenshot again. What is that thing?
.. a composited ARGB window using an svg not designed for that since i'm waiting on the artists to finish.
;)
uh
that's right, you just commented on the look of a test svg and overlooked every bit of interesting tech that actually makes it possible have krunner look better than pretty much anything out there. what an idiot. oh, wait, i'm on slashdot, i forgot
> I haven't seen anyone saying they'd be happy with GNOME implementing OOXML
> support while not sitting on the ECMA.
i have in previous conversations about this topic. so unless i'm a nobody or we're restricting the scope to just this thread, this isn't accurate =)
> Implementing something so large is not an easy process.
indeed
> Without milking out all the extra details to make life easier for the developers
> this kind of job would be a very long, very annoying pain in the neck.
this doesn't require being part of an ECMA group. it's like suggesting that to implement an html renderer effectively you need to be in the appropriate w3c working groups.
> We really shouldn't be in positions where we put our volunteers in tight
> spots because we're afraid "of what they might say".
i would agree; nothing i've said is in this spirit. this is about IOS committee machinations and the future of ODF and OOXML in those arenas, not what people on slashdot post in their comments.
all *that* said, this is way more of a molehill than the mountain it's become due to communication mismanagement by the various involved parties. =(
yep, just another day at the office. ;)
the link in the comment above explains exactly where the code was: a small bit of code in kmidi and an even smaller chunk (a few lines) of rather inconsequential code in kghostview. all of it was replaced as soon as it was noticed, none of it was intentional/malicious, and it certainly wasn't a substantial part of even a single application.
i'm guessing it's kghostview that you were thinking of when you wrote, "there was a PDF viewer or something similar that used third party GPL'd code". which, in light of the actuality of the problem, seems a little bit of an overstatement of the situation. =)
it's all moot at this point, however, with Qt freely available under the GPL and the FreeQt Foundation standing in as an additional guarantee.