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

2006-12-01 Thread Dave Cridland

On Wed Nov 29 19:46:51 2006, Danny Milosavljevic wrote:
[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 / ?]


No, I, too, have about 1G on /, and 317G on /home/, so I put it all 
in /home and symlink, which works just fine:


lrwxrwxrwx 1 root root 16 2006-10-15 19:58 /scratchbox - 
/home/scratchbox


Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


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

2006-11-30 Thread David Weinehall
On ons, 2006-11-29 at 22:39 +0200, ext Marius Gedminas wrote:

[snip]

  [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 / ?]

Never heard of mount --bind?

I don't have my scratchbox installation on the root-disk, I just have it
bind-mounted from another partition.  Works just fine.  Of course, I'd
rather see it packaged the way a real Debian package is supposed to be.

 I used to do that, but then I've learned and now I just put everything
 into one big partition.
 
 And yes, /scratchbox/ is a bad place.  It does not follow the Filesystem
 Hierarchy Standard.  It should be /opt/scratchbox.  And the Debian
 packages should copy/symlink the /opt/scratchbox/login script to
 /usr/bin/sbox or something.

No, Debian-packages should install things in /usr/bin, /usr/share
and /usr/lib.  It should *NOT* install things in /opt and use symlinks.

Debian packages should *NEVER* install anything to /opt or /usr/local.


Regards: David Weinehall
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


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

2006-11-30 Thread Eero Tamminen
Hi,

ext Marius Gedminas wrote:
 [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 / ?]
 
 I used to do that, but then I've learned and now I just put everything
 into one big partition.

When I was using the older tarball versions of Scratchbox, I just extracted
the new one somewhere and then swapped a symlink to /scratchbox from an
earlier version to the new one (i.e. keeping the old Sbox around in case I
need to downgrade i.e. switch the symlink back after doing sbox_ctl
stop).


   - Eero
   
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


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

2006-11-29 Thread 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

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


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

2006-11-29 Thread Marius Gedminas
On Wed, Nov 29, 2006 at 07:46:51PM +, Danny Milosavljevic wrote:
 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 want this too!

 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.

Reading /scratchbox/login: if you give it -d dir, then it chdirs there.
Hey, and you can give it a command to run--this actually works!

  /scratchbox/login sbox-config -st SDK_ARM
  /scratchbox/login -d nflick dpkg-buildpackage -rfakeroot

where nflick is relative to /scratchbox/users/$USER/home/$USER

 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 ;)

Apparently you don't need to.

 [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 / ?]

I used to do that, but then I've learned and now I just put everything
into one big partition.

And yes, /scratchbox/ is a bad place.  It does not follow the Filesystem
Hierarchy Standard.  It should be /opt/scratchbox.  And the Debian
packages should copy/symlink the /opt/scratchbox/login script to
/usr/bin/sbox or something.

Marius Gedminas
-- 
This message has been ROT-13 encrypted twice for higher security.


signature.asc
Description: Digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers