How to enter an email address

[Ingo Klöcker]

On Friday 08 October 2010, Tom Albers wrote:
> ----- Oorspronkelijk bericht -----
> 
> > Hi,
> > 
> > I was just wondering if there is a simple _and_ correct solution
> > for an "enter
> > an email address" widget. In KGpg I use a simple KLineEdit and
> > afterwards
> > throw the contents into KPIMUtils::isValidSimpleAddress(). Linking
> > to kdepimlibs doesn't hurt there as I need the address book stuff
> > anyway.
> > 
> > But what to do on other places? One thing that came to my mind
> > would be the
> > <input type="email"> from HTML5. Depending on kdepimlibs for KHTML
> > is not an
> > option. And I think it would also be cool to immediately stop the
> > user from
> > entering invalid addresses. KRestrictedLine could do half of this
> > but would
> > not stop one from entering foo at example@org or other junk.
> > 
> > So the question is: do we have a simple widget that would do this?
> > If not, why
> > not? Entering email addresses (and URLs, that would be the next to
> > come up) is
> > something most programs do these days. Assisting the user and
> > developer here
> > would make totally sense to me.
> > 
> > Eike
> 
> There is a QValidator based one:
> http://api.kde.org/4.x-api/kdepimlibs-apidocs/kpimutils/html/classKPI
> MUtils_1_1EmailValidator.html

... which, obviously, lives in kdepimlibs which apparently (why 
exactly?) is not an option for KHTML. My question is "Why do you think 
this would require a hard dependency on kdepimlibs?"

IMNSHO it should be possible to extend KHTML without introducing hard 
dependencies. Simply add a suitable interface, provide a suitable 
fallback implementation which does a basic check and use the fully 
featured implementation if kdepimlibs is installed.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101008/0fa30ee8/attachment.sig>