Bugs item #1936333, was opened at 2008-04-06 17:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1020092&aid=1936333&group_id=212019
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: insight-ui
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bindul Bhowmik (bindul)
Assigned to: Nobody/Anonymous (nobody)
Summary: Insight preferences does not show up on the taskbar and proc
Initial Comment:
[This item was moved over from MindTree OpenMind. Defect Tracker#107]
In the current development version of Insight, it is possible to bring up the
preferences alone without the entire application ("insight -p").
The problem with this approach is that, if the Preference fame thus brought up
is closed using the (x) button on the top-right of the frame, the application
does not exit. Ideally this button should have the same behavior as the cancel
button.
Also the preference frame does not show up in the Windows taskbar (on Win32
systems).
Steps to reproduce:
-------------------
1. Bring up the preference frame using the '-p' command line switch.
2. OBSERVATION: It does not show up in the taskbar.
3. Open the windows task manager and locate the process running the application
and monitor it.
4A. If the window is closed using the 'Save' or 'Cancel' button, the
application dissapears and the process also exits (see the task manager).
4B. If the window is closed using the 'x' button, the application dissapears
but the process does not exit (see the task manager).
I think we need to fix both of these before the 1.6 release.
FOLLOW UP:
Date: 2006-04-06 03:17
Sender: Bindul Bhowmik
Team,
I had a look at the code last night and this is what I think needs to change:
Currently PreferencesFrame is a JDialog (even though it is called a frame). So
that is what is causing the bug mentioned above. The JDialog is required
because when we bring the preferences up from the application it needs to be
modal.
The resolution I am thinking of to it is to modify the class (and possibly also
the name of the class) to extend a JPanel. Having a cursory look I feel this
should not cause us any major pains.
Then have two new types - a JFrame and a JDialog. Both of whose contents would
be the panel mentioned above. The dialog would be brought up when preferences
are called from within the application - same as the current behavior. The
frame can be called up when
the preferences are coming up by themselves.
Thoughts?
Rgds,
Bindul
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1020092&aid=1936333&group_id=212019
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
mindtreeinsight-devel mailing list
mindtreeinsight-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mindtreeinsight-devel
