screenlets-dev team mailing list archive

[Natan Yellin <aantny@xxxxxxxxx>]

Hello,

On Sun, Mar 15, 2009 at 5:56 PM, Rico Pfaus <ryx@xxxxxxxxxxxxxxx> wrote:

> Hi everybody!
>
> While browsing through the current code of the screenlets there were
> many things that came to my mind. This is a rough list of thoughts,
> ideas and plans I had while browsing the code. Some things may need
> further discussion and refinement, some things seem to be already done
> in universal-applets. Natan (or whoever reads this), if you have any
> comments, feel free to add them.
>
> - All screenlets should be moved into one separate launchpad project and
> be removed from the core. The core should just contain the core library
> stuff. The same for the plugins, though we then may need a
> plugin-dependancy-system and -check within each screenlet, but that
> should be useful anyway (e.g. to display human-readable messages about
> missing deps instead of just crashing with python errors). A simple list
> with dependancies would be nice here (or do we have such thing
> already?).

In Universal Applets we moved all of individual screenlets into a separate
branch. It helps with organization and allows us differentiate between
screenlet developers and core developers.
https://code.launchpad.net/~universal-applets-extras-team/universal-applets/universal-applets-extras<https://code.launchpad.net/%7Euniversal-applets-extras-team/universal-applets/universal-applets-extras>

I never really understood the purpose of the plugin system (because it's
really just a module and not a plugin system), but we've discussed tracking
package dependencies (e.g. gnome-keyring) in the past. If the plugin system
allowed installing new plugins, then tracking plugin requirments would be
great as well.

>
>
> - Utils.py needs cleanup and a better organization of functions, many
> things don't belong in there (e.g. Evolution-specific code,
> file-handling stuff, etc.). The utils.py was never intended to become a
> general purpose utils module, it is a utils module for
> screenlet-specific functions to be used by external (i.e. non-screenlet)
> applications. Although we maybe should move all those to the
> screenlets-module itself and then really use utils.py as general-purpose
> lib. For fs-related functions maybe a sub-module like e.g. "utils.file"
> would be an option?

Yes. There's also a lot of inconsistency in function names, but we've tried
not to change anything to avoid breaking compatibility. Now that most of the
screenlets are in our own branch, we have a bit more freedom with that.

>
>
> - Screenlet-class needs to become its own file and the screenlets-module
> __init__.py should just hold utility functions (maybe what was
> originally placed in the utils module?) ... (seems to be partly done in
> U-A)
>
> - The entire code badly needs one consistent coding style and a document
> that describes the coding guidelines.
>
Pefi and myself did some work on style guidelines for UA. They're not
complete but they can be found in  the DEVELOPERS file.

>
> - The plugin API may need some refinement.
>
> - The whole sensors module needs to be re-thought. Maybe it should
> instead become a plugin or be moved to a different place. At least it
> badly needs refactoring.

Agreed. Most of the comments made about utils apply here as well.

>
>
> - Unfortunately there was a rollback of my option changes in rev82 and
> the OptionGroup was stripped due to backward compatibility issues.
> Having it done back then would have caused a lot less work compared to
> today, but it is still needed.

Before you work on any changes to the options module, I suggest that you
look at the changes we've made in UA. (I don't think Whise copied the
changes back into screenlets, but I could be mistaken.) Lets try to avoid
more duplication of work.

>
>
> - Translation of debug messages makes no sense. Gettext strings need a
> complete review. Only menu-items and messages that are directly
> displayed to the user should be translated.
>

>
> - The screenlets-manager should become its own launchpad project (also
> useful for packaging). It should then contain the tray-icon app (which
> should get splitted from the daemon process as noted below). It also
> obviously needs a lot of improvement. My original version was a really
> quick hack. The code needs to be splitted and reviewed. Maybe even a
> whole new app would be an option.

We've cleaned up the code a lot in UA, and Pefi began working on a
glade-based rewrite and redesign a while ago.
https://code.launchpad.net/~universal-applets-core/universal-applets/new_ui


>
>
> - The screenlets-daemon should not have a tray icon, that's entirely
> against the idea of a background service. The tray icon should be a
> separate application and come bundled with the screenlets-manager.
>
We've gotten rid of the daemon in UA, so we only have an optional tray icon.
(It's still called screenlets-daemon, but we're planning on changing that)

>
>
> That's it for the start :-) ... I don't know how much this collides with
> the things that are already done in (or planned for) universal-applets.
> If there is anything then please let me know.
>
Sounds good overall. :)

Natan