This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 11675 - What icons for new modes frames when cloned, uncdocked, ...
Summary: What icons for new modes frames when cloned, uncdocked, ...
Status: CLOSED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: jrojcek
URL:
Keywords: API, UI
: 13510 15448 (view as bug list)
Depends on: 15448
Blocks:
  Show dependency tree
 
Reported: 2001-04-23 16:36 UTC by mslama
Modified: 2008-12-22 20:34 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mslama 2001-04-23 16:36:55 UTC
What icons for new modes frames when cloned, uncdocked, docked into new single,
multitabbed, split frame?

I fixed #11456 and behaviour is as follows:

Current behaviour:
1.Clone action: Icon from original mode is used.
2.Undock, dock into new single, multitabbed, split frame: Default icon is used.

Before when top component was cloned icon of top component was used for frame.
It is ok till only one component is docked into this frame. But what if you dock
into it another top component? Anyway if you open source editor it uses its own
icon for source editor not top component's icon. So it would not be consistent
=> design must be carefull.

If you think current status is ok just close this issue.
Comment 1 Dirk Ruiz 2001-04-30 21:37:26 UTC
This is fine.  It tells users the truth about what type of frame they are
docking components into (multi-tab, Source Editor, etc).  Honestly, though, I
think only the most sharp-eyed of users is going to see the difference.  Window
management in NetBeans is very confusing.  We need to sit down and rework
frames, top components, docking, and MDI.  I'll go ahead and close it.  If 
anyone disagrees with this assessment, please reopen it.
Comment 2 Jiri Rechtacek 2001-09-12 16:13:56 UTC
There is some issue assigned for this behavior. I think it is ready for enlarge winsys enough.
Some hints: add the set/getIconURL methods in TopCompoment.
Comment 3 Jiri Rechtacek 2001-09-12 16:15:10 UTC
*** Issue 13510 has been marked as a duplicate of this issue. ***
Comment 4 Jiri Mzourek 2001-10-19 17:01:58 UTC
Component change: ui -> core
Comment 5 Jiri Rechtacek 2001-11-05 17:24:33 UTC
A polite fix of this issue asks a apichange of
org.openapi.windows.TopComponent. The method set/getIconURL should be
added because if a component is docked in single-mode (w/o icon) there
isn't any way how to obtain a icon URL for set it into mode.
Because beta-cycle on 3.3 release is being run than API change will be
postponed to 3.4. Comments are welcome.
Comment 6 Jiri Rechtacek 2002-01-29 16:42:15 UTC
*** Issue 15448 has been marked as a duplicate of this issue. ***
Comment 7 Jiri Rechtacek 2002-05-24 09:43:54 UTC
It is not defect but an enhancement, should be evaluated to next release.
Comment 8 Marek Grummich 2002-07-22 08:33:16 UTC
Target milestone was changed from '3.4' to TBD.
Comment 9 Marek Grummich 2002-07-22 08:44:41 UTC
Target milestone was changed from '3.4' to TBD.
Comment 10 Jiri Rechtacek 2002-07-29 15:31:12 UTC
Jano, could you look on it and then reassign on window system? Thanks
Comment 11 David Simonek 2005-12-20 13:08:52 UTC
I think this is obsoleted now, closing.
Comment 12 Marian Mirilovic 2005-12-20 15:56:03 UTC
closing