[JDIC-61] Add taskBar Notification in Tray API Created: 20/Jul/04  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Improvement Priority: Blocker
Reporter: armoghan Assignee: bino_george
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 61

 Description   

It would be a great feature if Skinable Taskbar Notification is added in Tray
Icon functionality like MSN or Yahoo.



 Comments   
Comment by georgez [ 20/Jul/04 ]

Reassigned to the right subcomponent.

Comment by georgez [ 20/Jul/04 ]

Reassigned to Bino George, which is maintaining the Tray Icon incubator project.

Comment by georgez [ 08/Jan/05 ]

Reassigned to the "JDIC API (package org.jdesktop.jdic.tray)" subcomponent, as
from release 0.8.6, Tray Icon code/API was incorporated into JDIC. The "tray"
subcomponent is deleted.

Comment by georgez [ 08/Jan/05 ]

Reassigned to the "JDIC API (package org.jdesktop.jdic.tray)" subcomponent, as
from release 0.8.6, Tray Icon code/API was incorporated into JDIC. The "tray"
subcomponent is deleted.

Comment by georgez [ 03/Mar/05 ]

Should be an "Enhancement".





[JDIC-94] Packager doen't work Created: 20/Sep/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: conny Assignee: joey_shen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: PC


Attachments: Text File resourcePath.patch    
Issuezilla Id: 94

 Description   

On Solairs jnlp2pkg command dose not work, the error message is: resource path
could not be null. On Linux the same thing happens.



 Comments   
Comment by joey_shen [ 20/Sep/04 ]

This is a regression introduced by the extension patch trying to fix issue 89.
Actually, only the local jnlp resourcepath input will be affected. remote jnlp
packager works fine. I'll submit a patch in a few minute.

Comment by joey_shen [ 20/Sep/04 ]

Created an attachment (id=63)
patch for this issue

Comment by conny [ 22/Sep/04 ]

On Solaris remote jnlp packager dose not work, following messages were printed
on the terminal: Cannot copy local directory: Cannot create new local file





[JDIC-164] Action.execute() does not check execution right Created: 18/Jan/05  Updated: 06/Feb/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.filetypes)
Affects Version/s: Branch-Issue_74-78
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: HTML File secureExec    
Issuezilla Id: 164

 Description   

I have some security concerns about Action.execute(). This method should at
least call SecurityManager.checkExec().

The current UnixLaunchUtility and WinAssociationProvider could use
Runtime.exec() instead of native methods – this might be preferable.



 Comments   
Comment by paul_huang [ 24/Jan/05 ]

Chas,

Could you please help to make a patch for this issue?

Thanks

-Paul

Comment by chas [ 25/Jan/05 ]

We can't use Runtime.exec() because we want a new console and the new process
should be detached from this one.

Next patch adds security to both UnixLaunchUtility and WinAssociationProvider:

+ final SecurityManager security = System.getSecurityManager();
+ if (security != null)
+ security.checkExec(path);

Additionally, the WinAssociationProvider was reworked: %1 is expanded to a 8.3
filename; %L is expanded to a long filename. The security.checkExec() method is
always given the long filename of the executable.

Comment by chas [ 25/Jan/05 ]

Created an attachment (id=141)
add SecurityManager.checkExec() before process creation

Comment by paul_huang [ 06/Feb/05 ]

Patch accepted. Check into CVS branch.





[JDIC-172] Scrollbars not appearing in Mozilla 1.7.5, JDIC 0.8.7 Created: 26/Jan/05  Updated: 10/Jul/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: mnooney Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC


Issuezilla Id: 172

 Description   

When i installed Mozilla 1.7.5 and embedded it the scrollbars disappeared.
However the scrollbars work fine on Mozilla 1.4.1. JDIC 0.8.7 was used.

See posts on discussion forum from miken Jan 25, 2005 11:02 PM.
Also tgore04 on Jan 19, 2005 6:52 PM.



 Comments   
Comment by michael_shan [ 03/Mar/06 ]

Assign to Michael.

Comment by michael_shan [ 21/Jun/06 ]

Have reproduced it with mozilla.

Comment by michael_shan [ 10/Jul/06 ]

Another related issue.
http://forums.java.net/jive/thread.jspa?threadID=16511&tstart=15

Comment by michael_shan [ 10/Jul/06 ]

Just FYI.
This issue is caused by missing components of Gecko. Version of mozilla 1.8a1
works well.
A bug should be filed to mozilla build. I'll close this issue after the bug is
filed.





[JDIC-240] Design tasks - Pluggable Service Providers with Mustang Created: 21/Mar/05  Updated: 25/Jan/11

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: Task Priority: Blocker
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JDIC-220 Desktop API Tuning for Mustang Open
Issuezilla Id: 240

 Description   

The api/spi pluggable providers as implemented in Issue_74-78 envision a single
provider instance and static api methods. Issue 220 requests instance methods
on each service.

Will each service.getInstance() method return a singleton, or will multiple
service instances be created?

If/when the spi plug point is added, is there going to be a single provider
instance or a provider instance per service instance?

An additional factor affecting these decisions is the desire to run in a
classloader container environment such as JPF. (Look at issue 235)



 Comments   
Comment by paul_huang [ 21/Mar/05 ]

Good questions, Chas. I am now working on the code to merge the branch
Issue_74-78 into the trunk, plus to apply the API changes introduced in Issue 220.

Actually, I am now just considering these questions. What would be your suggestion?

Comment by paul_huang [ 21/Mar/05 ]

I looked at the refactoring code from branch Issue_74-78 again and realized that
in this implementation, we actually obtained a singleton provider instance and
use this instance to invoke each method. If I am right, this should help to
avoide the limitation that "Static methods limit the potential of extension in
the future.". We can still "manage appcontext-sensitive configuration settintgs,
enforce security, etc. "

If this is the case, we can still keep using the static method invocation.

What's your idea, Chas?

Correct me if I am wrong.

Comment by chas [ 22/Mar/05 ]

I believe this will work for simple containers such as webstart or applet. We
would have problems in a EJB or servlet container, particularly with hot-deploy
applications. On the other hand, I doubt that EJBs or servlets are going to
need desktop services.

Can you imagine any scenario where a single application instance is going to
need multiple behaviors (either security or configuration)?

We'll want to minimize the number of expensive security checks. I think this
can be done once in each provider factory. I doubt security policies would
change based upon the thread.

The related issue 235 is that the delayed provider class loading occurs in the
AWT thread which does not have the same thread context classloader as the main
application thread and therefore cannot find the provider. The JPF framework
has a similar problem with Swing Look&Feel resources, so I am not sure we need
to change the SPI pattern to solve this issue. Additionally, this problem will
also go away if the jdic classes are loaded by the system classloader.

Comment by paul_huang [ 22/Mar/05 ]

This is the feedback from the AWT team.

"I think you need to just make another small step from the hidden, private
factory to a public factory, which Desktop.getDesktop is actually.

I am not saying you need to do this for JDIC Desktop package, but J2SE API
should have such a design."





[JDIC-254] WebBrowser doesn't pass cookies to popup - session lost Created: 12/Apr/05  Updated: 10/Jul/06

Status: Reopened
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: btknorr Assignee: michael_shan
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: Text File issue254_patch.diff    
Issuezilla Id: 254

 Description   

When using the WebBrowser api against a web application and the IE Browser
spawns a child popup window via javascript or some other means, the new child
browser window doesn't have a session. And in our web application this causes
the child window to go to a login screen – this issue is stopping us from
using the WebBrowser api.

This issue orginated by yangui:
http://www.javadesktop.org/forums/thread.jspa?messageID=71054&#71054



 Comments   
Comment by georgez [ 23/May/05 ]

Based on Stu Pond's fix, I created and attached a patch file (issue254_patch.diff).
The fix introduces one new class CBrowserFrameWindow to create and manage a
popup child window, which will reuse the session id of its parent windows.

Thanks, Pond !

Comment by georgez [ 23/May/05 ]

Created an attachment (id=188)
Pass parent window session ID to popup window.

Comment by armin_chen [ 13/Oct/05 ]

To solve this problem, we have to handle below event for IE:
DWebBrowserEvents2::NewWindow2 Event

There is some similar event for Mozilla.

Comment by michael_shan [ 24/Jan/06 ]

Assign to Michael

Comment by michael_shan [ 25/Jan/06 ]

Another post related with this issue.
http://www.javadesktop.org/forums/post!reply.jspa?messageID=68313

Comment by michael_shan [ 25/Jan/06 ]

Another post related with this issue.
http://www.javadesktop.org/forums/post!reply.jspa?messageID=68313

Comment by michael_shan [ 19/Jun/06 ]

Has been fixed in build20060613.

Comment by michael_shan [ 10/Jul/06 ]

Post http://forums.java.net/jive/thread.jspa?messageID=131355&#131355.
We are struggling with the "window.open loses cookie knowledge of opener" issue.
The recently released June build now opens new windows with the correct cookie
info, but they are:

1) Wrapped in a Java frame
2) Have 0,0 size.

Is there a way to call a "window.open" event in a WebBrowser object, and have
the new opening window be a valid IE frame in its own right, but with the cookie
knowledge of the Webbrowser frame?

Good work on this guys!





[JDIC-295] Problem with extension-tag Created: 29/Jun/05  Updated: 29/Jun/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: madsheep Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 295

 Description   

The situation:

  • The main-jnlp is created by a servlet in the address:
    localhost/dir1/DownloadServlet
  • The extension-jnlp is created by a servlet in the address:
    localhost/dir1/ExtensionDownload.jnlp
  • All jars (including the ones from the extension) will be downloaded from:
    localhost/dir2 (Not sure if that's important but more informations won't harm)

The problem:
The packager creates a temp-directory where it copies the two jnlps and a
subdirectory 'dir2' where it copies the jar-files. Later it tries to find the
extension-jnlp in the subdirectory 'dir1', where it can't be:

java.io.FileNotFoundException:
C:\DOKUME~1\jschoder\LOKALE~1\Temp\jnlp54162jnlp\dir1\ExtensionDownload.jnlp
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at
com.sun.javaws.net.BasicNetworkLayer.doRequest(BasicNetworkLayer.java:164)
at
com.sun.javaws.net.BasicNetworkLayer.doGetRequest(BasicNetworkLayer.java:92)
at
com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(LaunchDescFactory.java:77)
at
org.jdesktop.jdic.packager.impl.JnlpPackageInfo.addJnlpRefFilePaths(Unknown Source)
at
org.jdesktop.jdic.packager.impl.JDICPackagerFileRefVisitor.visitExtensionDesc(Unknown
Source)
at com.sun.javaws.jnl.ExtensionDesc.visit(ExtensionDesc.java:80)
at com.sun.javaws.jnl.ResourcesDesc.visit(ResourcesDesc.java:490)
at
org.jdesktop.jdic.packager.impl.JnlpPackageInfo.addJnlpRefFilePaths(Unknown Source)
at
org.jdesktop.jdic.packager.impl.JnlpPackageInfo.parseLocalJnlpInfo(Unknown Source)
at
org.jdesktop.jdic.packager.impl.JnlpPackageInfo.parseRemoteJnlpInfo(Unknown Source)
at org.jdesktop.jdic.packager.impl.Jnlp2Package.parseArguments(Unknown
Source)
at org.jdesktop.jdic.packager.impl.Jnlp2Package.generatePackage(Unknown
Source)
at org.jdesktop.jdic.packager.Jnlp2Msi.main(Unknown Source)






[JDIC-348] JDIC browser doesn't support heavyweight container hierarchy change Created: 06/Jan/06  Updated: 19/Jun/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: lilianc Assignee: michael_shan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 348

 Description   

The JDIC Browser doesn't support changing its heavyweight ancestor : I'm
properly posting this issue here as the JDIC forum might not be the best place
to leave it (I reported the probem there 6 months ago).

Here's a test case showing the problem with a JFrame and a JDialog, but the
problem is the same ** when moving from an AWT Panel to another one **.

This feature is used in VLDocking and probably other docking systems to allow
embedding the JDIC Browser within lightweight components. It works well with
other heavywieght components (like JOGL or Open CASCADE 3D renderers) but fails
with JDIC Browser.

Best regards,

Lilian Chamontin, VLSolutions.

---------------------------------

Source Code :

package test.swing.docking;

import java.awt.*;
import java.awt.event.*;
import java.net.URL;
import javax.swing.*;
import org.jdesktop.jdic.browser.WebBrowser;

/** Test case showing wrong behaviour of WebBrowser when container hierarchy
change occurs.
*

  • To reproduce the bug, click on the Detach button. The webbrower will (well,
    should) be detached
  • from its parent frame and put into another window.
    *
  • Here the problem seems to be due to a change of the native parent peer (from a
    jframe to
  • a jdialog).
    *
  • If you move the JDialog you will see the browser moving... inside the JFrame !
    *
  • I have also experimented the same problem when I insert a Panel (awt) in
    between the hierarchy
  • (thus also changing the native parent of the browser).
    *
  • @author Lilian Chamontin, VLSolutions
    */
    public class TestJDIC2 extends JFrame {
    WebBrowser browser;

JPanel center = new JPanel(new BorderLayout());

public TestJDIC2() {
setDefaultCloseOperation(EXIT_ON_CLOSE);
add(center, BorderLayout.CENTER);
add(new JLabel("left"), BorderLayout.WEST);
add(new JLabel("bottom"), BorderLayout.WEST);
add(new JLabel("right"), BorderLayout.EAST);

try {
URL url = new URL("http://www.google.com");

browser = new WebBrowser(url, false);
center.add(browser, BorderLayout.CENTER);
} catch (Exception e){
e.printStackTrace();
}

JButton detach = new JButton("Detach");
detach.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e)

{ center.remove(browser); JDialog dlg = new JDialog(TestJDIC2.this); dlg.getContentPane().add(browser, BorderLayout.CENTER); dlg.setSize(new Dimension(400,300)); dlg.validate(); dlg.setVisible(true); center.revalidate(); } }); add(detach, BorderLayout.NORTH); center.setPreferredSize(new Dimension(800,600)); pack(); setVisible(true); }

public static void main(String[] args){
new TestJDIC2();
}
}



 Comments   
Comment by michael_shan [ 06/Jan/06 ]

Hi Lilian,
Thank you for your reporting.
At first glance,I don't think it's a webBrowser problem but a problem of Canvas
or the way we use it.
A component refer a component then put the refered component into another
component(though we've removed it,but will it works as we thought?), is that
operation ok? I'm not sure of that.

Comment by lilianc [ 06/Jan/06 ]

Hi Michael,

The code posted here works fine with any Swing or AWT component, and also works
with canvases like the GLCanvas from JOGL... There's nothing uncommon in it,
it's just an AWT component reparenting.

Reparenting a component (beeing awt or swing) is something found in every
advanced application (for example, extracting a component from a window to give
it more room on screen or mergeing two components in a tabbed pane).

The problem here occurs only if the hierarchy change involves an AWT container
(Frame, Panel), but works fine with a swing JPanel (e.g. when swapping two
JSplitPane components).

Lilian

Comment by michael_shan [ 23/Jan/06 ]

Hi,
Change "browser = new WebBrowser(url, false)"; to "browser = new WebBrowser(url,
true);"
Pls refer the javadoc :
/**

  • Constructs a new <code>WebBrowser</code> with an specified URL and
  • boolean flag to indicate the dispose schema.
  • @param url
  • the URL to be shown in this instance.
  • @param autoDispose
  • ture to indicate this instance will automatically dispose
  • itself in <code>removeNotify()</code>; false to indicate
  • the developer should call <code>dispose()</code> when this
  • instance is no longer needed.
  • @see #removeNotify()
  • @see #dispose()
  • @see #isAutoDispose()
    */
    public WebBrowser(URL url, boolean autoDispose) {........}
Comment by lilianc [ 25/Jan/06 ]

The problem is that the browser shoudn't be auto-disposed !

If the user is in the middle of filling a form, the form will be cleared when
changing of parent (the page is reloaded) : this is unacceptable for our
customers...

(and if some applets are running in the web page, they will be destroyed as well).

Comment by michael_shan [ 19/Jun/06 ]

Assign to Michael.





[JDIC-413] Not possible to create a screenshot in init() method Created: 13/Jul/06  Updated: 13/Jul/06

Status: Open
Project: jdic
Component/s: Screensavers
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Improvement Priority: Blocker
Reporter: normanfo Assignee: markroth8
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 413

 Description   

In the screensaver's init() method it is not possible to create a screenshot
using java.awt.Robot (win xp). The screen is always black before the actual
screenshot can be taken. Some screensavers might want to use the current desktop
image and perform some visual manipulation of it.






[JDIC-442] WebBrowser not work in Win98 Created: 11/Oct/06  Updated: 18/Dec/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Improvement Priority: Blocker
Reporter: maicon_b Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 98
Platform: PC


Issuezilla Id: 442

 Description   

The WebBrowser, in the new jdic version, not work in my Windows98 with IE6.

Command: java -cp ".;jdic.jar;demo/Browser" Browser
Return: Can't connect to the native embedded browser.
Error message: Maximum retry number reached!



 Comments   
Comment by maicon_b [ 25/Oct/06 ]

The new version does not support Windows 98.
Some old versions running properly.

Comment by michael_shan [ 31/Oct/06 ]

Hi Maicon,
It maybe caused by the nspr4.dll was removed. With the latest jdic version, you
can try to put "ielib" folder,which contains the dll, under the same folder of
jdic.jar to see if it can work well under win98. If it does, we'll contain the
folder for our new version. Thanks!

Michael

Comment by maicon_b [ 01/Nov/06 ]

Hi Michael,
I already tried this, with and without the 'ielib' folder,
with 2 copies of the nspr4.dll, one in /jdicfolder/ and the other
in /jdicfolder/ielib. But...
result: not work...

Thanks,
Maicon

Comment by michael_shan [ 02/Nov/06 ]

Hi Maicon,
Perhaps more debug/error info will be helpful, will you please dump that? And I
have to admit that I have no experience of running JDIC under win98 either I'm
not sure if it can run well.

Michael

Comment by maicon_b [ 03/Nov/06 ]

The following debug info is from the last version (20061102):

      • Jtrace: Envent Thread run once!
      • Jtrace: Msg Client new once!
      • Jtrace: Specified browserManager null
      • Jtrace: Default browserManager is used.
      • Jtrace: Found a free socket port: 1263
        native lib path C:\WINDOWS\Desktop\jdic-20061102-bin-win\windows*** Jtrace:
        init share native.....
      • Jtrace: nspr4.dll under C:\WINDOWS\Desktop\jdic-20061102-bin-
        win\windows\ielib is set to PATH
      • Jtrace: Engine initialize once!
        native lib path C:\WINDOWS\Desktop\jdic-20061102-bin-win\windows*** Jtrace:
        Executing C:\WINDOWS\Desktop\jdic-20061102-bin-win\windows\IeEmbed.exe -
        port=1263
      • Jtrace: Connecting to native browser ... 0
      • Jtrace: java.net.ConnectException: Connection refused: no further
        information
      • Jtrace: Connecting to native browser ... 1
      • Jtrace: java.net.ConnectException: Connection refused: no further
        information
      • Jtrace: Connecting to native browser ... 2
        ...
      • Jtrace: java.net.ConnectException: Connection refused: no further
        information
      • Jtrace: Connecting to native browser ... 29
      • Jtrace: java.net.ConnectException: Connection refused: no further
        information
        Can't connect to the native embedded browser. Error message: Maximum retry
        number reached!

Thank you very much!
Maicon

Comment by maicon_b [ 06/Nov/06 ]

Look the following logs:

Pieces of Debug:

      • Jtrace: Found a free socket port: 1094
      • Jtrace: Executing C:\WINDOWS\Desktop\jdic\IeEmbed.exe -port=1094

Netstat -an: (connections created by jdic - Browser)
Proto Local Address Extern Address State
TCP 0.0.0.0:1093 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1102 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1092 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1092 127.0.0.1:1093 ESTABLISHED
TCP 127.0.0.1:1093 127.0.0.1:1092 ESTABLISHED
->TCP 127.0.0.1:1102 127.0.0.1:1094 SYN_SENT

The 127.0.0.1:1094 (from the last line) must not be a Extern, but a Local
Address... as in win XP

Thanks
Maicon

Comment by maicon_b [ 06/Nov/06 ]

If you go to windows XP command and type "ieEmbed -port=5555 <enter>" the
netstat inform a Listening port until any other program begin and finalize a
connection with the ieEmbed (ex: putty).

But on windows 98, the listining stay for more/less 10 seconds and it dies when
the ieEmbed is from the 0.9 version... And when the ieEmbed.exe is from the
0.9.1 version, the netstat not even shows the Listening.

Netstat shows: TCP 127.0.0.1:5555 0.0.0.0:0 LISTENING

Thanks,
Maicon

Comment by maicon_b [ 18/Dec/06 ]

Is possible to trace the differences between the new (0.9.1) and the old (0.9)
version of IeEmbed.exe ?
Is possible to create one compatible .exe with windows 98, analyzing the
differences ?

Thanks,
Maicon





[JDIC-446] Build has a dependency that breaks on Mac OS Created: 13/Oct/06  Updated: 19/Oct/06

Status: Open
Project: jdic
Component/s: Misc Project
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: robross Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File build.xml.patch    
Issuezilla Id: 446

 Description   

The instructions for building this project (as given here:
https://jdic.dev.java.net/documentation/README.html#Build%20the%20Source

include this instruction:

Set javaws.jar to the class path, which is under jre_home/lib for java5+ and
jre/javaws for java1.4.2.

There is no such jar file in either the 1.4 or 1.5 JDK implementations on the
Mac; therefore it is impossible to build as-is on a Mac.

A work-around is to copy this jar file from a Windows JDK to the Mac.

However, this should not be a build dependency. If some functionality is
required from that lib that is not provided on all platforms, it needs to be
part of the source or lib distribution of the JDIC project so it can build on a Mac.

Rob Ross



 Comments   
Comment by lordy [ 19/Oct/06 ]

Not quite right, Mac OS X comes with javaws.jar file, you only need to find it: /Applications/Utilities/Java/
J2SE\ 5.0/Java\ Cache\ Viewer.app/Contents/MacOS/lib/javaws.jar

But it is right we should fix this problem that other user simple can use "ant buildall" without changing
build.xml by hand.

So please Michael import my patch.

Comment by lordy [ 19/Oct/06 ]

Created an attachment (id=254)
patch which add javaws.jar to classpath for Mac OS X

Comment by michael_shan [ 19/Oct/06 ]

Hi Chris,
I think we should let users specify the javaws.jar's location, since we can't
write version dependent info into the build.xml,thus,if users use different
version java,they will still meet errors, right?
Instead of doing that,I think it's better to clarify that clearly in the readme
to tell users to set the javaws.jar's location correctly,of course,correct path
of java5.0's will be given as a sample. Any suggestions? Thanks!

Michael

Comment by robross [ 19/Oct/06 ]

I think using a build.properties file might be helpful. In my own projects, I
use a build.properties file that is read by the main build.xml file, and I
include things that might be build-environment-dependent, so that it's easy to
tweak the build.properties file without having to change the build.xml file. For
example, on my webapp projects one of the properties might be tomcat.dir; thus,
I don't have to expect a specific location in the build.xml file, but each
developer can just write where their particular tomcat directory is located.

You could get the location of the javaws.jar file from this file, and then the
developer trying to build only has to adjust that property (or a small set of
properties).

Rob

Comment by michael_shan [ 19/Oct/06 ]

Yes, you're right. In fact,we use .bat or .sh file to set environment first then
call build.xml to build jdic. We'll upload them to the cvs.





[JDIC-453] JDIC hangs WINWORD when close Created: 03/Nov/06  Updated: 17/Nov/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: sergio_av Assignee: michael_shan
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 453

 Description   

build: jdic-20060308-bin-windows
testcase: browser (included demo)

When an MS Word Document is opened by Browser demo app an instance of
WINWORD.exe can be found in the task manager. The word document is showed
correctly, but if you close the demo Browser app, WINWORD.exe still remains in
execution. Therefore if you execute again the Browser demo app and you attempt
to load the same MS Word Document a grey page will appear.

I have tried with other WebBrowser control client applications and I see
WINWORD.exe stops execution when the word document is closed.



 Comments   
Comment by sergio_av [ 09/Nov/06 ]

The same error with EXCEL files. I suppose this will happen to all kind of
documents opened from an extern process server ActiveX like WINWORD.exe and
EXCEL.exe.

Comment by sergio_av [ 16/Nov/06 ]

Any comment about this issue?

Comment by michael_shan [ 17/Nov/06 ]

Hi,
I've reproduced this issue. While the dealing of opening native apps are done by
Gecko,which we still don't know how to let it close them when exit. We still
need investigate on that and maybe mozilla guys know that better ..

thanks,
Michael

Comment by sergio_av [ 17/Nov/06 ]

Mozilla? I forgot to say that I use JDIC with IE 6.0 (IeEmbed.exe)





[JDIC-455] libtray.jnilib is not a Universal binary, so it fails on Intel Created: 07/Nov/06  Updated: 07/Nov/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: robross Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Attachments: Text File bugFix_455.diff    
Issuezilla Id: 455

 Description   

Current Mac build of the TrayIcon API doesn't include a universal jni binary, so
it fails on intel harware.

Btw, we need to add an OS item to distinguish between Mac OS PPC and Mac OS Intel.

Rob



 Comments   
Comment by robross [ 07/Nov/06 ]

Created an attachment (id=268)
patch to fix build script to create a universal binary jni lib file

Comment by michael_shan [ 07/Nov/06 ]

Thanks Rob, I've put "Wed Nov 8 02:16:00 +0000 2006: bugFix_455.diff" into cvs.





[JDIC-474] NullPointerException when using the default OSX browser Created: 05/Dec/06  Updated: 05/Dec/06

Status: Open
Project: jdic
Component/s: MacOS
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: jsvazic Assignee: elliotth
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: All


Issuezilla Id: 474

 Description   

When trying to create a new IBrowserInstance using the default browser on OSX, I
get the following stacktrace:

Exception in thread "EventThread" java.lang.IllegalArgumentException: Null
charset name
at java.nio.charset.Charset.lookup(Charset.java:430)
at java.nio.charset.Charset.forName(Charset.java:497)
at org.jdesktop.jdic.browser.internal.MsgClient.<init>(Unknown Source)
at org.jdesktop.jdic.browser.internal.NativeEventThread.run(Unknown Source)

Looking at the code I noticed that the org.jdesktop.jdic.browser.WebKitEngine
class returns null from it's getCharsetName() method, which is causing this
error to occur. Can this please be fixed by either returning a valid value or
consider using a call to Charset.defaultCharset() if the JDK version is 5.0 or
later?






[JDIC-484] hi how to i post issues in the forum Created: 18/Jan/07  Updated: 18/Jan/07

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: venkimani1 Assignee: abeginner
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Other


Issuezilla Id: 484

 Description   

hi
I thought this should be the way to post issues with the forum and since your
name begins with abeginner ,i assume beginners like me assign things to you !
Well i am thankfull to all who had contributed and thinking of java as a
desktop tool is a cool feature ! I was embedding jdic browser in a notes form
in the form of applet ! notes has this weired formula language ...which can
change on refresh ....what i am trying to do is based on a field in notes form
the value of the field change based on the user input and based on it the url
is set to the browser ! everything was fine except if the refresh happens !
when refresh happens the applet is not reloaded (i understand that ) and the
jvm instance is still alive ....but the applet is disposed and reloaded and
cannot attach the available browser instance in the memory ! Also when the form
in domino is closed the applet is disposed off....but the browser instance
(IeEmbed.exe) invoked still resides and it won't go off untill notes client is
completely shut down and restarted ....is there a way to unload the invokation
on exit programatically than to allow the OS to work on that
thanks and hope some one will reply .....i did try dispose() in old
version ...removeNotify() etc but nothing took the instance out and as long as
it is there frequent loading of the same is not possible ...
thanks for the help in advance
venki






[JDIC-492] JDIC browser component dies - checks reveal that IeEmbed.exe is no longer running Created: 20/Mar/07  Updated: 12/Oct/07

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: jannaude Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 492

 Description   

Started app that contains two Jframes each with a WebBrowser component. IE
components works fine for a while displaying embedded Flash animations. After
some time, user notices that IE window is no longer being displayed. Subsequent
checks using Task Manager reveals that IeEmbed is no longer running. Calls to
WebBrowser components do not return errors or exceptions however.



 Comments   
Comment by jannaude [ 21/May/07 ]

Hi guys,

Any word on this issue? This is an urgent request.

Thanks,

Jan

Comment by jannaude [ 12/Oct/07 ]

Hi guys,

Could you please URGENTLY provide feedback on this, this affects a production
application. If you need anything more to resolve the matter, please contact me
at jnaude@fnb.co.za.

Thanks,

Jan Naude





[JDIC-499] WebBrowser component not functional on Vista Created: 11/Jun/07  Updated: 11/Jun/07

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: jsnodgrass Assignee: michael_shan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: PC


Issuezilla Id: 499

 Description   

The WebBrowser component doesn't work on Vista. I get a grey panel instead of a
web browser control. The component works properly when I disable UAC in Vista or
run the application with administrator privileges.






[JDIC-501] Feature is disappeared and new Failure has arrived Created: 04/Jul/07  Updated: 04/Jul/07

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: lrcusts Assignee: michael_shan
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 501

 Description   

Feature is disappeared:
I have formerly used the jdic version (20060613) and there i had the possibility
to set the wished browser.
EngineManager bem = BrowserEngineManager.instance();
bem.setActiveEngine(BrowserEngineManager.IE);

Why this is no longer supported?

New Failure on Closing my App after using the WebBrowser:
Now i get folloan Exception..
java.lang.NullPointerException: null pData
at sun.awt.windows.WComponentPeer.hide(Native Method)
at java.awt.Component.removeNotify(Unknown Source)
at org.jdesktop.jdic.browser.WebBrowser.access$201(Unknown Source)
at org.jdesktop.jdic.browser.WebBrowser$2.run(Unknown Source)

and an windows-error for the ieembed.exe:
Die Anweisung in "0x004028f2" verweist auf Speicher in "0x00000030". Der Vorgang
"read" konnte nicht auf dem Speicher durchgeführt werden.......






[JDIC-519] PopupMenu is shown behind the taskbar if the auto-hide taskbar is enabled When JDIC app is run using jdk 1.6 Created: 12/May/08  Updated: 12/May/08

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: susmitha Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File trayIconTest.jar    
Issuezilla Id: 519

 Description   
  • On Windows XP machine set, task bar to auto-hide
  • Run the attached test program using JDK > 1.6.0_02

java -cp trayIconTest.jar;jdic.jar test.jdic.JDICTrayIconTest

  • Goto System tray and right click on the icon:Magnifying glass
  • Notice that a menu with three options Login, About, Exit appers
  • Now move the mouse away from the task bar such it is hidden
  • Again, goto the System tray and right click on the Maginifying glass icon
  • Notice that this time the menu with three options is shown behind the taskbar

Workaround :

  • Use java.awt.TrayIcon (But this class is only available from jdk 1.6)
  • Applications that are using JDIC library and cannot use features of JDK 1.6
    will suffer because of this bug, when the app is run with JDK 1.6.
  • Application developers do not usually control the version of Java that is
    used by their users.
  • Also the same test case, works perfectly with JDK 1.5, so this behavior looks
    like a regression in quality.


 Comments   
Comment by susmitha [ 12/May/08 ]

Created an attachment (id=306)
Test class to show TrayIcon popup behind the task bar on jdk1.6.





[JDIC-522] JDICplus is Microsoft-only Created: 05/Jun/08  Updated: 05/Jun/08

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: ronaldhughes Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 522

 Description   

JDICplus deviates from previous JDIC components in that it only works for Microsoft customers. This must
be a joke, right? The 'J' in JDIC doesn't stand for Microsoft, nor does it stand for Windows. Is this an
attempt to hijack JDIC from its original purpose?

The technology that makes up JDICplus might be interesting, but it belongs elsewhere. Please move it.






[JDIC-541] JDIC 0.9.5 Desktop API broken in Java Web Start Created: 01/Sep/09  Updated: 01/Sep/09

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: icemank Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 541

 Description   

JDIC 0.9.5 Desktop API is broken in Java Web Start since it uses
ClassLoader.getSystemClassLoader() to load the platform specific service provider.
This will not work since the system class loader is unaware of the jars
downloaded by JWS. See the JWS FAQ:
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html#211
The correct way is to either use:
this.getClass().getClassLoader();

or

Thread.getCurrent().getContextClassLoader();

The latter may be the best solution since it is portable to all deployment
contexts (stand-alone, applet and web start).

This problem also affects the JDIC Tray API and JDIC FileTypes API.






[JDIC-8] Improve Interface for Screensaver Options Created: 07/Jun/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Screensavers
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: grlea Assignee: markroth8
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: All


Issuezilla Id: 8

 Description   

After developing one screensaver, which had a lot of options (for a
screensaver), I found I had to write quite a bit of boilerplate to turn my
options (or "properties") into the data types I wanted (int, float, etc.). It'd
be great not to have to do this.

One idea I'd like to suggest is for screensavers to be provided with a
screensaver-specific implementation of java.util.prefs.Preferences
(http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/Preferences.html).
This would be a non-proprietary, J2SE-compliant solution (no new interfaces!)
having all the methods that would be needed by a screensaver. It would also
obviate the need for the ScreensaverSettings class, the interface of which
currently has methods that reveal too much about the underlying implementation
(i.e. xscreensaver configuration through command-line options).






[JDIC-114] installer classes Created: 01/Oct/04  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File install.jar    
Issuezilla Id: 114

 Description   

A recent forum thread debated the way that jdic is packaged and delivered. I am
attaching a zip of some of the work I have done in the installer area.

1. JreInstall installs a "standard" jdic distribution into a jre.
2. WebstartInstall installs the native portion of a "standard" jdic distribution
into a webstart environment.
3. VersionServlet is installed into the webstart server to help with the
versioning aspects.

The "standard" jdic distribution envisioned contains jdic.jar,
jdic-installer.jar, and a sub-directory for each supported platform. Within
each platform directory is a jdic-platform jar. Below each platform directory
are the architecture subdirectories which contain the native jdic libraries.

Because there are quite a number of platform/architectures to support, perhaps
the future direction is that individuals could contribute binaries for new
platforms/architectures.



 Comments   
Comment by chas [ 01/Oct/04 ]

Created an attachment (id=72)
installer idea

Comment by georgez [ 03/Mar/05 ]

Should be an "Enhancement".





[JDIC-115] Binarypath cannot be specified externally Created: 02/Oct/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: 0.8.6
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Martin Grebac Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 115

 Description   

The binarypath currently cannot be specified from external world, but depends
on variety of conditions, which is unclear and hard to modify mechanism. The
mechanism could stay, however I think it would be good to do a check for
existence of a property (e.g. jdic-binary-path) first - and if it's set, then
use it, otherwise try something else.
This would help e.g. to bundle jdic with apps which cannot have all the
jars/dlls/exes/... in one place.
I can submit a patch if it's needed.






[JDIC-173] Packager to support javaws version methods. Created: 27/Jan/05  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: toddm Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 173

 Description   

Would like to use packager to insert a app deloyed using version name convention
into the javaws cache currently only the href attribute is read. I tested using
the example and the set up as below.

Thanks
Todd

app\webpad__V1.0.jar
\jlfgr__V1.0.jar
\jhcore__V1.0.jar
\jh__V1.0.jar
\holidays__V1.0.jar
\javahelp.jnlp
\webpad.jnlp

webpad.jnlp
<jnlp spec="1.0" codebase="$$codebase">
<information>
<title>WebPad Name version</title>
<vendor>Sun Microsystems, Inc.</vendor>
</information>
<resources>
<property name="publish-url" value="$$context/publish"/>
<j2se version="1.3"/>
<jar href="webpad.jar" version="1.0"/>
<jar href="jlfgr.jar" version="1.0"/>
<extension name="Help System"
href="javahelp.jnlp">
<ext-download ext-part="javahelp" download="lazy" part="help"/>
</extension>
<jar href="holidays.jar" version="1.0" download="lazy" part="help"/>
</resources>
<application-desc main-class="WebPad"/>
</jnlp>

javahelp.jnlp
<jnlp spec="1.0+" codebase="$$codebase">
<information>
<title>JavaHelp</title>
<vendor>Sun Microsystems, Inc.</vendor>
</information>
<resources>
<jar href="jhcore.jar" version="1.0" part="core"/>
<jar href="jh.jar" version="1.0" part="javahelp" download="lazy"/>
</resources>
<component-desc/>
</jnlp>






[JDIC-182] Should fall-back to the native browser if the default one cannot be embedded. Created: 03/Feb/05  Updated: 19/Jun/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: sgregory Assignee: dongdongyang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 182

 Description   

Hello,

I have a problem where Mozilla 1.7 on my Windows 2000 computer doesn't seem to work. I am sure that
this is a problem for a significant number of people. It would be nice if
org.jdesktop.jdic.browser.Browser would detect this, and fall-back to using the native (IE in this case)
browser instead of leaving the user with an empty box.

Nicer yet would be for other platforms to fall-back to at least an HTML JTextPane if they do not have a
native browser.

Thank You!



 Comments   
Comment by georgez [ 03/Mar/05 ]

This is a reasonable request. Currently, On Windows, if Mozilla is not set as
the default browser, we'll just fall back to IE. But we didn't check if Mozilla
is set as the default browser but it fails to be embedded, and if IE still fails
to be embedded, it won't fall back to other default Java or native HTML viewer.
On *nix platform, it won't fall back to any other viewers.

Submitted patch to this would be very welcome !

Comment by georgez [ 03/Mar/05 ]

This is a reasonable request. Currently, On Windows, if Mozilla is not set as
the default browser, we'll just fall back to IE. But we didn't check if Mozilla
is set as the default browser but it fails to be embedded, and if IE still fails
to be embedded, it won't fall back to other default Java or native HTML viewer.
On *nix platform, it won't fall back to any other viewers.

Submitted patch to this would be very welcome !

Comment by dongdongyang [ 19/Jun/06 ]

Being of members changing, reassign the task.





[JDIC-239] Screensaver Preview Should Be Scaled Down, Not a Smaller Component Created: 21/Mar/05  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Screensavers
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: grlea Assignee: markroth8
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 239

 Description   

The preview for screensavers (on Windows at least) is created using a smaller
Component. For some screensavers, especially those whose parameters contain
pixel sizes or speeds expressed as pixels per second, this results in a preview
that looks very unlike the actual saver.

A suggestion for how this could be better is to:
Create a background component that is 1/4 the size (i.e. 1/2 size in each
dimension) of the screen, give this component to the Screensaver, and then
scale the image painted to that component and paint the scaled image into the
preview pane.



 Comments   
Comment by markroth8 [ 21/Mar/05 ]

Thanks for filing this issue.

I think it should really be up to the screensaver to scale to as small a size as
necessary to fit itself in the component that is provided. Only the screensaver
knows the best / most efficient way to do that.

I know the reality is that many of the screensavers (blackglass included) don't
do well in the preview window, though. We should probably fix that on a
screensaver-by-screensaver basis.

It might be useful for the SDK to provide a utility class that does what you
described. In fact, the Graphics2D class provides the ability to scale a
graphics context pretty seamlessly.

I'll think about this some more. In the meanwhile, which ones but you in
particular, so I can focus my efforts on getting those to look nicer.





[JDIC-275] New method supportsProtocol() Created: 10/May/05  Updated: 26/Jan/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: turadg Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 275

 Description   

Until issue #274 is completed, it will be very helpful to know whether the
native component can access the resource at your URL. Since different native
components are implement the Browser API, potentially some of them could handle
a particular protocol while another couldn't.

A new method as below would enable the calling context to deal with this
accordingly.

public boolean supportsProtocol(String protocol)

or alternatively make the URL the argument directly

public boolean supports(URL url)

I notice the willOpenURL() method, which sounds similar, but serves a different
purpose.



 Comments   
Comment by georgez [ 31/May/05 ]

As JDIC Browser leverage the full functionality of native browsers (IE or
Mozilla), which should support most of the available protocols.

So, I think this new method doesn't make much senst. How it can be used in your
case ? Thanks.

Comment by turadg [ 03/Jun/05 ]

Oh, I wrote most of the explanation on the other ticket, issue #274.

Our use case makes use of "jar:" urls. We have an interface for a component
that takes a URL. Some of the implementers use JEditorPane which can read from
a "jar:" url, but some are implementors use the native browser component which
can't. When it can't, I need to know that so I can make the resource accessible
in a protocol the browser supports (e.g. file: by exploding the JAR).

Basically the problem boils down to this: the contract of the java.net.URL has
an openConnection() method which is the way to stream in the contents. The
develop is free to write new protocols or URLConnectionHandlers and anything in
that takes a java.net.URL can work with it. Except... these native browser
components.

If there isn't something done to bridge this change of contract, then I suggest
that the browser component not take a java.net.URL and instead take simply a
String (which is all it does with the URL).

Of course, what I would most like is for the JDIC component to figure out
whether the native component can access the URL and if not do something to make
it work. ie. what I describe in issue 274.

Comment by michael_shan [ 26/Jan/06 ]

Assign to Michael.





[JDIC-294] StringIndexOutOfBounds when using JNLP-Servlet Created: 23/Jun/05  Updated: 23/Jun/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: madsheep Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 294

 Description   

I'm using a servlet to generate the jnlp. The name of the servlet (and the path)
doesn't contain a dot. Therefore I recieve the following exception:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(Unknown Source)
at
org.jdesktop.jdic.packager.impl.FileOperUtility.getFileNameWithoutExt(Unknown
Source)
at
org.jdesktop.jdic.packager.impl.Jnlp2Package.checkPackageNameArgument(Unknown
Source)
at org.jdesktop.jdic.packager.impl.Jnlp2Package.parseArguments(Unknown
Source)
at org.jdesktop.jdic.packager.impl.Jnlp2Package.generatePackage(Unknown
Source)
at org.jdesktop.jdic.packager.Jnlp2Msi.main(Unknown Source)

The solution for the problem is quite simple. Just add a check to the method
FileOperUtility.getFileNameWithoutExt if the index is -1 and return the full
name in this case.






[JDIC-329] Form submit callback Created: 07/Sep/05  Updated: 07/Sep/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: mcmeans Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 329

 Description   

I need something similar to WebBroser.willOpenURL except to get notification
when the user clicks on a button to submit a form. I want to intercept the form
POST or GET and massage it.

I need to know the details of the post. Something like:

formclicked^SubmitBtn=Submit&field1=abc123&ResetBtn=reset&field2=Test+this






[JDIC-342] JdicManager throws exception if not loaded with URLClassLoader Created: 22/Nov/05  Updated: 05/Dec/06

Status: Reopened
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: pjgust Assignee: michael_shan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 342

 Description   

org.jdesktop.jdic.init.JdicManager.initShareNative() casts the class loader for
the class to a URLClassLoader, and throws a JdicInitException if it was not
loaded with a URLClassLoader. Our application has a custom class loader that is
not a URLClassLoader, and loads its classes through a different mechanism.
Throwing an exception in that case may not be the right thing to do. In
addition, the code to add the binary path to the java.library.path is also
skipped, even though it may be necessary. I suggest putting the cast inside the
inner try/catch block where it is actually referenced as a URLClassLoader. I
also suggest considering some kind of hook for class loaders that do not derive
from URLClassLoader.



 Comments   
Comment by michael_shan [ 25/Jan/06 ]

Assigne to Michael

Comment by michael_shan [ 01/Mar/06 ]

Hi ,

Thank you for your reporting, but I'm not too sure about this issue. I can't
find where did the cast occure as you described
"org.jdesktop.jdic.init.JdicManager.initShareNative() casts the class loader for
the class to a URLClassLoader,and throws a JdicInitException if it was not
loaded with a URLClassLoader." Could you pls. clear that?

Thanks!
Michael

Comment by michael_shan [ 08/Mar/06 ]

Assign to DongDongYang.

Comment by michael_shan [ 12/Mar/06 ]

Hi,

I've found the codes.

Comment by michael_shan [ 12/Mar/06 ]

For the crossplatform build, the JdicManager.java used this class cast to put
jars into classpath.

Comment by michael_shan [ 20/Mar/06 ]

A serious bug.

Comment by michael_shan [ 29/Mar/06 ]

Hi,
With the build of 20060308, this issue should be fixed. Please have a try.

Comment by michael_shan [ 27/Apr/06 ]

Background:

JDIC's cross platform version, it tends to choice platform related
jdic_stub.jar automatically.Thus users can only import jdic.jar without caring
about different os. But the auto adding/loading of jdic_stub.jar is some
difficult to realize.

Analysis of this cr:
In our former code, we supposed that the classloader of JDIC should be instance
of URLClassLoader, but this has been failed when deploying JDIC as a plugin of
NetBeans, which doesn't extend URLClassLoader.

The latest fix of dynamically setting java.class.path property will not
work,since after JVM starting, it will not care the change of this property.

Current way to fix:

  • If classes are loaded by instance of URLClassLoader, use before way of using
    method "addURL" to change loading path dynamically and this will work well
  • For classes are not loaded by instance of URLClassLoader, user have to add
    jdic_stub.jar to classpath manually

Final way to fix:
1. Remove JDIC cross platform verion.Since if user have to jdic_stub.jar to
classpath manully, it's not necessary to provide this version anymore.
2. Develop JDIC ClassLoader to load classes in jdic_stub.jar.

I prefer fix 1,since fix 2 will make the architecture of JDIC bad. Fix 1 is
acceptable, as few softwares will provide a version of all platforms,for e.g .,
Java.

Michael

Comment by michael_shan [ 06/Nov/06 ]

Change to browser type.

Comment by michael_shan [ 05/Dec/06 ]

Hi Michael,
unfortunately I was not able to add a comment to the issue, don’t know why
(attachment was possible).
We would love to use jdic within eclipse on different platforms (no
URLClassLoader),therefore I had another suggestion to solve the platform
dependency stuff:
Why don’t you just use a Factory that creates the ServiceManagerStub dependent
on the operating system?
The following steps would be necessary:
1)Refactor all internal ServiceManagerStub classes within the os specific
packages into concrete ones, e.g. WinServiceManagerStub, MacSerrviceManagerStub, …
2)Add a factory into ServiceManager.getService() that uses the concrete stub (as
an interface of course). The factory could load the class without concrete
dependencies by reflection (similar to what you’ve done within
JdicManager.dealCrossPlatformVersion())
3)Remove that UrlLoader Code completely

