Active Topics
-
How many of you still use N900 as main phone? (595)
to Community by deutch1976 - 1 day, 9 hrs ago -
Big news (7)
to OS2008 / Maemo 4 / Chinook - Diablo by endsormeans - 2 days, 18 hrs ago -
Firefox with Leste (8)
to Maemo 7 / Leste by endsormeans - 2 days, 18 hrs ago -
Which is the best N95? What software modifications could be made to it? (3)
to General by Kalatti - 5 days, 18 hrs ago -
Installing CSSU Stable in year 2024 (2)
to Maemo 5 / Fremantle by teroyk - 6 days, 2 hrs ago -
Porting apps to Leste (34)
to Maemo 7 / Leste by Arno_11 - 6 days, 11 hrs ago - more...
go1dfish |
2009-12-13
, 23:55
|
|
Posts: 237 |
Thanked: 157 times |
Joined on Dec 2009
@ San Diego, CA
|
#21
|
As promised, here is my Python/Qt4 app: http://talk.maemo.org/showthread.php?t=37089
|
|
2009-12-14
, 01:26
|
|
Guest |
Posts: n/a |
Thanked: 0 times |
Joined on
|
#22
|
noobmonkey: I forgot to mention that if you want to learn Qt fast, you can get the previous edition of the official Qt book as a free download (it's too old to cover the Maemo-specific features of Qt, but it's a great book, and good as a general reference to Qt) The documentation is also quite good, although the book is a better place to start for most people. I'd read the first few chapters, then skim the conceptual overview pages on the Qt Docs (e.g. signals and slots, etc.)
Link: http://blog.hartwork.org/?p=156
I've also heard this book (also free) recommended: but I think it's more advanced, and I haven't looked at it yet: http://cartan.cas.suffolk.edu/oopdocbook/opensource/
#qt on Freenode IRC is also quite helpful, as is #maemo for Maemo questions
Link: http://blog.hartwork.org/?p=156
I've also heard this book (also free) recommended: but I think it's more advanced, and I haven't looked at it yet: http://cartan.cas.suffolk.edu/oopdocbook/opensource/
#qt on Freenode IRC is also quite helpful, as is #maemo for Maemo questions
|
|
2009-12-14
, 04:23
|
|
Posts: 237 |
Thanked: 157 times |
Joined on Dec 2009
@ San Diego, CA
|
#23
|
Originally Posted by jaem
I haven't used this book in particular, but the Maemo-specific features of qt are so far quite minimal, and easy to pick up.
noobmonkey: I forgot to mention that if you want to learn Qt fast, you can get the previous edition of the official Qt book as a free download (it's too old to cover the Maemo-specific features of Qt, but it's a great book, and good as a general reference to Qt) The documentation is also quite good, although the book is a better place to start for most people. I'd read the first few chapters, then skim the conceptual overview pages on the Qt Docs (e.g. signals and slots, etc.)
Link: http://blog.hartwork.org/?p=156
I've also heard this book (also free) recommended: but I think it's more advanced, and I haven't looked at it yet: http://cartan.cas.suffolk.edu/oopdocbook/opensource/
#qt on Freenode IRC is also quite helpful, as is #maemo for Maemo questions
My previous experience with QT was with qt4.3 (and very briefly 4.4) and so far all of that knowledge/code has translated very well to 4.6 on Maemo
 |
|
2009-12-14
, 13:21
|
|
Posts: 3,203 |
Thanked: 1,391 times |
Joined on Nov 2009
@ Worthing, England
|
#24
|
Wow, impressed with all the help and support - thank you everyone 
Going to install ubuntu properly on my other laptop tonight instead of using a VM - will make the familiarisation alot easier
Going to install ubuntu properly on my other laptop tonight instead of using a VM
- will make the familiarisation alot easier
 |
|
2009-12-14
, 13:35
|
|
Posts: 529 |
Thanked: 262 times |
Joined on Dec 2008
@ Eastleigh, Hampshire, UK
|
#25
|
From my perspective I'd say use python. yes c++ *can* be faster, but only if you can actually get it to work. in my experience unless you are trying to push the limits of the device, the difference in app performance will be hidden completely by bad programming.
By which I mean you'll waste so much time trying to make c++ work at all, or do anything, that the theoretical performance difference isn't worth much.
of course if you already know c/c++ and are a super clever guy, then go for it. But for me, coming from a java background, I tried C, and it took me ages to get not very far, and I gave up trying to debug my segfaults. I just wasn't prepared to sink my time into getting good enough at C to make it worth while.
Python is *way* faster to develop and get on with for anyone that doesn't start with serious c experience.
In real terms I think I stand a better chance of writing performant Python than I do in C, just because I have a better understanding of what is going on. But maybe that's just me.
By which I mean you'll waste so much time trying to make c++ work at all, or do anything, that the theoretical performance difference isn't worth much.
of course if you already know c/c++ and are a super clever guy, then go for it. But for me, coming from a java background, I tried C, and it took me ages to get not very far, and I gave up trying to debug my segfaults. I just wasn't prepared to sink my time into getting good enough at C to make it worth while.
Python is *way* faster to develop and get on with for anyone that doesn't start with serious c experience.
In real terms I think I stand a better chance of writing performant Python than I do in C, just because I have a better understanding of what is going on. But maybe that's just me.
__________________
----------
N900
http://danielwould.wordpress.com
Check out Witter, a twitter client for N900
http://danielwould.wordpress.com/witter
If Witter isn't working for you, eg crashes/doesn't start, gives errors etc etc. Please run it from x-term using:
run-standalone.sh python2.5 /opt/witter/witter.py
This will generate diagnostic output. Without this I cannot help you.
----------
N900
http://danielwould.wordpress.com
Check out Witter, a twitter client for N900
http://danielwould.wordpress.com/witter
If Witter isn't working for you, eg crashes/doesn't start, gives errors etc etc. Please run it from x-term using:
run-standalone.sh python2.5 /opt/witter/witter.py
This will generate diagnostic output. Without this I cannot help you.
| The Following User Says Thank You to dwould For This Useful Post: | ||
|
|
2009-12-14
, 23:39
|
|
Posts: 237 |
Thanked: 157 times |
Joined on Dec 2009
@ San Diego, CA
|
#26
|
Originally Posted by dwould
I tend to agree, but one performance hurdle of python difficult to overcome is slow startup speed. Once your app is loaded users are hard pressed to tell a difference espescially if your app relies heavily on fumctionality provided by a relatively fast toolkit like qt or gtk.
From my perspective I'd say use python. yes c++ *can* be faster, but only if you can actually get it to work. in my experience unless you are trying to push the limits of the device, the difference in app performance will be hidden completely by bad programming.
By which I mean you'll waste so much time trying to make c++ work at all, or do anything, that the theoretical performance difference isn't worth much.
of course if you already know c/c++ and are a super clever guy, then go for it. But for me, coming from a java background, I tried C, and it took me ages to get not very far, and I gave up trying to debug my segfaults. I just wasn't prepared to sink my time into getting good enough at C to make it worth while.
Python is *way* faster to develop and get on with for anyone that doesn't start with serious c experience.
In real terms I think I stand a better chance of writing performant Python than I do in C, just because I have a better understanding of what is going on. But maybe that's just me.
|
|
2009-12-14
, 23:43
|
|
Posts: 3,203 |
Thanked: 1,391 times |
Joined on Nov 2009
@ Worthing, England
|
#27
|
well that was pants.......
I installed Kubuntu.... looked great for the first 5 minutes now all i get is a black screen after login..... just a sexy little mouse pointer....
Meh, may try ubuntu tomorrow instead....
I installed Kubuntu.... looked great for the first 5 minutes now all i get is a black screen after login..... just a sexy little mouse pointer....
Meh, may try ubuntu tomorrow instead....
|
|
2009-12-14
, 23:48
|
|
Posts: 237 |
Thanked: 157 times |
Joined on Dec 2009
@ San Diego, CA
|
#28
|
Originally Posted by noobmonkey
KDE4 still just isn't user ready in my opinion, gnome based ubuntu feels much more polished.
well that was pants.......
I installed Kubuntu.... looked great for the first 5 minutes now all i get is a black screen after login..... just a sexy little mouse pointer....
Meh, may try ubuntu tomorrow instead....
| The Following User Says Thank You to go1dfish For This Useful Post: | ||
 |
|
2009-12-15
, 09:11
|
|
Posts: 41 |
Thanked: 8 times |
Joined on Nov 2009
@ Zürich, Switzerland
|
#29
|
I just started as well and followed the disucssion until here... I guess I'm now at the same level as noobmonkey:
Set up my laptop with ubuntu, installed maemo sdk, installed esbox and started with the helloworld example...
But... that's where I'm stuck now: Somehow when I try to build the application, there keep errors showing up, saying that hildonmm.h and libosso.h couldn't be found (and some others). Where can I find these? Do I need to be online for building the application? Are they somewhere local on my disk?
Set up my laptop with ubuntu, installed maemo sdk, installed esbox and started with the helloworld example...
But... that's where I'm stuck now: Somehow when I try to build the application, there keep errors showing up, saying that hildonmm.h and libosso.h couldn't be found (and some others). Where can I find these? Do I need to be online for building the application? Are they somewhere local on my disk?
|
|
2009-12-15
, 09:18
|
|
Posts: 66 |
Thanked: 44 times |
Joined on Nov 2009
|
#30
|
Originally Posted by dwould
Valgrind is in the SDK repos and it works fine within scratchbox. It's a really useful tool for debugging segfaults and memory leaks. It's like an automatic screwup detector for C programming!
I tried C, and it took me ages to get not very far, and I gave up trying to debug my segfaults.
Of course, python is great. I mainly use C when there are no python bindings available for some library that I want to use.