xnap-commons-devel — XNap Commons development is discussed here.

[XNap-Commons-Devel] JHylaFAX 1.2.0 released

[Steffen P. <ste...@gm...>]

Hi,

I have released a new version of JHylaFAX (the only project I know off that is 
based on the XNap Commons). Just in case anyone wants to rate it ;) (and help 
promote the Commons) :

http://freshmeat.net/projects/jhylafax/

Steffen

-- 
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[KUBO H. <hi...@sf...>]

Hi,

> --- xnap-commons.org/src/java/org/xnap/commons/gui/DirectoryChooser.java	
> 2005-05-04 12:53:28.000000000 +0900
> +++ xnap-commons/src/java/org/xnap/commons/gui/DirectoryChooser.java	
> 2005-06-04 11:01:35.000000000 +0900
> @@ -45,8 +45,8 @@
>  	implements TreeSelectionListener
>  {
> -    public static final int APPROVE_OPTION = 1;
> -    public static final int CANCEL_OPTION = 2;
> +    public static final int APPROVE_OPTION = 0;
> +    public static final int CANCEL_OPTION = 1;
> 
> Is there a special reason why you changed these values?

For compatibility to JFileChooser's definition of constants which have same names.


> > But I think it will be required to make subclass of FileChooserDelegator
> > which delegates method calls to a JFileChooser instances or
> > an DirectoryChooser instance or something else chooser instance.
> 
> Why not have a separate class for the directory chooser panel? We could 
> extract methods that can be shared between FileChooserPanel and 
> DirectoryChooserPanel to an abstract common super class. 

OK, I agree with you.
When I wrote this patch, I tried to simulate JFileChooser#setFileSelectionMode
(A dynamic mode change is required by calling setFileSelectionMode method),
with reluctance. 


> I don't like the idea of boolean flags much.

me too:)


> And concerning FileDropAcceptableTextField.java: How about using a "decoration 
> pattern instead of inheritance" (as Felix put in chat). I'd prefer 
> implementing the DropTargetListener as an abstract class, requiring the 
> chooser panel to implement drop(File) and to set the filename instead of 
> inhereting JTextField.

You're right. "the Decoratoin Pattern" will be better.
I'll make abstract class DragTargetAdapter and 
class FileDragTargetAdapter.


> Thanks for providing the patch. I think this will be a very useful enhancement 
> of the XNap Commons. Once we have figured out the technical details I am 
> certainly interested in merging it.

You are welcome!
-- 
KUBO Hiroya
hi...@sf...

Re: [XNap-Commons-Devel] Completion

[Chris M. <ch...@st...>]

Yeah Foxtrot not JFoxtrot. Strandz has stuck with Foxtrot and never used Spin. 
Spin acknowleges that the original idea came from Foxtrot.

http://foxtrot.sourceforge.net/
http://spin.sourceforge.net/

I'm afraid I don't really have much insight for this group as to which solution 
is better.