Seems to be a tiny patch (most work has to be done in 1).
For a user of the jar, all he has to do is just adding the main jars plus all os
dependent jars. Only those would be loaded at runtime that are really created by
the factory.

Regards
Darius

Comment by michael_shan [ 05/Dec/06 ]

Hi Darius,

Thank you for your suggestion.I prefer this idea and it's worth to be
investigated. A future affection of this is that,if it works well I think JDIC
needs provide only one build,the cross platform version . Would you like put
your hands dirty on this issue? We really need more contributors' help on JDIC.

thanks,
Michael





[JDIC-349] JTabbedPane paint problem (JDK1.4.2) Created: 06/Jan/06  Updated: 06/Jan/06

Status: Open
Project: jdic
Component/s: www
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mbucher Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC


Issuezilla Id: 349

 Description   

WebBrowser component in JTabbedPane shows up even its tab is not selected.
Defect only with JDK 1.4.2. Works correct on JDK5.

To reproduce, try this code with JDK1.4.2:
-----------------------------------------------
package de.inxnet.inxmail;

import java.awt.BorderLayout;
import java.awt.Color;

import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTabbedPane;

import org.jdesktop.jdic.browser.WebBrowser;

public class BrowserTestCase
{
private WebBrowser webBrowser;

public BrowserTestCase()

{ JPanel p1 = new JPanel(); p1.setBackground( Color.GREEN ); JPanel p2 = new JPanel( new BorderLayout() ); webBrowser = new WebBrowser( true ); p2.add( webBrowser ); JTabbedPane tab = new JTabbedPane(); tab.add( "1", p1 ); tab.add( "2", p2 ); JFrame frame = new JFrame( "JDIC Browser test" ); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.getContentPane().add( tab ); frame.setBounds( 0, 0, 640, 480 ); frame.setVisible( true ); webBrowser.setContent( "<html><body><b>Content of Tab #2</b>"+ " (Tab #1 is EMPTY!)</body></html>" ); }

public static void main( String[] args ) throws Exception

{ new BrowserTestCase(); }

}
-----------------------------------------------






[JDIC-448] update tdemo/Browser to use BrowserEngineManager Created: 20/Oct/06  Updated: 22/Oct/06

Status: Open
Project: jdic
Component/s: demo
Affects Version/s: current
Fix Version/s: None

Type: Task Priority: Critical
Reporter: lordy Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File Browser.java.patch    
Issuezilla Id: 448

 Description   

Hey Michael, for the next release we should also fix the demos to the new way of using browser. Please
add patch asap.
Christopher



 Comments   
Comment by lordy [ 20/Oct/06 ]

Created an attachment (id=256)
patch

Comment by michael_shan [ 22/Oct/06 ]

Hi Chris,
Thank you for your code,I've put it into cvs with a minior change
from "(Compoment)webBrowser" to "webBrowser.asComponent()" . Thanks!

Michael

Comment by michael_shan [ 22/Oct/06 ]

To finish this issue, we still need update the webstart demo to include
staffs under Mac OS. Thus, this demo will work under linux/solaris/mac/win.





[JDIC-517] JdicManager. initShareNative() produces wrong path for cross-platform Created: 15/Apr/08  Updated: 15/Apr/08

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mbo Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 517

 Description   

in JdicManager.initShareNative() the following code should produce the url of
jdic.jar as a String

//running url of current class

String runningURL =(
new URL(JdicManager.class
.getProtectionDomain()
.getCodeSource()
.getLocation(),
".")
).openConnection().getPermission().getName();

but the code URL.openConnection().getPermission().getName() actually appends the
name of the permission to the String, in my case "<all permission>"

This results in a wrong library path.

To fix this i just removed the .openConnection().getPermission().getName() part.






[JDIC-520] Patch to fix build on MacOS 10.5 and to allow loading of JDIC in a separate ClassLoader Created: 12/May/08  Updated: 12/May/08

Status: Open
Project: jdic
Component/s: MacOS
Affects Version/s: current
Fix Version/s: None

Type: Task Priority: Critical
Reporter: stringbean Assignee: elliotth
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Attachments: Text File jdic.patch    
Issuezilla Id: 520

 Description   

This patch fixes the following issues under MacOS X:

  • Compilation under MacOS 10.5 (targets 10.4 as build version).
  • Loading the JDIC tray integration from a separate ClassLoader
  • The build4crossplatform.xml build file now cleans the Mac native code.
  • Addition of a cleandemo target to the build4crossplatform.xml that cleans out
    the demo classes.
  • Addition of a cleanall target to the build4crossplatform.xml that calls all
    the clean targets.

The main fix is the ClassLoader one. We encountered problems when using multiple
ClassLoaders in our code where the tray icon would appear but it would not
display the menu. This was due to the native code being loaded in the default
ClassLoader which could not find the classes. I have fixed this by storing a
reference to the class that installs the tray icon and using that to display the
menu.



 Comments   
Comment by stringbean [ 12/May/08 ]

Created an attachment (id=307)
Patch for MacOS issues





[JDIC-534] WebBrowser focus and keyboard issues Created: 15/Mar/09  Updated: 15/Mar/09

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: alexzhang Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 534

 Description   

When using WebBrowser to display a web page, there have a focus issue and the
mnemonics of the menu items won't work for us, please see below requirements. In
fact, the issues existed on all build versions, including the latest version 0.9.5.
I wrote a sample to reproduce my issues, please help to see if there any issues
with my codes.
Now we have two requirements:
1. After run the JDIC095, we want the focus in the JTextField 1, not on the web
page in WebBrowser.
2. After run the JDIC095, we want the mnemonics of the menu items can work normally.

// Sample codes
package com.jdic;

import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.FlowLayout;
import java.awt.event.KeyEvent;
import java.net.MalformedURLException;
import java.net.URL;

import javax.swing.BorderFactory;
import javax.swing.JFrame;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import javax.swing.JPanel;
import javax.swing.JTextField;

import org.jdesktop.jdic.browser.WebBrowser;

public class JDIC095 {
public static void main(String[] args) {
JFrame frame = new JFrame("Test");
frame.setPreferredSize(new Dimension(500,300));
frame.setLayout(new FlowLayout());
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

JMenuBar menuBar = new JMenuBar();
JMenu menuFile = new JMenu("File");
JMenuItem miNew = new JMenuItem("New");
JMenuItem miOpen = new JMenuItem("Open");
JMenuItem miSave = new JMenuItem("Save");

menuFile.setMnemonic(KeyEvent.VK_F);
menuFile.add(miNew);
menuFile.add(miOpen);
menuFile.addSeparator();
menuFile.add(miSave);

menuBar.add(menuFile);

frame.setJMenuBar(menuBar);

JTextField jtf = new JTextField();
jtf.setPreferredSize(new Dimension(160, 30));
jtf.setText("JTextField 1");
frame.add(jtf);

JTextField jtf1 = new JTextField();
jtf1.setPreferredSize(new Dimension(160, 30));
jtf1.setText("JTextField 2");
frame.add(jtf1);

JPanel jp = new JPanel();
jp.setLayout(new BorderLayout());
jp.setBorder(BorderFactory.createLineBorder(Color.gray));
jp.setPreferredSize(new Dimension(200, 120));
WebBrowser canvas = new WebBrowser();
canvas.setFocusable(false);
try

{ canvas.setURL(new URL("http://www.google.com")); }

catch (MalformedURLException e)

{ e.printStackTrace(); }

jp.add(canvas);
canvas.setVisible(true);
frame.add(jp);

frame.pack();
frame.setVisible(true);
}
}






[JDIC-538] JDIC 0.9.5 webbrowser text input box can't enter any text on S10 by using jdk 1.6 Created: 01/Jul/09  Updated: 09/Jul/09

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9.1
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: bennyluo Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: All


Issuezilla Id: 538

 Description   

When use JDIC 0.9.1 to use jdk 1.6 on solaris 10 with mozilla 1.7.

I am trying to use the demo program Browser.jar to run the Browser class like
below:

/usr/jdk/jdk1.6.0_14/bin/java -cp ./Browser.jar:./jdic.jar -Djava.lib.path=.
Browser

Everything is all right, except the text input box in the html page, when the
browser download all the html page, the text input box can not enter any text.
Whatever you type any key on keyboard, it can not been displayed in the text
input box or the text will be displayed in the address bar, although the mouse
focus still in the text input box.

This sympton only happen on solaris 10 with Mozilla by using jdk 1.6, it will
not happen on windows with IE and Mozilla by using jdk 1.6, also, if I use jdk
1.5 on solaris 10 with mozilla, the sympton will NOT happen too, but
unfortunately, I need to use jdk 1.6.

Please help to identify whether it is a bug of JDIC project on solaris 10.
Thanks.



 Comments   
Comment by uta [ 09/Jul/09 ]

The workaround is in switching on xembed server (-Dsun.awt.xembedserver=true in
java command line). This workaround is really a quite another way to interact
with embedded components (like JDIC browser) from Java.
We do see this particular problem with focus handling is solved, but
nobody can predict what other areas could be broken.

The property "sun.awt.xembedserver" can be set by
System.setProperty("sun.awt.xembedserver", Boolean.TRUE.toString());
in customer code.





[JDIC-543] Refreshing the browser through IE F5 loses authentication Created: 19/May/10  Updated: 19/May/10

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: antokh Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC
URL: http://forums.java.net/jive/thread.jspa?threadID=148854&tstart=0`


Issuezilla Id: 543

 Description   

It would seem there's an issue with JDIC authentication. Can someone please
confirm this is a bug? I posted here:
http://forums.java.net/jive/thread.jspa?threadID=148854&tstart=0






[JDIC-1] Unable to setup Mozilla browser on Debian Linux Created: 02/Jun/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: johnmunsch Assignee: kyleyuan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 1

 Description   

The instructions for setting up the browser window will not work on my machine
(Debian Linux). Even though I have Mozilla 1.5 running on this machine there is
no mozembed* file on this machine at all.

I'm note sure whether the instructions should be changed or if there is a bigger
issue. I can say that there should probably be a way for the software to search
for the required files (once we know definitively what they are) so there is no
expectation for the end user to modify environment variables.



 Comments   
Comment by georgez [ 21/Jun/04 ]

The initial assigned owner (issues@jdic) is not valid.





[JDIC-10] FreeBSD port Created: 09/Jun/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: Task Priority: Major
Reporter: hmichelon Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: FreeBSD
Platform: All


Attachments: Text File freebsd.diffs     Text File issue10-patch.diff     Text File patch2_issue10.diff    
Issuezilla Id: 10

 Description   

This is a patch for building and running jdic on FreeBSD.
Only the packager component isn't patched due to the lack of the JDK 1.5 on FreeBSD.
Some modifications (in the unix native part) applies to all platforms -> must be
tested.
To build jdic on FreeBSD you must install:

  • The devel/gmake port
  • The www/gnome2 port
  • The www/mozilla port (whithout cleaning the port after make)
    and define the following variable :
    export MOZILLA_SRC_HOME=/usr/ports/www/mozilla/work/mozilla

Index: src/build.xml
===================================================================
RCS file: /cvs/jdic/src/build.xml,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 build.xml
37a38,41
> <condition property="dist.dir" value="dist/freebsd">
> <os name="freebsd"/>
> </condition>
>
Index: src/jdic/build.xml
===================================================================
RCS file: /cvs/jdic/src/jdic/build.xml,v
retrieving revision 1.2
diff -r1.2 build.xml
74a75,78
> <condition property="dist.dir" value="dist/freebsd">
> <os name="freebsd"/>
> </condition>
>
114a119,122
> <condition property="platform.target" value="buildfreebsd">
> <os name="freebsd"/>
> </condition>
>
211a220,226
> - FREEBSD DISTRIBUTION
> -->
> <target name="buildfreebsd" depends="buildunixjar, javadoc, buildbsdjni,
buildbsdembed"
> description="build java and native source code for FreeBSD platform" >
> </target>
>
> <!--
247a263,269
> <target name="buildbsdjni" depends="init"
> description="build native jni libraries." >
> <exec dir="$

{unix.native.jni.dir}" executable="gmake" failonerror="yes" />
>
> <!-- copy generated .so file -->
> <copy file="${unix.native.jni.dir}

/libjdic.so" todir="$

{dist.dir}" />
> </target>
276a299,317
> </target>
>
> <!-- *** Build Unix native embeded browser code *** -->
> <target name="buildbsdembed" depends="init">
> <!-- clean the previous build -->
> <exec dir="${unix.native.mozilla.dir}" executable="gmake" failonerror="yes">
> <arg line="clean"/>
> </exec>
>
> <exec dir="${unix.native.mozilla.dir}" executable="gmake" failonerror="yes">
> <arg line="all"/>
> </exec>
>
> <!-- copy the embeded Mozilla executable -->
> <exec os="FreeBSD" executable="cp" failonerror="yes">
> <arg value="${unix.native.mozilla.dir}/mozembed-freebsd-gtk2" />
> <arg value="${dist.dir}

/." />
> </exec>
>
Index: src/jdic/demo/FileExplorer/FileExplorer.java
===================================================================
RCS file: /cvs/jdic/src/jdic/demo/FileExplorer/FileExplorer.java,v
retrieving revision 1.2
diff -r1.2 FileExplorer.java
250c250
< } else if (osName.startsWith("linux") || osName.startsWith("sunos"))

{ --- > }

else if (osName.startsWith("linux") || osName.startsWith("sunos") ||
osName.startsWith("freebsd")) {
Index: src/jdic/src/unix/native/jni/GnomeBrowserService.cpp
===================================================================
RCS file: /cvs/jdic/src/jdic/src/unix/native/jni/GnomeBrowserService.cpp,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 GnomeBrowserService.cpp
27c27
< #include <gtypes.h>

> #include <glib.h>
Index: src/jdic/src/unix/native/jni/GnomeUtility.cpp
===================================================================
RCS file: /cvs/jdic/src/jdic/src/unix/native/jni/GnomeUtility.cpp,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 GnomeUtility.cpp
26c26
< #include <gtypes.h>

> #include <glib.h>
Index: src/jdic/src/unix/native/jni/Makefile
===================================================================
RCS file: /cvs/jdic/src/jdic/src/unix/native/jni/Makefile,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 Makefile
33c33
< LDFLAGS = -G

> LDFLAGS = -G -ldl -lrt
39c39,45
< LDFLAGS = -shared -fPIC

> LDFLAGS = -shared -fPIC -ldl -lrt
> endif
> ifeq ($(UNAME), FreeBSD)
> PLATFORM = freebsd
> CXX = g++
> CXXFLAGS = -c -I/usr/local/include -I/usr/X11R6/include
> LDFLAGS = -shared -fPIC -L/usr/local/lib -L/usr/X11R6/lib
49,61c55,64
< EXTRA_INCLUDES = -I$(USR_INCLUDE_DIR)/libgnome-2.0 \
< -I$(USR_INCLUDE_DIR)/gnome-vfs-2.0/libgnomevfs \
< -I$(USR_INCLUDE_DIR)/gnome-vfs-2.0 \
< -I$(USR_INCLUDE_DIR)/gnome-vfs-module-2.0 \
< -I$(USR_INCLUDE_DIR)/gnome-vfs-module-2.0/libgnomevfs \
< -I$(USR_INCLUDE_DIR)/glib-2.0 \
< -I$(USR_INCLUDE_DIR)/glib-2.0/glib \
< -I$(USR_LIB_DIR)/glib-2.0/include \
< -I$(USR_INCLUDE_DIR)/bonobo-activation-2.0 \
< -I$(USR_INCLUDE_DIR)/libbonobo-2.0 \
< -I$(USR_INCLUDE_DIR)/orbit-2.0 \
< -I$(USR_INCLUDE_DIR)/linc-1.0 \
< -I$(USR_INCLUDE_DIR)/gconf/2

> EXTRA_INCLUDES = `pkg-config --cflags glib-2.0` \
> `pkg-config --cflags libgnome-2.0` \
> `pkg-config --cflags gnome-vfs-2.0`\
> `pkg-config --cflags gnome-vfs-module-2.0` \
> `pkg-config --cflags glib-2.0` \
> `pkg-config --cflags bonobo-activation-2.0` \
> `pkg-config --cflags libbonobo-2.0` \
> `pkg-config --cflags ORBit-2.0` \
> `pkg-config --cflags linc` \
> `pkg-config --cflags gconf-2.0`
64,66d66
< -lgnome-2 \
< -lgnomevfs-2 \
< -lbonobo-activation \
68,69d67
< -lgconf-2 \
< -lORBit-2 \
71,79c69,78
< -llinc \
< -lgmodule-2.0 \
< -ldl \
< -lgobject-2.0 \
< -lgthread-2.0 \
< -lpthread \
< -lglib-2.0 \
< -lpopt \
< -lrt

> `pkg-config --libs glib-2.0` \
> `pkg-config --libs libgnome-2.0` \
> `pkg-config --libs gnome-vfs-2.0`\
> `pkg-config --libs gnome-vfs-module-2.0` \
> `pkg-config --libs glib-2.0` \
> `pkg-config --libs bonobo-activation-2.0` \
> `pkg-config --libs libbonobo-2.0` \
> `pkg-config --libs ORBit-2.0` \
> `pkg-config --libs linc` \
> `pkg-config --libs gconf-2.0`
Index: src/jdic/src/unix/native/mozilla/Makefile
===================================================================
RCS file: /cvs/jdic/src/jdic/src/unix/native/mozilla/Makefile,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 Makefile
55a56
> nspr \
84a86,93
> endif
> endif
> ifeq ($(OS_ARCH), FreeBSD)
> ifdef MOZ_ENABLE_GTK
> PROGRAM = mozembed-freebsd-gtk1.2$(BIN_SUFFIX)
> endif
> ifdef MOZ_ENABLE_GTK2
> PROGRAM = mozembed-freebsd-gtk2$(BIN_SUFFIX)
Index: src/jdic/src/unix/native/mozilla/Makefile.in
===================================================================
RCS file: /cvs/jdic/src/jdic/src/unix/native/mozilla/Makefile.in,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 Makefile.in
86a87,94
> ifeq ($(OS_ARCH), FreeBSD)
> ifdef MOZ_ENABLE_GTK
> PROGRAM = mozembed-freebsd-gtk1.2$(BIN_SUFFIX)
> endif
> ifdef MOZ_ENABLE_GTK2
> PROGRAM = mozembed-freebsd-gtk2$(BIN_SUFFIX)
> endif
> endif
Index: src/packager/build.xml
===================================================================
RCS file: /cvs/jdic/src/packager/build.xml,v
retrieving revision 1.2
diff -r1.2 build.xml
15a16
> buildfreebsd: on FreeBSD to build a FreeBSD distribuition.
77a79,82
> <condition property="dist.dir" value="dist/freebsd">
> <os name="freebsd"/>
> </condition>
>
102a108,111
> <condition property="platform.target" value="buildfreebsd">
> <os name="freebsd"/>
> </condition>
>
122c131
< which is buildwin32, buildlinux, or buildsolaris. -->

> which is buildwin32, buildlinux, buildfreebsd or buildsolaris. -->
246a256,262
> </target>
>
> <!--
> - FREEBSD DISTRIBUTION
> -->
> <target name="buildfreebsd" depends=""
> description="build all the class and native source code" >



 Comments   
Comment by hmichelon [ 09/Jun/04 ]

Created an attachment (id=3)
FreeBSD port patch

Comment by georgez [ 09/Jun/04 ]

Henri, to add an additional diff file, you could just add "Create a new
attachment" with the complete diff info. Or you just add one more diff file.

I looked into the patch, it looks good. I checked the modifications to the unix
native part work on my Linux machine, but got a problem on Solaris machine:

bash-2.03$ pkg-config --cflags bonobo-activation-2.0
sh: gnome-config: not found
Package libxml-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxml-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libxml-2.0', required by 'Bonobo Activation', not found

I checked that the required libxml-2.0.pc is not found :
bash-2.03$ grep xml /usr/lib/pkgconfig/bonobo-activation-2.0.pc
Requires: glib-2.0 gmodule-2.0 ORBit-2.0 libxml-2.0

You have any idea ? I'll look at it further.

Comment by georgez [ 21/Jun/04 ]

I'm working on this patch. Reassigned to me.

Comment by georgez [ 06/Jul/04 ]

Created an attachment (id=18)
Refined patch for FreeBSD support.

Comment by georgez [ 06/Jul/04 ]

The patch was accepted with minor modifications, will be checked in soon.

Comment by georgez [ 06/Jul/04 ]

The patch (issue10-patch.diff) was checked in to the source tree. A FreeBSD
distribution will be created as downloadable.

Comment by georgez [ 06/Jul/04 ]

As to the pkg-config problem for libxml-2.0.pc I saw on Solaris 8.

The reason is that libxml2 was shipped with Solaris before GNOME (and so before
pkgconfig), Therefore the .pc was not included originally. After I applied patch
114814-01 (http://sunsolve.sun.com/pub-cgi/retrieve.pl), the problem didn't exist.

Comment by hmichelon [ 07/Jul/04 ]

Created an attachment (id=20)
Under all *BSD platforms GNU make is called gmake : add two rules to handle this case. Deactivating the packager due to the lack of JDK 1.5.

Comment by hmichelon [ 07/Jul/04 ]

To run a JDIC application under FreeBSD :

  • define the following variable : export MOZILLA_FIVE_HOME=/usr/X11R6/lib/mozilla
  • modify the following variabe : export
    LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MOZILLA_FIVE_HOME
Comment by georgez [ 07/Jul/04 ]

The new patch was accepted and checked in to the source tree. And a downloadable
binary provided by hmichelon is now available at:

https://jdic.dev.java.net/servlets/ProjectDocumentList?folderID=1304

Which only includes the JDIC API binary, not including the JDIC Packager due to
the lack of JDK 1.5.

Thanks.
-George.





[JDIC-28] Execute action on file Created: 17/Jun/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: current
Fix Version/s: None

Type: Task Priority: Major
Reporter: blochg Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File ExecuteAction.fixed.patch     Text File ExecuteAction.fixed.patch     Text File ExecuteAction.patch    
Issuezilla Id: 28

 Description   

This patch adds the functionality to execute Actions (from the filetypes
subcomponent) on files. The implementation works on windows, in the unix
version the execute method throws a DesktopException.



 Comments   
Comment by blochg [ 17/Jun/04 ]

Created an attachment (id=8)
Patch adds function to execute an Action on a file

Comment by georgez [ 21/Jun/04 ]

Changed to the right subcomponent.

Comment by paul_huang [ 07/Jul/04 ]

Hi Bolchg

Sorry for the late reply. We were just back from this year's Java one conference.
I tried your patch and got the following error message:
(Stripping trailing CRs from patch.)
patching file jdic/src/jdic/src/share/classes/org/jdesktop/jdic/desktop/Desktop.
java
Hunk #2 FAILED at 333.
1 out of 2 hunks FAILED – saving rejects to file jdic/src/jdic/src/share/classe
s/org/jdesktop/jdic/desktop/Desktop.java.rej
(Stripping trailing CRs from patch.)
patching file jdic/src/jdic/src/share/classes/org/jdesktop/jdic/desktop/internal
/LaunchService.java
(Stripping trailing CRs from patch.)
patching file jdic/src/jdic/src/unix/classes/org/jdesktop/jdic/desktop/internal/
impl/GnomeLaunchService.java
(Stripping trailing CRs from patch.)
patching file jdic/src/jdic/src/win32/classes/org/jdesktop/jdic/desktop/internal
/impl/WinLaunchService.java
Hunk #1 FAILED at 163.
1 out of 1 hunk FAILED – saving rejects to file jdic/src/jdic/src/win32/classes
/org/jdesktop/jdic/desktop/internal/impl/WinLaunchService.java.rej

Any idea?

Thanks

Comment by blochg [ 08/Jul/04 ]

Created an attachment (id=22)
Fixed patch

Comment by blochg [ 08/Jul/04 ]

Created an attachment (id=23)
Fixed patch

Comment by paul_huang [ 09/Jul/04 ]

Hi Gerhard

I've checked your patch. I understand you are trying to export some of the
internal API,which will provide a flexible execution mechism.

Actually, JDIC team did have a thorough discussion about this, we did plan to
providethe same kind flexible execution mechism. However, our decision is not to
public such kind of execution mechanism, based on the consideration that it
would be confusing to let user define the verb themselves.What kind of verb is
legal and what is illegal? In order to open a file, some user may use "open",
while other may prefer "start".

Considering this, we feel it would be better to provide user a set of predefined
API (for the common verbs), such as open, edit, print, etc.

From another point of view, it would be redundent design to include the execute
API if we've already provide the major, common APIs. Suppose a user want to open
a document, he may then have two kinds of choices:
1. Use open()
2. Use execute()
We should avoid such kind of redundence in the API design.

Based on those mentioned above, I feel it would not be quite proper to include
the patch into JDIC.

What's you oppinion? You are welcome to have an open discussion about this.

-Paul

Comment by blochg [ 09/Jul/04 ]

I agree that the use of an arbitrary verb will make no sense in most cases. My
intention was to use the AssociationService to get the Association and finally
the Actions for a particular filetyp that are registered with the system.
It should be clear, that executing an Action aquired on this way is well-
defined and will absolutely make sense. I would even go as far as saying that
without the possibility of executing "non-standard" actions, the mechanisms
provided by Association for managing Actions are quite useless.

Comment by paul_huang [ 11/Jul/04 ]

Then, in this case, the problem you'll run into is: How can you tell which verb
you get from Associationservice is the one you want to use?
I understand you can get Association by getFileExtensionAssociation(),
getMimetypeAssociation() or getAssociationByContent(). I just want to know how
you can tell which verb is the one you want to use while getting these verbs on
the fly? In most cases, you have to provide a set of predefined verb category
for certain target action. In this way, you'll fall back into the API like
open(), edit(), print(), etc.

Comment by blochg [ 12/Jul/04 ]

I thought of presenting a list of available actions to the user and let her
choose the desired one like Windows Explorer does. By using
action.getDescription (using action.getVerb as fallback in case the first
returns null) one can get a descriptive string for each available action and
use it e.g. to fill a menu for user presentation.
With the provision of a generic execution mechanism, it will be possible to
execute these actions in a platform independent way.





[JDIC-30] Mac OS X support Created: 19/Jun/04  Updated: 17/Oct/06

Status: Open
Project: jdic
Component/s: MacOS
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: elliotth Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File build-mac-jdic.txt     Text File issue30_0_8_6_patch.diff     Text File issue30_patch.diff     Text File issue30_patch_1.diff     Zip Archive jdic_osx.zip     File mac_os_x.tar    
Issuezilla Id: 30

 Description   

the current release supports Linux, Solaris and Windows. the obvious missing item in the list is Mac OS
X. i have the beginnings of an implementation, and would like an issue on which to hang it. this is that
issue.



 Comments   
Comment by elliotth [ 19/Jun/04 ]

Created an attachment (id=9)
modifies Ant build.xml files to build new Mac OS X tree

Comment by elliotth [ 19/Jun/04 ]

Created an attachment (id=10)
new Mac OS X source tree (mozilla and filetypes sections still just copies of Linux code)

Comment by georgez [ 21/Jun/04 ]

Changed the summary to be task description.

Comment by georgez [ 21/Jun/04 ]

The build-mac-jdic.txt patch looks fine. But please keep ONLY those necessary
updates to the CVS repository in the patches.

Some updates are not actual changes to the CVS repository, please remove them
while making the patch. Like below code, you commented out that line to build
the code locally. But while making the patch, you need to add it.
<!-- Build a JDIC Packager distribution -->

  • <ant dir="packager" target="buildall"/>
    + <!-- ant dir="packager" target="buildall"/ -->

For the mac_os_x.tar file, which includes new/added files/directories, please
follow the instructions in the patch webpage:
"2. Forgetting about new (added) files. Run cvs add (but do not commit!) to make
sure CVS thinks of them as added as part of the patch, and remember -N which
includes them in the patch. Also run cvsremove (but do not commit) when a patch
should delete some files."

And remove all unnecessary files, just keep those new/add files/directories.

One more thing, please give a detailed description on what features/APIs does
the patch implemented. As I see, Desktop.open() Desktop.browser(), and
Desktop.print() APIs are implemented.

Great work ! Thanks.

-George Zhang

Comment by elliotth [ 21/Jun/04 ]

> For the mac_os_x.tar file, which includes new/added files/directories, please
> follow the instructions in the patch webpage:
> "2. Forgetting about new (added) files. Run cvs add (but do not commit!) to make
> sure CVS thinks of them as added as part of the patch, and remember -N which
> includes them in the patch. Also run cvsremove (but do not commit) when a patch
> should delete some files."

CVS won't let me "cvs add"; i don't have sufficient permission.

> One more thing, please give a detailed description on what features/APIs does
> the patch implemented. As I see, Desktop.open() Desktop.browser(), and
> Desktop.print() APIs are implemented.

those plus both forms of Desktop.mail (a slight reworking of the Evolution
implementation, which we might want to factor out and reuse for both). Mac OS'
Mail.app doesn't support attachments in s.

Desktop.isPrintable just returns "true".

--elliott

Comment by georgez [ 13/Jul/04 ]

Created an attachment (id=27)
Experimental porting of Desktop class to MacOS.

Comment by georgez [ 13/Jul/04 ]

Hi Elliott,

Now I'm working on this patch (I've been to JavaOne for JDIC booth for about two
weeks). And quite looking forward to this port.: )

You see, in the discussion forum, l0ne provides a .zip file
(http://matrixtcg.altervista.org/jdic_osx.zip) containing a porting of the
Desktop classes to Mac, which didn't use JNI. To keep track of it, I attached
that file here.

I agree that your patch seems more complete. But I expect your comments.

For the filetypes part, if that's hard to port, we could just ignore it now.
For the browser part, do you have any idea that if we could just reuse the
current browser component code ? Or we have to rewrite it ?

A few days ago, Henry provided a binary for FreeBSD using that code without
modifications.

-George Zhang.

Comment by georgez [ 13/Jul/04 ]

Created an attachment (id=28)
A patch with the newly added and modified files.

Comment by georgez [ 13/Jul/04 ]

Hi, Elliott,

I've made a few minor modidications to your patch (build-mac-jdic.txt and
mac_os_x.tar), generated a combined patch (issue30_patch.diff) and checked it
into the source tree. The modifications include:
For the mac_os_x.tar file:
1. Removed the .../classes/.../filetypes directory, since the Filetypes API are
not implemented.

2. Updated .../classes/.../desktop files to each line length is less than 80
characters. These files follow the similar style (with line length more 80 char)
with some existing files, which should also be refactored. I just refactor these
newly added files.

3. Removed the .../native/mozilla directory, since this part needs to be tested
if the same source works on Mac as well.

For the build-mac-jdic.txt patch file, which modified both jdic/src/build.xml
and jdic/src/jdic/build.xml files.

You know, the first build.xml is just a cover file to build JDIC API source
(under jdic/src/jdic) and JDIC Packager source (under jdic/src/packager), and
copy the binaries/docs to generate a distribution.

Since currently the patch only implements one package (desktop) of JDIC API, to
provide a "buildall" target in jdic/src/build.xml doesn't make much sense, and
it would also requires some modifications to that file to avoid copying those
files not exist (built for other packages).

So, I only provide the "buildall" target in jdic/src/jdic/build.xml, the user
could build a Mac distribution (with jdic.jar and libjdic.lib support desktop
package) under jdic/src/jdic directory.

Please help to pull out the latest source and build it to see if there are any
problems.

More patches for other package are also welcome.

-George Zhang.

Comment by georgez [ 14/Jul/04 ]

Created an attachment (id=29)
Added fix to the previous fix.

Comment by georgez [ 14/Jul/04 ]

A new patch is created (issue30_patch.diff) to correct below two problems:

1. Below classes need to be implemented to build the source:
src/jdic/src/mac_os_x_/classes/org/jdesktop/jdic/filetypes/internal

The new patch provides the dummy implementations.

2. The jni/MacLaunchService.mm was accidentally checked in with the .h file, the
new patch corrects it.

-George Zhang.

Comment by georgez [ 08/Oct/04 ]

Created an attachment (id=76)
Updated fix for JDIC 0.8.6.

Comment by georgez [ 08/Oct/04 ]

I've attached the patch provided by Elliott to build the JDIC release 0.8.6
source on Mac OS X. The JDIC 0.8.6 for Mac provided by Elliott is uploaded to:
https://jdic.dev.java.net/servlets/ProjectDocumentList?folderID=1955&expandFolder=1955&folderID=0

Thanks a lot to Elliott.

Comment by georgez [ 05/Nov/04 ]

Reassign it to the "MacOS" subcomponent, which will hold all the MaxOS related bugs.

Comment by georgez [ 06/Mar/05 ]

Another issue(#222) is created for Browser support on Mac OS X specifically:
https://jdic.dev.java.net/issues/show_bug.cgi?id=222

Comments or patches for that should go to that issue.

Comment by michael_shan [ 17/Oct/06 ]

Reassign to michael.





[JDIC-31] Generate Installation Package from URL Created: 20/Jun/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Task Priority: Major
Reporter: robert_chen Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC


Attachments: Text File issue31.patch     Text File patch.diff    
Issuezilla Id: 31

 Description   

For the case of need to download all files from http, we move the step of
checking files' validity to: after we download them, instead of before we
download them.



 Comments   
Comment by robert_chen [ 20/Jun/04 ]

Created an attachment (id=11)
patch file for issue 27

Comment by paul_huang [ 07/Jul/04 ]

Suggest change the Summary to be "Generate Installation Package from URL"

Comment by robert_chen [ 24/Aug/04 ]

Created an attachment (id=51)
patch number 2

Comment by robert_chen [ 24/Aug/04 ]

latest patch for "Generate Installation Package from URL", added by
robert_chen@dev.java.net
1. add package from URL support.
2. fix the bug for no href inlcuded in jnlp file.





[JDIC-37] Use filetypes.Association to implement Desktop methods Created: 23/Jun/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: chas Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 37

 Description   

Where possible, (ie. edit, isEditable, isPrintable, open, and print) use
filetypes.Association to implement Desktop methods. For example, the isEditable
implementation becomes essentially:

associationService.getAssociationByContent(file.toURL()).getActionByVerb("edit")!=null

This layering will eliminate several native and internal plumbing methods.






[JDIC-38] seperate ant targets for package building Created: 23/Jun/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 38

 Description   

Please add top level ant script targets for "browser", "desktop", and
"filetypes". These targets would build and jar each package seperately.






[JDIC-40] updates to FileExplorer to demonstrate icon functionality Created: 25/Jun/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File fileexplorer.patch    
Issuezilla Id: 40

 Description   

Here are updates to the FileExplorer demo. The Explorer will show the mime type
and icon of each file.



 Comments   
Comment by chas [ 25/Jun/04 ]

Created an attachment (id=15)
diff patch for file explorer demo

Comment by georgez [ 25/Jun/04 ]

Thanks Chas,

I had a look at the patch, it looks good. I think if the demo is updated as you
patches, it would look much better. But at the moment, I'm on a travel (for JDIC
POD at JavaOne), so I haven't built it myself.

One thing now, in the files, you are using tabs (8 space long) instead of spaces,
that would make the code hard to read, if the developers' editor has a different
setting for tab length (in space).

So, could you reproduce the patches for this issue as well as issue#39, and
replace all tabs with 4 spaces ? That would make the coding style consistant.

Thanks,
-George.





[JDIC-47] Ant task to run packagers Created: 01/Jul/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: kohsuke Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 47

 Description   

It is more convenient if I can just run those packagers from Ant in a convenient
syntax, as opposed to use the general-purpose exec task.

Also, I don't see why those packagers are provided as native executable files.
Isn't it easier if they are just the jar files?






[JDIC-64] SimpleScreensaver.setComponenet doesn't seem to work Created: 20/Jul/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Screensavers
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jeeky Assignee: markroth8
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 64

 Description   

There are many cases where it would be advantageous to replace the supplied
renderable component with a custom one, such as a JFrame or a JOGL based
component. The trailing code attempts to do this. Rather than calling the
appropriate function on the new Container (as expected), the code simply fails
(the Graphics object is null).

Is the sample performing the replacement incorrectly, or is the code not
designed to receive a different default Container? If not, should this feature
be added?

Here is the sample:

/*

  • Created on Jul 20, 2004
    */
    package ss;

import java.awt.*;
import javax.swing.*;
import org.jdesktop.jdic.screensaver.*;

/**

  • @author Mark Bastian
    *
    */
    public class MyScreenSaver2 extends SimpleScreensaver
    {
    public static void main(String[] args) { ScreensaverFrame ssf = new ScreensaverFrame(new MyScreenSaver2 (), ""); ssf.show(); }

/* (non-Javadoc)

  • @see org.jdesktop.jdic.screensaver.ScreensaverBase#init()
    */
    protected void init() { super.init(); this.getContext().setComponent(new MyPanel()); }

private class MyPanel extends JPanel
{
public void paint(Graphics arg0)

{ this.setBackground(Color.WHITE); super.paint(arg0); }

}

public void paint(Graphics arg0)

{ System.out.println(arg0); }

}



 Comments   
Comment by markroth8 [ 21/Jul/04 ]

The setComponent() method is not intended to be called by the screensaver. It
is given to you by the system so that you can draw your screensaver. Different
platforms will have different instances of this component available.

I'll clarify this in the javadocs.

In all the implementations of ScreensaverBase thus far, the Component also
happens to be a Container. If you're feeling adventurous, you can cheat and
cast the Component to a Container so that you can add your own InternalFrame or
your own Panel. However, this is not guaranteed, and there may be platforms
where this is not possible, in the future (e.g. we haven't done our Mac binding
yet, contributions welcome).

You mentioned JOGL - please join the forums on
https://screensavers.dev.java.net/ I am currently working on built-in support
for JOGL in the next release of the SaverBeans SDK. The work is mostly done.





[JDIC-66] Add ability to "launch" based on double click Created: 23/Jul/04  Updated: 08/Jan/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jeffteague Assignee: bino_george
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC


Issuezilla Id: 66

 Description   

The current API supports using addActionListener() to listen for
TrayIcon "activation"

On Windows it would be nice to have more fine tuned control over the launch of
the application (or default action).

I would like to be able to launch an action based on single click or
double click mouse events.

Perhaps this could be implemented with MouseListener, or perhaps with extensions
to the ActionEvent ActionCommand or Modifier.



 Comments   
Comment by georgez [ 08/Jan/05 ]

Reassigned to the "JDIC API (package org.jdesktop.jdic.tray)" subcomponent, as
from release 0.8.6, Tray Icon code/API was incorporated into JDIC. The "tray"
subcomponent is deleted.





[JDIC-74] package.html causes spurious javadoc output Created: 11/Aug/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File packages_html.diff     HTML File t    
Issuezilla Id: 74

 Description   

When creating javadoc, there are several warnings output to the console. The
attached tweeks to the three package.html prevent these warnings.



 Comments   
Comment by chas [ 11/Aug/04 ]

Created an attachment (id=41)
diffs to three package.html files

Comment by paul_huang [ 13/Sep/04 ]

Chas,

Could you please help to specify the warning messages, I get the following
warning messages before applying the patch:
[javadoc]
C:\cvstest\jdicsrc\jdic-0.8.4.1-src\jdic\src\share\classes\org\jdesktop\jdic\filetypes\AssociationService.java:27:
cannot resolve symbol
[javadoc] symbol : class AppAssociationWriterFactory
[javadoc] location: package internal
[javadoc] import org.jdesktop.jdic.filetypes.internal.AppAssociationWriterFactory;
[javadoc] ^
[javadoc]
C:\cvstest\jdicsrc\jdic-0.8.4.1-src\jdic\src\share\classes\org\jdesktop\jdic\filetypes\AssociationService.java:29:
cannot resolve symbol
[javadoc] symbol : class AppAssociationReaderFactory
[javadoc] location: package internal
[javadoc] import org.jdesktop.jdic.filetypes.internal.AppAssociationReaderFactory;
[javadoc] ^
[javadoc]
C:\cvstest\jdicsrc\jdic-0.8.4.1-src\jdic\src\share\classes\org\jdesktop\jdic\desktop\internal\ServiceManager.java:23:
cannot resolve symbol
[javadoc] symbol : class ServiceManagerStub
[javadoc] location: package impl
[javadoc] import org.jdesktop.jdic.desktop.internal.impl.ServiceManagerStub;
[javadoc] ^

However, these warning messages still exist after applying the patch.

Thanks

-Paul

Comment by paul_huang [ 16/Sep/04 ]

Accepted.

Comment by chas [ 01/Oct/04 ]

next attachment show the output I am speaking of

Comment by chas [ 04/Oct/04 ]

Created an attachment (id=73)
the spurious javadoc output

Comment by paul_huang [ 07/Oct/04 ]

Patch accepted and put into branch Issue_74-78, will be merge into trunk from
the branch soon.





[JDIC-75] IconService implementation (from issue 41) Created: 11/Aug/04  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive 75.zip     GZip Archive error.txt.gz     Zip Archive IconService.ZIP     HTML File t     HTML File t     HTML File t     HTML File t     HTML File t2     File test.cpp    
Issuezilla Id: 75

 Description   

Attached is an implementation of an icon service. The icon provider is
pluggable. There is a win32 provider and a Gnome provider. (The gnome provider
has little testing)



 Comments   
Comment by chas [ 11/Aug/04 ]

Created an attachment (id=42)
icon service

Comment by paul_huang [ 16/Sep/04 ]

Hi Chas

Could you please help to illustrate why you used the following code
#pragma pack( 2 )
in WinIconWrapper.cpp.

Thanks

Comment by chas [ 16/Sep/04 ]

The microsoft compiler defaults to 4 or 8 byte sized structures if the pragma is
not used. The offset of GroupEntries within the memory image is improperly
determined without the pragma. See next attachment for the a demonstration of
the sizeof differences.

Comment by chas [ 16/Sep/04 ]

Created an attachment (id=60)
demonstration of sizeof difference

Comment by paul_huang [ 19/Sep/04 ]
      • Issue 39 has been marked as a duplicate of this issue. ***
Comment by paul_huang [ 19/Sep/04 ]
      • Issue 41 has been marked as a duplicate of this issue. ***
Comment by paul_huang [ 27/Sep/04 ]

Bug About IconService
----------------------------
Hi Chas,

I found the following bug during my smoke test for IconService. You may try the
following steps to repeat the bug.

  • Environment: Windows XP with ACDSee 6.0 installed and associate all the
    relevant picture file extension to ACDSee.
  • Try to get the icon image of .bmp, .gif, .jpeg with the following lines of code
    Association tempAssoc = null;
    tempAssoc = AssociationService.getFileExtensionAssociation(fileExtField.getText());
    if (tempAssoc != null) { System.out.println(tempAssoc); Image tempImage = null; tempImage = tempAssoc.getIcon(20); }

You will get the following error message:
java.lang.ArrayIndexOutOfBoundsException: 12064
at org.jdesktop.jdic.icons.impl.WinIconWrapper.TRIPLE(WinIconWrapper.java:84)
at org.jdesktop.jdic.icons.impl.WinIconWrapper.Bitmap(WinIconWrapper.java:146)
at org.jdesktop.jdic.icons.impl.WinIconWrapper.BitmapDir(WinIconWrapper.java:174)
at org.jdesktop.jdic.icons.impl.WinIconWrapper.getImages(WinIconWrapper.java:207)
at
org.jdesktop.jdic.icons.impl.WinIconWrapper.getIconsFromSpecification(WinIconWrapper.java:76)
at org.jdesktop.jdic.icons.impl.WinIconProvider.getIcon(WinIconProvider.java:47)
at org.jdesktop.jdic.icons.IconService.getIcon(IconService.java:65)
at org.jdesktop.jdic.icons.IconService.getIcon(IconService.java:52)

Comment by paul_huang [ 27/Sep/04 ]

Below is the .bmp file Association info FYI.
------------------------------------------
Name: ACDSee.bmp
Description: ACDSee BMP Image
MimeType: image/bmp
Icon File: C:\Program Files\Common Files\ACD Systems\PlugIns\IDE_ACDStd.apl,1
File Extension: .bmp
Action List:
Description:
Verb: ACDPrint
Command: "C:\Program Files\ACD Systems\ACDSee\5.0\ACDSee5.exe" /p "%1"
Description:
Verb: edit
Command: rundll32.exe C:\WINDOWS\system32\shimgvw.dll,ImageView_Fullscreen %1
Description:
Verb: Open
Command: "C:\Program Files\ACD Systems\ACDSee\5.0\ACDSee5.exe" "%1"
Description:
Verb: printto
Command: rundll32.exe C:\WINDOWS\system32\shimgvw.dll,ImageView_PrintTo /pt
"%1" "%2" "%3" "%4"

Comment by chas [ 01/Oct/04 ]

Created an attachment (id=71)
spurious javadoc output

Comment by chas [ 04/Oct/04 ]

Please ignore my previous attachement, it was supposed to be attached to issue 74.

To proceded on the ArrayIndexOutOfBoundsException, I will need a copy of
"C:\Program Files\Common Files\ACD Systems\PlugIns\IDE_ACDStd.apl"

Comment by chas [ 04/Oct/04 ]

Even if I can find a way to support the ACD icon, the following implementation
of getIconsFromSpecification should be used:

public static ImageProducer[] getIconsFromSpecification(String specification) {
final byte[] iconBytes= GetIcon(stringToCharArray(specification));
if(iconBytes==null)
return null;
try

{ return getImages(iconBytes); }

catch(Exception ignore)

{ return null; }

}

Comment by paul_huang [ 08/Oct/04 ]

Well, I assume you are trying to update the implementation of
getIconsFromSpecification.I copied the latest implementation and upload it into
the branch.

Comment by chas [ 12/Oct/04 ]

I think the next patch will fix the ArrayIndexOutOfBoundsException

Comment by chas [ 12/Oct/04 ]

Created an attachment (id=79)
patch to fix ArrayIndexOutOfBoundsException

Comment by paul_huang [ 12/Oct/04 ]

I applied the patch and now checked it into the branch (WinIconWrapper is now
1.1.2.3). My testing result shows the patch fixed the
ArrayIndexOutOfBoundsExcpetion and the icon color problem. However, there is
some regression bug appeared: Before the patch, the icons for filetypes .html
and .pdf could be retrieved (althought there is some color incorrection). After
applying the patch, the icon is retrived as a mess. Please refer to the
attachment for the detailed information.

Comment by paul_huang [ 12/Oct/04 ]

Created an attachment (id=80)
Screen shots and assoc infor for incorrect icon retrieving.

Comment by chas [ 13/Oct/04 ]

Attached will fix messed up 32 bit icons, also fixes color problem.
Additionally, higher numb of color icons will be chosen in preference to lower
number of colors.

Comment by chas [ 13/Oct/04 ]

Created an attachment (id=81)
fix 32bit icons

Comment by paul_huang [ 14/Oct/04 ]

Chas, The latest patch is great! I applied the patch and my demo application to
retrieve the relevant file icon works perfect on Windows platform. Each icon
could be displayed. Thanks for the patch.

However, when I tried to run some icon test on Linux platform, there are some
show stopper bugs happened. I tried to get the icon file for .mp3 and .rm. The
test failed on both Sun JDS (Gnome 2.2, Core 2.4.19) and RedHat Fedora (Gnome
2.4, Core 2.4.22). I will post the error message as an attachment. The test case
is sth like below

