[ews.eclipse.technology.desk] Re: Some ideas...

[Robert Enyedi <renyedi@xxxxxxxxx>]

I'm not a member of the Eclipse desktop project. I'm around just out of 
curiosity and I'm trying to help because I felt the need for such a 
project for a long time (let's say since the beta releases of JDK 1.2).

I understand your problem and I agree with you that such a feature is 
useful. It's just that a better OLE/COM support should be the job of a 
project aimed at interfacing with the Win32 platform. Not the job of 
this project and not even of the SWT project.

This project should generalize the desktop concepts found across many 
operating systems and not to tie itself to a specific platform.


Tommy wrote:
> I see, so you consider an Eclipse OLE/COM Object Viewer and better Java 
> OLE access as outside your project scope.
>
> I was just thinking about the basic infrastructure that everybody needs 
> when integrating Windows and Java. It would help speed up your 
> development effort, for the Windows platform at least (and other 
> developers can contribute easier).
>
> But maybe that should be the job of the SWT project to provide these 
> kind of tools...
>
> Robert Enyedi wrote:
>
> > I believe that the purpose of the desktop project should be on 
> > providing a uniform layer over common functionality found across the 
> > majority of the operating systems. File deletion by moving it into the 
> > Recycle Bin or Trash is such an example.
> >
> > But focusing on support for features found only on a single operating 
> > system would certainly break the WORA vision of the Java platform.
> >
> > I see the desktop project as a set of patches to the core Java classes 
> > that would deepen the integration with the operating systems and their 
> > desktops. This should have come directly from Sun a several years ago, 
> > but it didn't happen (see the feeble attempt from 
> > javax.swing.filechooser.FileSystemView class). Maybe this time 
> > something good will happen for Java on the desktop.
> >
> >
> > Tommy wrote:
> >
> > > Easier support for OLE and ActiveX integration. There is already some 
> > > integration in Eclipse but it´s still hard if you have never worked 
> > > with   OLE and ActiveX objects.
> > > For example, going via oleAutomation.getIDsOfNames(new String[] { 
> > > "whatever"} ); etc. just seems unnatural.
> > > So it would be great to have a more Java centric interaction with OLE 
> > > objects.
> > >
> > > Also some kind of OLE/COM Object Viewer that is integrated in Eclipse 
> > > would be cool.
> > >
> > > - Thomas
> > >
> > > news.eclipse.org wrote:
> > >
> > > > One thing I miss from the C++ world is support for windows file 
> > > > change notification and perhaps some of the efficiency / 
> > > > functionality of find file apis vs. how things are now done in 
> > > > Java.  It should be possible to get all available meta info about a 
> > > > file or other entity using just _one_ api call (and crossing of the 
> > > > java / native boundary), rather than having to make separate calls 
> > > > to determine length, modification date, read-only status, etc.
> > > >
> > > > I don't know if full exposure of file system functionality would be 
> > > > worthwhile or not.  (Any way to do it without being to specific to 
> > > > O/S?) Windows supports multiple streams of data per file, though I 
> > > > don't know how much it's used.  Would this compare to the old mac 
> > > > notion of data and resource forks?  If so, perhaps a general 
> > > > exposure of multiple streams per "file" would be nice.
> > > >
> > > > Other ideas might be defrag stuff, good services/scheduling support.
> > > >
> > > > Joel
> > > >
> > > > "Robert Enyedi" <renyedi@xxxxxxxxx> wrote in message 
> > > > news:d0onpi$jfu$1@xxxxxxxxxxxxxxxxxx
> > > >
> > > > > Hi,
> > > > >
> > > > > Just like the founders of this project, I know that Java is lacking 
> > > > > a lot of desktop integration features. For a while I've been 
> > > > > developing an open-source file manager in Java and these are the 
> > > > > main areas where I have to use native bindings:
> > > > >
> > > > > - partition information - there's no way of obtaining basic 
> > > > > partition information in Java: type, size, free space. The Eclipse 
> > > > > Update Manager codebase contains such code 
> > > > > (http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.update.core.win32/src/) 
> > > > > and I use something similar to it. It's not that hard, but it's 
> > > > > still native code and should be available as an API. For example, 
> > > > > any container/application server needs such an API for doing a safe 
> > > > > deploy.
> > > > >
> > > > > - file permissions/attributes - all you can do in Java is set a 
> > > > > file's read-only attribute. There's no way of resetting it. And you 
> > > > > can check if it's hidden, but no API for changes is provided. There 
> > > > > should be a specialized API for dealing with a unified file 
> > > > > permission model that covers mainly the permission models of win32 
> > > > > and Unix.
> > > > >
> > > > > - shell context menu - while the first two areas are of general 
> > > > > interest, the handling of the system shell's context menu is 
> > > > > somewhat of limited use. I need it in my file manager 
> > > > > (http://sourceforge.net/project/screenshots.php?group_id=35271&ssid=8601) 
> > > > > and I also have some code already implemented (only for win32 and 
> > > > > it works just partially): 
> > > > > http://cvs.sourceforge.net/viewcvs.py/jcommander/plugins/org.jcommander.systemshell.win32/src/. 
> > > > > However, an API for the system shell and the contextual menu in 
> > > > > particular might be useful also for other kind of applications that 
> > > > > require tight desktop integration.
> > > > >
> > > > > While trying to address these needs for my application, I directly 
> > > > > experienced the two obvious difficulties in developing native 
> > > > > bindings:
> > > > > - design of a unified and platform independent API - requires 
> > > > > knowledge of all the major platforms
> > > > > - implementation of the APIs for each target platform - thorough 
> > > > > knowledge of the specific APIs is needed and this is the hardest part
> > > > >
> > > > > What I've found out as missing in Java for desktop integration is 
> > > > > just a small part of what other requirements might be.
> > > > >
> > > > > Do you have a plan about the areas of desktop integration that the 
> > > > > Eclipse Desktop project intends to address?
> > > > >
> > > > > Regards,
> > > > > Robert