Build, Release, QA ------------------ *Weekly checkpoint* With alpha3 out of the way, Bear spun and Dan tested the alpha4 weekly checkpoint. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006539.html http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006540.html
*Slackware* Dave Curtis showed up as a potential new user, trying out Slackware 10.2. Dave and Bear worked through various obstacles and eventually got him up and running. Bear noted a bug where setuptools was looking at Cheeseshop for an egg instead of our locally built egg (the required version was missing). Thread starts here: http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006541.html *i18n* Bear gave everyone a heads up that some i18n related build changes were about to land. Changes include egg-based bundled parcels installed in developer mode, removal of "chandler/resources", creation of "icons" directory, unit test updates, etc. (By the end of the week everything had landed and all was well). http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006557.html After the changes landed, Brian K gave us an update that Chandler is now localizable. Translations are loaded and maintained as eggs. Chandler's image and HTML resources are loaded from the default localization egg for Chandler. Brian has an example French localization (which still needs polish as Brian does not speak French -- Philippe will take this for Alpha5). http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006569.html *Change to distribution* Bear realized that develop-mode needs to be un-installed before shipping the distribution. Bear's small change will fix a problem with the distributions created by the tinderboxes. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006580.html *Fedora Chandler Ugly* Viksit Gaur gave a screen shot of Chandler on Fedora Core 5, which was not pretty to look at. Fonts, sizes, layouts, etc. are a bit of a mess. Viksit asked if this was a problem on Linux generally. He asked for ideas or workarounds. John explained that we have a bug in bugzilla for the sidebar problems (Bug 5243). He hopes to have a fix in a few weeks. Resizing the window should clear up the sidebar display. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006591.html Intern and SoC projects ----------------------- *Contacts* Ernesto was looking to display the 'rawVCard' attribute in a multiline text area, he was getting a single line text field. He gave a code snippet and asked for advice. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006546.html Bryan Stearns explained that by default, attribute editors are picked by looking at the attribute's type and the presentationStyle.format attribute. If 'rawVCard' is schema.Text, it should pick the multiline text area, given that Ernesto set the presentationStyle to 'MultiLine'. If Ernesto wrote a custom attribute editor, he'd have to register it and make sure to pass the style information to the control being created. Bryan also noted that specifying the height= might not work currently for multiline text areas. Ernesto replied that he did indeed write a custom editor (he gave some code snippets). He sees the problem based on the location of the makeEditor block. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006562.html Bryan explained that it is likely a sizer issue based on an extra block layer. In theory Ernesto's code should work. Ernesto fixed the problem with a stretch factor. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006565.html *Quick item entry* Darshana let everyone know that she's working on adding a quick item entry feature to the search bar. An example use case: "/event OSAF staff meeting at 10:45am" will create an event in the calendar. She gave wiki links to specs. She's looking for suggestions on how to put NLP to use with this feature. http://wiki.osafoundation.org/bin/view/Journal/QuickItemEntry http://wiki.osafoundation.org/bin/view/Projects/JottingNewItemsWorkflow http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006568.html Viksit asked how Darshana would distinguish/parse different units of information: with commas? with newlines? keywords? assumptions that a 2 digit state code belongs to an address? http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006576.html Core projects ------------- *Dashboard date, last modified* Bryan offered two proposals to address redirectTo and other dashboard related domain model issues. The 'Date' column uses the concept of 'next important date' when sorting. Next important date takes into account ticker dates, event start time, date last modified, date sent, and date created. Bryan called out 'last modified' -- the last time a user-meaningful change was made. Dragging an event in the calendar counts, selecting the item in a different block doesn't (even though it changes the selectedIn attribute). The first problem is indexing the date column, the second problem is keeping track of last modified. In earlier discussions, onValueChanged was rejected as a solution to the date index problem (too heavy a hammer). Using a Calculated attribute was also rejected -- making this work with monitors wasn't likely to work well. Bryan observed that we want to store the value calculated for 'nextImportantDate' -- we need it for both indexes and for display. Bryan proposed declaratively specifying what he wants in the schema (similar to Grant's proposal earlier). He'd specify the type, the attributes it was based on, and a method to call if one of the attributes changed. The 'nextImportantDate' attribute could be indexed directly, instead of having to compare indexes (by comparing items, which would require loading them). Bryan rejected onValueChanged for the last modified problem as well, for similar reasons. Bryan proposed an attribute aspect "substantive". By default this would be "True", but could be set to "False" for attributes like 'selectedIn'. For attributes that are considered "substantive", an onSubstantiveChange method would be called (where "last modified" and "last modified by" could be set). Bryan noted that recurrence and Travis' IMAP work could also use this notion of what it meant to be a "substantive" change. He suggested that if the solution solves the problems above as well as the recurrence and IMAP use cases, we could likely get rid of onValueChanged altogether. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006553.html Andi summarized the mechanisms that react to attribute changes. He proposed getting rid of onValueChanged (too big a hammer) and replacing it with an attribute aspect naming a method to invoke when an attribute changes. Bryan replied that Andi's proposal was perhaps the reverse of Bryan's proposal: hang the method off any attribute that requires it vs hanging the attribute off of the method that updates it. Bryan gave an example of what Andi's proposal might look like, noting that it might work but seems odd to record the dependencies far from the definition of the attribute. Bryan also noted that last modified would require putting onChange=updateLastModified for every user-editable update. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006558.html Grant summarized an IRC discussion that resulted in a proposal supported by Phillip, Andi, Bryan and Grant. To solve "calculated attributes" (e.g. nextImportantDate): Andi will add an onChanged attribute aspect that lists methods to be called when the attribute changes. Phillip will add support in the schema API for a syntax similar to the one Grant and Bryan requested. Longer term, we'll support the ability of the attribute aspect to point to a method defined in an annotation class (an Importable). To solve lastModified: Andi will add support for a commit-time hook to the repository, and Phillip will figure out a tasteful syntax for allowing "substantive" changes to take advantage of the hook (assume that ContentItem changes are substantive by default). http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006596.html *Stamps and Annotations* Grant had questions about two cases where annotation classes have attributes that aren't repository values. (1) The Calculated class (the analog of a python property) doesn't completely work inside Annotations. Attribute editors, indexes, etc. require an item and an attribute name. The property doesn't appear on the target class. Add the wrapped property on the fly? (2) Indexes that make use of attributes are OK, as one can use the fully qualified annotation name. Indexes using a comparison require invoking a method -- in this case on the annotation class. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006574.html Phillip observed that we need help from the repository to make these cases work well. For (1), the repository could place a descriptor for the Annotation's Calculated attribute on the class, which could invoke Calculated's computation. A similar solution could work for the index case. Alternatively the Annotation could add the descriptor, but we'd have problems guaranteeing that the annotation class is imported in time. By storing information (on an attribute aspect) such that we can import the class/method when we need it, we address that problem. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006582.html Grant noted that the proposal resulting from the dashboard/lastmodified discussion (see above) should address the Calculated case (1). The compare index case (2) will eventually require an "Importable", not just a method name. (This addresses import-ordering issues, forcing the required class/method to be imported). In the short term Grant implemented Phillip's suggestion where the Annotation class adds a Comparator decorator to the target class when creating Annotation classes. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006597.html *Save/restore settings* Morgen added "save/restore" settings to the Test menu, to help reconfigure Chandler after starting with a fresh repository. "Save Settings" records sharing accounts as well as currently shared collections to an .ini file. "Restore Settings" loads the saved settings file, recreating appropriate accounts and collections. We have future ideas to extend it for email and create hooks for 3rd party parcels. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006566.html *Feedback* Heikki checked in a feature not unlike Mozilla's "talkback". When an exception is written to stdout or stderr a feedback window pops up. Various info is collected from the system, as well as optional user feedback, and the user can submit the data to OSAF. Starting with --stderr will disable the feature. Suggestions welcome for iterations on the first cut. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006567.html *Import dependencies* Grant described a problem where unit tests failed because some parcels can't be loaded on their own. Bryan moved the detail parcel to resolve the problem. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006589.html *Collections* John is thinking of implementing the sidebar with two separate blocks for "out of the box" and "user" collections. He will have a collection that contains all "out of the box" items, and a collection that contains all "user" items. He asked if it was possible to combine these collections in a way that preserved the order of the numeric indexes (__adhoc__). He also wants to maintain the selections from both collections in the new collection. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006581.html Andi explained that if the __adhoc__ indexes are in a different order than the ref collections, John would have to create the Union's index and reorder it using Indexed.placeInIndex(). If the order changes in the user or out of the box collections, there is currently no automatic way to reflect this in the new index. Similarly, Andi has doubts about maintaining the selections in the new collection as well. Numeric index order changes are not propagated. (The addition or removal of keys from indexes is propagated). Andi is concerned about implementing more index dependencies, given problems we've had with sub-indexes. http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006584.html *Thunderbird extension* Davor gave some examples of Thunderbird extensions and a patch in Mozilla's bugzilla that add mail headers. (Travis had mentioned this kind of work being necessary to implement Chris's idea of a Thunderbird extension that implemented Chandler-related stamping features). http://lists.osafoundation.org/pipermail/chandler-dev/2006-August/006592.html Meetings -------- No apps meeting, status: http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20060810 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
