i didn't get much time to work on the plugin last week, but here's a WIP version attached if anyone wants to try it out.

a couple settings pages don't work (filters and responses), and some of the menu items are missing still (add contact, switch target to get back to mail/settings from some places). but it can be played around with a bit.

i've been using this with roundcube-1.0.3, and my dev setup has a few plugins that you may not have but i think it ought to work in most cases (the spam button is hardcoded at the moment, and only for my hacked version of markasjunk2). i haven't done much styling either, so the buttons and some other things are still a bit ugly.

On 14-11-27 09:05 AM, Brendan wrote:

i'm not sure it's possible to do a pure css responsive solution, as there are a few things that will come back to bite you:

• if the client is in splitview mode for the list, the click handlers

and open target are different from the full view mode (message opens in iframe instead of new window)

• for addressbook and settings, the 3rd pane is often opened as an

iframe, which is often small enough that it will trigger the @media css section for mobile (leaving the iframe with different styling)

• users changing the field order on the mailbox list view can make the

responsive css hard to deal with

• probably a couple other things i'm forgetting

i've been working on converting the changes we've made locally to some of the main javascript files to implement a passable mobile UI into a plugin that anyone can use; it's a combination of javascript, php, and css. i still have some work to do ironing out a couple things, but it's generally functional at this point - likely next week i'll have a beta version that people can try out. like your pure css, it's larry-only, although i'm pretty sure it could be adapted to work with classic too (just with some different css rules)

currently on the list views (mail and addressbook) it creates a shadow copy of the list and displays that copy for mobile (via css) rather than normal one. this allows consistent click behaviour no matter whether the user is in split or full mode, and allowed me to add a click to select handler that is always present (rather than only having one if the checkbox plugin is active and the checkbox column is enabled for the user). it also allows a partial "infinite scroll" implementation (where more messages are loaded once you scroll to the bottom of the message list)

on the compose page, it limits the user to text mode - tinymce just takes up too much space.

it also implements a shadow menu bar, as it makes it easier to save space and keep only the most used options/buttons on the screen to save precious space.

i haven't done a lot of styling/design around things yet, i've just been working on making things work (so some things aren't the prettiest, and some of the icons might not be the correct ones)

On 14-11-27 05:02 AM, martijn.thie@kpn.com wrote:

...

As a response on the ticket: #1489838 “separate mobile interface is needed” (http://trac.roundcube.net/ticket/1489838)

First of all, I agree... Mobile/tablet interface should be there in the standard product, as a lot of people are more and more using tablets and mobiles as their primary device.

About a solution... I guess one would first need to make a choice whether to implement Responsive Design in Larry or to select another template/theme based on the device-type using the user-agent string.

Both solutions have advantages and drawbacks. Selecting a different template based on the device type, gives you the possibility to create separate functionality per device. Some functions should work a little different for a tablet then they should for a mobile device. So, in some cases that might require different javascript calls or so. The major drawback is, that you're always behind on supporting all devices. To stay compatible, it needs effort around the clock.

On the other hand, Responsive Design is the choice for a future-ready template. It doesn't care about which device you are on, it just looks at the capabilities of the device and adapts the design along. It is a pure CSS solution. That is good, but that also means that you don't get to have separate functionality. The major drawback to Responsive Design is that the CSS structure can be harder to maintain.

That all said... I have made a first attempt at enabling Responsive Design for the default Larry template. In about one day, I've succeeded to redesign the email screen for the most part. The boundaries I used for my attempt was to only use one CSS file to do it all. This one CSS file is simply added to the default CSS includes.

The biggest problem that I faced, was that not all styling is done in a CSS file, but for some elements CSS is added directly to the element using the style attribute. In some cases I had to entirely corrupt the CSS of some elements to undo the CSS that was put into the style attribute.

I’m not sure if and how attachments are processed by this mailinglist (as this is my first post), but I’ve attached a zip file containing the css. Also added three screenshots of the result on my Android device. The screenshots show the Dutch version of Roundcube, but it should give you an impression.

In order to try it out and see how Responsive Design works, just add the css file (mystyle.css) to “root-of-roundcube/skins/larry” and add the following line to the “root-of-roundcube/skins/larry/includes/links.html”:

<link rel="stylesheet" type="text/css" href="/mystyle.css" /> Reload the page in your browser and adjust the size of your browser window to a smaller width. Currently (for testing purpose) the width at which the Responsive Design kicks in is at 1111px.

Please keep in mind that this is just a simple try-out from my part. It’s incomplete (at best) and the result of only one day of trying. A better result is possible by adding an additional javascript file for adjusting some html elements before the Responsive CSS kicks in. And an even better result can be get by removing the style attributes from the HTML and adjusting the HTML of Larry in small ways to better adopt smaller windows.

Regards, Martijn

---

Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev

...

i didn't get much time to work on the plugin last week, but here's a WIP version attached if anyone wants to try it out.

Is there additional config that needs to be done for this? I installed and activated it in a test 1.0.3 instance, but my iPhone still displays the normal interface.

hm, no. it ought to just pick up right away. in a desktop browser, try loading up webmail - you should see it loading mobile.css as one of the network requests.

shrinking the browser down to be under 760px wide should trigger the CSS that displays the mobile view, as well.

i've run into a problem a couple times now. following the instructions at http://trac.roundcube.net/wiki/Doc_Plugins for a plugin with javascript that needs to register javascript hooks does not always work

• calling rcmail.addEventListener() can fail as the browser has not yet

finished compiling the rcube javascript code/object (chrome seems to trigger this often, probably due to some compilation optimizations it has).

for a small plugin, i just added a setTimeOut loop that would only execute once rcube had been defined, but it's a bit of an ugly hack (and could open up some timing issues with respect to when the code actually runs).

with this mobile plugin i ran into the problem again. locally, i added a browser/jquery event at the beginning of rcube.init() (in app.js): $.event.trigger({'type':'rcmail_init'});

the plugin javascript then just has a section: $(document).on('rcmail_init', function() { // register rcube event listeners });

it fires before pretty much anything else, which lets the plugin's javascript add roundcube event listeners before they might otherwise fire (later on inside init).

this solves the problem, but i had been meaning to ask if anyone had any better solutions to this problem already (preferably that don't involve updating roundcube to include a new event trigger). does anyone have any ideas?

On 14-12-09 02:33 PM, Brendan wrote:

oh. i know what's wrong. i tweaked something in app.js to work around a problem i was having with javascript execution order. let me see if i can fix that.

if you want to use it as it, add this line to program/js/app.js: 150 $.event.trigger({'type':'rcmail_init'});

(the problem is that the rcmail object is not always available when the script starts compiling)