Created attachment 126516 [details]
Gallery Mockup

Here is the basic functionality required:

- Add View >> Gallery checkbox to pulldowns 
- Add Button to the toolbar after the table button for Gallery (similar to OpenOffice).  The button is a toggle to enable/disable this feature.
- When either the checkbox or button is pressed, a mini-file manager will expose as per the mockup and display thumbnails of images.
- The user would then be able to drop and drag items from this area into the composer.
- The area would have a scrollbar to display as many items as are in the directory.
- By default, it would use $HOME/Pictures, but $EVOLUTION_GALLERY_PATH would override this and point it to another directory.
- Only images would be displayed, no documents or PDFs would display in this area.

Created attachment 134565 [details] [review]
First Patch

Notes from Pepp on the patch

Some quick notes/remarks :
- the patch was built against evolution 2.26.1
- it uses gnome's thumbnail mechanism which allow to use existant cache + to display any thumbnalizable file (at least images and pdf)
- it uses EVOLUTION_GALLERY_PATH if set, otherwise defaults to ~/Pictures (which can causes a problem : this folder won't exist on every PC because it can be localized. I haven't look for a solution for this t the moment)
- thumbnail loading is semi-asynchronous : it's done with g_idle_add callback ; I'm not sure whether or not it's a good idea (tough I'm not sure we can do real async here because this callback is dealing with Gtk UI objects)
- I'm not sure that memory free-ing is done correctly - valgrind seems to tell me it's ok, but I'm still not sure.

Created attachment 134567 [details]
How It Looks With This Patch

Created attachment 134568 [details]
Gallery In OpenOffice For Consistency

A few quick comments:

  - Please adapt the patch to git master or at least 2.27.1.
    The gallery feature will not be included in 2.26.

  - Rather than an attachment-bar-like expander, I'd suggest putting a
    "Picture Gallery" toggle button in the HTML toolbar next to the smiley
    face, and then move the icon view underneath the toolbar (just above
    the text editing area).  That way the gallery and its control would be
    naturally hidden when the composer is in plain text mode, and we
    wouldn't be wasting precious vertical space with an expander label.

  - The patch should check whether Nautilus has already cached a thumbnail
    image for the file and if so use that.  The thumbnail path is exposed
    in GIO as a GFileAttribute called "thumbnail::path".  See e-attachment.c
    in the current source code for an example.

  - We're trying to move -away- from libgnomeui in preparation for GNOME 3,
    but what to use in place of GnomeThumbnailFactory is an open question.
    I ran into this too while rewriting the attachment UI for 2.27.1.
    It's looking like we'll have to replicate Nautilus's thumbnail service
    in Evolution using GnomeDesktopThumbnailFactory from the GNOME Desktop
    Library (which would be a new dependency).  This may be a subproject
    that needs to land first so that both the gallery and attachment bar
    can act as clients of it.

  - Minor nitpick: images_folder = "~/Pictures";
    That won't work on Windows.  Use g_get_user_special_dir() instead.

Created attachment 135548 [details] [review]
Updated patch

Tested on evolution 2.26.1
Apply almost cleanly on git master (the only problem is due to the removal on some actions in e-composer-action & evolution-composer.ui which imply some rejects when patching), I hope it's ok.

Created attachment 135594 [details] [review]
Revised patch

I took pepp's patch and iterated on it a bit, refactoring some things and getting the UI closer to what I had in mind.  Since I think this feature could become fairly complex as it matures, I split the icon view into a new widget called EPictureGallery.

It basically works, but still needs polishing and better integration before it's ready for inclusion.  Here's what I think we still need to do:

  - Drag and drop from the gallery to the message area is adding the image
    both inline and as an attachment, but that's probably a side-effect of
    my recent attachment rewrite.  I'll take care of fixing that.

  - I also want to be able to drag TO the picture gallery, not just from.
    That includes image files outside of Evolution, pictures in web browsers,
    and inline or attached pictures from other emails.  Dropping a picture in
    the gallery should save it to the picture gallery folder without over-
    writing anything (assuming the folder is writable).

  - Right-clicking on a picture anywhere in Evolution should include an
    "Add to Picture Gallery" menu option, which acts the same as dropping
    a picture in the gallery.

  - I think we have to allow users to change their picture gallery folder,
    especially since it's currently not obvious where it's getting pictures
    from.  I want to the option for this to be directly in the gallery, NOT
    in composer preferences.  If you search for files in Nautilus, that blue
    bar you get above the search results with the "Location" chooser is
    roughly what I have in mind.  It should also include a helpful blurb
    about how you can drag the thumbnails.

  - Also, the custom folder will be remembered in GConf, so I think we can
    ditch the secret environment variable.  If the GConf key is locked down
    (which I imagine Dave will want to do), we'll handle that appropriately.

  - Hovering over a gallery thumbnail should pop up a tooltip showing the
    file's base name and size.

  - The file scanning and thumbnailing MUST be done asynchronously.  The
    current code blocks the UI until scanning is finished, which probably
    isn't a problem when scanning 10 pictures, but IS when scanning 1,000.

  - We also need to monitor the picture gallery folder for out-of-band file
    additions or deletions and update the gallery to reflect that.  I want
    the following use case to work:

       You just got back from vacation and want to email your family some
       vacation photos that are still on your camera.  You start composing
       an email with the picture gallery visible, then plug in your camera
       and import photos to the gallery folder.  The photos instantly appear
       in the picture gallery, and you then drag them into your email.

Created attachment 135595 [details]
Screenshot of Latest Patch

Marking the patch in comment #9 as "needs-work" to get it off our unreviewed list.

Created attachment 176859 [details] [review]
evo patch

for evolution;

Yet another revision. I only followed Pepp's and Matt's work. I didn't do everything what Matt outlined above, but I have comments on each:

* drop in composer - seems Matt fixed this, it's adding pictures only as attachments now

 * drop to gallery, right click menu, well, let's have it done separately

 * configurable path changed to GConf, no UI for that, as there is no enough space for it in the composer window

 * tooltip - none, but I believe the filename and size is useful information, thus it's shown always. I can imagine people locating their files also by names

 * asynchronicity - main issue is that all the operations on the thumbnailer and list store itself is suppose to be done in the main thread, which is kinda limiting. On the other hand, there was a typo in the code, so it was always regenerating thumbnails for images (I suppose), because attributes are comma separated list, not command + space separated list (I realized that when I added a SIZE attribute, which didn't work, so it might be quicker now. Nonetheless, opening composer is not invoking gallery filling, it's filled only when it's shown for the first time in the composer. I consider it a good behaviour, not slowing down work for users composing text-only emails.

 * monitoring - done, gallery is live on folder changes.

One thing though, we may add there some kind of sorting probably, based on file names, because right now it's pretty confusing, ordering depends on the file creation in the folder, I suppose, which is really strange for most users. Anyway, let's have a different bug for it. (Which means I'm closing this one.)

Created commit e861630 in evo master (2.91.5+)