Hi! On Wed, Feb 17, 2021 at 11:52 PM Bastien Nocera <had...@hadess.net> wrote:
> On Wed, 2021-02-17 at 22:07 +0100, Jehan Pagès wrote: > > <snip> > > There is also something which I am not fond of with the order > > depending on a shared database: we must agree on an order which might > > not be fair. Say 2 applications are on the exact same action fields, > > i.e. they both work on the same file formats (for instance JPEG, PNG > > for image viewers). If the defaults depend on this shared database, > > then the same one will consistently be the default image viewer > > shadowing (if installed) all the others. Be it based on character > > order (then you'd want to just name your app "aaa") or just whatever > > the database maintainer prefer for oneself, it's not right. > > It's not a database, it's a default configuration for various desktops. > As mentioned in my previous email, it's also likely to be easily > changed in the "default applications" panel in GNOME, and equivalent > somewhere else. > > > On the other hand, when no order is specified centrally, but each > > software is able to tell its intent "I'm made to display JPEG, PNG…" > > without specifying priority relatively to other software, at least we > > can go with fairer algorithm (something not based on an arbitrary > > choice making a strict order). Be it "last installed" or "keeping > > stability to whatever was here first" (then it will likely be > > dependent on your desktop choice during install, and distrib > > maintainers, at least not the same on all distributions). > > The order for mime-types with no defaults has nothing to do with a > "shared database", it's implementation specific, as it's not codified > in the mime specs. I know. Your quote of mine was me discussing the idea of getting more logics into a shared database as proposed earlier by Thomas (clearly looking at the part of I quoted myself doesn't say much of it, it was in the flow of the discussion). But I'm aware it's not like this currently. I was only preemptively saying that I'm not fan of this proposed solution to the problem. > GLib probably behaves differently than Qt does, > which means that the file managers using either of those are likely to > behave differently. > > If you want to solve this problem, you'll probably need to figure out > whether their behaviour is intentional, and then change the specs to > clarify the intended behaviour. > How do we know this? Who will know this if not even you who maintain these files know this? I think we are all aware that with software going on for dozens of years, sometimes some of the reasons for things get lost in time. 🙂 Now even if it's intentional, I don't think that's such a good behavior anyway. So I'm not sure it matters too much to know if it is actually intentional or not. Which is why I proposed the change from my first email. So far, with all the discussions which went on, I still believe it is a good solution, mostly because it scales well. Developers just have to add a bit more of semantic associations in their desktop file. And then distributions/desktop can update their no-default algorithm to use this info if it is present. In particular, a software which set some native and intent MIME types explicitly says that it is likely not a proper default application for all the other MIME types it supports (e.g. GIMP is not a proper default for JPEG handling, neither is LibreOffice the best default for .txt files…). Oppositely it explicitly says it is a very good fit for whatever is its native formats, and that it's an appropriate fallback for same-intent formats if no applications set it as native. The nice thing is that it requires really not so much change from everyone and it looks to me it would work quite well here. Jehan -- ZeMarmot open animation film http://film.zemarmot.net Liberapay: https://liberapay.com/ZeMarmot/ Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg