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

[Robert Enyedi <renyedi@xxxxxxxxx>]

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