screenlets-dev team mailing list archive

[Rico Pfaus <ryx@xxxxxxxxxxxxxxx>]

Am Donnerstag, den 09.12.2010, 07:47 +0900 schrieb boamaod@xxxxxxxxx:
> 08.12.2010 20:50, Rico Pfaus wrote:
> >
> >> 1. Project for individual Screenlets development:
> >> https://launchpad.net/indiv-screenlets
> >>
> >> I added all the Screenlets as well as all of Universal Applets and some
> >> more Screenlets (quite randomly) from Gnome-look.org. There is 89 of
> >> them now. Not all of them function though, but most of them at least
> >> start and do something. I also created two packages that the project
> >> produces:
> >>
> >>       screenlets-pack-basic
> >>       screenlets-pack-all
> >>
> >> If you want some actual Screenlets to be distributed with "screenlets"
> >> core, you have to distribute also at least the package
> >> "screenlets-pack-basic". There are no Screenlets in package
> >> "screenlets", but "screenlets-pack-basic" is "recommended" by it and
> >> "screenlets-pack-all" is "suggested". This is to make
> >> installation/updating/removing of Screenlets more dynamic.
> > I like really that. Only change I'd propose is to let the core depend on
> > pack-basic (instead of just recommending). Otherwise people might be a
> > bit confused if they install the screenlets package but have nothing
> > they can use. But that's up to discussion.
> The advantages of "recommending" is that user can remove the pack-basic 
> if needed and/or replace it with some other pack (for example the 
> pack-all). This would be quite complicated when the package is to be 
> "depended on". "Recommending" makes the system more 
> modular/configurable. I'm thinking here mainly of distros, which may 
> want to include the Screenlets by default, but not the selection of 
> Screenlets from our pack-basic, but their own. This kind of 
> customization would work "out of the box", if we just "recommend" the 
> pack-basic. On most systems installing "recommends" is the default 
> behavior anyway.
Ok, though I don't know of any distros that provide own screenlets. But
who knows, maybe this encourages them to do. I am fine with that.

> 
> > Also a nice improvement, really good to have that separated now. This
> > reminds me that we badly need to clean the core (and likely many
> > screenlets) from translated debug messages. It should make translating
> > much more comfortable and less time-intense.
> >
> I cleaned most of the core from the gettexted console messages. See 
> revisions 486 and 518 and maybe some more. By now only Screenlets 
> packager and debianizer have translatable console messages. Of course 
> it's quite okay to remove these too. I felt that maybe I already removed 
> too much, so I didn't remove these yet.
Ok, cool. Those translated debug messages actually made debugging much
more difficult.

> 
> >> As next step I'd consider fixing individual Screenlets and doing some
> >> work on the core, but I don't really have time to do it. I'd like to
> >> encourage users of individual Screenlets to fix the bugs, but this
> >> hardly works. Using Launchpad and Bazaar is too much for most of them.
> > I'll see if I can find the time for it. I already fixed my own
> > screenlets on my local working copy and did some minor core fixes.
> I hope your local copy doesn't diverge too much. Better check your 
> changes in soon!
It's mostly related to some screenlets, my core fixes can be easily
merged by hand.

> 
> > I'd also really like to know what were the major changes in the U-A
> > branch - besides the whole "melange server" thing and changes related to
> > that. From what I can see there were just some structural changes and
> > minor bugfixes? Maybe Natan can sum that up.
> >
> Well, there are hundreds of check-ins of you look at the log. I wouldn't 
> call all of these "minor bugfixes". There are lot of improvements to the 
> code, but some of them are not really finished. I would really like to 
> know, which of them are considered important/critical and should be 
> definitely merged into Screenlets. I personally don't really understand 
> Screenlets framework, I have just fixed some things, but I don't have 
> picture of the whole. It's really hard to decide for me what should be 
> merged.
Hmm, my bad. It's been a while since a checked the U-A commits, so maybe
Natan can shed some light on this.

