Alec Flett | 1 Apr 04:00 2005

new columnheader in calendar

starting tomorrow, you should see our first use of David's cool ColumnHeader widget in the calendar

There is an obvious bug that on Windows and GTK it doesn't show a visible selection (i.e. like the current week/day in calendar) This is a slight feature regression from 0.5 but David says he's thinking/working on a solution.

I wanted to land this now to make sure we get some good exposure on this widget, but no need to file a bug about that particular problem.

Alec


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
Katie Capps Parlante | 1 Apr 06:38 2005

Re: PyCon Report

Hi Nick,

Yes, a validator would help. The design of parcel xml makes that 
slightly tricky, as the definition of new Kinds would need to define the 
xml schemas. Each parcel that defines new Kinds defines a new namespace.

We could of course define an xml schema for the core items (Kind, 
Attribute, etc.). We could also define xml schemas for common Kinds in 
the framework (Blocks, WakeupCallers).

And yes, we've gotten feedback that this might be something of an abuse 
of xml.

Alternatively, we could define a different xml schema for CPIA that was 
better suited to ui layout.

Keep in mind that parcel xml is just a mechanism to load items into the 
repository -- the parcel loader parses the xml and makes standard api 
calls to the repository. We could come up with alternative ways of 
loading items into the repository -- Phillip Eby and others have been 
thinking about such alternatives.

Cheers,
Katie

Nicholas Bastin wrote:
> 
> On Mar 31, 2005, at 1:14 AM, Katie Capps Parlante wrote:
> 
>> one more pycon report:
>> (http://wiki.osafoundation.org/bin/view/Journal/ 
>> KatiePyConReport20050330)
>>
>> Sprints
>> -------
>> I found the sprints to be very rewarding, a good use of two days. We  
>> split up into two groups, where we had one or two volunteers and one  
>> or two osaf helpers in each group. One pair worked on a delicious  
>> parcel and one pair worked on a flickr parcel.
>>
>> Lessons learned about writing chandler parcels
>> ----------------------------------------------
>>
>> (+) Debugging xml is a real pain. Watching people try and find a typo  
>> in a namespace really makes one wince.
> 
> 
> I don't really know anything about the internals of Chandler, but don't  
> you have a schema?  If you have schemas for each kind of XML document  
> that you need to produce, debugging is pretty easy - the validator will  
> tell you what is wrong with your document.
> 
> -- 
> Nick
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Anthony Baxter | 1 Apr 09:34 2005
Picon

Re: PyCon Report

On Thursday 31 March 2005 16:14, Katie Capps Parlante wrote:
> (+) Debugging xml is a real pain. Watching people try and find a typo in
> a namespace really makes one wince.

FWIW, Zope3's zcml has exactly the same problems, and is the #1 reason
why I no longer spend time working on Z3. xml is for data, not code.

--

-- 
Anthony Baxter     <anthony@...>
It's never too late to have a happy childhood.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Phillip J. Eby | 1 Apr 20:02 2005

Re: PyCon Report

At 08:38 PM 3/31/05 -0800, Katie Capps Parlante wrote:
>Hi Nick,
>
>Yes, a validator would help. The design of parcel xml makes that slightly 
>tricky, as the definition of new Kinds would need to define the xml 
>schemas. Each parcel that defines new Kinds defines a new namespace.
>
>We could of course define an xml schema for the core items (Kind, 
>Attribute, etc.). We could also define xml schemas for common Kinds in the 
>framework (Blocks, WakeupCallers).

If you really wanted to go this route, I'd suggest making use of the XML 
Metadata Interchange (XMI) format, version 2.0.  It includes 
transformations from XMI to XML Schema and vice versa (along with UML 
mappings), and the Eclipse Modelling Framework (EMF) supports automatically 
generating custom GUI editors for content defined via such schemas.

In other words, if I understand all this correctly, you can design an 
application model in a UML editor, throw the XMI of it into EMF, and then 
generate an XML schema for the application data, and a GUI to edit files 
according to that schema.  So, at that point you're fully TLA compliant.  ;)

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Nicholas Bastin | 1 Apr 20:04 2005
Picon

Re: PyCon Report


On Mar 31, 2005, at 11:38 PM, Katie Capps Parlante wrote:

> Hi Nick,
>
> Yes, a validator would help. The design of parcel xml makes that 
> slightly tricky, as the definition of new Kinds would need to define 
> the xml schemas. Each parcel that defines new Kinds defines a new 
> namespace.

This isn't that big of a problem if you're willing to add one more step 
on startup.  If each parcel defined a schema fragment for its' types, 
then you can use XSLT on startup to assemble all of the fragments into 
a complete schema for that users' repository.

