Mobile and GSOC

[Davide Bettio]

Hi,

On 03/27/11 21:24, Marco Martin wrote:
> to me, as i explained before what is important is not much the applications 
> per se, but how are written and how they use said mobile stack, i'm still not 
> sure  how many of those pieces should be plasmoids, how many separate 
> applications
> 99% of phone management, *maybe* except the contact list should be managed by 
> plasmoids, c++ ones is ok for what uses stuff that isn't worth doing a qml 
> export., any needed custom window managementcan be given at the proper level
Phone managment, dialing and messaging will require to link to several
libraries,
so I'm not sure if using only QML is a good idea but I'm rather sure
that it's not a good idea to make bindings for each library.
Anyway I'm currently using a QML view and a C++ logic approach and what
I really need is a clean way to do that.

> for applications, i would like to see an unique way to do kapplications, that 
> can access to kxmlguy kactions and uses only Package to access/load qml files.
>
> it's a bit a rant, but what i don't want to see other quick and dirty mobile 
> applications.
Currently all the quick and dirty stuff is kept in two different (and
unmerged branches) and not in master,
so we can remove all the apps without polluting the history.
The quick and dirty approach has been useful to experiment and to
explore how to implement things correctly.
Anyway it's not clear to me how to implement apps correctly and we
should define it as soon as possible.
I think a good discussion on this point should be started.

>> * phonebook application (that stores contacts on akonadi)
>> * phone dialer
>> * phone management application (which works as PIN requester/active
>> calls management, etc...)
> why 3? (remember also the there you want as less running process as possible)
The first and the second one can be merged for sure, I've divided the
thing into 2 pieces because I've been experimenting with 2 different things.
The phonebook view will be moved into a QML library and the dialer will
use it.
The phone managment application should start as soon as possible so the
shell can start while the user is typing sim PIN.
The phone managment application usually has no open window and it should
be light weight.
If the shell stop to work the user can answer to phone calls in any
case. Anyway it can be merged easily into the shell if required.

>> * signal strength applet
>> * mobile operator name applet
> i think for the base case, it should be only a single applet that shows both, 
> then if a distribution/vendor/someone wants to split it in two, that's fine
I've decided to use two different applets because the signal strength
usually is always
displayed while the operator name sometimes is displayed on the desktop.
I don't think we have enough space in the panel for both.

Anyway I've forgot to mention that we have also a DataEngine called
"mobilenetworkengine".
You can find it in the main branch as a fake DataEngine or in the
mobilephone branch as a ofono based DataEngine.

>> Actually all the code is working with ofono/ofono-qt and phonesim but it
>> should work on real hardware without any change.
>> All the code is available on plasma-mobile (mobilephone and apps branches).
>> I would like to continue to work on this project as a gsoc project.
>> During the gsoc I plan to improve existing applications and to write
>> other required applications (sms, calls register, etc...)
>> Any comment or advice is welcome :)
> this I think is really good, can you try to write an elaborate proposal, at 
> least ~2 pages rather soon (you have until 8th april)
Ok, sure I will.

Bye,
Davide Bettio.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20110327/028e9325/attachment.sig