Re: GTK+ modularization



On 7/14/06, Sean Kelley <sean sweng gmail com> wrote:
I think you have to be careful about even embedded specs.  For
example, I am working on a device that has 1 to 4GB of flash space and
64 to 128MB of RAM.  A Nokia 770 would be a good parallel, although
with less flash space on board.  These sort of specs are more in line
with consumer devices.  They are still running arm processors.

Sean


I guess my point on embedded is there is some minimal code size
that should be the target and we need to fit as much as possible in there.

Generally on embedded devices you can have X amount of code.
If X is large then just use the full implementation 1-4GB of flash is not common
if you have it then your not code size constrained.

I'm basically suggesting that the overall code base should build in

2 4 6 8 ... versions.

On top of the base builds you would have your custom widgets.
Or you need to customize the smallest build if its too large.

My point is lets first figure out what the smallest build should be.
Adding stuff is the easy part.

Is the smallest build 2 mb 4 ??  Is it a useful build ?

My approach has been to focus for now is on using only gdk not gtk.

But its not a complete solution since you could use a really small subset
of gtk.




On 7/14/06, Mike Emmel <mike emmel gmail com> wrote:
> Hmm I'm not sure what to say I don't think that the nature of emedded programing
> is comming through our its needs.
>
> Generally your running a small set of custom apps if you provide a
> public api (rare)
> Someone targeting the device will port to it.
> If you have the luxury of tons of space then run full gtk.
> If not a minimal base set that at least get gtk in the picture followed
> by domain specific standardization is what you want.
> Look at J2ME for a lot of good concepts they use device profiles.
>
> Its not the desktop world. Basically if you want gtk to become useful on
> embedded platform you need to shoot for a total lib footprint of 1-2
> megs for the base
> system.
>
> I worked on JSR209 which was cutting swing down to fit on the mobile.
> The experience
> left me doubtful that its really a good idea since the needs of the
> two communities differ so radically. Te chnically it looks good by you
> have to cut the system to the bone first and there is a lot of
> resistance to doing that from the desktop developers.
>
> If your serious about embedded gtk then figure out what you can do
> with a version of
> glib gtk cairo atk libpng etc that fits in 1-2 megs first.
>
>
>
>
>
> On 7/13/06, Allin Cottrell <cottrell wfu edu> wrote:
> > On Thu, 13 Jul 2006, muppet wrote:
> >
> > > As i understand it, the target for this modularization is not
> > > desktops --- it's embedded devices.
> >
> > Hmm, perhaps I haven't been following this closely enough.  In
> > an embedded context the slimming of GTK certainly make sense.
> >
> > > Therefore I heartily condone the effort to make subsets that
> > > can be turned off, but with respect to your concerns about
> > > portability of desktop apps, would suggest that these subsets
> > > are not advertised as useful for desktop systems.
> >
> > Yes.  I find it's surprisingly easy for people to shoot
> > themselves in the foot, and anything that makes that less likely
> > is welcome.  (In this context, shooting self in foot =
> > installing or building a GTK runtime that will not support all
> > the apps the user wants to run.)
> >
> > --
> > Allin Cottrell
> > Department of Economics
> > Wake Forest University, NC
> > _______________________________________________
> > gtk-devel-list mailing list
> > gtk-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]