[Evolution-hackers] Colon is a show-stopper.
Here is a typical message file: ~/.local/share/evolution/mail/local/cur/1365462216.8388_1.Iris:2,S Can I persuade Evolution to use some other character in lieu of the colon? This is very important to me... it's a show-stopper. Thanks - Mark Filipak. -- VMware Player 5.0.2 Host: WinXP3, 32-bit Guest: Linux Mint 14, 64-bit + Xfce 4.10 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Accessing evolution-data-server with python
I'm working on a calendar based project, written in python, which needs to access evolution-data-server. So far, I have been using the python-evolution module to access it. However, it is proving to be a little slow and only has a few capabilities implemented. To speed things up and access more features, I'm hoping to be able to use gobject introspection instead. I've come across some sample code for retrieving contacts from eds at http://cgit.collabora.com/git/user/rgs/eds-introspection/commit/ and I've tried a similar approach to retrieve calendar events, but it hasn't worked. I've replaced EBook.BookClient with ECalendar.CalClient and used get_object_list() rather than get_contacts(), but there doesn't appear to be a get_object_list_finish() method available in ECalendar.CalClient, while get_contacts_finish() does exist in EBook.BookClient. So, how do I access and edit calendar events using python and gobject introspection? The system I am using is as follows: Ubuntu 11.10 64-bit evolution-data-server 3.3.2-0unbuntu1~oneiric libedata-cal-1.2-13 3.2.2-0ubuntu1~oneiric gir1.2-ecalendar-1.2 3.2.2-0ubuntu1~oneiric ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] unsubscribe
___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Unsubscribe
___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] modify the widget height
Dear All: Our project is planning to transplant the evolution to the low-cost PC, on which the screen resolution is 800*400. When the evolution starts, the widget of the main window and the assistant widget is out of the screen range, so I can't see the bottom of the widget and can't use the "OK", "forward","backward" button . I try to modify the source , but the source code is too big, I can't locate which c file can help me change the widget height. Can anyone give me a hand? Thanks. MARK ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution-data-server/calendar/libical and SVN
Hey there, As per: http://live.gnome.org/SubversionMigration evolution-data-server will not currently build from SVN because libical isn't automatically checked out. One option would be to do: $> cd evolution-data-server/calendar $> svn propset svn:externals http://svn.gnome.org/svn/libical/trunk I see a couple of problems with that though: - The libical module will be checked out using anonymous SVN, meaning evo hackers wouldn't be able to directly hack on that checkout - When you branch, the branched evolution-data-server will still refer to libical trunk. You'd need to modify the svn:externals property to refer to the libical branch Cheers, Mark. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution-win32-devel] My ORBit2 Win32 problem today
Tor, Great to hear; you really do amazing work. For those who might care, I'll upload an updated installer tomorrow. Unlike the old installer, it'll be MSI and have support for various languages. The default GTK theme will also be set automatically for the user, as Tor suggested. Please let me know if you have any suggestions or if I can help with anything. Thanks, Mark On 6/20/06, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > I spent much time today debugging a problem related to > evolution-exchange. When quitting Evolution, and then after a while > starting it again, it hang. bonobo-activation-server was waiting for a > reply from evolution-exchange-storage.exe (which had been staying around > even after Evolution quit). > > That process isn't actually supposed to stay around after Evolution > quits .(Unlike gconfd-2, evolution-data-server and > evolution-alarm-notify.) So, why didn't it go away? It actually was hung > in a quite spectacular fashion, so no wonder it couldn't be contacted. > (Its sockets were still in LISTEN and ESTABLISHED state, so > bonobo-activation-server didn't notice the process was in fact dead as a > dodo.) > > Well, the root cause why it didn't go away was the atexit() call in > ORBit2's CORBA_ORB_init(). (Well, g_atexit(), but that is just a #define > for atexit() in Win32.) > > The exact semantics for atexit() are hard to define on modern systems > with shared and dynamically loaded libraries. What if one DSO registers > an atexit() function that calls a function in another DSO? Apparently > especially on Windows the environment in which the functions registered > with atexit() eventually run can be rather random. My personal opinion > is that atexit() should be banned... > > On Windows, atexit()-registered functions run when the registering DLL > is being unloaded. As far as I know, there is no way to be sure what > other DLLs are still present at the time. Apparently not even WinSock > necessarily works at all then. This was what caused the hang. Why > evolution-exchange-storage has affected but not other processes that > link to libORBit2, I don't know, probably just a coincidence. As I said, > atexit() behaviour has much randomness. > > So, I simply ifdeffed out the atexit() usage on Windows... Just let the > process die, and any TCP peers should notice that the connections break > and act accordingly. Seems to work fine, although I guess there is a > risk that, like the comment in corba-orb.c says, the atexit() > functionality really is needed "to clean up any remaining UDS and to > flush any remaining oneway traffic in buffers". > > A safe way around this would be to explicitly flush and shut down CORBA > and Bonobo before exiting main() in evolution-exchange/storage/main.c. > Unfortunately I couldn't find any API to do that cleanly. Calling > bonobo_debug_shutdown() (twice, as bonobo_init_full() apparently gets > called twice and bonobo_debug_shutdown() needs to be called as many > times to actually do anything...) causes a g_error() from > bonobo_context_shutdown(): "In-proc object has no servant association > this probably means you shutdown the ORB before you shutdown libbonobo". > I wonder if that is a bogus error message? > > Anyway, there are now fresh zipfiles for ORBit2, libbonobo, > evolution-data-server and evolution in > http://ftp.gnome.org/pub/gnome/platform/2.14/2.14.2/win32/ and > http://ftp.gnome.org/pub/gnome/desktop/2.14/2.14.2/win32/ . In addition > to the fix for the problem described above, they also contain the fixes > mentioned in my recent mails: > > - There is no absolute need any longer to kill the processes that stay > running when one quits Evolution, or to clean out state files. > > - Evolution on Windows now works for users with any random Unicode > characters in their username, or if installed in a folder with spaces > (or any random Unicode character) in the pathname. (This of course is > one main point which the porting effort has had to take into > consideration from start; but only recently did I actually test it > thoroughly.) > > Enjoy, > --tml > > > > > ___ > Evolution-win32-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/evolution-win32-devel > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution .desktop file
On Fri, 2005-09-09 at 00:50 +0800, Not Zed wrote: > On Wed, 2005-09-07 at 10:23 +0200, Vincent Untz wrote: > > On Wed, September 7, 2005 09:37, Not Zed wrote: > > > > > > Sounds like a design issue with the panel to me. Why should it > > > hard-code any applications at all? And if it does hard-code them, then > > > it can hard-code the appropriate one for that gnome version i guess. > > > > Because we want to have default launchers on the panel for the most used > > applications, ie web browser and e-mail client. > > > > And we can't change this at every release cycle since this is the > > configuration for the user: when the user upgrades to GNOME 2.14, his > > nice evolution-2.4 launcher will disappear if we hard-code the version > > in the desktop filename. > > Umm, why can't you change it each release cycle? you've got 6 months to > change the name. Is that not long enough? Would you like more time? Here's the scenario: - User logs into Gnome 2.x for the first time and gets a shiny new panel launcher that's hard-coded to invoke evolution-2.y - User upgrades to the new stable Gnome 2.x+2, and the previously existing panel launcher stops working, since it points to evolution-2.y, but the machine now has evolution-2.y+2 installed. Maybe a new user would get a shiny new panel launcher for evolution-2.y+2, but users existing before the upgrade are out of luck. The obvious solution is: - Don't hard-code evolution versions in default panel launchers; have them invoke "evolution", which should be a symlink to the latest stable version. - Avoid hard-coding evolution versions in launchers in the menus, since they can be dragged to the panel or the desktop, where they will bitrot. - If we need an "evolution unstable" launcher, that should also invoke a symlink that can be updated when a new unstable version is released. -Mark Gordon ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution .desktop file
Hi Michael,
So, each time I've come across issues with the way evolution seems to
version every path, filename etc. it installs I've never felt that I
understood the reason *why* evolution does this. What exactly is the
rationale?
Let me make some random points, though:
- Applications provide various consumable public interfaces just like
libraries provide an API and ABI. Some examples of those are:
- The paths and basenames of its binaries: may be referenced by
scripts people write, hard-coded into apps, config files (like
manually created mime type associations), user created panel
launchers etc.
- Command line options and format: again referenced by scripts,
apps etc.
- The paths to and format of the app's config files: admins may
have scripts which tweak the config files, other apps may try
and extract configuration items from them
- The app's GConf keys, their format and behaviour: again, admins
would have scripts to modify them and other apps my try and
read or tweak them, but also a user's configuration needs to
keep working when moving back and forth between versions of the
app (think NFS homedir shared between two OS versions)
- The basenames of its .desktop files: other apps might reference
the .desktop file if it they want to launch the app, and
.menu files will reference the .desktop file e.g. if you edited
your menu and disabled the evolution entry, the user's .menu
file might contain
Office
evolution.desktop
- Icon names: might be use in manually created launchers, other
apps might reference them
You could go on, but the point is that, like it or not,
applications present interfaces which people will consume. Changing
those interfaces will cause breakage.
That doesn't mean that all these interfaces need to be completely
locked down and never changed like a stable ABI, but it does mean
that changing them will likely have consequences we may not have
anticipated.
It'd be nice if we could figure out how stable each of these
interfaces should be and document that so people consuming the
interfaces would have some idea how likely they are to change, but
that takes work.
Anyway - at best, consistently changing these interfaces every
release just seems very unhelpful.
- We could label each of the interfaces above as "completely and
utterly unstable; do not use on pain of death" but users of those
those interfaces do use them to provide real benefit to real users
e.g.
- We can put evolution's .desktop file on the default panel
and it doesn't break when people don't upgrade evo and the
panel in lockstep
- The launcher on the user's panel continues to work even when
you upgrade evo
- Menu editing doesn't break unpredictably
- We can launch evo when you double click on an entry in the
clock applet's calendar
- We can figure out what calendars to have in the clock applet's
calendar by reading Evolution's GConf key, thus sharing the
configuration with Evo
- We can provide a GConf backend to pull user mail account data
from LDAP
- Admins can configure Evo defaults with scripts and those
scripts keep working when they upgrade evo
- I can't see anyone wanting parallel-installable applications,
barring developers and testers, perhaps. Real users won't ever
want to have two versions of the same application and choose
between them. Developers and testers achieve that effect with all
other applications by installing them in different prefixes.
- Even if users did want the app to be parallel-installable, does
anyone do it in practice (e.g. by packaging them in
parallel-installable manner). Does it ever get tested? Do we know
it actually works?
Cheers,
Mark.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
