Re: mc.ext is problematic by nature

[László Monda]

On Sun, Apr 22, 2012 at 3:55 PM, Holger Herrlich
 wrote:
>
> Your last change to convince me by argument. Exspecially, I miss
> advantages you clained.

Given the lack of positive reception at this point I couldn't care
less about convincing anybody.  I still want to express my thoughts
cleanly, though.

> For don't-care-systems simply use the appropriated applications.
>
> Please note, that to override the native way to define associations via
> mc.ext, a config-ascii file -- not something hardcoded, _is_ changing
> mc.ext behavior. That also claims your thread title: "mc.ext is
> problematic by nature".

I didn't mean hardcoded, it's not the right word indeed.  What I meant
is that given the cross-platform nature of MC, chances are mc.ext
won't contain the right associations out of the box right after
installation.  It has to be edited which could be avoided on Linux
desktops (and maybe on some other platforms, too) in most cases by
using the feature that I am suggesting.

-- 
László Monda <http://monda.hu>
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[Hartmut Figge]

László Monda:
>2012/4/8 Szabó Gergely :

>> What would you do on a text-only Debian Squeeze server?
>
>I'd check whether the shared-mime-info package (which implements the
>above standards) is installed and not try to read system level
>defaults if it's not.

On my Gentoo shared-mime-info is installed because of some dependencies,
but there is no desktop at all. Only icewm. There are no system level
defaults. ;)

Hartmut
-- 
Usenet-ABC-Wiki http://www.usenet-abc.de/wiki/
Von Usern fuer User  :-)



___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[László Monda]

First of all, sorry for the very late reply.

On Tue, Apr 10, 2012 at 9:24 AM, Holger Herrlich
 wrote:
>
> On 04/09/2012 12:48 AM, László Monda wrote:
>> I'd like to emphasize the advantages of respecting system defaults
>> (and making them overridable through mc.ext).
>
>> You made your point clear, mc.ext has its advantages.  So as taking
>> system level defaults, I think.
>
> What are that advantages?

The advantages are respecting system-level defaults and behaving
consistently.  (And please let's not go again into whether the
freedesktop standards constitute as system level standards because
it's the best that we have on Linux desktops and it's fairly widely
available.)

It has been emphasized in this thread that MC is a cross-platform
application that can run on Linux desktops, Linux servers, OpenWrt,
Android, etc.  If so, then it doesn't make a damn sense to provide a
single hardcoded association file (mc.ext) for all these platforms.

The freedesktop standards pertain to Linux desktops, Android surely
has something else and some systems don't have anything.

> What do you want to change in the file mc.ext? What features?

I don't want anything in mc.ext to be changed.  I'd rather want a
checkbox option under Options -> Configuration called something like
"override mc.ext associations with native ones" which would override
the mc.ext open actions with the associations that are defined on the
system level.

-- 
László Monda 
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[László Monda]

On Mon, Apr 9, 2012 at 7:45 AM, Andrew Savchenko  wrote:
> Hello,
>
> On Mon, 9 Apr 2012 02:00:14 +0200 László Monda wrote:
>> As I said a bit earlier in a related discussion the relevant standards are
>> http://www.freedesktop.org/wiki/Specifications/mime-actions-spec and
>> http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
>> which are implemented by Gnome 3 and which are supposed to be
>> implemented by major desktops.
>
> These are desktop conventions. Have you ever considered that mc is
> not used only on desktops? It runs on servers, routers, phones and at
> very specific environments.

Yes, I did because I use mc on dozens of servers and on two OpenWrt
routers on a regular basis.  I suggested not taking system level
associations if the relevant directories are not present on a system.

> Furthermore freedesktop specs are not mandatory. Gnome and KDE may
> follow them, but others may not; and many people doubt if they are
> sane. I remember a hell with just configuration files path changes in
> mc according to XDG. Thank's god this is now optional and one can
> disable this crap.

I didn't say that the current standards are perfect but these are the
best that we have for now.  Currently basic filename associations for
Office file formats and PDF don't work out of the box from mc on a
modern Linux desktop and let's not even speak about dozens of others.

mc could take the list of associations that are based on the
*currently installed* applications on a system and use those out of
the box.  I think it'd be a huge advantage by itself.

> Global MIME specs are faulty by design which doesn't consider that
> different applications (or even the same application) may have need
> in different application processors for a current file type.

Although I doubt that it's a showstopper please elaborate on that.

-- 
László Monda 
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[László Monda]

2012/4/8 Szabó Gergely :
> On Sun, Apr 08, 2012 at 09:00:40PM +0200, László Monda wrote:
>> 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.
>>
>> László Monda 
>
> Hello,
>
> I think the problem is that Unices don't have the concept of
> system level defaults. Gnome and KDE do, but they are not the system.

