Java GUI Design: Docking and floating observation / questions
tastle
docking panels. In a sense, it will look like an MDI application, but
it will allow the user to drag "panels" outside of the Frame or dock
them to the inside.
I started a test application that uses Java's MDI features
(JDesktopPane, JInternalFrame) and it looks really nice. However,
after looking at different Java applications, it seems that perhaps
they are not using JInternalFrames after all. It appears that they
are using a combination of JDialog Boxes that have a fixed relative
position to the main JFrame (for floating features), and JSplitPane.
The dialogs, since they remain relative, appear to the eye as if they
are part of the main frame since they maintain their position. This
also allows them to be dragged outside of the Frame. As for docking,
it seems that once you move the frame to a certain position, the
dialog is hidden and the existing frame at that position is set to
visible and the content panes are copied. The opposite procedure
would happen for undocking.
Searching through this and other newsgroups, I've noticed that some
people are starting (as I have) to make this type of docking
application using JDesktopPane and JInternalPane, but I don't believe
this is necessary or even required.
Am I close with my assessment of this GUI design? I would really
appreciate any tips from you guys / gals who have done this sort of
thing before. Any code examples for reference would be appreciated.
Thanks for your time,
Tim
Jon A. Cruz
> I'm currently designing an application that will have floating and
> docking panels. In a sense, it will look like an MDI application, but
> it will allow the user to drag "panels" outside of the Frame or dock
> them to the inside.
MDI is a bit of a deprecated design approach. Apple has not wanted it
for the longest time, and Microsoft officially said not to do it as of
Windows 95.
Perhaps you can just focus on using JPanels, and then move those in and
out of JFrames or other container JPanels as needed.
dhek bhun kho
"Jon A. Cruz" <j...@joncruz.org>, Fri, 25 Jul 2003 19:54:23 -0700:
> tastle wrote:
>> I'm currently designing an application that will have floating and
>> docking panels. In a sense, it will look like an MDI application, but
>> it will allow the user to drag "panels" outside of the Frame or dock
>> them to the inside.
> MDI is a bit of a deprecated design approach. Apple has not wanted it
> for the longest time, and Microsoft officially said not to do it as of
> Windows 95.
I was just wondering why is it a 'deprecated design'? It is very useful
with complex GUI's as it allows easier access to a lot of menu's. It just
takes getting used to. It really gives me headaches when everything is in
one frame when working with an application like NetBeans (or photoshop,
gimp, dreamweaver). I don't have a 20" screen (just a 20' plasma tv, but
I can't connect it to my computer). MDI is especially useful if you have a
multi-headed setup (or a Windowing system that can switch between
workspaces instantaneously).
Greets
Dhek Bhun.
Jon A. Cruz
>
> I was just wondering why is it a 'deprecated design'? It is very useful
> with complex GUI's as it allows easier access to a lot of menu's.
That all depends. There are different ways to deal with that.
> It just
> takes getting used to. It really gives me headaches when everything is in
> one frame when working with an application like NetBeans (or photoshop,
> gimp, dreamweaver). I don't have a 20" screen (just a 20' plasma tv, but
> I can't connect it to my computer). MDI is especially useful if you have a
> multi-headed setup (or a Windowing system that can switch between
> workspaces instantaneously).
Actually, I have the latter, and I find the opposite to be true. MDI
forces taking over too much of the screen. Having SDI apps, on the other
hand, allows me to work in several documents at once (e.g. A browser
frame open (8.5x11 proportions) to a site I'm coding from, an editor,
and a running test app).
Anyway, big companies such as Microsoft and Apple decided after much
research that MDI was a poor interface, and that proper SDI apps gave a
better end-user experience.
dhek bhun kho
"Jon A. Cruz" <j...@joncruz.org>, Sun, 27 Jul 2003 08:05:57 -0700:
> dhek bhun kho wrote:
>>
>> I was just wondering why is it a 'deprecated design'? It is very useful
>> with complex GUI's as it allows easier access to a lot of menu's.
>
> That all depends. There are different ways to deal with that.
>
> > It just
>> takes getting used to. It really gives me headaches when everything is in
>> one frame when working with an application like NetBeans (or photoshop,
>> gimp, dreamweaver). I don't have a 20" screen (just a 20' plasma tv, but
>> I can't connect it to my computer). MDI is especially useful if you have a
>> multi-headed setup (or a Windowing system that can switch between
>> workspaces instantaneously).
>
> Actually, I have the latter, and I find the opposite to be true. MDI
> forces taking over too much of the screen. Having SDI apps, on the other
> hand, allows me to work in several documents at once (e.g. A browser
> frame open (8.5x11 proportions) to a site I'm coding from, an editor,
> and a running test app).
I agree. Stupid me. I mixed the two. I keep confusing them because the M
of Multiple Document always make me think that that means that I have
multiple windows. But that is actually the latter. :) Too bad my second
monitor broke down (seriously). It was really handy to have one screen
with all the compiler output and another one where I could type.
So were are talking about the same, but I am mixing right with wrong.
> Anyway, big companies such as Microsoft and Apple decided after much
> research that MDI was a poor interface, and that proper SDI apps gave a
> better end-user experience.
Greets,
Bhun.
tastle
> > research that MDI was a poor interface, and that proper SDI apps gave a
> > better end-user experience.
Perhaps I also had the terminology wrong. Basically I want to have a
design similar to that of a JDeveloper or Visual Studio environment.
Maybe the term I should have used is SDI?
In any event, what I've coded so far is a framework that can tell if
dialogs are inside the bounds of the application window. As soon as
they are dragged outside of a boundary, they move on their own
coordinate system. (Inside the boundary, they follow the same
translation of their parent frame.) This is basically an illusion to
make the dialogs seem part of the frame when inside of the frame
bounds.
The biggest uncertainty in my mind now, is how to "dock" items. I've
heard people mention that copying content panes is the way to go. For
example, if you are dragging a dialog over an area deemed to be a
docking point. Once the mouse is released, the dialog is made
invisible and the content pane is copied to the "newly visible" panel,
that would be already set in a splitpane. The illusion of docking
would be created.
However this design doesn't seem versitile. I believe there would be
limitations to the number of items docked to a side, because I would
have only N number of set hidden frames per-side. This could be
solved by knowing the maximum number of possible frames, and creating
a dummy framework on each docking side with some type of logic system
to handle when one item is dragged above / below / right / left of an
existing item, so that frames are adjusted.
Is there some trick that I could be missing or am I approaching this
in the correct fashion? Any experiences or ideas would be
appreciated.
Thanks once again.
Sandip Chitale
DockManager - oversees and manages the docking operations in the
application. Docks and Dockees register with it. Listens on mouse
events when the Dockee is being dragged. Calls the DockingNegotiator
when a dragged Dockee ghost window is on top of registered Dock.
Dock - interface implemented by any container that wants to be a dock.
With possible implementations:
SplitterDock
TabbedDock
RowDock
ColumnDock
GridDock
NEWSDock (NEWS = North, East, West South)
Dockee - interface implemented by any container that contains user's
dockable components. Provides drag handles and possibly title, icon
and dock, undock buttons. Remebers last Dock if any.
DockingNegotiator - interface implemented by a class that manages the
docking negotiation possibly based on DockOrientationHints and
DockeeOrientationHints.
With possible implementations:
AlwaysDockDockingNegotiator
NeverDockDockingNegotiator
MaxDockeeCountDockingNegotiator
DockOrientationHints - specifying preferred orientation and allowed
orientation of Dockees.
DockeeOrientationHints - specifying preferred orientation and allowed
form factors of Dockees.
tas...@hotmail.com (tastle) wrote in message news:<952b10de.03072...@posting.google.com>...