Re: [Evolution-hackers] Evolution library consolidation

2012-12-13 Thread Milan Crha
On Tue, 2012-11-27 at 15:30 -0500, Matthew Barnes wrote:
  The new libeutil will include APIs that are currently scattered
 across:
  
 a11y/libevolution-a11y.so
 e-util/libeutil.so
 filter/libfilter.so
 widgets/e-timezone-dialog/libetimezonedialog.so
 widgets/editor/libeeditor.so  (new in Dan's branch)
 widgets/menus/libmenus.so
 widgets/table/libetable.so
 widgets/text/libetext.so
 libedataserverui/libedataserverui.so (from E-D-S)
 
 Addendum: Forgot to list an obvious and important one:
 
widgets/misc/libemiscwidgets.so

On Wed, 2012-12-12 at 14:45 -0500, Matthew Barnes wrote:
 On Sun, 2012-12-09 at 08:59 -0500, Matthew Barnes wrote:
  I expect this is a couple days worth of monkey work, but I should have
  it done by mid-week in time for the 3.7.3 release.
 
 Just committed this to master.

Hi,
I didn't understand from the initial announcement that you'll not only
merge those above in one .so, but that you'll also move all the files
into one folder. This makes it quite messy to find anything, the
previous file layout was better from my point of view. I guess making 
   eutil/menus
   eutil/table
   ...
as static libraries, linked into one libeutil.so would work pretty well
too, with an advantage of sorted code.

It's similar like with imapx files in eds. I didn't see any issue with
them being part of eds/camel, instead of eds/camel/providers/imapx, but
after some time of usage I realized that it's quite unfortunate,
especially when you want to find something in imapx code. Before the
file movement I was able to go to eds/camel/provides/imapx and search
only imapx related files for my search term, but now I search *whole*
camel, which gives me too much noise.

Maybe we cannot do anything with imapx anymore, but we still can with
eutil, or not?

Just my opinion.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution library consolidation

2012-12-13 Thread Matthew Barnes
On Thu, 2012-12-13 at 08:59 +0100, Milan Crha wrote:
 I didn't understand from the initial announcement that you'll not only
 merge those above in one .so, but that you'll also move all the files
 into one folder. This makes it quite messy to find anything, the
 previous file layout was better from my point of view. I guess making 
eutil/menus
eutil/table
...
 as static libraries, linked into one libeutil.so would work pretty well
 too, with an advantage of sorted code.

The old partitioning is still reflected in the API documentation.  I
don't see anything messy about having the source files in a flat list.
GTK+ is able to manage its widgets well enough with a similar layout.

Matt

___
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] mail migration

2012-12-13 Thread Sasa Ostrouska
Hi I know this is not direclty related to hacking on evolution, but I
would like to ask one advice.

I have about 5Gb of e-mails on my laptop which I use for work, and it
is still on evolution 2.26.3.
I would like to migrate now this stuff to evolution 3.6.x

What is the best way to do that ?

Simply upgrading evolution seems not to work, as it starts the wizard
as if .evolution dir doesnt exist.

Any tools around ?

Rgds
Saxa
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Evolution library consolidation

2012-12-13 Thread Milan Crha
On Thu, 2012-12-13 at 06:43 -0500, Matthew Barnes wrote:
 The old partitioning is still reflected in the API documentation.  I
 don't see anything messy about having the source files in a flat list.
 GTK+ is able to manage its widgets well enough with a similar layout.

Hi,
API documentation doesn't matter, I thought you'll understand the pain
when it gets to searching *the code*. I do not think comparing with GTK+
matter, they have code divided into folders too, at least gdk and gtk+
parts, and those are in separate folders, with their own subfolders.
They also have special folder for 'tests', while you made that all
together, counted 241 .c files in there (gtk has more, but that is gtk,
they have it that way, we *had* it better way, in my opinion). Searching
for any common function in there will not be fun.

I was told, many years ago, that folders are for people, computers don't
care of folders in a sense of dealing with a mess, but people do.
I do. At least. That said, the flat folder feels like a regression for
me, because I got use to the sorted code during the years I work on
evolution*.
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers