Linked by Thom Holwerda on Sun 31st Oct 2010 22:13 UTC, submitted by Michael
KDE Ambition. Too little, and you stagnate. Too much, and you end up stumbling. Keep this in mind. KDE4 was, and is, a very brave and ambitious effort, and while in my personal opinion they've still got a long way to go, especially in the performance department (I regained some hope lately), they're getting there. Imagine my surprise that after the recently announced overhaul of Plasma, a rather wild idea has popped up that would mean Qt5 and KDE5 - assuming the idea gets enough support, of course.
Order by: Score:
Smaller bytes
by jessesmith on Sun 31st Oct 2010 22:31 UTC
jessesmith
Member since:
2010-03-11

I tend to agree with the paragraph toward the end which suggests kdelibs is broken down into smaller chunks. It sounds like an easier and more reasonable approach at the moment than turning KDE's base into Qt.

Reply Score: 4

RE: Smaller bytes
by _txf_ on Sun 31st Oct 2010 22:51 UTC in reply to "Smaller bytes"
_txf_ Member since:
2008-03-17

That would be a good first step. As a side effect of that one could clearly start to see what classes are duplicates of Qt classes and start pruning and injecting any additional (non kde) functionality back from K classes to the Qt base classes.

I never quite understood why they didn't modularize kdelibs4 (further).

Edited 2010-10-31 22:53 UTC

Reply Score: 4

RE: Smaller bytes
by orestes on Sun 31st Oct 2010 22:55 UTC in reply to "Smaller bytes"
orestes Member since:
2005-07-06

That'd be my assessment too. Globbing things together for no good reason is generally a recipe for headaches. Were it my call I'd say figure out where QT and kdelibs overlap and strip the redundant parts while keeping the unique elements as their own entities for those interested in using them.

Reply Score: 2

RE: Smaller bytes
by kaiwai on Mon 1st Nov 2010 00:07 UTC in reply to "Smaller bytes"
kaiwai Member since:
2005-07-06

I tend to agree with the paragraph toward the end which suggests kdelibs is broken down into smaller chunks. It sounds like an easier and more reasonable approach at the moment than turning KDE's base into Qt.


I assume with the breaking down into smaller components will also mean removing some of the duplication that exists between Qt and kdelibs. Does it make sense to maintain a separate rendering engine when it would be smarter to hook into the webkit based engine that is already inside Qt? I hope that what eve decision is eventually made it is done on the basis of what is good for KDE rather than particular individuals grandstanding.

Then there is still the issue of a udev/udisk/upower backend; it still isn't feature complete and a first class backend. Oh well.

Reply Score: 2

Yes
by RichterKuato on Sun 31st Oct 2010 22:43 UTC
RichterKuato
Member since:
2010-05-14

Yes! Merge KDE and QT then Merge QT and GTK+. That will solve all of the worlds problems.

Reply Score: 2

RE: Yes
by stabbyjones on Sun 31st Oct 2010 23:09 UTC in reply to "Yes"
stabbyjones Member since:
2008-04-15

Oh that would totally work. If there's one thing free software users love it's a lack of choice.

One of the first comments I read on slashdot said they would fork QT if the merge happened.

Reply Score: 3

RE[2]: Yes
by RichterKuato on Sun 31st Oct 2010 23:24 UTC in reply to "RE: Yes"
RichterKuato Member since:
2010-05-14

The cool thing then is that this would provide choice.
You have the choice of reduced duplicated effort. In addition you have the choice of Gtk+ apps working better on KDE and QT apps working better on Gnome.

Also, I don't care.

Reply Score: 1

RE[2]: Yes
by Bill Shooter of Bul on Mon 1st Nov 2010 06:28 UTC in reply to "RE: Yes"
Bill Shooter of Bul Member since:
2006-07-14

That's a good start, but to be safe you should probably re-implement it in MICROSOFT COBOL and include a binary blob to take care of DRM restrictions that anyone might need to place on a any part of any program remotely if they discover they hold a patent on some part. Free Software lovers will be in heaven!

