← Back to team overview

screenlets-dev team mailing list archive

  1. screenlets-dev team
  2. Mailing list archive
  3. Message #00306

Re: Screenlets developpement ?

  Thread Previous • Date Previous • • Thread Next 
Hello everybody,
As you may have noticed, I have created a new branch of Screenlets and a new team to drive it (see https://launchpad.net/~screenlets-stayinalive and https://launchpad.net/~screenlets-stayinalive). I didn't plan to start a new branch for good. I already had some fixes and mods for Screenlets in the pocket, because I adapted it to an Estonian localized Ubuntu distro called Estobuntu (see http://estobuntu.org/estobuntu-english). I just didn't want to loose all this work and reading the Screenlets mailing list and bug reports, it appeared to me that this project is dead for more than two years and nobody cares. So this is my apology for splitting up.
Seeing now some movement on Screenlets main branch, I think it would be good for me to merge my changes and continue with one original Screenlets. However, there will be a problem whether to continue from Screenlets or Universal Applets. For my part I chose Screenlets for my mods, because Screenlets worked "out-of-the-repo" and U-A had problems with really basic things (and was not tested in wild). Since I have by now an updated and quite reasonably well working modification of Screenlets branch (at least in Ubuntu Maverick), I suppose this can be merged first, and then part by part, U-A can be added (while Natan cleans up the U-A source tree and gives some basic comments on what is good and stable and what is just a sketch).
What is that I have done for Screenlets? I have tried not to add any functionality that would break anything, just in order to use the current iteration the best way. I even avoided fixing things which were straightforwardly stupid in the code, but still worked. 

Screenlets Core
* Applied the fixes I thought reasonable from the bug tracker (but not all of them). * Fixed the UI to work with latest Ubuntu distros and did some cosmetics (tray icons, tray menu icons, icons on some buttons, some menu updates etc). * Fixed the bugs with loading themes and Screenlets with the same name (implemented versioning). 
    * Implemented logger.py from U-A.
* Doubled some variables and added some functions in order to make Screenlets eat both from the pot of U-A and its own. * Updated (and reworked) part of the translation strings and made it cooperate with Launchpad translations (auto-updates and stuff). 
    * Created a command line Screenlets Debianizer (more to follow).
* Implemented already present Screenlets class __requires__ field to point to required packages. * Moved most of the Screenlets from the Core package to Extras package and left only six of them (Calc, Clock, Flower, Notes, Slideshow, Trash). * Linked "Get more Screenlets" to http://www.screenlets.org/index.php/Get_more_screenlets instead of the Screenlets.org own Screenlets list.
The hottest news is debianizing and installing from repo, which hasn't been really available before. Installing straight from the repository is the safest way of installing anything and users will receive updates of course, dependencies are tracked etc. I made all this relevant and available for the Screenlets. The user has now four different sockets for Screenlets:
1) /usr/share/screenlets is the place where the basic example Screenlets are installed. These are really for the example and should be generally usable or fun. Now they are part of Screenlets Core package, but maybe it should be made something like screenlets-basic-pack. It includes only six Screenlets now, but I suppose if we find suitable Screenlets which work fine and are polished enough we can raise the number to 16 or something like that. More would be already hard to grasp to users who want to just check it out (no need for too specific screenlets).
2) /usr/share/screenlets-packs is the place where Screenlets additional packs would be isntalled. These would be thematic I suppose, for example screenlets-clocks-pack, screenlets-networking-pack, screenlets-weather-pack etc. These packs have the same status as the big screenlets-extra-pack, which presently contains almost all the U-A screenlets I made to, if not to work then at least run with Screenlets Core (last generation Screenlets are screenlets-extra-pack-old). These packs cannot overwrite each others contents. If extra-pack is installed, user generally cannot have overlapping smaller packs and vice versa.
3) /usr/share/screenlets-indiv is the place where individual debianized Screenlets are installed. This should be actually the main line for installing Screenlets. The big packs mentioned in the last paragraph are more like to have a look what are the possibilities and which Screenlet seems to be most usable. But when this is decided for user, it would be meaningful to uninstall the big package and not waste the disk space, and more important the UI space for the garbage that is not needed. Just to install the individual ones really needed and get the automatic updates for them.
4) ~/.screenlets/ will stay the place where user will manually (or from Screenlets Manager) install the Screenlets and themes. By now themes are not installed from repositories, so this is the only place where user-installed themes will be. Themes can be installed there without having a Screenlet itself installed in ~/.screenlets/ directory.
All these four sockets are checked for the latest version of an individual Screenlet by Screenlets Manager and daemon. So if user installs a newer version in any of those places, it will be used. So the correct version string in the Screenlet class header will be really essential. Themes will be checked from all system directories and, from the Screenlet's own directory and from the user home (~/.screenlets/*/themes/). Theme versions will not be checked, but the theme in user's home directory will be preferred to the ones in system directories (the order is: user -> individual deb -> deb from package -> core package).
Individual debianized Screenlets are created automatically by Screenlets Debianizer and uploaded to PPA. Debianized Screenlets have proper versioning and the dependencies will be added from Screenlet class header. It will be convenient to find desired Screenlet quickly from package manager by the pattern foobar-screenlet[-foo] (the last part would be for the modifications of the Screenlet).
All this makes Screenlets a quite usable piece for my mind and still worth being alive for couple of years (although I have some ideas about the future). I don't know how much all this helps the development, but it is at least something. 

