RFC: Remove unimplemented application menus?

Austin English austinenglish at gmail.com
Mon Mar 28 21:19:07 CDT 2011

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.


More information about the wine-devel mailing list