Reply Score: 3

RE[3]: Yes
by sorpigal on Mon 1st Nov 2010 14:23 UTC in reply to "RE[2]: Yes"
sorpigal Member since:
2005-11-02

I want to mod this as funny but I'm not sure if I get the joke.

Reply Score: 2

RE[4]: Yes
by Bill Shooter of Bul on Mon 1st Nov 2010 16:42 UTC in reply to "RE[3]: Yes"
Bill Shooter of Bul Member since:
2006-07-14

Well, most lovers of FOSS aren't too fond of Microsoft +1, nobody really likes cobol +1, nobody likes binary blobs in the midst of otherwise open source ( aka like those that can be loaded into the kernel), nobody likes DRM (information should be free), nobody likes software patents, and of course nobody wants to allow third parties to disable their programs remotely as easily as sending a DCMA takedown notice is now.

That would be the ultimate in lawsuit negotiation, "pay me now or I shut down all of your customers software with one click." mu ha ha ha ...

Reply Score: 2

Ambitious, but possibly infeasible?
by woegjiub on Mon 1st Nov 2010 00:30 UTC
woegjiub
Member since:
2008-11-25

Considering the possible major stumbling blocks (will Qt want the KDE functionality, will nokia accept the desktop-oriented improvements, etc), it seems like there is a set of large barriers, but if they could be overcome...

Merging Qt and KDE would be AMAZING.
Not only the hugely increased developer support, but the corporate funding, the idea that maybe more user-oriented higher level features will be able to use the EXACT SAME stack on KDE as they do on MeeGo?
I hope this will get KDE's NEPOMUK implemented more widely.
Also, considering Shuttleworth's desire to use more Qt, will this mean more mainstream linux KDE apps instead of GTK?

I may be not making sense, or saying things that are not actually applicable, but the idea sounds incredible, if the major barriers can be overcome.

Edited 2010-11-01 00:31 UTC

Reply Score: 2

WereCatf Member since:
2006-02-15

Merging Qt and KDE would be AMAZING.
Not only the hugely increased developer support, but the corporate funding, the idea that maybe more user-oriented higher level features will be able to use the EXACT SAME stack on KDE as they do on MeeGo?


You're confusing things. Kdelibs is NOT KDE. KDE is the desktop environment while kdelibs is just a library. KDE consists of a lot more stuff than just a library and thus you could NOT use "exact same stack on KDE as they do on MeeGo."

Reply Score: 3

woegjiub Member since:
2008-11-25

*facepalm*
Sorry.

Is NEPOMUK in KDELibs?
Because, if that could be merged into Qt, adopted by Canonical (who are said to be looking at Qt), and Nokia, that would be a wonderful thing.
Tagging file managers are a great idea, and when housing collections of items, folders are not good enough as they mean only one cataloguing method is possible.

Reply Score: 1

Gnome approach
by Delgarde on Mon 1st Nov 2010 00:54 UTC
Delgarde
Member since:
2008-08-19

Worth noting is that this is also the direction Gnome have been heading in recent years - retiring stuff from the Gnome part of the stack, and replacing them with equivalents lower down in glib and gtk+. For instance, deprecating GConf in favour of a settings API built into glib. Or replacing various widgets in libgnomeui and libsexy with equivalents in core gtk+.

It makes sense to me, anyway. You don't want to cram everything into the core, but if it does belong there, that's where it should be. My impression is that there's stuff in kde-libs that would be useful to those targeting Qt but not KDE, so it would be good to move it higher up. Conversely, there's plenty of stuff in Qt that could usefully be split out into separate libraries, as proposed last week...

Reply Score: 4

cb88
Member since:
2009-04-23

Merge it with meego merge it with boostlibs merge it with llvm merge it with QT merge it with KDE merge it with libreoffice merge it with wine merge it with facebook merge it with osnews merge it with slashdot! merge it with google and yahoo.... MERGE IT ALL!!

Ahem... in light of that though I don't think merging is bad and hopefully the modules will be buildable separatly from one another merely with less duplication and synergy between projects YAY!

