[Sugar-devel] Duplication of effort

[Jim Simmons]

Luke,

A logo-compliant (not the right word, but the concept is similar)
Sugar app needs to interface with the Journal.  It should have a
toolbar.  Ideally, it should support some kind of collaboration or
sharing.  Now if I wanted to convert one of the KDE education programs
to run under Sugar and meet the human interface guidelines how much
work would using QT instead of GTK really save me?  I'd still have to
pretty much rewrite the UI anyway.  I've thrown together a few
toolbars for Sugar Activities and it isn't that hard or even time
consuming.

There were some emails in the past on how Tux Paint can't save to the
Journal so you can't use it with Memorize, etc.  The GCompris chess
programs let you play with the computer but not with another child.

Maybe comparing this to MS-DOS under Windows 3.1 is a little harsh.
How about Windows apps running under Wine?

James Simmons


On Mon, Jul 27, 2009 at 3:09 PM, Luke Faraone<luke at faraone.cc> wrote:
> On Mon, Jul 27, 2009 at 15:36, Jim Simmons <nicestep at gmail.com> wrote:
>>
>>  I too don't see much future in sugarizing existing QT or GTK apps.
>>  Running
>> something like that is a bit like buying Windows 3.1 and using it to
>> multitask MS-DOS apps.
>
> 'fraid I don't understand the comparison. MS-DOS -> Windows 3.1 was the
> introduction of a whole new UI, that of a graphical one. Sugar is just
> adding new APIs to existing toolkits. Much more time would be spend
> "reinventing the wheel" if we were to rewrite all the QT and GTK+/GTK# apps
> that had educational functionality we liked in PyGTK than if we were to just
> wrap/Sugarize the apps.
> A variety of wildly popular and useful Sugar Activities are re-tools of old
> GTK applications, such as Write (AbiWord), TuxPaint (itself), and Metropolis
> (itself), xoIRC (urk), Colors (itself), and Scratch (also itself). The list
> goes on and on.
> There are a number of applications at http://edu.kde.org/ which would also
> benefit the Sugar ecosystem. After Tomeu provides the base, in terms of Qt
> bindings for Sugar, it will open the door to the porting of most of these
> without considerable effort.
>
>> while some QT programs are superior to their GTK counterparts it isn't the
>> toolkit that makes them superior.
>
> Completely correct. However the fact remains that the work is already
> *done*, and porting them to GTK would take much more work than porting them
> in their current Qt form to use Sugar.
> --
> Luke Faraone
> http://luke.faraone.cc
>