On Mon, 2003-11-17 at 13:19, Ettore Perazzoli wrote:
On Fri, 2003-11-14 at 14:54, JP Rosevear wrote:
hmm, but then, what about changes in the source? How would the backend
know?
It doesn't know right now either. I think we can work this out along
the way if necessary.
I think if
On Fri, 2003-11-14 at 01:43, JP Rosevear wrote:
On Tue, 2003-11-11 at 04:40, James Ogley wrote:
Many many centuries ago, there was a lot of discussion, and work towards
fixing bug #232 - reading TNEF attachments. The solution that was
arrived at was using gtnef (kudos Larry)
However,
On Mon, 2003-11-17 at 13:30, JP Rosevear wrote:
I prefer the serialized source solution, because it is possible to open
ad hoc calendars for temporary purposes. Could the gconf key just be a
named property on the source?
I guess it could, but then you have a consistency problem... I.e. you
On Mon, 2003-11-17 at 13:49, Ettore Perazzoli wrote:
On Mon, 2003-11-17 at 13:30, JP Rosevear wrote:
I prefer the serialized source solution, because it is possible to open
ad hoc calendars for temporary purposes. Could the gconf key just be a
named property on the source?
I guess it
On Mon, 2003-11-17 at 13:44, Larry Ewing wrote:
On Fri, 2003-11-14 at 01:43, JP Rosevear wrote:
On Tue, 2003-11-11 at 04:40, James Ogley wrote:
Many many centuries ago, there was a lot of discussion, and work towards
fixing bug #232 - reading TNEF attachments. The solution that was
On Mon, 2003-11-17 at 11:02, Ettore Perazzoli wrote:
On Mon, 2003-11-17 at 14:00, JP Rosevear wrote:
On Mon, 2003-11-17 at 13:49, Ettore Perazzoli wrote:
On Mon, 2003-11-17 at 13:30, JP Rosevear wrote:
I prefer the serialized source solution, because it is possible to open
ad hoc
On Mon, 2003-11-17 at 14:27, Larry Ewing wrote:
On Mon, 2003-11-17 at 13:03, JP Rosevear wrote:
On Mon, 2003-11-17 at 13:44, Larry Ewing wrote:
On Fri, 2003-11-14 at 01:43, JP Rosevear wrote:
On Tue, 2003-11-11 at 04:40, James Ogley wrote:
Many many centuries ago, there was a lot
On Mon, 2003-11-17 at 14:52, Dan Winship wrote:
I don't think the connector links to the mailer at all, although it does
link to camel. Dan?
Connector is irrelevant here. We don't want non-Ximian GPL code in
evolution because it keeps us from being able to do things like, oh,
say, link
Hello,
right now components upgrade from an existing Evolution version when
they are first activated. However, that's bad since they get all
activated at the same time and it's not clear to the shell when that
happens (so e.g. if there are progress dialogs they'll interfere and
stuff).
So I
On Tue, 2003-11-18 at 09:02, Ettore Perazzoli wrote:
Hello,
right now components upgrade from an existing Evolution version when
they are first activated. However, that's bad since they get all
activated at the same time and it's not clear to the shell when that
happens (so e.g. if there
On Mon, 2003-11-17 at 20:57, Not Zed wrote:
On Tue, 2003-11-18 at 09:02, Ettore Perazzoli wrote:
The mechanism is similar to that of the old e-config-upgrade, i.e. it
stores the version number in a GConf key and attempts an upgrade if the
current version number is higher than the old one.
11 matches
Mail list logo