Note: Original quote was "Merge it with Maemo merge it with BoostLibs!!! MUHAHAAHHAAH"

Reply Score: 1

won't happen.
by Elv13 on Mon 1st Nov 2010 04:56 UTC
Elv13
Member since:
2006-06-12

KDElibs provide unified icon set, FreeDesktop standards compatibility. KDE equivalent of registers (KonfigSKeleton), deep dbus requierment and more importantly, Nepokuk and the semantic stack (underused, but with some potential).

Those parts does not make sense on anything but KDE on *nix. The Windows port of DBUS is unusable, the FreeDesktop standard that drive how Linux desktop work are for *nix only and a total duplication of those found on Windows/Mac (don't misquote me, they can not be replaced by the Windows/Mac ones, they need to be for *nix only) and the semantic stack is worthless if it is not platform wide (for now and for that reason, it is currently useless).

KDElibs can not be merged for those reasons and many other. I am not saying I would not like to see my own apps work on a wider variety of platforms and remove all those #ifdef on those I coded to work with Qt only if needed. But I won't see a merge coming, because it won't happen, ever. See how it worked for Phonon, it took a years before it was deprecated. It was based on KDE needs instead of everybody needs.

Reply Score: 5

RE: won't happen.
by smitty on Mon 1st Nov 2010 05:29 UTC in reply to "won't happen."
smitty Member since:
2005-10-13

KDElibs provide unified icon set, FreeDesktop standards compatibility. KDE equivalent of registers (KonfigSKeleton), deep dbus requierment and more importantly, Nepokuk and the semantic stack (underused, but with some potential).

Those parts does not make sense on anything but KDE on *nix. The Windows port of DBUS is unusable, the FreeDesktop standard that drive how Linux desktop work are for *nix only and a total duplication of those found on Windows/Mac (don't misquote me, they can not be replaced by the Windows/Mac ones, they need to be for *nix only) and the semantic stack is worthless if it is not platform wide (for now and for that reason, it is currently useless).

KDElibs can not be merged for those reasons and many other. I am not saying I would not like to see my own apps work on a wider variety of platforms and remove all those #ifdef on those I coded to work with Qt only if needed. But I won't see a merge coming, because it won't happen, ever. See how it worked for Phonon, it took a years before it was deprecated. It was based on KDE needs instead of everybody needs.


Sure, there's stuff that doesn't make sense. Like KTHML, that would never get accepted since Qt has webkit already. I think the point, though, is that large portions of KDELibs could potentially be merged back into Qt. Then the rest could stay in a much more slimmed down version of KDELibs, or better yet as various Qt modules maintained by KDE.

I don't know, it sounds like a good move in the long run, but also like something that could take a long time and a lot of effort. Which may not be a wise thing to start so soon after KDE4 is starting to stabilize.

I think they should start working on modularizing KDELibs, that would be nice no matter what the ultimate decision is and will likely be required if they want to merge in smaller chunks at a time into Qt anyway. Then in a couple years when everything is modularized maybe they can take another look and see if it still makes sense.

Reply Score: 4

RE: won't happen.
by segedunum on Mon 1st Nov 2010 23:07 UTC in reply to "won't happen."
segedunum Member since:
2005-07-06

Yer, cross-platform toolkits exist for a reason, but once you start building your own platform specific environment then you're already nailing your colours to the mast. You can't just then roll that environment back into the cross-platform toolkit in an effort to solve problems you think you have.

Put simply, KDE has to make KDE an attractive enough desktop platform so that developers will want to write applications for it and Qt will then want to add better support for it as a platform. That's the direction things have to go in.

Reply Score: 4

I really hate talking as if it theory.
by oiaohm on Mon 1st Nov 2010 05:11 UTC
oiaohm
Member since:
2009-05-30

QT is currently be modulised.

And KDE is already break itself down.

This will be a slow transition over the live of KDE 4.x. KHTML usage is slowly being reduced inside KDE and QT Webkit support is being used instead.

Plasma is avoiding duplicating some things up as well.

Yes KDELIBS and QT are merging. This does not need to be rushed. Slow and steedy will be painless.

Reply Score: 2

Getting started
by vivainio on Mon 1st Nov 2010 05:54 UTC
vivainio
Member since:
2008-12-26

There is a logical way to get started with this - ensure it's easy to use a kde module from a plain Qt program without pulling in half the kde. It doesn't really matter after that whether Qt and kde merge - it's just a branding issue. Good modular libs could be deployed widely by Nokia next - e.g. it would be possible to have them as internal parts of meego and symbian.

Reply Score: 5

RE: Getting started
by mat69 on Mon 1st Nov 2010 06:49 UTC in reply to "Getting started"
mat69 Member since:
2006-03-29

I wholeheartly agree on that.
When writing small programs I use locally -- both on Windows and on Linux -- I opted for Qt instead of kdelibs, despite that in many areas the later is more easy to use.

Needing so many dependcies would have made it a pain. Having a kdecorelibs that only depended on Qt would have changed that.

This would make kdelibs itself a lot more interesting and sustainable for developers.

Though I think a merge with Qt should not be done in most cases, yeah KUrl should be merged but other parts should just become Qt libs -- once their requirements like KUrl have been merged.

Reply Score: 3

shaunehunter
Member since:
2007-02-12

I always kind of assumed this was the direction they were heading in with the release of KDE4/QT4. Given Trolltech and then Nokia's employees always heavy involvement in KDE's development it just seemed logical. It's seems that the KDE is disorganized and a concrete direction to a goal like this needs to be stated otherwise KDE4 will just float around forever and stagnate like GNOME2 has.

With the acquisition of QT by Nokia, KDE has been sitting in a potentially explosive position for a couple years now and it seems to continue to be loaded with more powder every day. Currently the largest mobile phone and microchip manufacturers (Nokia and Intel) are unsuccessfully scrambling to create in Meego what KDE almost already is (and so much more). Now Ubuntu, the largest desktop Linux distro, want's to switch to QT.

If this merger happens it means that every KDE app will be available on Windows and Mac OS's as well as almost half the worlds mobile phones by default (Amarok could be a potent gateway drug). No opportunity for the adoption of linux by end users of this scale has ever been presented before. It's been my opinion that the KDE people have been severly neglecting platform promotion.

With some sales savvy and a clear workable proposal I think these three parties could be brought on board to do something really special.

I also think that the KDE4/QT4 Social Semantic Desktop idea is a better fit for a Unity/GNOME Shell type interface than GNOME/Gtk or even KDE's current one.

To end with a random thought, KDE's biggest criticism is the KDElibs dependancies on thier apps. I guess people don't realise that they're under 15MB in total.

Reply Score: 3

superstoned Member since:
2005-07-07

Notice that besides those 15 mb there are a lot of other dependencies. But yeah, most people heavily over-estimate the impact of KDE libs on their system...

You are right in that this is something which should've happened a long time ago. The idea isn't exactly new, at least I know I've spoken about this very thing over a year ago with Sebas - Qt just wasn't very open back then however. Now the time is right to start doing this and I hope it'll happen.

But there is more than just a communication/promo barrier here - technically it'll be a lot of work and in some area's it'll be impossible with Qt and KDE how they are. So don't hold your breath. Small steps will have to come first ;)

Reply Score: 4

shaunehunter Member since:
2007-02-12

Whenever more than one person works toward a goal there was sale of the idea preceding it. As a long time salesman I know that people buy the presentation, not the product. This is true about anything you or I have ever done consciously or unconsciously. Our decisons don't occur spontaniously in our minds but by a series of suggestions. Thats a bit absract but if the sale of this idea can be made KDE/QT can gain major resources for the softwares development. Nobody sets up a factory, starts manufacture and then seeks investment right?

I think KDE would do well as a superset complementing QT be tightly integrated with little overlap but without Nokia on fully board it can't happen. They must be conviced that KDE is what they need first.

I'd much rather have KDE continue it's practice of almost traspairent (from a user prespective anyway) of developing KDE4. They've done some pretty major changes and since 4.3 it's been a pretty smooth ride (I probably have the kubuntu team to thank for that).

In my opinion Corny's atempting this now because he sees that it's the only way to see KDE/QT live up to it's potential. I wish him luck.

btw, the 15MB figure was from adding the KDE/Qt specific dep.'s of konqueror together. In total the app weighs in at under 20MB and about 35MB in RAM on my system (unless the evil nspluginviewer goes arwy). It just bugs me to see people badmouth it and happily install bloated ass java and flash with firefox without a word.

Reply Score: 2

oiaohm
Member since:
2009-05-30

Like KTHML, that would never get accepted since Qt has webkit already.

Remember Webkit and Khtml are blood brothers. No new KDE applications are not using Khtml. In fact Khtml is a deprecated API. Legacy support really is the status of Khtml. Correct way is to use the QT webkit for html rendering,

The merge has started. Piece by Piece. While in the process QT and KDELIBS will be converted into modules.

This is not going to be a big jump. By the time the legacy is dropped is most likely a few years off. KDE 4.0 was a big jump and it was required to start this process.

On the issue of dbus for windows. The bugger does truly work. Just it not as fleshed out with dbus services. Sorry to say there are a lot of secuirty things dbus does better.

Reply Score: 4

Comment by Laurence
by Laurence on Mon 1st Nov 2010 11:05 UTC
Laurence
Member since:
2007-03-26

One thing that I kept thinking while reading this article was that the whole point of KDE is it's a unified desktop environment. So yes, kdelibs might not be modularised to the extent where you can't just use one class without importing the whole KDE stack, but then that's not really an issue given that people using kdelibs should generally be targeting the KDE platform specifically.

Maybe I'm missing the point , but for me the decision between Qt and kdelibs has always been an easy one: am I targeting KDE specifically or not?

That said, I've been a happy KDE user since version 2 and haven't personally experienced any of the performance hits nor instabilities in 4.x (well, 4.2+) that many users have complained about - so I would happily build specifically for that platform should the scenario arise.

Reply Score: 3

RE: Comment by Laurence
by vivainio on Mon 1st Nov 2010 12:26 UTC in reply to "Comment by Laurence"
vivainio Member since:
2008-12-26

One thing that I kept thinking while reading this article was that the whole point of KDE is it's a unified desktop environment.


I thought they got rid of that marketing approach with the change to new naming ("KDE workspace" or whatever).

Reply Score: 3

RE[2]: Comment by Laurence
by Laurence on Mon 1st Nov 2010 12:58 UTC in reply to "RE: Comment by Laurence"
Laurence Member since:
2007-03-26

I thought they got rid of that marketing approach with the change to new naming ("KDE workspace" or whatever).


I thought the renaming of KDE to KDE Software Compilation was to further emphasise the whole integrated environment aspect of KDE. ie, you don't just get a DE, but you get toolkits, applications and a whole experience where everything communicates with each other. I guess much like what Apple and MS do with their products on their respective platforms (though perhaps MS less so because they don't even follow their own GUI guidelines).