Association tempAssoc = null;
tempAssoc = AssociationService.getFileExtensionAssociation(fileExtField.getText());
if (tempAssoc != null) {
System.out.println(tempAssoc);
ImageIcon iconImage = null;
Image tempImage = null;
tempImage = tempAssoc.getIcon((new
Integer(iconSizeField.getText())).intValue());
if (tempImage != null) {
iconImage = new ImageIcon(tempImage);

Comment by paul_huang [ 14/Oct/04 ]

Created an attachment (id=83)
Error Msg to retrieve icon image for .mp3 and .rm on Linux platform

Comment by chas [ 14/Oct/04 ]

Let me first say that I never tested the Unix icon provider. I'm suprised that
it worked as well as it did. However, I was recently was able get a Linux box,
and have done some preliminary tests.

To get anything to work, I needed to add a -fno-exceptions to the CXXFLAGS in
the unix/jni/native/Makefile to get rid of a runtime error:
"__gxx_personality_v0 undefined symbol"

There is still a problem – each time I shut done my test program, I see the
following displayed on the console:

    • ERROR **: Must shutdown ORB from main thread
      aborting...
      Aborted

My belief is that the gnome vfs library routines are initializing an ORB. We
must need to shutdown the library in some fashion.

I think that we should dispense with using the gnome_vfs library and go directly
after the .keys and .mime files. This is probably a new issue.

Comment by chas [ 14/Oct/04 ]

Created an attachment (id=84)
patch to prevent NullPointerException in XdgIconTheme

Comment by paul_huang [ 18/Oct/04 ]

Chas, I applied patch 84 and I wouldn't get any nullpointer exception error now
but I still can't get the icon image for .mp3 and .rm. I checked the relevant
file icon image from nautilus and all of the icon images could be correctly
displayed there.

I tried to debug the code for .mp3 files. The icon file name retrieved is
i-music and it can be found only in /usr/share/pixmaps/Bluecurves/, which is not
the dir listed in the function of
private static File getIconFile(String fileName) of XdbIconTheme.java

Any idea?

Comment by chas [ 18/Oct/04 ]

It would appear that "Bluecurves" is the only theme which contains the image for
.mp3 and .rm files. Try setting your theme to "Bluecurves". Is Bluecurves the
Gnome default theme? KDE's default theme is hicolor.

For more information about how themes work, look at
http://freedesktop.org/Standards/icon-theme-spec. Note that this specification
may not actually be implemented by Gnome at this time.

chas

Comment by chas [ 19/Oct/04 ]

Perhaps the default theme should be set from the gnome desktop configuration.
There appears to be a gtk_icon_theme_get_default() method which might be useful.
We could even go so far as to hook into the gnome desktop configuration
changes. I'm not sure how much is desired.

chas

Comment by chas [ 22/Oct/04 ]

The following patch obtains the default icon theme from the gconf key
"/desktop/gnome/interface/icon_theme". The IconService will not track gconf
configuration changes.

Comment by chas [ 22/Oct/04 ]

Created an attachment (id=90)
obtain default icon theme from gconf on startup

Comment by paul_huang [ 23/Jan/05 ]

An incubator project has been set up for the iconservice project.

Comment by georgez [ 03/Mar/05 ]
      • Issue 200 has been marked as a duplicate of this issue. ***




[JDIC-76] AssociationService pluggable provider (from #41) Created: 11/Aug/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.filetypes)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 89.txt     Zip Archive Associations.zip     HTML File t     HTML File t     HTML File t    
Issuezilla Id: 76

 Description   

Well, the changes are quite extensive. I think certain changes are too
intertwined to make separate updates. I don't have much time at this
point to submit these as independent patches so I'm requesting that you
forgive me as you review this lump of changes. I am very willing to
seperate out those changes that are deemed by the team to be worthy of
integration.

1. Added abstract Provider class for AssociationService. This allows
applications to modify or federate these services. Also allows an
application to specify which provider implementation to use via a System
property.

2. Merged AppAssociationReader and AppAssociationWriter interfaces into
the AssociationProvider abstract class. Merged the implementation classes
into Provider classes which extend AssociationProvider.

3. Added Action.execute. (This is necessary for issue #37)

4. Action.hashCode and Association.hashCode now throw
UnsupportedOperationException. As these are mutable objects, they should
not be used as a key in a HashMap.

5. Moved contents of filetypes/internal/impl to impl. Interfaces which
were in internal are replaced by abstract classes in filetypes/spi.

6. Remove unused native methods – particularly in WinRegistryWrapper.

7. Wherever possible, use native windows methods which take unicode
arguments rather than ansi arguments. This eliminates unnecessary
translation to/from ansi.

8. Added StartUp/ShutDown to native code of WinAssociationProvider.

9. Cleaned windows native includes to minimal set.



 Comments   
Comment by chas [ 11/Aug/04 ]

Created an attachment (id=43)
complete association package

Comment by paul_huang [ 14/Sep/04 ]

Hi Chas

It's really ok. Please forgive our late reply. I will look into your code ASAP.
Thanks for your contribution to JDIC project.

-Paul

Comment by paul_huang [ 16/Sep/04 ]

Good patches to consolidate and enhance JDIC.

Comment by paul_huang [ 22/Sep/04 ]

Hi Chas,

I see you add two APIs for the AssociationService by this patch: getAssociation
and getFileName. However, I feel they are more for internal implementation use
and I don't feel we should public these APIs.

-Paul

Comment by paul_huang [ 22/Sep/04 ]

And the same suggestion for registerAssociation(Association, boolean) &
unRegisterAssociation(Association, boolean). I understand you are trying to
provide user option to specify the "hive" in the registry table but I really
think we should not public them as we already have APIs like
registerUserAssociation/registerSystemAssociation/unregisterUserAssociation/unregisterSystemAssociation

-Paul

Comment by paul_huang [ 23/Sep/04 ]

Implementation for Association.equals

Chas, I see you've used actionList.equals(otherActionList) and
fileExtensionList.equlas(otherFileExtensionList) in the implementation of
Association.equals. However, this will return the undesired result.

Say, we construct an Association assoc1 with the action list contains the
commands "open", "print" and "printto" and the other Association assoc2 with the
same commands but in different order, i.e. "print", "printto", "open".

Theoretically, these two Associations should be equals. However, with the
"equals" method implementation, the comparison will return false. So I changed
them into
(actionList.containsAll(otherActionList) && otherActionList.containsAll(actionList))
and
(fileExtensionList.containsAll(otherExtensionList) &&
otherFileExtensionList.containsAll(fileExtensionList))

Comment by paul_huang [ 23/Sep/04 ]

Hi Chas,

Based on the previous threads I've posted, I did the following modification to
the filetypes patches:
1. Move getFileName(URL) from org.jdesktop.jdic.filetypes.AssociationService
down to org.jdesktop.jdic.filetypes.spi.AppUtility
2. Change registerAssociation(Association, boolean) and
unregisterAssociation(Association, boolean) from public to private
3. Move getAssociation(URL) from org.jdesktop.jdic.filetypes.AssociationService
to org.jdesktop.jdic.desktop and set it as private

You may checkout the latest code from the branch Issue_74-78. You are welcome to
raise your oppinion.

Comment by paul_huang [ 29/Sep/04 ]

Hi Chas

I feel that you might missed a file in the patch: WinRegistryWrapper.cpp.

-Paul

Comment by paul_huang [ 29/Sep/04 ]

Sorry, Chas. My mistakes, it seems that the following 2 files could be deleted
from the patch: org.jdesktop.jdic.filetypes.WinRegistryUtil.java,
org.jdesktop.jdic.filetypes.WinRegistryWrapper.java

Accordingly, the file org.jdesktop.jdic.desktop.impl.WinUtility needs some small
changes to use the API from WinAssociationProvider instead of WinRegistryWrapper.

In this way, the file WinRegistryWrapper.cpp will no longer be required.

-Paul

Comment by paul_huang [ 18/Oct/04 ]

Hi Chas,

I have did some changes to the Service-Provider pattern. The original
Service-Provider pattern will support Singleton only. Some of the JDIC
components would require Multiton. The changes will allow developers to specify
which style to be used: Single or Multiton.

You may checkout the latest code from branch Issue_74-78. You are welcome to
bring up any refinement.

Thanks

Comment by chas [ 18/Oct/04 ]

I would suggest the following attached refinements.

Comment by chas [ 18/Oct/04 ]

Created an attachment (id=86)
proposed refinements to multi-instance providers

Comment by paul_huang [ 18/Oct/04 ]

I checked the patch 86 and it seems that the modified ProviderFactory will still
support Singleton only. Let's look at the following code:
--------------------------------
public Provider getProvider() {
if (provider == null)

{ createProvider(); }

return provider;
}
--------------------------------
In this case, the ProviderFactory will only create and return one single
provider in its lifecycle. And the same for CreateProvider(), based on this
patch, the Provider will be created only once.

I don't think this will provide a support for Multiton.

Comment by chas [ 19/Oct/04 ]

The 'provider' member will only get set if this is a singleton ProviderFactory.
Look at method loadProvider, lines 115-116:

if (isSingleton)
provider= ip;

Perhaps this is too subtle without documentation. Please review next attachment.
chas

Comment by chas [ 19/Oct/04 ]

Created an attachment (id=87)
add documentation to previous patch

Comment by chas [ 19/Oct/04 ]

I think the spi packages should be included in the javadoc.

Comment by chas [ 19/Oct/04 ]

Created an attachment (id=88)
Add spi packages to javadoc

Comment by paul_huang [ 22/Oct/04 ]

I checked the patch #87 and I don't think it would support the multiton. The
only way to instantiate a Provider would be through the function
public synchronized Provider getProvider()
However, patch #87 would only allow one Provider to be created.
I will submit a new patch to support Singleton & Multiton. Please check.

Thanks

-Paul

Comment by paul_huang [ 22/Oct/04 ]

Created an attachment (id=89)
Patch to provide support for Singleton & Multiton Provider

Comment by paul_huang [ 22/Oct/04 ]

I am not quite agree with you to put spi into the javadoc. As you could see, we
curretly only public the "functional" component in the javadoc. For spi,
although it's quite important and it does introduce a quite good pattern, it's
not the functional component and it is only used internally.

From another point of view, there are two kinds of developers,
1) The developers who just wish to use JDIC API
2) The developers who coding JDIC itself.

The javadoc is targetting at the 1st kind of developers, who only wish to see
the funcitonal API.
That said, I would like to suggest we leave the spi outside of Javadoc.

-Paul

Comment by chas [ 22/Oct/04 ]

JDK 1.4 javadoc includes at least 7 spi packages: java.awt.im.spi,
java.nio.channels.spi, java.nio.charset.spi, javax.imageio.spi,
javax.naming.spi, javax.security.auth.spi, javax.sound.midi.spi,
javax.sound.sampled.spi – Documenting the spi allows developers to get a
greater sense of how the api works and how it is to be used.





[JDIC-77] Desktop pluggable provider (from #41) Created: 11/Aug/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: chas Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive Desktop.zip    
Issuezilla Id: 77

 Description   

These changes are on top of IconService (issue 75) and AssociationService
(issue 76)

1. Added abstract Provider classes for MailService and BrowserService. This
allows applications to modify or federate these services. Also allows an
application to specify which provider implementation to use via a System property.

2. Layered desktop open/edit/print on top of Action.execute. (issue 37) This
eliminates duplicate code and, for Windows, eliminates the need for the SDK
update (AssocQueryString is no longer being used.) However, this will probably
break Mac OS X.

3. Moved contents of desktop/internal/impl to impl. Interfaces which were in
internal are replaced by abstract classes in desktop/spi.

4. Added StartUp/ShutDown to native code of WinDesktopWrapper.



 Comments   
Comment by chas [ 11/Aug/04 ]

Created an attachment (id=44)
Desktop pluggable provider

Comment by paul_huang [ 16/Sep/04 ]

Hi Chas

I really like your patches. I can see you've spend a lot of time and energy on
these patches and I see these patches as strong consolidation and enhancement to
the current JDIC. I really appreciate your contribution to JDIC project. I will
organize an internal code review for your patches and get back to you ASAP.

Thanks again!

-Paul

Comment by paul_huang [ 29/Sep/04 ]

Chas,

The two function in WinDesktopWrapper.cpp should be
Java_org_jdesktop_jdic_desktop_impl_WinDesktopWrapper_StartUp
Java_org_jdesktop_jdic_desktop_impl_WinDesktopWrapper_ShutDown
Instead of
Java_org_jdesktop_jdic_filetypes_impl_WinDesktopWrapper_StartUp
Java_org_jdesktop_jdic_filetypes_impl_WinDesktopWrapper_ShutDown





[JDIC-78] junit tests for IconService and AssociationService Created: 11/Aug/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive Tests.zip    
Issuezilla Id: 78

 Description   

I have attached the junit tests which I used to verify the changes for issues
#75 and #76. The build.xml has new targets for testing.

Additionally build.xml features these other changes:

1. Separated jdic.jar into jdic.jar and jdic-platform.jar. This will allow a
single distribution with all jars. Currently, developers must merge multiple
source distributions when setting up a webstart server.

2. Java portions of code can be compiled regardless of platform.

3. Added Implementation-Title and Implementation-Version to jar files. Added
Class-Path to jdic.jar



 Comments   
Comment by chas [ 11/Aug/04 ]

Created an attachment (id=45)
tests for IconService and AssociationService





[JDIC-85] Configuration patch dose not work on Linux Created: 31/Aug/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: demo
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: conny Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 85

 Description   

The Browser test case can not run on Linux without setting the environment
variables MOZILLA_FIVE_HOME and LD_LIBRARY_PATH.



 Comments   
Comment by conny [ 31/Aug/04 ]

On Linux, the Configuration patch works well with Mozilla version both 1.4 for
Sun Java Desktop System and 1.4.1 for Sun Java Desktop System, but not with
other versions.

Comment by conny [ 02/Sep/04 ]

This bug can reproduce by using the new released version(Sep.2nd) with Mozilla
1.4.1 from the mozilla.org website. In this build the mozembed-linux-gtk1.2 file
is added into the folder jdic-linux-native, since that the gtk1.2 is used by the
Mozilla 1.4.1 from the mozilla.org website. Now both the file
mozembed-linux-gtk1.2 and mozembed-linux-gtk2 are in this folder. But it seems
that the java code can not determin which file should be used.

The error message is as follow:
+++ Ctrace:
+++ Ctrace: (mozembed-linux-gtk2:2747): Gtk-CRITICAL **: file gtktypeutils.c:
line 43 (gtk_type_unique): assertion `GTK_TYPE_IS_OBJECT (parent_type)' failed
+++ Ctrace:
+++ Ctrace: (mozembed-linux-gtk2:2747): Gtk-CRITICAL **: file gtktypeutils.c:
line 100 (gtk_type_new): assertion `GTK_TYPE_IS_OBJECT (type)' failed





[JDIC-88] Allow multiple JARs for screensavers Created: 09/Sep/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Screensavers
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markroth8 Assignee: markroth8
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 88

 Description   

It should be possible to deliver a screensaver in multiple JARs instead of
forcing it all in one JAR.

The only way to do this today is to include the list of JARs separated by ':' or
';'. However, Windows and Unix use different separators so one has to manually
go in and adjust the Windows vs. Unix binaries.

The SDK should be adjusted so that a list of JARs separated by ':' will change
to ';' on Windows so that multiple JARs can be included in the classpath for the
screensaver.



 Comments   
Comment by markroth8 [ 09/Sep/04 ]

Added amira to cc list





[JDIC-90] Please add tray notification pop-ups Created: 14/Sep/04  Updated: 08/Jan/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jknowles Assignee: bino_george
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 90

 Description   

As requested in this forum thread:

http://www.javadesktop.org/forums/thread.jspa?threadID=3598

Please add notification pop-ups to the systray project.



 Comments   
Comment by georgez [ 08/Jan/05 ]

Reassigned to the "JDIC API (package org.jdesktop.jdic.tray)" subcomponent, as
from release 0.8.6, Tray Icon code/API was incorporated into JDIC. The "tray"
subcomponent is deleted.





[JDIC-91] 0.8.5 FreeBSD port Created: 15/Sep/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: 0.8.5
Fix Version/s: None

Type: Task Priority: Major
Reporter: hmichelon Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: FreeBSD
Platform: PC


Attachments: Text File issue91_0.8.5_freebsd_1.diff     Text File jdic-0.8.5-freebsd.diff    
Issuezilla Id: 91

 Description   

in src/jdic/src/unix/native/jni/Makefile:
Since libdl, libpthread and librt are OS-specific libraries, move -ldl,
-lpthread and -lrt in OS-dependent part of the Makefile
This changes aren't specific to the FreeBSD port (but needed because these
libraries are part on libc under FreeBSD, and using them when calling ld cause
an error) and add more "portability" to the makefile.



 Comments   
Comment by hmichelon [ 15/Sep/04 ]

Created an attachment (id=58)
FreeBSD port

Comment by georgez [ 22/Sep/04 ]

Hi Henri,

Sorry for the late response.

The new patch looks fine. I just recreate the patch using -u option, to make it
easier to read. It's checked into the source tree.

Could you help to get a binary 0.8.5 for FreeBSD and send it to me ?

Thanks,

Comment by georgez [ 22/Sep/04 ]

Reassigned to me (georgez).

Comment by georgez [ 22/Sep/04 ]

Created an attachment (id=66)
Updated patch for 0.8.5 on FreeBSD.





[JDIC-98] Can not generate package by using relative path to the JNLP file on Solaris Created: 24/Sep/04  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: conny Assignee: joey_shen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 98

 Description   

On Solaris, can not generate package by using relative path of the JMLP file.
The following message was printed on the terminal:

— Output messages while generating the PKG package —

    1. Building pkgmap from package prototype file.
      ERROR in ./jnlps/notepad/prototype:
      no object for <images/notepad.gif> found in local path
      no object for <notepad.jar> found in local path
      no object for <notepad.jnlp> found in local path
      no object for <notepad.jnlp.bak> found in local path
      no object for <pkginfo> found in local path
      no object for <checkinstall> found in local path
      no object for <postinstall> found in local path
      no object for <postremove> found in local path
      pkgmk: ERROR: unable to build pkgmap from prototype file
    2. Packaging was not successful.





[JDIC-110] Leverage the service-provider pattern on tray component Created: 30/Sep/04  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.8.6
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paul_huang Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 110

 Description   

Try to apply the service-provider pattern to the package org.jdesktop.jdic.tray



 Comments   
Comment by paul_huang [ 30/Sep/04 ]

Will try to apply the service-provider pattern for org.jdesktop.jdic.tray on the
branch Issue_74-78 and then merge into the trunk.

Comment by georgez [ 03/Mar/05 ]

Should be an "Enhancement".





[JDIC-113] Specify the supported mailer in relevant document Created: 30/Sep/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: 0.8.6
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paul_huang Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 113

 Description   

Current Desktop API mail() and mail(Message) only supports limited email client.
We should specify the supported email client in the relevant document or else
the user may feel confused when getting unsupported exception.






[JDIC-116] libjdic.so has the same name for Linux and Solaris Created: 02/Oct/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: 0.8.6
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Martin Grebac Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 116

 Description   

libjdic.so has the same name for solaris and linux, even though these are
different binaries. The files then have to be stored in different locations (if
one wants to distribute all os versions altogether). If it's possible, I'd
suggest to name the files to libjdic-linux.so libjdic-solaris.so



 Comments   
Comment by chas [ 08/Oct/04 ]

This proposed name mangling scheme does not take into account that a particular
platform may have multiple architectures (eg. x86 and sparc.)

Comment by Martin Grebac [ 08/Oct/04 ]

That's true. Would adding the platform string at the end (like
libjdic-solaris-x86.so) be sufficient?

Comment by georgez [ 08/Oct/04 ]

Hi Chas / snajper:

I see the points doing that. Then the code needs a small update:
Change
System.loadLibrary("jdic");
to
System.loadLibrary("jdic-***");
based on the running platform.

This is part of the solution to the one common, OS independent release problem.
I'll work on that the give a proposal. Thanks.





[JDIC-120] Build JDIC Browser component against Gecko SDK and Mozilla binary on Windows. Created: 07/Oct/04  Updated: 21/Jun/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: georgez Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 120

 Description   

This issue is actually the similar problem with issue#119(Build JDIC Browser
component against Gecko SDK and Mozilla binary on Unix.). But as the code base
of Browser component for Windows and Unix is different, the fix is also different.

So, I reported this new issue to track the fix for Windows platforms.



 Comments   
Comment by dongdongyang [ 21/Jun/06 ]

Assign to Michael.





[JDIC-122] MouseListener on tray Created: 08/Oct/04  Updated: 08/Jan/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: bflorat Assignee: bino_george
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 122

 Description   

Hi,

It would be nice if we could add a MouseListener and a MouseWheelListener on the
tray ( for instance to set volume using the mouse wheel just over the tray). I
know we can add it on the tray popup but it would be better if we could control
the tray without having to open it.



 Comments   
Comment by georgez [ 08/Jan/05 ]

Reassigned to the "JDIC API (package org.jdesktop.jdic.tray)" subcomponent, as
from release 0.8.6, Tray Icon code/API was incorporated into JDIC. The "tray"
subcomponent is deleted.





[JDIC-135] cross-platform release Created: 18/Nov/04  Updated: 14/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: 0.8.6
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: armin_chen Assignee: armin_chen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File build.xml     Zip Archive cross-platform.zip     Text File cross_platform.diff     Text File cross_platform_jdic.diff     Text File cross_platform_jdic.diff    
Issuezilla Id: 135

 Description   

Provide a cross-platform jdic release.



 Comments   
Comment by armin_chen [ 18/Nov/04 ]

Created an attachment (id=98)
Rename some classes such as ServiceManagerStub

Comment by armin_chen [ 18/Nov/04 ]

Rename the following classes to Win*** and Gnome***:
org.jdesktop.jdic.desktop.internal.imp.ServiceManager
org.jdesktop.jdic.tray.internal.imp.ServiceManager
org.jdesktop.jdic.filetypes.internal.AppAssociationReaderFactory
org.jdesktop.jdic.filetypes.internal.AppAssociationWriterFactory

And change the following files:
share/classes/org/jdesktop/jdic/desktop/internal/ServiceManager.java
share/classes/org/jdesktop/jdic/tray/internal/ServiceManager.java
share/classes/org/jdesktop/jdic/filetypes/AssociationService.java

Comment by armin_chen [ 19/Nov/04 ]

Created an attachment (id=100)
Rewrite build.xml for jdic.

Comment by armin_chen [ 19/Nov/04 ]

Created an attachment (id=101)
The new build.xml

Comment by armin_chen [ 17/Dec/04 ]

Created an attachment (id=114)
replace the org.jdesktop.jdic.init.JdicManager.java and the build.xml for jdic with this one.

Comment by armin_chen [ 14/Mar/05 ]

Created an attachment (id=171)
diff JdicManager.java and build.xml for cross_platform build





[JDIC-137] Proposal: new tray design/implementation Created: 21/Nov/04  Updated: 16/Dec/04

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: cowwoc Assignee: bino_george
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive jace-1.2.zip     Zip Archive tray-1.0.zip    
Issuezilla Id: 137

 Description   

I'm attaching a copy of my system-tray library for your review. I would like you
to consider replacing the current org.jdesktop.jdic.tray design/implementation
with my own.

