3

This idea is to integrate KHTML even deeper into the new pillars of KDE, especially Akonadi. The reason is this:

Web pages suck. They really, REALLY suck. If you want to check 2 E-mail accounts, you have to open 2 tabs or 2 new windows. That's like being forced to open 2 different applications for the same task. Instant messaging in web-pages sucks even more. Every implementation is different, looks and behaves differently from every other implementation. Some open a new browser window (Hotmail), some stay in the same window (Facebook), some give you the choice (GMail), but none of them co-operate with each other. It's ridiculous that I could have 5 or 6 different windows/tabs open just to speak to 3 people in exactly the same manner. Don't even get me STARTED on file management! /rant


On the other hand, web-pages have something that desktop applications don't, that keeps people going back to them all the time. For some reason, people keep using glorified document viewers (browsers) to perform tasks in a horribly inefficient manner.

Here's why: I go to GMail, enter my E-mail address and password and bang! I'm done. I don't have to worry about whether it uses POP or IMAP, what the incoming/outgoing servers are, what encryption is used, how my password has to be sent etc. Just my username and password.

It's the same with facebook. If I want to chat to someone, I just type in my username and password and the website handles all the details for me. Hotmail, Facebook, Yahoo!, GMail, it's the same everywhere - I type in my username and password and the details vanish.


So, the suggestion is this: have KHTML use a plug-in system that detects these details and exports them to Akonadi resources that are automatically picked up by desktop applications. Maybe, show a yellow bar at the top stating, "This web-app has been integrated into [application/'your desktop']. (Open Application(s))". Now, the user discovers that they won't have 5 or more windows open for chat, but 2: Kopete's contact window and the chat window with tabs. All right, so you could argue that they might have 3 or 4 chat tabs, but at least you're not hunting through several, "Firefox" windows or several poorly-named tabs to look for who just sent you an instant message: you know where the window is and can even open it from the notification when they send you an instant message. Now, the user can check all their E-mail from KMail without routing through windows and tabs for different accounts. They can send E-mails to all of their contacts (across several E-mail accounts) from any E-mail address, or just 1 E-mail address if they want (replying to a GMail message from a Hotmail account? Suddenly it's not just possible, but very simple too).

So to summarise 'Incorporate web services into applications':
So webmail magically works in kmail
All online instant messengers work in Kopete.

How??

It would require a lot of code for each website. Especially as most these don't have nice APIs.

There are plenty of email services which incorporate nicely with KMail via IMAP as is. If you want to use kmail, use a proper email provider. (same for Instant Messaging)

No.

All we're doing is taking the log-in information from the websites - say GMail - and exporting it to Akonadi resources, along with pre-set server information - say an IMAP resource and a Jabber/XMMP resource (there's also a contacts and a calendar resource in the works that we could export to). Facebook would export a Jabber/XMMP resource, Yahoo an IMAP and Yahoo IM resource, and Hotmail a POP3(/separate Hotmail E-mail resource that maybe integrates better into it) and MSN resource.

Ah, that makes a lot more sense.

However, I still am of the opinion that this isn't anywhere near as useful as just having a lot of nice presets in kmail/kopete for selecting 'google mail' then typing in a username/password.

The problem is that new users don't really realize that Kopete is capable of doing e.g. MSN, Google Talk and Yahoo! Chat, because it's just called, "instant messenger". Similarly, they might not recognize that you don't need webmail to check your E-mail, or might have been scared off by previous E-mail clients with the complexities such as server information. However, if they visit the website and type in their details, we could let Konqueror do all that hard work for them and then start the application.

Well sorry, that sounds good on the paper, but I don't think it will work. With the information GoogleMail gives you on the website, you could *never* configure an email-client. You could, maybe, if you write a specific script for googlemail; but that sort of sucks too...

If I'm wrong, please correct me, but I think it's completely impossible to implement this properly. Maybe you can do some hacks, but that's all.

Best regards,
Sven

scummos wrote:Well sorry, that sounds good on the paper, but I don't think it will work. With the information GoogleMail gives you on the website, you could *never* configure an email-client. You could, maybe, if you write a specific script for googlemail; but that sort of sucks too...

If I'm wrong, please correct me, but I think it's completely impossible to implement this properly. Maybe you can do some hacks, but that's all.

Best regards,
Sven

That's kinda false. A new Akonadi resource for googlemail could implement these details quite trivially (after figuring them out through reverse-engineering, I presume). With the new KMail being based on Akonadi, I expect more such resources to become available; with Akonadi/Nepomuk being so closely tied together, I expect GMail's tags could be easily implemented and used through Nepomuk in KMail.

Sorry, I don't quite understand what you mean.
The only thing I could imagine is the website pointing to an XML file with a meta tag or so, and this XML file's information being read by konqueror etc. Do you mean something like that?

For a set of the more popular webmail sites like gmail, yahoo, and hotmail, Akonadi could have the necessary presets built into it. Then on logging into one of the sites (in Konqueror) that Akonadi recognizes then it just does a lookup into the presets and pulls in the username and password. The websites themselves don't need to be pointing at xml files or have meta data in them to tell Akonadi what to do, Akonadi associates the website (url) with the appropriate presets.

For the less popular sites which won't have Akonadi built-in presets, Akonadi will likely need some extra assistance in determining the appropriate settings. KHTML could still recognize that you are logging into a web mail site and ask if you want to set up the Akonadi resource, but then Akonadi will present a dialog saying: "KDE doesn't recognize this web mail site. Please fill in the appropriate details."

Why not implement this a bit less messy then? Just enable the user to select "Google Mail" in kmail, enter user name and password, and make kmail auto-configure the rest. That's a much cleaner approach, if you ask me.

Best Regards,
Sven

Because when the average user wants to check their E-mail, they probably won't think, "KMail": they'll think, "website". This will show them that KMail is there, that it DOES do E-mail and that it doesn't have to be a pain to set up - then set it up automatically.

Similarly, how many people are going to know you can use Facebook chat from Kopete? What about Google Talk? Will they know that Choqok can log-in to Twitter?

They won't think to look this stuff up, and they won't know it does any of that stuff until they're told or shown. The point of this idea is to show the user that these programs do have this capability.

And for God sake, it's not just about KMail! ¬_¬

Well, sorry, I imagine this to be quite annoying... that might evolve to something like Microsoft's Clippy... "Konqueror has detected that you logged in to googlemail, do you want to open kmail instead?"

But hey, okay, it's an idea. I don't like it, but maybe others will.

No, it would be more like the remember passwords bar on the top of the page with buttons to Open in Kmail, Cancel, and Never ask again; and it will be only so annoying as that bar is already (which will show up anyway because you submitted a username and password on a web form, unless you already told it to remember or never ask for that web form)

airdrik wrote:No, it would be more like the remember passwords bar on the top of the page with buttons to Open in Kmail, Cancel, and Never ask again; and it will be only so annoying as that bar is already (which will show up anyway because you submitted a username and password on a web form, unless you already told it to remember or never ask for that web form)

Hm, okay.
But one last question: What the hell does this have to do with KHTML (which is a HTML rendering engine, isn't it)?

KHTML would be the component that would be recognizing if you navigate to a web mail site and display the Open in Kmail bar.
Doing so in KHTML has advantages and disadvantages; namely: it will work across applications that use KHTML for rendering pages, but OTOH most of the other applications that use KHTML for rendering either won't be used for going to gmail, or wouldn't be appropriate locations to have such a notification. IMO, it is probably better to implement in Konqueror (or whatever other browser you would use to navigate to your web mail site) than KHTML.