RFC: Remove unimplemented application menus?

James McKenzie jjmckenzie51 at gmail.com
Mon Mar 28 21:35:24 CDT 2011

On 3/28/11 7:23 PM, Austin English wrote:
> On Tue, Mar 29, 2011 at 03:20, James McKenzie<jjmckenzie51 at gmail.com>  wrote:
>> 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.
> Sure, that's his call, but I don't see the point in discussing it
> without someone volunteering to write the code.
> It's a moot point, I don't use winefile, and I'd rather see it cleaned
> up than have tons of stubs that make it look incomplete. However, I'm
> not going to take the time to fix it, and am happy to see Francois do
> so. Either way is fine with me, and it's not my decision.
> That's all I've got to say here, back to bugzilla for me.
I agree with this statement.  Cleaning up poorly written code is always 
a noble task.

James McKenzie

More information about the wine-devel mailing list