RFC: Remove unimplemented application menus?

[Austin English]

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.

-- 
-Austin