Steffen Pingel wrote:
> Hi,
> 
> 
>>What does XNap-Commons standardize on for threading ("some kind of
>>asynchronous implementation")? 
> 
> 
> Currently nothing, as we didn't have a need for threading so far :).
> 
> 
>>I have used JFoxtrot; it works well and it 
>>is being actively developed, but there is also Spin.
> 
> 
> I have used Foxtrot as well and liked it a lot. Spin I have heard of but never 
> used. I guess it is up to whom ever uses a threading first. If applicable I 
> would certainly look into using Foxtrot.
> 
> Does Spin have any particular advantage? Could you provide a link with more 
> information on Spin?
> 
> Steffen
> 


-- 
www.strandz.org

The 'least code' framework.

Re: [XNap-Commons-Devel] Completion

[Steffen P. <ste...@gm...>]

Hi,

> What does XNap-Commons standardize on for threading ("some kind of
> asynchronous implementation")? 

Currently nothing, as we didn't have a need for threading so far :).

> I have used JFoxtrot; it works well and it 
> is being actively developed, but there is also Spin.

I have used Foxtrot as well and liked it a lot. Spin I have heard of but never 
used. I guess it is up to whom ever uses a threading first. If applicable I 
would certainly look into using Foxtrot.

Does Spin have any particular advantage? Could you provide a link with more 
information on Spin?

Steffen

-- 
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] Completion

[Chris M. <ch...@st...>]

What does XNap-Commons standardize on for threading ("some kind of asynchronous
implementation")? I have used JFoxtrot; it works well and it is being actively 
developed, but there is also Spin.

- Chris Murphy

Steffen Pingel wrote:
> Hi,
> 
> 
>>Well, retrieving directory entries form the file system will take more
>>longer time than sorting the entries, I suppose...
> 
> 
> Yes, that is a point. Therefore we should look into some kind of asynchronous 
> implementation anyhow ;).
> 
> Steffen
> 


-- 
www.strandz.org

For matching users to their data.

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[Steffen P. <ste...@gm...>]

Hi,

--- xnap-commons.org/src/java/org/xnap/commons/gui/DirectoryChooser.java	
2005-05-04 12:53:28.000000000 +0900
+++ xnap-commons/src/java/org/xnap/commons/gui/DirectoryChooser.java	
2005-06-04 11:01:35.000000000 +0900
@@ -45,8 +45,8 @@
 	implements TreeSelectionListener
 {
-    public static final int APPROVE_OPTION = 1;
-    public static final int CANCEL_OPTION = 2;
+    public static final int APPROVE_OPTION = 0;
+    public static final int CANCEL_OPTION = 1;

Is there a special reason why you changed these values?

> But I think it will be required to make subclass of FileChooserDelegator
> which delegates method calls to a JFileChooser instances or
> an DirectoryChooser instance or something else chooser instance.

Why not have a separate class for the directory chooser panel? We could 
extract methods that can be shared between FileChooserPanel and 
DirectoryChooserPanel to an abstract common super class. I don't like the 
idea of boolean flags much.

And concerning FileDropAcceptableTextField.java: How about using a "decoration 
pattern instead of inheritance" (as Felix put in chat). I'd prefer 
implementing the DropTargetListener as an abstract class, requiring the 
chooser panel to implement drop(File) and to set the filename instead of 
inhereting JTextField.

Thanks for providing the patch. I think this will be a very useful enhancement 
of the XNap Commons. Once we have figured out the technical details I am 
certainly interested in merging it.

If anything above is unclear, please ask and I will try to explain in more 
detail.

Steffen
 
-- 
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] Completion

[Steffen P. <ste...@gm...>]

Hi,

> Well, retrieving directory entries form the file system will take more
> longer time than sorting the entries, I suppose...

Yes, that is a point. Therefore we should look into some kind of asynchronous 
implementation anyhow ;).

Steffen

-- 
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] Completion

[KUBO H. <hi...@sf...>]

Hi,

At Fri, 10 Jun 2005 16:44:23 +0200,
Steffen Pingel wrote:
> > > We should have internal logic of asynchronous update of completion list
> > in case canceling action by hitting Ctrl-G(like emacs minibuffer) or
> > something.
> 
> Sounds great. Until we have that, I am rather hesitant concerning the sorting 
> of the combo box. I guess this will take too much time, when large 
> directories like /usr/bin are completed.

Well, retrieving directory entries form the file system will take more 
longer time than sorting the entries, I suppose...

Anyway, an abstract feature of canceling some kind of creating completion entries
will be required... Please wait!

--
KUBO Hiroya
hi...@sf...

Re: [XNap-Commons-Devel] Completion

[Steffen P. <ste...@gm...>]

Hi,

> We should have internal logic of asynchronous update of completion list
> in case canceling action by hitting Ctrl-G(like emacs minibuffer) or
> something.

Sounds great. Until we have that, I am rather hesitant concerning the sorting 
of the combo box. I guess this will take too much time, when large 
directories like /usr/bin are completed.

Steffen

-- 
Steffen Pingel - ste...@gm... - http://steffenpingel.de

[XNap-Commons-Devel] snapshot release

[Steffen P. <ste...@gm...>]

Hi,

after finally having tackled the maven artifact plugin [1], I have uploaded a 
new snapshot to the repository (this time including a source release): 
http://xnap-commons.sourceforge.net/repository/xnap-commons/jars/. 

I have fixed a few bugs in the table code recently that i want to get into the 
next JHylaFax release...

Steffen


[1] I recommend to install the updated version from 
http://maven.apache.org/start/download.html

-- 
Steffen Pingel - ste...@gm... - http://steffenpingel.de

[XNap-Commons-Devel] Completion

[KUBO H. <hi...@sf...>]

> > This patch contains a new feature of sorting FileCompletion list by
> > filename.
> 
> Sounds cool, we just have to make sure it doesn't become too slow, after all 
> completion is completely handled in the gui thread right now, and for some 
> modes this cannot be changed easily.

OK, in other words, we have to implement this feature as follows:
 (1)Start a sorting thread by SwingUtilities.invokeLater.
 (2)Calling Observer#update to update completion list.

"Whenever possible, you should use invokeLater instead of invokeAndWait."
   http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html#invokeAndWait


The current Completion implementation synchronously(blocking method call) 
updates completion list.

We should have internal logic of asynchronous update of completion list
in case canceling action by hitting Ctrl-G(like emacs minibuffer) or something.

But the external user interface should be synchronous, block user input 
except with canceling action. Later update of completion list may be 
troublesome and embarrassing.
-- 
KUBO Hiroya
hi...@sf...

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[KUBO H. <hi...@sf...>]

Felix,

At Tue, 7 Jun 2005 14:36:59 -0400, Felix Berger wrote:
> 
> Proposition: Instead of allowing to create your own action, just provide a 
> protected method in FileChooserPanel which is called by the FileChooserAction 
> in its actionPerformed method. This way the action's text and icon is always 
> persistent. See DefaultDialog for a similar pattern.

I see.

> I'd still be interested to know why you would like to subclass the action, 
> maybe this would help me better understand your motivation.

Well, I had no special idea about subclassing the action...

But I think it will be required to make subclass of FileChooserDelegator
which delegates method calls to a JFileChooser instances or
an DirectoryChooser instance or something else chooser instance.

http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050608-FileChooserPanel.patch
In this new patch, FileChooserDelegator is separated from FileChooserAction.


       private FileChooserDelegator fileChooserDelegator;
       private FileChooserAction fileChooserAction;

       public void launchFileChooserDialog()
       {
              fileChooserDelegator.launchFileChooserDialog();
       }

       protected class FileChooserDelegator{
              protected JFileChooser fileChooser;
              protected DirectoryChooser directoryChooser;

              ....

	      public void launchFileChooserDialog()
 	      {
                 .....
              }
       }

       private class FileChooserAction extends AbstractXNapAction {
               FileChooserAction() {
                       putValue(ICON_FILENAME, "fileopen.png");
                       putValue(SHORT_DESCRIPTION, I18n.tr("Choose a file"));
               }

               public void actionPerformed(ActionEvent event)
               {
                       launchFileChooserDialog();
               }
      }


...How about this?

KUBO Hiroya
hi...@sf...

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[Felix B. <bf...@gm...>]

On Tuesday 07 June 2005 01:15 pm, you wrote:
> Sorry, my refactoring is not so good. How about this new one?
> http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050608-FileChoose
>rPanel.patch

Proposition: Instead of allowing to create your own action, just provide a 
protected method in FileChooserPanel which is called by the FileChooserAction 
in its actionPerformed method. This way the action's text and icon is always 
persistent. See DefaultDialog for a similar pattern.

I'd still be interested to know why you would like to subclass the action, 
maybe this would help me better understand your motivation.

> This patch contains a new feature of sorting FileCompletion list by
> filename.

Sounds cool, we just have to make sure it doesn't become too slow, after all 
completion is completely handled in the gui thread right now, and for some 
modes this cannot be changed easily.

Thanks for your contributions,
Felix

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[KUBO H. <hi...@sf...>]

Sorry... I had mistake your name, Felix.

> I googled by keyword "ClosableTabbedPane" then I found XNap Commons.
> 
> There are may implementations of ClosableTabbedPane, but most of their
> software licenses are not free or not clearly defined.

Now I try to add "Reordering Tab by Mouse Drag and Drop" to 
ClosableTabbedPane class in XNap Commons. I'll release new patch soon.

KUBO Hiroya
hi...@sf...

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[KUBO H. <hi...@sf...>]

Hi, Flex.

Felix Berger wrote:
> 
> Just out of curiosity how did you learn about XNap Commons?

I googled by keyword "ClosableTabbedPane" then I found XNap Commons.

There are may implementations of ClosableTabbedPane, but most of their
software licenses are not free or not clearly defined.

> I had a look at your patch. It looks decent and extends the FileChooserPanel 
> nicely.

Thanx. 

> A few remarks:
>
> * I did not quite understand the need for the abstract filechooser action, why 
> and how would you overwrite it? Since the action is an inner class it can 
> retrieve the selection mode from the FileChooserPanel, so there is no need to 
> store that information itself. How do you install a different implementation 
> of the action into the panel?

Sorry, my refactoring is not so good. How about this new one?
http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050608-FileChooserPanel.patch

This patch contains a new feature of sorting FileCompletion list by filename.

KUBO Hiroya
hi...@sf...

Re: [XNap-Commons-Devel] Re: FileChooserPanel enhancement

[Felix B. <bf...@gm...>]

Hi Hiroya,

I had a look at your patch. It looks decent and extends the FileChooserPanel 
nicely.

A few remarks:

* Maybe we could reuse the constants from JFileChooser, otherwise they should 
be documented.

* I did not quite understand the need for the abstract filechooser action, why 
and how would you overwrite it? Since the action is an inner class it can 
retrieve the selection mode from the FileChooserPanel, so there is no need to 
store that information itself. How do you install a different implementation 
of the action into the panel?

Regards,
Felix

Re: [XNap-Commons-Devel] FileChooserPanel enhancement

[Felix B. <bf...@gm...>]

On Saturday 04 June 2005 01:10 am, Hiroya KUBO wrote:

> XNap-Commons is very cool!

Thanks! Just out of curiosity how did you learn about XNap Commons?

> BTW, I would like to contribute a patch (to current cvs version of
> xnap-commons):
> http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050604-FileChoose
>rPanel.patch
>
> It improves usability of FileChooserPanel.
>  * You can choose a file by drag an icon on your desktop and drop it in
> JTextField on FileChooserPanel. * DirectoryChooesr dialog will be popup
> when FileChooserPanel#setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY)
> has called.
>
> I will be happy if my code fragment can be a part of your freesoftware
> distribution.

Thanks for your patch, I'll try to have a look at it within the next few days.

Regards,
Felix

[XNap-Commons-Devel] Re: FileChooserPanel enhancement

[KUBO H. <hi...@cu...>]

Sorry! I found several bugs...

> BTW, I would like to contribute a patch (to current cvs version of xnap-commons):
> http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050604-FileChooserPanel.patch
> 
> It improves usability of FileChooserPanel. 
>  * You can choose a file by drag an icon on your desktop and drop it in JTextField on FileChooserPanel.
>  * DirectoryChooesr dialog will be popup when FileChooserPanel#setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY) has called.


fixed version is here:

http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050604-2-FileChooserPanel.patch

--
Hiroya KUBO 
hi...@sf...

[XNap-Commons-Devel] FileChooserPanel enhancement

[Hiroya K. <hi...@sf...>]

Hi, All.

XNap-Commons is very cool!
The UI class library implementation is higly usefull to me. Thanks a lot!

BTW, I would like to contribute a patch (to current cvs version of xnap-commons):
http://sqs.cmr.sfc.keio.ac.jp/tdiary/files/xnap-commons-20050604-FileChooserPanel.patch

It improves usability of FileChooserPanel. 
 * You can choose a file by drag an icon on your desktop and drop it in JTextField on FileChooserPanel.
 * DirectoryChooesr dialog will be popup when FileChooserPanel#setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY) has called.

