ActiveState Community

You can use an observer and watch for the notification topic "file_project". The subject will be the project itself, and the data will be the directory the kpf file is located in.

_projectOpenObserver = function(subject, topic, data)
{
    //log.debug("_projectOpenObserver: observed '"+topic+"' notification: data='"+data+"'\n");
    switch (topic) {
    case 'file_project':
        var project = subject.QueryInterface(Components.interfaces.koIProject);
        // do something here
        break;
    }
}
var observerSvc = Components.classes["@mozilla.org/observer-service;1"].
                    getService(Components.interfaces.nsIObserverService);
observerSvc.addObserver(projectOpenObserver, "file_project",false);

I should've been able to extrapolate that from one of my previous questions about notifications within Komodo, but I didn't. Thanks, Shane.

Where can I find a list of all the events that are observable?

This document describes:
    - the current set of notifications in Komodo (using the
      nsIObserverService mechanism) and how to use them usefully
    - how to define new notifications when necessary


Komodo's Core Notifications

- Topic: 'komodo-ui-started'
  Sent-From: Komodo startup routine after the UI initialization
  Used-By: None yet.
  Description: Once the UI is fully initialized, this notification is
        sent to inform listeners that the UI is now loaded and that it
        is ready to be used.

- Topic: scheme-changed
  Sent-From: koScintillaSchemeService.py and pref-alllangfonts.js 
  Description: sent when a new scheme is selected in "Fonts and Colors"
      preferences or saved
  
