It is a bit thin on scope and implementation details.<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
E.g. does this include folder specific settings UI, composer, attachment<br>
handling, address book integration/recipient editor, filter/search UI, etc.<br>
<br>
Maybe list a couple of example workflows that should be possible with the<br>
improved UI.<br></blockquote><br>I updated my proposal with a concrete mockup and ugly but hopefully descriptive kolourpaint drawings.<br>It is more like a rewrite than a little update so please give it a second look.<br>
<br>This design proposal constrains me a little as I was hoping to be able to experiment with the ideas of a task driven approach that float around the Plasma Active project these days. But I can see how "I will do mockups and play around with UI ideas. This will be great. Trust me" is not a good project proposal.   <br>
<br>@Thomas <br>I am really interested in your feedback on my "initial mockup" it is basically a brain dump of what I was imagining so far. Is this something we can work with? I have still some time to change it.<br>
<br>@Sebas<br>I didn't know OBS was that powerful. thanks for sharing. I will have to learn about OBS try to set it up.<br><br><br>"Would it then not be better to have someone from PA be the primary mentor for this?" <br>
<br>Thomas Pfeiffer is form PA but not a developer, so he can't be a Mentor I guess. The code I am intending to write will sure look a lot like what we have in plasma-mobile and declarative-plasmoids. I hang around in #active for some time now and feel comfortable working with the PA guys so I wouldn't mind getting mentored by one of them. But having someone with KDE PIM knowledge who makes you aware of possible performance problems and can help with questions regarding Akonadi is also really useful. <br>
<br>Any opinion from the PA developers on this? <br><br><br>Cheers<br><br>Mike <br><br><br>