From kde-devel Mon Mar 22 00:12:07 2010 From: Dinesh Date: Mon, 22 Mar 2010 00:12:07 +0000 To: kde-devel Subject: Re: kde-devel Digest, Vol 84, Issue 42 Message-Id: <2ca5cc7a1003211700u274e304eu6c675e70dcf7bbcb () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-devel&m=126921610518639 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0190996916==" --===============0190996916== Content-Type: multipart/alternative; boundary=001485f91396403558048258618d --001485f91396403558048258618d Content-Type: text/plain; charset=ISO-8859-1 Hi all, A Diumenge, 21 de mar? de 2010, Oswald Buddenhagen va escriure: > > > On Sun, Mar 21, 2010 at 03:28:38PM +0530, Dinesh wrote: > > > I am Dinesh, an undergraduate looking to spend my summer contributing > > > full-time to KDE via the Google Summer of Code by making A proper > > > Smartphone managing suite for KDE. > > > > this project idea sounds like it would be duplicating a lot of > > http://labs.trolltech.com/page/Projects/QtMobility > > But as I understand it's almost impossible to get Nokia to accept big > contributions to Qt (as oposed to bugfixes that seems to be working quite > good) so are you suggesting that he just does nothing waiting for you to code > it? What if QtMobility doesn't end up working at the end or is a totally > different thing? 1 small point from my side(somebody correct me if i am wrong) . even if qt mobility provides the functionality, isnt qtmobility supposed to be talking to the non-nokia platforms using their standard api that they give?? i mean from whatever i ve read till now, SyncML is supposed to be a standardrized, open platform for exchanging information. so isnt all i am doing is using one open library instead of some another open library?? > yes, this is a known deficit which is being addressed. somehow. > somewhen. > > > so are you suggesting that he just does nothing waiting for you to > > code it? > > > that's one possibility. duplication would certainly affect kde's > decision on spending a soc slot on it. > > > What if QtMobility doesn't end up working at the end > > > success is the only option. ;) > > > or is a totally different thing? > > > investigating this thoroughly would be part of pursuing this gsoc > proposal further. Yes, i agree. > > Is the mobility project an effort to get Qt to run on mobile > platforms, or is an effort to get Qt on existing platforms to connect > to mobile devices? I may just have missed it but I cannot find a > clear explanation of what the actual goals of the project are. The > best I could find is: > > "Our goal is to make Qt an even more comprehensive application and UI > framework by developing new APIs addressing mobile functionality. > Ultimately this will enable rich mobile applications to run across > many more platforms? Nokia and non-Nokia platforms! Why didn?t we > think of this earlier!" > > This seems to imply that it is designed to run on mobile platforms, > but isn't very clear about that. I am sure you know far more about it > then I do, but it might be a good idea for the people in the project > to add more specific information on the site explaining exactly what > they intend to do. Because based on the website and blog at least I > couldn't find any indication they intend to support the sort of > capabilities Dinesh suggested. > > One possible solution would be for Dinesh to write a system which > support the addition of new device backends to support new sorts of > devices. That way we aren't limited to the sorts of devices he had > time to code for. Additionally, this would allow for a wrapper > backend to be written for Qt mobility when and if the Qt mobility > project supports the stuff his project needs, and any redundant > backends could be phased out at that time while ones that support > devices the Qt mobility project does not support or supports them > better can be kept. Even if the Qt mobility project does everything, > we still need KDE to be set up to take advantage of those > capabilities. > > -Todd I totally agree with this, but i have to admit, the only back-ends i worked on till now are obexfs/obexftp for file transfer and opensync 's syncml for getting contacts from my phone...so i am more of an illiterate when it comes to the other backends available.... even though i am totally ready to learn more(but i really need help on this, cuz it will be like researching on things that i dont yet know).. "qt mobility" is an umbrella project for "everything which has to do > > with mobile devices". in my book that includes synchronization. i don't > know the details and i'm not sure how much i'd be allowed to talk about > them anyway. ask the responsible trolls in #qt-labs at brisbane working > hours. can any one do this for me please?? my college blocked all the IRC channels and i have my mid term exams this week, so by the time my exams are done(this saturday), the bonding time with mentoring organizations will be almost over. > > "qt mobility" is an umbrella project for "everything which has to do > > with mobile devices". in my book that includes synchronization. i don't > > know the details and i'm not sure how much i'd be allowed to talk about > > them anyway. ask the responsible trolls in #qt-labs at brisbane working > > hours. > > If that is the case the website should probably say it. The website > is not currently very clear. once again, here is the link that might clarify things a bit: http://qt.nokia.com/doc/qtmobility-1.0-beta/index.html#platform-compatability in this link nokia says : "A functional backend for the API on the platform is not being worked on. It is possible for others to implement and integrate support." for contacts on any of the desktop platforms (Windows,Linux,Mac OS) however it also says: "A functional backend for the API on the platform is being worked however it is not functionally complete." for versit for all the qt platforms. (again, somebody correct me if i am wrong) i guess the only thing that means is that the desktop platforms themselves have to implement the PIM modules and QTMobility project can be used to make vcard, vcalender, vtodo files etc. so that means someone still has to write a way to get Kontact to exchange information with mobile phones, and doesnt that mean we are back to where we have started? Dinesh --001485f91396403558048258618d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

