Bugzilla – Full Text Bug Listing
| Summary: | Enhance FileDialog to allow drop of files anywhere | ||
|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Hannes Erven <hannes> |
| Component: | RWT | Assignee: | Project Inbox <rap-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ivan, rsternberg |
| Version: | unspecified | ||
| Target Milestone: | 3.1 M1 | ||
| Hardware: | PC | ||
| OS: | All | ||
| See Also: | https://git.eclipse.org/r/51124 | ||
| Whiteboard: | |||
|
Description
Hannes Erven
New Gerrit change created: https://git.eclipse.org/r/51124 Continuing the discussion from Gerrit, I wonder if this could this be an acceptable solution?
FileDialog dialog = new FileDialog(parent, SWT.MULTI);
dialog.setData(RWT.CLIENT_FILES, clientFiles);
dialog.setData(RWT.AUTO_CLOSE, Boolean.TRUE);
dialog.open();
In case of SWT.SINGLE, only the first client file would be added. This would be easier to use in single-sourcing project. All you need is a fake RWT class.
Not sure if RWT is a good place for those constants anyway.
What if we agreed on fixed strings like "RWT_ClientFiles" instead?
(In reply to comment #2) > Continuing the discussion from Gerrit, I wonder if this could this be an > acceptable solution? > > FileDialog dialog = new FileDialog(parent, SWT.MULTI); > dialog.setData(RWT.CLIENT_FILES, clientFiles); > dialog.setData(RWT.AUTO_CLOSE, Boolean.TRUE); > dialog.open(); > > In case of SWT.SINGLE, only the first client file would be added. This would be > easier to use in single-sourcing project. All you need is a fake RWT class. > > Not sure if RWT is a good place for those constants anyway. > > What if we agreed on fixed strings like "RWT_ClientFiles" instead? Dialog is not a Widget. This, set/getData API is not available. Another option could be an utility class similar to existing DialogUtil like: FileDialogUtil.openWith( fileDialog, ClientFiles[], autoclose ); To me, a FileDialogUtil class seems to be a much better architecture than setting some magic constants - e.g. in terms of type safety, visibility (to the developer reading the javadoc/code suggestions), etc. Would you agree that the method in FileDialogUtil would create an instance of e.g. class org.eclipse.swt.widgets.internal.FileDialogRAP extends FileDialog? We still need a mechanism to override/implement methods from FileDialog and keep data in fields. The FileDialog is Adaptable. We could create an adapter (as we have elsewhere in RAP widgets) to access internal (private) fields/methods. There is no need for subclass FileDialogRAP. The FileDialogUtil will not create the dialog instance. I see it something like this: FileDialog dialog = new FileDialog( parentShell, style); FileDialogUtil.open(dialog, ClientFile[], autoclose); Ralf, what do you think? ... in FileDialogUtil.open: FileDialogAdapter adapter = dialog.getAdapter(FileDialogAdapter.class); adapter.setInitialClientFiles(ClientFile[]); adapter.setAutoClose(autoclose); dialog.open(); The suggested functions (adding ClientFiles and enabling auto-close) are not necessarily tied to opening the dialog. Just like other setters in the SWT FileDialog API (e.g. setOverwrite, setFileName), these methods would be called before open() to have an effect.
With a method like
FileDialogUtil.open(dialog, ClientFile[], autoclose);
I'm concerned that at some point we'd need to add another parameter, which would then end up in a mess. Ideally, I'd like to write:
FileDialog dialog = new FileDialog(parent, SWT.MULTI);
dialog.setClientFiles(clientFiles);
dialog.setAutoClose(true);
dialog.open();
If we don't want to extend the API, we could replace the setters with some kind of extension API:
FileDialogUtil.setClientFiles(dialog, clientFiles);
FileDialogUtil.setAutoClose(dialog, true);
or
RWTExtensions.on(dialog).setClientFiles(clientFiles);
RWTExtensions.on(dialog).setAutoClose(true);
The latter would have the advantage of a single entry point for all kinds of widgets. This would allow us to get rid of the "magic data constants":
RWTExtensions.on(table).setCustomItemHeight(69);
I like the idea, but if RWTExtensions class resides in RWT bundle, we need a dependency to FileDialog, which I want to avoid. ... maybe for FileDialog this is the way to go: FileDialogUtil.setClientFiles(dialog, clientFiles); FileDialogUtil.setAutoClose(dialog, true); and FileDialogUtil will be part of org.eclipse.rap.filedialog bundle, but in org.eclipse.rap.rwt.widgets package. (In reply to Ivan Furnadjiev from comment #10) > ... maybe for FileDialog this is the way to go: > FileDialogUtil.setClientFiles(dialog, clientFiles); > FileDialogUtil.setAutoClose(dialog, true); > and FileDialogUtil will be part of org.eclipse.rap.filedialog bundle, but in > org.eclipse.rap.rwt.widgets package. agreed. There's one catch: if FileDialogUtil resides in different package, then the setClientFiles() method [or field] of FileDialog would need to be public. So basically we'd still break strict SWT-API compliance... Or we use the Adaptable pattern, which I think is the way to go since that's the way it is done in DialogUtil . A new patchset will be available at Gerrit in a few moments. (In reply to Hannes Erven from comment #12) > There's one catch: if FileDialogUtil resides in different package, then the > setClientFiles() method [or field] of FileDialog would need to be public. That's why I proposed the adapter (see comment#7). Fixed with change https://git.eclipse.org/r/#/c/51124/ |