Re: [Evolution-hackers] Evolution library consolidation
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
[Evolution-hackers] mail migration
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
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
Re: [Evolution-hackers] Evolution library consolidation
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