Re: mc.ext is problematic by nature

On Sun, Apr 8, 2012 at 10:00 PM, Holger Herrlich
<holgerherrlich05 arcor de> wrote:
> On 04/08/2012 09:00 PM, László Monda wrote:
>> Regarding your example, the user can (and should) change this
>> association on the system level.  Also, this example is rather an
>> exception than the norm as system level assiociations are usually
>> fairly relevant.
> I do not know a system level for linux so far. Here are gnome-system
> levels that compete with kde etc. and of cause with minority level
> window managers.

The relevant standards are and

I'm not sure about every window manager but Gnome 3 adheres to this
standard and probably some major ones, too.  Lots of
standards such as these define many basic architectural building
blocks of modern Linux desktops.

> It's not an exception: I'm trying to enable [ALT]+drag of windows via
> config file with no success, stick keys are set by random and so on.
> I start X via xinit just because of all that side effects called system
> defaults. Here are so much of that! At so different locations!

I can't see what dragging windows has to do with filename associations.

> What's so wrong in having an ascii file in /etc (a system default dir)
> doing exactly what I want -- in a way (shell script) what I know what
> I'm doing.
> What's so right in computer science to allways be at the current fashion
> -- without knowing that you are doing?

At this point it's not hard to tell that your opposition to the idea
of mc.ext going away is strong.  Instead of hurting mc.ext in any ways
I'd like to emphasize the advantages of respecting system defaults
(and making them overridable through mc.ext).

> Isn't it an inovation to not going the Windows way? Does on my system
> really anyone else than I have to deceide what is "best". Does he know
> what I plan to do? Does that mean, that every time say gnome changes, mc
> have to fixed?

Please realize that if you defined all the associations that you care
about in mc.ext you couldn't care less with system level defaults
because those would be overridden by mc.ext.

>> I agree however that eliminating mc.ext is probably overkill, but
>> system level defaults should be taken into consideration and mc.ext
>> could provide a way to override those.
> mc.ext makes mc independent, custom-build-able, predictable, easy,
> re-usable, maybe maintainable. The reason I use mc is that it's very
> reliable. The last 15 years I used mc on QNX, BeOS and various Linuxes.
> With time of experince it runs better. Natural human behavior. What
> better will the quick and dirty system default make.

You made your point clear, mc.ext has its advantages.  So as taking
system level defaults, I think.

László Monda <>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]