I will be happy if my code fragment can be a part of your freesoftware distribution.

Best regards,
--
Hiroya KUBO 
hi...@sf...

[XNap-Commons-Devel] CloseableTabbedPane stack trace

[Chris M. <ch...@st...>]

I have just tried CloseableTabbedPaneExample.java with 
xnap-commons-0.9-SNAPSHOT.jar and get this stack trace as I close the tabs from 
right to left. The first one closes fine, but the 2nd one stack traces.

- Chris

<<<<
"C:\Program Files\Java\jdk1.5.0\bin\java" -Didea.launcher.port=7537 
-Didea.launcher.library=C:\IntelliJ-IDEA-4.5\bin\breakgen.dll 
-Dfile.encoding=windows-1252 -classpath "C:\Program 
Files\Java\jdk1.5.0\jre\lib\jce.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\charsets.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\javaws.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\deploy.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\plugin.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\jsse.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\rt.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\ext\dnsns.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\ext\sunjce_provider.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\ext\sunpkcs11.jar;C:\Program 
Files\Java\jdk1.5.0\jre\lib\ext\localedata.jar;C:\dev\classes;C:\sdz-zone\lib\Renderers.jar;C:\sdz-zone\lib\app-images.jar;C:\sdz-zone\lib\activation.jar;C:\sdz-zone\lib\jdo-config-remote-linode-teresa-prod-mysql.jar;C:\sdz-zone\lib\jdo-config-remote-debian-teresa-dev-mysql.jar;C:\sdz-zone\lib\mail.jar;C:\sdz-zone\lib\dsgnr-images.jar;C:\sdz-zone\lib\hsqldb.jar;C:\sdz-zone\lib\license.jar;C:\sdz-zone\lib\Date_selector.jar;C:\sdz-zone\lib\servlet.jar;C:\sdz-zone\lib\junit.jar;C:\sdz-zone\lib\jta.jar;C:\sdz-zone\lib\xml-apis.jar;C:\sdz-zone\lib\TableLayoutPersistenceDelegate.jar;C:\sdz-zone\lib\TableLayout.jar;C:\sdz-zone\lib\foxtrot.jar;C:\sdz-zone\lib\jdo-config-remote-debian-teresa-prod-mysql.jar;C:\sdz-zone\lib\jakarta-regexp-1.3.jar;C:\sdz-zone\lib\log4j-1.2.9.jar;C:\sdz-zone\lib\mysql-connector-java-3.0.15-ga-bin.jar;C:\sdz-zone\lib\jdo.jar;C:\sdz-zone\lib\jdogenie.jar;C:\sdz-zone\lib\openaccess.jar;C:\sdz-zone\lib\wr-sdz-dt-files.jar;C:\sdz-zone\lib\wr-jdo-meta.jar;C:\s
dz-zone\lib\wr-prod-properties.jar;C:\sdz-zone\lib\jdo-config-local-client-wombat-test-mysql.jar;C:\sdz-zone\lib\jdo-config-local-client-teresa-prod-mysql.jar;C:\sdz-zone\lib\mvnforum-properties.jar;C:\sdz-zone\lib\jpox-1.1.0-beta-2.jar;C:\sdz-zone\lib\jdo-config-local-demo-wombat-test-mysql.jar;C:\sdz-zone\lib\MDateSelector.jar;C:\sdz-zone\lib\xnap-commons-0.9-SNAPSHOT.jar;C:\IntelliJ-IDEA-4.5\lib\idea_rt.jar" 
com.intellij.rt.execution.application.AppMain example.CloseableTabbedPaneExample
Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 2
	at 
javax.swing.plaf.basic.BasicTabbedPaneUI.getTabBounds(BasicTabbedPaneUI.java:1313)
	at 
javax.swing.plaf.basic.BasicTabbedPaneUI.getTabBounds(BasicTabbedPaneUI.java:1248)
	at 
javax.swing.plaf.basic.BasicTabbedPaneUI$Handler.mousePressed(BasicTabbedPaneUI.java:3217)
	at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:222)
	at java.awt.Component.processMouseEvent(Component.java:5485)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3093)
	at java.awt.Component.processEvent(Component.java:5253)
	at java.awt.Container.processEvent(Container.java:1966)
	at java.awt.Component.dispatchEventImpl(Component.java:3955)
	at java.awt.Container.dispatchEventImpl(Container.java:2024)
	at java.awt.Component.dispatchEvent(Component.java:3803)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
	at java.awt.Container.dispatchEventImpl(Container.java:2010)
	at java.awt.Window.dispatchEventImpl(Window.java:1766)
	at java.awt.Component.dispatchEvent(Component.java:3803)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
	at 
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 1
	at 
javax.swing.plaf.basic.BasicTabbedPaneUI.getTabBounds(BasicTabbedPaneUI.java:1313)
	at 
javax.swing.plaf.basic.BasicTabbedPaneUI.getTabBounds(BasicTabbedPaneUI.java:1248)
	at 
javax.swing.plaf.basic.BasicTabbedPaneUI$Handler.mousePressed(BasicTabbedPaneUI.java:3217)
	at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:222)
	at java.awt.Component.processMouseEvent(Component.java:5485)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3093)
	at java.awt.Component.processEvent(Component.java:5253)
	at java.awt.Container.processEvent(Container.java:1966)
	at java.awt.Component.dispatchEventImpl(Component.java:3955)
	at java.awt.Container.dispatchEventImpl(Container.java:2024)
	at java.awt.Component.dispatchEvent(Component.java:3803)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
	at java.awt.Container.dispatchEventImpl(Container.java:2010)
	at java.awt.Window.dispatchEventImpl(Window.java:1766)
	at java.awt.Component.dispatchEvent(Component.java:3803)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
	at 
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
	at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Process finished with exit code 0
 >>>>

-- 
www.strandz.org

For matching users to their data.

Re: [XNap-Commons-Devel] release vorbereitungen

[Steffen P. <ste...@gm...>]

Hi,

> Meine Frage war, ob es noch moeglich waere, zu checken, ob das uebergebene
> table model in
> TableLayout ein TableSorter ist, und fuer andere models nur das column
> ordering und das
> tableheader menu anzubieten ohne die sortierung?

Ah, jetzt verstehe ich. Das k=F6nnte man durchaus =FCberlegen.

> Wenn das ein paar exceptions ueberfluessig machen wuerde, waere es
> vielleicht ganz nett, die default classen
> werden zur zeit eh geladen, da ich EmacsCompletionMode.class.getName() et=
c.
> benutze.

Viele Exceptions wird das nicht sparen (ausser ClassNotFound), aber das die=
=20
Klassen eh geladen werden ist ein Punkt. Mich w=FCrde vor allem interessier=
en=20
wieviel Zeilen Code das spart.

Steffen

=2D-=20
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] release vorbereitungen

[Tammo v. L. <tva...@ta...>]

Hi,

> PS: Schaue micht jetzt mal nach blog moeglichkeiten um, wenn ihr vorsch=
laege
> habt, wuerde es vielleicht
> auch gerne auf meinem server laufen lassen, damit es etwas privat ist.
s9y, wordpress - im englischen wikipedia gibts ne =FCbersicht.

Gru=DF,
   Tammo

Re: [XNap-Commons-Devel] release vorbereitungen

[Felix B. <bf...@gm...>]

>Ja, der TableSorter ist eine Art Mediator zwischen View und eigentlichem
>Modell. Dadurch, dass an ein TableModel delegiert wird, kann man bestehende
>Applikationen ganz leicht umbauen in dem man einfach noch einen TableSorter
>instanziert, dem man das bestehende Model übergibt. Ich finde das nett, da
>die Sortierung eigentlich Teil des View ist.

Das ist auf jeden Fall die bessere Loesung gegenueber der
Ableitungshierarchie,
so kann man sortierung einfach dazu pluggen, ohne alle alten table models
aendern
zu muessen.

