RE: Some changes gna gna

[Philip Van Hoof <spam pvanhoof be>]

On Fri, 2006-05-19 at 10:38 +0300, Dirk-Jan Binnema nokia com wrote:

> done :-) not sure if it would be good to move to tinymail though,
> but we can see some time.

The more things that go into the library, the better. But it does,
indeed, depend. And I don't force people to put their extensions in the
tinymail distribution. I even allow binary-only extensions and I'm
planning to at some point attempt to maintain a ABI.

This is why I'm trying to make the right decisions about the API. Soon
I'm going to reorder (but mostly don't change) the function-pointers of
the many interfaces. In such a way that the ones that are least likely
to change are at the top of the structures.

That way will it be more easy to keep offsets te same. I might also add
some dummy functions as future-slots. I'm interested in how other
library teams (like the gtk+ folks) get this ABI promise done. I know
it's not easy. And nevertheless I wont make it a top priority either.

Flexibility and adaptiveness is far more important. But I try to make
flexibility possible to designing intelligent: for example move things
to strategy design patterns rather than using inheritance or forcing a
developer to hack the core libraries.

To each type is to be as simple as possible.

Imagine the msg view types. They are simple and do what they have to do
following their description: VIEW a message. They don't save a mime
part. This is why I delegated to saving of a mime part to a strategy.

Which I guess answers your question below.

> strategy is a bit different from mozembed; in our case, even
> text messages are rendered through gtkhml(3.8). Reason for that if
> we would have GtkTextView for text-mails and GtkHTML for html-mails,
> a lot of further implementation would be duplicated, or have
> small annoying differences between the two -- I am talking about
> things like copy/paste/select-all/search/fonts/zooming etc. etc.
> 
> Besides, I like clickable URLs, even in text-mails :-) and I like 
> to define my own regexps for that, as they can be system-specific.
> 
> The (hackish) solution is to use a tny_txt_buffer_stream to retrieve
> the text from the message, and then convert it to HTML.

Sure. Feel free to implement the msg view type however you thing it
should be implemented for your platform and/or device. And if I don't
agree, I can implement my own (perhaps derived) version.

The reason why I implemented the mozembed one using a gtktextview and,
in case the mime-part is a html one, a gtkmozembed one is that until you
start using the gtkmozembed widget it doesn't consume a lot resources
and for showing (demo-purpose) what you can achieve.

IMHO is the tnymozembedmsgview not very usable. Mainly because I have to
fake the stream by writing it to a temporary file. I'm probably going to
be more interested in your gtkhtml one, if I'd have to select a default.

> >o. Each tnymsgviewiface now has to set a tnysavestrategy. 
> >There's a tnysavestrategy implemented for Gtk+ which will 
> >support gnome-vfs if --enable-gnome is turned on, and which 
> >will use a normal filesystem file descriptor if not. Both the 
> >tnymsgview and the tnymozembedmsgview use this one in the 
> >libtinymail-gnome-desktop platform implementation.
> 
> What is the goal of the savestrategy (besides using yet
> another design pattern :-)?  For saving to disk I guess... but for
> 'Save as...', or for caching purposes?

'Save as'. Caching is the responsibility of the libtinymail implemen-
tation. I'm not sure whether that should be exposed to the ui developer.

> <snip>
> 
> Cool stuff ;-)

> >Conclusion: the implementer of a platform library has even 
> >greater flexibility at his hands now. He can define how to 
> >save a file. How to view a message (with or without a HTML 
> >component). How to get notified about offline and online state 
> >of the device. And how to store accounts.
> 
> We have our own MsgView and AccountStore; and soon also
> our own Device I guess...

Sounds good.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be