What I did notice and not fix:
* Menus doubleing when adding same Screenlets from cache. I just didn't bother, because this happened too seldom. * Some strange issue with the theme loading and overriding. The colors overidden by theme were not always used and this flickered during one session couple of times because of some unidentified action. * Many individual Screenlets need to be updated to work fine and even to function (for example network speed Screenlets do not work really etc). I didn't bother to fix all this at once. This was not my goal.
Results of my work can be checked out in reality from Screenlets Stayin Alive PPA (ppa:screenlets-stayinalive/screenlets, https://launchpad.net/~screenlets-stayinalive/+archive/screenlets). I have put there the Screenlets Core 0.1.3 and all the individual Screenlets from screenlets-extra-pack as well as the extra-pack itself (and extra-pack-old). Have a look and give your feedback!
To be honest, I don't plan to get really into developing Screenlets into something amazing. I just wanted to fix it for use. So I might do something in the future, but I don't know if I have time to spend. If that's OK by your mind, I will first just merge my code with main branch. I can later try to merge the code with U-A and manage things a bit, but I don't give any promises. 

I have also created some documentation with the Stayin' Alive project...

Some explanations and installation instructions
http://www.screenlets.org/index.php/Screenlets_Stayinalive

What's not written up here has probably got marked in
http://www.screenlets.org/index.php/Screenlets_Stayinalive_Documentation

Now the main questions for me are, if this stuff is good enough:
1) to be put into Screenlets Team's main PPA as legitimate Screenlets 0.1.3... ? 

    2) to be merged with Screenlets main code branch... ?
3) and if the idea of having the structure of separate a) screenlets, [a1) screenlets-basic-pack,] b) screenlets-extra-pack [c) and screenlets-dev containing screenlets-packager/debianizer] is good enough to be realized for the main Screenlets project... ?
If any of this sounds reasonable to you, please give comments and your preferences about the specifics of it. Otherwise I have to keep my thing separately as the Screenlets' last retro-nostalgic Stayin' Alive project. But as I think my modifications really work, I want to publish them to the community anyway. I believe that publishing under main Screenlets project would be good, because it would bring some publicity to the project and maybe some new people would be interested in development. 

And the last word...
Actually I believe that in the coming future Screenlets need to be developed more as a Compiz plugin than a standalone system (or set of plugins or/and combined with some applet/application install/configuration system). Nowadays absolutely every application can be a widget on the screen. There is no need for Screenlets framework like the present one. I believe, the point is to make it easy for applications to offer a widget mode for users. So there will be no need for separate Screenlets or Universal Applets. I believe so-to-call Screenlets should be more integrated into the desktop and window manager. I believe this needs some really good thinking and design and I'm not sure if that's too much connected with the current Screenlets or even Universal Applets (at least not the source code I believe). But for sure having Screenlets ready and working is a stepping stone to some wilder future developments.
Maybe Natan can comment on how Universal Applets positions among these things. The project anyway cries for proper documentation as I believe, there are basically only some vague blueprints. 

Sincerely "etc",
Guido Tabbernuk

29.10.2010 04:15, Natan Yellin kirjutas:

Maybe. I'll try to look at it next week.
On Thu, Oct 28, 2010 at 9:10 PM, Julien Lavergne <julien.lavergne@xxxxxxxxx <mailto:julien.lavergne@xxxxxxxxx>> wrote: 

    Do you have the possibility to quickly isolate the part of the
    code using GtkPlug/GtkSocket ? So it will be easier to merge the code.
    Otherwise, I'll try to look at it, but I think it will take less
    time if you look at it (you know the code more than me :)). I can
    manage the code merge once it's isolate.

    Regards,
    Julien Lavergne


    On Thu, 28 Oct 2010 20:38:54 +0200
    Natan Yellin <aantny@xxxxxxxxx <mailto:aantny@xxxxxxxxx>> wrote:

    > Hi Julien,
    > I don't have time to work on this atm, but I think we should base
    > development off the UA branch. A lot of the code has been
    refactored and
    > there are a number of bugfixes and new applets/screenlets that
    aren't
    > present in Screenlets.
    >
    > I propose taking the UA branch and stripping out all of the
    Universal
    > Applets functionality. (For now, at least.) I think you'll get a
    faster and
    > more stable product that way in only a fraction of the time.
    (Most of UA's
    > shortcomings and bugs are due to problems with the GtkPlug/Socket
    > architecture that's used to embed applets anywhere. If we remove
    that code
    > then everything should be stable.)
    >
    > Regards,
    > Natan
    >
    > On Thu, Oct 28, 2010 at 5:37 PM, Julien Lavergne
    > <julien.lavergne@xxxxxxxxx <mailto:julien.lavergne@xxxxxxxxx>>wrote:
    >
    > > Hi,
    > >
    > > Recently, some people show interest to continue the
    developpement of
    > > Screenlets. I really would like this happens, as the Debian
    and Ubuntu
    > > Maintainer, an upstream project active is a very good thing :)
    > >
    > > To avoid confusion, fragmentation etc ... I really think we
    should all
    > > focus on the main project on Launchpad
    (https://launchpad.net/screenlets),
    > > and only on one branch (
    > > https://code.launchpad.net/~screenlets-dev/screenlets/trunk
    <https://code.launchpad.net/%7Escreenlets-dev/screenlets/trunk>).
    > >
    > > Do you have plan to restart developpement ? There is no
    progress since more
    > > than 1 year, so I suppose you don't have a plan for the future ?
    > >
    > > What I can propose, is to give someone else Admin rights on the
    > > screenlets-dev team, so we can accept more developers, and
    re-start the
    > > developpement in only one place.
    > >
    > > Note that the UA branch is something different, as it's quite
    different, we
    > > need more time to review it and possibly integrate it. But at
    least,
    > > re-starting the developpement of the currrent branch will be a
    huge
    > > improvement.
    > >
    > > Thanks in advance for your answer.
    > >
    > > Regards,
    > > Julien Lavergne
    > >


    --
    Julien Lavergne <julien.lavergne@xxxxxxxxx
    <mailto:julien.lavergne@xxxxxxxxx>>
  Thread Previous • Date Previous • • Thread Next