[haiku-commits] Re: r36500 - haiku/trunk/src/kits/app

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 27 Apr 2010 17:24:58 +0200

On 2010-04-27 at 17:07:07 [+0200], Stephan Assmus <superstippi@xxxxxx> wrote:
> Well, I was fond of my previous solution and considered it a solution to the
> general problem. It would have required to clean up applications declaring
> support for types which I myself consider needless/useless. You have
> expressed in the ticket that you don't like the idea to remove declarations
> of support for specific types from applications as long as they actually
> support them. So far I have not heard proposals of how to deal with this.

Then please re-read my comment [1], particularly the fourth bullet.

> I
> have expressed what I think about this at length in the ticket. What I have
> implemented now at least fixes the problem and other future problems like
> this. And it even has an idea behind it, which is that if a preferred
> application is set at all for sub-type, that it is not preferred by the user
> to open this type in the preferred handler of the super type.
> 
> So you can consider it a new status quo in which the user has less chance to
> have a file a) not open at all or b) in the wrong application, if a better
> application is installed and known to the system, but the MIME data base is
> misconfigured for some reason.

The same can be said for the solution I proposed (actually Axel as well), 
without special-casing the misconfiguration case.

[Well, in fact I agree with tangobravo that, if possible (as in Tracker's 
case), a misconfiguration should be brought to the user's attention. 
BRoster::FindApp() and Launch() API would need to be slightly extended (e.g. 
by a flags parameter allowing to specify that the method shall fail (with a 
descriptive error code) in case of misconfiguration or ambiguity instead of 
trying to be "intelligent").]

CU, Ingo

[1] http://dev.haiku-os.org/ticket/5821#comment:15

Other related posts: