Hi, On Wed, 29 Nov 2006 12:24:46 -0500, Mike Frantzen wrote: > I think it's even worse than that. There are enough differences to the > usual linux/gtk development environment that the N770 is very > frustrating to develop for.
I find it actually quite nice. There are some memory-saving quirks (as expected for an embedded device), but overall it is very nice to program for. >[...] > The N770 > used enough bleeding edge technology that it has some very sharp edges; > and as a developer I really don't like the bleeding part. > > The big ones that immedietly come to mind are: > 1) gstreamer which I understand if you want to offload multimedia to > the DSP. It's just too bad that it's not stable. They are (were?) hiring, go and fix it so it _is_ stable ;) > 2) dbus/libosso. blech, complex solution to a simple problem. very > "Windows" like Well, even being an old-school communicating-processes-with-pipes UNIX model thinker, I have to admit that on an embedded platform there just isn't enough RAM to do it the right way (likewise to develop a GUI app in C is madness, usually - that I take part in regularily ;) -, but there just isn't enough RAM to do otherwise). Now if you specified what exactly is bad about dbus/osso... > 3) hildon-specific gtk widgets instead of just modifying the stock GTK > widgets to work well on the N770 platform > > Porting existing applications to the N770 involves rewriting some things > and kludging the hell out of others. Both which make it much less > likely that the diffs will be accepted back into the main application's > source tree. Which means the porter has to maintain his diffs out of > the tree which is a big PITA. I see where you are coming from. I usually assume GTK as a platform as an unchanging entity (even _binary_ compatible since time immemorial). That said, with IT2006, the only special-case I have left is hildon_window_new, hildon_program_* stuff and the mime callback, all in all maybe 20-30 lines. It's not like the whole development paradigm changed. > Writing new applications for the N770 locks your application into the > N770 platform or you implement a lot of things twice, once for the N770 > and once for everything else. My experience negates that. You do design the GUI look twice, by neccessity. The display is smaller and higher resolution than any PC display and stylus input neccessites some changes. The other stuff is fine just like it was. > You end up doing things twice since it's > much more pleasant to debug outside of a N770 or a scratchbox. Hmm, I dislike the two-environment stuff as much as the next guy, but I don't see a way around it. Is there a way to do something to the tone of like: (outside of scratchbox) cd scratchbox/home/user/source/foobar/source/ scratchbox-batch SDK_ARM make I.e. I'd like to avoid having to do manual mode changes with "/scratchbox/login" / "exit" all the time just to issue "make". And "/scratchbox/login" doesn't take the working directory you were in (before calling it) into account. Hmm, I should just check what "/scratchbox/login" does and hack something up myself... after all, this might be some weird special thing that interests only me, again ;) [and "/scratchbox/" is a bad place to put scratchbox to, am I the only one to have almost all the harddisk space on "/home/" and almost none on "/" ?] cheers, Danny _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
