From Sukimashita

This page serves as a collective ground for various information used for planning during the development of the project and is probably totally inaccurate/outdated or quickly changing.

Contents 1 Next steps 2 Dependencies 3 Components 4 Plugin System 5 Terminology 6 Ideas/Thoughts

[edit] Next steps

In no particular order:

• Move to D Programming Language
• Autotoolize GTK+ D Hello World Application
• Generate config.d file with configure settings
• Create shared library of libgphobos for linking (let's use tango)
• Create shared libraries of GTK+ D bindings (libgtkd.so for now)
• ./configure && make && make install - Hello World GTK+ in D!

• Create basic RPMs for D Application Development:
  • gdc (/usr/bin/[gdc|gdmd])
  • d-phobos (.so,.a) (standard)
  • d-tango (.so,.a) (tango)
  • gdb-d (incl. D patches)

• Create RPMs for D GNOME Development
  • libgtkd

[edit] Dependencies

• GTK+ >= 2.10
• GLib >= 2.4
• libglade2
• intltool >= 0.35
• gconf
• DBUS

[edit] Components

• gnome-observer-daemon

A background daemon which efficiently checks added sources for changes and initiates notifications.

- Read gconf settings
- Load plugins and add their features
- Poll source status of all added sources
- Call associated notification handlers if source status switches to "CHANGED"
- Exit after all "jobs" are done but register a timeout (with DBus?) when to spawn next in order to save memory

• gnome-observer-daemon-settings

A settings dialog to manage sources, plugins and global settings stored in gconf.

- Tabs: General, Sources, Plugins

• gnome-observer-daemon-applet

An applet which indicates the current status of a specific source. Multiple applets can be added to visualize the status of certain sources.

- Preferences: Select source to indicate status for

[edit] Plugin System

The plugin system in GOD allows plugins to extend GOD's standard functionality. A plugin is able to offer multiple new source types or notification handlers at once.

To achive this we require these core components:

• Main Application Loop
• Plugin Manager
• Source Manager
• Notification Manager

A proposed API pseudocode:

// exported by GOD
struct GodSourceType {
  gchar *name;
  gicon *icon;
  
  GodSourceSettings *settings; // return type specific settings list, might also give glade xml data for add/remove/edit dialog for specific source?

  gcallback *on_check_status;  // callback which checks for source status based on type-specifc callback (check website for changes, login using ssh and check server,...)
}

struct GodNotificationHandler {
  gchar *name;
  gicon *icon;

  GodNotificationHandlerSettings *settings;

  gcallback *on_notify; // spawn the notification handler's notification
  gcallback *
}

god_plugin_[add|remove]()
god_source_manager_type_[add|remove](*GodSourceType)
god_notification_handler_[add|remove](*GodNotificationHandler)

// exported by Plugins
plugin_on_get_information()
plugin_on_update()
plugin_on_load()
plugin_on_unload()

[edit] Terminology

Source

A target which is observed (e.g. Website, Directory, Server). Usually implemented and provided by a plugin.

[edit] Ideas/Thoughts

• GNotify

How about making all this rather be a "notification traffic configuration" remotely similar to KNotify on KDE? If we extend the "source" idea to "events", for instance a HAL dbus event for a new USB device could spawn a notification. Just that our tool allows for fine grained configuration of event sources and what notification should be triggered. Thus you should be able to send an SMS when someone plugs in a firewire camera. We could offer a default set of "system sources" and allow for configuration (notify me or not, only if critical etc.) and addition of others using plugins (such as checking websites for changes).

• libnotify

How does this interact with the "desktop notification" specifications? Is there duplicated code? There are plans for a libnotify capplet for the control-center to probably allow to filter specific notifications based on category/urgency etc.