Version: 0.8.1 (using KDE KDE 3.2.2) Installed from: Mandrake RPMs OS: Linux Did you already seen LongHorn ? Do you know what is planned for that release ? They want to integrate the adressbook, the mails... in their explorer. I think it would be very nice to do so in KDE, and I think we can do it without a to big lot of work. For instance, have a pim:/ protocol, and inside that protocol, a folder notes, a folder mails... In the mails folder, a "special" folder to get the mails, and all the mails sub-folders. In an addressbook folder, all the contacts, editable with the properties on right clic, and a clic on the contact would send him a mail...
perhaps file-types for phone-, fax-, multifunction-, sms- numbers, sip, h323, iax, icq, aim, postaddress would be useful too. But i dont know if it would be better to build a open-ldap-backend for pim-data and a ldap-kio, enum-kio for konqueror. So other non-kde apps could use it.....
I also vote for this wish (yeah: 371! great). I find the suggestion very good and it's all about what I've thinked. I would want to ask if developer point of view it is possible to "link" PIM data into an application ? For example ask KOrganizer the TODOs and display one of them AND update the view if the user modified the TODO in KOrganizer ? Would be also very needed (perhapse it ask a lot of wor and must wait KDE 4.0 ?). I've heard Kontact now display Kopete contacts state but it isn't the same I think.
> I would want to ask if developer point of view it is possible to "link" PIM data into an application ? I think it's possible to do that. Look at Konqueror : you remove a file from a konsole and konq "see" that instantly so I think with a center of PIM datas it would be possible, and that center could have for interfaces Kontact or that KIO protocol !
Sorry, but that doesn't make any sense. Why would you show mails, events or other PIM data in Konqueror? Kontact does this in a tremendously better way and the kioslave concept doesn't fit to this data very well anyway.
It's a sample... A kioslave is accessible through Konqueror, but also KWrite, Kate, KOffice... All KDE apps. For instance, in the current situation, when you open a mp3 inside a mail, it goes into /tmp with a barbarian name, and then it's opened with the sound player. With a KIO protocol, it would be possible to open it without temporary file. Another sample : with that, a newbie could learn only one app, konqueror, and use it for all !
And a feature it would allow : inside Konqueror, we would be able to read mails with tabbed browsing. I think it could be useful, and a lot best than the usual system of multi-window...
yep, imho all apps which can be embedded now should also allow for working on them - eg you shoulnt only be able to vieuw kword files in kword-embedded-in-konqueror, but also be able to edit them. this way, you can be working on multiple doc's (and webpages and emails) in 1 konqi screen (and several tab's) and be able to save the tabs in a bookmark so you can load them again with a few clicks tomorow, and continue working on them! whould be really really great... no 3 open kword windows & kontact & konqueror, but just one... I've been thinkin' about this (and I call it 'projeKt'). I think it could be very handy to clean your workspace and keep it in 1 window (a projekt window), with the abillity to save it as projekt etc.
No, keep Konq as Konq. I don't like Konq as a web browser and a file explorer; I prefer them separate. So having it do everything? No thanks!
Hey I don't want to do all in Konq : with a KIO to access PIM datas, Kontact would always be there ! You could choose : Kontact + Konq + ... or Konq for everything.
"No, keep Konq as Konq. I don't like Konq as a web browser and a file explorer; I prefer them separate. So having it do everything? No thanks! " Neither of these are konqueror. The web browser is khtml and the file explorer is something else. konq can embed any kpart. In this case, the proposal is making mails and such available through a kio, which makes them files not only browsable with konq's file browser, but also accessible from every kde app transparently.
"In this case, the proposal is making mails and such available through a kio, which makes them files not only browsable with konq's file browser, but also accessible from every kde app transparently. " This would also make every mail and attachment searchable from a regular search box, seems to me like a good way really find stuff. This is a very good idea and I believe this is really inituive(spelling). K-menu->Search, and you'll find everything, nice.
I think it would also be a concrete answer to Google Desktop Search, with a more usable solution ! Such a KIO, in addition of http://bugs.kde.org/show_bug.cgi?id=82581 (another idea I submitted with thid onr) and a new search interface (more intuitive, easier to understand, with more options like "Document contains titel" or "Artist is ..." (so with metadata) would allow us to have a killer-application, like Spotlight or the future WinFS. KDE has the architecture to explode their functionalities, use it !
""No, keep Konq as Konq. I don't like Konq as a web browser and a file explorer; I prefer them separate. So having it do everything? No thanks! " Neither of these are konqueror. The web browser is khtml and the file explorer is something else. konq can embed any kpart. In this case, the proposal is making mails and such available through a kio, which makes them files not only browsable with konq's file browser, but also accessible from every kde app transparently." which is, imho, a great idea.
If this is possible, I suggest the title of this bug is changed in order to attract more votes. I believe this bug proposal is another crucial feature in relation to the overall improvemnts of the searching capabilites within the KDE desktop. Perhaps with a better bug title I think more will vote for this bug.
you might be right. anyway, the idea is great: being able to open an attachment from a email directly from the file-open dialogue in kword is very usefull...
The idea is tempting in both directions: Not only can attachments be opened directly, but also it is possible to attach any PIM object to where files can be attached. I came across this with a simple problem: I would like to attach and e-mail to an appointment, which - at the moment - is impossible. But I can attach any file. So So instead of saving this e-mail into some folder and attaching the file, I could attach the e-mail directly.
That aligns with a wish I am conceiving for a long time: to reference emails by URL. I am surprised that emails, in common use for more than a decade and still one of the most important communication media is downright sealed concerning that issue.
yes, indeed. KIO needs to be even more 'everywhere', imho. imagine you search for 'casper' and a svg drawing in an archive from a mail from casper turns up. you drag'n'drop the drawing from the search window in kword. later you decide to drag'n'drop the object from kword in krita, give it some effects (of course, seperate layer) and you drag it back. yeah, guess this won't work now, but it should, imho...
I'm voting for this bug. I'd like to see something like this in action. A developer's view would be nice, though...