[dolphin] [Bug 464460] Support environmental variables in Places

[Felix Ernst]

https://bugs.kde.org/show_bug.cgi?id=464460

--- Comment #3 from Felix Ernst <felixernst at kde.org> ---
(In reply to Michael Mikowski from comment #2)
> Felix, I generally agree with your sentiment.  However, I do think there is
> some value here for your consideration.
> 
> Honestly, just support for a small subset like HOME and USER might be a good
> first step. I did this with qwe bash bookmarks app
> (https://github.com/olafurw/qwe), and now users can share a config file,
> which is very handy.
[…]
> 2. Use Cases: 1. Users create config files that can be shared without
> modifications;

Excuse me if I have missed a detail here: Config files for what?

> 2. Developers can rely on static configs that do not need to
> be rewritten for every user;
> 3. Apps can abstract a greater number of
> default settings through a central default config expressed in
> $XDG_CONFIG_DIRS.

When I talk about use cases I generally have use cases of end-users in mind. I
don't think we should add code that might or might not simplify the work of
developers of other software. Otherwise we add complexity that should live with
the software that needs that complexity.
I am sorry if I am being a bit dense here but I don't understand why software
might rely on the links in the places panel in the first place. There is
already a standard why to retrieve typical locations in Qt (
https://doc.qt.io/qt-6/qstandardpaths.html#StandardLocation-enum ). Why would
any software read out the places panel links of users to capture an intent?
That seems extremely non-portable. I might be totally missing your point
though.

> 3. Bookmarks can be changed via scripts :  yes, but this hard-codes configs
> and does not capture intent like environment variable expansion can.
> Rewriting is pretty much a hack to get around that intent isn't captured.

I think it is fine. Again, I don't think most applications really need to mess
with the places panel links in the first place. I believe you might have a
different perspective than most users here because you are trying to improve
the user experience of your application. But even then, I am not quite sure if
this would enable software like yours to do new things or if this would merely
simplify the implementation.

> 4. Cost vs. benefit: I defer to you on that. I did want to illustrate,
> however, that I do certainly see some benefit. Using the escape character
> might mitigate much of the risk. Admittedly, environment variable are often
> not set in various contexts, so perhaps just a very limited subset as
> discussed above would be a good start.

Well, for one thing, the code of the places panel is also shared with
Gwenview's side bar and KDE's default file picker, so whatever functionality we
add here affects a lot of other applications. This means that any more expert
feature we add increases complexity even for applications that want to be
extremely simple. On the other hand if we don't explain this feature to users
somewhere, it generally might as well not exist because users will not know
about it. So it is a bit of a damned if we explain and damned if we don't
situation IMO. To me it seems like it would make more sense not to increase
complexity of any of that unless there is a problem users can't solve
otherwise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.