RFC: Remove unimplemented application menus?

[James McKenzie]

On 3/28/11 7:19 PM, Austin English wrote:
> On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzie51 at gmail.com>  wrote:
>> On 3/28/11 7:15 PM, Austin English wrote:
>>> 2011/3/29 James McKenzie<jjmckenzie51 at gmail.com>:
>>>> On 3/28/11 9:28 AM, André Hentschel wrote:
>>>>> Am 28.03.2011 17:27, schrieb James McKenzie:
>>>>>> 2011/3/27 André Hentschel<nerv at dawncrow.de>:
>>>>>>> Am 27.03.2011 13:50, schrieb Francois Gouget:
>>>>>>>> Some Wine programs, winefile in particular, have a lot of
>>>>>>>> unimplemented
>>>>>>>> menus. That is you can see the menu entry but clicking on it only
>>>>>>>> gives
>>>>>>>> you a 'Not yet implemented' error dialog (or does nothing in the case
>>>>>>>> of iexplore). For instance just for the first two winefile menus none
>>>>>>>> of the following are implemented:
>>>>>>>>
>>>>>>>>    File ->      Print...
>>>>>>>>    File ->      Associate...
>>>>>>>>    File ->      Search...
>>>>>>>>    File ->      Select Files...
>>>>>>>>    Disk ->      Share as...
>>>>>>>>    Disk ->      Remove Share...
>>>>>>>>    Disk ->      Select Drive...
>>>>>>>>
>>>>>>>>
>>>>>>>> I think such a situation is bad:
>>>>>>>>   * Having tons of unimplemented menus looks amateurish.
>>>>>>>>   * It's very confusing. You see tons of menus except over 50% of them
>>>>>>>>     don't work. So it makes the GUI more complex with no benefit.
>>>>>>>>   * I suspect most of these menus have been unimplemented for years
>>>>>>>>     so there is little hope of seeing them improve any time soon.
>>>>>>>>   * For a number of them it's questionable whether it makes sense to
>>>>>>>>     implement them in Wine at all as they correspond to tasks that
>>>>>>>>     better belong to the native system facilities (Share as for
>>>>>>>>     instance).
>>>>>>>>   * I doubt they serve any significant compatibility purpose.
>>>>>>>>   * In the mean time they generate more work for translators and
>>>>>>>>     translation reviewers.
>>>>>>>>   * It generates more work for anyone checking whether the GUI is
>>>>>>>>     consistent / follows human interface guidelines (wrt. ellipses for
>>>>>>>>     instance).
>>>>>>>>
>>>>>>>> So I propose to simply remove unimplemented menus. When / if someone
>>>>>>>> ever decides to implement some of the corresponding functionality,
>>>>>>>> adding the corresponding code and GUI bits back should not be too
>>>>>>>> hard.
>>>>>>>>
>>>>>>>> Objections?
>>>>>>>>
>>>>>>> Good Idea, at least for the year old stub menus (like winefile).
>>>>>>> For recently added, with hope to see them implemented in the next time
>>>>>>> (maybe gsoc), we should wait some month (e.g. iexplore) IMO.
>>>>>>>
>>>>>> I agree.  This was proposed as a GOSC project by one of the people.
>>>>>> There is a thread on Wine Users about these menus being
>>>>>> 'unimplemented' and how they should be.  Would this be a good item for
>>>>>> a bug report for an Request for Enhancement?
>>>>> IMHO no, there is no point i think.
>>>>> PS: is this meant to be also sent to wine-devel?
>>>>>
>>>>>
>>>> Are these features the program should possess or not?  These tend to be
>>>> 'standard' menu items for most Windows programs and the underlying code
>>>> does
>>>> lie in Windows, not the individual programs and has since the Windows 3.x
>>>> days.
>>> Theoretically they should be there, yes, but it's not really worth the
>>> effort.
>>>
>> At least we could implement some sort of stub to popup a dialog to say the
>> function is not implemented in Wine?  Does Excel have a Open... and Save...
>> menu item (these are also implemented in Windows or is it the program?)
> Yes, Excel has the dialog, along with most other programs. Winefile
> itself does not have it implemented. If you want to take the time to
> stub out the dialogs, be my guest, but few people use winefile as is,
> and fewer use the full dialogs (I bet most that notice it is broken
> are just curious if it does work). The effort spent stubbing it would
> be better spent fixing bugs that break actual applications.
>
Austin:

However, this just might be something that AJ will approve.

James McKenzie