screenlets-dev team mailing list archive

[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.


> 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.

> > 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!


> 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.

> 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++."

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.

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.

Cheers,

Guido Tabbernuk