Re: [Evolution-hackers] Evolution library consolidation
On Thursday 13 of December 2012 06:43:15 Matthew Barnes wrote: 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. Hi, firstly, sorry for speaking up so late, I didn't have much time for Evo before Christmas. I'm with Milan on this - I'd much more prefer to have several subfolders rather then one folder with ~500 files. When working on the editor for instance, it's much easier for me to move in a folder with fewer files. I'd very like see larger submodules having their own folders. /e-util /activity - EActivity* classes /alert - EAlert* classes /attachments - EAttachment* classes /categories - ECategory* and ECategories* classes /editor - EEditor* classes /emoticons - EEmoticon* classes /filter - EFilter* classes /gal - Gal* classes /name-selector - ENameSelector* classes /signature - EMailSignature* classes /table - ETable* classes /cell - ECell* classes Just because they don't do it in GTK+ does not mean we should follow them blindly. Honestly, digging around in 500+ files slows me down and just annoys me. There is _absolutely_ no pain in using subfolders, there's only gain in developers' comfort. And from personal experience, it's also less scary for new potential contributors. Secondly, I don't understand why almost every class in Evolution should include the complete EEditor headers and ETable headers etc, when they are really needed only in a very few places. This impacts build time, because all the headers have to be preprocessed and compiled every time for every single class that includes e-util.h. I'm all for group headers - it's a good idea, but let's be a bit more reasonable here - why not having e-table.h for ETable stuff, e-editor.h for EEditor stuff etc...? Bye and Merry Christmas :) Dan 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 signature.asc Description: This is a digitally signed message part. ___ 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
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 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
Re: [Evolution-hackers] Evolution library consolidation
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. If you're building from git, I would strongly advise blowing away your current installation and rebuilding all Evolution-related modules from scratch to avoid interference from now-defunct libraries. Also check out the new libeutil API documentation. I'm still populating the libeutil-sections.txt file but I hope to complete it by month's end. Matthew Barnes ___ 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 14:20 -0500, Matthew Barnes wrote: Immediately after the merge I'm going to consolidate Evolution's base libraries into a single base utility library. libeutil seems as good a name as anything else I can think of, so I'm going to stick with that. Since the webkit-composer branch is not quite as ready to merge as I thought, and I'd like to get the library consolidation done before it gets any later in the development cycle, I'm going to proceed with it now and I'll just adapt Dan's branch to the changes myself. 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. Matthew Barnes ___ 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] Evolution library consolidation
I'm currently smoke testing Dan's webkit-composer branch before giving him the go-ahead to merge it to master. Immediately after the merge I'm going to consolidate Evolution's base libraries into a single base utility library. libeutil seems as good a name as anything else I can think of, so I'm going to stick with that. I'm also going to absorb libedataserverui back into Evolution, since Evolution is now the only module using it (I've done my due diligence on other modules that still show a dependency -- in most cases it was just a historical artifact that could be dropped). So all the non-deprecated APIs in libedataserverui will become part of Evolution's new libeutil. I plan to have this in for Evolution 3.7.3. 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) At least, that's the list for starters. I'd still like to keep things like libemformat.so, libcomposer.so and libeshell.so separate. I'm on the fence about the smime libraries. Additionally, since almost all the #include paths will need updating anyway, I'm going to move libeutil to a single-include model like we've done for Camel and E-D-S. In addition to convenience, it helps shield 3rd party apps as well as our own extension packages from quite so much API churn, even though we still make no guarantees about API stability in Evolution libraries. The new #include directive for libeutil will be #include libeutil/libeutil.h which will bring in all headers in the library. With all the base utility libraries under one header, maybe we can then get serious about producing some good API documentation for this stuff. My attempts thus far have been half-hearted at best. Matthew Barnes ___ 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 14:20 -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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