In short, I thought what the KDE team was trying to sell (for want a better term) was the whole bundle rather than just a toolkit and/or productivity apps and/or DE shell.

Reply Score: 4

RE[3]: Comment by Laurence
by vivainio on Mon 1st Nov 2010 15:03 UTC in reply to "RE[2]: Comment by Laurence"
vivainio Member since:
2008-12-26


I thought the renaming of KDE to KDE Software Compilation was to further emphasise the whole integrated environment aspect of KDE.


I thought just the opposize - e.g. there is now a separate "KDE development platform", which sort of suggests you can pick up pieces of the whole KDE instead of dealing with this impermeable monolith that has everything from KIO (useful) to games (not useful).

Reply Score: 4

RE[3]: Comment by Laurence
by mart on Mon 1st Nov 2010 19:16 UTC in reply to "RE[2]: Comment by Laurence"
mart Member since:
2005-11-17

I thought the renaming of KDE to KDE Software Compilation was to further emphasise the whole integrated environment aspect of KDE.


Well, actually KDE wasn't renamed to KDE Software Compilation. The SC thingwas meant to be an internal naming to help us define what is the portion that gets syncronously released... unfortunately this got out as the new name, but it isn't.

The emphasis is instead moving the meaning of KDE from "desktop environment" to "community that writes software" (the acronym doesn't mean anything now)
and some of the "products" of said community are:
* the KDE Platform (that is, but not only, kdelibs)
* the KDE Plasma Desktop (and netbook, and mobile..) workspaces
* a ton of applications that happens to use the KDE Platform

So, if the said Platform (or parts of it) can have an appeal in the development of applications not directly targeted to one of the KDE Plasma workspaces, but helps the developer anyways (like just happens to have a class that solves their exact problem) everyone wins

Reply Score: 3

re:
by ngativ on Mon 1st Nov 2010 13:08 UTC
ngativ
Member since:
2010-11-01

This is the kind of issues that end users don't really care, but i guess it would benefit users.The KDE community is always thinking about what is the next step, and i love that

Reply Score: 2

v Bloatware.
by axilmar on Mon 1st Nov 2010 13:31 UTC
RE: Bloatware.
by boudewijn on Mon 1st Nov 2010 13:44 UTC in reply to "Bloatware."
boudewijn Member since:
2006-03-05

In KDE 3.5. KDE 4.x is quite different.

Reply Score: 3

RE[2]: Bloatware.
by Bille on Mon 1st Nov 2010 20:27 UTC in reply to "RE: Bloatware."
Bille Member since:
2007-05-31

In KDE 3.5. KDE 4.x is quite different.

Yup, although more could probably be shifted to base/runtime:
> rpm -ql kdelibs4 |egrep "bin|libexec"
/usr/bin/checkXML
/usr/bin/kbuildsycoca4
/usr/bin/kcookiejar4
/usr/bin/kded4
/usr/bin/kdeinit4
/usr/bin/kdeinit4_shutdown
/usr/bin/kdeinit4_wrapper
/usr/bin/kjs
/usr/bin/kjscmd
/usr/bin/kross
/usr/bin/kshell4
/usr/bin/kunittestmodrunner
/usr/bin/kwrapper4
/usr/bin/makekdewidgets
/usr/bin/meinproc4_simple
/usr/bin/nepomuk-rcgen
/usr/bin/preparetips
/usr/lib64/kconf_update_bin
/usr/lib64/kde4/libexec
/usr/lib64/kde4/libexec/filesharelist
/usr/lib64/kde4/libexec/fileshareset
/usr/lib64/kde4/libexec/kconf_update
/usr/lib64/kde4/libexec/kdesu_stub
/usr/lib64/kde4/libexec/kio_http_cache_cleaner
/usr/lib64/kde4/libexec/kioslave
/usr/lib64/kde4/libexec/klauncher
/usr/lib64/kde4/libexec/kmailservice
/usr/lib64/kde4/libexec/kpac_dhcp_helper
/usr/lib64/kde4/libexec/ksendbugmail
/usr/lib64/kde4/libexec/ktelnetservice
/usr/lib64/kde4/libexec/lnusertemp
/usr/lib64/kde4/libexec/start_kdeinit
/usr/lib64/kde4/libexec/start_kdeinit_wrapper

Reply Score: 1

RE[3]: Bloatware.
by mat69 on Mon 1st Nov 2010 22:00 UTC in reply to "RE[2]: Bloatware."
mat69 Member since:
2006-03-29

The reason for kdelibs is BC and SC. kdebase does not make that promise in general.
So moving things to base would not be a solution.

Reply Score: 2

RE: Bloatware.
by ebasconp on Mon 1st Nov 2010 15:41 UTC in reply to "Bloatware."
ebasconp Member since:
2006-05-09

The only way of getting beauty and simplicity in huge software is breaking it down in a lot of small pieces... à la KDE ;)

