Hi,
I've noticed that when using an ldap address book, the addresses are not listed in the address book, except when doing a search. This looks a little like a bug to me, because the list_records function is called, but will never return anything.
I've attached a minor patch that sets the default filter, when list_records is called. This means that when $this->_exec_search is called, it's will return a result.
I hope this patch might help.
Regards Glen Ogilvie
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/mm/q8/HsaHBnxn/rcube_ldap_filter.patch Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
Glen Ogilvie wrote:
Hi,
I've noticed that when using an ldap address book, the addresses are not listed in the address book, except when doing a search. This looks a little like a bug to me, because the list_records function is called, but will never return anything.
This is not a bug but intended behavior. Most (public) LDAP servers have very long response times or do not even allow a complete listing.
I've attached a minor patch that sets the default filter, when list_records is called. This means that when $this->_exec_search is called, it's will return a result.
This is a good idea, Thanks!
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
First Topic:
I noticed my 25x25 skins/default/images/buttons/mail.gif is corrupted. It's been that way for a long time but I actually looked at it tonight in an external viewer to verify.
Anyone else have this problem? I tried grabbing the latest file from CVS and it has the same problem.
Why are we even using GIF for the top right header buttons. Couldn't we use PNG?
These GIFs appear to be referenced in default/common.css
Let's ditch them for PNG!
In the meantime if someone with CVS access wants to commit this non-corrupt image: http://webmail.kaatman.com/skins/default/images/buttons/mail.gif
Second Topic:
With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Anyone else notice this? _______________________________________________ List info: http://lists.roundcube.net/dev/
Matt Kaatman wrote:
First Topic:
I noticed my 25x25 skins/default/images/buttons/mail.gif is corrupted. It's been that way for a long time but I actually looked at it tonight in an external viewer to verify.
my r675 trunk checkout has the correct icon. so does r690 which i checked right now.
Why are we even using GIF for the top right header buttons. Couldn't we use PNG?
These GIFs appear to be referenced in default/common.css
Let's ditch them for PNG!
why do you think we should use png? just because gif is bad and png is not? please elaborate.
kind regards, raoul bhatia
ps: please use one email per problem/request and use meaningful subjects. this way one can track conversations more easily. thank you! :)
Matt Kaatman wrote:
With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Anyone else notice this?
yes i noticed this too. don't know why this was introduced thou. can anyone explain this behavour?
kind regards, raoul bhatia
2007/8/16, Matt Kaatman roundcube-dev@matt.kaatman.com:
Why are we even using GIF for the top right header buttons. Couldn't we use PNG?
These icons are referenced as background-images in CSS. Older IE browsers are not able to correctly display the alpha channel of background PNGs. See folder list icons.
Let's ditch them for PNG!
Even PNG images are not safe from being corrupted on SVN checkout...
With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Must be broken since r667: http://trac.roundcube.net/trac.cgi/changeset/667#file3 The check for list.selection.length>0 is gone. Rich, please fix!
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On 8/16/07, Raoul Bhatia [IPAX] r.bhatia@ipax.at wrote:
Matt Kaatman wrote:
(...) Why are we even using GIF for the top right header buttons. Couldn't we use PNG?
These GIFs appear to be referenced in default/common.css
Let's ditch them for PNG!
why do you think we should use png? just because gif is bad and png is not? please elaborate.
With Internet Explorer behaving so weird when it comes to PNGs I see no reason to use them (at all). After all IE is still the most used browser.
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On 8/16/07, Thomas Bruederli roundcube@gmail.com wrote:
2007/8/16, Matt Kaatman roundcube-dev@matt.kaatman.com:
(...) With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Must be broken since r667: http://trac.roundcube.net/trac.cgi/changeset/667#file3 The check for list.selection.length>0 is gone. Rich, please fix!
Thomas,
I still suspect you really do know the entire source by heart. :)
@Rich: If you make a fix, please send me the patch as well.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
So do these two images look the same to you?
http://webmail.kaatman.com/skins/default/images/buttons/mail.gif http://webmail.kaatman.com/skins/default/images/buttons/mail2.gif
mail.gif (833 bytes) is the one I get from svn. mail2.gif is one I resized and converted from the PNG.
The first one is most certainly corrupted in firefox, ie and irfanview on windows and also firefox on ubuntu. I've deleted it and updated from svn many times.
Matt
Raoul Bhatia [IPAX] wrote:
Matt Kaatman wrote:
First Topic:
I noticed my 25x25 skins/default/images/buttons/mail.gif is corrupted. It's been that way for a long time but I actually looked at it tonight in an external viewer to verify.
my r675 trunk checkout has the correct icon. so does r690 which i checked right now.
Why are we even using GIF for the top right header buttons. Couldn't we use PNG?
These GIFs appear to be referenced in default/common.css
Let's ditch them for PNG!
why do you think we should use png? just because gif is bad and png is not? please elaborate.
kind regards, raoul bhatia
ps: please use one email per problem/request and use meaningful subjects. this way one can track conversations more easily. thank you! :)
List info: http://lists.roundcube.net/dev/
Matt Kaatman a écrit :
So do these two images look the same to you?
http://webmail.kaatman.com/skins/default/images/buttons/mail.gif http://webmail.kaatman.com/skins/default/images/buttons/mail2.gif
mail.gif (833 bytes) is the one I get from svn. mail2.gif is one I resized and converted from the PNG.
The first one is most certainly corrupted in firefox, ie and irfanview on windows and also firefox on ubuntu. I've deleted it and updated from svn many times.
I have the same error, when I do a checkout from windows. Checkout from linux everything has always been correct. Maybe the type is not the good one (ie binary/text, which would explain why I got an error on windows and not on linux ?) I solved the problem by putting the correct icon by hand, but if I delete it the incorrect icon does appear again.
Aurélien
Matt Kaatman wrote:
So do these two images look the same to you?
http://webmail.kaatman.com/skins/default/images/buttons/mail.gif http://webmail.kaatman.com/skins/default/images/buttons/mail2.gif
mail.gif (833 bytes) is the one I get from svn. mail2.gif is one I resized and converted from the PNG.
The first one is most certainly corrupted in firefox, ie and irfanview on windows and also firefox on ubuntu. I've deleted it and updated from svn many times.
The one that I have is 831 bytes, and that's the one I pull from SVN, and it works fine in FireFox 2.0.0.6, IE 7, and Opera 9.23.
# ls -l mail.gif -rw-r--r-- 1 www www 831 May 22 09:37 mail.gif # svn st -u Status against revision: 692 # rm mail.gif # svn up Restored 'mail.gif' At revision 692. # ls -l mail.gif -rw-r--r-- 1 root www 831 Aug 16 09:44 mail.gif
I attached my copy of mail.gif to this message. This makes me wonder if it isn't the subversion client that is corrupting it on checkout somehow.
Here is some more info, which might help.
# svn info mail.gif Path: mail.gif Name: mail.gif URL: https://svn.roundcube.net/trunk/roundcubemail/skins/default/images/buttons/m... Repository Root: https://svn.roundcube.net Repository UUID: 208e9e7b-5314-0410-a742-e7e81cd9613c Revision: 692 Node Kind: file Schedule: normal Last Changed Author: roundcube Last Changed Rev: 49 Last Changed Date: 2005-10-20 17:20:26 -0500 (Thu, 20 Oct 2005) Text Last Updated: 2007-08-16 09:44:30 -0400 (Thu, 16 Aug 2007) Checksum: bcb88ad554fb314132025d2754c82126
Jim
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/mm/H7/Zk9oOXRb/mail.gif Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/
Matt Kaatman wrote:
So do these two images look the same to you?
http://webmail.kaatman.com/skins/default/images/buttons/mail.gif http://webmail.kaatman.com/skins/default/images/buttons/mail2.gif
mail.gif (833 bytes) is the one I get from svn. mail2.gif is one I resized and converted from the PNG.
The file is actually fine but there were wrong properties set for it in SVN. This may cause your SVN client to check it out as text and not as a binary file.
The first one is most certainly corrupted in firefox, ie and irfanview on windows and also firefox on ubuntu. I've deleted it and updated from svn many times.
I've now corrected this in revision 693 (http://trac.roundcube.net/trac.cgi/changeset/693)
Just remove your local copy of the file and type "svn up"
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
With Internet Explorer behaving so weird when it comes to PNGs I see no reason to use them (at all). After all IE is still the most used browser.
Well, it depends. It's not as easy as "GIF is bad, PNG is good".
GIF: -) 256 colors only -) small in size -) transparency works
PNG: -) true color -) larger compared to GIF -) great transparency support, but broken in IE
Both have lossless compression (not like JPEG).
So it depends on what you want to do with your graphic and if you need true color or not. If you don't use transparency it's fine to use PNG within IE, if you don't need true color use GIF because the files are smaller.
Best regards, Mike
png transparency only fails in IE6 and below, not IE7
you can do larger than 256 colour gifs, but they are not lossless
size is not really comparable because it depends on how many colours are
being used - png uses selectable palette
so my advice is use what is required...
i generally use png for images that don't have a large palette (this is
where jpg is appropriate)
i use gifs where i need transparency, otherwise png or jpg as above
the best way to see whats best for non-transparent images is create .gif
and .png and see what is smaller..
On Fri, 17 Aug 2007 02:30:19 +1000, Michael Baierl mail@mbaierl.com
wrote:
till wrote:
With Internet Explorer behaving so weird when it comes to PNGs I see no reason to use them (at all). After all IE is still the most used browser.
Well, it depends. It's not as easy as "GIF is bad, PNG is good".
GIF: -) 256 colors only -) small in size -) transparency works
PNG: -) true color -) larger compared to GIF -) great transparency support, but broken in IE
Both have lossless compression (not like JPEG).
So it depends on what you want to do with your graphic and if you need
true color or not. If you don't use transparency it's fine to use PNG
within IE, if you don't need true color use GIF because the files are
smaller.Best regards, Mike
Chris Fordham wrote:
the best way to see whats best for non-transparent images is create .gif and .png and see what is smaller..
good idea, thou i would not agree to always use the smaller version (either .gif, .png or .jpg) as we would possibly end up having 3 gifs, 4 pngs and 2 jpgs for our icons, which could get a little confusing.
kind regards, raoul bhatia
Im not sure how a file extension can be confusing, but if you say so!
On Fri, 17 Aug 2007 16:41:06 +1000, Raoul Bhatia [IPAX] r.bhatia@ipax.at
wrote:
Chris Fordham wrote:
the best way to see whats best for non-transparent images is create
.gif and .png and see what is smaller..good idea, thou i would not agree to always use the smaller version (either .gif, .png or .jpg) as we would possibly end up having 3 gifs, 4 pngs and 2 jpgs for our icons, which could get a little confusing.
kind regards, raoul bhatia
Hi,
On 8/17/07, Chris Fordham chris@xhost.com.au wrote:
png transparency only fails in IE6 and below, not IE7 you can do larger than 256 colour gifs, but they are not lossless size is not really comparable because it depends on how many colours are being used - png uses selectable palette
No, it is still broken in IE7. At least it doesn't work a 100%. Which renders using PNGs useless for me.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
It is so easy to correct broken png issues in IE 5.5 and up. If we take for granted that RC will only work in newer browsers anyways (I haven't even tried RC in IE5 or NS6 for instance), then what's the issue with including the little javascript function below to fix it once and for all?
[code] function correctPNG() { for(var i=0; i<document.images.length; i++) { var img = document.images[i] var imgName = img.src.toUpperCase() if (imgName.substring(imgName.length-3, imgName.length) == "PNG") { var imgID = (img.id) ? "id='" + img.id + "' " : "" var imgClass = (img.className) ? "class='" + img.className + "' " : "" var imgTitle = (img.title) ? "title='" + img.title + "' " : "title='" + img.alt + "' " var imgStyle = "display:inline-block;" + img.style.cssText if (img.align == "left") imgStyle = "float:left;" + imgStyle if (img.align == "right") imgStyle = "float:right;" + imgStyle if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle var strNewHTML = "<span " + imgID + imgClass + imgTitle + " style="" + "width:" + img.width + "px; height:" + img.height + "px;" + imgStyle + ";" + "filter:progid:DXImageTransform.Microsoft.AlphaImageLoader" + "(src='" + img.src + "', sizingMethod='scale');"></span>" img.outerHTML = strNewHTML i = i-1 } } } window.attachEvent("onload", correctPNG); [/code]
This will, as far as I've been able to tell, correct transparency issues in IE every single time.
Michiel
On Fri, 17 Aug 2007 10:26:41 +0200, till klimpong@gmail.com wrote:
Hi,
On 8/17/07, Chris Fordham chris@xhost.com.au wrote:
png transparency only fails in IE6 and below, not IE7 you can do larger than 256 colour gifs, but they are not lossless size is not really comparable because it depends on how many colours are being used - png uses selectable palette
No, it is still broken in IE7. At least it doesn't work a 100%. Which renders using PNGs useless for me.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Chris Fordham wrote:
Im not sure how a file extension can be confusing, but if you say so!
It is, it is. It especially introduces bugs as the developers have to think about every single file. If all icons are using the same it's much cleaner.
Mike _______________________________________________ List info: http://lists.roundcube.net/dev/
Michael Baierl wrote:
Chris Fordham wrote:
Im not sure how a file extension can be confusing, but if you say so!
It is, it is. It especially introduces bugs as the developers have to think about every single file. If all icons are using the same it's much cleaner.
thank you, i did not know how to explain this ;)
kind regards, raoul bhatia
Hi Michiel!
On 8/17/07, Michiel Oosterling michiel@newforms.nl wrote:
It is so easy to correct broken png issues in IE 5.5 and up. If we take for granted that RC will only work in newer browsers anyways (I haven't even tried RC in IE5 or NS6 for instance), then what's the issue with including the little javascript function below to fix it once and for all?
Because it's just wrong to use JavaScript to fix a graphical issue.
As I stated, there are *still* problems with PNG in IE7. Especially when layers and transparency are involved, sometimes PNGs are not displayed at all.
To me this makes it broken.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Hi all,
I think it's browser's supplier who has to fix such issues, not developers using JavaScript to "patch" the issue. But until developers do try to comply with IE's famous "features" like the PNG issues, that is not gonna happen.
Regards, Doichin
till написа:
Hi Michiel!
On 8/17/07, Michiel Oosterling michiel@newforms.nl wrote:
It is so easy to correct broken png issues in IE 5.5 and up. If we take for granted that RC will only work in newer browsers anyways (I haven't even tried RC in IE5 or NS6 for instance), then what's the issue with including the little javascript function below to fix it once and for all?
Because it's just wrong to use JavaScript to fix a graphical issue.
As I stated, there are *still* problems with PNG in IE7. Especially when layers and transparency are involved, sometimes PNGs are not displayed at all.
To me this makes it broken.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
Technically he's fixing an IE issue with javascript.
Really though, I started a monster discussion about a minor issue of the file not being set to binary in svn.
oops!
On Fri, 17 Aug 2007 19:42:11 +0200, till klimpong@gmail.com wrote:
Hi Michiel!
On 8/17/07, Michiel Oosterling michiel@newforms.nl wrote:
It is so easy to correct broken png issues in IE 5.5 and up. If we take for granted that RC will only work in newer browsers anyways
(I
haven't even tried RC in IE5 or NS6 for instance), then what's the issue with including the little javascript function below to fix it once and
for
all?
Because it's just wrong to use JavaScript to fix a graphical issue.
As I stated, there are *still* problems with PNG in IE7. Especially when layers and transparency are involved, sometimes PNGs are not displayed at all.
To me this makes it broken.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
On 8/17/07, Matt Kaatman roundcube-dev@matt.kaatman.com wrote:
Technically he's fixing an IE issue with javascript.
Really though, I started a monster discussion about a minor issue of the file not being set to binary in svn.
Discussions are always healthy. ;-))
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I've never had to 'think about every single file'? What is this thinking ? And yeah, this does not introduce bugs...
If your concept is that they would accidently put in the wrong file
extension, then they didn't confirm the filename to begin with and even so
typographical/syntactical errors are a common thing to debug in
programming. Its called human error.
On Fri, 17 Aug 2007 23:46:27 +1000, Michael Baierl mail@mbaierl.com
wrote:
Chris Fordham wrote:
Im not sure how a file extension can be confusing, but if you say so!
It is, it is. It especially introduces bugs as the developers have to
think about every single file. If all icons are using the same it's much
cleaner.Mike _______________________________________________ List info: http://lists.roundcube.net/dev/
Hey Chris!
On 8/19/07, Chris Fordham chris@xhost.com.au wrote:
I've never had to 'think about every single file'? What is this thinking ? And yeah, this does not introduce bugs...
(Please don't TOFU (0), it makes it all harder to read and follow!)
What Michael is getting at is that when you stick to one technology it's easier to handle it. So what I have been saying numerous times now is, that PNG is broken in IE6 AND IE7 (the #1 browser, even though we don't like it). I just had a case on another project where a hidden layer made PNGs on a page disappear - oh yeah, and it worked with right away GIF.
So for myself the decision is rather easy when it comes to PNG vs GIF. Whatever introduces more problems than it fixes is not worth to be used. Not too many people have time fix browser-specific bugs, so why not move away from this completely?
In anyway, everyone is welcome to replace the images in his local install. :)
(...) Its called human error.
PICNIC (1), or human error is probably the #1 error in programming? :)
Cheers, Till
0, http://en.wikipedia.org/wiki/TOFU 1, http://en.wikipedia.org/wiki/PICNIC _______________________________________________ List info: http://lists.roundcube.net/dev/
On Sun, 19 Aug 2007 23:29:00 +1000, till klimpong@gmail.com wrote:
Hey Chris!
On 8/19/07, Chris Fordham chris@xhost.com.au wrote:
I've never had to 'think about every single file'? What is this
thinking ? And yeah, this does not introduce bugs...(Please don't TOFU (0), it makes it all harder to read and follow!) What Michael is getting at is that when you stick to one technology it's easier to handle it. So what I have been saying numerous times now is, that PNG is broken in IE6 AND IE7 (the #1 browser, even though we don't like it). I just had a case on another project where a hidden layer made PNGs on a page disappear - oh yeah, and it worked with right away GIF.
till, i know about the support, and its not completely broken like you
claim, thus my original argument of using what is optimally the best image
type based on number of colours in the palette, if transparency was
required and the effective image size. There is no need to repeat
yourself. I read it the first time. Perhaps you didn't read my email which
stated that pngs that are not transparent work fine in IE. I am a
client-side developer and create sites for a living. im well aware of the
limitations of these.
Also if you have a think about it, because javascript is a dependency of
roundcube, perhaps the idea of a javascript function to fix transparent
support in IE isnt that bad...
So for myself the decision is rather easy when it comes to PNG vs GIF. Whatever introduces more problems than it fixes is not worth to be used. Not too many people have time fix browser-specific bugs, so why not move away from this completely?
If you apply this concept, then we should scrap the use JavaScript.
Microsoft made JScript, Netscape made JavaScript then there is ECMAScript
262, the standard. IE doesn't comply and introduces lots of problems.
Sounds crazy hey!
Like i said before, the use of different file extensions does not
introduce bugs... What is the worst that can happen, a image doesn't load,
because of wrong extension, extension changed, done. This seems quite
minor to me..
Can you please give me an example of one of these so called bugs created
by using a non-transparent PNG.
In anyway, everyone is welcome to replace the images in his local
install. :)(...) Its called human error.
PICNIC (1), or human error is probably the #1 error in programming? :)
Cheers, Till
0, http://en.wikipedia.org/wiki/TOFU 1, http://en.wikipedia.org/wiki/PICNIC
On Mon, 20 Aug 2007 10:20:42 +1000, Chris Fordham chris@xhost.com.au
wrote:
On Sun, 19 Aug 2007 23:29:00 +1000, till klimpong@gmail.com wrote:
Hey Chris!
On 8/19/07, Chris Fordham chris@xhost.com.au wrote:
I've never had to 'think about every single file'? What is this
thinking ? And yeah, this does not introduce bugs...(Please don't TOFU (0), it makes it all harder to read and follow!) What Michael is getting at is that when you stick to one technology it's easier to handle it. So what I have been saying numerous times now is, that PNG is broken in IE6 AND IE7 (the #1 browser, even though we don't like it). I just had a case on another project where a hidden layer made PNGs on a page disappear - oh yeah, and it worked with right away GIF.
till, i know about the support, and its not completely broken like you
claim, thus my original argument of using what is optimally the best
image type based on number of colours in the palette, if transparency
was required and the effective image size. There is no need to repeat
yourself. I read it the first time. Perhaps you didn't read my email
which stated that pngs that are not transparent work fine in IE. I am a
client-side developer and create sites for a living. im well aware of
the limitations of these.
I think i might take this back. I just read up on the outstanding issues
for IE7/PNG. I rarely run into the colour problems, but you are right,
perhaps this is enough to scrap the use of PNG if a workaround is not
going to be used for IE. Dont' worry about replying to my last mail Till,
im wrong...
Also if you have a think about it, because javascript is a dependency of
roundcube, perhaps the idea of a javascript function to fix transparent
support in IE isnt that bad...So for myself the decision is rather easy when it comes to PNG vs GIF. Whatever introduces more problems than it fixes is not worth to be used. Not too many people have time fix browser-specific bugs, so why not move away from this completely?
If you apply this concept, then we should scrap the use JavaScript.
Microsoft made JScript, Netscape made JavaScript then there is
ECMAScript 262, the standard. IE doesn't comply and introduces lots of
problems. Sounds crazy hey! Like i said before, the use of different file extensions does not
introduce bugs... What is the worst that can happen, a image doesn't
load, because of wrong extension, extension changed, done. This seems
quite minor to me..Can you please give me an example of one of these so called bugs created
by using a non-transparent PNG.In anyway, everyone is welcome to replace the images in his local
install. :)(...) Its called human error.
PICNIC (1), or human error is probably the #1 error in programming? :)
Cheers, Till
0, http://en.wikipedia.org/wiki/TOFU 1, http://en.wikipedia.org/wiki/PICNIC
Hi,
Has anyone seen a fix yet for the problem below?
On Thu, August 16, 2007 7:47 pm, Thomas Bruederli wrote:
2007/8/16, Matt Kaatman roundcube-dev@matt.kaatman.com:
With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Must be broken since r667: http://trac.roundcube.net/trac.cgi/changeset/667#file3 The check for list.selection.length>0 is gone. Rich, please fix!
Regards Glen Ogilvie
OSS: Open Systems Specialists Ltd phone: 09-984-3000 fax: 09-984-3001 mobile: 021-684-146 email: gogilvie@oss.co.nz web: www.oss.co.nz post: P.O. Box 8833, Auckland
List info: http://lists.roundcube.net/dev/
Glen Ogilvie wrote:
Hi,
Has anyone seen a fix yet for the problem below?
Should now be fixed in revision 748. If it still occurs, please reopen Bug #1484522
~Thomas
On Thu, August 16, 2007 7:47 pm, Thomas Bruederli wrote:
2007/8/16, Matt Kaatman roundcube-dev@matt.kaatman.com:
With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Must be broken since r667: http://trac.roundcube.net/trac.cgi/changeset/667#file3 The check for list.selection.length>0 is gone. Rich, please fix!
Regards Glen Ogilvie
List info: http://lists.roundcube.net/dev/
Hey Thomas, Glen,
On 8/30/07, Thomas Bruederli roundcube@gmail.com wrote:
Glen Ogilvie wrote:
Hi,
Has anyone seen a fix yet for the problem below?
Should now be fixed in revision 748. If it still occurs, please reopen Bug #1484522
The fix is in SVN, I tested this extensively. ;-)
How to get SVN code? http://trac.roundcube.net/trac.cgi/wiki/Dev_SVN
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
as far as i can tell it too works for me!
thank you for this fix, raoul bhatia
till wrote:
Hey Thomas, Glen,
On 8/30/07, Thomas Bruederli roundcube@gmail.com wrote:
Glen Ogilvie wrote:
Hi,
Has anyone seen a fix yet for the problem below?
Should now be fixed in revision 748. If it still occurs, please reopen Bug #1484522
The fix is in SVN, I tested this extensively. ;-)
How to get SVN code? http://trac.roundcube.net/trac.cgi/wiki/Dev_SVN
Cheers, Till _______________________________________________ List info: http://lists.roundcube.net/dev/
I was about to send my version I fixed locally but if you update from SVN it looks like Thomas just fixed it.
Glen Ogilvie wrote:
Hi,
Has anyone seen a fix yet for the problem below?
On Thu, August 16, 2007 7:47 pm, Thomas Bruederli wrote:
2007/8/16, Matt Kaatman roundcube-dev@matt.kaatman.com:
With the last couple revisions from CVS, I've lost the ability to highlight multiple emails and hit delete. As soon as multiple items are highlighted the delete button is grayed out.
Must be broken since r667: http://trac.roundcube.net/trac.cgi/changeset/667#file3 The check for list.selection.length>0 is gone. Rich, please fix!
Regards Glen Ogilvie
OSS: Open Systems Specialists Ltd phone: 09-984-3000 fax: 09-984-3001 mobile: 021-684-146 email: gogilvie@oss.co.nz web: www.oss.co.nz post: P.O. Box 8833, Auckland
List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/
-
Aurélien Pocheville -
Chris Fordham -
Glen Ogilvie -
Jim Pingle -
Matt Kaatman -
Michael Baierl -
Michiel Oosterling -
NetOne - Doichin Dokov -
Raoul Bhatia [IPAX] -
Thomas Bruederli -
till