I'm also experiencing this, but on a 13" laptop with a 1366x768 resolution.

The account creation dialog does fit in the screen, unless there are error messages (e.g I mistyped my password).

So I can actually create an account, as long as I get it right the first time. :)

If I don't, the buttons to cancel/confirm are out of the screen.

*** Bug 737028 has been marked as a duplicate of this bug. ***

*** Bug 737850 has been marked as a duplicate of this bug. ***

*** Bug 739936 has been marked as a duplicate of this bug. ***

I can confirm it on the dialog windows of general IMAP accounts, which are longer than in Gmail.
It happens on a 13" laptop as well as on a 19" monitor.

*** Bug 742131 has been marked as a duplicate of this bug. ***

*** Bug 745999 has been marked as a duplicate of this bug. ***

The bug still exists in geary 0.10. This makes geary unusable for users who are not aware of window movement with Meta + Click and difficult to use for others.

The same problem exists for the account settings and the new "additional email addresses"-view since these are basically the same view.

Are there any concerns for using a gtk scrolledwindow? I would love to create a patch if there is a chance for this beeing accepted.

(In reply to Theodor van Nahl from comment #8)
> Are there any concerns for using a gtk scrolledwindow? I would love to
> create a patch if there is a chance for this beeing accepted.

I think we'd prefer if the dialog was simplified with certain elements moved to other panes (much like the way alternate addresses are accessed).

Why don't you just use a tab design? Four tabs would be enough - Account, IMAP, SMPT, Other or something like that.

I have a 16:10 laptop screen - that is 1280*800, which is higher than most laptops, and I can't see a third of the dialog.

Same problem with the window where you can add additional email addresses (still part of the accounts dialog).
The window is stretched vertically and there's no reason for this as the list of address is currently empty.

I used Alt+space and Move to be able to interact with this dialog.

*** Bug 749805 has been marked as a duplicate of this bug. ***

I agree with Juraj.  A tab-based layout would be a natural fit.

Created attachment 314791 [details] [review]
Use a Gtk.Notebook in the dialog

(In reply to Jim Nelson from comment #9)
> I think we'd prefer if the dialog was simplified with certain elements moved
> to other panes (much like the way alternate addresses are accessed).

As there is a lot of data to be entered with the dialog I cannot think of an easy way this could be done with additional other panes.
In my mind a Gtk.Notebook fits well here.
Please find attached a patch that splits up the parts of the dialog and places them into the tabs of a notebook. The notebook is small enough to fit on smaller laptop screens.

The patch is tested and works. I does not lead to any Gtk-criticals or warnings.
The patch was commited here [1] for convienience.
[1] https://github.com/purejava/geary/commit/85251aa6b584e7271ab1b057fb415deca8c095db

I hope, the patch has a chance to get considered.

Created attachment 314792 [details]
Screenshot

Attached you can also find an image that shows the look of the new dialog with "other" accounts.

(In reply to Ralph Plawetzki from comment #14)
> Created attachment 314791 [details] [review] [review]
> Use a Gtk.Notebook in the dialog

You accidentally included po/de.po file to the patch

This was intended as I introduced a new label.
Looking through the commits of the past for translations, it seemed that
changing the po file is the right way of doing this.

If this is wrong, could you please point me to a description on how to
do this?

(In reply to Ralph Plawetzki from comment #18)
> This was intended as I introduced a new label.
> Looking through the commits of the past for translations, it seemed that
> changing the po file is the right way of doing this.
> 
> If this is wrong, could you please point me to a description on how to
> do this?

AFAIK you prepare the patch for source code/ui files, after commit maintainer will update po files.

Ralph, I'm just an user and translator of Geary.. I've tested your patch and I think this is an improvement to the current dialog, which is not usable on my screen.
Ideally, I would prefer a single window with no tabs; but if it's not possible, this patch makes the account dialog usable on any screen. This is a major issue IMO (6 duplicate issues are an indicator).

I saw two minor problems in your patch:

- Additional email addresses ends with three strange characters
- Strange characters also in the password field of IMAP settings

See screenshots here:
http://s1.postimg.org/8qb64azkf/geary_account.png
http://s1.postimg.org/daxcj8j9r/geary_account_2.png

I confirm that you should remove the de.po file from your patch.
The pot and po files are generated automatically and they are handled through Gnome Damned Lies infrastructure.

Created attachment 314831 [details] [review]
new patch

Federico, thank you for testing the patch. The strange characters is a very good catch from you!
I committed yesterday from a non UTF-8 system and that changed all non-ASCII characters in ui/login.glade.
This affected the button label you found and all entry fields that show dots when entering text.

Thank you very much for the hint to remove the de.po file from the patch. I was not aware of how this is handled.

Please find attached the new patch.

It works fine now!

Last comment: any better description than "Service preferences"?
Some ideas: Account details, Credentials.

(In reply to Federico Bruni from comment #22)
> It works fine now!

Thanks for testing again!
 
> Last comment: any better description than "Service preferences"?
> Some ideas: Account details, Credentials.

You are right: "Account details" fits much better.

Created attachment 314841 [details] [review]
new patch

First tab label changed from "Service preferences" to "Account details".

Created attachment 316079 [details] [review]
Improved patch.

Less generic ids for new Gtk.Notebook tab labels.
Reverted changes due to newer glade version in ui/login.glade.

Just wanted to add that it also a big deal on HiDPI laptop screens. For example, on the Dell XPS 13 the resolution is 3200x1800, but with 2x scaling (1600x900 effectively) the menu is still tossed out of bounds.

Comment on attachment 316079 [details] [review]
Improved patch.

Hm. there are quite some things that could be improved with this patch:
- edit login.glade directly instead of using glade to keep maintainability
- use Gtk.Stack and Gtk.StackSwitcher here instead of Gtk.Notebook for usability

*** Bug 753108 has been marked as a duplicate of this bug. ***

*** Bug 759284 has been marked as a duplicate of this bug. ***

Hi Ralph,

Thanks for your work on this bug. I tend to agree with Jim in that some more advanced elements of the existing dialog could got moved off it (the signature UI comes to mind), but I'd also like to get it more in line with the GNOME 3 HIG.

Also, while both the account creation and account settings are obviously related, the workflow guiding the user through initial setup can be cut down a fair bit by comparison, which may lead to a larger difference in how they are presented.

For the account settings, I have something like the following in mind:

1. The account dialog should contain a GtkStack (without any switcher) for transitions between the account list and account details components.

2. The account list component should have a GtkListBox and follow the HIG Editable Lists pattern, probably using a full-width list if the rest of the contents stay narrow enough, and where each row has a remove button and the last row is an add button. See: https://developer.gnome.org/hig/stable/lists.html.en

3. When selecting an account, the dialog's stack transitions to the account detail component - another GtkStack, and a GtkStackSwitcher is added to the dialog's HeaderBar.

4. The account detail stack is controlled by the GtkStackSwitcher, per the HIG View Switcher pattern (<https://developer.gnome.org/hig/stable/view-switchers.html.en>) which has three children: "Account" - containing the existing misc account details and composer sections, "Incoming Mail" - containing the IMAP and Storage sections, and "Outgoing Mail" - containing the SMTP section.

I have to think about the account creation UI a bit more, but it would likely be a third child component for the dialog's stack, and a more guided, cut down version of the full account settings, like as it is at the moment.

Would you be interested in working towards this kind of design?

Hi Michael,

I am sorry.
Meanwhile I became a member of the elementary OS Apps developer team and help developing the forked geary there, so unfortunately I myself right now do not have time left to take over responsibility for Gnome/geary as well.

Kind regards,
Ralph

(In reply to Ralph Plawetzki from comment #31)
> Meanwhile I became a member of the elementary OS Apps developer team and
> help developing the forked geary there, so unfortunately I myself right now
> do not have time left to take over responsibility for Gnome/geary as well.

No problem, thanks for your work on it.

I'll leave this open in case anyone else wants to take a look at it.

Created attachment 329594 [details] [review]
[WIP] use GtkStack

Fiddled around a bit and was able to get to this.

Done:
* Use a Stack/StackSwitcher
* Moved some ui code from add-edit-page.vala to the glade-file (signature elements are now visible from Glade)
* Removed a lot of unnecessary elements in the glade file.

Todo:
* Put the StackSwitcher in a HeaderBar
* Find out how to disable buttons in the StackSwitcher
* Check what settings belong in which categories
* Maybe use GtkSwitch instead of GtkCheckButton for some boolean settings?

Created attachment 329595 [details]
[WIP] use GtkStack - screenshot

Screenshot of the layout using GtkStack.

Could you put the GtkStack into the headerbar, System Monitor style?

That's the plan, which is why I made sure to include it in the little todo-list :)
(It's not up there yet since it needs a bit more work than the rest, due to the way account pages are setup).

Hey Niels, this patch looks like a good start.

After a quick look, the only thing I'd note for the moment is that the Glade file changed to require GTK+ 3.16, however Geary is currently targeting 3.14, so that will need to be rolled back.

Thanks Michael, changed that requirement back to 3.14.

For the detailed account edit page, I do agree with Ralph that a notebook might be the best UI element to represent the different settings (whereas a stack page would make more sense if e.g. we were to merge the account settings and the preference settings). That way, we can also add the alternate emails as a separate tab in the notebook. Another option would be a GtkStackSideBar, but that isn't a possibility since it is only available in GTK+ >= 3.16.

Another question: it might seem silly, but do you know if there is a reason for the separate AddEditPage and AccountDialogAddEditPane?

(In reply to Niels De Graef from comment #38)
> For the detailed account edit page, I do agree with Ralph that a notebook
> might be the best UI element to represent the different settings (whereas a
> stack page would make more sense if e.g. we were to merge the account
> settings and the preference settings). That way, we can also add the
> alternate emails as a separate tab in the notebook.

I'd like to limit the number of top-level stack/notebook pages to reduce the number that people have to search through, which means advanced settings like the alternate emails will need to remain accessed via buttons on three or four main pages. This is basically how Epiphany's prefs work, which is a good model to follow.

But that aside, having a look at other GNOME apps, they do seem to use Notebooks for their pref windows. Geary's requirements are a bit more complicated since it has multiple accounts, but we should try to remain relatively consistent with the rest of the desktop.

So instead of adding a child Stack and Switcher when the user activates an account in the list (i.e. Part (3) of Comment 30), a Notebook is added instead. This should leave enough room in the HeaderBar to also put the Cancel/Save buttons there, which also needs to happen anyway.

Does that seem reasonable?

> Another question: it might seem silly, but do you know if there is a reason
> for the separate AddEditPage and AccountDialogAddEditPane?

I think one is used for creating new accounts, the other is for editing an existing account. One or both are probably badly named. :)

is using a scrollbar an option?

Created attachment 330200 [details]
Add-edit-page ~ Screenshot comparison

Sorry about my reply taking some time, but some problems came up.

The biggest issue we face is the fact that the add-edit-pane is used at several places, and several options require some fields to be hidden/shown. This means we need to think of a UI that fits the following scenarios:
(1) The first time a user starts up Geary, he/she gets welcomed with a welcome screen: this is a little login dialog, along with a way to add the initial account.
(2) Adding an account from a known provider (e.g. GMail)
(3) Adding/Editing an account from an "unknown" provider
(4) Editing an account from a known provider (e.g. GMail)
Not only that, but there are some differences between adding and editing that don't really make sense, e.g. you can't choose the amount of time Geary should go back on the server looking for emails, or a signature.

I included a screenshot, together with a prototype with a horizontal notebook. Vertical would seem a better choice since even 3 tabs already require scrolling on smaller screens with a vertical noteboook.

So my question is whether it is better to "keep it simple" and for example add a scrollbar, or to use a more advanced interface like a notebook/stackswitcher.

Yep, well a scrollbar is only really appropriate for lists and document like UIs, so that's out unless we want a brown paper bag quick fix. :) If nothing else, using a flow box would be better than a scrollbar.

So just to clarify - in the screenshot above, you mean it's an example of a vertical notebook, right? What scrolling is required on smaller screens in the case of using a horizontal notebook? Do you have the px sizes of those windows?

The code and UX probably needs to be split up between the Add Account use case and Edit Account use case. It is pretty likely that using a Gtk.Assistant for creating new accounts (which can also also have a special case to handle any first-run welcome screen) is appropriate here anyway, which implies using separate top-level classes for that and the accounts dialog.

We may still be able to get some code/UI reuse however by splitting out the Account/Incoming/Outgoing panes out into separate top-level widgets, each with their own UI template, which can then be added as needed to the Add Account Assistant and the Accounts Dialog. These each would still have to support the 2×2 modes you mention, but individually they are smaller chunks of code so that additional complexity from the different modes may be manageable in that case.

The use of a combobox for selecting an account is interesting, but the current approach of an activatable list has a bunch of advantages that I'd be unhappy to lose. What's your reasoning behind it?

Created attachment 330230 [details]
UI mockup

Here's a rough mockup of what I was thinking of in Comment 30, except using tabs.

Created attachment 330231 [details]
UI mockup source

Created attachment 330411 [details]
[Screenshot] Horizontal notebook

Screenshot with a horizontal notebook (450px-466px). Seems like Glade gave me a far more stretched horizontal version. (Note that this version only uses 3 tabs atm).

> It is pretty likely that using a Gtk.Assistant for creating new accounts is
> appropriate here anyway
Huh, didn't know that existed. Does indeed seem the best UI for this.

> The use of a combobox for selecting an account is interesting, but the current
> approach of an activatable list has a bunch of advantages that I'd be unhappy
> to lose. What's your reasoning behind it?
The combobox is not for choosing an account, but selecting the service provider of your email host. The account list is still untouched, and I had something similar to Comment 43 in mind for that (although it isn't clear where the 'delete account'-button would go).

(In reply to Niels De Graef from comment #45)
> 
> Screenshot with a horizontal notebook (450px-466px). Seems like Glade gave
> me a far more stretched horizontal version. (Note that this version only
> uses 3 tabs atm).

Okay, cool, well that looks like it should fit a netbook screen.

> The combobox is not for choosing an account, but selecting the service
> provider of your email host.

Ohhhh, okay. Well since that's not currently able to be changed once an account has been created, when editing an account it just shouldn't be shown, or shown as a static label. In the mockup I have it in the HeaderBar's subtitle.

> The account list is still untouched, and I had
> something similar to Comment 43 in mind for that (although it isn't clear
> where the 'delete account'-button would go).

I'm imagining having a remove button for each list item (the "-"'s in the mockup) - check out the HIG link in (2) of Comment 30 above.

Just FYI there's a bit of work going on regarding the email address UI over in Bug 747893 - may need a bit of coordination.

As mentioned in Bug 747893 - I've just created a new wip/ux branch in git for the design work, currently has a WIP mockup for the Accounts tab and email editing: https://git.gnome.org/browse/geary/plain/ux/accounts/email-mockups.png?h=wip/ux

Just fleshed out account mockups a bit more. These are also in the ux branch here: https://git.gnome.org/browse/geary/plain/ux/accounts/account-mockups.png?h=wip/ux

(In reply to Michael Gratton from comment #49)
> Just fleshed out account mockups a bit more. These are also in the ux branch

Is there a GTK control that lets you drag and reorder a list?  If so, how easy is it to add to the Accounts List and the Sender Addresses?

(In reply to Michael Gratton from comment #49)
> Just fleshed out account mockups a bit more. These are also in the ux branch

BTW, this is a huge improvement over the current code. Thanks for working on this!

Created attachment 333379 [details] [review]
WIP - Accounts revamp

Hi everyone! Apologies for the delay, I've been a bit preoccupied by work & studies.

First of all: Michael, great mockups, it's a real improvement over the current situation or the ones we were discussing.

Now, I tried to implement the UI for these screenshots, which lead to the attached patch. Note that it is very much an early WIP and has only been tested on GTK+ 3.20.

The current architecture is as follows:
* to enable reuse of code, I split up the aggregation of the account information in several AccountForms. These can both be reused as a page in a AccountCreateAssistant or as a part of dialog/popover.
* there is now a common css class for preferences. This allows one to easily adapt the UI for the general preferences dialog as well.

A short but non comprehensive todo-list:
* Merge the AccountEditDialog and AccountListDialog into one, to prevent multiple overlapping dialogs.
* Small tweaks to the UI (same size rows, placeholder texts, ...)
* anything interactive basically ^^
* The major part: in the old way, validation happens through a GearyController method, which is very backwards in my opinion. Validation should happen by the model itself, or possibly by a delegated validator-object. I suggest moving the validation code into the geary engine at the very least, but a validator for the models (Geary.AccountInformation, Geary.Endpoint, ...) seems the best approach.
* POTFILES.in

Is this the UI everyone can agree on? :)

Created attachment 333380 [details]
[Screenshot] WIP - Accounts revamp

Screenshots for comparison.

Review of attachment 333379 [details] [review]:

Hey Niels, I'm glad you're picking this back up. I haven't tried the patch yet, but did have a quick look through it.

The AccountForm approach is great. For reasons I note below you may want to consider using a Gtk.Grid as the base class, which is generally better than using a Box these days. There's a few other notes below as well, but in general the approach so far is spot on. Also, feel free to add yourself as the copyright holder for any substantive amounts of code you have written, if you want. It's your code after all.

Merging the two dialogs is definitely a good idea. I was imagining a stack with a slide-left-right transition, what did you have in mind?

In an ideal world, it would be best to have just-in-time validation wherever possible, rather than waiting for the user to hit Save. For example if the user enters an email address that is already used in a different account, they should be allowed to do so but it should show up flagged as such in the UI (highlighted red, with an appropriate warning icon and tooltip, or whatever) and the Save button should be disabled until unless the account successfully validates again. I haven't looked into how much work that would involve, but I imagine one way to do it would be to create a Geary.Engine.AccountValidator class, move the Engine's existing validate_account_information_async() routine to it, and split that method up up into a separate one for each thing or group of things to be validated (email address, endpoint, etc). The UIs can then create and use an instance of that as needed. It will need to call back into the Engine to implement most of the validation (e.g. enumerating existing accounts to check for duplicate addresses) but that's fine. I think this might be the approach you were getting at anyway. :)

FWIW, I'm totally down with this UI. I do want to think about how the Assistant will work for different account types, but regardless, reusing the AccountForm classes will be the way to go.

::: src/client/accounts/account-list-dialog.vala
@@ +11,3 @@
+    private Gtk.ListBox account_list;
+
+    private Gtk.Window parentWindow;

Is it possible to grab the parent from Gtk.Widget.get_parent_window(), which makes this member somewhat redundant.

@@ +22,3 @@
+
+        try {
+            foreach (Geary.AccountInformation account in Geary.Engine.instance.get_accounts().values)

Avoid using global static objects like Engine.instance - I'm aiming to remove them in the future. Pass an instance of Engine in as a constructor param instead.

@@ +30,3 @@
+        // Watch for accounts to be added/removed.
+        Geary.Engine.instance.account_added.connect(on_account_added);
+        Geary.Engine.instance.account_removed.connect(on_account_removed);

While this technically might not be race at the moment, because I don't think Geary is currently using threads in a way that will affect available accounts, it's better to code defensively and hook up the handlers before doing the loop.

::: src/client/accounts/forms/account-form.vala
@@ +8,3 @@
+  * The AccountForm represents a part of the elements.
+  */
+public abstract class AccountForm : Gtk.Box {

Consider converting this to a Gtk.Grid, since that supports Gtk.Align.Baseline alignment which is important for forms like this, and since it also uses the child's h/vexpand and h/valign properties rather than pack_start/end args, so it's a better encapsulated, more flexible approach.

Hi !

The new WIP layout seems promising :) Nice job !

Until this new layout is ready for release, is it possible (and simple/quick ?) to add a scrollbar/resize option ? Or is there a way to validate my settings without accessing the button ?

(In reply to The Black Hole from comment #55)
> Until this new layout is ready for release, is it possible (and simple/quick
> ?) to add a scrollbar/resize option ? Or is there a way to validate my
> settings without accessing the button ?

Unfortunately the only way to do that at the moment is to temporarily increase the resolution of the screen if possible, or use your window manager to access the bottom of the dialog: Pressing and holding <Alt> or <Super> then clicking and dragging any part of the window up usually works, although with some WM the particular key/button combination may be something else.

(In reply to Michael Gratton from comment #56)

Thanks for your suggestion but I can't increase my resolution on my laptop (1366x768) and with the <Alt> trick, the window won't further than the top of the screen.

But I've found a temp solution accidentally ! By pressing <Tab> multiple times, I can switch between options, text inputs, etc... and the OK/Validate button. So I just have to press <Enter> blindly to confirm the selection when I think it's on this button :) Works perfectly !

*** Bug 770843 has been marked as a duplicate of this bug. ***

*** Bug 772311 has been marked as a duplicate of this bug. ***

The mockups look really good to me - definitely an improvement on what's in Geary today. A few comments, in case they're useful:

 * Instant apply is generally preferable to explicit apply - it would be great if instant could be used throughout.
 * The dialog design is best suited to cases where there are a lot of email accounts. For single email accounts navigation is purely overhead. That big window will look rather empty with only 2/3 accounts. One option might be to change to a sidebar switcher or similar.
 * Where possible, we generally try to avoid stacking dialogs on top of each other. This is partly to reduce the amount of navigation steps, but is also better visually. Flatter design, in which settings can be interacted with directly, rather than one based on nested dialogs, is generally preferable.
 * It seems common to want to edit imap and smtp at the same time. I had this recently when creating an account and trying different combinations of settings to get it to work.

I've done a few experiments, just to show how the design could be adapted in line with the comments above. Feel free to do with them what you wish.

https://dl.dropboxusercontent.com/u/5031519/geary/account-settings.png

Hey Allan,

Thanks for the feedback! A few questions:

How do you envisage the account order and the primary email being changed? DnD on  the rows? We would probably need drag grips at the start of the rows to indicate that, right? But then that might look a bit weird with the account circles. I wonder how you do that with the keyboard, also.

I guess deleting an account could be handled by a button at the bottom, below server settings, but that seems a bit out of place.

Out of curiosity, what were you changing in the IMAP and SMTP settings at the same time - credentials? Wasn't that validated correctly at account setup?

What would you suggest is best practice for instant apply when settings are interdependent? E.g. TLS negotiation and port number? A combobox that combines both might work, but then custom ports need to be handled still. I'm a little bit wary about using instant apply for security settings since if you accidentally chose no security, then your password may get sent over the wire in clear text.

(In reply to Michael Gratton from comment #61)
...
> Thanks for the feedback! A few questions:

Hi Michael! Sorry for the slow response. And just to reiterate, my mockup was just meant as a demonstration.
 
> How do you envisage the account order and the primary email being changed?
> DnD on  the rows? We would probably need drag grips at the start of the rows
> to indicate that, right?

DnD and drag grips would be my first choice, yes.

> But then that might look a bit weird with the
> account circles.

That's true. You could change the circles to something else.

> I wonder how you do that with the keyboard, also.

For accessibility purposes you could use ↑ and ↓ when the row is focused, I suppose. That certainly 

> I guess deleting an account could be handled by a button at the bottom,
> below server settings, but that seems a bit out of place.

Alongside Server Settings maybe, on the left.

> Out of curiosity, what were you changing in the IMAP and SMTP settings at
> the same time - credentials? Wasn't that validated correctly at account
> setup?

I'd created an account that didn't properly work after I'd created it, so I tried different combinations of the username/password/authentication settings until it worked.

> What would you suggest is best practice for instant apply when settings are
> interdependent? E.g. TLS negotiation and port number? A combobox that
> combines both might work, but then custom ports need to be handled still.
> I'm a little bit wary about using instant apply for security settings since
> if you accidentally chose no security, then your password may get sent over
> the wire in clear text.

While instant apply is generally preferred, this sounds like a case where explicit apply might be better. The HIG states:

"Explicit apply is only necessary if changes in the dialog have to be applied simultaneously in order to have the desired behaviour."

It's a bit sad that this is still a problem after nearly 5 years, 4 of them at "High" importance. It's still very relevant because laptops with hidpi displays scaled to an effective height of 800 pixels or less are quite common now. Couldn't you just adopt the best solution proposed so far instead of getting sidetracked by ideas for other improvements?

How about replacing the main labels with GtkExpanders containing the relevant options (maybe adding one called "Details" at the top)? I think that would be quite easy for users and easy to implement, although you might want to add some code to make it remember the collapsed/expanded state of each section between sessions.

(In reply to Allan Day from comment #60)
...
> I've done a few experiments, just to show how the design could be adapted in
> line with the comments above. Feel free to do with them what you wish.
> 
> https://dl.dropboxusercontent.com/u/5031519/geary/account-settings.png

Dropbox changed all their sharing links recently. This is the updated URL:

https://www.dropbox.com/s/a3qdycrxpirofoq/account-settings.png?dl=0

Hi all! Sorry for the delay on replying, I've been (and still am) busy getting through projects, a thesis and (my almost last) exams.

@Allan: thanks! Since this will land in 0.13, which should get a bump of the minimal required GTK+ version, I might be able to directly implement that mockup indeed.

@Michael: I kind of understand the idea of adding a GtkExpander for the time being in 0.12 to accomodate the people with a notebook. I wouldn't put too much thought in it, since the complete UI change should really land in 0.13.

@Tony: I'm sorry that this bug has been taking a while. It's just a bit more work than it seems at first sight, with the module for accounts being one of the more organically grown modules with a lot of pitfalls. As I mentioned at the top of this comment, I've been having a lot of work in my studies, so I've been limiting my free time to small digestible breaks. That has the disadvantage of being too short in time to be able to properly work on this bug (as changing one part of the code seems to break so many others). Please also do keep in mind there has been a major gap in those 5 years (with Geary being close to dead at a moment) before we started working on this. In the meantime, I've been doing some rebasing of this patch to the latest master, and I'm planning on using the work made in bug 768975. So work is still being done, but at a slow pace to keep up with my personal life.

Oh, I didn't realise Geary only had one overworked developer on it. It looks so polished and I thought it was a major part of ElementaryOS.

*** Bug 754437 has been marked as a duplicate of this bug. ***

Now that the service info (Bug 768975) and GOA integration (Bug 714876) work has gone in, we're going to need to fix up the accounts dialog to support both that and also non-GOA based OAuth2 accounts (Bug 746705).

So the branch wip/714104-refine-account-dialog is going up with an intermediate solution. It's currently very much a WIP and the UX is somewhere between Niel's and Allan's. So it will likely want some additional love once it lands, but that will very likely need to wait for 0.14.

I was curious about the new look.
It looks really awesome!

The branch did not compile for me due to the last refactoring changes.
Here is how to circumvent the compilation errors.
https://gitlab.gnome.org/purejava/geary/commits/wip/714104-refine-account-dialog
The first of the two commits is needed on Arch linux as it has enchant2 already.

Hey Ralph, cheers. Yeah I'm not surprised that it's a bit busted, I have a stash somewhere with a bunch of changes that probably need to get pushed. That also includes some work for the new account part of the UI, but I wasn't terribly happy about the initial approach I was taking with it, so hadn't pushed it up yet. I will if you're interested in having a look though.

So is Enchant 2 API compatible? Why did they bother with the version bump then I wonder? Do you mind if I borrow that patch? /:)

(In reply to Michael Gratton from comment #71)
Hi Mike, cheers :)

> I will if you're interested in having a look though.

Sure!

> So is Enchant 2 API compatible? Why did they bother with the version bump
> then I wonder?

There were a couple of changes with the Enchant 2 API, but looking through the changes and checking what geary is using, I think no changes for geary are necessary.
https://github.com/AbiWord/enchant/releases/tag/v2.0.0
https://gitlab.gnome.org/GNOME/geary/blob/master/bindings/vapi/enchant.vapi

> Do you mind if I borrow that patch? /:)

No, of course not. Take whatever you like.

Kind regards,
Ralph

I just pushed an update to the wip branch with some initial code for the new account UI, and minor fixes elsewhere. Items left on the todo list are as follows:

 - Implement saving changes to existing accounts
 - Proper progress reporting and error feedback when creating a new account
 - Add UI elements for editing existing server details
 - Some additional GOA integration work
 - Support reordering of accounts and emails addresses (dnd + short cuts + buttons/context menu?)

Ralph, could you let me know if that doesn't build for you?

(In reply to Michael Gratton from comment #73)
> Ralph, could you let me know if that doesn't build for you?

It builds fine on Arch linux.

Please note that I changed two things before building as Arch linux has enchant-2:

meson.build
-enchant = dependency('enchant', version: '>= 1.6')
+enchant = dependency('enchant-2', version: '>= 1.6')

renamed:      bindings/vapi/enchant.vapi -> bindings/vapi/enchant-2.vapi

Kind regards,
Ralph

Account creation and GOA integration has been pushed up to the WIP branch.

Current TODO now looks like:

 - Implement saving changes to existing accounts
 - Add UI elements for editing existing server details
 - Support reordering of accounts and emails addresses (dnd + short cuts + buttons/context menu?)
 - Handle self-signed certs when creating the account

If anyone has a mail server that uses a self-signed cert for both IMAP (and ideally SMTP submission) that they can create a temp account that I can use for testing, please do let me know.

Fixed on master by https://gitlab.gnome.org/GNOME/geary/merge_requests/71