Meine Frage war, ob es noch moeglich waere, zu checken, ob das uebergebene
table model in
TableLayout ein TableSorter ist, und fuer andere models nur das column
ordering und das
tableheader menu anzubieten ohne die sortierung?

>Ich habe noch überlegt der Completion Factory Class Objekte zu übergeben.
Das
>würde mit Java 5.0 jegliche Casts einsparen und sähe im Code sehr nett aus.
>Der Nachteil wäre, daß der ClassLoader jede Completion Klasse schon bei der
>Anmeldung bei der Factory laden würde, obwohl die eigentliche Klasse noch
>nicht benutzt würde. Wobei das Setting letztendlich eh einen Klassennamen
>speichern würde, wobei man den wiederrum in der Factory auf das Class
Objekt
>mappen könnte...

Wenn das ein paar exceptions ueberfluessig machen wuerde, waere es
vielleicht ganz nett, die default classen
werden zur zeit eh geladen, da ich EmacsCompletionMode.class.getName() etc.
benutze.

Gruss,
Felix

--
Steffen Pingel - ste...@gm... - http://steffenpingel.de


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r
_______________________________________________
xnap-commons-devel mailing list
xna...@li...
https://lists.sourceforge.net/lists/listinfo/xnap-commons-devel

[XNap-Commons-Devel] Tutorial

[Steffen P. <ste...@gm...>]

Hi,

es gibt eine erste Version des Tutorials. Das ganze ist als kurz Einf=FChru=
ng=20
gedacht und soll durch die Beispiele und die API Dokumentation erg=E4nzt=20
werden:

http://xnap-commons.sourceforge.net/tutorial/index.html

=46alls jemand Lust hat etwas hinzuzuf=FCgen oder zu =E4ndern, go ahead.=20

Steffen

=2D-=20
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] release vorbereitungen

[Steffen P. <ste...@gm...>]

Hi,

> > Ich habe bei allen
> >source files LGPL Header eingef=FCgt und den jeweiligen Autor als Copyri=
ght
> >Holder eingetragen.=20
>
> Wie wichtig ist das? Ich denke, ich habe es meistens dazu geschrieben.

Mir ist es nicht so wichtig, aber dem jeweiligen Urheber vielleicht schon :=
).=20
Ich meinte nicht die @author Tags, sondern "Copyright by..." im LGPL Header.

> Das Decorator pattern von TableSorter gefaellt mir sehr, auch TableLayout.
> Frage: braucht TableLayout
> wirklich das TableSorter Interface, oder wuerde auch ein TableModel
> reichen?

Ja, der TableSorter ist eine Art Mediator zwischen View und eigentlichem=20
Modell. Dadurch, dass an ein TableModel delegiert wird, kann man bestehende=
=20
Applikationen ganz leicht umbauen in dem man einfach noch einen TableSorter=
=20
instanziert, dem man das bestehende Model =FCbergibt. Ich finde das nett, d=
a=20
die Sortierung eigentlich Teil des View ist.=20

Ich habe noch =FCberlegt der Completion Factory Class Objekte zu =FCbergebe=
n. Das=20
w=FCrde mit Java 5.0 jegliche Casts einsparen und s=E4he im Code sehr nett =
aus.=20
Der Nachteil w=E4re, da=DF der ClassLoader jede Completion Klasse schon bei=
 der=20
Anmeldung bei der Factory laden w=FCrde, obwohl die eigentliche Klasse noch=
=20
nicht benutzt w=FCrde. Wobei das Setting letztendlich eh einen Klassennamen=
=20
speichern w=FCrde, wobei man den wiederrum in der Factory auf das Class Obj=
ekt=20
mappen k=F6nnte...=20

> PS: Schaue micht jetzt mal nach blog moeglichkeiten um, wenn ihr
> vorschlaege habt, wuerde es vielleicht
> auch gerne auf meinem server laufen lassen, damit es etwas privat ist.

Bin schon gespannt... www.blogger.com, aber Privat ist das nicht.

Steffen

=2D-=20
Steffen Pingel - ste...@gm... - http://steffenpingel.de