<p><br>
On Aug 10, 2012 7:18 PM, "Jameson Graef Rollins" <<a href="mailto:jrollins@finestructure.net">jrollins@finestructure.net</a>> wrote:<br>
><br>
> On Fri, Aug 10 2012, Jani Nikula <<a href="mailto:jani@nikula.org">jani@nikula.org</a>> wrote:<br>
> > How would this work together with something like [1] (rationale in [2])?<br>
> ><br>
> > [1] id:"<a href="mailto:ab777cf0fa83778d3399ac52094df9230738819d.1328798471.git.jani@nikula.org">ab777cf0fa83778d3399ac52094df9230738819d.1328798471.git.jani@nikula.org</a>"<br>
> > [2] id:"<a href="mailto:cover.1328719309.git.jani@nikula.org">cover.1328719309.git.jani@nikula.org</a>"<br>
> ><br>
> > If you introduce a mechanism to store the state, could it be extended to<br>
> > store the state of each individual part? That, in turn, could be used to<br>
> > add support for expanding/collapsing each alternative part through the<br>
> > buttons (e.g. [ text/html (not shown) ]). Each button could toggle the<br>
> > state of the part, and refresh buffer.<br>
><br>
> Hey, Jani.  Are these patches needed if we have Mark's patch?  I would<br>
> prefer to see Mark's solution.  Since alternative parts are supposed to<br>
> be just that, alternative, it seems to me that a solution that would<br>
> cycle through display of these parts is really what we want.  Is there a<br>
> strong need to show multiple alternative parts at the exact same time?</p>
<p>Thanks to broken Microsoft mail clients, I get plenty of invitations that have text/plain and text/calendar alternative parts with information complimenting each other. I usually need to see both (luckily the included html part I can ignore) and it's helpful if I can see them at the same time. In a perfect world neither you or me would need any of this functionality...</p>

<p>I suppose cycling through the alternative parts is, in a sense, correct for the reasons you state, we have the code here to do just that, and I can always cook up something for myself. Let's go with this, then, to move forward.</p>

<p>BR,<br>
Jani.</p>