Bug 361001

Comment 1 Ivan Furnadjiev 2011-10-15 06:29:45 EDT

+1 to disable the OK button, but only in case of autoupload set to false. If autoupload is set to true the upload is performed regardless the OK button.

Comment 2 Beyhan Veliev 2011-10-15 08:32:21 EDT

(In reply to comment #1)
> +1 to disable the OK button, but only in case of autoupload set to false. If
> autoupload is set to true the upload is performed regardless the OK button.

Is it possible to control the update start? I think it will be better just to show an warning/error in the title area and not upload

Comment 3 Ralf Sternberg 2011-10-15 15:42:08 EDT

(In reply to comment #1)
> +1 to disable the OK button, but only in case of autoupload set to false. If
> autoupload is set to true the upload is performed regardless the OK button.

I think we should be consistent here. If we prevent uploading in the default mode, we should do so in auto-upload mode as well. Couldn't we just *not* upload the rejected files in auto-upload mode *and* disable the OK button?

Comment 4 Ivan Furnadjiev 2011-10-17 08:16:06 EDT

(In reply to comment #3)
> Couldn't we just *not* upload the rejected files in auto-upload mode *and* disable the OK button?
Yes... Sounds reasonable for me.

Comment 5 Austin Riddle 2011-10-17 10:22:03 EDT

(In reply to comment #0)
> I think that the FileDialog should not accept filtered file name extension.
> Currently, the background color of the file text field changes when user
> selects a not allowed file name extension but it is still possible to press the
> OK button. I think that in this case the default behavior should be to disable
> the OK button. This will make single sourcing of FileDialog easier.

I have some reservations about this because the filter in the RCP file dialog (at least in Windows) is a convenience to the user, not a blocking feature. You can still specify files that do not match the current filter.

Comment 6 Austin Riddle 2011-10-17 10:30:03 EDT

(In reply to comment #2)
> (In reply to comment #1)
> > +1 to disable the OK button, but only in case of autoupload set to false. If
> > autoupload is set to true the upload is performed regardless the OK button.
> 
> Is it possible to control the update start? I think it will be better just to
> show an warning/error in the title area and not upload

It is much better for notifications to be localized where a problem occurs. In a multi-upload case, a title bar change would convey less information than a change on the actual field to which the warning pertains. Is there something in particular that you don't care for about the way that the warning is visualized?  We could use a decorator instead.

Comment 7 Ralf Sternberg 2011-10-17 19:06:08 EDT

(In reply to comment #5)
> I have some reservations about this because the filter in the RCP file dialog
> (at least in Windows) is a convenience to the user, not a blocking feature. You
> can still specify files that do not match the current filter.

This is a strong point against this request. When in SWT the filter does not prevent selecting those files, then we should not alter the semantics in RAP. Thanks for pointing this out, I'll close this bug as INVALID. Beyhan, please reopen if you disagree and explain again why you think that this would make single sourcing easier.

(In reply to comment #6)
> We could use a decorator instead.

I'd also think that a decorator would look more common. Maybe Nick could come up with some UI tweaks? Anyone who likes to open a bug for it?

BTW, we may check whether there is some way (at least in some browsers) to pass this filter string to the file selection dialog. Again, this would be another bug.

Comment 8 Austin Riddle 2011-10-18 09:44:34 EDT

> BTW, we may check whether there is some way (at least in some browsers) to pass
> this filter string to the file selection dialog. Again, this would be another
> bug.

When we initially discussed the design I recall that Tim had mentioned a lack of support for the *accept* attribute in any browsers.

Here is one resource:
http://www.w3schools.com/tags/att_input_accept.asp

Comment 9 Ralf Sternberg 2011-10-18 09:56:14 EDT

"The accept attribute is not properly supported by any of the major browsers." - This seems to be true. Tried this attribute on latest Chromium and Firefox 7 and they do not support it. :(

Comment 10 Christian Kühl 2013-08-05 07:07:33 EDT

(In reply to comment #7)
> (In reply to comment #5)
> > I have some reservations about this because the filter in the RCP file dialog
> > (at least in Windows) is a convenience to the user, not a blocking feature. You
> > can still specify files that do not match the current filter.
> 
> This is a strong point against this request. When in SWT the filter does not
> prevent selecting those files, then we should not alter the semantics in
> RAP. Thanks for pointing this out, I'll close this bug as INVALID. Beyhan,
> please reopen if you disagree and explain again why you think that this
> would make single sourcing easier.

I would like to disagree with this and reopen this topic.
There is a clear difference for the users. In SWT it isn't possible to see files other than the expected ones. So almost every user will only select a valid file. In RWT the user can select every file and just a yellow background after the selection shows, that something isn't normal. 
The conclusion is, that as long as it isn't possible to pass the filter string to the FileDialog, disabling the "OK" button is the best approach to simulate the behaviour of SWT.