66555 - truncate image filename in context menu more cleanly

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, defect)

Description

[sairuh (rarely reading bugmail)]

spun off from bug 21515. thx to dean for pointing this out.

if the image file has a long name, we currently truncate it as "Save Image
(long_long_long..." instead of "Save Image (long_long_lo...name.gif)". we should
do the latter.

Comment 1

[sairuh (rarely reading bugmail)]

doron, you wanna take this one...?

Comment 2

[Doron Rosenberg (IBM)]

--> me.

i have a patch, just need to know, how much should we cut off? ns4 win98 does this:
[10]...[6].ext

Comment 3

[:deanis74]

Sounds OK to me.

Comment 4

[sairuh (rarely reading bugmail)]

actually, i rechecked stuff and what i'm seeing is (filename.gif)... where the
ellipses follow the whole filename. {eg, the banner on http://mozilla.org/]
would that be yet another bug? or does that pertain to this one?

Comment 5

[sairuh (rarely reading bugmail)]

argh, disregard my comment re: the ellipses. of course they should be there,
since a dialog would follow after selection. doh!

anyhow, i'm gonna attach a test image file with a long name.

Comment 6

[sairuh (rarely reading bugmail)]

Attachment: testcase - an image file with a looooong filename

Comment 7

[Warner Young]

Doron, sorry, not trying to make this even more complicated, but...  Instead of
a predetermined number of characters before and after the ellipsis, how hard
would it be to calculate the width of the characters to display, and always make
sure the name doesn't exceed a certain width?  Though perhaps a minimum number
of characters should always be displayed no matter what.

Comment 8

[Doron Rosenberg (IBM)]

Is it possible to determine the width of the context menu? Even then, we need a
maximum width.

I am going to play more around with ns4 and see what it does

Comment 9

[Doron Rosenberg (IBM)]

cc mpt in case there is a spec on this

Comment 10

[Matthew T (active 1999-2002)]

A spec? For this? Hahahaha... ahem.

Doron, don't give any special treatment to the suffix -- a picture doesn't 
necessarily have one. Just {up to 10 characters}...{up to 10 characters}.

Comment 11

[Doron Rosenberg (IBM)]

yea, i currenty do [10]...[6]

a lot of capital letters will mess any more than that, since we are not using
unispace (um, where each character takes the same width, forgot how that is called).

Comment 12

[Doron Rosenberg (IBM)]

i'll attach my patch tomorrow, still playing with the numbers.

Comment 13

[Doron Rosenberg (IBM)]

[10]...[6] fails with image names containing a lot of capital letters, so this
is more complex.

Comment 14

[Warner Young]

Doron, this is why I suggested calculating the width and capping the filename
based on some sort of max width.  Then it won't matter what kind of characters
are in the filename.

Comment 15

[german]

I think as long as the .extension is preserved and has a few letters before 
that extension (up to like 6) and a few letters from the beginning of the word 
(up to like 10) you should be fine. what do you mean by failing?

Comment 16

[Doron Rosenberg (IBM)]

by failing i meant there is overflow and the last bit of the name becomes "...".
A image with just capital letters can overflow after 6 characters showing in
modern for example.

Probably a good idea is to have a loop until no overflow occurs and keepign
taking a character away from the center or such. If anyone has any idea how to
check if a menuitem overflows in js...

Comment 17

[Doron Rosenberg (IBM)]

i have a evil temp fix - make the imagename lowercase! 

/me ducks

Comment 18

[Doron Rosenberg (IBM)]

-> 1.0

There is still some overflow issues, now only with classic and images with
capital letters (AWWWWWWWWWWW.jpg for example). So this is going to take more
time, especially since Ben says there is no simple js way to check for overflow
in a menuitem.

Comment 19

[Doron Rosenberg (IBM)]

Attachment: proposed patch

Comment 20

[Doron Rosenberg (IBM)]

ok, i added a patch which will do it for most cases. The only case is the
aforementioned case of capital letters in the imagename. Also, this seems to
only happen in classic, modern's contextmenus are more flexible it seems.

So unless anyone knows of a way to check if a menuitem is overflowing, I suggest
this for a temp fix.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Looks good to me as a temp fix... r=[e-mail]

Comment 22

[:deanis74]

Is endBit long enough?  For filenames with an 3-character extension, that's the 
last character of the filename then .extension.

Comment 23

[Doron Rosenberg (IBM)]

the last 5 chars are taken, so it would bee "x.foo" for example as endbit.  

Comment 24

[:deanis74]

That's what I said, just not too clearly!  I was just wondering if this was 
enough info.

Comment 25

[Karl Ove Hufthammer]

See also bug #52978.

Comment 26

[Doron Rosenberg (IBM)]

Attachment: corrected patch

Comment 27

[:deanis74]

Yeah, I was going to mention that (!).  r=[e-mail]

Comment 28

[Doron Rosenberg (IBM)]

cc: alecf for a possible sr=

I'm looking at to why modern handles this better (it lets the context menu grow)
while classic causes overflow pretty quickly.

Comment 29

[Alec Flett]

so we don't know how classic does this? seems like they must set a maximum width
on the menu or something?

Anyway, I think this patch is hacky, I'd like further investigation on classic
first.

Comment 30

[Doron Rosenberg (IBM)]

ok, i found the css that makes classic's menu less wide that modern.

http://lxr.mozilla.org/seamonkey/source/themes/classic/global/win/menu.css#66

Modern has 

http://lxr.mozilla.org/seamonkey/source/themes/modern/global/menu.css#198

so we can change classic's max-width then. However, I still think we should
truncate the imagename. Any opinions? 

Comment 31

[:deanis74]

Yes, no matter what we need to truncate.  But if we change the max width then we 
should be able to push this out to around 25 characters instead of 15.

Comment 32

[Alec Flett]

I really think we should leave it up to the theme to decide when (or if) to
truncate.

Comment 33

[Doron Rosenberg (IBM)]

hmm, the problem is, it won't truncate "neatly" (ie, cuts off at the end, not in
the middle). But that is anothing issue probably...

Comment 34

[Doron Rosenberg (IBM)]

This is very ugly for very long imagenames, the context menu grows to almost hal
fo the screen width.

I think that we should increase the classic width to be like modern and then do
a name truncation after say 25. Any opinions?

Comment 35

[:deanis74]

For the truncating on the right instead of the middle, can the crop for menus be 
set to center, similar to how it's (going to be?) done for the bookmarks window? 
 The cropping is handled in nsTextBoxFrame.cpp, so it should be possible for 
this to take effect.

Comment 36

[Warner Young]

What should this bug's status be?  I notice in the latest builds that the
filename is no longer displayed at all in the context menu.  Is this
intentional, or just a temporary thing?

Comment 37

[Lorenzo Colitti]

wyoung: the new context menus that landed just before 1.0 RC1 don't include the
image name in the context menu.

There is a working patch for this in bug 136110, but there doesn't seem to be
consensus that this feature is useful. If you would like it, please comment in
bug 136110 and/or vote for that bug.

Comment 38

[Doron Rosenberg (IBM)]

the imagename isn't needed.