On 3/28/11 7:23 PM, Austin English wrote:
On Tue, Mar 29, 2011 at 03:20, James McKenzie<jjmckenzi...@gmail.com>  wrote:
On 3/28/11 7:19 PM, Austin English wrote:
On Tue, Mar 29, 2011 at 03:17, James McKenzie<jjmckenzi...@gmail.com>
  wrote:
On 3/28/11 7:15 PM, Austin English wrote:
2011/3/29 James McKenzie<jjmckenzi...@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<n...@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



Reply via email to