Hello, On Sun, Mar 15, 2009 at 5:56 PM, Rico Pfaus <[email protected]> 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
_______________________________________________ Mailing list: https://launchpad.net/~screenlets-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~screenlets-dev More help : https://help.launchpad.net/ListHelp
