Re: [JPP-Devel] BizzJUMP Distro Available For Docking Window FrameworkDemo
Bing, Did you check out the trunk of my BizzJUMP SVN? The use of the substance look and feel should be removed from the source code inthe trunk. It should be using the InfoNode look and feel instead. As I mentioned in a previous e-mail, there are a lot of problems when the InfoNode docking window framework and the Substance look and feel are combined. Bing wrote: "I think internal frames and docking system do not play along well. Conceptually they overlap quite a bit." How do they overlap? Bing wrote: "Docking inside a internal frame is too heavy-weighted. If a docking system is introduced, then it should probably replace the internal frame architecture." I haven't noted any performance problems with using the docking window framework inside of the TaskFrame class. Although it would be possible to have the TaskFrame itself be a tab this would require modifications to the JUMPWorkbench class, and I don't see the tangible benefits in that. Perhaps their are benefits that I am not thinking of? I suppose if you converted the JUMPWorkbench class to the be the parent of the docking window tree I suppose you could slide TaskFrames around with some more flexibility. But eliminating the TaskFrame's extension of the JInternalFrame class might cause some other problems. For example, you'd start screwing with the CursorTool code, which needs to know which TaskFrame is active. I think there is a lot of other code in OpenJUMP that is wired directly to the TaskFrame, and depends on it being an extension of an InternalFrame. If you talk about replacing it you increase the amount of work to integrate a docking window framework into OpenJUMP. SS On Wed, Oct 8, 2008 at 10:08 PM, Bing Ran <[EMAIL PROTECTED]> wrote: > Hi, > > Some quick thoughts. > > I have checked out the code in the svn to compile it with infonode 1.5. > > The JumpWorkBench uses substance LAF and it does not work well with > InfoNode. > > - The infonode does not look good on my system, especially the tab part. > - The painting is buggy and paint is often misplaced in the title section, > with flickering. > > Commenting out the substance stuff makes it look a lot better. > > I think internal frames and docking system do not play along well. > Conceptually they overlap quite a bit. Docking inside a internal frame is > too heavy-weighted. If a docking system is introduced, then it should > probably replace the internal frame architecture. > > > BTW, the MyDoggy demo looks really cool and the project seems active and > makes a good candidate. > > Just my 2 cents. > > Bing > > -- > From: "Sunburned Surveyor" <[EMAIL PROTECTED]> > Sent: Thursday, October 09, 2008 3:56 AM > To: "OpenJump develop and use" > Subject: [JPP-Devel] BizzJUMP Distro Available For Docking Window > FrameworkDemo > >> I've put together a demo version of BizzJUMP so other programmers can >> check out my integration of the InfoNode Docking Windows Framework. >> You can download it here: >> >> http://www.redefinedhorizons.com/shared_files/bizzjump-20081008.zip >> >> Please not this distro contains some expiremental code and plug-ins, >> so don't expect everything to work. :] However, it should give you a >> chance to play around with the docking windows framework. >> >> The source code for BizzJUMP can be viewed on the SourceForge SurveyOS >> Project SVN: >> >> http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/bizzJUMP/ >> >> No programming library is perfect, and the InfoNode Docking Windows >> Framework is no exception. The docking window framework has some >> trouble with alternate look and feels. I had real problems with some >> of the Substance look and feels, including dirty areas that wouldn't >> repaint and task windows that would dissappear. I don't think you'll >> have these problems if you stick to the "native" look and feels or the >> metal look and feel. BizzJUMP is currently using the infonode look and >> feel, and this isn't causing any problems. >> >> The following points may also be of interest: >> >> - I set up the BizzJUMP TaskFrame to contain three (3) main tabs. The >> LayerNamePanel is in its own tab and the LayerViewPanel is in its own >> tab. There is a third tab that can be used by plug-ins to present >> supplemental information. You can adjust and rearrange (change the >> location of) all three of these tabs. I have modified the tabs used >> for the LayerViewPanel and LayerNamePanel so that you can't close >> them. This keeps the user from closing one of the tabs and then not >> being able to get it back. I made some special modifications to the >> InfoNode code so that the third tab will always keep one tab open (for >> the same reason). However, if you have multiple tabs open in the third >> tab area you will be able to close the tabs until only one tab >> remains. >> >> It is still possible to make each of the three main tabs a floating >> window. If the user makes one of these main tabs a floating win
Re: [JPP-Devel] BizzJUMP Distro Available For Docking Window Framework Demo
I did get it to work by specifying a Java 1.6 in the batch file. My impressions of the docking framework are mixed. I remember it now from Paul's work. It looks kind of ugly and non-standard, but it may be worth it for the functionality. regards, Larry On Wed, Oct 8, 2008 at 4:53 PM, Sunburned Surveyor < [EMAIL PROTECTED]> wrote: > Larry, > > I just realized I need to check the compiler settings for the > libraries that BizzJUMP depends on. One of these is likely set for > Java 1.6. Let me do this after work today and I will report back with > the results. > > SS > > On Wed, Oct 8, 2008 at 2:31 PM, Sunburned Surveyor > <[EMAIL PROTECTED]> wrote: > > Larry, > > > > It looks like the error comes from an incorrect version of the JRE: > > > > http://support.codegear.com/article/35846 > > > > Are you running JRE 1.4 or JRE 1.5? If you are sure you're running 1.5 > > on the computer you used to launch BizzJUMP there may be something I > > missed with my Eclipse Project settings. Still, I'm pretty sure it is > > set to compile for 1.5 See the attached screenshot. > > > > SS > > > > On Wed, Oct 8, 2008 at 2:12 PM, Larry Becker <[EMAIL PROTECTED]> > wrote: > >> It didn't work for me. I can't get a project without: > >> > >> java.lang.UnsupportedClassVersionError: Bad version number in .class > file > >> at java.lang.ClassLoader.defineClass1(Native Method) > >> at java.lang.ClassLoader.defineClass(Unknown Source) > >> at java.security.SecureClassLoader.defineClass(Unknown Source) > >> at java.net.URLClassLoader.defineClass(Unknown Source) > >> at java.net.URLClassLoader.access$100(Unknown Source) > >> at java.net.URLClassLoader$1.run(Unknown Source) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at java.net.URLClassLoader.findClass(Unknown Source) > >> at java.lang.ClassLoader.loadClass(Unknown Source) > >> at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) > >> at java.lang.ClassLoader.loadClass(Unknown Source) > >> at java.lang.ClassLoader.loadClassInternal(Unknown Source) > >> at > >> > com.vividsolutions.jump.workbench.ui.WorkbenchFrame.addTaskFrame(WorkbenchFrame.java:723) > >> at > >> > com.vividsolutions.jump.workbench.ui.WorkbenchFrame.addTaskFrame(WorkbenchFrame.java:706) > >> at > >> > com.vividsolutions.jump.workbench.ui.plugin.NewTaskPlugIn.execute(NewTaskPlugIn.java:51) > >> at > >> > com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130) > >> at > >> > com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller$4$1.run(FeatureInstaller.java:575) > >> at java.awt.event.InvocationEvent.dispatch(Unknown Source) > >> at java.awt.EventQueue.dispatchEvent(Unknown Source) > >> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown > Source) > >> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown > Source) > >> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > >> at java.awt.EventDispatchThread.pumpEvents(Unknown Source) > >> at java.awt.EventDispatchThread.run(Unknown Source) > >> > >> Larry > >> > >> On Wed, Oct 8, 2008 at 3:54 PM, Michael Michaud < > [EMAIL PROTECTED]> > >> wrote: > >>> > >>> Hi SS, > >>> > >>> Thank you for letting us try bizzjump. The docking framework for > >>> OpenJump looks nice. > >>> I'll give it a try and let you know > >>> > >>> Michaël > >>> > >>> > >>> Sunburned Surveyor a écrit : > >>> > I've put together a demo version of BizzJUMP so other programmers can > >>> > check out my integration of the InfoNode Docking Windows Framework. > >>> > You can download it here: > >>> > > >>> > http://www.redefinedhorizons.com/shared_files/bizzjump-20081008.zip > >>> > > >>> > Please not this distro contains some expiremental code and plug-ins, > >>> > so don't expect everything to work. :] However, it should give you a > >>> > chance to play around with the docking windows framework. > >>> > > >>> > The source code for BizzJUMP can be viewed on the SourceForge > SurveyOS > >>> > Project SVN: > >>> > > >>> > http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/bizzJUMP/ > >>> > > >>> > No programming library is perfect, and the InfoNode Docking Windows > >>> > Framework is no exception. The docking window framework has some > >>> > trouble with alternate look and feels. I had real problems with some > >>> > of the Substance look and feels, including dirty areas that wouldn't > >>> > repaint and task windows that would dissappear. I don't think you'll > >>> > have these problems if you stick to the "native" look and feels or > the > >>> > metal look and feel. BizzJUMP is currently using the infonode look > and > >>> > feel, and this isn't causing any problems. > >>> > > >>> > The following points may also be of interest: > >>> > > >>> > - I set up the BizzJUMP TaskFrame to contain three (3) main tabs. The > >>> > LayerNamePanel is in its own tab and the LayerViewPanel is in it
Re: [JPP-Devel] BizzJUMP Distro Available For Docking WindowFrameworkDemo
SS, Yes, I was using the trunk and I removed the Substance LAF. The docking system manages lots of windows either as split panes or tabbed panes, which is pretty much what the desktop pane does. Thus what I call overlap. An internal frame containing docking windows looks heavy: one containing component too more:) That's what I meant. Performance-wise, I don't see any degradation. In my private work I am starting evaluating MyDoggy and see how it'll work. Regards, Bing -- From: "Sunburned Surveyor" <[EMAIL PROTECTED]> Sent: Thursday, October 09, 2008 10:16 PM To: "OpenJump develop and use" Subject: Re: [JPP-Devel] BizzJUMP Distro Available For Docking WindowFrameworkDemo > Bing, > > Did you check out the trunk of my BizzJUMP SVN? The use of the > substance look and feel should be removed from the source code inthe > trunk. It should be using the InfoNode look and feel instead. As I > mentioned in a previous e-mail, there are a lot of problems when the > InfoNode docking window framework and the Substance look and feel are > combined. > > Bing wrote: "I think internal frames and docking system do not play along > well. > Conceptually they overlap quite a bit." > > How do they overlap? > > Bing wrote: "Docking inside a internal frame is > too heavy-weighted. If a docking system is introduced, then it should > probably replace the internal frame architecture." > > I haven't noted any performance problems with using the docking window > framework inside of the TaskFrame class. Although it would be possible > to have the TaskFrame itself be a tab this would require modifications > to the JUMPWorkbench class, and I don't see the tangible benefits in > that. > > Perhaps their are benefits that I am not thinking of? I suppose if you > converted the JUMPWorkbench class to the be the parent of the docking > window tree I suppose you could slide TaskFrames around with some more > flexibility. > > But eliminating the TaskFrame's extension of the JInternalFrame class > might cause some other problems. For example, you'd start screwing > with the CursorTool code, which needs to know which TaskFrame is > active. I think there is a lot of other code in OpenJUMP that is wired > directly to the TaskFrame, and depends on it being an extension of an > InternalFrame. If you talk about replacing it you increase the amount > of work to integrate a docking window framework into OpenJUMP. > > SS > > On Wed, Oct 8, 2008 at 10:08 PM, Bing Ran <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Some quick thoughts. >> >> I have checked out the code in the svn to compile it with infonode 1.5. >> >> The JumpWorkBench uses substance LAF and it does not work well with >> InfoNode. >> >> - The infonode does not look good on my system, especially the tab part. >> - The painting is buggy and paint is often misplaced in the title >> section, >> with flickering. >> >> Commenting out the substance stuff makes it look a lot better. >> >> I think internal frames and docking system do not play along well. >> Conceptually they overlap quite a bit. Docking inside a internal frame is >> too heavy-weighted. If a docking system is introduced, then it should >> probably replace the internal frame architecture. >> >> >> BTW, the MyDoggy demo looks really cool and the project seems active and >> makes a good candidate. >> >> Just my 2 cents. >> >> Bing >> >> -- >> From: "Sunburned Surveyor" <[EMAIL PROTECTED]> >> Sent: Thursday, October 09, 2008 3:56 AM >> To: "OpenJump develop and use" >> Subject: [JPP-Devel] BizzJUMP Distro Available For Docking Window >> FrameworkDemo >> >>> I've put together a demo version of BizzJUMP so other programmers can >>> check out my integration of the InfoNode Docking Windows Framework. >>> You can download it here: >>> >>> http://www.redefinedhorizons.com/shared_files/bizzjump-20081008.zip >>> >>> Please not this distro contains some expiremental code and plug-ins, >>> so don't expect everything to work. :] However, it should give you a >>> chance to play around with the docking windows framework. >>> >>> The source code for BizzJUMP can be viewed on the SourceForge SurveyOS >>> Project SVN: >>> >>> http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/bizzJUMP/ >>> >>> No programming library is perfect, and the InfoNode Docking Windows >>> Framework is no exception. The docking window framework has some >>> trouble with alternate look and feels. I had real problems with some >>> of the Substance look and feels, including dirty areas that wouldn't >>> repaint and task windows that would dissappear. I don't think you'll >>> have these problems if you stick to the "native" look and feels or the >>> metal look and feel. BizzJUMP is currently using the infonode look and >>> feel, and this isn't causing any problems. >>> >>> The following points may also be of interest: >>> >>> - I set up the BizzJUMP TaskFrame to contain th
Re: [JPP-Devel] BizzJUMP Distro Available For Docking WindowFrameworkDemo
Check out http://www.vlsolutions.com/en/products/docking/ It's the one I like the best so far On Thu, Oct 9, 2008 at 9:38 PM, Bing Ran <[EMAIL PROTECTED]> wrote: > SS, > > Yes, I was using the trunk and I removed the Substance LAF. > > The docking system manages lots of windows either as split panes or tabbed > panes, which is pretty much what the desktop pane does. Thus what I call > overlap. > > An internal frame containing docking windows looks heavy: one containing > component too more:) That's what I meant. Performance-wise, I don't see any > degradation. > > In my private work I am starting evaluating MyDoggy and see how it'll work. > > Regards, > > Bing > > > > -- > From: "Sunburned Surveyor" <[EMAIL PROTECTED]> > Sent: Thursday, October 09, 2008 10:16 PM > To: "OpenJump develop and use" > Subject: Re: [JPP-Devel] BizzJUMP Distro Available For Docking > WindowFrameworkDemo > > > Bing, > > > > Did you check out the trunk of my BizzJUMP SVN? The use of the > > substance look and feel should be removed from the source code inthe > > trunk. It should be using the InfoNode look and feel instead. As I > > mentioned in a previous e-mail, there are a lot of problems when the > > InfoNode docking window framework and the Substance look and feel are > > combined. > > > > Bing wrote: "I think internal frames and docking system do not play along > > well. > > Conceptually they overlap quite a bit." > > > > How do they overlap? > > > > Bing wrote: "Docking inside a internal frame is > > too heavy-weighted. If a docking system is introduced, then it should > > probably replace the internal frame architecture." > > > > I haven't noted any performance problems with using the docking window > > framework inside of the TaskFrame class. Although it would be possible > > to have the TaskFrame itself be a tab this would require modifications > > to the JUMPWorkbench class, and I don't see the tangible benefits in > > that. > > > > Perhaps their are benefits that I am not thinking of? I suppose if you > > converted the JUMPWorkbench class to the be the parent of the docking > > window tree I suppose you could slide TaskFrames around with some more > > flexibility. > > > > But eliminating the TaskFrame's extension of the JInternalFrame class > > might cause some other problems. For example, you'd start screwing > > with the CursorTool code, which needs to know which TaskFrame is > > active. I think there is a lot of other code in OpenJUMP that is wired > > directly to the TaskFrame, and depends on it being an extension of an > > InternalFrame. If you talk about replacing it you increase the amount > > of work to integrate a docking window framework into OpenJUMP. > > > > SS > > > > On Wed, Oct 8, 2008 at 10:08 PM, Bing Ran <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> Some quick thoughts. > >> > >> I have checked out the code in the svn to compile it with infonode 1.5. > >> > >> The JumpWorkBench uses substance LAF and it does not work well with > >> InfoNode. > >> > >> - The infonode does not look good on my system, especially the tab part. > >> - The painting is buggy and paint is often misplaced in the title > >> section, > >> with flickering. > >> > >> Commenting out the substance stuff makes it look a lot better. > >> > >> I think internal frames and docking system do not play along well. > >> Conceptually they overlap quite a bit. Docking inside a internal frame > is > >> too heavy-weighted. If a docking system is introduced, then it should > >> probably replace the internal frame architecture. > >> > >> > >> BTW, the MyDoggy demo looks really cool and the project seems active and > >> makes a good candidate. > >> > >> Just my 2 cents. > >> > >> Bing > >> > >> -- > >> From: "Sunburned Surveyor" <[EMAIL PROTECTED]> > >> Sent: Thursday, October 09, 2008 3:56 AM > >> To: "OpenJump develop and use" > >> Subject: [JPP-Devel] BizzJUMP Distro Available For Docking Window > >> FrameworkDemo > >> > >>> I've put together a demo version of BizzJUMP so other programmers can > >>> check out my integration of the InfoNode Docking Windows Framework. > >>> You can download it here: > >>> > >>> http://www.redefinedhorizons.com/shared_files/bizzjump-20081008.zip > >>> > >>> Please not this distro contains some expiremental code and plug-ins, > >>> so don't expect everything to work. :] However, it should give you a > >>> chance to play around with the docking windows framework. > >>> > >>> The source code for BizzJUMP can be viewed on the SourceForge SurveyOS > >>> Project SVN: > >>> > >>> http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/bizzJUMP/ > >>> > >>> No programming library is perfect, and the InfoNode Docking Windows > >>> Framework is no exception. The docking window framework has some > >>> trouble with alternate look and feels. I had real problems with some > >>> of the Substance look and feels, including dirty area