A Diumenge, 21 de mar? de 2010, Oswald Buddenhagen va escriu= re:
>
> > On Sun, Mar 21, 2010 at 03:28:38PM +0530, Dinesh w= rote:
> > > I am =A0Dinesh, an undergraduate looking to spend m= y summer contributing
> > > full-time to KDE via the Google Summer of Code by making A p= roper
> > > Smartphone managing suite for KDE.
> >
= > > this project idea sounds like it would be duplicating a lot of > > ht= tp://labs.trolltech.com/page/Projects/QtMobility
>
> But as= I understand it's almost impossible to get Nokia to accept big
>= contributions to Qt (as oposed to bugfixes that seems to be working quite<= br> > good) so are you suggesting that he just does nothing waiting for you = to code
> it? What if QtMobility doesn't end up working at the en= d or is a totally
> different thing?

1 small point from my sid= e(somebody correct me if i am wrong) . even if qt mobility provides the functionality, isnt qtmobil= ity supposed to be talking to the non-nokia=20 platforms using their standard api that they give?? i mean from whatever i ve read till now, SyncML is supposed to be a standardrized, open=20 platform for exchanging information. so isnt all i am doing is using one open library instead of some another open library??
=A0
> yes, th= is is a known deficit which is being addressed. somehow.
> somewhen.<= br>>
> > so are you suggesting that he just does nothing waitin= g for you to
> > code it?
> >
> that's one possibility. duplica= tion would certainly affect kde's
> decision on spending a soc sl= ot on it.
>
> > What if QtMobility doesn't end up workin= g at the end
> >
> success is the only option. ;)
>
> > or is= a totally different thing?
> >
> investigating this thoroug= hly would be part of pursuing this gsoc
> proposal further.

Yes, i agree.

>
> Is the mobility project an effort to get = Qt to run on mobile
> platforms, or is an effort to get Qt on existin= g platforms to connect
> to mobile devices? =A0I may just have missed= it but I cannot find a
> clear explanation of what the actual goals of the project are. =A0The<= br>> best I could find is:
>
> "Our goal is to make Qt = an even more comprehensive application and UI
> framework by developi= ng new APIs addressing mobile functionality.
> Ultimately this will enable rich mobile applications to run across
= > many more platforms? Nokia and non-Nokia platforms! Why didn?t we
&= gt; think of this earlier!"
>
> This seems to imply that i= t is designed to run on mobile platforms,
> but isn't very clear about that. =A0I am sure you know far more ab= out it
> then I do, but it might be a good idea for the people in the= project
> to add more specific information on the site explaining ex= actly what
> they intend to do. =A0Because based on the website and blog at least I=
> couldn't find any indication they intend to support the sort o= f
> capabilities Dinesh suggested.
>
> One possible solut= ion would be for Dinesh to write a system which
> support the addition of new device backends to support new sorts of> devices. =A0That way we aren't limited to the sorts of devices he= had
> time to code for. Additionally, this would allow for a wrapper=
> backend to be written for Qt mobility when and if the Qt mobility
&= gt; project supports the stuff his project needs, and any redundant
>= backends could be phased out at that time while ones that support
> = devices the Qt mobility project does not support or supports them
> better can be kept. =A0Even if the Qt mobility project does everything= ,
> we still need KDE to be set up to take advantage of those
>= capabilities.
>
> -Todd

I totally agree with this, but = i have to admit, the only back-ends i worked on till now are=A0 obexfs/obex= ftp for file transfer and opensync 's syncml for getting contacts from = my phone...so i am more of an illiterate when it comes to the other backend= s available.... even though i am totally ready to learn more(but i really n= eed help on this, cuz it will be like researching on things that i dont yet= know)..


=A0"qt mobility" is an umbrella project for "everyth= ing which has to do
>
> with mobile devices". in my book t= hat includes synchronization. i don't
> know the details and i= 9;m not sure how much i'd be allowed to talk about
> them anyway. ask the responsible trolls in #qt-labs at brisbane workin= g
> hours.

can any one do this for me please?? my college bloc= ked all the IRC channels and i have my mid term exams this week, so by the = time my exams are done(this saturday), the bonding time with mentoring orga= nizations will be almost over.

> > "qt mobility" is an umbrella project for "ever= ything which has to do
> > with mobile devices". in my book t= hat includes synchronization. i don't
> > know the details and= i'm not sure how much i'd be allowed to talk about
> > them anyway. ask the responsible trolls in #qt-labs at brisbane w= orking
> > hours.
>
> If that is the case the website = should probably say it. =A0The website
> is not currently very clear.=

once again, here is the link that might clarify things a bit:
http://qt.nokia.com/doc/qtmobility-1.0-beta/index.html#platform-co= mpatability

in this link nokia says :

"A functional backend for the API= on the platform is not being worked on. It is possible for others to imple= ment and integrate support."
for contacts on any of the desktop pla= tforms (Windows,Linux,Mac OS)

however it also says:
"A functional backend for the API on the = platform is being worked however it is not functionally complete."
for versit for all the qt platfo= rms.

(again, somebody correct me if i am wrong) i guess the only th= ing that means is that the desktop platforms themselves have to implement t= he PIM modules and QTMobility project can be used to make vcard, vcalender,= vtodo files etc. so that means someone still has to write a way to get Kon= tact to exchange information with mobile phones, and doesnt that mean we ar= e back to where we have started?

<= /span>
Dinesh
--001485f91396403558048258618d-- --===============0190996916== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0190996916==--