57942 - OS/2 - Window List Description Registration Problems

Status: VERIFIED WONTFIX

(SeaMonkey :: General, defect, P3)

Description

[Barry Marshall (at work)]

Thinkpad 770X, 1024 * 768 * 32bpp, WSeB, running 1020.

The registration of the browser's windows in the Window List isn't very 
clear, in comparison to other OS/2 applications.  This bug will use 
Navigator/2 4.61 for the comparison point.

Problem #1: 
If I have multiple browser windows running, the usual way they should 
appear in the Window List is:

Application Name
   Browser Window #1
   Browser Window #2
   etc.

Mozilla doesn't do this.  It basically just keeps popping windows into 
the Window List without any structure.

Browser Window #1 - Mozilla Build ID
Browser Window #2 - Mozilla Build ID


This is a bit of a problem, especially with the browser's current 
location being the first thing to appear in the Window List.  The user 
can loose track of which line in the Window List the browser is running 
in.

The preferred listing should be

Mozilla Build ID
  Browser Window #1
  Browser Window #2



Problem #2 : The description in the Window List is a bit vague.

What would be helpful is to register the window list something like:

Mozilla  {Build ID : 2000102005}
  Browser - Blah Blah Blah
  Mail - Blah Blah Blah
  Address Book - Blah Blah Blah
  Composer - Blah Blah Blah


Problem #3 - URL Titles Over 60 Characters

Some URL's come up with excessively long titles, which don't fit in the 
Window List task box.  It would be nice to end off these URL listing 
with ... or something to indicate that they're longer that can be 
displayed.  

Alternately, what about shoving them on the next line, like Plug and 
Play for PCMCIA does?



I'll attach a picture that shows all of these problems in action.

Comment 1

[Barry Marshall (at work)]

Attachment: Window list issues. Compare how Netscape/2 groups the windows, the lack of descriptions, and over-length entries.

Comment 2

[slaquinta]

SCREENED.  VERIFIED AS VALID.

Comment 3

[Jeffrey S. Kobal]

There are really four problems to resolve here.

(1) The Window List indenting is a function of the Workplace Shell.  In order to 
get the fancy indented listing, the program must be run from an icon.  This will 
be done when a "released" version is installed.

(2) MOZILLA.EXE is marked as WINDOWCOMPAT so that it opens a VIO console for the 
output.  In order for the Workplace Shell to be able to keep track of the 
windows for a session (to do the intended stuff), we have to mark the EXE as 
WINDOWAPI instead... but then we won't get the output console.  This will also 
be done when a "released" version is made.

(3) For some strange reason, the type of window (e.g. Composer) is tacked onto 
the END of the title, instead of the beginning, which would make it easier to 
distinguish between different windows.  This is something we'd mostly likely 
have to change by putting OS/2-specific code in the XP module that entitles the 
windows.

(4) Truncation of titles in the Window List.  The Window List entries are tied 
directly to the text in the titlebar of the windows, so to truncate one means we 
truncate the other.  Our only alternative would be to put in code after setting 
the title bar text to search for the Window List entry for that window (since 
setting the title bar text also sets the Window List text) and change the Window 
List text manually.  This could be done in the platform-specific code in 
nsFrameWindow.cpp (in widget/src/os2).

None of these are high-priority issues at this point in time.  If anyone out 
there in Warpzilla-land wishes to give #3 or #4 a shot, go right ahead.

Comment 4

[Jeffrey S. Kobal]

For "Problem #2" (which in my description was #3), the code to fix this would go 
into nsContentTreeOwner::SetTitle (xpfe/appshell/src/nsContentTreeOwner.cpp), 
where the title text is constructed from the pieces.  We could put in 
OS/2-checking to swap it around, or add a query of a preference for the format.

Comment 5

[Barry Marshall]

Hmmm... Would it be worth opening a seperate cross-platform 
feature-enhancement bug for that?  I don't know how other OS'es list their 
active windows/tasks other than Microsoft's Taskbar.  At least with Taskbar 
you have the additional icon on the left there to give you a visual indication 
of what that task is.

What does MACOS, BEOS, or the various *ix do for this?  Anything equivalent?

Comment 6

[timeless]

BeOS has three things. a taskbar, an app switcher and a task manager.
the task manager deals w/ whole teams [aka apps], and the purpose is to kill a 
non responsive app. The other two display the app and then have a child window 
list per app.

in the taskbar it amounts to this:
1) mozilla
 a) mozilla.org -browser
 b) ...
2) opera
 a) mozilla.org ...
 ...

in the switcher, the display is different, but the hierarchical organization is 
the same.

Windows. The switcher displays at most 21 items, each normal window is an item, 
it's prefered that the window title be to the left of the app for two reasons.
1) window titles are often long, 2) the app is hinted at by its icon and is 
therefor of much less importance than the window specific title
the Task manager and task bar use the same window titles as the windows and 
switcher. Again all of these displays have an icon that hints the 
app/component.  Unfortunately, some apps still use the old fashioned window 
titling schema, so i can have 20 tera term windows each of the form 'tera term 
- $(host)' which is really hard to read in most displays because there is often 
very little room for the content beyond 10 letters.
The sorting here is so useless and annoying, especially w/ 64+ windows open 
(excluding windows that are magic and don't get listed)

To paraphrase a friend, ~macos is application centric, not document centric~. 
So on macos you have the Process List, which just lists processes, not the 
windows they have.

I didn't use QNX long enough to look there (iirc it's a windows knock off).

IMO BeOS did the best job for this task.

Comment 7

[Barry Marshall]

Sounds like this is OS/2-specific only then due to our lack of icons, I guess.  

Would introducing another Preference query cause more effort in getting it in?  
That would touch more than the module in question, no?  Quality of the fix would 
be better though.

Comment 8

[Mike Kaply [:mkaply]]

Fix checked in.

Comment 9

[Mike Kaply [:mkaply]]

I HATE BUGZILLA.

wrong defect

Comment 10

[Barry Marshall (at work)]

Last night I installed the refreshed OS/2 Web Browser to check out another bug 
and I thought I noticed that the Window List issues seem to have cleared up in 
that build....  it was WAY too late and wasn't paying that much attention.

Any chance of adding that fix into the mainline code?  The most recent OS/2 
build I have (0.9.2.1+) still shows the Window List weirdness.

Comment 11

[Mike Kaply [:mkaply]]

We're not going to do this.

Because the appname contains the build ID, this ends up looking pretty clunky.

We haven't received any complaints about the way it is, so we are going to leave 
it.

Comment 12

[Mike Kaply [:mkaply]]

Verified- we aren't fixing this.