I guess you mean the thing down the bottom of the screen? Yeah, eventually, its probably harder than you'd think it should be though.to become any kind of dumping ground... And yes, Gtk definitely does do progress bars, but having a separate progress bar isn't as nice (doesn't feel as "integrated", etc.) as having an evo progress bar.
Wow. Well thats calendar land stuff anyway, SEP.> If its like anything else in the calendar, it'll just load it into memory, and make it > slow while its at it! :) Hmm... :) Apparently (this is mostly what we hear from our business office in Toronto, so it may be exaggerated) a lot of our customers really like having nice big attachments on calendar items, and they actually use Outlook as a way to share files this way (however stupid
Yeah, "providers" will be come full-blown objects, loaded via the plugin system.> > camel plugins How do these relate/compare to the EPlugin stuff? > They're not really as important since camel already has extensibility for the core > function of storing email. > They're also different since they're not based on gobjects, need to be thread > safe, etc. Right, so camel "plugins" will just be what camel providers are now?
But so potentially will SASL authentication mechanisms, filtering/search expressions, content parsers (e.g. think ms-tnef promoted transparently to a mime multipart structure), and so forth. It would be nice, for example, to have a combination of camel plugins and evolution plugins that integrated together so you could create a custom vfolder implementation entirely separate to the main codebase. Something like this might also be needed for server-side filtering rules (infact, as with filters and vfolders in general they are in many respects the same problem). But that is looking far down the track.
--
|
<<attachment: zed-48.small.jpg>>
