Open Bug 89261 Opened 23 years ago Updated 4 years ago

Element Properties window should have a relevant icon

Categories

(SeaMonkey :: UI Design, enhancement, P5)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: mpt, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug) 

To reproduce:
1.  Open the context menu for an image or link in a Web page, and choose
    `Properties'.
2.  Look in the top left corner of the Properties window.

What you see:
*   Nothing in particular.

What you should see:
*   For Image Properties, a copy of the picture scaled down to 32*32.
*   For Link Properties, a generic link icon (perhaps a page with a chain on
    it).
Etc.

Problem occurs with:
*   build 2001070308, Mac OS 9.1

Problem does not occur with:
*   Mac OS Finder
*   Windows Explorer
*   Microsoft Internet Explorer for Windows
Blocks: 89250
Sounds neat! But what to do if there are both image and link metadata avalible?
This would be quite cool. But also Effort.

Gerv
Matthew, can you answer Jonas' question?

Anyone have any idea how to get a copy of the image and scale it down without
having to re-retrieve it over the network?

usability/polish, 0.9.4.
Status: NEW → ASSIGNED
OS: Mac System 9.x → All
Hardware: Macintosh → All
Target Milestone: --- → mozilla0.9.4
> But what to do if there are both image and link metadata avalible?

That's yet another reason for image properties and link properties being in two 
different properties windows. (Sorry to sound like a broken record here.:-)

For how to get a cached copy of the image, I suggest asking networking people. 
Darin?

Does Page Info use a cached copy of the image?
when you load an image, imagelib will use its cache if it finds a matching
image.  if not, then it will ask necko for the image.  asking necko may or may
not result in a network hit.  you can ask necko to use its "local copy" by
passing the LOAD_FROM_CACHE load flag.  i'm not sure how to cause imagelib to
use this flag.

pavlov?
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla1.0
-->sicking
Assignee: blakeross → sicking
Status: ASSIGNED → NEW
mpt: i need a spec. What should be done when there is information from several 
sections?
Show image properties and link properties in two different properties windows. 
(Sorry to sound like a broken record here.)
so we would should have "image properties", "link properties", "quote
properties" "insertion properties" and "text properties" context-menu items? I
agree it would be unlikely that more then two of these are visible at the same
time, but I'm still not sure I like the idea.
This would be both redundant and confusing IMO. My view is that we should stick
with a single Properties menu item, which shows you the Properties of the thing
or things under the click. Like now, in fact :-)

That's not to say the resultant window couldn't use some work.

Gerv
I'm compleatly with Gerv, so the question remains, what do we do when there is 
info from several groups avalible?
I agree w/ gerv's comment #10.
Target Milestone: mozilla1.0 → mozilla1.1
Target Milestone: mozilla1.1 → Future
What if the window used the favicon from the site?
Can the window icon be set from javascript or would that have to be a C++ chunk
of code?
IMO it shouldn't use the favicon or scaled image, there should simply be a single
 "Element Properties" icon (since a "link properties" and "image properties" (etc)
 window are the same thing).

Isn't this icon for identifying what kind of window this is (an internet 
explorer window, a mail/news window, a js console window) _not_ for identifying 
its contents? (thats what the text is for)

This is the same behaviour as the bookmark properties dialog (it has the same 
icon for folders as for bookmarks).
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
Additional information:
a) the SeaMonkey Logo is not bad, but indeed, a specific icon would be better
b) Ideas for possible icons:
   <https://www.iconfinder.com/icons/146127/about_help_info_information_more_info_properties_icon>
   <http://www.softicons.com/system-icons/oxygen-icons-by-oxygen/actions-document-properties-icon>
c) Removed assignee due to facts
Assignee: jonas → nobody
Status: RESOLVED → REOPENED
Ever confirmed: true
Priority: -- → P5
Resolution: EXPIRED → ---
Whiteboard: [good first bug]
(In reply to Rainer Bielefeld from comment #23)
> Additional information:
> a) the SeaMonkey Logo is not bad, but indeed, a specific icon would be better
> b) Ideas for possible icons:
>   
> <https://www.iconfinder.com/icons/146127/
> about_help_info_information_more_info_properties_icon>
Incompatible open source license.

> <http://www.softicons.com/system-icons/oxygen-icons-by-oxygen/actions-
> document-properties-icon>
non-free, non-open source.

> c) Removed assignee due to facts
Status: REOPENED → NEW
Perhaps the icon could have an "i" similar to one of those two icons (or the "information" icon) on the background used in the majority of SeaMonkey window icons. (blue with white streak in the middle)

(I don't design icons, but this is an idea for someone who does)
Keywords: good-first-bug
Whiteboard: [good first bug]
You need to log in before you can comment on or make changes to this bug.