[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ews.eclipse.technology.desk] Re: Some ideas...

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