Folder name truncation no longer needed or should be configurable

[patrick]

Because of the vertical splitter (that divides folder list and mail list / preview pane), the user can now change the width of the folder list. Thus a fixed length truncation of the folder names is no longer necessary and strongly counteracts the usefulness of the vertical splitter.

IMO either the truncation should be removed altogether, or it should be configurable by the user.

[patrick]

Folder name truncation

[alec]

Splitter position can be read in PHP backend and folder names can be truncated to length matching list width. But changing length in javascript when moving splitter will be harder.

[arodier]

Hi,

Here a simple patch to correct this.

[alec]

We'll not fix this in such way. Names must be auto-truncated on list init and resize, like in standalone clients e.g. Thunderbird.

[arodier]

Well,

In this case, what about using a JS library like ExtJS or YUI library to draw the folders list ? Perhaps these libraries already implement this out of the box ?

[Lazlo]

Replying to arodier:

Well,

In this case, what about using a JS library like ExtJS or YUI library to draw the folders list ? Perhaps these libraries already implement this out of the box ?

This should be fixed with jQuery and not with another extra JS library. Maybe this jQuery plugin (​http://www.reindel.com/truncate/) is a good example how to implement it in Roundcube.

[glob]

there's javascript code which performs middle-truncation based on pixels at ​https://gist.github.com/24261/7fdb113f1e26111bd78c0c6fe515f6c0bf418af5

[thomasb]

Another rather simple solution: wrap unread count in a <span> which can be absolutely positioned. Then using css text-overflow for folder names. Optionally add title attributes to see the full name when hovering.

[thomasb]

Please test foldername_truncation.patch which implements a client-side truncation inspired by the script mentioned in comment 10. Disadvantage: lot of computation to be done on the client.

[patrick]

Replying to thomasb:

Please test foldername_truncation.patch which implements a client-side truncation inspired by the script mentioned in comment 10. Disadvantage: lot of computation to be done on the client.

Awesome! Works really well with my small amount of folders (~30). I'll try on some other server tomorrow, where I have access to an IMAP account with ~10000 deeply nested folders.

[patrick]

Replying to patrick:

I'll try on some other server tomorrow, where I have access to an IMAP account with ~10000 deeply nested folders.

I promised too much - the account has been cleaned up. But I tried it with an account that has 2372 folders, and at least six nesting levels:

Firefox 3.6.13 (Linux): After logging in, Roundcube says "Loading..." for a couple of seconds, after which Firefox tells me, that a script has been running for a long time, and whether I want to stop it. I clicked continue, and after another couple of seconds (less than 10), I could use Roundcube without problems. After moving the vertical splitter, there is a less-than-10-seconds delay. This is on a three year old Core 2 box.

Firefox 3.6.13 (Linux, two year old netbook): After logging in, and a couple of seconds waiting, the folder, message list and preview panes appear, and the first couple of folder names I can see are properly truncated, but the interface is unresponsive. It stays that way for one or two minutes. Once it becomes responsive, I can move the splitter, which results in a long wait again. There are no such delays when using Roundcube without the patch on this IMAP account.

Chrome 9.0.597.67 beta (Windows VM): After logging in, and a couple of seconds waiting, the folder, message list and preview panes appear, but the folder name truncation has not been done yet, and the interface is unresponsive. After some more seconds, Chrome tells me, that the a page became "unresponsive". I clicked 'wait', only to get the message again. Two or three minutes later, I'm still waiting. Chrome is still using 100% CPU time. This is on a VirtualBox? VM on the above mentioned three year old Core 2 box. Chrome does not hang when using Roundcube with the patch on this IMAP account.

Summary: Very good on IMAP accounts with "normal" numbers of folders (also tested in Chrome, and on my netbook) - but seems to hit a limit in Chrome's JavaScript? processor with many folders. It's also unusably slow on my netbook, with a large amount of folders in the IMAP account. I think it's a good solution for many users, but for some it will render Roundcube unusable. Maybe browser-side folder name truncation should be disabled when the amount of folders exceeds some limit, say, 500 folders.

[alec]

Some numbers from me. With 40 folders execution time of rcube_render_mailboxlist() is 80-100 ms in Firefox and Chrome, not bad, but... in IE8 it above 1000 ms.

[alec]

1. It doesn't work with collapsed folders. So, we'll need a function triggered on expand.
2. For better performance we can skip short names and collapsed folders

    if (text.length <= 4 || !(width = elem.width()))
         return;
   

3. I have 2x faster method of making abbreviations (might be worse for some langs)

       width = span.offsetWidth;
       if (width > len) {
           // how many letters to cut
           var cut = Math.max(2, Math.ceil(str.length * ((width - len) / width) / 2)),
             mid = Math.floor(str.length / 2);
           // build resulting string
           result = str.substring(0, mid - cut) + ellip + str.substring(mid + cut);
       }
   

4. Because we could achieve better performance by eliminating offsetWidth use, maybe it would be possible to use rcmail.env.folder_coords.
5. Think about disabling this feature on IE and/or when there's too many folders (above 100?)

[thomasb]

Replying to alec:

1. It doesn't work with collapsed folders. So, we'll need a function triggered on expand.

Right, collapsing/expanding has to trigger this, too.

2. For better performance we can skip short names and collapsed folders

Should be easy to add.

3. I have 2x faster method of making abbreviations (might be worse for some langs)

Thins only makes an assumption and doesn't fit the really available space. But we could use this "guessing" to set the initial value of cut and save some iterations in the while loop.

4. Because we could achieve better performance by eliminating offsetWidth use, maybe it would be possible to use rcmail.env.folder_coords.

I don't see a way around offsetWidth because we really need to let the browser render the text and compute its length. folder_coords only gives us the width of the box where the texts has to fit in but not the width of the rendered text.

5. Think about disabling this feature on IE and/or when there's too many folders (above 100?)

If there's no other way around the bad performance of IE...

[alec]

Replying to thomasb:

3. I have 2x faster method of making abbreviations (might be worse for some langs)

Thins only makes an assumption and doesn't fit the really available space. But we could use this "guessing" to set the initial value of cut and save some iterations in the while loop.

Yes, the assumption is that all letters have the same width, which obviously is not true, but can be close to it.

4. Because we could achieve better performance by eliminating offsetWidth use, maybe it would be possible to use rcmail.env.folder_coords.

I don't see a way around offsetWidth because we really need to let the browser render the text and compute its length. folder_coords only gives us the width of the box where the texts has to fit in but not the width of the rendered text.

But there's also a width calculation for every folder container, so maybe we could skip this using rcmail.env.folder_coords.

[thomasb]

Patch committed in [9e1daa4c]