> 
> > I never used Google Gadgets, but I guess the major difference between
> > Screenlets and other widget frameworks is that Screenlets in fact are no
> > "widget framework" :-) ...
> >
> > The Screenlets-API has no limitations, Screenlets are just common
> > desktop apps with a more modern, "task-oriented" look. Most (all?)
> > widget engines are limited to some sandboxed, HTML-driven toy-API,
> > whereas Screenlets can utilize the full repertoire of anything Python
> > and Linux have to offer.
> >
> > Developers have to understand this difference and realize that they can
> > do very different things using Screenlets - things that other frameworks
> > might not be able to.
> 
> I think Google Gadgets can be coded using various kinds of programming 
> languages and can be run on various levels of system. I read from FAQ: 
> "JavaScript is the preferred language for Google Desktop gadgets. 
> VBScript gadgets do exist, but are uncommon. It is possible to write 
> gadgets in C#, VB.NET, C or C++."
Interesting. I always had the impression that Google Gadgets are
HTML-driven widgets that run within a single host process much like
Apple's Dashboard. So are they actually full-fledged, standalone
applications? From what I knew they always rely on a webkit
HTML-rendering control as base. Maybe that's changed throughout the
years.

But I guess it's not wise to attempt such competition or comparison
anyway, instead Screenlets should try to find their own "niche" and just
do their job as good as possible. Python is a very popular language on
the modern Linux desktop. If we understand Screenlets as a
python-library for creating cool and handy mini-apps in the first place,
there is no reason to compete with existing widget frameworks. But
that's just my opinion, I understand that the separation between "widget
framework" and "handy mini app" is rather minimal and probably
non-existent for the end-user.

> I agree, that Google Gadgets are not so close to core of the system, but 
> I wouldn't call them based on a toy-API. Their intention is to offer 
> really easy and customizable widget framework, which is in many senses 
> much more powerful than Screenlets framework. For example using GTK+ 
> widgets is problematic in Screenlets, but Google Gadgets offers you any 
> kind of GUI objects for easy use. Screenlets suggests that you use only 
> drawing functions and pop up menus and basically no real interaction.
You're right. That's because Screenlets were never designed to use GTK
widgets inside their visual area. Originally they were really just
planned to solve a single purpose - much like Clock, Ruler, *-Meter did.
The "problem" was that most developers wanted to create more
feature-rich widgets that required much more UI elements than the simple
ones did.

I often thought about (and even started) implementing a Sprite-driven
API that allows for much more comfortable widget creation and improved
portability of Screenlets between toolkits and platforms. But to do that
peformant and usable it would have required to move away from Python as
core language, recreate the core in C and then create language bindings
for different languages. 

Eventually it would have led to creating something equal to Plasma or
Google Gadgets. All that would have produced a giant pile of work and
had needed careful planning by more than a handful of individuals. It
also raised the question if the world really needs yet another big
widget framework. That's why I put that idea back into the dark corners
of my mind and decided to just keep things as they are :) ...

I would happily contribute to such a project but I simply don't have the
time to start something like that myself and I am very sceptical that
the Screenlets should (or can) be extended to such "universal applet"
thingy without moving away from Python and restarting from scratch.

(Sorry, got carried away a bit :) ..)

> And in your statement you forget Plasmoids, which are really dynamic and 
> do not have most of the shortcomings of Screenlets. Actually Plasmoids 
> can be run on GNOME too, but then you have to install Plasma itself of 
> course, which is a bit nonsense.
True. When I created the screenlets there was no Plasma and I never
looked into it since it's too KDE-related for my taste. I always felt
that Gnome/GTK users usually don't like "mixing" toolkits or desktop
components. But you're right - Plasma is indeed powerful and no toy-API
at all :) .. I think that was one driving force behind Natan's U-A
"melange" server changes.

> 
> Cheers,
> 
> Guido Tabbernuk

best regards
Rico