- Topic: 'invocation_terminated'
  Sent-From: Whereever invocations are controlled and invoked (currently
      koInvokeInterpreters.py and koInvokeCommand.py.
  Description: This is sent to indicate that an invoked invocation has
      terminated. For example, the current debugger infrastructure uses
      invocations and uses this notification to know when debugging has
      terminated.  This is a replacement mechanism for the Invocation's
      current termination listener system. The "data" field should
      eventually be the process' exit code, but I am punting on that for
      now: YAGNI.

- Topic: 'open_file'
  Data: [\t]
  Sent-From: The Commandment Service for "open" commandments
  Description: Gives a file that Komodo should open. The data field is
        the filename (an absolute path) to open and optionally specify
        the part of the text that should be selected after the
        file is opened (separated by a tab). (Note: the given
        filename is NOT a URL.)

        The specification for the  data is any
        of the following:

           d        character index (no selection)
           a,b      column,line position (no selection)
           a-b      selection between a (anchor) and b (currentPos)
           a,b-c,d  selection between anchor (column a, line b) and
                    currentPos (column c, line d).
           a,b-c    selection between anchor (column a, line b) and
                    currentPos (characted index c).
           a-b,c    selection between anchor (character index a) and
                    currentPos (column b, line c).
        Columns are 1-based, lines are 1-based, character indices are
        expressed in characters, not bytes.


- Topic: 'feature_status_request'
  Sent-From: Getting Started Page
  Used-By: KoFeatureStatusService's background thread.
  Description: This tells KoFeatureStatusService's background thread to
        gather status information for the given feature (the feature is
        identified by a string in the data field). When the status is
        ready it is sent back via a 'feature_status_ready' notification.

- Topic: 'feature_status_ready'
  Sent-From: KoFeatureStatusService's background thread.
  Used-By: Getting Started Page
  Description: This gives the readiness status for a Komodo feature (it is
        sent after a corresponding 'feature_status_request' notification).
        The data string identifies the feature and the data object is a
        KoFeatureStatus instance (giving the status and possibly a reason
        why the feature is not active).

- Topic: 'mru_changed'  (MRU stands for Most Recently Used.)
  Sent-From: mru.js (Or whatever the current MRU handling code is. It may
        eventually move to a koIMRU PyXPCOM component.)
  Description: Signifies that a specific MRU list has changed in some way
        and any code that presents a UI of this MRU to the user will need
        to update its UI. The 'data' field indicates the name of the MRU
        (which is always also the name of the pref with which the MRU is
        associated).

- Topic: 'subsystem_changed'
  Sent-From: various code locations (generally pref's panels)
  Description: Signifies that some subsystem of Komodo has changed in such a
        way that other parts of Komodo may need to adapt to this change.
        The 'subject' field of the notification is generally None and the
        'data' field identifies the subsystem. Currently used 'data' values
        are:
            'p4', 'cvs'

- Topic: 'view_opened'
  Subject: the view instance
  Sent-From: The  base class
  Description: Signifies that a view has just been opened.

- Topic: 'view_closing'
  Subject: the view instance
  Sent-From: The  base class
  Description: Signifies that a view is about to be closed.  This happend prior
               to any changes on the view (eg. document being set to null)


- Topic: 'view_closed'
  Subject: the view-editor instance
  Sent-From: The  base class
  Description: Signifies that a view has just been closed.  This happens at the
               very last moment, so some things will not be available, such as
               the document.

- Topic: 'current_view_changed'
  Subject: the view instance
  Sent-From: The  base class
  Description: Signifies that a view has just been made current.  If
               the subject is null, it means that there is no current
               view.

- Topic: 'post_activate_view'
  Sent-From: ScintillaView.activate(), should really be called from
            AbstractView base class but is not (for reasons discussed
            in internal documentation).
  Description: Signifies that a new view (really just a scintilla view)
            has just been activated. I.e., the user has just switched
            to a new file tab.

- Topic: 'pre_deactivate_view'
  Sent-From: ScintillaView.deactivate(), should really be called from
            AbstractView base class but is not (for reasons discussed
            in internal documentation).
  Description: Signifies that the current view (really just a
            scintilla view) is about to be deactivated. I.e., the user has
            just switched to a new file tab and the context is just about to
            switch away from the current tab.

- Topic: 'current_view_encoding_changed'
  Sent-From: koIEditorWrapper implementation (currently in koEditorWrapper.py)
  Description: To indicate that the current buffer's encoding has been changed.

- Topic: 'current_view_language_changed'
  Sent-From: AbstractView.viewAs()  (in abstractview.js)
  Description: To indicate that the current buffer's language has just been
            changed.

- Topic: 'current_view_check_status'
  Sent-From: A view's lint buffer (lint.js::LintBuffer).
  Description: To indicate a state change for background checking in the
    current view.

- Topic: 'status_bar_reset'
  Sent-From:
  Description: Used to reset the status bar labels

- Topic: 'status_message'
  Sent-From: various places
  Description: Used to display a status message on the status bar.

- Topic: 'set_logger_level'
  Sent-From: koLoggingService.py
  Received-by: logging.js
  Topic syntax: ":" where name is the name of the logger, and level is the number
     corresponding to the 'sensitivity' of the logger.
  Description:
     This notification is sent by the python module koLogging.py to let the logger manager
     in koLogging.js know that a logging level has changed.

- Topic: 'add_logger'
  Sent-From: koLoggingService.py
  Received-by: logging_control.js
  Topic : loggername
  Description:
     This notification is sent by the python module koLoggingService.py
     to let the logging UI manager know that a logger was created.

- Topic: 'emit_log'
  Sent-From: koLoggingService.py
  Received-by: logging_control.js
  Subject: koILogRecord instance
  Description:
     This notification is sent by the python module koLoggingService.py
     to let the logging UI manager know that a log record should be added
     to the display.

- Topic: 'quit'
  Sent-From: the Commandments system, for the sake of automated testing
  Received by: komodo.js
  Description: quits Komodo, as if the user had done Alt-F, X.  (XXX need a 'force-quit')

- Topic: 'note'
  Sent-From: the Commandments system, for the sake of automated testing
  Received by: komodo.js
  Description: writes the arguments to the 'status' logger, so that the driver scripts can 'annotate'
     the logfile, to know when what was written.

- Topic: kb-load
  Sent-From: The loading of parts by the koProject.py code
  Received by: the keybinding manager
  Description: when a part with a keybinding is loaded, this notification is sent passing the part as the object.
               The keybinding mgr does its magic by inspecting the part.

- Topic: kb-unload
  Sent-From: The removal of parts by the koProject.py code
  Received by: the keybinding manager
  Description: when a part with a keybinding is removed, this notification is
               sent passing the part as the object. The keybinding mgr does its
               magic by inspecting the part.

- Topic: file_changed
  Sent-From: koDocument and project/toolbox services when a document or
             project/toolbox is saved. It is also sent from view_checkDiskFiles
             when a file has changed on disk, and koProject when a file is imported
             to the project.
  Received by: file status service
  Description: The data should be a uri. When the status service recieves
               this notification, it schedules the file status to be updated
               in the background

- Topic: file_status_now
  Sent-From: anywhere we need to force a synchronous status update on a file
  Received by: file status service
  Description: The data should be a uri.  When the status service recieves
               this notification, it immediately updates the file status.  This
               will block UI since it happens on the main thread.  Alternately,
               getStatus can be called if you have a koIFileEx instance.

- Topic: file_status
  Sent-From: file status service after status retrieval is done
  Received by: whoever needs to know when status is updated
  Description: The data is a list of url's that are newline seperated.

- Topic: file_update_now
  Sent-From: anywhere we need to tell the status service to run 'now'
  Received by: file status service
  Description: This releases the background thread so it will run
               status checking.  It does not force updates on any particular
               files, so if they are not due for an update, they don't
               get updated.

- Topic: file_added
  Sent-From: file service
  Received by: whoever needs to watch for new files added to the cache,
               such as the file status service
  Description: This is not a global observer, you must use the observer
               service that is part of the file service.  Whenever the
               file service creates a new koIFileEx intance, it notifies
               it's own observers on this topic.

- Topics: codeintel_activated, codeintel_deactivated
  Sent-From: codeintel.js (JavaScript side of control for Code Intel system)
  Description:
    Notify observers that the Code Intelligence system has been activated or
    de-activated (either when initializing or when the associated pref
    changes).

This is not all of the notifications available, but covers the majority of them.

Cheers,
Todd