JUN
4
2006

KDE Commit-Digest for 4th June 2006

In this week's KDE Commit-Digest: Kopete 0.12 is released after 10 months of development. Usability fixes in RSIBreak and experiments in amaroK. Common KOffice color management initiative - "pigment" - started. User interface optimisations in Adept package manager. KDE 4 changes: DCOP is finally removed from trunk/. The KDE 4 icon theme, Oxygen, is imported into KDE SVN.

Comments

I think the server is now down...


By biquillo at Sun, 2006/06/04 - 5:00am

I'm also having issues.

Every once in a while, the server will actually respond and open a connection, but I never get a response to the HTTP request. Weird.


By Des at Sun, 2006/06/04 - 5:00am

What is the "Oxygen style and window decoration for KDE"?

Will these be the defaults for KDE4?

How will they look like?


By mingus at Sun, 2006/06/04 - 5:00am

You might want to follow the Oxygen link... that might answer your question.


By Des at Sun, 2006/06/04 - 5:00am

I have followed it, that's where I got the question from, but there's no answer.


By mingus at Sun, 2006/06/04 - 5:00am

The question "how will it look like?" isn't really easy to answer as stuff like this is work in progress (and probably will be so until KDE4 will be released).
So just be patient :)


By Easy to guess at Sun, 2006/06/04 - 5:00am

Oxygen is an icon theme. I haven't heard anyone say it will be a style or window decoration.

Yes, it will be the KDE4 default.

There are previews of what it looks like at the link you followed.


By Des at Sun, 2006/06/04 - 5:00am

Thomas is author of the popular and impressive Baghira style for QT/KDE. He is working on Oxygen style and window decoration for KDE.

(http://www.oxygen-icons.org/?cat=2)


By mingus at Sun, 2006/06/04 - 5:00am

Well ... unfortunately Baghira is a rip-off of an existing style (Apple's Aqua) and suffers from a multitude of graphical glitches (things not matching up, extraneous bevels, badly aliased edges - in many cases limitations of Qt3s painting engine, I'm sure, but not in all), so those aren't particularly impressive credentials.


By Anonymous at Mon, 2006/06/05 - 5:00am

If the credentials are not up to snuff, look as the icons themselves in the svn

http://websvn.kde.org/trunk/playground/artwork/Oxygen/theme/svg/

I think we all will be UNpleasantly surprised. The new Kmail icon is a black stick crossing tiny tiny envelop. The most distinguishing features of the new Kaddressbook icon are holes in the "rolodex" card (anyone still remember those?)

I just ran a small "lets see how distinguishable are you at 16 pixels test" - most of the major application icons sucked at small sizes. Sometimes closed-doors development can make a major product launch a dud.


By Daniel "Suslik" D. at Mon, 2006/06/05 - 5:00am

> I just ran a small "lets see how distinguishable
> are you at 16 pixels test" - most of the major

That test makes currently zero sense:

- as the script which created the icons in SVN from vector graphics had some bugs.
- as small icon sizes (16x16, 22x22) always need to be fine-tuned manually. That step is always the hardest and the most critical one and that final finishing hasn't happened yet.
- as the development of Oxygen is still very much work in progress and the icon theme pretty much incomplete.

I know that the previous icon themes had the same problems at that stage of development (quickly scaled down icons were considered colorful hard to distinguish blobs back then). So just be patient and give it some time. As someone who was involved in creating the HiColor icon theme and with the initial development of CrystalSVG I actually think this looks very promising already :-) And don't forget that the creators of Oxygen (David, Ken and Nuno) have very much experience with creating icon themes even behind "closed-doors" already. So they know what they are doing.


By Torsten Rahn at Mon, 2006/06/05 - 5:00am

As someone who worked on an icon set before, you should probably already know how to approach the creation correctly. 1st you think of a concept that is potentially good and distinguishable at small sizes, then you artistically blow it up.

The way I see Kontact and Kmail icons created (the most commonly used apps after Konqueror) - "Lets how how well I can draw a pen or an assorted stack of paper. We'll optimize whatever I come up with to small sizes as an afterthought."

I admire pinheiro's ability to recreate real objects with vectors, but I think in some rare but important things (like the kmail icon) he put the horse before the carriage. Internally he even exports the Kmail icon as ../pics/new oxygen/svg/pen.png - talking about people's priorities and understanding of the purpose.

All artsy ppl have an affliction of doing things because they "can", not because they "should". I wish they would be more open to input from "dim whit" public, at least in important things like icons for Kmail.

Not to come empty handed - over impose an @ sign over something like this
http://www.handmadeinteractive.com/lufthansa/images/seal.jpg
Crude but instantly detectable at small sizes and rather unique.


By Daniel "Suslik" D. at Mon, 2006/06/05 - 5:00am

> 1st you think of a concept that is potentially
> good and distinguishable at small sizes, then
> you artistically blow it up.

If you really really want to have something in the end that adheres to usability so much that you can essentially forget about the look then this might be a possible approach. Oxygen on the other hand is not an icontheme which is purely meant to focus on usability only though.

Creating icons is a highly iterative process. If you start off while putting too many limits onto yourself the result will be quite limited (in terms of artwork) itself.
It's much more creative, innovative and challenging to start by creating something "impossible" just following the artistic vision. Once your vision has become reality it's time to strongly look at the "rough edges" in terms of usability, accessibility and implementation without loosing the focus for the original vision. At worst you have to rethink and redo pieces at that stage after having reached for the sky.

There's no question that earlier icon themes like HiColor, Windows 3.0, Mac OS 9 etc. were modelled sticking without compromises to the usability vision (and sticking to the workflow you suggested). However these days the compromise between usability and artwork has shifted a lot towards the artwork part (resulting in iconthemes that focus less on usability like Vista, Mac OS X, etc.). And people choose their desktops based on the first visual impression and tend to stick to it. So making it look really good is mandatory. Pushing the limits is mandatory, because we can.


By Torsten Rahn at Mon, 2006/06/05 - 5:00am

"he put the horse before the carriage. Internally he even exports the Kmail icon as ../pics/new oxygen/svg/pen.png"

sory i dont folow you there.
The apps icons should funtion in small sizes thats true, but they should also be appeling in large sizes, done in svg, coerent in all szes, work has marketing material.
That what we try to do in Oxygen ofcourse we wont please every one, and ofcourse we still have lots of work to do, and lots of imput to get.
Every work is made of several stages we now think we can enter a new stage, hope you can help us to make the best icon set ever.


By pinheiro at Mon, 2006/06/05 - 5:00am

"hope you can help us to make the best icon set ever."

How open is the team towards reopenning the discussion of what goes onto icons of main KDE apps? My primary interests: Kmail, Kaddressbook.

Again, my issue is not with the quality of drawing, it is with the quality of composition (chosen pieces, size-significance of pieces, intent / conveyance of each item)

If someone would like to REopen a discussion on a particular IMPORTANT icon. Is there a mailing list / forum where proposals may be posted and openly discussed?

Every time you say "lets see you do better" you should also qualify if "doing better is still allowed for submission / consideration" Otherwise, it looks like vailed paw swipes from under the bed "no-caps" Aaron likes to present (see bellow. :) )


By Daniel "Suslik" D. at Tue, 2006/06/06 - 5:00am

Just feel free to post your suggestions on kde-artists@kde.org or visit #kde-artists on freenode or mail your opinion to nuno, ken or david directly. I guess they are open to any constructive ideas for improvement. And I know that if you come up with a good suggestion they won't be able to resist from even repainting the icon from scratch if necessary;-)


By Torsten Rahn at Tue, 2006/06/06 - 5:00am

