← Back to team overview

ubuntu-phone team mailing list archive

Re: [Calendar App] Commit 3: Initial C++ code ported to pure QML/JS

 

Al 14/02/13 19:52, En/na Frank Mertens ha escrit:
> Hi all,
> 
> I just finished porting my initial C++ code to full QML/JS and I though I might
> share my first experience with V8. The number of code lines where at least halved.
> The two C++ model classes disappeared in two lines of code. Performance-vise I run
> into issues initially with object instantiation. Accidentally I instantiated each day
> item for the flickable month view at component construction time. I had to kill qmlscene
> after a minute of waiting. Generally item instantiation seems to be pretty expensive, but
> when it's up and running pure QML seems to run more fluently. My guess is that JS/V8 is
> doing realtime memory allocation more cleverly than Qt/C++, but I don't really care
> as long as it's working.
> By the way I'm working on a Lenovo Edge equipped with a Turion limited at 800Mhz.
> I don't think that any mobile device released this year will be slower;)
> 
> I also pushed a small JS library file with the pragma style as shown in the notepad-qml
> example. I started using the built-in Date object of Javascript and opted for extending
> it where functions seem to be missing (ideally with the same method names as in QDate).

Thanks for taking the time to write and share that Frank, that's pretty
awesome, good work!

> Like the last time I'm just pushing here some code to the public master branch
> without brothering much, if it breaks something somewhere. I'm used to follow this
> simple First Come First Service strategy from my commercial projects. Means, if you
> push some code first, you have to perform the SERVICE (yes in big letters) to listen
> to anybodies complaints and merge their stuff if it conflicts with your changes.
> 

I would recommend discussing this workflow with Kevin and the team
before taking the approach of committing directly to the trunk. What we
recommend on the Development Guide is to use feature branches, which get
peer-reviewed before landing into trunk:

https://wiki.ubuntu.com/UbuntuPhone/CoreApps/DevelopmentGuide#Workflow

This way we use full potential of a distributed VCS:

- The trunk is always in a functional state (*)
- Your code gets peer-reviewed before being used by others
- You can still commit and work on your code exactly as if you were
  in trunk. Your branch can be pushed to and published online (and
  branched from)

There are probably more benefits to list from the distributed approach,
but these are the first ones that came to mind, I hope you find the
feedback useful!

Cheers,
David.

(*) otherwise, if you commit directly to trunk and something breaks,
your team mates might be blocked if you are not available to fix it,
which might be a critical issue when working on different time zones.

-- 
David Planella
Ubuntu App Development Liaison
http://gplus.to/dplanella / @dplanella
www.ubuntu.com / www.davidplanella.org

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References