[maemo-developers] [maemo-developers] Re: Proper documentation (was Re: HildonProgram input to gtk_widget_show()?)

[From: Danny Milosavljevic]

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