As I said a bit earlier in a related discussion the relevant standards are
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec and
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec
which are implemented by Gnome 3 and which are supposed to be
implemented by major desktops.

> What would you do on a text-only Debian Squeeze server?

I'd check whether the shared-mime-info package (which implements the
above standards) is installed and not try to read system level
defaults if it's not.

> Or an Android phone? Or an OpenWRT router?

Although these are rather exotic environments in these cases I'd check
whether the relevant directories are available on the system and not
try to read those system level defaults if they're not there.

> Even if the computer had Gnome, what would you do if you were
> connected to the machine through a text-only ssh-session?

Given that the above standards define a directory hierarchy the
associations are easily readable from within an SSH session.

> So it's all up to the user or, in our case, mc.ext.

Yes, and respecting system level defaults also has definite advantages.

> Best regards
> Gergely Szabo
> ___
> mc-devel mailing list
> http://mail.gnome.org/mailman/listinfo/mc-devel



-- 
László Monda 
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[László Monda]

On Sun, Apr 8, 2012 at 10:00 PM, Holger Herrlich
 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
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec and
http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec

I'm not sure about every window manager but Gnome 3 adheres to this
standard and probably some major ones, too.  Lots of freedesktop.org
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 
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[Szabó Gergely]

On Sun, Apr 08, 2012 at 09:00:40PM +0200, László Monda wrote:
> 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.
> 
> László Monda 

Hello,

I think the problem is that Unices don't have the concept of
system level defaults. Gnome and KDE do, but they are not the system.
What would you do on a text-only Debian Squeeze server? Or an Android
phone? Or an OpenWRT router?
Even if the computer had Gnome, what would you do if you were
connected to the machine through a text-only ssh-session?

So it's all up to the user or, in our case, mc.ext.

Best regards
Gergely Szabo
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[László Monda]

On Sun, Apr 8, 2012 at 8:33 PM, Holger Herrlich
 wrote:
> On 04/07/2012 12:04 AM, László Monda wrote:
>> Hi List,
>>
>> Upon reinstalling Linux I had to face mc.ext having lots of
>> associations that refer to outdated applications.  This is a specific
>> case but there's a general problem.
>>
>> The first problem is that MC is supposed to be a cross-platform file
>> manager and as such it's not possible to cherry-pick applications that
>> are the best on every platform.  The second problem is that these
>> applications are in flux and the most popular ones will change by
>> time.
>>
>> There are lots of tickets requesting mc.ext changes because of the
>> above.  On the long run this is a fight against windmills.
>>
>> Has anybody considered using platform-specific native registries of
>> file associations instead of using mc.ext?
>>
>> (Maybe mc.ext shouldn't be deprecated but platform-specific native
>> registries should be the default and those could be overridden in
>> mc.ext.)
>
> Please note that this solution is applied in firefox such that !wine!
> notepad is launched for text files in linux -- no way to disable the
> feature.

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 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.

-- 
László Monda 
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: mc.ext is problematic by nature

[Holger Herrlich]

On 04/07/2012 12:04 AM, László Monda wrote:
> Hi List,
> 
> Upon reinstalling Linux I had to face mc.ext having lots of
> associations that refer to outdated applications.  This is a specific
> case but there's a general problem.
> 
> The first problem is that MC is supposed to be a cross-platform file
> manager and as such it's not possible to cherry-pick applications that
> are the best on every platform.  The second problem is that these
> applications are in flux and the most popular ones will change by
> time.
> 
> There are lots of tickets requesting mc.ext changes because of the
> above.  On the long run this is a fight against windmills.
> 
> Has anybody considered using platform-specific native registries of
> file associations instead of using mc.ext?
> 
> (Maybe mc.ext shouldn't be deprecated but platform-specific native
> registries should be the default and those could be overridden in
> mc.ext.)

Please note that this solution is applied in firefox such that !wine!
notepad is launched for text files in linux -- no way to disable the
feature.

Regards Holger
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel

mc.ext is problematic by nature

[László Monda]

Hi List,

Upon reinstalling Linux I had to face mc.ext having lots of
associations that refer to outdated applications.  This is a specific
case but there's a general problem.

The first problem is that MC is supposed to be a cross-platform file
manager and as such it's not possible to cherry-pick applications that
are the best on every platform.  The second problem is that these
applications are in flux and the most popular ones will change by
time.

There are lots of tickets requesting mc.ext changes because of the
above.  On the long run this is a fight against windmills.

Has anybody considered using platform-specific native registries of
file associations instead of using mc.ext?

(Maybe mc.ext shouldn't be deprecated but platform-specific native
registries should be the default and those could be overridden in
mc.ext.)

-- 
László Monda 
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel