KC KDE #23 is Out
Friday, 2 November 2001 | Numanee
Aaron J. Seigo wrote in to point out that a new issue of the worthy Kernel Cousin KDE is out. This week, read updates on multimedia in KDE3, future plans for Noatun, the elusive PyKDE2, a brand new JavaScript engine, and more. Hopefully, we'll also get some details on the new DCOP drooliness (more, more, more) soon. :-)
Comments:
PyKDE2 - Peter Clark - 2001-11-02
I for one am very excited about PyQT/PyKDE. I've been teaching myself Python and love how quick and easy it is! I've been wanting to make a couple of GUI programs, and it would be great to have something sit in the kicker as a native KDE app. One thing that concerns me, however, is that KDE3 will probably out, or almost out, once PyKDE2 comes out. Is this going to present a problem, or will the porting issues be slim/none? Boudewijn, any plans for a book on PyKDE? :) When will your book on PyQT be published? I haven't had a chance to go through the final draft (http://stage.linuxports.com/pyqt/book1.htm) yet, but I might buy the book if I can save enough of my pennies. (P.S. Remember me from the conlang list? I need to sign up again, now that my life has settled down some. :) :Peter
Re: PyKDE2 - FO - 2001-11-02
the port from pykde2 to pykde3 will be relativly easy compared to pykde to pykde2. remember that kde2 was a near rewrite. also, in pykde2, changes/improvements had to be made to sip.
Re: PyKDE2 - Rakko - 2001-11-04
Greetings, fellow conlanger! :O) I didn't even know he was writing a PyQt book. Cool! Very cool.
Different uses of Kmail - Alain - 2001-11-02
> First you can configure a special sent-mail folder for each identity you have (if there's none selected, we use kernel->sentFolder()). Secondly, this adds an option (a combobox) to the composer window to allow me to select a different one for that specific message." Anybody has his own needs. The mine is to keep in history folders (like "family", "job" and so) all the mails, those received from somebody and those sent to the same somebody (it's easier to retrieve exchanges in a common folder...). It is good/bad done with Kmail. Very good done with received mail. There is a filter to create and it runs... Very bad done with sent mail. At first, in the history folders, there is not a "From" column (I posted a wish around 6 months ago, no news...) (it is a common feature, done in Outlook Express and Netscape Messenger). Then I don't reach to automatically send the mails in the history folders. The "from" option in the filter does nothing... So I must put manually my sent mails in the history folders. So, of course, it would be interesting for some ones to put in specific sent-mail folder according to the sender identity. But there are other needs, perhaps more important for the end users, usually using a single identity...
Re: Different uses of Kmail - Michael Häckel - 2001-11-02
> At first, in the history folders, there is not a "From" column (I posted a wish > around 6 months ago, no news...) Maybe you forgot to include the patch :-) > The "from" option in the filter does nothing... So I must put manually my sent > mails in the history folders. Filtering according to the from header actually works well here. You didn't for example confuse "contains" with "eqals to" or something like that?
Re: Different uses of Kmail - Alain - 2001-11-02
>> At first, in the history folders, there is not a "From" column (I posted a wish around 6 months ago, no news...) > Maybe you forgot to include the patch :-) ? I don't understand... I am on KDE 2.2.1... >> The "from" option in the filter does nothing... So I must put manually my sent mails in the history folders. > Filtering according to the from header actually works well here. You didn't for example confuse "contains" with "eqals to" or something like that? No, it's "equals to" (and "contains" is not bad...). I test again now on a new filter and it is bad too, my sent emails are always going in the sent folder... Aaaah, no, no, it's good : there is another parameter : apply to both, sent and received messages. By default it is on received only... I don't understand why it is not on "both"... It would be many more natural to have "both" by default... Well, good thing. Now, please, explain me this "patch :-)"...
Re: Different uses of Kmail - Alain - 2001-11-02
> By default it is on received only... Hmmm, no it is on new messages. > I don't understand why it is not on "both"... It would be many more natural to have "both" by default... Hmmm, no more, "both" gives duplicate message. It seems that replacing "contains" by "equals to" was the good explanation... But I am not sure (it seems without effect with received mail)... Sorry I am confused, I don't explain what thing was wrong... Perhaps it was me, the verifications of my tests were bad ?? I don't think because I tested at each new version, 2.1, 2.2, 2.2.1...
Re: Different uses of Kmail - Alain - 2001-11-02
Waooh, 7 messages and 4 from me, I am the best today ;-)... After a good lunch, I tested again and I am less confused, I now understand.... My first idea was good : I need to put the "advanced parameters" to "both". My trouble came that for testing, I sent email to myself and I mixed the sent and received messages, believing they were all sent... So I was right when I said : > > It would be many more natural to have "both" by default... For a user, it is not obvious to change the default option of an "advanced" parameter which disables a useful and used feature... and is almost in duplicate use with the "from", "to" etc options...
DCOP Examples for KDE 3.0 - ian reinhart geiser - 2001-11-02
For those of you who do not randomly dig arround KDE with KDCOP, I want to give and update of its current progress. I have added DCOP intefaces to some of the lower level libraries of KDE. This has caused some interesting side effects. Now all every main window of every KDE appliaction can be controlled via DCOP. Using the following code you can move your kate window: > dcop `dcop kate-*` kate-mainwindow#1 move 100 200 Now the exciting thing is that this is available to all applications and there was no code added to Kate to do this. There are quite a few of these base DCOP interfaces I have added for KDE 3.0 and I hopefully will get some userland documentation out there for people to play with. The other issue is the tool KDCOP. It has undergone some tweaks to help developers and end users use DCOP more for automation and development. I have attached a screen shot of the new KDCOP. Features include: * Copy return data to clipboard * DND DCOP calls from the tree in multiple languages (Python, C++ and Shell for now) * Whole mess of new data types supported (Pixmaps, colors, fonts) While these are not all fully working yet, we should see them in full force for KDE 3.0 Stay tuned... this is going to get very interesting, at least if you get into DCOP ;) -ian reinhart geiser
Re: DCOP Examples for KDE 3.0 - ian reinhart geiser - 2001-11-02
Oh one more screenie...
Re: DCOP Examples for KDE 3.0 - KDE User - 2001-11-02
One word... *killer*!
Re: DCOP Examples for KDE 3.0 - Jason Tackaberry - 2001-11-03
Very cool! :)
DCOP for KDE 3.0 - Thilo - 2001-11-03
as i'm no coder yet (i know, i keep saying that )-: i would like to wish for the following: wouldn't it be super cool to have a lirc->dcop bridge and that way being able to control the whole desktop with a remote?! combined with the recent dcop developments, this would enable lirc control to every kde app -> and THAT would just be way kool... Thilo
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-03
Whoa back up the truck Zeak! This is not a good idea for two reasons: a) AFAIK there is no good way to authenticate a username passowrks with DCOP. Everything happens via magic cookies. b) Allowing access to your desktop via something as easy to hijack as IRC would be suicide in its own right. Instead what we want to do is use something like XMLRPC or SOAP over SSL. This way we can authenticate with the standard methods of username and password. Now here lies the real rub. I have to write a SSL based HTTP server on my own and I have tried and failed twice now. Ideally this would be nice but I just do not see it as a reality until we can do this in a safe mannor. -ian reinhart geiser
Re: DCOP for KDE 3.0 - Arondylos - 2001-11-03
I think he did not mean (nor write) controlling the KDE desktop via IRC, but with lirc - lirc is AFAIK a project to enable infrared controllers to communicate with Linux (mainly remote controls). http://www.lirc.org/
Re: DCOP for KDE 3.0 - Thilo - 2001-11-03
well, i don't know if we are talking about the same, but if you are talking about infrared devices, then you sure got some security concerns. there is nothing wrong about that, but nobody has ever tried to hijack my digital receiver box by faking infrared signals. :-)) i am sorry if i have not made myself clear in the last posting! i am talking something like kgesture but for infrared remotes. you start klirc (or whatever) and when you press the play button on your remote the movie starts or something. this would make many writing lirc plugins (for noatun for example) obsolete, because as long as the app has a dcop interface you can also control it via the remote. you could use the remote to control a kpresenter presentation! as i only unterstood half of what you suggested afterwards, i suppose it is great too... keep up the good work! thilo
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-03
Oh i am an idiot. It is still too early in the morning here. Yes Infrared control would rock very much so. I think there is some work done in the area all ready too. Once KDCOP can export DCOP command lines correctly it would be very easy to create an application that would proxy commands to DCOP from the infrared control. Sorry about that. :P -ian reinhart geiser
Re: DCOP for KDE 3.0 - ik - 2001-11-03
are there ways to do this ? then we are able to remotecontrol KDE right now ... - querying the active window/app ... with dcop - maximizing/minimizing/closing it even if it doesn't have a dcop interface ...
Re: DCOP for KDE 3.0 - Thorsten Schnebeck - 2001-11-04
Yes, I have a LIRC-scripted kpresenter-setup - sooo coool: The basics: my .lircrc ("RAX9" is my remote control and "button" are the defined keys): begin remote = RAX9 button = cd-play prog = irexec repeat = 0 config = lirc_kpresenter screenNext end begin remote = RAX9 button = cd-disk_skip prog = irexec repeat = 0 config = lirc_kpresenter screenStart end and lirc_presenter looks like this #!/bin/bash KPRESENTER=`dcop | grep kpresenter` dcop $KPRESENTER View-0 $1 Have fun! Thorsten
Re: DCOP for KDE 3.0 - aleXXX - 2001-11-05
yes, or even simpler begin remote = RAX9 button = cd-disk_skip prog = irexec repeat = 0 config = dcop someobject somecall end That's what I use. Bye Alex
Re: DCOP for KDE 3.0 - ik - 2001-11-06
that won't work with kde3 anymore (now you can call kpresenter-4564 as kpresenter, but that won't be possible anymore)
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-06
dcop `dcop-*` will call the first instance of the application. or you can do a dcop `dcop start` to start a new application and call a dcop function. look forward to some more verbose examples in the comming weeks. -ian reinhart geiser
Re: DCOP for KDE 3.0 - Thorsten Schnebeck - 2001-11-06
"dcop start" looks dangerous (?) Can I start a bash-script #!/bin/bash rm -rf * kpresenter ?? Bye Thorsten
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-06
BAH! You people need to read documentation before you freak out. 1) You example makes no logical sense what so ever. In fact it would be easier for the user just to type sh `rm -rf /` at the command line. 2) On the off chance you read about dcopstart you would find that it starts an application via kdeinit and returns the string in a form so that dcop can grok it. I mean people, do you read about this stuff before you write that "dcop" will end the world. It is only as secure/insecure as shell. One would think that if Unix email/shell was so insecure that after 30 years we would have as many viruses as windows. Guess what, WE DONT! Now if it sounds like I am going off on you, I am not, I am going off on everyone who keeps trying to spread the word that dcop is the source of all evil here. Please do not be offended but honestly this is a dead subject that has been beaten into the ground over and over again. So unless you can come up with a virus that can spread in the manner than this is all just speculation. Waldo obviously gives the things he does thought and I am sure he would never have written dcopfind, and dcopstart without any thought on secureity. So please EVERYONE, not just Thorsten here. Read the docs, play with the commands. Look at what dcop and UNIX can and cannot do. You will see that we have opened no new holes in secureity. If anyone has any actual real questions on this subject please do email me or post them here, but please first think them out. Read the docs, and _try_ these ideas first. So far no-one has shown me a script that I can "accidentally" run and destroy my system. The closest thing I can come up with is a script that opens up 20000 instances of Konqi on my desktop. Even then I still have to chmod +x it, just to run it... If the user is smart enough to chmod +x a file, they are more than likely going to ask "Why am I doing this?", "Why am I setting a random text file I recieved in the email from a total stranger to executable mode?". Okay with that said, I want to apologize to all I have offended. -ian reinhart geiser
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-06
BAH! You people need to read documentation before you freak out. 1) You example makes no logical sense what so ever. In fact it would be easier for the user just to type sh `rm -rf /` at the command line. 2) On the off chance you read about dcopstart you would find that it starts an application via kdeinit and returns the string in a form so that dcop can grok it. I mean people, do you read about this stuff before you write that "dcop" will end the world. It is only as secure/insecure as shell. One would think that if Unix email/shell was so insecure that after 30 years we would have as many viruses as windows. Guess what, WE DONT! Now if it sounds like I am going off on you, I am not, I am going off on everyone who keeps trying to spread the word that dcop is the source of all evil here. Please do not be offended but honestly this is a dead subject that has been beaten into the ground over and over again. So unless you can come up with a virus that can spread in the manner than this is all just speculation. Waldo obviously gives the things he does thought and I am sure he would never have written dcopfind, and dcopstart without any thought on secureity. So please EVERYONE, not just Thorsten here. Read the docs, play with the commands. Look at what dcop and UNIX can and cannot do. You will see that we have opened no new holes in secureity. If anyone has any actual real questions on this subject please do email me or post them here, but please first think them out. Read the docs, and _try_ these ideas first. So far no-one has shown me a script that I can "accidentally" run and destroy my system. The closest thing I can come up with is a script that opens up 20000 instances of Konqi on my desktop. Even then I still have to chmod +x it, just to run it... If the user is smart enough to chmod +x a file, they are more than likely going to ask "Why am I doing this?", "Why am I setting a random text file I recieved in the email from a total stranger to executable mode?". Okay with that said, I want to apologize to all I have offended. -ian reinhart geiser
Re: DCOP for KDE 3.0 - Thorsten Schnebeck - 2001-11-06
Ok, ok calm down. dcopstart is new AFAIK and not in the KDE_2_2_BRANCH. So time will tell if its secure or not. I like controlling my running processes via dcop and as I said somewhere in this thread: I don't know any method to start a new program - and so dcopstart is a little bit alarming. Google is a big brain and will index this thread - so again time will tell... Bye Thorsten
Re: DCOP for KDE 3.0 - Aaron J. Seigo - 2001-11-06
you are completely missing the point. any shell script can start a new program. therefore dcop is no less secure and no more secure than your regular shell environment. if some application came out that filtered random network traffic into dcop then yes, that would be a problem now wouldn't it? however, the same would be true if it simply pushed that data directly to a shell. dcop is not a new breed of security concern.
Re: DCOP for KDE 3.0 - Thorsten Schnebeck - 2001-11-06
Err? Missing the point? Got the dot? :-) You and Ian are right. Dcop and dcopstart seems (as far as I can see) to be secure enough to not support an intruder to succeed. But dcop is a very powerful tool if your system is already infected. Checking KMails DCOP-Iface I was very pleased _not_ to see a slotSendOutbox() command. Things like KAdressbook needs to be very restrictive. OTOH it would be nice to have a global adressbook with a powerful DCOP interface for searching and getting infos for other KDE-programs (thinking of PIM and groupware stuff)... until "something" send to all your email address a nice letter maybe with a sweet private attachement :-( And thats _my_ point: If "something" _is_ behind this wall and _is_ a running process, what is to do to make DCOP safer or better say harder to misuse? Something like application interface registration? Only the user selected app1 and app2 can use the interface of app3? But such a configuration must be passwort protected, too, so nobody can change this as a running process... I dont know? Security is a hard job especially if you are not that paranoid :-) Maybe I only saw too much "viruses" in our Win-NT-LAN at work during the last months so I am a bit sensitizes what all can happen... Good night Thorsten
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-07
Again you are going off half cocked here again, let me explane to you why if you read the documentation before going off here this would all be a non issue Take the following script: #!/bin/bash # This is a KMail Virus KMAIL=`dcopstart kmail` TO="geiseri@kde.org" CC="" BCC="" SUBJECT="Hey look at me i am a virus" MESSGE="This script" dcop $KMAIL KMailIface openComposer $TO $CC $BCC $SUBJECT $MESSAGE 1 dcop $KMAIL kmail-mainwindow#1 activateAction send_queued ## Okay now let me tell you why this fails: A) The user much chmod +x the script to run and kmail will not run it automagicly. We went over this all ready but I thought we may need to review this factoid. B) On the off chance some other application did this then we would need to install this other application in the same manner on all other machines we want to infect. C) This is an inane example, if someone gets to the point where they can use dcop to cause damage then there are a million more simple things they can do to the system. Like I dont know, smash the keyboard! In short you have no real thought out arguments and are just trying to promote FUD against this new technology that people have worked very hard to make very good. As your homework assignment I want you to telnet into your box. And try to run dcop... For extra credit points do it from while sitting at your console. Then you will see how insanely shallow all of your fears are. I mean javascript is more dangerous than this. -A progressively grumpier ian reinhart geiser
Re: DCOP for KDE 3.0 - Thorsten Schnebeck - 2001-11-07
Ok, not that much time - so this is only a short one: A) + B) nothing new C) Scripting is attractive for misusing it, because a script can run on every system KDE support. FUD: Wrong, I like DCOP and use it every day. Homework: nothing new here, too. As I said, DCOP does not support an intruder to succeed. progressively grumpier: I don't see any reason: If you don't like my concerns I can not help you. As you said, this is the right place to discuss about a new technology. I'm not the one who said: I am right and you are wrong. I have some concerns. I thank you, for your help to give me a "better feeling". But calm down. Oha, I'm late Bye Thorsten
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-07
Again you are going off half cocked here again, let me explane to you why if you read the documentation before going off here this would all be a non issue Take the following script: #!/bin/bash # This is a KMail Virus KMAIL=`dcopstart kmail` TO="geiseri@kde.org" CC="" BCC="" SUBJECT="Hey look at me i am a virus" MESSGE="This script" dcop $KMAIL KMailIface openComposer $TO $CC $BCC $SUBJECT $MESSAGE 1 dcop $KMAIL kmail-mainwindow#1 activateAction send_queued ## Okay now let me tell you why this fails: A) The user much chmod +x the script to run and kmail will not run it automagicly. We went over this all ready but I thought we may need to review this factoid. B) On the off chance some other application did this then we would need to install this other application in the same manner on all other machines we want to infect. C) This is an inane example, if someone gets to the point where they can use dcop to cause damage then there are a million more simple things they can do to the system. Like I dont know, smash the keyboard! In short you have no real thought out arguments and are just trying to promote FUD against this new technology that people have worked very hard to make very good. As your homework assignment I want you to telnet into your box. And try to run dcop... For extra credit points do it from while sitting at your console. Then you will see how insanely shallow all of your fears are. I mean javascript is more dangerous than this. -A progressively grumpier ian reinhart geiser
Re: DCOP for KDE 3.0 - Eric E - 2001-11-03
That does sound cool, but it's a security disaster waiting to happen. In fact, the whole DCOP/KParts integration starts KDE down that perilous integration road that Microsoft has walked so poorly.
Re: DCOP for KDE 3.0 - Ian Reinhart Geiser - 2001-11-03
Greetings People who are not familiar with how dcop and M$ VB viruses operate tend to talk this way. The fact of the mater is that under UNIX even with DCOP and lets say a user who randomly downloads and runs shell scripts off the internet it will be very hard for the M$ sort of viruses to propigate. Under M$ when you click on the schell script from your mail client it will run. Under linux it is not that easy. File permisions must be set for a script to run, and afaik MIME makes no attempt to preserve file permisiions. So that brings us to the binary approach. Now again under winders this is easy because there is one OS, one Platform... In KDE world this is not the situation. I am on a PowerPC, your intel virus is not a problem for me. You could use compiled python but again, I must support that for the virus to work. Now I admit NO system on this world is a bullet proof system. But as you can see from the above examples it is VERY VERY hard to comprimise this. I reccomend reading up on how DCOP works, you will be surprised at how it allows us to have automation without giving away the farm so to speak. Once you have a technical understanding of the situation it is not so scarry, is it :) And also, on the off chance you do have a technical reason why you think the way you do please share it with me. I am very interested in makeing use this is a safe and secure system to use. I am very confused/interested in how KParts can be used to make a virus. -ian reinhart geiser
Re: DCOP for KDE 3.0 - Eric E - 2001-11-03
Fair enough - I was talking beyond the extent of my knowledge (out of my **se as some would say). I guess a lot of autoFUD starts that way. I'll be honest and tell you I doubt that I'll get around to digging through technical docs for DCOP just to banter a bit about making KDE secure. So if you have any good sources for synopsis or non-technical reading, those would be much appreciated. For here and now: As I understand it, you're telling me that the KDE is protected by *nix's userland security. Fair point. Nonetheless, many, many Outlook viruses are spread by people doing something dumb like clicking on an attachment, all in userland. I've actually spread the pretty park virus that way, and I've been a network administrator. Not to mention that damage in userland may well be more troubling than damage to the system, which can be reinstalled pretty easily these days. Does this come under discussion? How can we guard against that?
Re: DCOP for KDE 3.0 - Kevin Puetz - 2001-11-04
as he said, a unix script randomly recieved via email doesn't get run when you click on it, it gets opened in a text editor (no execure permissions, fall back to read). And an app probably wouldn't have anythign at all happen as it couldn't be executed either (no execure permissions) and no app would really want to claim it to open as data (khexedit maybe :-) To run it, one would have to save and chmod +x it (add execute permissions). This is a small hurdle if you wanted to run it, but a big one against you doing so by accident. Also, kde apps don't hide extensions (no readme.txt.exe showing up as readme.txt) so it would generally be far more obvious when something was trying to masquerade as harmless. Besides, by the time something can run dcop calls, it's already running and can make system calls (rm -rf ~ anyone)? DCOP is *not* a new security hole, it's only a tool for code that's already running anyway, and accidently running unwanted code running is something unix permissions do their best to make difficult. (*) Yes, I'm neglecting the kxmlrpcd and the interface it provides to call dcop. If you are running that in such a fasion that it's accessible by anything other than its mode 600 unix domain socket in your own home directory, you should know why and have thought about the security consequences. Otherwise, only code already running (see?) as either you or root can talk to it :-).
Virus - Thorsten Schnebeck - 2001-11-04
Looking how (especially) new Linux Users think: "Linux is save" is a little bit alarming. But I dont think dcop is "per se" unsecure. As far as I understand dcop it is a method to control running programs. I don't find a way to exec programs via dcop. The real problems is stuff like RPM and auto-update; I bet, the first deep "virus" impact on Linux works like "I-am-such-a-cool-program-and-everybody-wants-to-download-and-install-me.i386.rpm" So, if we think of a net-based KDE-Installer we deeply need a working certification system! Bye Thorsten
Re: Virus - Evan "JabberWokky" E. - 2001-11-04
Well, that wouldn't be a virus, now would it? It would be a trojan. -- Evan
Re: Virus - Thorsten Schnebeck - 2001-11-04
That's why I said "virus" and not virus :-) I think trojan is also wrong - it should be called greek ;-) Bye Thorsten
Re: Virus - Erik - 2001-11-04
No, it would be a "trojan horse". For those of you who don't know the difference, a "trojan" is a victim of a "trojan horse". So if someone fools you to run a "trojan horse" on your computer, then you are a "trojan". For the historical background, read the Iliad.
Re: Virus - Evan "JabberWokky" E. - 2001-11-05
I'm so glad you pointed that out. By that same reasoning, Linux, BSD and OSX all running KDE are completely and totally safe from all viruses. Of course, so are all versions of Windows, DOS, AmigaOS and Outlook. No virus problem whatsoever. Computer viruses, on the other hand... My best friend has spent years flying around the world lecturing and doing high end support for computer security with a focus on malicious code. He refers to them as Trojans. For years he's forwarded me stuff about malicious code, and they are simply refered to as either being a "virus", "trojan", "worm" or some esoteric halfbreed or theoretical construct. These are documents that go to everybody from the NSA, the RAF, or Reuters. If historical background had anything to do with technical terms, people would look at you with a blank expression everytime you referred to booting your computer (it's "executing bootstrap routines", a la the thing on the shoewear), everytime you mentioned a modem (Oh, you mean the Modulator-Demodulator?), and everytime you talked about a VGA card ("You know... the video gate array card!" "Hunh? A punched card or a S-100 bus interface?"). The difference between a trojan and a virus, however, is significant and when discussing computer security, using the correct term is important. -- Evan
dcop signals - ik - 2001-11-03
hmm, one thing that's still not there , but would be extremely cool imo is a way to publish (dcop) signals in dcop interfaces. then we could write programs that listen to arbitrary signals and perform arbitrary actions ..
Re: dcop signals - Ian Reinhart Geiser - 2001-11-03
Hmmm. afaik this is possible: http://developer.kde.org/documentation/library/dcop.html#sec2.2.5 Also there was a commit last night that added some new features to DCOP signals. -ian reinhart geiser
Re: dcop signals - ik - 2001-11-03
well, dcop signals are indeed possible, but it would be cool if a dcop object could say 'i sometimes emit this signal' via the dcop interface. now i can't see which signals "objects" emit in the dcop browser. it would be nice to see QPixmap blahbla() DCOPref blah() SIGNALS ======= clientDied(int pid); in the dcop browser.
Winamp Skins in Noatun... butching XMMS code? - Kidcat - 2001-11-03
Would it be hard to port the code in XMMS to Noatun? The issues i can c are theese (?): It backends to tk (or is it gtk?) Is it modular enough to be easy to port? I would REALLY like to se winskin in Noatun/KDE3 for a lot of reasons includeing but not limited to: "I've become so f...... used to it" :-) /kidcat -- hardtoreadbecauseitissolong
Re: Winamp Skins in Noatun... butching XMMS code? - FO - 2001-11-04
xmms is gtk based.. and well, the abstractions between the ui and the core interface are not well done in it.. if it were, a kde port would be trivial in just porting the dialogs.. HOWEVER, in it's current state, xmms plugins require gtk and the playlist, etc.. use gdk extensivily. other than that, I think winskin should be included, but it really is a lost cause. winamp 2.x will be dead soon, with winamp 3.0 coming out, and apps that try to replicate winamp 2.x will have to update their skinning engines too. and guess what? the winamp 3.x skinning engine is very much like kjofol's (in look and feel). This might be because NULLSOFT hired the developer of kjofol.
Re: Winamp Skins in Noatun... butching XMMS code? - kidcat - 2001-11-05
There are still alot of nice looking skins for winamp 2.x.... And the main thing in the UI (of WA2.X) is that it is consistant and easy to use, whereas the kjofol-alikes all look and feel difrent. So whatever WA2.X or WA3.X is out i still think that the BOLLIONS of 2.x skins should not be renderd absolete. roger-over-&-out /kidcat
i am very sad - daniel - 2001-11-04
I am talking about the decision of take KonCD the default CD-Burning program for KDE3. There are lot of programs better that it, as K3B,CdBakeOven,KreateCD, and so on. We all know that all of its (included KonCD) uses cdrecord and programs like that. Then, KDE core team should choose the right CD-Burning app, studing the user interface. The apps i have mentioned have much better interface than KonCD, and the process of burning is much easy. Who has decided to include KonCD into KDE3? I mean, if you see the ratings into apps.kde.org, there are lot of CD-Burnings apps that have been rated more times. Which are the points that they have taken to decide to include this app into KDE3? I am sad. I think, KDE has to include apps easy for the Desktop, and i am sad because this decision has been wrong. http://cdbakeoven.sourceforge.net/pics/fileBrowser.png http://k3b.sourceforge.net/images/k3b-main-audio.jpg and so on ... Anybody can said that the GUI building is much better than KonCD, and this feature is very important here on the desktop.Its a pitty.
Re: i am very sad - daniel - 2001-11-04
I think this decision has to be decided by KDE users. I mean, its time to get rid of comercial decisions, and for the first time in history, do a referendum by KDE users to decide things in KDE3. The whole of KDE users, and i am user, will vote negative for KonCD.
Re: i am very sad - Moritz Moeller-Herrmann - 2001-11-04
I think you have some misunderstanding about the way KDE development works. There has been no official "decision" for koncd. It is just the author Kai Heitkamp of koncd who asked the KDE developers, if he could add his (IMHO) excellent koncd application to KDE cvs and voila there it is. Noone forces you to use it. In fact Kai Hietkamp has just taken on the extra responsibility to port and support his application for the next release of KDE. If you look at koncdm you find frequent releases and a stable release. Neither k3b nor cdbakeoven show the same. Noone hinders the developers of k3b and cdbakeoven from doing the same thing. If I check apps.kde.com, I find no mention of cdbakeoven at all. k3b is IMHO a bit confusing. Have you checked out the latest release of koncd? Finally regarding your coimment about "letting the users decide". This is complete crap. Users have nothing to say about KDE. OpenSource is not a democracy but a meritocracy. If either author wants his app to be the official KDE cd burning application, well just enter the competition, put your app in KDE cvs and the best one will win.
Other app name for KonCD? - Thorsten Schnebeck - 2001-11-04
But do you think KonCD is a good application _name_? Sounds a little bit to "adobish" for me - remember KIllustrator? This should be clarified before KonCD is bundled with every release. BTW, I really *like* KonCD task oriented GUI: 1 drag, 3 clicks and I have a new DivX :-) Bye Thorsten
Re: Other app name for KonCD? - AC - 2001-11-05
The name issue is a good point: Apart from the fact that "KOnCD" is a really boring name (if it must be a "K"-name, "KreateCD" has the better, more original name), you should really think whether you want once again include a program into the KDE main branch which almost surely is legally on shallow ground just because of the name!
Re: Other app name for KonCD? - kidcat - 2001-11-05
Well.... I don't think that the name is all that bad: 1) It sounds like WinOnCD which will make the new and oh-so-shook-up windoze user see it as a freindly face. 1.1) Peepz dont like to find a thing called IncinerateCD in the apps menu ;-) 2) Bundled sofware should IMHO have boring names defacto! Then let all the others have their K-Napalm-CD-Gun, 1.21GW-CD-Toaster-4-K and Fire-CD-in-a-Wizz. /kidcat
Re: Other app name for KonCD? - kidcat - 2001-11-05
Well.... I don't think that the name is all that bad: 1) It sounds like WinOnCD which will make the new and oh-so-shook-up windoze user see it as a freindly face. 1.1) Peepz dont like to find a thing called IncinerateCD in the apps menu ;-) 2) Bundled sofware should IMHO have boring names defacto! Then let all the others have their K-Napalm-CD-Gun, 1.21GW-CD-Toaster-4-K and Fire-CD-in-a-Wizz. /kidcat
Re: Other app name for KonCD? - AC - 2001-11-06
And exactly your point 1) is no advantage, but a big problem...
Re: Other app name for KonCD? - growndog - 2001-11-06
Is it too late to add a little laser beam to the "K-Napalm-CD-Gun" I think it would be more accurate that way since we're dealing with laser discs here;)
Re: i am very sad - FO - 2001-11-07
could several cd burning apps be included? i don't really like KonCD (no disrespect to the author, but I don't really like the gui, and neither do most people). AFAIK, one of the KDE developers asked the KonCD author if he/she could include it in KDE (i think Kulow asked). I think, (IMHO), KonCD was the wrong app to pick, esp. with usability concerns. And yes, Im talking about the newest.
another problem with your argument.. - FO - 2001-11-07
..is that many kde apps have not been updated in a long time (usually since kde 2.0). just look at apps like kpm. It doesn't even use modern Qt widgets like K/QListView and doesn';t even have translatable strings!