Mobile and GSOC

[Marco Martin]

On Sunday 27 March 2011, Davide Bettio wrote:
> 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,

how much public api said libraries would need to be used by something? i still 
think a dataengine with a couple of services would be nice there (it would be 
nice to be able to dial from a random contact list plasmoid, even if would 
pose the problem that maybe only some authorized plasmoids should be able to 
do so...)

> 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.

yeah, in this case a c++ approach is good since otherwise it would export too 
many things that would become "almost" public api (right now for instance is 
possible for anyone to import and use random pieces of kmail... not sure is a 
desiderable thing, but this is another of my pet peeves with qml ;p)

> > 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.

yup, sure, having something that works as an experiment is always good, then 
let's engineer it a bit :)

> 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.

yeah, not even to me actually ;)

> >> * 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.

my old phone with a 176x208 pixels display can fit it :p

> 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.

good :)



-- 
Marco Martin