Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001272 [Squeak] Browser major always 05-26-05 21:55 02-07-07 06:42
Reporter tim View Status public  
Assigned To
Priority normal Resolution open  
Status new   Product Version 3.8
Summary 0001272: HierarchyBrowser>setClass:selector: is broken
Description HIerarchyBrowser inherits setClass:selector: from Browser. Since this method strongly assumes that the class list view is of a class category, we are bound for trouble. The chances of the hierarchy exactly matching the category are slim to none.

The root of the problem is redefining a class in a HB; most of the code invoked as a result is inherited from B and just makes bad assumptions. See Browser>defineClass:notifying: etc.

At best you get the wrong class being selected in your HB, at worst you get notifier about a problem unrelated to the class change you made. Very confusing.
Additional Information Does it make sense for a hierarchy browser to dispaly the class category view?
3.8-6662 image.
Debug log attached, though not very helpful
Attached Files  SqueakDebug.log [^] (4,413 bytes) 05-26-05 21:55
 HierarchyBrowser.RJT.2.cs.gz [^] (610 bytes) 10-14-05 03:28
 HBclassListDebugLog.log [^] (3,411 bytes) 02-07-07 06:34

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

parent of 0001302new  HierarchyBrowser class hierarchy view does not update when new class added 
parent of 0005631new  Saving a class definition in the hierarchy browser causes a walkback 
Not all the children of this issue are yet resolved or closed.

- Notes
(0002851 - 321 - 369 - 369 - 369 - 369 - 369)
Ron
10-14-05 02:02

 I have a fix for this bug, I ran into it myself.
I reimplemented the method

HierarchyBrowser>> buildSystemCategoryBrowserEditString

and added the initialization so the Hierarchy browser would have it's class list.

This fixed the problem of selecting Browse from the category pane on a Heirarchy Browser. -Ron
 
(0002857 - 372 - 372 - 372 - 372 - 372 - 372)
Ron
10-14-05 03:28

 That change sucked. I didn't like the results. I makes no sense to browse a category and end up in a hierarchyBrowser, there is no guarantee all the classes in a category will have the same Hierarchy. I changed it so that it opens a regular browser instead and acts consistantly with other category browsers for other areas. (besides I uploaded the wrong patch file!!)
 
(0009483 - 444 - 486 - 486 - 486 - 486 - 486)
wiz
02-07-07 06:42

 Another DebugLog datum. From sq7067.

When browsing some parts of the heirarchy the confusion seriously hinder work.

It would be nice to find a way to separate the hierarchy index from the
catagory index browser uses. The problem is the sheer size of the two classes. And the total confusion between classList in the two.

When does the hierarchy browser mean one thing and when the other when it uses the same messages as browser?
 

- Issue History
Date Modified Username Field Change
05-26-05 21:55 tim New Issue
05-26-05 21:55 tim File Added: SqueakDebug.log
10-14-05 02:02 Ron Note Added: 0002851
10-14-05 02:02 Ron File Added: Collection Utilities.1.cs.gz
10-14-05 03:28 Ron Note Added: 0002857
10-14-05 03:28 Ron File Added: HierarchyBrowser.RJT.2.cs.gz
01-21-06 22:00 MarcusDenker File Deleted: Collection Utilities.1.cs.gz
02-07-07 06:31 wiz Relationship added parent of 0001302
02-07-07 06:32 wiz Relationship added parent of 0005631
02-07-07 06:34 wiz File Added: HBclassListDebugLog.log
02-07-07 06:42 wiz Note Added: 0009483

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
61 total queries executed.
37 unique queries executed.
Powered by Mantis Bugtracker