Reply Score: 2

RE: Bloatware.
by oiaohm on Tue 2nd Nov 2010 05:58 UTC in reply to "Bloatware."
oiaohm Member since:
2009-05-30

artsmessage, checkXML, cupsdconf, cupsdoprint, dcop, dcopclient, dcopfind, dcopidl, dcopidl2cpp, dcopidlng, dcopobject, dcopquit, dcopref, dcopserver, dcopserver_shutdown, dcopstart, filesharelist, fileshareset, imagetops, kab2kabc, kaddprinterwizard, kbuildsycoca, kcmshell, kconf_update, kconfig_compiler, kcookiejar, kde-config, kde-menu, kded, kdeinit, kdeinit_shutdown, kdeinit_wrapper, kdesu_stub, kdontchangethehostname, kdostartupconfig, kfile, kfmexec, kgrantpty, khotnewstuff, kinstalltheme, kio_http_cache_cleaner, kio_uiserver, kioexec, kioslave, klauncher, kmailservice, kpac_dhcp_helper, ksendbugmail, kshell, kstartupconfig, ksvgtopng, ktelnetservice, ktradertest, kunittestmodrunner, kwrapper, lnusertemp, make_driver_db_cups, make_driver_db_lpr, makekdewidgets, meinproc, preparetips, and start_kdeinit

