RFC: Remove unimplemented application menus?

James McKenzie jjmckenzie51 at gmail.com
Mon Mar 28 21:17:06 CDT 2011

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 

James McKenzie

More information about the wine-devel mailing list