Hello folks,
We're proud to finally announce the release of version 0.8 with the brand new skin, codename "Larry", becoming the new default UI for Roundcube. After two preview releases and a lot of fine-tuning, the new design by http://bueroflint.com has now grown up. But to all the nostalgics out there: don't worry! The old skin still remains part of the package and will be maintained for at least one more major release.
Beside the new UI, this version also contains more bugfixes and mprovements (see ) as well as some code refactorings. Another major change since the last stable release is the updated license which is now GPL v3+ with exceptions for skin & plugins. Read more about that on http://roundcube.net/license
After lots of testing and collecting your feedback, this version is considered stable and we recommend to update all productive installations of Roundcube. Get the new version from http://roundcube.net/download
Finally, some important notes for sysadmins to deploy the new Roundcube:
- The new skin brings an entirely new look to the webmail application.
Please carefully plan a roll-out of the new version and prepare your users accordingly.
- We're getting a lot of support requests from users who are under the
impression that Roundcube is a public service such as Gmail or Hotmail. Unfortunately we cannot help these people and thus we'd like to encourage everybody to do some branding on your Roundcube installation. You can replace the logo by config (option 'skin_logo') and even more important: the new release now has an option named 'support_url' where everyone should fill in an URL to instructions how to get help for that specific installation of Roundcube.
And last but not least: our recent partnership with the Kolab Groupware project is finally showing some results. The Kolab team just published a preview release of their all-new Kolab 3.0 groupware suite including Roundcube as the new web client. Enriched with nice new plugins, Roundcube gives easy access to all relevant groupware functions. Read more about Kolab at http://kolab.org/blog/grote/2012/08/07/alpha-kolab-3.0-and-roundcube-0.8-rel...
That's definitely worth celebrating, cheers!
Thomas
Hello,
since the new release is now also available in the FreeBSD ports tree, I have updated our server with it and it's working fine.
I like the new skin! :-)
Thanks a lot, Manfred
Am 07.08.2012 22:26, schrieb Thomas Bruederli:
Hello folks,
We're proud to finally
announce the release of version 0.8 with the
brand new skin, codename
"Larry", becoming the new default UI for
Roundcube. After two preview
releases and a lot of fine-tuning, the
new design by
http://bueroflint.com [1] has now grown up. But to all the
nostalgics
out there: don't worry! The old skin still remains part of
the package
and will be maintained for at least one more major
release.
Beside the new UI, this version also contains more bugfixes and
mprovements (see ) as well as some code refactorings. Another major
change since the last stable release is the updated license which is
now GPL v3+ with exceptions for skin & plugins. Read more about that
on http://roundcube.net/license [2]
After lots of testing and
collecting your feedback, this version is
considered stable and we
recommend to update all productive
installations of Roundcube. Get the
new version from
http://roundcube.net/download [3]
Finally, some
important notes for sysadmins to deploy the new Roundcube:
- The
new skin brings an entirely new look to the webmail application.
Please carefully plan a roll-out of the new version and prepare your
users accordingly.
- We're getting a lot of support requests from
users who are under the
impression that Roundcube is a public service
such as Gmail or
Hotmail. Unfortunately we cannot help these people
and thus we'd like
to encourage everybody to do some branding on your
Roundcube
installation. You can replace the logo by config (option
'skin_logo')
and even more important: the new release now has an
option named
'support_url' where everyone should fill in an URL to
instructions how
to get help for that specific installation of
Roundcube.
And last but not least: our recent partnership with the
Kolab
Groupware project is finally showing some results. The Kolab
team just
published a preview release of their all-new Kolab 3.0
groupware suite
including Roundcube as the new web client. Enriched
with nice new
plugins, Roundcube gives easy access to all relevant
groupware
functions. Read more about Kolab at
http://kolab.org/blog/grote/2012/08/07/alpha-kolab-3.0-and-roundcube-0.8-rel... [4]
That's definitely worth celebrating, cheers!
Thomas
Roundcube Development
discussion mailing list
dev@lists.roundcube.net
http://lists.roundcube.net/mailman/listinfo/dev [5]
Links:
[1] http://bueroflint.com [2] http://roundcube.net/license [3] http://roundcube.net/download [4] http://kolab.org/blog/grote/2012/08/07/alpha-kolab-3.0-and-roundcube-0.8-rel... [5] http://lists.roundcube.net/mailman/listinfo/dev
Am 07.08.2012 22:26, schrieb Thomas Bruederli:
We're proud to finally announce the release of version 0.8 with the brand new skin, codename "Larry", becoming the new default UI for Roundcube. After two preview releases and a lot of fine-tuning, the new design by http://bueroflint.com has now grown up. But to all the nostalgics out there: don't worry! The old skin still remains part of the package and will be maintained for at least one more major release.
I personally hope that the classic skin will be maintained forever.
And not because I'm "nostalgic", but because the Larry skin does simply waste too much vertical space, which makes the whole app for me (and others) less usable.
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 11/14/2012 06:48 PM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
FWIW, from the users i've spoken with, "Larry" is universally seen as an aesthetic improvement over the "classic" skin. Thanks for all the work that went into the redesign, and kudos to the roundcube dev team for building a robustly skinnable webapp!
However, "Larry" also appears to need a much wider screen to function without horizontal scrolling. This makes "Larry" particularly problematic for mobile users. I've proposed [0] the design of a plugin that might help users switch over to the "classic" skin if their browser is using a horizontal scrollbar, but i don't have the time or the bandwidth to implement it.
I'd be happy to review and give feedback on an attempt at implementation of such a feature, if anyone wants to work on it :)
Regards,
--dkg
On 11/15/12 10:47, Daniel Kahn Gillmor wrote:
On 11/14/2012 06:48 PM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
FWIW, from the users i've spoken with, "Larry" is universally seen as an aesthetic improvement over the "classic" skin. Thanks for all the work that went into the redesign, and kudos to the roundcube dev team for building a robustly skinnable webapp!
However, "Larry" also appears to need a much wider screen to function without horizontal scrolling. This makes "Larry" particularly problematic for mobile users. I've proposed [0] the design of a plugin that might help users switch over to the "classic" skin if their browser is using a horizontal scrollbar, but i don't have the time or the bandwidth to implement it.
I'd be happy to review and give feedback on an attempt at implementation of such a feature, if anyone wants to work on it :)
Regards,
I agree. The larry skin is set to a minimum width of 1150px. I have edited skins/larry/styles.css to change that from 1150 to 1024, which suits many of our users' small laptop screens much better.
I do want to say here that RC has matured nicely over the years. In the early days there were numerous things throughout the package that I tweaked. These days this minimum width and the default behavior of the Reply-all button are about it. The out-of-the-box config and options suits us nicely.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 15.11.2012 19:53, schrieb Arne Berglund:
I do want to say here that RC has matured nicely over the years. In the early days there were numerous things throughout the package that I tweaked. These days this minimum width and the default behavior of the Reply-all button are about it.
Ah, THAT sounds interesting. So why and how did you tweak the Reply-all button (because I recently had an issue with it, that's why I'm interested)?
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 11/15/12 11:24, Michael Heydekamp wrote:
Am 15.11.2012 19:53, schrieb Arne Berglund:
I do want to say here that RC has matured nicely over the years. In the early days there were numerous things throughout the package that I tweaked. These days this minimum width and the default behavior of the Reply-all button are about it.
Ah, THAT sounds interesting. So why and how did you tweak the Reply-all button (because I recently had an issue with it, that's why I'm interested)?
Greets,
See http://trac.roundcube.net/ticket/1488734
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 15.11.2012 20:27, schrieb Arne Berglund:
On 11/15/12 11:24, Michael Heydekamp wrote:
Am 15.11.2012 19:53, schrieb Arne Berglund:
I do want to say here that RC has matured nicely over the years. In the early days there were numerous things throughout the package that I tweaked. These days this minimum width and the default behavior of the Reply-all button are about it.
Ah, THAT sounds interesting. So why and how did you tweak the Reply-all button (because I recently had an issue with it, that's why I'm interested)?
Greets,
That reminds me of my post with the subject "Does Roundcube ignore Reply-To headers?" in the users list (Nov 09, 12:16). May I ask you to read this post
- and probably the follow-ups - and check if this is the same (or at least a
very similar) issue?
TIA,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 11/15/12 12:03, Michael Heydekamp wrote:
Am 15.11.2012 20:27, schrieb Arne Berglund:
On 11/15/12 11:24, Michael Heydekamp wrote:
Am 15.11.2012 19:53, schrieb Arne Berglund:
I do want to say here that RC has matured nicely over the years. In the early days there were numerous things throughout the package that I tweaked. These days this minimum width and the default behavior of the Reply-all button are about it.
Ah, THAT sounds interesting. So why and how did you tweak the Reply-all button (because I recently had an issue with it, that's why I'm interested)?
Greets,
That reminds me of my post with the subject "Does Roundcube ignore Reply-To headers?" in the users list (Nov 09, 12:16). May I ask you to read this post
- and probably the follow-ups - and check if this is the same (or at
least a very similar) issue?
TIA,
I'm on the road today, and haven't had time to read the whole thread carefully, but at first glance it certainly looks as if it could be related.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
On 11/15/2012 07:53 PM, Arne Berglund wrote:
I agree. The larry skin is set to a minimum width of 1150px. I have edited skins/larry/styles.css to change that from 1150 to 1024, which suits many of our users' small laptop screens much better.
This is fixed in git-master.
Am 15.11.2012 19:47, schrieb Daniel Kahn Gillmor:
On 11/14/2012 06:48 PM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
FWIW, from the users i've spoken with, "Larry" is universally seen as an aesthetic improvement over the "classic" skin.
This is a matter of taste. I don't even like the "darkness" of the larry skin too much, but that's not my main point.
To me, functionality is much more important than "aesthetic improvements". I have nothing against those kind of fancy improvements, as long as it doesn't reduce functionality. I could very well live with a plain text-oriented user interface, if it does what it should do. I started my computer life with DOS 3.x in the early '80s, that may be part of an explanation...
Now we have the contradictional situation that Larry a) reduces functionality in terms of consuming a lot more screen space than the classic skin, and b) increases functionality as it is providing functions the classic skin does not (e.g. addressbook, see comment above, I'm not sure if this is the only one).
Again, I urgently apply to provide complete and the same functionality in both/all skins.
However, "Larry" also appears to need a much wider screen to function without horizontal scrolling. This makes "Larry" particularly problematic for mobile users.
I can't tell anything about this. Probably that's what you have to pay for "aesthetic improvements"? ;-)
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 11/15/2012 12:48 AM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
For me there's no reason for using contact widget in compose screen. It's useless. I will consider adding it to the classic skin when we'll have searching in this contacts list.
Am 15.11.2012 20:31, schrieb A.L.E.C:
On 11/15/2012 12:48 AM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
For me there's no reason for using contact widget in compose screen.
Not sure if I get you right. So you would apply to remove this function from the Larry skin again, because...
It's useless.
...???
Opposed to you, I'm pretty often in the situation that I need to add this or that recipient to this or that field while composing a mail. For that purpose, I used to use ;-) the compose_addressbook plugin. The pure existence of this plugin proves that there are others than me who are in need of this functionality, as Core Bosman did not create it upon my personal request.
Unfortunately, this plugin doesn't currently work with 0.9-git anymore - at least not without any problem (dead buttons).
I will consider adding it to the classic skin when we'll have searching in this contacts list.
If you will personally consider it or not: It should be a general guideline for the development of Roundcube, that all functions should be available in all skins.
And if the majority of the developers should find a functionality "useless", then it should not be availabe in either skin.
Just my 2c.
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On Thu, Nov 15, 2012 at 8:51 PM, Michael Heydekamp listuser@freexp.de wrote:
I will consider adding it to the classic skin when we'll have searching in this contacts list.
If you will personally consider it or not: It should be a general guideline for the development of Roundcube, that all functions should be available in all skins.
The general decision was to only have one skin provided by the core team. And this will definitely be the new Larry skin. We currently keep the classic skin for the nostalgics and for a smooth introduction to all your users, but we can't afford to maintain multiple skins on our own. Of course we accept volunteer work on this.
And yes, we heard your complains about wasted space in Larry, along with others saying the same, and we'll try to improve the header section anytime soon.
~Thomas
Am 15.11.2012 21:00, schrieb Thomas Bruederli:
The general decision was to only have one skin provided by the core team.
I responded to this post two days ago, but my response is still waiting for moderator confirmation since then.
Are you able to release it...?
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 15.11.2012 21:00, schrieb Thomas Bruederli:
The general decision was to only have one skin provided by the core team. And this will definitely be the new Larry skin. We currently keep the classic skin for the nostalgics and for a smooth introduction to all your users, but we can't afford to maintain multiple skins on our own.
i tried the larry-skin and i REALLY can not find anything better than in the classic skin of 0.7.x, to say it clear:
i find the new skin terrible at all and i am relly happy that currently we can use the classical one
Am 17.11.2012 20:51, schrieb Reindl Harald:
Am 15.11.2012 21:00, schrieb Thomas Bruederli:
The general decision was to only have one skin provided by the core team. And this will definitely be the new Larry skin. We currently keep the classic skin for the nostalgics and for a smooth introduction to all your users, but we can't afford to maintain multiple skins on our own.
i tried the larry-skin and i REALLY can not find anything better than in the classic skin of 0.7.x, to say it clear:
i find the new skin terrible at all and i am relly happy that currently we can use the classical one
If Classic would just provide the same functionality as Larry (which it doesn't anymore, see previous posts)...
I also do like the classic skin more, but I wouldn't call Larry "terrible", that's a matter of taste. I could very well live with Larry, if it wouldn't just waste way too much vertical space on the screen (see previous posts as well).
A small improvement of Larry is to have buttons with text. Although the text doesn't fit in all cases, at least not in German...
Am 17.11.2012 21:09, schrieb Michael Heydekamp:
Am 17.11.2012 20:51, schrieb Reindl Harald:
Am 15.11.2012 21:00, schrieb Thomas Bruederli:
The general decision was to only have one skin provided by the core team. And this will definitely be the new Larry skin. We currently keep the classic skin for the nostalgics and for a smooth introduction to all your users, but we can't afford to maintain multiple skins on our own.
i tried the larry-skin and i REALLY can not find anything better than in the classic skin of 0.7.x, to say it clear:
i find the new skin terrible at all and i am relly happy that currently we can use the classical one
If Classic would just provide the same functionality as Larry (which it doesn't anymore, see previous posts)...
which functionality outside classic skin is needed this is a webmail and should be as simple as possible
used horde over years bloadtware, terrible slow, overloaded interfaces
all users are very happy since the switch to RC 0.7 so no - they would not be happy about another UI change they do not need any fautre of a local client
if someone needs a full featured mail-client he can use a desktop client at all
Am 17.11.2012 21:12, schrieb Reindl Harald:
Am 17.11.2012 21:09, schrieb Michael Heydekamp:
If Classic would just provide the same functionality as Larry (which it doesn't anymore, see previous posts)...
which functionality outside classic skin is needed
Well, we were just discussing this issue a few messages ago: Adding recipients through browsing the addressbook upon composing a message. This is the only function I'm currently aware of that Larry does provide as a core function, but Classic does not. There may be more, I don't know.
We have been coming from Squirrel, and were really surprised that Roundcube doesn't offer that kind of function, which had been available in Squirrel for ages already. So I was glad that the plugin compose_addressbook from Cor Bosman was available. Which is not needed with Larry anymore, as I learned two days ago, as it is now a (but just Larry) core function.
While writing this, I'm just asking myself how Roundcube does handle this: As we can't know which skin our users will be using, we need to activate compose_addressbook in the config for the Classic users. Can't this create a conflict with the Larry users, as they would now have a core function AND a plugin with pretty much the same functionality...?
if someone needs a full featured mail-client he can use a desktop client at all
I'm not using a desktop client at all anymore (and I don't want to). Roundcube is (for me) already pretty full-featured, it just needs to be "a little bit" improved here and there.
Furthermore, any message from trac@roundcube.net has the following signature:
Roundcube Webmail is a browser-based multilingual IMAP client with an application-like user interface. It provides full functionality you expect from an e-mail client, including MIME support, address book, spell checking, folder manipulation and plugins.
That's what it wants to provide, "full functionality", and I second that...
But again: As you, I do prefer the Classic skin. For reasons I already mentioned.
While writing this, I'm just asking myself how Roundcube does handle this: As we can't know which skin our users will be using, we need to activate compose_addressbook in the config for the Classic users. Can't this create a conflict with the Larry users, as they would now have a core function AND a plugin with pretty much the same functionality...?
This is not a problem, as my plugin makes sure it only runs with the classic skin.
Cor
Am 17.11.2012 22:29, schrieb Cor Bosman:
While writing this, I'm just asking myself how Roundcube does handle this: As we can't know which skin our users will be using, we need to activate compose_addressbook in the config for the Classic users. Can't this create a conflict with the Larry users, as they would now have a core function AND a plugin with pretty much the same functionality...?
This is not a problem, as my plugin makes sure it only runs with the classic skin.
I was aware that it runs only with the classic skin, but I'm being curious: How does this all work internally?
I mean, does the code of the plugin get loaded first, then the skin is being checked, and then the code gets unloaded again (if Larry is the active skin)?
And what happens if the user is switching back and forth between skins during a session...?
While writing this, I'm just asking myself how Roundcube does handle this: As we can't know which skin our users will be using, we need to activate compose_addressbook in the config for the Classic users. Can't this create a conflict with the Larry users, as they would now have a core function AND a plugin with pretty much the same functionality...?
This is not a problem, as my plugin makes sure it only runs with the classic skin.
I was aware that it runs only with the classic skin, but I'm being curious: How does this all work internally?
I mean, does the code of the plugin get loaded first, then the skin is being checked, and then the code gets unloaded again (if Larry is the active skin)?
If you turn on a plugin in the main config, it gets loaded no matter what. So you decide to load it or not. Early in the loading process of roundcube it checks the list of plugins, and calls the init() function in all plugins. This happens regardless of skin. My plugin checks the user's skin inside the init function, and if it's classic it will not do anything. You can easily see this yourself in the source :)
Normally a plugin with UI elements will have it's own skin directories, where you can load files based on skin. So you can have different images, icons, css, whatever, based on the skin setting.
And what happens if the user is switching back and forth between skins during a session...?
Then after switching the skin, the user will click on compose, and see above.
Cor
On 18.11.2012 00:42, Cor Bosman wrote:
If you turn on a plugin in the main config, it gets loaded no matter what. So you decide to load it or not. Early in the loading process of roundcube it checks the list of plugins, and calls the init() function in all plugins. This happens regardless of skin. My plugin checks the user's skin inside the init function, and if it's classic it will not do anything. You can easily see this yourself in the source :)
Thanks for this explanation! But apparently I have managed to confuse even you, because this....
and if it's classic it will not do anything.
...would be a bad idea for a plugin which is supposed to run with the classic skin only.
A "not" between "it's" and "classic" would have done the job. ;)
No offense.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 2012-11-18 00:42, Cor Bosman wrote:
If you turn on a plugin in the main config, it gets loaded no matter what. So you decide to load it or not. Early in the loading process of roundcube it checks the list of plugins, and calls the init() function in all plugins. This happens regardless of skin. My plugin checks the user's skin inside the init function, and if it's classic it will not do anything. You can easily see this yourself in the source :)
I think this type of checks ( eg. rcmail->config->get('skin') == "larry") not too good. If I create some new skins based on Larry with names like 'skin1', 'skin2', etc. all skin-name-checks will fail. Is there any chance to change the 'skin' variable to an array, like this: array( 'skin_name' => 'skin1', 'skin_type' => 'larry', 'skin_desc' => 'My new larry based skin named skin1', 'skin_author' => 'Skin Author skin_author@myskin.org' )
With this modification the plugins (and the core too) can check the skin_type property.
Am 17.11.2012 22:25, schrieb Michael Heydekamp:
Well, we were just discussing this issue a few messages ago: Adding recipients through browsing the addressbook upon composing a message. This is the only function I'm currently aware of that Larry does provide as a core function, but Classic does not. There may be more, I don't know.
it is a DESIGN-BUG if a SKIN offers FEAUTRES another one does not, not a feature of larry
As we can't know which skin our users will be using, we need to activate compose_addressbook in the config for the Classic users. Can't this create a conflict with the Larry users, as they would now have a core function AND a plugin with pretty much the same functionality...?
i can
roundcubemail.spec (%install) rm -rf %{buildroot}%{roundcubedir}/installer rm -rf %{buildroot}%{roundcubedir}/skins/larry
larry was not there before, larry is not there now and that is what i provide to my users:
- the same webmail as before 0.8
- NOT another UI change in the same year
most upstream people have no clue which simple UI changes can be a problem for ordinary users!
Am 17.11.2012 22:36, schrieb Reindl Harald:
Am 17.11.2012 22:25, schrieb Michael Heydekamp:
Well, we were just discussing this issue a few messages ago: Adding recipients through browsing the addressbook upon composing a message. This is the only function I'm currently aware of that Larry does provide as a core function, but Classic does not. There may be more, I don't know.
it is a DESIGN-BUG if a SKIN offers FEAUTRES another one does not, not a feature of larry
You really don't need to convince ME, I share the same position in this respect.
But for now, it is simply a fact that a skin in Roundcube is not ONLY a skin. Larry is offering at least one feature that Classic does not, and that's a decision taken by the developers (as could have been read here). Like it or not.
i can
roundcubemail.spec (%install) rm -rf %{buildroot}%{roundcubedir}/installer rm -rf %{buildroot}%{roundcubedir}/skins/larry
larry was not there before, larry is not there now and that is what i provide to my users:
Uh, this is beyond my scope, our "real" admin would have to deal with that. But thanks for the hint anyway.
most upstream people have no clue which simple UI changes can be a problem for ordinary users!
ACK.
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 17.11.2012 23:30, schrieb Michael Heydekamp:
roundcubemail.spec (%install) rm -rf %{buildroot}%{roundcubedir}/installer rm -rf %{buildroot}%{roundcubedir}/skins/larry
larry was not there before, larry is not there now and that is what i provide to my users:
Uh, this is beyond my scope, our "real" admin would have to deal with that. But thanks for the hint anyway.
I don´t know why I shoud delete larry. We already setup our roundcube-installation (both the 0.8.x and git-master)
to use classic-skin as default.
Am 18.11.2012 09:58, schrieb Martin Wodrich:
Am 17.11.2012 23:30, schrieb Michael Heydekamp:
roundcubemail.spec (%install) rm -rf %{buildroot}%{roundcubedir}/installer rm -rf %{buildroot}%{roundcubedir}/skins/larry
larry was not there before, larry is not there now and that is what i provide to my users:
Uh, this is beyond my scope, our "real" admin would have to deal with that. But thanks for the hint anyway.
I don´t know why I shoud delete larry. We already setup our roundcube-installation (both the 0.8.x and git-master) to use classic-skin as default.
because the user can choose larry in his preferences and if yiu like to reduce support complexity you only have one skin especially since here skins seems to have software-logic contained
Am 18.11.2012 13:07, schrieb Reindl Harald:
I don´t know why I shoud delete larry. We already setup our roundcube-installation (both the 0.8.x and git-master) to use classic-skin as default.
because the user can choose larry in his preferences and if yiu like to reduce support complexity you only have one skin especially since here skins seems to have software-logic contained
We don´t have an support problem with larry-skin.
Am 25.11.2012 10:03, schrieb Martin Wodrich:
Am 18.11.2012 13:07, schrieb Reindl Harald:
I don´t know why I shoud delete larry. We already setup our roundcube-installation (both the 0.8.x and git-master) to use classic-skin as default.
because the user can choose larry in his preferences and if yiu like to reduce support complexity you only have one skin especially since here skins seems to have software-logic contained
We don´t have an support problem with larry-skin
that is nice for you, i know my customers they sometimes take the phone when a single button is labeled "upload images" instead "save" while the other one is labeled "cancel"
that is how endusers are doing and devleiopers with changes for the sake of the change which happens often in the free software world do not understand this
we switched a few months ago from horde/imp to roundcube we should not change the complete layout twice a year
additionally i personally find the skin ugly and it does not work with transparent logos, it is wasting space and so on
classic is
- beautiful
- works fine with logos
- does not waste space
so i see no single reason for larry
Am 25.11.2012 10:03, schrieb Martin Wodrich:
Am 18.11.2012 13:07, schrieb Reindl Harald:
I don´t know why I shoud delete larry. We already setup our roundcube-installation (both the 0.8.x and git-master) to use classic-skin as default.
because the user can choose larry in his preferences and if yiu like to reduce support complexity you only have one skin especially since here skins seems to have software-logic contained
We don´t have an support problem with larry-skin.
This is true of course, but well, to be honest: We also don't have them because a) our default webmailer is still Squirrel (hopefully not for a long time anymore), b) therefore there are - besides you and me - currently only two more users working with Roundcube yet, and c) our user base is not THAT large anyway. ;-) Harald seems to be in quite a different situation, it sounds to me as if he would have tens/hundreds/thousands of users.
Am 25.11.2012 12:35, schrieb Reindl Harald:
classic is
- beautiful
- works fine with logos
- does not waste space
so i see no single reason for larry
I second that.
And although the logo issue is not one of the most important ones, it IS an issue (I recently mentioned that 'by the way' in one of my previous posts as well, and also attached a screenshot). Something that worked before, doesn't work now anymore - at least not in the same way (logo is being truncated at the bottom).
Am 25.11.2012 21:08, schrieb Michael Heydekamp:
We don´t have an support problem with larry-skin.
This is true of course, but well, to be honest: We also don't have them because a) our default webmailer is still Squirrel (hopefully not for a long time anymore), b) therefore there are - besides you and me - currently only two more users working with Roundcube yet, and c) our user base is not THAT large anyway. ;-) Harald seems to be in quite a different situation, it sounds to me as if he would have tens/hundreds/thousands of users
in total there are some hundret users
since most of them are business-users webmial is not that important but these days you need to provide it anyway and so it should have as less changes and support calls as possible
On Sunday 25 November 2012 21:08:22 Michael Heydekamp wrote:
Am 25.11.2012 12:35, schrieb Reindl Harald:
classic is
- beautiful
- works fine with logos
- does not waste space
so i see no single reason for larry
I second that.
As already pointed out in this thread before, you are free to make use of the freedoms offered to you by Free Software and maintain the classic skin yourself.
The other option is to pay somebody to do it. Since both of you seem to be doing business with Roundcube, this sounds like the logical thing to do. You can not make money with other people's work and then expect them to fulfill all your wishes at no cost.
Disclosure: I work for Kolab Systems that happens to offer support for Roundcube.
Regards, Torsten
Am 26.11.2012 11:55, schrieb Torsten Grote:
On Sunday 25 November 2012 21:08:22 Michael Heydekamp wrote:
Am 25.11.2012 12:35, schrieb Reindl Harald:
classic is
- beautiful
- works fine with logos
- does not waste space
so i see no single reason for larry
I second that.
As already pointed out in this thread before, you are free to make use of the freedoms offered to you by Free Software and maintain the classic skin yourself.
Which we're not able to, due to lack of PHP skills. As already pointed out in this list before. ;-)
The other option is to pay somebody to do it. Since both of you seem to be doing business with Roundcube, this sounds like the logical thing to do.
I have no idea where your impression is coming from, but you're totally wrong: I can't speak for Harald Reindl, but we at freexp.de are not doing any business at all. FreeXP is/was a freeware and open source MUA for DOS 16bit which is not developed anymore.
Nonetheless we are still running the server at our own cost as a sort of hobby, and are hosting a few domains for friends of us for free (e.g. www.akel.de). It appears that we are real bad business people...
You can not make money with other people's work and then expect them to fulfill all your wishes at no cost.
Bold statement, indeed...
Furthermore, I recently donated 200 USD to the Roundcube project out of my private pocket. Not because I would expect anything, but because I just wanted to support the project.
You should first gather some information, BEFORE you misinterpret things and publicly spread false impressions.
Disclosure: I work for Kolab Systems that happens to offer support for Roundcube.
Advertisement noted. Congrats, you're a far better business man than us.
Above all, I will keep on expressing my opinion about any issue whenever I wish - if you don't mind.
Hi Michael,
On Monday 26 November 2012 18:17:53 Michael Heydekamp wrote:
I have no idea where your impression is coming from, but you're totally wrong: I can't speak for Harald Reindl, but we at freexp.de are not doing any business at all.
Thanks for the clarification. At least Harald was talking about customers. I assumed the same in your case. Sorry for that!
You can also take what I said as a general comment about businesses and Free Software even if it doesn't apply to you personally.
You can not make money with other people's work and then expect them to fulfill all your wishes at no cost.
Furthermore, I recently donated 200 USD to the Roundcube project out of my private pocket. Not because I would expect anything, but because I just wanted to support the project.
I'm happy to see that you contributed financially to the Roundcube initiative. Thanks for that.
Another possibility for you would be to devote some energies in finding people that would maintain the classic skin for no or little money or people that feel as you feel and combine their resources to make this happen. Maybe even a kickstarter project.
Regards, Torsten
Am 25.11.2012 21:08, schrieb Michael Heydekamp:
We don´t have an support problem with larry-skin.
This is true of course, but well, to be honest: We also don't have them because a) our default webmailer is still Squirrel (hopefully not for a long time anymore), b) therefore there are - besides you and me - currently only two more users working with Roundcube yet, and c) our user base is not THAT large anyway. ;-)
I thing reason c) is the most important reason for us.
Harald seems to be in quite a different situation, it sounds to me as if he would have tens/hundreds/thousands of users.
I thing so, too.
Am 27.11.2012 19:10, schrieb Martin Wodrich:
Harald seems to be in quite a different situation, it sounds to me as if he would have tens/hundreds/thousands of users.
I thing so, too
that is correct but webmail is not a very important business since our core business is cms-development / advertisment und because we are a really small company my day has only 24 hours which are 24 hours to less each day :-(
Time for a reality check. Roundcube is an open-source project, developed by a group of unpaid volunteers. This group has done an outstanding job of developing the best web-based email client available. But they are only human, and their solutions and preferences will not always please everyone.
From that point of view, the additional time and effort required to maintain two entirely different skins would seriously slow the development process, and I support their plan to pick one and concentrate only on that. (I should say here that my organization has made larry the default, and we are not allowing users to select the classic skin, either. Saves us headaches on support if all users are on the same skin.)
And of course, if you don't like something about it, you can always use the existing package as a base, and modify it to suit your needs.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 18.11.2012 00:01, schrieb Arne Berglund:
Time for a reality check. Roundcube is an open-source project, developed by a group of unpaid volunteers. This group has done an outstanding job of developing the best web-based email client available. But they are only human, and their solutions and preferences will not always please everyone.
yes, but opensource does not forbid to say my opinion as clear as i can do
From that point of view, the additional time and effort required to maintain two entirely different skins would seriously slow the development process
from my point of view stay at the classical skin and polish it would have saved a lot of time as many big changes in many projects have only zero benefit compared with the needed work and impact on the userbase, but hey as long it doe snot end like GNOME3 all is fine
And of course, if you don't like something about it, you can always use the existing package as a base, and modify it to suit your needs
of course i could also shoot me in my knees
On 11/15/2012 08:51 PM, Michael Heydekamp wrote:
Opposed to you, I'm pretty often in the situation that I need to add this or that recipient to this or that field while composing a mail. For that purpose, I used to use ;-) the compose_addressbook plugin. The pure existence of this plugin proves that there are others than me who are in need of this functionality, as Core Bosman did not create it upon my personal request.
Tell me what in the contacts list is better and cannot be done using auto-completion feature?
If you will personally consider it or not: It should be a general guideline for the development of Roundcube, that all functions should be available in all skins.
Yes, but someone need to do this. I don't like to work on features that I don't like or even think they are useless. If you create a patch adding this into classic skin we'll consider applying it.
And if the majority of the developers should find a functionality "useless", then it should not be availabe in either skin.
The feature is there because I'm not a majority ;)
On Thu, Nov 15, 2012 at 9:00 PM, A.L.E.C alec@alec.pl wrote:
On 11/15/2012 08:51 PM, Michael Heydekamp wrote:
Opposed to you, I'm pretty often in the situation that I need to add this or that recipient to this or that field while composing a mail. For that purpose, I used to use ;-) the compose_addressbook plugin. The pure existence of this plugin proves that there are others than me who are in need of this functionality, as Core Bosman did not create it upon my personal request.
Tell me what in the contacts list is better and cannot be done using auto-completion feature?
You can *browse* your contacts. This is something you can't with the autocompletion simply because the limited number of results displayed. But auto-completion lets you search your contacts, thats why I considered the search feature within the address book widget less important. But that doesn't mean it will never appear there.
~Thomas
You can *browse* your contacts. This is something you can't with the autocompletion simply because the limited number of results displayed. But auto-completion lets you search your contacts, thats why I considered the search feature within the address book widget less important. But that doesn't mean it will never appear there.
I added a search function in my addressbook plugin on specific request from quite a few others out there with company LDAP addressbook consisting of hundreds or even thousands of contacts. Apparently without a search function it becomes useless :)
If I remember correctly, some LDAP systems dont even allow a full listing but only do search, but im not positive.
Cor
Cor Bosman wrote:
You can *browse* your contacts. This is something you can't with the autocompletion simply because the limited number of results displayed. But auto-completion lets you search your contacts, thats why I considered the search feature within the address book widget less important. But that doesn't mean it will never appear there.
I added a search function in my addressbook plugin on specific request from quite a few others out there with company LDAP addressbook consisting of hundreds or even thousands of contacts. Apparently without a search function it becomes useless :)
I fully accept this being a desirable feature and is therefore is on our roadmap: http://trac.roundcube.net/ticket/1488381
~Thomas
Am 15.11.2012 21:00, schrieb A.L.E.C:
On 11/15/2012 08:51 PM, Michael Heydekamp wrote:
Opposed to you, I'm pretty often in the situation that I need to add this or that recipient to this or that field while composing a mail. For that purpose, I used to use ;-) the compose_addressbook plugin. The pure existence of this plugin proves that there are others than me who are in need of this functionality, as Core Bosman did not create it upon my personal request.
Tell me what in the contacts list is better and cannot be done using auto-completion feature?
This is an answer related to real life: My brain simply can't always recall all people in my adressbook who might be interested in (or who are even in need of) a particular mail I'm currently composing.
The auto-completion procedure presumes that you already KNOW from the top of your head who you want to add to the recipient list. In real life, this is not (always) the case.
So I'm walking through the addressbook and can pick this and that recipient, because simply SEEING a recipient might remind me that it is one of the ones that needs to be added.
Understood...?
If you will personally consider it or not: It should be a general guideline for the development of Roundcube, that all functions should be available in all skins.
Yes, but someone need to do this.
Sure. Presumably one of the developers. I did not ask you personally to do that.
I don't like to work on features that I don't like or even think they are useless. If you create a patch adding this into classic skin we'll consider applying it.
I'm afraid my Borland Pascal skills won't be of any help here. ;)
And if the majority of the developers should find a functionality "useless", then it should not be availabe in either skin.
The feature is there because I'm not a majority ;)
Right. But then the majority should make sure to implement it in both/all skins.
But see also next post (which I still need to compose, so it may take a while from now on).
On Nov 15, 2012, at 8:31 PM, "A.L.E.C" alec@alec.pl wrote:
On 11/15/2012 12:48 AM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
For me there's no reason for using contact widget in compose screen. It's useless.
I really dont think you can make such bold statements. I made the compose_addressbook plugin not because I like writing and maintaining plugins, but because i got tons of questions and complaints from actual users about how to add contacts from their addressbook in the compose screen. It was just not obvious that starting to type something would actually search in your addressbook. If you have 100,000 customers, if only 10% ask you this, is starts to become _really_ annoying.
Maybe some of them would have been fine with just typing, but it turns out a lot of people dont really want that. They want to see what they have. Maybe they cant quite remember the person they're looking for, maybe they type really slow, maybe they're elderly and dont remember how things work very well. A visible, clickable, item on the screen helps. Having a clickable addressbook in your mail client is pretty much a standard item, for a reason.
Having said that, i dont think you should backport it to classic. I dont agree with Michael that classic should remain to be supported. It's hard enough supporting 1 skin for you guys (let alone plugin developers!). And this is open source, so if someone wants to maintain the classic theme, no one is stopping them. And besides that, my plugin functionally works fine for classic so why put time in that at all?
It's good to hear you guys might be looking at adjusting the vertical and horizontal spacing of the larry theme. It is pretty much the only recurring complaint people seem to have about larry.
Cor
Am 15.11.2012 21:23, schrieb Cor Bosman:
On Nov 15, 2012, at 8:31 PM, "A.L.E.C" alec@alec.pl wrote:
On 11/15/2012 12:48 AM, Michael Heydekamp wrote:
Therefore I herewith apply for that both skins share the same core functionality. This is currently not the case, as I had to learn yesterday (using the addressbook during composing).
For me there's no reason for using contact widget in compose screen. It's useless.
I really dont think you can make such bold statements. I made the compose_addressbook plugin not because I like writing and maintaining plugins, but because i got tons of questions and complaints from actual users about how to add contacts from their addressbook in the compose screen. It was just not obvious that starting to type something would actually search in your addressbook. If you have 100,000 customers, if only 10% ask you this, is starts to become _really_ annoying.
Maybe some of them would have been fine with just typing, but it turns out a lot of people dont really want that. They want to see what they have. Maybe they cant quite remember the person they're looking for, maybe they type really slow, maybe they're elderly and dont remember how things
A visible, clickable, item on the screen helps. Having a clickable addressbook in your mail client is pretty much a standard item, for a reason.
I totally agree!
Having said that, i dont think you should backport it to classic. I dont agree with Michael that classic should remain to be supported.
Well, it has been said:
Am 07.08.2012 22:26, schrieb Thomas Bruederli:
We're proud to finally announce the release of version 0.8 with the brand new skin, codename "Larry", becoming the new default UI for Roundcube. After two preview releases and a lot of fine-tuning, the new design by http://bueroflint.com has now grown up. But to all the nostalgics out there: don't worry! The old skin still remains part of the package and will be maintained for at least one more major release.
"At least"! And if it will be maintained, that can only mean to me "maintained".
Just being (still) existent without having the same functionality, is different to being "maintained".
And besides that, my plugin functionally works fine for classic so why put time in that at all?
Well, it doesn't, as you should be aware. At least not with 0.9-git. Did you forget what we are still discussing at length (dead buttons and the like)?
It's good to hear you guys might be looking at adjusting the vertical and horizontal spacing of the larry theme.
Yeah, bit I must have missed any word about vertical spacing. Where did you read that...?
Regards,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
And besides that, my plugin functionally works fine for classic so why put time in that at all?
Well, it doesn't, as you should be aware. At least not with 0.9-git. Did you forget what we are still discussing at length (dead buttons and the like)?
No, I havent forgotten but Im not too worried about it. 0.9 is currently bleeding edge, so if you insist on using it, expect problems. I'll see if Thomas understands why the busy boolean remains true, as thats the reason the buttons stop working. If he doesnt, i'll eventually get around to digging a bit deeper.
It's good to hear you guys might be looking at adjusting the vertical and horizontal spacing of the larry theme.
Yeah, bit I must have missed any word about vertical spacing. Where did you read that...?
Thomas said: ..."we'll try to improve the header section anytime soon.".. Maybe I misunderstood.
Cor
Am 15.11.2012 22:00, schrieb Cor Bosman:
And besides that, my plugin functionally works fine for classic so why put time in that at all?
Well, it doesn't, as you should be aware. At least not with 0.9-git. Did you forget what we are still discussing at length (dead buttons and the like)?
No, I havent forgotten but Im not too worried about it. 0.9 is currently bleeding edge, so if you insist on using it, expect problems.
I'm not "insisting" using it. Instead I'm testing it thoroughly from a user perspective as my personal production environment on a voluntary basis just for one reason: To recognize and report such problems before they'll make their way into a 0.9-release.
I can't see anything wrong with that, especially as intensive testing didn't seem to be one of the strongest parts of the Roundcube development so far.
And that compose_addressbook doesn't currently work with 0.9-master, is a pure fact. I'm just reporting this, but I don't blame anybody for it. Nonetheless it should be resolved soon, and from my point of view Roundcube is the problem here (rather than compose_addressbook).
And apart from that, I still think that both skins should share exactly the same core functions. And if they don't, it should at least clearly be stated which functions are missing in which skin (the best place being where the user can select the skin). I simply wasn't aware until two days ago that Larry has an addressbook in the compose skin.
It's good to hear you guys might be looking at adjusting the vertical and horizontal spacing of the larry theme.
Yeah, bit I must have missed any word about vertical spacing. Where did you read that...?
Thomas said: ..."we'll try to improve the header section anytime soon.".. Maybe I misunderstood.
I'm more worrying about the overall vertical spacing of Larry, not only in the header section. I sent a post to this list in this regard two days ago, but it is still waiting for moderator confirmation.
Greets,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
I can't see anything wrong with that, especially as intensive testing didn't seem to be one of the strongest parts of the Roundcube development so far.
And that compose_addressbook doesn't currently work with 0.9-master, is a pure fact. I'm just reporting this, but I don't blame anybody for it.
Thank you for reporting it. Im sure it'll be fixed at some point before 0.9 stable. Either by me or by an rc developer if it turns out to be an rc issue. I'll let you know.
Cor
-
A.L.E.C -
Arne Berglund -
Cor Bosman -
Daniel Kahn Gillmor -
Manfred Usselmann -
Martin Wodrich -
Michael Heydekamp
-
Reindl Harald -
taki -
Thomas Bruederli -
Torsten Grote