Yes folks, it's the program contained in kdelibs. Why should it be merged with Qt? I don't get it.

What happened to software simplicity and beauty? they are drowned in developers' ambitions...


Lets go threw that list.

kio_http_cache_cleaner Most likely should be deprecated and become part of QT Webkit.

Lot of the printing related would be better of in QT. So cupsdconf, cupsdoprint, make_driver_db_cups, and make_driver_db_lpr. To be correct most of this is already in QT under other names.

checkXML also another item that is inside QT already.

dcop stuff dcop, dcopclient, dcopfind, dcopidl, dcopidl2cpp, dcopidlng, dcopobject, dcopquit, dcopref, dcopserver, dcopserver_shutdown, dcopstart Most likely should be in a lib of its own right. So if dcop ever gets deprecated removal is simple.

What is talked about is not just merging with Qt some merged with Qt some converted into what would be QT module not a KDE designed one. The difference is a QT designed module does not depend on KDE libs instead just on QT itself. Cleanup time.

Reply Score: 1

RE[2]: Bloatware.
by _txf_ on Tue 2nd Nov 2010 15:44 UTC in reply to "RE: Bloatware."
_txf_ Member since:
2008-03-17


dcop stuff dcop, dcopclient, dcopfind, dcopidl, dcopidl2cpp, dcopidlng, dcopobject, dcopquit, dcopref, dcopserver, dcopserver_shutdown, dcopstart Most likely should be in a lib of its own right. So if dcop ever gets deprecated removal is simple.


DCOP is not used in kde4. In case you're unaware kde4 uses dbus. The original list was from kde3 I believe.

Reply Score: 3

RE[3]: Bloatware.
by oiaohm on Tue 2nd Nov 2010 22:41 UTC in reply to "RE[2]: Bloatware."
oiaohm Member since:
2009-05-30

I forgot. Its already legacy for porting KDE 3 applications forward to KDE 4. So if it still in KDELIBS it should be moved out sideways anyhow.

Reply Score: 1

No
by sorpigal on Mon 1st Nov 2010 16:35 UTC
sorpigal
Member since:
2005-11-02

The short answer is "No," but the long answer is "Yes."

Pulling the kdelibs monolith apart would be good for everybody (not counting the people who have to do the work) and could only serve to make packaging KDE and its apps easier for distributions.

Once it's pulled apart if some things could be merged in to Qt, if and where that makes sense, and the result remain source compatible with post-pull pre-merge KDE, then I see no reason not to work toward that kind of code sharing.

Pushing the KDE platform wholesale into Qt, on the other hand, is wrong to the point of stupid.

Reply Score: 3