LWN.net Logo

Repositioning the KDE Brand (KDE.News)

KDE.News covers the rebranding of KDE. Essentially, the "K Desktop Environment" expansion is deprecated, KDE refers to the community and is an "umbrella brand", what is currently called a KDE release will instead be a "KDE Software Compilation" release, and so on. "In the process, KDE's identity has shifted from being simply a desktop environment to representing a global community that creates a remarkably rich body of free software targeted for use by people everywhere. [...] KDE is no longer software created by people, but people who create software. [...] To be able to communicate this clearly in our messaging, it is necessary to reposition the KDE brand so that it reflects the reality. We therefore also need distinct brands for the products we produce." KDE hacker Aaron Seigo has some thoughts as well.
(Log in to post comments)

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 0:27 UTC (Thu) by nix (subscriber, #2304) [Link]

Probability that anyone other than the release notes and the people who
thought this up will ever say 'KDE SC 4.5' rather than just 'KDE 4.5'.

You can't change established parts of language like this by decree. It
just doesn't work. Witness RMS's hopeless struggle to make everyone say
GNU/Linux: the result, after decades of effort, is that most people still
say Linux, and *everyone* who says GNU/Linux is saying it because RMS
asked them to. People who don't know who RMS is *all* say Linux. The same
will happen here.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 2:13 UTC (Thu) by aseigo (guest, #18394) [Link]

The point is that we're trying to get people to stop talking about the Software Compilation as one big lump of a thing. It's a set of components that are not tied to the hip, though they do feature good integration and consistency between each other.

There is no "KDE x.y" and there hasn't been for some time, probably since the KDE 2.0 release in fact. A by-product of the release engineering that there are such epochal releases, but they aren't "a product" that goes together.

The result is that people get confused about things like "can I use the Solid lib without the KDE workspace? What about without the rest of kdelibs?" (answer: yes, and yes) or "can I use Digikam on $OTHER_PLATFORM or do i have to use the KDE workspace?" or "I'm using $OTHER_WORKSPACE, can I use Krita?".

By making it rather purposefully awkward to talk about the epochal releases, we hope to get people talking instead in terms of the dev platform, the workspace and the app suites.

You don't have KDE 4.3. You have the KDE Plasma Desktop 4.3, or the KDE Development Framework 4.3 or Okular 0.8.80 (perhaps "from the KDE SC 4.3").

The difference between what RMS is trying to do what we're doing is this: RMS is chasing an ideological prerogative that is not shared by all in a way that is not shared by many of the people involved in what he's trying to re-brand. We're rebranding our own work, not for ideological reasons but for reasons of communication clarity, and will be communicating around that consistently ourselves going forward. It's less like RMS chasing people around saying "It's GNU/Linux!" and more like Linus, the entire kernel team and the people who distribute it saying, "You know what, this is GNU/Linux." It's a very different ballgame.

I certainly do expect that people will, for some time, use the old naming system. That's just habituation and the speed at which a meme spreads in action. We know we will have to be consistent ourselves and continue it for a prolonged period of time; and we will.

So, while not simple, it is doable and the benefits are, we feel, quite worth it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 5:18 UTC (Thu) by JoeF (subscriber, #4486) [Link]

The point is that we're trying to get people to stop talking about the Software Compilation as one big lump of a thing. It's a set of components that are not tied to the hip

Except that it's not that way.
Case in point: I have tried to get Kopete from KDE 4 working in KDE 3.5, because the recent change to the Yahoo IM login was only applied in the 4.1.3 and 4.1.2 branches. No such luck, unless I run the whole KDE 4.
Thankfully, some people (outside of KDE, as far as I know) backported the change to Kopete 0.12.7.
So, unless you actually decouple the tools for real, it is just window-dressing.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 6:54 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]

I don't know what distro you use, but you should be able to run kopete from
the 4.x series under any environment. I know most distro's had problems with
integrating kde4 apps into the standard launchers (such as the 3.5 kmenu),
but it should have worked from the command line.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 7:40 UTC (Thu) by JoeF (subscriber, #4486) [Link]

Slackware 12.2, which doesn't have KDE4. Slackware 13 has KDE4, and it didn't have KDE3 anymore, which is why I didn't upgrade. Eventually, Patrick re-added KDE3 to Slack-current/extra, I guess due to popular demand...

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:42 UTC (Thu) by aseigo (guest, #18394) [Link]

So your point was that your distribution didn't provide KDE4 packages on the version with KDE3 so you couldn't mix and match. Well, that's a distribution issue, nothing inherent in what KDE upstream does.

KDE4 apps run just fine in a KDE3 workspace and elsewhere, and vice versa.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 8:27 UTC (Thu) by wstephenson (subscriber, #14795) [Link]

The tools are decoupled from the 'full english breakfast' session. If you couldn't get KDE 4 Kopete running in a KDE 3 session, you didn't have the KDE 4 libraries installed right. It's your responsibility as a user to either use a distribution which does this for you, or inform yourself how to do it yourself correctly.

The third option, moaning that KDE tells big fat lies in the comments here, may make you feel better, but just amuses the rest of us.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 11:38 UTC (Thu) by nye (guest, #51576) [Link]

There's always the fourth option - demean and put down anyone who thinks that saying "these versions are decoupled" shouldn't imply "as long as you have the degree required to figure out how to do it".

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 13:30 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

We can't help packaging bugs. Any KDE app works anywhere if it is properly packaged. Even on win and Mac. 'KDE 3.5' doesn't influence the apps which work in there - to non-KDE-3.5 apps it acts as a mere windowmanager.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 2:45 UTC (Fri) by lysse (guest, #3190) [Link]

> We can't help packaging bugs. Any KDE app works anywhere if it is properly packaged.

Yes, but that phrase - "properly packaged" - covers a vast and growing multitude of sins. If something depends on 500 different libraries, then I'd say claiming that anyone who found it impossible to get all 500 in sync was at fault for not using a properly packaged version of that something is a huge abrogation of responsibility.

And whilst I don't use KDE - haven't for years; never really got on with it, and I'm not demanding enough of my desktops to warrant it - this is becoming an increasing problem with *everything* in the FOSS ecosystem. I've seen non-beta releases that don't even bother packaging up their in-house dependencies properly! And I'm sick of a situation that's got way, WAY worse than DLL Hell ever was, and is ludicrously worse than Windows is today - and frankly, this idea that you can shrug off any and all responsibility for not making your shit compile properly by carping "proper package!" has been a massive contributory factor.

Sorry, did you want constructive criticism? Well, here's a suggestion - if you're shipping a source package, then at least make your config/build systems capable of fetching and default-building any missing dependencies statically, automatically, within the same damned source tree! Anything less than that is just an abrogation of the responsibility of going beyond works-for-me that you implicitly accept when you seek other users for your software. Honestly, it's the software equivalent of learning that houses are not just magically tidied up by the cleaning fairy a few moments before guests arrive...

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 2:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

please name a single program which has it's build system setup to fetch the source code for all libraries that it depends on, configure them, and build them when you try to build the program

nothing does this, and there are good reasons why this is so.

do you want the developers tracking the details of all the libraries that they use, where to get them, how to configure them appropriately (for all different platforms no less), how to install them without conflicts on every distro out there, etc.

or do you want them working on improving their application and documenting that they need library X (version > y, tested up through version z) and let the users or distro maintainers pull, configure, and install the appropriate libraries?

personally, I want the developers to work on their own app.

kdesvn-build

Posted Nov 27, 2009 3:44 UTC (Fri) by sbishop (guest, #33061) [Link]

please name a single program which has it's build system setup to fetch the source code for all libraries that it depends on, configure them, and build them when you try to build the program

KDE, funny enough: http://kdesvn- build.kde.org/. I've used it on old RHEL systems to build a decent, up- to-date KDE. It was nice to have everything taken care of for me.

kdesvn-build

Posted Nov 27, 2009 4:50 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

WOW, you mean that it will fetch the code for glibc and compile it if the development packages are not already installed on the system? what about PAM libraries?

I suspect that the most it did was to grab other KDE specific libraries.

kdesvn-build

Posted Nov 29, 2009 18:17 UTC (Sun) by sbishop (guest, #33061) [Link]

glibc and PAM, huh? Well, you need to be careful. If you have the script handle the user-space component of your operating system, it must, of course, handle the kernel-space component as well. You will, if I remember right, end up running FreeBSD. (It's pretty popular with the KDE devs.)

Typically, however, kdesvn-build will only build and install Qt, taglib, CMake, and QCA, among others.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 3:14 UTC (Fri) by foom (subscriber, #14868) [Link]

> Honestly, it's the software equivalent of learning that houses are not just magically tidied
> up by the cleaning fairy a few moments before guests arrive...

My software house *is* magically tidied up -- Debian unstable or experimental generally has recent
enough versions of any library I need that I'm usually just an apt-get install away from having the
prerequisites for compiling other software of interest.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 7:00 UTC (Fri) by nix (subscriber, #2304) [Link]

You want everything's build systems to learn how to autobuild glibc for
you if your version is too old?! If not that, then where do you stop?

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 13:02 UTC (Fri) by lysse (guest, #3190) [Link]

The thing about rants (well, mine anyway) is that they're (a) born of deep
frustration, and (b) not necessarily 100% thought through, especially when
it comes to solutions.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 18:36 UTC (Thu) by JoeF (subscriber, #4486) [Link]

Right, I didn't have the KDE4 libraries installed "right" because I didn't have them installed, period.
That's the lack of decoupling right there. You essentially have to have the whole KDE4 installed because the bulk of KDE _are_ the libraries. Thanks for making my point.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:20 UTC (Thu) by yokem_55 (subscriber, #10498) [Link]

Um no. Kdelibs does not include things that make up the full desktop shell
like plasma, kwin, dolphin, konqueror, kate, etc. Most distros have no
problem installing both kdelibs3 and kdelibs4, thus making it easy to pull
in kde4 apps into the kde3 desktop shell.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:48 UTC (Thu) by JoeF (subscriber, #4486) [Link]

Yes, but not all distros have the kde4 libs.
_That's_ the issue. Decoupling means I can download a kopete package, and it runs. I shouldn't have to go and download or compile the whole kdelibs, kdepimlibs and kde-support stuff, with all the dependencies that entails (boost, etc. etc.) That's what I had to do to get things working. And that's certainly _not_ what "decoupling" means.
The competition, e.g., Pidgin, works without all that cruft.
I only went through all this because I don't particularly like Pidgin. Others with a lower pain threshold would probably have given up.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 20:02 UTC (Thu) by dkite (guest, #4577) [Link]

>Decoupling means I can download a kopete package, and it runs. I shouldn't
have to go and download or compile the whole kdelibs, kdepimlibs and kde-
support stuff, with all the dependencies that entails (boost, etc. etc.)

Are you suggesting that
1. developers encourage static linking, or
2. developers roll their own when it comes to, I dunno, C++ libraries,
contact information server, graphics primitives, icon and configuration
handling, etc.?

Try building something like gnucash. Same issue. I would rather the
developers use existing libraries. There are two benefits that come to
mind, first the developers will have more time to add features to their
application, and the libraries will be tested and improved for everyone
else.

This isn't a KDE issue.

Derek

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 21:44 UTC (Thu) by JoeF (subscriber, #4486) [Link]

It is about minimizing the dependencies. Kopete probably only uses a small fraction of the stuff in kdelibs.
And if it was packaged on its own, like pidgin, it would have to have the required libraries and _only_ the required libraries with it.
That doesn't mean that it has to be statically linked. That's a non-sequitur.
In fact, I was rather surprised that kopete wasn't a separate download. It for sure isn't a core component or KDE, so why in the world would it only be available as bundle with all the other kde stuff? Even in kdenetwork, there is a whole bunch of stuff in there that has nothing at all to do with each other, except that it is somehow network-related.

And again, the whole issue is not about kopete per se, but about the fact that at this point, there isn't all that much decoupling, making the name change stuff just some marketing BS.
What they should have done is actually _do_ the decoupling, and _then_ announce it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 22:20 UTC (Thu) by aseigo (guest, #18394) [Link]

"Kopete probably only uses a small fraction of the stuff in kdelibs.
And if it was packaged on its own, like pidgin, it would have to have the required libraries and _only_ the required libraries with it."

This is what most distributions offer, in fact. Exactly, and precisely.

"In fact, I was rather surprised that kopete wasn't a separate download. It for sure isn't a core component or KDE, so why in the world would it only be available as bundle with all the other kde stuff?"

Good question; we offer the source code for those who would like to build it. Most of our users get it from our distributors, in your case that's Slackware. For those who decide to grab the sources and build, we've found that people appreciate being able to grab a representative "basic set" of tools for a given topic. For more advanced tools or vertical applications, we put those in Extragear and they are, indeed, shipped completely on their own.

Each item in the package that Kopete is in is buildable separately, however. You can configure the top level module and then simply cd into the kopete directory and build it from there. You don't need to build or install anything else in the KDE Network module / basic application set. The bundling of the sources is simply a convenience, one many of our from-source users appreciate.

However, many KDE distributors (most, in fact) split those packages up into smaller chunks, so that Kopete, for instance, appears on its own. Let me give you a practical example from OpenSUSE:

independence:~ # zypper search kopete
Loading repository data...
Reading installed packages...

S | Name | Summary | Type
--+--------------------------------------+--------------------------------------------------------+-----------
| kde4-kopete | Instant Messenger | package
| kde4-kopete-devel | Instant Messenger - Development Files | package
| kopete | Instant Messenger | package
| kopete-devel | Instant Messenger - Development Files | package
| kopete-protocol-facebook | Facebook Protocol Support for Kopete | srcpackage
| kopete-protocol-facebook | Facebook Protocol Support for Kopete | package
| kopete-protocol-facebook-debuginfo | Debug information for package kopete-protocol-facebook | package
| kopete-protocol-facebook-debugsource | Debug sources for package kopete-protocol-facebook | package

As you can see, there is both Kopete built using the 3 and 4 versions of the KDE dev platform. Even one of the protocols (facebook) is broken out into its own package in this case. I can install one or all of those packages and everything is handled for me. If I wanted the version of Kopete from KDE SC 4.3 but I was using the KDE 3 desktop, I could just do "zypper install kde4-kopete" and Kopete along with the needed libraries would be installed (and nothing else; not the rest of kdenetork, not the KDE Plasma Desktop .. just the KDE 4 Dev Platform and other libraries that Kopete may use). I can even install the development headers so I can build third party plugins for Kopete from sources if I wish.

KDE makes this possible by ensuring that the apps in the main modules are buildable separately and by shipping all the non-"basic set" applications individually from Extragear. Distributors make this possible by making sound decisions for their end users.

Not all distributors will package things this way, of course, and that's one of the things about freedom: different people will do it different ways according to their needs, and those needs may not be yours. If Slackware doesn't package things the way you need them to then use someone else as your KDE distributor. (I know many people for whom Slackware does it "just right", so this isn't a slam on Slackware in any way. :)

None of this has anything, whatsoever, to do with the KDE rebranding, other than that the rebranding makes the KDE communication match the reality of what actually happens. e.g. Kopete available separately from the Plasma Workspace.

(As a thought experiment, how do you think it works on MacOS or Windows? :)

"What they should have done is actually _do_ the decoupling, and _then_ announce it."

Can we agree on this: let's ensure you have all your facts straight, and THEN let's hear what you think we should do? That seems to be the logical, not to mention the responsible, way to go about this.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 6:22 UTC (Mon) by JoeF (subscriber, #4486) [Link]

For those who decide to grab the sources and build, we've found that people appreciate being able to grab a representative "basic set" of tools for a given topic.
Well, then count me as one who doesn't appreciate that. I'd like to be able to just grab the sources I need to compile and run one program, e.g., kopete.

Can we agree on this: let's ensure you have all your facts straight, and THEN let's hear what you think we should do? That seems to be the logical, not to mention the responsible, way to go about this.
If you try to insinuate that I don't have my facts right, try better next time. Insulting your users is never a good way to go about things.
I have wasted enough time to just get this whole kopete for KDE4 running just because KDE3 has become abandonware.
If you want a constructive answer, the logical way would be to continue to support KDE3 at least for some time and not let people who, for whatever reason, are not ready to switch to kde4 yet, standing in the rain. That, in my opinion, is more important than some pie-in-the-sky, marketing-driven rebranding.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 15:36 UTC (Mon) by foom (subscriber, #14868) [Link]

Your problem appears to be with the source code layout of KDE, something that, quite frankly, doesn't matter for 99% of users. So it's rather silly to hear you complain so vociferously that their marketing is incorrect, when you're probably one of the only people in the world who both 1) builds from source 2) cares how big it is.

If you find compiling from source that horrendous, I'd recommend using a package manager to install your software, where the libraries and apps have already been split off into individual pieces. And let the KDE people lay out their source code however they find easiest for *development*.

Repositioning the KDE Brand -- v-- Build from source

Posted Dec 3, 2009 20:39 UTC (Thu) by brianomahoney (subscriber, #6206) [Link]

No, once again nonsense:

What I am really tired of is the 3-4 major sub-projects that an Open-Source distribution depends on eg: (1) KDE (2) Mozilla (3) OOO (4) Java/Mono which seem unable to (a) package their source, (b) provide a convenient build system, (c) list dependancies realistically.

I am all for innovation but do we really need UNDOCUMENTED uses of autoX, libtool, cmake, ant, python 'pyXXX' and many more ... all of which don't come outr of a SVN or GIT download and neet to be stitched together by hand with pre, co and postrequisites before you can say 'make' or whatever?

NO, this is sloppy junk, and BTW Google should stop adding to this mess with Chrome and Android.

Repositioning the KDE Brand -- v-- Build from source

Posted Dec 4, 2009 1:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, for KDE and Mozilla your points are wholly baseless.

The build system for Mozilla is a pretty boring Autoconf/Automake thing,
and has some (rather out of date) documentation. The build system for KDE
4 has lots and lots of docs (let's ignore the brittle KDE3
edge-of-the-Autoconf-world build system, it's dead).

The cmake and autoconf-driven build systems of Mzilla and KDE4 are
definitely convenient: fire and forget, literally. (Mozilla's problem here
is that a lot of its configure flags actually break the system if you turn
them on: I don't know why they're available. But the defaults work. KDE
doesn't have this problem.)

My autobuilder scripts for both KDE and Mozilla are less than two dozen
lines. (Of course this excludes the parts that do the ordinary boring
configure && make && make install stuff that most packages need. This is
KDE/Mozilla-specific stuff). So the build system is definitely not much
less conveneint than that of other packages.

Both Mozilla and KDE list their dependencies: KDE does so, again, to an
almost insane length. If you can't find it (three whole clicks from the
KDE front page) and can't work out the deps by consulting the source, you
probably shouldn't be trying to build directly from the VCS.

Your belief that generated files like configure scripts et al should be
stored in version control systems disagrees with that of everyone working
on free software projects I've ever talked to, and betrays a definite lack
of experience in the area. Generated files should not, ever, go into
VCSes, even if it adds dependencies: only the developers need such
dependencies, and the generated files will rapidly lead yo into conflict
hell.

Now, OOo is a sodding nightmare, I'll agree with that. Any project that
ends up producing forks just to fix the *build system* is in a bad way.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 18:46 UTC (Thu) by JoeF (subscriber, #4486) [Link]

The third option, moaning that KDE tells big fat lies in the comments here, may make you feel better, but just amuses the rest of us.

Decoupling means being able to run kopete without installing all the rest of KDE4.
Heck, pidgin can run on KDE3 just fine. Why can't the latest kopete? The answer is: because it is tightly coupled to KDE4.
No amount of arrogant posts changes the fact that at this point, the "decoupling" is indeed a "big fat lie." It is PHB-style marketing BS.
Get your act together and release a stand-alone kopete that runs on KDE3. _Then_ you would have a point.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:50 UTC (Thu) by aseigo (guest, #18394) [Link]

That's like asking for the KDE3 version of Kopete to run without KDE3's libraries, e.g. make it run with KDE1's libraries. Well, that's an impossibility.

However you can install just the KDE Dev Platform 4 libraries and runtime (something not easily achieved with KDE3, btw; we made this much easier by purposefully reorganizing parts of our source tree for the 4.x releases). This makes it no different in any way to any other application out there that uses shared libraries.

The libraries are, btw, less than 10% of the code of the overall KDE codebase.

"The answer is: because it is tightly coupled to KDE4."

That is factually incorrect. It only uses the 4.x libraries and is not tightly coupled to any other part of KDE's software outside of that. It isn't tightly coupled to other KDE appications and has no coupling at all to any KDE workspace (or non-KDE workspace, for that matter).

"Get your act together and release a stand-alone kopete that runs on KDE3."

The version of Kopete that comes with the 4.x series does run in the KDE3 workspace and aside other KDE3 apps just fine as long as you have the 4.x libs (and that's all!) installed; we also released a KDE3 version of Kopete, though that is no longer developed further. You are free to do so.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 21:56 UTC (Thu) by JoeF (subscriber, #4486) [Link]

The version of Kopete that comes with the 4.x series does run in the KDE3 workspace and aside other KDE3 apps just fine as long as you have the 4.x libs (and that's all!) installed

So, you essentially confirm that there is no decoupling at this point.

we also released a KDE3 version of Kopete, though that is no longer developed further. You are free to do so.

I've found the patches to get the Yahoo login working for kopete 0.12.7, and I am using that now, thank you very much.

But again, the whole issue is not about any particular program per se. The issue is that your announcement of decoupling is nothing more than basically meaningless marketing hogwash at this point.
I hope you add some meat, i.e., actually _do_ the decoupling you talk about.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 22:28 UTC (Thu) by aseigo (guest, #18394) [Link]

"So, you essentially confirm that there is no decoupling at this point."

No; you're evidently asking for Kopete not to use any libraries. That's not how software works.

What we're saying is that there is a development platform, workspaces and applications. The applications and workspaces use the dev platform, but applications and workspaces do not rely on each other.

As I explained above (the comment containing the example using Zypper) you can quite easily see this in action.

"I've found the patches to get the Yahoo login working for kopete 0.12.7, and I am using that now, thank you very much."

Great! :)

"The issue is that your announcement of decoupling is nothing more than basically meaningless marketing hogwash at this point."

The announcement is completely accurate. The decoupling talked about in the announcement is not at all what you are looking for (applications 'magically' using libraries they haven't been written for; in such a world the GIMP could use Qt and MS Office would run on Linux natively). From what we can gather from your previous comments you have some deep misconceptions about how things are put together within KDE's software. To be frank, that is something we do take part of the blame for: we have not been very clear in how we communicate "how things actually get put together" and so people end up with all sorts of odd ideas. This rebranding is one piece in the overall solution for that happening to people in the future.

But to reiterate: apps are not tied to the workspace; they are not tied to each other; they do depend on the development platform (which is the entire point of the dev platform, of course), but that is a relatively thin layer of libraries (relative to the bulk of applications above and software infrastructure below). This is exactly what the announcement tries to make clear, and this is exactly how it's been since at least KDE 3.0 if not even earlier. (IOW, this isn't even a "KDE4" thing)

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 6:30 UTC (Mon) by JoeF (subscriber, #4486) [Link]

No; you're evidently asking for Kopete not to use any libraries. That's not how software works.
I know very well how software works, I develop software myself.
But, I would not have my users jump through the amount of hoops that you apparently think is ok.
And I don't think I have misconceptions about how KDE works. I understand very well that kopete, for example, relies on certain libraries. But I don't think it relies on most of the libraries that need to be compiled in kdelibs. And it certainly doesn't need all the things in kdenetworks.
And I have a certain understanding of the word "decoupling", based on the English dictionary definition. It seems to me that the KDE people use a different definition.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 0:54 UTC (Fri) by malor (subscriber, #2973) [Link]

I have no dog in this race, and while I suspect this 'branding' idea is going to fail for the simple reason that it's too complex, I do want to show the output from Debian Lenny, coming from a server that's not presently running X Windows:

apt-cache show kopete
[snip]
Source: kdenetwork
Version: 4:3.5.10-2
Replaces: konversation (<= 0.14.0-4), sim (<= 0.9.3-2)
Depends: kdelibs4c2a (>= 4:3.5.9), libc6 (>= 2.7-1), libgadu3 (>= 1:1.8.0+r592), libgcc1 (>= 1:4.1.1), libglib2.0-0 (>= 2.12.0), libgsmme1c2a (>= 1.10), libidn11 (>= 0.5.18), libmeanwhile1 (>= 1.0.2), libqt3-mt (>= 3:3.3.8b), libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.27), libxrender1, libxslt1.1 (>= 1.1.18)
Recommends: qca-tls
Suggests: kdeartwork-emoticons, khelpcenter, imagemagick, gnupg, ekiga

I did an 'aptitude install kopete', just to see what would be installed:

The following NEW packages will be installed:
aspell{a} aspell-en{a} dbus{a} dbus-x11{a} dictionaries-common{a} esound-clients{a} esound-common{a} fam{a} hicolor-icon-theme{a} kdelibs-data{a} kdelibs4c2a{a} kopete libakode2{a} libart-2.0-2{a} libarts1-akode{a} libarts1c2a{a} libartsc0{a} libasound2{a} libaspell15{a} libaudiofile0{a} libavahi-client3{a} libavahi-common-data{a} libavahi-common3{a} libavahi-qt3-1{a} libavc1394-0{a} libdbus-1-3{a} libesd0{a} libfam0{a} libfreebob0{a} libgadu3{a} libgsmme1c2a{a} libiec61883-0{a} libilmbase6{a} libjack0{a} libjasper1{a} liblua50{a} liblualib50{a} libmad0{a} libmeanwhile1{a} libopenexr6{a} libraw1394-8{a} libsamplerate0{a} libspeex1{a} libtiff4{a} libvorbis0a{a} libvorbisfile3{a} libxaw7{a} libxpm4{a} libxslt1.1{a} libxtrap6{a} libxxf86misc1{a} menu-xdg{a} oss-compat{a} portmap{a} qca-tls{a} x11-xserver-utils{a}

That's not a completely trivial list, and it'll use 137 megs on disk to run, but that's not even vaguely the whole KDE4 distro. It looks like it's just grabbing the libs, and that whatever distro you're using has done a poorer job of packaging.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 8:11 UTC (Mon) by JoeF (subscriber, #4486) [Link]

Thanks for actually making my point.
137MB for an f-ing IM client??? Give me a break.
That's Microsoft-style bloatware.
If kopete really needs 137MB of disk space to run, something is seriously wrong with it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 9:31 UTC (Mon) by mpr22 (subscriber, #60784) [Link]

Two points.

  1. By the looks of it, malor's system doesn't have any existing software using X11 or audio.
  2. aptitude appears to have been configured to install Recommends: items by default.

Repositioning the KDE Brand (KDE.News)

Posted Dec 1, 2009 5:44 UTC (Tue) by malor (subscriber, #2973) [Link]

Did you actually read the list of required dependencies? This is on a fairly minimal server without X Windows, so getting all the dependencies installed requires a great deal more than it would on a server with X already on it.

If you look at the direct depends carefully, most of them are very basic libraries for sound and graphics, as well as a couple for talking on specific IM networks. The only two that are directly KDE-related appear to be kdelibs4c2a and libqt3-mt. kdelibs is about 10 megs, libqt3 is about 3.5, and kopete itself is 8 megs. So it's a total KDE-related footprint of about 21 or 22 megs, which is maybe a little high, but considering you're getting the QT and KDE libraries with it, not at all unreasonable. The rest of the dependencies are really basic things that you'd usually have installed if you were on X Windows, even if you don't have KDE at all.

Ubuntu is quite different; they've put a TON of dependencies on kopete, and even starting from X, you'll end up with an extra 215 megs of stuff. So the clean packaging is quite clearly optional. I presume that they've compiled more features into Ubuntu kopete, but I don't know that for sure.

Basically, it looks to me like the KDE claims of fairly strong differentiation between the desktop environment and basic requirements to run individual pieces of software are quite accurate. If I just 'aptitude install kde', it'll take 1,139 megs.

As a point of comparison, in a quick search, I don't see any GNOME applications that do the multi-network connection. GnomeICU does ICQ only, and takes 111 megs with dependencies.

For context: 'aptitude install gnome' requires 1,587.

Repositioning the KDE Brand (KDE.News)

Posted Dec 10, 2009 11:13 UTC (Thu) by Cato (subscriber, #7643) [Link]

Kopete from KDE 4.3.1 does work alongside KDE 3.5.10 - I built a version that included the fix for Yahoo authentication and it ran fine, but I had to take care to use a completely separate directory tree such as /opt/kde4local that would not be used by KDE 3.5.

Unfortunately this didn't work with any emoticons which were essential for the person I was doing this for, so I ended up switching to Google Talk, which uses Jabber and worked fine with KDE 3.5.10's Kopete. Since Jabber is an open standard this sort of problem should not recur.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 10:35 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

aseigo wrote:
[P]eople get confused about things like [...] "can I use Digikam on $OTHER_PLATFORM or do i have to use the KDE workspace?"

Just after I mused in the "Giving up the GIMP..." article comments about using Digikam in Gnome...

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 20:04 UTC (Thu) by aseigo (guest, #18394) [Link]

hehe; syncronicity at work, my friend! ;)

and yes, as people consider those kinds of things already, very naturally, we figured it was time our communication matched that reality and even helped it along rather than pretend that's not how it is.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 8:25 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

Just out of interest (and as I am sadly not a DE specialist), what does Digikam (probably...) depend on the KDE libraries for? Excluding Qt of course, as it is clear what it uses that for. I'm just wondering how much would need to be changed for it to use the Gnome libraries in combination with Qt instead of KDElibs and Qt. As a configuration option of course :) (Or even better, cross-DE wrapper libraries.)

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 12:49 UTC (Fri) by krake (subscriber, #55996) [Link]

I am not a Digikam expert either, but the usual suspects are things like
config framework [1], I/O framework (for remote access and maybe thumbnail
creation), plugin discovery [2], hardware access [3] (e.g. detection of
cameras), metadata framework, semantic data integration (e.g. rating,
tagging).

> Or even better, cross-DE wrapper libraries.

Fun fact is that the KDE libraries are often such wrapper libraries,
letting the application developer use functionality despite that being
implemented differently on different platforms.

[1] http://techbase.kde.org/Development/Tutorials/Using_KConf...
[2]
http://techbase.kde.org/Development/Tutorials#Services:_A...
[3]
http://techbase.kde.org/Development/Tutorials#Hardware_Aw....

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 13:01 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

> Fun fact is that the KDE libraries are often such wrapper libraries
Ahem, yes, as in what Aaron was actually saying (maybe I should read the comments I reply to better?). So perhaps all that would be needed would be a bit of work to reduce the size of the dependency (230MB in Ubuntu Karmic IIRC).

Repositioning the KDE Brand (KDE.News)

Posted Nov 28, 2009 15:33 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

so much? that's crazy, you can get a basic kopete upon kde-libs including
all dependencies AND Xorg AND drivers, as can be seen a little up in this
thread, for about 130 MB! Something is wrong in ubuntu, unless you wanted to
install all of the KDE software compilation...

Repositioning the KDE Brand (KDE.News)

Posted Nov 28, 2009 18:56 UTC (Sat) by michaeljt (subscriber, #39183) [Link]

The following is Ubuntu's take on digikam. Without the --no-install-recommends, it also pulls in dolphin, khelpcenter and (via kipi-plugins) konqueror, adding another 35Mb when all is said and done. As I said, work might be needed to clean up the dependencies :) I don't think that they have seriously considered using KDE software components without KDE as a whole yet.

$ sudo apt-get install digikam --no-install-recommends
[...]
Suggested packages:
digikam-doc kdebase djvulibre-bin akonadi-server gxine xine-ui libxine1-doc
libxine-doc libxine1-ffmpeg
Recommended packages:
dolphin kipi-plugins khelpcenter4 exiv2
The following NEW packages will be installed:
digikam kde-icons-oxygen kdebase-runtime kdebase-runtime-bin-kde4
kdebase-runtime-data kdebase-runtime-data-common kdelibs-bin kdelibs5
kdelibs5-data kdepimlibs-data kdepimlibs5 libakonadiprivate1
libboost-program-options1.38.0 libclucene0ldbl libexiv2-5 libkdcraw7
libkexiv2-7 libkipi6 libknotificationitem1 liblensfun-data liblensfun0
liblzma0 libmarble4 libplasma3 libsoprano4 libstreamanalyzer0 libstreams0
libxcb-shape0 libxcb-shm0 libxcb-xv0 libxine1 libxine1-bin libxine1-console
libxine1-misc-plugins libxine1-x marble-data phonon-backend-xine
soprano-daemon
0 upgraded, 38 newly installed, 0 to remove and 0 not upgraded.
Need to get 62.1MB of archives.
After this operation, 196MB of additional disk space will be used.

Repositioning the KDE Brand (KDE.News)

Posted Nov 29, 2009 8:42 UTC (Sun) by jospoortvliet (subscriber, #33164) [Link]

yes, there are certainly a few things there which aren't needed. And there
is a lot there which isn't part of the KDE platform but part of the lower
stack. Xine, soprano, libexiv, boost and Akonadi come to mind.

But anyway - I don't see why any of this makes digikam any less standing on
its own? Ok, installing dolphin or any other graphical application is silly,
but that's recommended, not required. The libs makes sense - and you only
have to install them once. It's not like the diskspace is gonna hurt
anyone... Digikam uses marble for geolocation, soprano for tagging and
rating, might use akonadi soon for storing the actual images. And each has
his own dependencies too... With functionality come dependencies. Or a huge,
unmaintainable codebase because you have a strong NIH attitude (eg Firefox,
OpenOffice)

Repositioning the KDE Brand (KDE.News)

Posted Nov 29, 2009 9:49 UTC (Sun) by michaeljt (subscriber, #39183) [Link]

> But anyway - I don't see why any of this makes digikam any less standing on its own?

My question is more whether the Ubuntu package of Digikam (subtle difference there!) stands on its own. And the discussion of reducing the total dependency size (and that didn't include Qt either, which I have installed for VirtualBox) comes from the original idea that Digikam might be a good alternative to F-Spot, with its Mono dependency (both large in megabytes and charged politically) in the default Ubuntu install. In this context it does make sense to keep the size in megabytes of the Digikam dependencies as small as they can reasonably be.

It is not definitely not NIH - although to tell the truth, I don't think that it is NIH in the cases of Firefox and Oo.o either; they just both arrived from the proprietary world, where you don't have the luxury of FOSS-style dependencies.

Repositioning the KDE Brand (KDE.News)

Posted Nov 29, 2009 10:13 UTC (Sun) by jospoortvliet (subscriber, #33164) [Link]

Well, the dependencies are big if you don't run anything yet. The KDE
Platform IS big, offers a lot of features. Digikam does. I guess that is
indeed a disadvantage, having a 3.5 mb download would be better. But it's
not a huge issue, right?

I can see why somebody wouldn't want to use F-spot - mono being evil (or
not) and all. And having the slowness due to an interpreted language etc (or
not, again, it's up for debate). Of course I'd rather see ppl who want to
use Digikam and other KDE apps because they're good ;-)

I just hope the dependencies aren't a real reason not to use digikam or
other KDE apps. I think for normal users they're not, as the won't even see
the libs being downloaded. As long as it is reasonably properly packaged (eg
doesn't include dolphin) things should be OK.

Repositioning the KDE Brand (KDE.News)

Posted Nov 29, 2009 21:32 UTC (Sun) by michaeljt (subscriber, #39183) [Link]

> Of course I'd rather see ppl who want to use Digikam and other KDE apps because they're good ;-)
See http://brainstorm.ubuntu.com/idea/22708/ for my attempt at getting something moving here. Feel free to promote it a bit and pass the link around to like-minded people if you like it (or tell me why not if you don't :). I think it would be great if good applications were not held back by being associated with the "other desktop", and I think this would be a good chance to break down some of the walls in people's minds.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 17:25 UTC (Thu) by nix (subscriber, #2304) [Link]

There is no "KDE x.y" and there hasn't been for some time, probably since the KDE 2.0 release in fact. A by-product of the release engineering that there are such epochal releases, but they aren't "a product" that goes together.
I dunno. I compare KDE to GNOME, and KDE is a helluva lot more an integrated entity than GNOME ever is. It's got a working component framework, a vast collection of libraries, a common code style (pretty much), an integrated version control system (modulo the amarok experiment), a similar naming style, common user interface guidelines, relatively few very large modules at the source control level, built as a single lump...

... seems pretty much like a single thing to me. Yes, you can install parts of it, but how common *is* that? Probably either people install one KDE app they particularly like, or they install the whole lot because they run the KDE desktop that you're trying to say doesn't exist, plasma and all.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 17:56 UTC (Thu) by foom (subscriber, #14868) [Link]

I use a GNOME desktop (not really sure why, just used to it), but mostly KDE applications, because
they're less crashtastic, and more functional (e.g. konsole instead of gnome-terminal -- no contest
there!).

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 20:00 UTC (Thu) by aseigo (guest, #18394) [Link]

"KDE is a helluva lot more an integrated entity than GNOME ever is."

Integrated, yes, but not tightly coupled. The integration that is a definite feature and benefit of using multiple pieces of KDE software with each other gets confused with tight coupling, which is a state where you can't reasonably pull the pieces apart.

With KDE's software, you can run the various workspaces and applications independently from each other. There is user experience and even feature benefit from running them together, but even separate they work very well. We've also paid a lot of attention to getting our apps to work well in other workspaces, such as how the buttons change order in dialogs when run in a KDE, GNOME, MacOS or MS Windows workspace, or how we can now use the native file and print dialogs.

So, yes, integration is there. It's a great feature. We do recommend people take advantage of that by running lots of KDE software titles together ... but it's not a requirement.

"you can install parts of it, but how common *is* that?"

Very common, actually. On Linux, many people who use a GNOME workspace shell also use KDE apps like Amarok, K3B, Konqueror, Dolphin and Digikam.

"Probably either people install one KDE app they particularly like"

Exactly, and we're trying to help increase the occurrence of that by raising awareness that things are not tightly coupled and that the libraries underneath are also highly portable and modular themselves.

"the KDE desktop that you're trying to say doesn't exist, plasma and all. "

We're not saying that there is no such thing as a KDE desktop. We're saying that it's simply not the only thing we do, nor is it the most important thing we do (it's equally important, but not more). The KDE Plasma Desktop (and, for that matter, KDE Plasma Netbook) do indeed exist and you do indeed get a better experience running other KDE applications when you use a KDE workspace (file dialog, configuration and other basic feature consistency, for instance).

We're not saying it doesn't exist, we're simply saying that it's not the only configuration and that you can most definitely go ala cart if you wish, as many already do.

Instead of thinking of it as a binary operation (there is or there isn't a desktop) think of it as a system that integrates well as you bring the pieces together but where none the pieces *require* the others with the exception of the base libraries. This makes it more of a rainbow than a black and white situation, and that is something that appeals to a far wider audience.

We very, very happy when someone uses all of KDE's software and we will continue to encourage that "whole enchilada" approach. For those who that isn't appealing, though, we'd rather see them use at least some of our software than none of it, especially as that is already possible right now and works very well.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 22:02 UTC (Thu) by JoeF (subscriber, #4486) [Link]

"Probably either people install one KDE app they particularly like"

Exactly, and we're trying to help increase the occurrence of that by raising awareness that things are not tightly coupled and that the libraries underneath are also highly portable and modular themselves.

That's what I would like to see. But right now, that doesn't seem possible in at least some cases (see kopete.)
So, is kde going to separate the apps out more? Or are you relying on downstream to do that?

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 2:52 UTC (Thu) by xorbe (subscriber, #3165) [Link]

if ya can't fix it, re-brand and re-market it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 11:16 UTC (Thu) by sebas (subscriber, #51660) [Link]

Except that this re-branding is not about a change in conception, but about making our communication be more in line with how the software actually looks like and works. Your comment sounds more like trying a cheap shot instead of showing that you got it. Bummer.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 11:43 UTC (Thu) by nye (guest, #51576) [Link]

>Your comment sounds more like trying a cheap shot instead of showing that you got it. Bummer.

Relatively few people are going to 'get it', because it's indistinguishable from the kind of cheap marketing tactics we all see every day from companies we despise.

Rebranding has a tendency to meet resistance for a while, even when it's needed and ultimately beneficial; excessively smarmy rebranding like this may well never take off at all.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 13:43 UTC (Thu) by sebas (subscriber, #51660) [Link]

That's actually an attitude we come across on a regular basis. There seems
to be very little understanding among technical people, such as software
developers for more abstract communications issues. It's probably the same
the other way round (ever heard marketing and sales people talking about
software developers ... ?).

You're right in that the KDE team did actually expect resistance, and that
the focus is on long-term clearer communication.

I wouldn't call it "smarmy" though, if you look at it, it's much more a
re-alignment with reality after 13 years. Think "what does Amarok running
on Windows have to do with a 'Desktop Environment'", for example. KDE has
simply outgrown the "DE paradigm", and the naming around that has never
had gotten the TLC to catch up with this.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 15:27 UTC (Thu) by nye (guest, #51576) [Link]

>That's actually an attitude we come across on a regular basis. There seems to be very little understanding among technical people, such as software developers for more abstract communications issues. It's probably the same the other way round (ever heard marketing and sales people talking about software developers ... ?).

It's not a lack of understanding, per se. It's an observation that certain types of language are used almost entirely by blusterous people who have nothing to say - and a great deal of that kind of language seems to have crept into this announcement. The same content could have been communicated with about a tenth of the verbiage, and choosing less awkward names would increase the appeal. It doesn't sound like a *natural* change; perhaps that's the problem.

I don't expect that you will ever succeed in decoupling the idea of a 'KDE Application' from the 'KDE Workspace'. My not-very-well-thought-out opinion is that it would have been a better idea to rebrand the KDE platform, and attach that brand to KDE applications - not that it matters because all the distinctions you are trying to make are pointless, even meaningless to the end-user.

Anyway, I believe I can at least understand the reasoning behind this, and wish you luck - because I think you'll need it.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 17:19 UTC (Thu) by krake (subscriber, #55996) [Link]

> I don't expect that you will ever succeed in decoupling the idea of a
'KDE Application' from the 'KDE Workspace'.

Why not?
This is actually one of the easier ones IMHO since it reflects end users'
reality best, i.e. apps like Amarok, K3B, Kontact, etc. being used on
other workspaces than KDE's.

> not that it matters because all the distinctions you are trying to make
are pointless, even meaningless to the end-user.

Isn't it mainly interesting for the end-user?
I mean if the communication from the creators better fits into what the
end-users are already doing (using apps built with KDE Development
Frameworks on workspaces built on different frameworks).

It should additionally help those who are still uncertain about that or
uncertain about whether the creators will consider it a bug if it doesn't
work like that.

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 19:55 UTC (Thu) by dkite (guest, #4577) [Link]

Is this 'communications from the creators' or communication from a marketing
department?

Big difference if you ask me.

Derek

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 20:19 UTC (Thu) by aseigo (guest, #18394) [Link]

"certain types of language are used almost entirely by blusterous people who have nothing to say"

KDE has proven it has had something to say for 13 years. We've done that in the form of millions of lines of code that sits on computers used by 10s of millions of people around the world. We've done that by creating technologies like KHTML that have become WebKit which is used by some of the largest companies in technology today in their core products. We have a lot to say, we have said it pretty well. When communicating to those who know us, I think it's reasonable to ask that you take the communication within the context of our history.

I do agree that often "blusterous people who have nothing to say" will take on the mantle of enthusiasm and passion so as to fool people into thinking they have something to be enthusiastic and passionate about. However, it would be a shame if we therefore stopped being or showing enthusiasm and passion just because there are charlatans out there. What I see in the announcement is a lot of enthusiasm and passion; I don't see any charlatanism.

"My not-very-well-thought-out opinion is that it would have been a better idea to rebrand the KDE platform, and attach that brand to KDE applications"

If by "platform" you mean "development libraries" that's what we're doing.

Note that we haven't rolled out the detailed guidelines for how to tag applications as "KDE" (since there are a few different ways in which an app can be "KDE": it can come from the main KDE community itself, it can be part of the SC, it can be completely 3rd party but use the KDE dev platform), but I think the distinction between what you've suggested and what we've done may not be as big as you think.

If by "platform" you mean "the desktop workspace" then we'll just have to agree to disagree because the entire point of this exercise is to recognize the existing realities that:

* KDE's libraries do not rely on the KDE workspace, and many of the libraries are completely stand-alone

* KDE's applications do not rely on the KDE workspace

* we have multiple workspace offerings now, so there is no "one workspace" to brand everything with if we even wished to

"all the distinctions you are trying to make are pointless, even meaningless to the end-user"

Some of the distinctions are for developers who might use KDE's libraries, and for them it's anything but pointless. Some of the distinctions are for our enthusiast community who helps evangelize KDE to the broader world; if they don't understand how things fit together, they will recommend things poorly. Some of the distinctions are for ourselves so that we remember to tell others about the real benefits possible, such as the multiplatform support, without feeling bad about "betraying" our own workspaces (which, btw, is what I happen to work on, oddly enough :) or without the message being confusing because we use the same terms in our communication for more than one thing.

Communication and marketing isn't easy, it isn't obvious and it isn't something one can get right without some serious effort and enterprise.

Thanks for wishing us luck, it's always helpful to get a few breaks here and there along the way.

Repositioning the KDE Brand (KDE.News)

Posted Dec 2, 2009 15:35 UTC (Wed) by clugstj (subscriber, #4020) [Link]

"KDE has proven it has had something to say for 13 years. We've done that in the form of millions of lines of code that sits on computers used by 10s of millions of people around the world. We've done that by creating technologies like KHTML that have become WebKit which is used by some of the largest companies in technology today in their core products. We have a lot to say, we have said it pretty well. When communicating to those who know us, I think it's reasonable to ask that you take the communication within the context of our history."

Are you trying to prove his point? That paragraph is entirely bluster!

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 20:07 UTC (Thu) by dkite (guest, #4577) [Link]

>little understanding among technical people, such as software
developers for more abstract communications issues.

Considering that I had to reread the marketing offerings a few times to
parse out what the h*** you were talking about.

Do you folks in these KDE marketing meetings actually talk like that?

If so then I will follow my initial reaction and actively ignore everything
that KDE marketing produces. Last time KDE marketing did anything noteworthy
it took a year before people had calmed down and stopped screaming.

Derek

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 11:43 UTC (Thu) by hppnq (subscriber, #14462) [Link]

Except that this re-branding is not about a change in conception, but about making our communication be more in line with how the software actually looks like and works.

Ehh, purposefully awkward?

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 12:01 UTC (Thu) by Alterego (subscriber, #55989) [Link]

in konqueror > help > about kde :
Environnement de Bureau KDE
Version 4.3.2 (KDE 4.3.2)

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 13:28 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

Yep. Will change in KDE SC 4.4 ;-)
(darn I almost had to go back and edit this to add SC there)

Repositioning the KDE Brand (KDE.News)

Posted Nov 26, 2009 13:38 UTC (Thu) by sebas (subscriber, #51660) [Link]

And it'll stay that way (unlike superstoned notes). We'll not retrofit old
versions, but will transition to the new, clearer naming from now on.

KDE 3.5 style launcher for KDE 4.3?

Posted Nov 26, 2009 19:47 UTC (Thu) by tdwebste (guest, #18154) [Link]

I would like to give KDE 4 another go, but my biggest grief is the KDE 4 launcher. If I could only set up a KDE 3.5 style simple launcher for KDE 4.3.

After a brief search I have found nothing. If others know, please share!!

KDE 3.5 style launcher for KDE 4.3?

Posted Nov 26, 2009 20:22 UTC (Thu) by aseigo (guest, #18394) [Link]

"I would like to give KDE 4 another go"

I assume you mean the KDE Plasma Desktop; you can use the rest of KDE 4, such as the applications, without requiring the workspace. In any case, it would be great if you could also use the workspace comfortably, so:

If by "launcher" you mean the menu in the panel, right click on the K icon and select "Switch to classic menu".

If by "launcher" you mean the "Run Command" dialog, you can disable all the plugins you don't like by clicking on the configure icon in the top left (usually a picture of a little 'wrench') and unselecting all the ones you don't care about. If you just keep "Applications", "Services", "Web Shortcuts" and "Calculator" you have the exact equivalent of KDE 3's run command.

So there you go, enjoy the KDE Plasma Desktop :)

KDE 3.5 style launcher for KDE 4.3?

Posted Nov 26, 2009 21:31 UTC (Thu) by nix (subscriber, #2304) [Link]

Seriously, isn't it faster and less cumbersome just to say 'plasma'?

KDE 3.5 style launcher for KDE 4.3?

Posted Nov 27, 2009 1:20 UTC (Fri) by aseigo (guest, #18394) [Link]

It's also less cumbersome to say "Aaron" instead of "Aaron Joseph Seigo from Canada" when referring to me. But if there are two Aarons in the room it can get a little confusing to just say "Aaron". So we use cues like eye contact or using last names or initials ("aaron s.").

There's Plasma Desktop and Plasma Netbook right now, and Plasma Mobile has started development. So ... Plasma is a little ambiguous already.

That said, if it's the only one in the room, so to speak, ("Hey, dude, what's that on your desktop?") then "plasma" might work just fine.

Of course, in more formal situations, we often use full names for people. If I'm introducing you as a speaker at a conference, for instance, I'll probably use your full name. So in more formal situations "KDE Plasma Desktop" will often get used.

It really depends on the context ... and importantly it's never just "KDE" now. :)

KDE 3.5 style launcher for KDE 4.3?

Posted Nov 27, 2009 7:03 UTC (Fri) by tdwebste (guest, #18154) [Link]

thx, yes the classic launcher within the Plasma Desktop is much less busy.

Next the default Plasma transparency and blue on blue is out of control. And not really good for fast review.

Right now I am sticking KDE applications within LXDE.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 4:01 UTC (Fri) by alfille (subscriber, #1631) [Link]

The announcement is certainly confusing.

After reading all the explanation, I think you are saying that KDE applications can run on other desktops, or even other platforms just fine. They don't need an emulation layer, and create minimal duplication of features the desktop provides.

At least that seems to be the theory.

But that means I should be able to download a KDE application. I can't unless I use my distro (and so wait for updates, etc).

Let's say I want kate.
Google "kate kde" -> kate-editor.org
ok not so bad. Pretty web design.

But then:
"The Kate project develops two main products: KatePart, the advanced editor component which is used in numerous KDE applications requiring a text editing component, and Kate, a MDI text editor application. In addition, we provide KWrite, a simple SDI editor shell which allows the user to select his/her favourite editor component."

Hmm. Download?
Only "Kate syntax highlight files"

I give up. Trust my distro, or look elsewhere. It's not a separate program by any reasonable description.

----------------
I'm not complaining about KDE applications. Many are very good. I'd even run the desktop if it supported Xinerama again. But you can't convince me that branding KDE applications as distinct from KDE is going to fly, because you don't offer them that way.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 7:28 UTC (Fri) by nix (subscriber, #2304) [Link]

Er, in that case Linux systems include *no* 'separate applications', and
neither does any other OS. *Every* program has at least one dependency on
*something*, and a massively multiarch system like Linux *always* ends up
with binaries being distro-dependent. That doesn't mean that most parts of
KDE depend on anything but the core libraries, and mostly not all of
those. (Mind you, this is true of GNOME too, but they're happy to call
themselves a desktop environment.)

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 9:57 UTC (Fri) by hppnq (subscriber, #14462) [Link]

*Every* program has at least one dependency on *something*, and a massively multiarch system like Linux *always* ends up with binaries being distro-dependent.

The observation is, that KDE components are meant to work together (or are perceived that way!) to the extent that you can plug parts of the software into other parts -- and you really couldn't do that with Kate and OpenOffice or another program that needs editing capabilities. (I am of course speaking of dlopen() rather than $EDITOR.)

Perhaps that kind of functionality can be discarded easily or it is small enough so it doesn't unnecessarily bloat the installation or runtime environment. In any case I consider this to be normal: if an application requires the loading of a library there must be other programs that also need that library, or my system is not functioning optimally.

(But I'm now too lazy to really care about that. Too many cernlib compiles will do that to you. ;-)

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 12:33 UTC (Fri) by krake (subscriber, #55996) [Link]

> But you can't convince me that branding KDE applications as distinct
> from KDE is going to fly

They are obviously not distinct from KDE, after all KDE produces them.

But several of KDE's products are distinct from each other, especially
applications and workspaces.

It is like saying "But you can't convince me that branding Apple
applications as distinct from Apple is going to fly"

Of course not, they are made by Apple.
But Apple also has different products, e.g. iTunes and Mac OSX. Sure
iTunes works probably best on OSX, but the number of users on other
platforms is greater than zero.

Same for KDE applications. You might gain advantages of running them on a
KDE workspace or together with other KDE applications, but again the
number of users with other combinations is also greater than zero.

I know quite some people who use all kinds of workspaces, e.g. Awesome, as
the shell they run KDE applications under.

The new branding will hopefully make this easier to understand for people
using less geeky workspaces, who might at the moment get the false
impression that in order to use a KDE application they would have to give
up their current choice of workspace.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 13:26 UTC (Fri) by alfille (subscriber, #1631) [Link]

I understand dependences and integration. My point is that many KDE applications aren't even separate downloads.

That's fine. Perhaps kate is so tied to other components of KDE that a separate download is impracticable. But that makes the idea of separate branding and positioning confusing.

My experience with KDE applications is that you choose one, you get a whole ball of yarn installed along with it. A dozen other packages and libraries. So my impression is that you get pretty much all of KDE when you want any part of it. It's a whole ecosystem.

What isn't clear to me, as a moderately sophisticated user, is whether starting a KDE application under, say, gnome is a bad idea. I know I'm starting up a lot of other components. How much ram and cpu does it cost me?

Take kate, which I like. Is the 20% better function of kate over gedit worth launching on a slower system under gnome? That's the kind of information that your marketing should be addressing.

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 17:49 UTC (Fri) by foom (subscriber, #14868) [Link]

> Take kate, which I like. Is the 20% better function of kate over gedit worth launching
> on a slower system under gnome? That's the kind of information that your marketing
> should be addressing.

I never even thought to look for information like that. I just use the apps that work well for me,
whether they're KDE or GNOME...is that really so uncommon? What do I care if it installs a few
extra libraries with the app? If it launches too slowly on your computer, of course, that's a reason
for you not to use it...

Repositioning the KDE Brand (KDE.News)

Posted Nov 27, 2009 18:05 UTC (Fri) by krake (subscriber, #55996) [Link]

> My point is that many KDE applications aren't even separate downloads.

Separate source downloads would probably be possible but not very
sufficient since you would end up building all shared parts again and
again.

On binary package level at least the distibution I am using (Debian) has
all apps as separate downloads with all shared parts as dependencies.

The first C++ program pulls the C++ standard library, the first Qt
program Qt, the first Python program pulls required Python packages, the
first KDE program the KDE libraries and KDE base runtime.

Any other program of each category is then just itself or any program
specific additional dependencies.

If efficient downloading is not required, I imagine one could bundle all
dependencies with each application and let the package manager figure out
which one it really has to install after unpacking.

> A dozen other packages and libraries.

Quite possible.
Just like with any other application which has new dependencies. The
first X client will install quite a number of libraries as well.
But any further app should be then also be relatively moderate, probable
less than a handful of new things.

> So my impression is that you get pretty much all of KDE when you want
any part of it.

This is actually quite an interesting experiment. If you know how a
"full" KDE ecosystem looks and behaves like, installing a new system
without any KDE packages and the installing a single application will
show you how much you haven't installed yet.

The base dependencies are a tiny subset of all packages containing
software by KDE.

The packaging teams might actually have numbers comparing "kde-minimal"
and "kde-full".


Repositioning the KDE Brand (KDE.News)

Posted Nov 28, 2009 16:10 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

I don't get your problem. Is it that the kate site does not offer a tarball
to download? What good whould that do the common user? You're apparently
one of the few who likes do deal with dependencies yourself - I'd rather do
pacman -S kate and be done with it. Whatever it downloads, whatever it
takes - as long as it works. Aspell? zlib? xorg-server? I don't care. I do
know they're not part of 'KDE', only "kdelibs-4.3.3" is. Which is pretty
much the only KDE thing being downloaded. Yes, there is poppler, dbus, but
those are infrastructure below KDE.

There is no other 'being tied in'. For Kate to work you ONLY need the KDE
libs and everything below (X.org, dbus, hal, linux/BSD/etc kernel). Kate
does not depend on Amarok, or Gwenview, or Dolphin. If your distro has
decided to couple it with any of those - send an angry email to them.

Of course having at least kdebase-runtime (with the very basics like
Systemsettings so you can configure themes and global behaviour) would
probably be very nice - I can see how distro's make that mandatory...

Repositioning the KDE Brand (KDE.News)

Posted Nov 30, 2009 6:46 UTC (Mon) by JoeF (subscriber, #4486) [Link]

You're apparently one of the few who likes do deal with dependencies yourself
There are people like that, including me...
Call me old school, but I like to know exactly what's on my system.
And I don't want to waste disk space. While in a lot of situations, disk space is plenty, there are situations where every MB counts, e.g., on netbooks. My netbook has a SSD, and I have no need to fill that with some libraries that are not really needed.

Debugging and Fixing Monolithic Systems

Posted Nov 30, 2009 19:23 UTC (Mon) by pboddie (guest, #50784) [Link]

I don't get your problem. Is it that the kate site does not offer a tarball to download? What good whould that do the common user?

In fact, the ability to download the sources for only the application (or the components which make up the application), and the ability to build those sources against pre-installed libraries, possibly to fix a bug in the application, is something which shouldn't be downplayed. The traditionally monolithic nature of KDE with its not-quite-separate bundles doesn't lend itself to this kind of agile bug-fixing: download a ton of stuff, .configure, make, persuade stuff to look in the right place, build more stuff, and so on, one day perhaps being in a position to make that trivial fix.

It then becomes quite easy to make the case for dynamic languages like Python to get around this architectural burden, where the solution in such a situation would be to just locate the source file and "hotfix" it in place. Of course, a load of people in various desktop-related projects dislike Python and friends, entertaining them only for tweaks and "non-technical user" customisations, but at this point those languages offer a lot more to contributors who are not completely invested in a given project. KDE and projects of a similar nature really have to step up to compete here.

Debugging and Fixing Monolithic Systems

Posted Nov 30, 2009 20:05 UTC (Mon) by krake (subscriber, #55996) [Link]

It is by far not as complex as you make it look like.

For the scenario of fixing a bug in a specific program, say KBattleShip,
you download the source archive for the respective module, in this case
kdegames.

Since you have a binary from your distribution already, all build
dependencies can be satisfied by the distribution's development packages.

Most distributions even have explicit commands to get all build
dependencies for a specific target package.

Actually, they usually also have the sources as a buildable package, so if
you found and fixed the problem you could even replace the binary shipped
by the distribution, while still satisfying all package manager
requirements

Debugging and Fixing Monolithic Systems

Posted Nov 30, 2009 20:10 UTC (Mon) by krake (subscriber, #55996) [Link]

Arg!

Forgot to write that even when you go the route of using the source
archive of the respective module, you can build each application in it on
its own.

After initializing the build system for the module, each subdirectory
(either apps or module libs) can be built and installed separately.
If there is an intra module dependency, e.g. a lib shared by apps of that
module, it will be built automatically.

KDE Xinerama

Posted Nov 30, 2009 18:50 UTC (Mon) by rfunk (subscriber, #4054) [Link]

"I'd even run the desktop if it supported Xinerama again."

There are certainly different definitions of "support", but I'm running KDE
4.3.3 (er, KDE Plasma Desktop from KDE SC 4.3.3) on Kubuntu Karmic, and
Xinerama is working just fine. New windows/dialogs don't cross the screen
boundary, nor does maximizing.

OTOH, the KDE 3.5.10 installation I still have at home doesn't seem very
Xinerama-aware.

Repositioning the KDE Brand (KDE.News)

Posted Dec 3, 2009 20:22 UTC (Thu) by brianomahoney (subscriber, #6206) [Link]

As someone who has just spent several days struggeling to get KDE 4.3 working as well as 3.5xx did I can tell you that:

1. If Gnome was not worse I would use that:

2. Getting a good bug tracking/wiki/doc system in place is __far_more__ important than "Re-branding" leave that to M$ and Tiger Woods!

3. Most of us care about solidly working functionality, that is well documented or we can Google for, not __idiots__ waxing lyrical about the beauty of the UI. The American phrase "Lippenstift auf einem Schwein" needs to be taken to heart by many KDE devs.

=== If you can't configure KMAIL without a pain something is broken, eg signature files, (No complaint if not findable)

=== Bluetooth (binding aka verbindung) not English "pairing" an dosn't work on SuSE 11.2 install (you neet to run an agent eg simple-agent, by hand to get the agent registered with Dbus, and may need to tune the Dbus service names.

KDE 4.3x Plasma Desktop is quite nice, but triggers false frees in the Plasma Desktop executable which means that you have to turn off glibc checking while it starts up (to avoid aborts from the false free code), and this hides a memory leak that slows the desktop down after several days.

Having it look like Vista/Win7 isn't important to me, __NOT__ having it __BE__ like Win *, eg undocumented, buggy and in-secure is.

The KDE devs need to get their head out their ass!

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds