On Thu, Jul 17, 2008 at 9:37 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> Lots of reasonable points made on this thread.
>> The two cents I'd like to throw in are:
> $0.01: we shouldn't feel like shipping unsugarized apps is a failure:
> better an working app w/ crappy UI than no working app at all!
> $0.02: my suggestion to "replace" Browse wasn't to eliminate the
> sugar-specific UI work, simply to suggest that we could more
> profitably base it on Firefox than Gecko. Similarly, minimizing the
> differences between upstream Abiword and write is (IMO) a Good Thing.
> We should keep our forks as small as possible, so that we can most
> effectively use the work being done upstream.
>> For Firefox, that means (for example) that we can use upstreams
> Awesome Bar instead of reimplementing our own url completion. For
> abiword, it means acknowledging that a lot of our initial Tubes port
> was/is simply unnecessary now that we have a stream-based
> collaboration mechanism, and we can/should be able to strip down Write
> as a consequence. It's possible that we can most fully utilize
> Abiword/GTK's theme mechanism to make Sugar UI "upstreamable" as well.
> Again, the point is to reduce our diffs with upstream.
Yes, I agree that this is a goal that makes a lot of sense.
Unfortunately, my experience says that the approach you are suggesting
won't be less work than what we are doing right now, because the
software components you mentioned aren't so easily malleable as you
seem to think.
Check out the sources for abiword and gnumeric and grep for MAEMO, do
you think those projects will let everyone add their ifdefs to suit
their UI choices?
Checkout microb-engine from maemo, they include their own patched mozilla.
This approach might work well for Nokia and their dozens of engineers
working on Maemo, but for the Sugar guys? At this time we would be
even more insane than we are and we would have provided a much worst
experience to kids.
Seriously, embedding a gtk widget like the ones we have in Read, Write
and Browse gives a pretty sweet spot in customizability. Adding some
buttons and calling methods on that widget is not hard, we actually
reuse all the hard work in the upstream project while choosing
carefully the way in which we expose that functionality to users.
If we count the amount of man-hours that went into those activities
and told the nokia executives in charge of maemo, I think that they
would be quite surprised...
And then, having children and activity authors in general being able
to read the code and embed those widgets in their python activities...
that's invaluable, in my opinion. A maemo-tinkerer would need to set
up a build box in order to add a button to the toolbar of one of those
apps.
Regards,
Tomeu
(sorry if I have offended anyone regarding Maemo. I know little about
it, just have seen how they integrate with upstream projects and
wanted to make the point that this wouldn't work for us)