[Sugar-devel] Moving to GTK3 and GObject Introspection

[Aleksey Lim]

On Sun, Aug 07, 2011 at 10:14:57AM +0100, Daniel Drake wrote:
> On Sun, Aug 7, 2011 at 9:53 AM, Aleksey Lim <alsroot at activitycentral.org> wrote:
> > +1, if during the process of moving to GTK3 sugar will be matured in all
> > directions that it will be ready for 1.0, then switch to 1.0 is obvious.
> > But not sure if it is a good idea to mix switching to gtk3 and trying
> > to be 1.0 (as a well matured platform) at the same time.
> 
> 1.0 doesn't have to indicate "mature product" - it could just indicate
> "new underlying technologies" - but you're right in that some people
> could/would interpret it with the "mature product" meaning.
> 
> It will be interesting to see what happens with Linux 3.0. This major
> version change means far less than ours would (they didn't change
> *anything* from normal release cycles), and so far it has not caused
> any misunderstanding/turmoil, as far as I can see.

well, it might make sense but see the following paragraph..

> But this view does raise a few questions: Do you think Sugar would
> ever be mature? To me, its one of those things that will always have
> major areas for improvement around the corner.
> 
> In the case of the HIG, have we seen much movement on compliance in
> the last 2 years? Would the design team even regard it as something
> that should be aspired to for a mature release? (I suspect it's quite
> out of date, as Sugar is a moving target)

It obviously depends on how someone is seeing sugar.

* If sugar is just a python based window manager with some library
  toolkit to code python applications for this shell,
  then sugar is pretty ready to do Linux-3.0 shift
  (and having bunch of very cool ideas to make horizons wider, e.g.,
  web based approach, integration with other DEs, etc.)

* For me sugar is more a social phenomenon when things like python based
  window manager are just tools to support this phenomenon.
  The sugar phenomenon for me is an ecosystem for doing (e.g., not
  only using). One of aspects of such doing (which is closer to me)
  is creating/changing software (ie, not only creating python based
  applications for particular python based window manager).

  And I don't see several (major for me) features implemented:

  - decent sharing/distribution method of software peaces
    Once more, it is not about well skilled devs who do it for years and
    have theirs software well packaged for all major distros.
    It is about sharing/distributing not-well-matured/one-day-hack/etc
    software that was done by not skilled devs (ie, sugar doers) as a
    part of theirs "learning while doing" process.
    It is also about that current .xo model is *too* ineffective in
    several ways:

    - lack of dependencies when activity devs need to bundle (with all
      related minuses) or rely on particular sugar distributor that it
      will include some software (initiatives like Sugar Platform are
      "fixes" only in short time period)
    - it supports only python (or script based in general) software
      taking into account the lack of dependencies, ie, if activity is
      ruby based, there is no any guarantee that it will run on sugar
      box as-is

  - no official sdk/toolkit to support non-python software/activities
    but there is what Etoys did, ie, using low level dbus access but no way
    to create sugar looking UI library,
    but there is Polyol library that is vala based and can be used (and
    used in GCompris and Tuxpaint) for wrapping all dbus internals to
    high level API + gtk UI toolkit instead of python based
    sugar-toolkit

  - another way to avoid only-python doing, is reusing web technologies
    like what was done in Gnome3 and KDE4
    eg, WebSDK (or any other SDKs) are the things that need to be
    introduced in Sugar-1.0

  I just mentioned the major points for me, maybe other people have
  different ones. So, sugar is not ready for 1.0 for me. Of course
  switching to gtk3 will make it closer but thats not enough.

> In the end it is only a number, and there isn't anything wrong with
> sticking with the current scheme, even if the discussion did go in the
> "1.0" direction last time - see
> http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/25094/focus=25156
> - but how would the existing scheme work? What release comes after
> 0.98? 0.100? Then 0.102?

Well, it is a matter of taste...
For me 1.0 should have at least initial implementations for what , at least,
I mentioned in previous paragraph. For me having 0.102 sounds better
then 1.0 w/o features I talked about.

-- 
Aleksey