I do crystal icons and I know it is a overtly designed set. Just keeping with the icons done already is a lot killing to infuse details. Finally at 16x16 most detailing go poof!
No No, bitmap handywork at 16x16 can't bring the details gone. I work on OOo set and just open the svgs in inkscape and you will know for sure.
Good about Oxygen is that it looks better than crystal. But much handywork is needed for smaller sizes. May be somewhat more than the real icon designing.


By Manik Chand at Mon, 2006/06/05 - 5:00am

> But much handywork is needed for smaller sizes.
> May be somewhat more than the real icon designing.

Right. I remember that I wanted to have a teddy bear for the HiColor iconset packages_toys icon. At that time it was mandatory not to use the alpha channel (because X wasn't able to use it) and a fully transparent background and therefore not having antialiasing available.
I started to paint the 32x32 version first:
http://websvn.kde.org/tags/KDE/2.2.2/kdebase/pics/hicolor/hi32-app-packa...

Once I was done with it somebody laughed at me: "How do you want to accomplish that in 16x16 pixels?" It took longer than creating the 32x32 version but without having created the 32x32 as a "target vision" first in the end I probably wouldn't have created an icon half that good let alone deeming it possible ;-)

http://websvn.kde.org/tags/KDE/2.2.2/kdebase/pics/hicolor/hi16-app-packa...


By Torsten Rahn at Mon, 2006/06/05 - 5:00am

I would not fault Oxygen for what is a general problem. It was decided that new icons must be SVG and must also include 16x16 and 22x22 PNGs. The reason for the small icons being required is that simply rendering the SVG to those sizes tends to produce a fuzzy colored blob rather than an icon. :-) The more detailed the SVG icon, the worse the problem.

The intent is that these small icons _must_ be hand optimized. Unfortunately, what many have done is simply render the SVG to 16x16 and 22x22 PNG with either this script, InkScape, or The GIMP thereby totally defeating the purpose of this and simply wasting space.

To be clear: 16x16 and 22x22 icons must be hand optimized PNGs and many icons are improved in 32x32 (and possibly even 48x48) when hand optimized PNGs are made as well.


By James Richard Tyrer at Tue, 2006/06/06 - 5:00am

"Sometimes closed-doors development can make a major product launch a dud."
This is very true. And in this case doubly so. I say this because what the Oxygen project promises and what they are delivering are inconsistent.
What ever happened to the standard answer that used to be given that the community decides which is the default for KDE4. The answer is it never was! The Appeal team controls all of the decisions behind closed doors. The default will be Oxygen because they know best. Who gives a crap what anybody else says. This message will continue to be echoed all though out KDE now. Welcome to the new Kworld order.
The Oxygen stinks in here, where is the unparalleled consistency and unmatched beauty that we were promised? If Oxygen was an open project there would have been a lot of people fixing patching contributing improving. It would have been healthy for KDE. The Tango team does it right in this area. You guys did not just miss the boat you missed the whole dock!


By Holding nose at Mon, 2006/06/05 - 5:00am

> What ever happened to the standard answer that
> used to be given that the community decides
> which is the default for KDE4.

Who says that KDE is a total democracy? It never was.
Actually no Open Source project even is. I guess you got certainly something wrong there.
While the KDE team values the input of its users and certainly takes it serious KDE never was designed by community vote.

> The Tango team does it right in this area.
> You guys did not just miss the boat you missed the whole dock!

Bla! You are aware of the fact that Tango had been developed at Novell under NDAs for months before it was finally released to the public?

So there's no difference compared to Tango concerning that.

Having a closed intial period is not uncommon for OpenSource projects.


By Torsten Rahn at Mon, 2006/06/05 - 5:00am

Hmmm you are an Appeal member if I am not mistaken.

>Who says that KDE is a total democracy? It never was.
>Actually no Open Source project even is. I guess you got certainly something >wrong there."

>"While the KDE team values the input of its users and certainly takes it serious KDE never was >designed by community vote."

Before Oxygen was publicly named as the default there was some discussion on IRC about whether it would be the default. The answer always seemed to be along the lines of the defaults are not for us to decide that if the community excepts it as the default that would be great.(The humble artists approach.) I witnessed this type of response several times before it was named default that is what I was referring to.
Before Appeal was created decisions as to the defaults were discussed openly on a mailing list giving all interested people the ability to weigh in on the matter. Sure someone eventually made a final decision but at least people could be involved even in even a small way. That is no longer the case.

>"Bla! You are aware of the fact that Tango had been developed at Novell under NDAs for months >before it was finally released to the public?

>So there's no difference compared to Tango concerning that.

>Having a closed intial period is not uncommon for OpenSource projects."

I was referring to the success of Tango's community involvement currently. Not it's beginnings. As I am questioning Oxygens current state. There is a huge difference in the current way things are developed between the two projects. IMO Tango has the right formula and it is wildly successful. They have a few top tier artists tightly managing a very active community of contributors. I believe that for the Oxygen team to not follow Tango's example at this point would cause them to miss not just the boat but the whole dock. IMO.

>Having a closed intial period is not uncommon for OpenSource projects."

Bla! Blah! Are you saying that Appeal and Oxygen are still in a closed initial period?


By Holding nose at Tue, 2006/06/06 - 5:00am

Like Tango we now planed from day one to open the theme to the cummunity help, this is the stage we are now entering.
Hope we can get your help has well.
About the defoult thing, no one till this day said it would be kde4 defoult theme, i halyays belived that it has god chances of being couse we are working so hard at it and adresingin so many old questions wen making it.
But im kite sure that if we simply (do not deliver) there wont be any oxygen in kde.
Suming it help us make the best theme ever the theme is now in svn donwload it see it make your improvments send them to us or svn you feedback is also apreciated.


By pinheiro at Tue, 2006/06/06 - 5:00am

Wow that is news!
Where will the Oxygen team be accepting submissions? kde-artists mailing list or...? IRC #kde-artists or...? Will it be similar to Tango in this regards or is there another plan underway?


By Holding nose at Tue, 2006/06/06 - 5:00am

stay tuned we hope to update the site in the coming days on the subject, rmember its alwys esay to email me Ken or David we will surely read it and try to respond, we dont think we are the howners of the truth in fact we do beleve that 2 heads think beter than 1 we just had to frist design somthing that was coerent, for starters betwen all of us.


By pinheiro at Wed, 2006/06/07 - 5:00am

Like I said before this is breaking news. As nothing like this has ever been said about Oxygen before. It will be interesting to see what happens in this area.


By Not holding nos... at Wed, 2006/06/07 - 5:00am

> Hmmm you are an Appeal member if I am not mistaken.

Yes, and of course a member of the Illuminati. I suppose you are an anonymous coward trying to spill shit from the safe _closed_ dark onto the work of others. Really, I love your obvious believe in transparency & openness.

> Sure someone eventually made a final decision

Yeah and that someone usually is the KDE artist team who maintains the respective current theme in KDE svn. And of course the KDE artist team always took feedback from the public into account for the development. That's after all why Oxygen exists: It tries to take the good aspects from Crystal and adds a lot of elements that were requested by the community ("less cartoonish", "better colors", "less colorful").

Just as an exercise you might want to tell me how choosing Crystal (which initially was developed behind "closed doors" at Connectiva) as a default icon theme over HiColor was the result of a public community discussion voting on mailing lists ( when in fact it was _not_ ).

> Not it's beginnings.

But Oxygen _is_ still in its beginnings. And with Oxygen being released to SVN the artist team has completed another milestone successfully. Still there is enough open work ahead that will probably take many months until Oxygen is at 1.0 stage.

If you are really interested in KDE's decision making process I'd urge you to go and read a book (while having a cup of good hot chocolate) which deals with the social aspect of open source development. KDE isn't very much different from other projects with regard to this. You'll find out that KDE's development as a social phenomen is much more complex than you'd like it to be. So complex actually that there are scientific papers which focus on that aspect within KDE.


By Torsten Rahn at Tue, 2006/06/06 - 5:00am

>Yes, and of course a member of the Illuminati. I suppose you are an anonymous >coward trying to spill shit from the safe _closed_ dark onto the work of others.
>Really, I love your obvious believe in transparency & openness

LOL! If I want to make statements and ask questions in an anonymous way that is my perogitive and my right. If it was not, the option would not be open to me here at the dot. This does not deminish my point or my questions.
You do not need to defend your position and I am surprised that you did. I am not spilling shit onto the work of others. I was merely pointing out that you are an Appleal member nothing more nothing less.

In all honesty Penhiro answered my questions and made available information that was never mentioned anywhere that I know of before.

>Yeah and that someone usually is the KDE artist team who maintains the >respective current theme in KDE svn. And of course the KDE artist team always >took feedback from the public into account for the development. That's after >all why Oxygen exists: It tries to take the good aspects from Crystal and adds >a lot of elements that were requested by the community ("less cartoonish", >"better colors", "less colorful").

After a quick search of the kde-artists mailing list on gmane.org (for the word decisions) I came across a post from the primary maintainer of KDE artwork in response to a curious potential contributor. It was stated that all of the decisions concerning default artwork is discussed on the mailing list. Discussing the defaults openly is not something I invented nor have I once until now written the word Vote. I was hard pressed to find any discussion about the Oxygen theme between the creators and others as you imply above. Other than an announcement about the launch of the website.
However the results for "less cartoonish", resulted in "No documents match your query". A subsequent search for "cartoonish" returned 2 pages but alas nothing in relation to Oxygen. A search for "better colors" returned 6 pages but once again no results related to Oxygen. A search for "less colorful" resulted in one page with a post made by you in 2002-04-30 in regards to crystal.

Here is my point before Appeal decisions were made openly on the mailing list now they are not. On one hand Penhiro says he never expected Oxygen to be the default on the other hand in the announcement made after Akademy on this very site it is stated very clearly that it was always intended for the default. The decision for Oxygen to be pushed as the default was decided through channels other than what were previously defined by the primary maintainer with his blessings. The reality is decisions have been made off of the list this is a break from the ways things have been done in the past. If decisions will continue to be made off of the list then there should be an announcement on the list that decisions will no longer be made on the list. At least let people know how the decisions will be made from now on rather that just making moves in SVN and then announcing it after the fact.

>If you are really interested in KDE's decision making process I'd urge you to >go and read a book >(while having a cup of good hot chocolate) which deals with >the social aspect of open source >development.

With Appeal members holding various key positions (The KDE.eV board, HIG and CIG and Marketing work group) I think I will wait until a book has been written that discusses the effect that Appeal has had on the decision making process within KDE. It could even be positive but there is no way of really knowing is there.(I am a glass of straight good Scotch man myself I find it a bit more warming with a longer lasting side effect. :) Never really acquired a taste for chocolate myself.) But thanks for the tip. ;)


By Holding nose at Tue, 2006/06/06 - 5:00am

s/perogitive/prerogative


By Holding nose at Tue, 2006/06/06 - 5:00am

Very honestly if we dont suport enough information about what we do is becouse we simple dont have time for that, i'm totaly sure this is a bad thing but we are so busy making so much work we cant find time to deliver that output, i hope we can in the near future.
The problmem is that in the end brain commands me to make art not documentation, (be sure i know this is wrong) sory.


By pinheiro at Wed, 2006/06/07 - 5:00am

> the community decides which is the default for KDE4.

erm, that was -never- intimated or promised. what was said, and what we have been doing (so our actions match the words), is that we were going to working more with users and the community at large when designing and creating kde4. that has certainly been done, but no project of any sort of size and coherence does "design by popular vote". there has been an unprecedented amount of community and end-user feedback for kde4.

> The Appeal team controls all of the decisions behind closed doors.

care to back that up with some facts? no, you can't because it isn't true.

> Who gives a crap what anybody else says

i get the feeling you have a particular event in mind. care to share what it is?

> If Oxygen was an open project there would have been a lot of people fixing
> patching contributing improving. It would have been healthy for KDE.

erm ... you want to contribute to the icon set? break out your graphics app and rev up the pixels! somehow i really doubt that if you start contributing quality oxygen styled icons they won't end up svn ;)

but consider: there needs to be a unifying look and feel, a vision behind the visual concepts. that isn't something that "a lot of people fixing patching contributing" is good at producing. that part is largely done at this point now thanks to a small team of hard working individuals.

> The Tango team does it right in this area.

first off, the tango team worked for quite a while in complete secrecy (~1 year iirc?). oxygen was announced pretty much from day 0. as results that demonstrate the concepts have become available they have also been shared immediately. so if you want to talk openness, Tango isn't the winner here.

as for quality of final product, i think the results speak for themselves. go look at the tango icons, look at the oxygen icons ... tell me which look better.


By Aaron J. Seigo at Mon, 2006/06/05 - 5:00am

To answer most of your statements above I refer you to the last post I made to Mr. Rahn.

I only have this to add.

>as for quality of final product, i think the results speak for themselves. go >look at the tango icons, look at the oxygen icons ... tell me which look better.

Based on an overall assessment of the current state Tango would harbor more votes than Oxygen. Oxygen has a few very stunning icons mixed with a bunch questionable ones at this point. But as Pinhero pointed out they will be working in a similar manner as Tango and including anybody interested in improving the current set in SVN. This could give the set the boost it needs. And I could see it overtaking Tango on overall look and feel eventually. And yes everyone is a critic. :)


By Holding nose at Tue, 2006/06/06 - 5:00am

tango's had longer to mature, yes. but (and be sure you're looking at the oxygen icons in svn, not the website) look at the style concepts and final artwork of what exists right now. it's rapidly becoming more consistent and the ideas of clear visual icon class separation, colour usage and composition is several steps ahead.


By Aaron J. Seigo at Wed, 2006/06/07 - 5:00am

16px icons? are you serious? i suppose you use an 8 bit display as well. and a 16 bit processor. with 4MB of ram. and no hard disk.

it's not the 1980s anymore. it's time we moved on to new breathtaking heights like 32px or even 64px icons, particularly when it comes to application icons and filemanager views.

i'll take amazing 32px icons with crap (or even no 16px) icons over good 16px icons (which are never good, btw; there's not enough information in them to be anything better than "ok" imho) with good 32px icons.


By Aaron J. Seigo at Mon, 2006/06/05 - 5:00am

I'm sorry Aaron, but most people use 16px icons in their system tray, I'm also pretty sure you use it. Mostly because I don't know that it's possible to change the size of the system tray icons.

-Pascal


By pascal at Tue, 2006/06/06 - 5:00am

Nah, system try icons are 22 pixels.

The only time you use 16 pixel icons in KDE are when you specifically set your toolbars to that size, or when you have launcher icons on a "tiny" sized panel (in that case, the 22 pixel system tray icons are just cut off).


By Dolio at Tue, 2006/06/06 - 5:00am

as Dolio said, systray icons in kde are 22px and have been for some time. fact checking is good ;)

but let's pretend they -were- 16px icons down there in the systray. that would be a really poor idea (16px is -tiny-, rather hard to hit with the mouse and very low amount of information) and in kde4 we'd -fix- that by making them larger. in kde4 we can change what sucks and make good decisions for today as well as tomorrow. we're not beholden to how things are (though it admitedly does require a bit of imagination to get past that)


By Aaron J. Seigo at Tue, 2006/06/06 - 5:00am

"it's not the 1980s anymore. it's time we moved on to new breathtaking heights like 32px or even 64px icons"

This is utter B.S. aaron and you know it. Title bar and task button icons are 16 pixels. For majority of people, so that the system tray would not look like a task-bar, icons there are also 16 pixels.


By Daniel "Suslik" D. at Tue, 2006/06/06 - 5:00am

the task bar is only 16 pixels because nobody has bothered to fix the taskbar. did you know that there is already support in kwin for larger icons? or where do you think the 32px icons in the alt-tab window switcher come from?

as for the "taskbar not looking like systray" that's also rubbish =)

expect changes here in kde4. 16px icons are usability hell.


By Aaron J. Seigo at Wed, 2006/06/07 - 5:00am

Actually, the usability of 16x16 icons depends on the format of your screen and its size. If you have 1024x768 or less, they are usable unless you have a *really* small screen. They probably *are* useless if you have a screen resolution of much more than 100 DPI.

Perhaps it would be possible to have the TaskBar icon size automatically set based on the size and format of the screen in the X configuration file.

Also, IIRC the system tray icons are 24x24 not 22x22. And, you can't just change that because the larger icons probably don't exist.


By James Richard Tyrer at Wed, 2006/06/07 - 5:00am

However Baghira is vastly popular. And concerning your comments: I don't think that Thomas is meant to be responsible for the artwork part but for creating the actual code after specifications made by the artists. And in that department he has obviously been very successful already.


By Torsten Rahn at Mon, 2006/06/05 - 5:00am

I like it, but please don't use brown for the folders...i find it ugly, i really like the blue one :)


By Giovanni Venturi at Fri, 2006/06/09 - 5:00am

Warning: main(http://commit-digest.org/index.inc): failed to open stream: HTTP request failed! in /home/kde-digest/public_html/issues/2006-06-04/index.php on line 1

Fatal error: main(): Failed opening required 'http://commit-digest.org/index.inc' (include_path='.:/usr/share/php4:/usr/share/php') in /home/kde-digest/public_html/issues/2006-06-04/index.php on line 1

:(


By anon at Mon, 2006/06/05 - 5:00am

I use DCOP quite often, I'm interested how DBUS can be used, what is for example the DBUS-variant of;
dcop kontact kontact-mainwindow#1 hide

What is the DBUS-equivalent of kdcop? I think kdcop is extremely nice to browse through the different options.

Thanks!


By LB at Mon, 2006/06/05 - 5:00am

DCOP has already been completely replaced by DBus in KDELibs and by the time KDE 4 is released 'kdbus' should be working replacement for kdcop. Considering that D-Bus's design was based on/inspired by dcop it shouldn't be any problem in KDE 4 to do things like that (hopefully more functionality will be exposed in the KDE 4 version of programs).


By Corbin at Mon, 2006/06/05 - 5:00am

I asked Thiago, trolltech employee responsible for the Qt d-bus bindings, about how extensively d-bus was going to be supported. He said that each Qt object has a property and if that propery is enabled then that slot/signal will be accessible via d-bus. (I've forgotten the name of the property at the moment though.) The compiler will do the work so adding d-bus support at that level will be trivial.


By Anon Cow. at Mon, 2006/06/05 - 5:00am

"What is the DBUS-equivalent of kdcop?"

My initial guess would be kdbus, and some search reveals:
http://www.kde-apps.org/content/show.php?content=34692

Why not give it a try? If you report your impression as a kdcop user to the developers, it may help them make it even better than kdcop.


By Morty at Mon, 2006/06/05 - 5:00am

As far as I understood, the "external" dcop interface you are using manipulate
kontact will remain unchanged, the same is true for the dcop tool.

The changes are that the dcop tool will communicate with the applications via
the dbus daemon, and no longer via the dcopserver.


By ac at Mon, 2006/06/05 - 5:00am

So if the Oxygen team themeselves say:

"When possible action icons should be compound of a single element. More than two elements will make the icon to look too crowded and not usable at all. "

Then why does the configuration-icon have two elements? A screwdriver and a wrench, why not just the wrench???


By KDE User at Mon, 2006/06/05 - 5:00am

Well, it says "When possible"...


By Luca Beltrame at Mon, 2006/06/05 - 5:00am

Pages