--
Nick

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Phillip J. Eby | 1 Apr 22:15 2005

FYI: ICU and Python

Per discussions the other day about Brian's internationalization proposal 
(http://wiki.osafoundation.org/bin/view/Chandler/ChandlerInternationalizationProposal), 
I did a little investigation into ICU implementations for Python.

Zope 3 includes separately-distributable 'zope.i18n' and 'zope.i8n.locales' 
packages.  (They rely on a couple of other zope packages, one of which is 
already distributed with Chandler, so the footprint isn't too large.)

These packages provide support for ICU locales, using the locale XML files 
from the ICU project.  This support includes locale-specific date, number, 
and currency formatting and parsing, as well as calendar, time zone, and 
language information, all using standard Python types, including the 
datetime types.  It does not, however, include collation support, or any 
other ICU features.

zope.i18n also includes support for using gettext files, and for defining 
on-the-fly translatable message IDs.  It's not clear whether Chandler would 
need this if Brian's proposal is used, because much of the idea is to move 
translation to a different run phase.  However, under Brian's proposal a 
change in locale would force the system to search and re-translate all 
localized strings in the repository, or alternatively to re-load all 
parcels.  If that approach is taken then on-the-fly translations aren't 
needed, and we might as well use Python's built-in gettext support, perhaps 
with some enhancements for locale/language fallback.

The interfaces for zope.i18n and zope.i18n.locales can be found at:

     http://svn.zope.org/Zope3/trunk/src/zope/i18n/interfaces/__init__.py?view=auto
     http://svn.zope.org/Zope3/trunk/src/zope/i18n/interfaces/locales.py?view=auto

While the ICU implementation here is far from complete, it has been around 
a while and used for some projects, so it has presumably already 
incorporated any important "lessons learned" for working with ICU locales 
in Python.  And of course there are lots of tests.  We would probably do 
well to actually try using some of it before embarking on any significant 
efforts to create a direct binding to the ICU libraries for Python, if for 
no other reason than that it's much easier to debug Python than C or C++, 
and it's much harder to make pure Python code crash your process.  :)

The other Python ICU project I looked at was "picu", which can be found at:

     http://cvs.sourceforge.net/viewcvs.py/python-codecs/picu/

It is an actual binding to the C ICU library, primarily for supporting 
collation.  It hasn't been touched in years, however, so it's not clear 
that it would work with a current version of ICU.  However, it could 
perhaps be a reasonable place to start when we need to implement collation 
support, and it's certainly a decent example of how to wrap ICU routines in 
C for Python, in the event we need additional services.

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Mike Taylor | 2 Apr 01:39 2005

wxPython unicode

Monday morning I'll be coordinating with David S. to turn on Unicode 
support in wxPython for all three platforms.

I'll post a message here when the binaries are available so everyone 
can update their chandler/Makefile from CVS to pick up the latest 
version.

thanks,

---
Bear
http://code-bear.com

Open Source Applications Foundation (OSAF)
http://www.osafoundation.org

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
Mike Taylor | 4 Apr 17:06 2005

Tinderbox is CLOSED, starting 0.5.01 milestone release

I'll post a message when the tree is re-opened

---
Bear
http://code-bear.com

Open Source Applications Foundation (OSAF)
http://www.osafoundation.org

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
Mike Taylor | 4 Apr 18:10 2005

0.5.01 Milestone released - Tree is OPEN


---
Bear
http://code-bear.com

Open Source Applications Foundation (OSAF)
http://www.osafoundation.org

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822 40B3 CD29

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
Heikki Toivonen | 4 Apr 20:49 2005

Re: IMAP and SMTP accounts defined in external parcel

RL 'Bob' Morgan wrote:
> With STARTTLS, a site like ours that wants to protect people's passwords
> can set our IMAP servers to advertise TLS and require that it be
> negotiated by a client in order to log in (or they can use
> SASL/GSS/Kerberos, but that's another story).  A client that has been
> thoughtfully designed will be set to use TLS if it is offered by the
> server.  This way the client will work just fine, securely, with our
> site *without the user having to configure it*.  And it will still work
> fine with plain old sites that just use cleartext.  So everybody wins.
> But note this means that the client has to ship with "use TLS if
> offered" as a default.  It is sometimes argued that client providers

IMO "Use TLS if available" option sucks. When a user has that set, they
won't know if the traffic is encrypted or not. From usability point it
is great, of course. But from security point of view it would be better
to try and force SSL/TLS and only if that did not work ask the user if
it would be ok to try unencrypted.

--
   Heikki Toivonen

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Gmane