PRO:

  • Cleaner implementation with more comments
  • Cleaner design (same flexibility with half the number of classes).
  • Native L&F: the windows L&F of my library is far closer to native than the old
    tray library. With the exception of two minor known bugs, it feels completely
    native.
  • Easy migration: from an end-user perspective, migration from the old to the
    new API will be a very simple matter. (we'd rename the package name of my
    library to use org.jdesktop.jdic.tray)

CON:

  • Only supports win32. We'd need to ported the old code to the new API
  • Requires JDK 1.5, WindowsXP. We'd need to port it to older platforms.
  • Does not support animating icons or floating bubble captions although these
    are easy to add.

In a nutshell, my library focuses on stability and maintainability. We can (and
should) expand this over time to support other platforms. It would be easy to
take the old tray code and port it to my new API.

Please take a look at my library, should you wish to make use of its contents, I
will require a developer's role for this project.

Thank you,
Gili Tzabari



 Comments   
Comment by cowwoc [ 21/Nov/04 ]

Created an attachment (id=102)
Tray library source-code

Comment by cowwoc [ 21/Nov/04 ]

I will attach Jace 1.2 as soon as I get clearance from its author. Meanwhile
feel free to look over my code.

Comment by cowwoc [ 21/Nov/04 ]

Created an attachment (id=103)
Please replace the old source-code package with this new one. The old one was incorrect.

Comment by cowwoc [ 22/Nov/04 ]

Created an attachment (id=104)
Unofficial JACE 1.2 release

Comment by cowwoc [ 22/Nov/04 ]

Ok, now extract JACE 1.2 into some directory (say c:\program files\jace), set an
environment variable JACE_HOME pointing to c:\program files\jace\release.

Then extract the tray API into another directory, run "ant" followed by "ant
test" and away you go. I look forward to your feedback.

Comment by bino_george [ 08/Dec/04 ]

I tried building this code, but it seems to give me
the following errors :

Buildfile: build.xml

release:
[echo]
[echo] ### Building TrayCore ###
[echo]

pack200task:

BUILD FAILED
C:\gili\build.xml:41: The following error occurred while executing this line:
C:\gili\core\build.xml:7: taskdef class com.sun.tools.apache.ant.pack200.Pack200
Task cannot be found

Comment by cowwoc [ 08/Dec/04 ]

Bino,

See https://java-pack200-ant-task.dev.java.net/ for the Pack200 ant task. I will
add this to the documentation.

Thank you,
Gili

Comment by cowwoc [ 15/Dec/04 ]

Ok, an update...

First, please edit this page: https://jdic.dev.java.net/developer.html

and note that "Our Contributers -> cowwoc" maps to "Gili Tzabari", that's me

Secondly, I have updated the Tray API and Jace to allow it to run under Java
Webstart. I would like to know what you think of the code I have already posted.
Did you take a look at it?

Thirdly, I am a bit concerned about the fact that this project is licensed under
LGPL. There has been a lot of negative noise coming from FSF recently regarding
their view that if you use a LGPL library, you must open up your application to
reverse engineering and other ugly things (section 6 of the LGPL license). See
http://www.javalobby.org/forums/thread.jspa?threadID=15903&messageID=91818939&tstart=0
for more information. Is it possible for us to relicense the project under a
more liberal license? Sun's licenses make me more comfortable.

Thanks,
Gili





[JDIC-151] Animated gif blink on notification area of Gnome. Created: 02/Jan/05  Updated: 02/Jan/05

Status: Open
Project: jdic
Component/s: demo
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gvelo Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 151

 Description   

Animated gif ( duke.gif ) blink on notification area.

This is the context:
Java Web Start ( running the Demo on
http://javadesktop.org/jdic/demo/TrayIcon/trayicon.jnlp )
j2sdk1.4.2_05
gnome 2.8.1






[JDIC-154] Packager Silent Install Option Created: 07/Jan/05  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mrtivo Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 154

 Description   

It would be great if the packager had an ability to create installers that can
be ran silently. It would also be great if the packager just made msi files.






[JDIC-156] Add pack200 compression support for jars packaged with JDIC Packager Created: 07/Jan/05  Updated: 29/Apr/05

Status: Open
Project: jdic
Component/s: Packager
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: keithkml Assignee: paul_huang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 156

 Description   

Pack200 + GZIP allows for huge compression (60-90%) of jar files. Packing jars
into the JDIC Packager installers, then unpacking them upon installation, would
make most JDIC-created installer packages much smaller. (This is how Sun's
JRE/JDK installers are so small, compard to their uncompressed size.)



 Comments   
Comment by georgez [ 03/Mar/05 ]

Should be an "Enhancement".





[JDIC-159] Browser component does not handle NTLM authentication Created: 13/Jan/05  Updated: 13/Jan/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: alarenal Assignee: armin_chen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: Other
URL: http://www.javadesktop.org/forums/thread.jspa?threadID=7243&tstart=0


Issuezilla Id: 159

 Description   

When trying to access web site on Microsofts IIS server with active NTLM
authentication (so called "Integrated Windows Authentication") the browser
component does not handle the authentication request and therefore access to the
site is denied.






[JDIC-162] Icon Provider does not provide proper size image Created: 18/Jan/05  Updated: 24/Jan/05

Status: Open
Project: jdic
Component/s: IconService
Affects Version/s: IconService0.1.1
Fix Version/s: IconService0.1.2

Type: Bug Priority: Major
Reporter: chas Assignee: chas
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Attachments: Text File scale.diff    
Issuezilla Id: 162

 Description   

The UnixIconProvider does not scale the icon found.



 Comments   
Comment by chas [ 18/Jan/05 ]

Created an attachment (id=133)
properly scale icon image

Comment by paul_huang [ 24/Jan/05 ]

Please apply the patch to the Iconservice incubator project.

Comment by paul_huang [ 24/Jan/05 ]

Update version info to IconService0.1.1 and Milestone to IconService 0.1.2





[JDIC-163] Icon Provider does not provide proper size image Created: 18/Jan/05  Updated: 24/Jan/05

Status: Open
Project: jdic
Component/s: IconService
Affects Version/s: IconService0.1.1
Fix Version/s: IconService0.1.2

Type: Bug Priority: Major
Reporter: chas Assignee: chas
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: All


Attachments: Text File scale.diff    
Issuezilla Id: 163

 Description   

The WinIconProvider does not scale icon image if necessary



 Comments   
Comment by chas [ 18/Jan/05 ]

Created an attachment (id=134)
get scaled image if necessary

Comment by paul_huang [ 24/Jan/05 ]

Chas,

Please apply this patch directly into the Iconservice incubator project. I also
add a new sub component IconService for easy referecne.

Thanks

-Paul

Comment by paul_huang [ 24/Jan/05 ]

Update version info to IconService0.1.1 and Milestone to IconService 0.1.2





[JDIC-169] duplicate "open" actions in Association Created: 20/Jan/05  Updated: 24/Jan/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.filetypes)
Affects Version/s: Branch-Issue_74-78
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chas Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Attachments: Text File open.diff    
Issuezilla Id: 169

 Description   

If a default application has been added for a mime type, (using the
desktop/Preferences/File Types and Programs applet,) the
GnomeAssociationProvider will add two "open" actions to the mime type association.



 Comments   
Comment by chas [ 20/Jan/05 ]

Created an attachment (id=137)
prevent duplicate "open" action

Comment by paul_huang [ 24/Jan/05 ]

The patch has been checked into the branch.





[JDIC-170] Browser doesn't work with Mozilla 1.4 .exe installation. Created: 22/Jan/05  Updated: 22/Feb/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: georgez Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 170

 Description   

This problem is related with issue#101:
https://jdic.dev.java.net/issues/show_bug.cgi?id=101

but it only happens with Mozilla 1.4.* .exe installation. So I open this new
issue. The exact problem is reported as a mozilla bug#279209
https://bugzilla.mozilla.org/show_bug.cgi?id=279209

The relevant code is at:
https://jdic.dev.java.net/source/browse/jdic/src/jdic/src/share/native/mozilla/Common.cpp?rev=1.3&content-type=text/vnd.viewcvs-markup

It could be reproduced by using 0.8.7 on Windows setting mozilla 1.4 (installed
by a .exe package) as the default browser.



 Comments   
Comment by michael_shan [ 22/Feb/06 ]

Assign to Michael.





[JDIC-174] Browser component integration in JDK Created: 27/Jan/05  Updated: 31/Jan/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.7
Fix Version/s: None

Type: Task Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 174

 Description   

As JDIC Browser component was approved to be included into later JDK releases
(Mustang or Dolphin). This issue is created to track the process.



 Comments   
Comment by georgez [ 27/Jan/05 ]

I would be the contact point from the JDIC side and will work on it.

Comment by georgez [ 27/Jan/05 ]

A branch ISSUE_174_BRANCH is created in the CVS repository for this issue.

Comment by georgez [ 31/Jan/05 ]

The Browser API spec is updated according to the feedback from J2SE AWT team. A
post sent to the forum:
http://www.javadesktop.org/forums/thread.jspa?threadID=8186&tstart=0

And the state of this issue is changed to "STARTED".





[JDIC-175] File Changes watch Created: 01/Feb/05  Updated: 20/Oct/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: 0.8.4
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: rlopes Assignee: georgez
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 175

 Description   

It would be nice to have notification of changes on the filesystem.
Probably something like this:

http://www.jniwrapper.com/winpack_features.jsp#filewatch



 Comments   
Comment by georgez [ 03/Mar/05 ]

Should be an "Enhancement".

Comment by keithkml [ 28/Apr/05 ]

add self cc

Comment by georgez [ 28/Apr/05 ]

I made a mistake. This should be categorize as a "FEATURE", insteaf of an
"Enhancement".

Comment by coxcu [ 04/Aug/06 ]

For some applications, this feature is absolutely essential. If it isn't
available on all platforms (is it?), the API needs to be carefully designed to
reflect that. I definitely favor this feature, even if it isn't available on
all platforms.

Comment by coxcu [ 05/Oct/06 ]

The JNI wrapper link given before is dead. This one is live now.
http://www.jniwrapper.com/jniwrapper_downloads/samples/FileSystemWatcherSample.java

In case that goes dead, here are the relevant imports:

import com.jniwrapper.win32.io.FileSystemEvent;
import com.jniwrapper.win32.io.FileSystemEventListener;
import com.jniwrapper.win32.io.FileSystemException;
import com.jniwrapper.win32.io.FileSystemWatcher;

Comment by coxcu [ 20/Oct/06 ]

See also:

"Separate libraries for Windows and Mac OSX that enable Java programs to get
alerts when files are created, deleted or modified on a PC/Mac."
https://filewatcher.dev.java.net/





[JDIC-176] File Attribute Hidden Created: 01/Feb/05  Updated: 04/Aug/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: 0.8.4
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: rlopes Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 176

 Description   

The java api can't set the hidden attribute for a file on windows.



 Comments   
Comment by georgez [ 03/Mar/05 ]

Should be a "Feature".

Comment by coxcu [ 04/Aug/06 ]

Rather than being able to manipulate the hidden attribute, how about the following?

/**

  • Return true, if the file is hidden.
    */
    public boolean isHidden();

/**

  • Make the file hidden if hidden is true, otherwise make it visible.
  • On some platforms, visibility is determined by a naming convention,
  • so this may result in the file being renamed.
  • Returns true if the file was previously hidden and false otherwise.
  • Throws the appropriate exception if changing the hiddenness of the file
  • was not possible.
    */
    public boolean setHidden(boolean hidden) throws AppropriateException;

I favor throwing an exception on failure, because forgetting to check the
boolean on File.delete() and File.rename() is a frequent cause of bugs. The
fact that some of those bugs are platform specific only makes it worse.





[JDIC-180] "https" protocol dose not work properly with Browser component Created: 02/Feb/05  Updated: 03/Mar/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: conny Assignee: michael_shan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 180

 Description   

On windows xp and 2000 platform, reproduce steps:
1. set Mozilla as the default browser
1. start Browser demo application
2. input https://jdic.dev.java.net into the URL field
3. the browser dose not link to the https site, the URL changes back to the old one

Mozilla is installed by *.exe file and downloaded from mozilla.org

This issue dose not happen with IE on windows platform.



 Comments   
Comment by michael_shan [ 03/Mar/06 ]

Assign to Michael.





[JDIC-184] Remove the two new APIs Created: 06/Feb/05  Updated: 06/Feb/05

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: Branch-Issue_74-78
Fix Version/s: None

Type: Task Priority: Major
Reporter: paul_huang Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 184.patch    
Issuezilla Id: 184

 Description   

This patch will remove the two new APIs introduced from the refactoring patch:
1. Action.execute();
2. AssociationService.getProtocolAssociation()

The original patch was contributed by Chas.



 Comments   
Comment by paul_huang [ 06/Feb/05 ]

Created an attachment (id=145)
Patch to remove the two new APIs

Comment by paul_huang [ 06/Feb/05 ]

Put the patch into CVS branch.





[JDIC-189] Would it be possible for org.jdesktop.jdic.tray.TrayIcon to extend javax.swing.Icon instead of Object? Created: 16/Feb/05  Updated: 16/Feb/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: sgregory Assignee: bino_george
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 189

 Description   

Would it be possible for org.jdesktop.jdic.tray.TrayIcon to extend javax.swing.Icon instead of Object? It
seems a more natural fit (and that would have made a project I am working on a little easier ).

  • Thanks!





[JDIC-190] Fire javax.swing.event.HyperlinkEvent's (ENTERED, EXITED, and ACTIVATED) Created: 16/Feb/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: sgregory Assignee: kyleyuan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 190

 Description   

Please fire javax.swing.event.HyperlinkEvent's (ENTERED, EXITED, and ACTIVATED). These events could
be added to the org.jdesktop.jdic.browser.WebBrowserEvent /
org.jdesktop.jdic.browser.WebBrowserListener mechanism instead, but
javax.swing.event.HyperlinkEvent has been around as long as Swing and thus the current standard.

This plus org.jdesktop.jdic.browser.WebBrowserListener should allow a resonable functional status
area to be made for WebBrowser's.



 Comments   
Comment by georgez [ 03/Mar/05 ]

Should be an "Enhancement".





[JDIC-193] [Incubator Project] SystemInfo package. Created: 24/Feb/05  Updated: 27/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: 0.8.8
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: carldea
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 193

 Description   

This issue is reported to track two new features proposed by John Ellis and Carl:
// Check user idle time
http://www.javadesktop.org/forums/thread.jspa?threadID=8462&tstart=0
and
// Check if the system is locked.
http://www.javadesktop.org/forums/thread.jspa?threadID=8646&tstart=0

Both are small APIs: long getIdleTime() and boolean isLocked().

As both these two features provide system information, and there are other
system information such as system load, etc. I'd suggest to put all these APIs
into a new package systeminfo (or systemutil), to be held as an incubator
project. Comments are welcome.



 Comments   
Comment by carldea [ 26/Mar/05 ]

The method name for the Session Idle Time feature is:

long SystemInfo.getSessionIdleTime()

The method name for the Session Locked feature is:

boolean SystemInfo.isSessionLocked()

I made the SystemInfo class with a private constructor since this should be a
singleton (I think).
I would like to also test this under Java 1.5 for JVM class sharing to see if
two users on Window XP w/ fast user switching is affected.

Comment by georgez [ 27/Mar/05 ]

As Carl and John are the owners of this incubator project (package
org.jdestkop.jdic.systeminfo) SystemInfo, assign this issue to Carl. And change
it status to "STARTED".

Comment by georgez [ 27/Mar/05 ]

Status changed from "NEW" to "STARTED".





[JDIC-196] Improved API for Icon Size determination Created: 25/Feb/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: davyboyhayes Assignee: bino_george
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 196

 Description   

I won't reiterate a previous issue for more getter methods, but add to them
instead. I noticed that when running under Windows (XP), the default icon size
is 16x16. Upon inspecting the WinTrayIconService.java code, I see that these are
constants. This is not the true case in windows. You can actually have larger or
smaller icon sizes under windows, due to change in DPI settings etc.... For some
random reason, my current system setting has them set to 17x17. Under my
KDE-linux setup, my icon size is 32x32.

What would be good to see, is under SystemTray, there is a java.awt.Dimension
getCurrentIconSize() method which would inspect the current tray settings on the
OS, to determine the size of the icon you need to generate. Furthermore, under
TrayIcon, a similar java.awt.Dimension getCurrentIconSize(). This may be
difficult to achieve though under Windows, as I have not been able to find
suitable methods of detecting this.

Why would this be useful? If you were able to get the size of the icon first,
you would be able to select suitable pre-drawn icons for the size, rather than
resize a large graphic down. The duke.gif animated gif in the TrayDemo looks a
little awful under Windows, because it is being squashed out of it's aspect
ratio, and there is no kind of sub-pixel rendering to improve the graphic. If
this was left up to the graphic designer or the java implementor at the time, to
know what size icon they need to draw, it would look a lot better.

Thanks,

Davy Boy Out...



 Comments   
Comment by davyboyhayes [ 25/Feb/05 ]

Found a project on CodeProject which might help for windows side of things...
http://www.codeproject.com/shell/trayposition.asp

Many thanks,

Davy Boy Out...

Comment by georgez [ 03/Mar/05 ]

Should be an "ENHANCEMENT".





[JDIC-198] Menu Hidden by Auto-Hide Always-on-top Taskbar (0.8.8) Created: 01/Mar/05  Updated: 01/Mar/05

Status: Open
Project: jdic
Component/s: demo
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yonghow_r Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: All


Issuezilla Id: 198

 Description   

Referring to issue 153... I am still have the same problem when I try the Tray
demo from the version 0.8.8.
I tried to the bi-weekly download (jdic-20050117-bin-windows.zip),
but got the following error when I tried to do a right-click :

=============================================
java.lang.NoSuchMethodError: javax.swing.JDialog.setAlwaysOnTop(Z)V
at org.jdesktop.jdic.tray.internal.impl.WinTrayIconService.processEvent
(Unknown Source)
at org.jdesktop.jdic.tray.internal.impl.WinTrayIconService$2.run
(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy
(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForHierarchy
(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
=============================================

I am using Java version 1.4.2



 Comments   
Comment by armin_chen [ 01/Mar/05 ]

setAlwaysOnTop() is a new API since JDK1.5, so this bug only fixed for JDK1.5.
Noticed that your java version is 1.4.2, so you still have the problem.

Comment by yonghow_r [ 01/Mar/05 ]

Hi Armin,

Thanks, I thought so too. Thats why I put my JDK version in the issue.
Thanks for clarifying, I will try with JDK 1.5.

Regards,
Yong How





[JDIC-199] Javascript "window.print()" doesn't work using executeScript(). Created: 02/Mar/05  Updated: 30/Aug/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Bug Priority: Major
Reporter: georgez Assignee: dongdongyang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File ScriptWinPrintBrowser.java    
Issuezilla Id: 199

 Description   

With Browser API executeScript() added to release 0.9, Javascript
"window.print()" should be able to print the currently loaded page.

But with the biweekly build 20050302, it works with IE and Mozilla unzipped from
a .zip package on Windows. But it hangs in the "Preparing" dialog with Mozilla
installed from a .exe package on Windows and Mozilla on Linux.



 Comments   
Comment by georgez [ 02/Mar/05 ]

I'll look at it.

Comment by dongdongyang [ 21/Jun/06 ]

Created an attachment (id=242)
testcase

Comment by dongdongyang [ 30/Aug/06 ]

Being of team member changing, reassigned the issue.





[JDIC-201] TrayIcon PNG-24 support Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.tray)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: bino_george
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 201

 Description   

This issue was reported by below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=7463&tstart=50






[JDIC-202] Controling windows volume control(Audio Mixer) Created: 03/Mar/05  Updated: 14/Jul/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: 0.8.8
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 202

 Description   

This issue was reported in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=7119&tstart=100



 Comments   
Comment by georgez [ 14/Jul/05 ]

Just an update. This feature is somewhat covered in the Misc incubator project:
https://jdic.dev.java.net/incubator/misc/index.html

which include a Volume API to get, set, and monitor the system volume.





[JDIC-203]  Make a java app to start on boot Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: 0.8.8
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 203

 Description   

This issue was reported in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=7097&tstart=100






[JDIC-204] Native app launcher/executable. Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 204

 Description   

This feature was stated in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=6692&tstart=150



 Comments   
Comment by georgez [ 03/Mar/05 ]

Another thread on this feature:
http://www.javadesktop.org/forums/thread.jspa?threadID=2884&tstart=150

Comment by georgez [ 03/Mar/05 ]

Should be a "FEATURE".





[JDIC-205] Access HTTP proxy settings in standalone apps Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 205

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=6011&tstart=150






[JDIC-206] Features useful for testers Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 206

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=5978&tstart=0






[JDIC-207] Pdf viewer Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 207

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=2695&tstart=50



 Comments   
Comment by georgez [ 03/Mar/05 ]

Should be a "FEATURE".





[JDIC-208] Recycle/Trash Bin Created: 03/Mar/05  Updated: 14/Jul/05

Status: Open
Project: jdic
Component/s: FileUtil
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: fabiocastilhomartins
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 208

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=5166&tstart=50



 Comments   
Comment by georgez [ 14/Jul/05 ]

This feature is covered in the FileUtil incubator project:
https://jdic.dev.java.net/incubator/fileutil/index.html

So, I reassign it to Fábio C. Martins, and change the "Subcomponent" field to
"FileUtil", which is for the FileUtil incubator project.





[JDIC-209] Desktop single sign-on support Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 209

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=3308&tstart=150






[JDIC-210] Browser panel inside an applet Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 210

 Description   

This feature was reported in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=3084&tstart=0






[JDIC-211] Desktop shortcuts Created: 03/Mar/05  Updated: 11/Mar/08

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 211

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=2672&tstart=200



 Comments   
Comment by coxcu [ 11/Mar/08 ]

The thread link is now dead.





[JDIC-212] Global HotKeys Created: 03/Mar/05  Updated: 11/Mar/08

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 212

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=2729&tstart=200



 Comments   
Comment by keithkml [ 28/Apr/05 ]

add self cc

Comment by coxcu [ 11/Mar/08 ]

The thread link is now dead.

Comment by coxcu [ 11/Mar/08 ]

From Glossitope/AB5K thread on this...

system wide keys on windows:
http://www.vbaccelerator.com/home/vb/code/libraries/Subclassing/Registered_Hotkeys/article.asp
http://www.codeproject.com/vb/net/mclhotkeynet.asp
http://www.codeproject.com/useritems/mclhotkey.asp?df=100&forumid=15455&exp=0&select=1267687
http://www.autohotkey.com/

find the runforest run program
http://www.zathras.de/angelweb/macapplications.htm





[JDIC-213] Application management integration (Add/Remove Programs) Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 213

 Description   

This feature was proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?forumID=52&threadID=2672&messageID=11535#11535






[JDIC-214] Single instance applications Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 214

 Description   

A feature to manage one instance for multiple application windows, like Mozilla.






[JDIC-215] Access to desktop mail/ address book/calendar accounts/ data Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 215

 Description   

Just like desktop package to access sytem browser/mailer/file viewer, this
feature access the user data.






[JDIC-216] Property dialog Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 216

 Description   

Property dialog is commonly used in various desktops.






[JDIC-218] Fil-explorer integration (icon preview, hierarchy integration) Created: 03/Mar/05  Updated: 03/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 218

 Description   

Provide better support for the FileExplorer component.






[JDIC-219] Mozilla plug-in container. Created: 03/Mar/05  Updated: 30/Mar/05

Status: Open
Project: jdic
Component/s: JDIC general
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 219

 Description   

A Mozilla plug-in container.



 Comments   
Comment by georgez [ 30/Mar/05 ]

Though the Browser component itself could display a filetype (such as pdf,
RealPlayer files) for which a browser plugin exists, Kyle Yuan
(kyle_yuan@dev.java.net) proposed to implement such a Mozilla plug-in container:

"...Browser itself is heavy, and has some compatibility issues. But mozilla's
plugin APIs are a) stable - there are not any changes of plugin APIs since
Netscape 4.x; b) simple - only 10~20 interfaces need to be implemented to
support plugin. And once we implemented the plugin interface in java, we can get
all mozilla plugin work - not only Acrobat, but also Flash, RealPlayer,
Quicktime etc. Java developers can even use Flash as one of their UI widget,
isn't that an exciting news?"





[JDIC-220] Desktop API Tuning for Mustang Created: 03/Mar/05  Updated: 25/Jan/11

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paul_huang Assignee: armin_chen
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on JDIC-240 Design tasks - Pluggable Service Prov... Open
Issuezilla Id: 220

 Description   

We are working to put the Desktop package into Mustang now. Here would be the
place to gather all the feedback for JDIC Desktop API to meet J2SE API
defination standard.



 Comments   
Comment by paul_huang [ 03/Mar/05 ]

Reassigned to Paul

Comment by paul_huang [ 03/Mar/05 ]

Feed back from Denis@AWT team:
1. Make Desktop class obtained through the static-factory method. Convert all
method to non-static.
Use case would be
----------------------------------------
Desktop desktop = Desktop.getDesktop();
desktop.open("c:
test.txt");
desktop.print("c:
test.txt");
------------------------------------------
Static methods limit the potential of extension in the future. With an instance
acquired from the factory, you can then manage appcontext-sensitive
configuration settintgs, enforce security, etc.

2. Add isSupported method for all atomic actioins - browse, edit, print, open,
mail.

3. Make Class Message an internal class for Desktop.

4. Change the return type of all get method of Class Message to be list instead
of an interator.

5. Specify that the implementation of mail() API converts the string to UTF8 to
work around the Unicode handling problem within native mail applications, or it
wouldn't pass the JCK.

6. Use File object list instead of String object list to speicfy the attachment
info.

7. Add more detail to the documentation of each method and class.

Comment by paul_huang [ 08/Mar/05 ]

1. Will follow Denis's suggestion to provide static-factory and make all other
methods non-static methods.

2. Provide a new API isSupported(String actionName, File file). The actionName
will specify the action type and the file will specify the file to be operated.
With this API introduced, the two APIs isEditable() and isPrintable() will be
removed.

3. Consider changing the API mail(Message message) to mail(URL). Developers
would be requried to specify the message as an Mailto URL. In this way, the
class Message will be removed.

4. Will not consider this if we are going to remove the Message class. Or we
will change all the return type as a List (copy of the internal reference) for
all the get methods of the Message class.

5. Will specify in Javadoc.

6. Use File object list instead of String object list to speicfy the attachment
info.

7. Will enrich the document.

Comment by paul_huang [ 21/Mar/05 ]

Add dependency to Issue 240.

Comment by pietschy [ 25/Apr/05 ]

> 3. Consider changing the API mail(Message message) to mail(URL). Developers
> would be requried to specify the message as an Mailto URL. In this way, the
> class Message will be removed.

Can attachments be added using the mailto url? If not (or if it's difficult) I
would prefer to retain the Message object (or find an elegant way to support
attachments).

Comment by georgez [ 27/Apr/05 ]

A branch "Issue_220" was created for the API and implementation revising for the
inclusion in Mustang. Check out the latest API spec and implementation code from
there.

Comment by keithkml [ 28/Apr/05 ]

I'm pretty sure "DesktopLauncher" or "ApplicationLauncher" would be a better
name. This package has no more to do with the desktop than the system tray or
file types API do.





[JDIC-228] Get the icon for a folder Created: 07/Mar/05  Updated: 27/Apr/05

Status: Open
Project: jdic
Component/s: IconService
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: rlopes Assignee: chas
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 228

 Description   

IconService should have a method for obtaining the folder icon



 Comments   
Comment by keithkml [ 27/Apr/05 ]

add self cc





[JDIC-229] get the default file icon Created: 07/Mar/05  Updated: 27/Apr/05

Status: Open
Project: jdic
Component/s: IconService
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: rlopes Assignee: chas
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 229

 Description   

IconService should have a method to get the default file icon (icon for a file
that has no extension or the extension is unknown).

Optionaly this could be returned in the getIcon method in case the Operative
System doesn't have that application type registered.



 Comments   
Comment by keithkml [ 27/Apr/05 ]

add self cc





[JDIC-230] Mac OS X support (Tray API) Created: 08/Mar/05  Updated: 01/Nov/06

Status: Open
Project: jdic
Component/s: MacOS
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: georgez Assignee: robross
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive mac_os_x.zip     Text File my-patch.diff     Text File my-patch.diff    
Issuezilla Id: 230

 Description   

This issue is created to track the task of making the JDIC Tray API (package
org.jdesktop.jdic.tray) available on Mac OS X. A thread on the forum is:
http://www.javadesktop.org/forums/thread.jspa?threadID=8965&tstart=0

Thanks to Tommi ! Merging MacJTray source into JDIC would provide a more
complete Tray API and a common community. I assigned this issue to him.



 Comments   
Comment by robross [ 23/Oct/06 ]

Created an attachment (id=259)
NEW sources to add to CVS for implementing TrayIcon API on Mac OS

Comment by robross [ 23/Oct/06 ]

Created an attachment (id=260)
patch file for changes to EXISTING sources for Mac TrayIcon API

Comment by robross [ 23/Oct/06 ]

I am submitting my code for initial checkin of the Mac OS implementation for the
TrayIcon API.

Rob Ross

Comment by michael_shan [ 30/Oct/06 ]

Reassign to Rob.

Comment by robross [ 01/Nov/06 ]

Created an attachment (id=262)
Fix for alpha in icons, and bug fixes to the ant build xml files





[JDIC-237] Deprecate willOpenWindow() method with willOpenWindow(URL url). Created: 20/Mar/05  Updated: 07/Mar/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: georgez Assignee: michael_shan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File patch_win32_ie.diff     Text File patch_win32_ie.diff     Text File patch_win32_mozilla.diff     Text File patch_win32_mozilla.diff    
Issuezilla Id: 237

 Description   

This issue was reported in below thread:
http://www.javadesktop.org/forums/thread.jspa?messageID=62343

The users want to access the url that is going to be opened in the new window.
The current willOpenWindow() spec is as:

protected boolean willOpenWindow()
Called before every new window is to be created. A subclass could override
this method to prevent new window from popping up.
Returns:
false will prevent the new window from popping up; otherwise true.

Which won't return the url to be loaded in the new window. It should do that
like willOpenURL(URL url) method.

So, deprecate willOpenWindow(), and replace it with willOpenWindow(URL url) is
the fix.



 Comments   
Comment by georgez [ 22/Mar/05 ]

I looked at this issue. It can be fixed for Mozilla (Windows/Unix), as we can
retrieve the URL to be opened in the new window before actually opening the new
window (CBrowserView::CreateNewBrowserFrame).

But got a problem with IE on Windows. NewWindow2 event currently used to block
or allow the creation of a new window doesn't return the URL to be displayed in
the new window:
http://msdn.microsoft.com/workshop/browser/webbrowser/reference/events/newwindow2.asp

Though the obsolete NewWindow event is said to be able to return the URL to be
displayed, I didn't find the correct way.

With event NewWindow3, the URL to be opened in the new window is returned:
http://msdn.microsoft.com/workshop/browser/webbrowser/reference/events/newwindow3.asp

But "NewWindow3 is available only in Microsoft Windows XP Service Pack 2 (SP2)
or later.", which is unacceptable.

So, this issue won't be fixed, unless there is a viable solution.

Comment by georgez [ 22/Mar/05 ]

Will be done.

Comment by georgez [ 13/Jun/05 ]

A patch for implementing this feature for Mozilla on Windows is attached, which
only contains the native code. The patch for the Java code is simple.

Comment by georgez [ 13/Jun/05 ]

Created an attachment (id=193)
Impl willOpenWindow(URL url) API for Mozilla on Windows.

Comment by michael_shan [ 12/Feb/06 ]

Assign to DongDongYang.

Comment by michael_shan [ 13/Feb/06 ]

Assign to Michael.

Comment by michael_shan [ 21/Feb/06 ]

Created an attachment (id=232)
Fix for IE.

Comment by michael_shan [ 21/Feb/06 ]

Using string param instead of URL.

Comment by michael_shan [ 22/Feb/06 ]

To keep consistent with willOpenURL(), change it back to URL as parameter.

Comment by michael_shan [ 22/Feb/06 ]

Created an attachment (id=233)
Fix for IE (URL as parameter)

Comment by michael_shan [ 22/Feb/06 ]

Created an attachment (id=234)
Fix for mozilla under win.

Comment by michael_shan [ 22/Feb/06 ]

For Mozilla under Unix, it doesn't support open URI in a new window and donesn't
support right mouse click either.

We have to provide thoese features before realizing this issuse, but they seem
need some more works.So it's better to open another feature to realize them.
Issue237 will depend on the to be opened issue.

Comment by michael_shan [ 22/Feb/06 ]
      • Issue 345 has been marked as a duplicate of this issue. ***
Comment by michael_shan [ 07/Mar/06 ]
      • Issue 365 has been marked as a duplicate of this issue. ***




[JDIC-242] Can't get the image from the WebBrowser Graphics Created: 23/Mar/05  Updated: 09/Nov/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.8.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rlopes Assignee: michael_shan
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File HTMLThumbnail.java    
Issuezilla Id: 242

 Description   

I have tried unsucessfuly to get the image from the WebBrowser component in the
way i do it for other swing components. All i get is an empty image, so makes me
wondering is there is some problem with the paint method or any other thing in
the WebBrowser that cause this.

I submit as attachment to show the problem, and also to show that the same
method works on other components (like JEditorPane) but doesn't work on WebBrowser.



 Comments   
Comment by rlopes [ 23/Mar/05 ]

Created an attachment (id=175)
Demostration code

Comment by dongdongyang [ 19/Jun/06 ]

Being of changing members, reassign the task.

Comment by michael_shan [ 09/Nov/06 ]
      • Issue 336 has been marked as a duplicate of this issue. ***




[JDIC-246] Prevent Drag and Drop Created: 29/Mar/05  Updated: 07/Feb/06

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dargham Assignee: michael_shan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 246

 Description   

Would it be possible to prevent dragging and dropping links to the WebBrowser
from the windows desktop?

Thanks



 Comments   
Comment by michael_shan [ 07/Feb/06 ]

Assign to Michael.





[JDIC-251] org.jdesktop.jdic.tray.TrayIcon has no way of setting the font Created: 11/Apr/05  Updated: 12/Apr/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: 0.9
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: sgregory Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 251

 Description   

org.jdesktop.jdic.tray.TrayIcon has no method to set the font used. A project that I work on suports
many languages (including Japanese) and we have to be able to set the font on our components to
make sure that the required characters are available.



 Comments   
Comment by armin_chen [ 11/Apr/05 ]

On Windows, we can not set which font to be used by TrayIcon's Tooltip and
Balloon Message. It always use system default font. Currently, JDIC TrayIcon use
system default ecnoding to encode the tooltip and balloon message. So, there
should not be any problem of using wide character.

Comment by sgregory [ 12/Apr/05 ]

Is there a technical reason that the font for the tooltip cannot be changed? Japanese is definately not
showing up for me. I could email you a screenshot if that would help.





[JDIC-252]  shell extension Created: 12/Apr/05  Updated: 12/Apr/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.filetypes)
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pcwheels Assignee: paul_huang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 252

 Description   

Would it be possible to extend the current functionality of the JDIC.filetypes
package to include cross-platform shell extension? The aim of the extension
would be to add entries to the context-menu for specific/all filetypes or folders.
For example, on Windows this would be a register entry under:
HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers






[JDIC-257] Setting the Process Priority Created: 25/Apr/05  Updated: 25/Apr/05

Status: Open
Project: jdic
Component/s: JDIC API general
Affects Version/s: 0.9
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 257

 Description   

This feature request was reported in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=11113&tstart=0






[JDIC-260] JDIC Browser with html editing added. Created: 26/Apr/05  Updated: 26/Apr/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.browser)
Affects Version/s: 0.9
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: georgez Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 260

 Description   

This is actually a feature request, though it's an additiontion to to JDIC
Browser, proposed in below thread:
http://www.javadesktop.org/forums/thread.jspa?threadID=11190&tstart=0






[JDIC-261] Add ability to browse in new window to Desktop.browse() Created: 27/Apr/05  Updated: 28/Apr/05

Status: Open
Project: jdic
Component/s: JDIC API (package org.jdesktop.jdic.desktop)
Affects Version/s: 0.9
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: irivera Assignee: georgez
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 261

 Description   

The current behavior for the method Desktop.browse(URL url) is to recycle a
previously opened browser window, if it's available. I'd find useful a second
method: Desktop.browse(URL url, boolean openInNewWindow) to be able to specify
that the navigation should happen in a new window.

Thank you in advance for your attention.

Iván Rivera



 Comments   
Comment by georgez [ 27/Apr/05 ]

Thia feature was planned and partly implemented in the JDIC code, but not
exposed publicly:
https://jdic.dev.java.net/source/browse/jdic/src/jdic/src/share/classes/org/jdesktop/jdic/desktop/Desktop.java?rev=1.1.1.1&view=markup
...
private static void browse(URL url, String target) throws DesktopException {}
...

The main reason is: this API should work with any available browser, but there
is no common way to do this for all the browsers. For example, there is no such
option "-newwindow" for all the browsers. So, we just provide browser(URL)
method to depend on the browser itself to reuse an existing window or open a new
window.

As we are integrating the desktop package into Mustang, the revised API spec
removed this API:
https://jdic.dev.java.net/source/browse/jdic/src/jdic/src/share/classes/org/jdesktop/jdic/desktop/Desktop.java?rev=1.1.1.1.10.5&view=markup

Does it make sense? Thanks !

https://jdic.dev.java.net/source/browse/jdic/src/jdic/src/share/classes/org/jdesktop/jdic/desktop/Desktop.java?rev=1.1.1.1.10.5&view=markup

Comment by irivera [ 28/Apr/05 ]

Thank you for your prompt answer.

Our current browser integration facility spawns a "rundll32
url.dll,FileProtocolHandler" process using a Runtime.exec(), which is of course
Windows dependent, but is able to launch any browser currently registered as
default in the desktop. However, all browsers we integrate (IExplorer and
Firefox) recycle the most recently used window (or tab, in the case of Firefox).
Our users have filed an issue against that behavior, feeling that a new window
should be used everytime a browser call is started from one of our Swing-based
clients. Their rationale is sound: our clients act as integration hubs for
various web-based applications from other sources, and they don't want to
arbitrarily lose one of them when invoking another one.

Your method proposal browse(URL url, String target) is better than mine; I can
foresee two alternatives for its successful implementation:

1) If you are able to identify the default browser, and there is a well-known
way to use the target argument in that browser, then proceed (perhaps by using a
Strategy pattern); otherwise throw an UnsupportedOperationException.

2) Expose the method as is, but make sure to document clearly that the target
argument is a hint, and that it's up to the browser to actually honor it. Native
desktop integration is hairy business, and I'm sure developers would understand...

Once more, thank you for your attention.

Iván Rivera





[JDIC-263] IconService will not load icon from some exe files Created: 27/Apr/05  Updated: 27/Apr/05

Status: Open
Project: jdic
Component/s: IconService
Affects Version/s: IconService0.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: keithkml Assignee: chas