13 Mar
2025
13 Mar
'25
2:42 a.m.
Seems pretty much that double-clicking on files in konqueror almost
always default to embedded viewing rather than external tools. While
this behavior can be changed for individual mime types, can this
behavior be change globally?
Changing every mime type to open in an external tool is a lot of drudgery.
Thanks.
13 Mar
13 Mar
2:49 a.m.
On 3/12/25 9:42 PM, Darrell Anderson via tde-users wrote:
Seems pretty much that double-clicking on files in
konqueror almost
always default to embedded viewing rather than external tools. While
this behavior can be changed for individual mime types, can this
behavior be change globally?
Changing every mime type to open in an external tool is a lot of drudgery.
Thanks.
Not a solution but I found this bug report and short discussion:
https://bugs.trinitydesktop.org/show_bug.cgi?id=768
7:30 a.m.
On 2025/03/13 11:49 AM, Darrell Anderson via tde-users wrote:
On 3/12/25 9:42 PM, Darrell Anderson via tde-users
wrote:
Hi Darrell,
the file association allows to change the settings for all files using the "All"
group, just set it to external view.
That is what I did (or perhaps was the default) and it works like a charm.
Cheers
Michele
Seems pretty much that double-clicking on files
in konqueror almost always default to embedded viewing rather than
external tools. While this behavior can be changed for individual mime types, can this
behavior be change globally?
Changing every mime type to open in an external tool is a lot of drudgery.
Thanks.
Not a solution but I found this bug report and short discussion:
https://bugs.trinitydesktop.org/show_bug.cgi?id=768
4:03 p.m.
On 3/13/25 2:30 AM, Michele Calgaro via tde-users wrote:
On 2025/03/13 11:49 AM, Darrell Anderson via tde-users
wrote:
Kind of not fully intuitive/obvious to me. I have that set but upon
further inquiry there are sub levels in the 'all' category.
The top level shows 'Show file in separate viewer', but expanding the
top level 'all' widget shows an 'all' and 'allfiles' option that
need
the same configuration.
I'll see how that goes.
Thanks.
On 3/12/25 9:42 PM, Darrell Anderson via
tde-users wrote:
Hi Darrell,
the file association allows to change the settings for all files using
the "All" group, just set it to external view.
That is what I did (or perhaps was the default) and it works like a charm.
Cheers
Michele Seems pretty much that double-clicking on files
in konqueror almost
always default to embedded viewing rather than external tools. While
this behavior can be changed for individual mime types, can this
behavior be change globally?
Changing every mime type to open in an external tool is a lot of
drudgery.
Thanks.
Not a solution but I found this bug report and short discussion:
https://bugs.trinitydesktop.org/show_bug.cgi?id=768
15 Mar
15 Mar
4:58 a.m.
On 3/13/25 2:30 AM, Michele Calgaro via tde-users wrote:
On 2025/03/13 11:49 AM, Darrell Anderson via tde-users
wrote:
No charm here. Seems I have to set every #$%^*%# mime type to open in a
an external viewer. I wish I knew what I am doing wrong.
On 3/12/25 9:42 PM, Darrell Anderson via
tde-users wrote:
the file association allows to change the settings for all files using
the "All" group, just set it to external view.
That is what I did (or perhaps was the default) and it works like a charm. Seems pretty much that double-clicking on files
in konqueror almost
always default to embedded viewing rather than external tools. While
this behavior can be changed for individual mime types, can this
behavior be change globally?
Changing every mime type to open in an external tool is a lot of
drudgery.
Thanks.
Not a solution but I found this bug report and short discussion:
https://bugs.trinitydesktop.org/show_bug.cgi?id=768
17 Mar
17 Mar
4:59 a.m.
On 3/14/25 11:58 PM, Darrell Anderson via tde-users wrote:
On 3/13/25 2:30 AM, Michele Calgaro via tde-users
wrote:
Try, try again!
Digging further into this, looks like I raised this topic about 13 years
ago in this list.
Unless explicitly declared false, seems the default behavior is
AutoEmbed=true. This design decision probably goes back to the days when
many users caught the fever that Konqueror should become a swiss army
knife of file managers.
I tested a fresh profile. All but a few mimetypes launch embedded.
Browsing the /opt/trinity mimelnk files does find some files explicitly
declared false, such as KOffice mimetypes.
Modifying the all and allfiles mimetypes to launch externally has no
effect for me. Two respective desktop files are created in
$TDEHOME/share/mimelnk containing X-TDE-AutoEmbed=false, but to no
avail. Seems these two associations should override everything else but
that is not what I see.
Likewise with checking the default of each top group (application,
audio, fonts, etc.). The default for each individual mimetype seem to be
'Use settings for $parent group', but that seems to be ignored too.
Seems a user should be able to configure the top groups to use external
separate viewers and be done.
To override this default behavior, I'm guessing the solution is heavy
patching mimelnk desktop files when compiling the packages or creating a
large collection of mimelnk desktop files stored in a central $TDEDIRS
(plural, not TDEDIR single) directory. Looks like the $TDEDIRS approach
is how I tackled the problem back in the KDE 3 and early TDE days.
Individually modifying every single mimetype to launch externally
results in a gob of desktop files being created in
$TDEHOME/share/mimelnk and a hugely convoluted
$TDEHOME/share/config/profilerc file.
Perhaps I am doing something so fundamentally obtuse that nobody can see
the cause no matter how I describe the problem. I really would like to
resolve this default embedded behavior in some kind of simple and sane
manner. Perhaps I am just too old school expecting to view everything in
an external tool. :)
On 2025/03/13 11:49 AM, Darrell Anderson via
tde-users wrote:
No charm here. Seems I have to set every #$%^*%# mime type to open in a
an external viewer. I wish I knew what I am doing wrong. On 3/12/25 9:42 PM, Darrell Anderson via
tde-users wrote:
the file association allows to change the settings for all files using
the "All" group, just set it to external view.
That is what I did (or perhaps was the default) and it works like a
charm. Seems pretty much that double-clicking on files
in konqueror almost
always default to embedded viewing rather than external tools. While
this behavior can be changed for individual mime types, can this
behavior be change globally?
Changing every mime type to open in an external tool is a lot of
drudgery.
Thanks.
Not a solution but I found this bug report and short discussion:
https://bugs.trinitydesktop.org/show_bug.cgi?id=768
5:55 p.m.
I don't know how to solve your issue itself, but perhaps you could work around it
easily by opening a foreign file browser program such as Xfce's Thunar from within TDE
whenever you want to get a different default file opening behavior. That way you won't
have to work within Konquerer's design quirks.
I haven't tested that approach yet myself, but it seems like it may work, unless TDE
overrides the default file opening behavior of the foreign file explorer program.
There is also of course the option of opening files via `open` from a shell instead of
Konquerer, or opening the program you want to use first and then using it to browse to and
open the file you want (perhaps with the file path copied from Konquerer in advance to
find it faster).
Or, perhaps even easier, simply figure out the command names of the programs you want,
then select the file you want to open in Konquerer, then press Ctrl E to bring up the
prompt (which will already contain the file name, if you selected it prior to pressing
Ctrl E), and then simply prefix that relative file name with the command for the program
you want to run.
Oh, or perhaps even better, you could add a shell script to `/usr/local/bin/` which
examines the file it is given as an argument and then chooses from your own list of
manually constructed programs to run, so that you don't have to memorize the command
names of the programs you use, unlike you would in the above workaround. You'd just
use that custom shell command within the Ctrl E popup instead of a different command per
file type. That could be a great middle-ground solution.
As the most "extreme" solution: You could even program you own simple file
browser conceivably, which you could design to have use exactly the programs you want,
which could add some flexibility but could be a lot more work potentially. If you kept it
simple enough it may not be too much work though, and would be much more customizable in
principle.
Anyway, hope that helps and have a great day/night!
9:52 p.m.
On 3/17/25 12:55 PM, WraithGlade via tde-users wrote:
I don't know how to solve your issue itself, but
perhaps you could work around it easily by ....
Thanks for replying. :)
All clever ideas (I relish people who think outside the box!), but in
the end all are work-arounds for a problem that should not exist.
For me the frustrating part is I am trying diligently to return to TDE
full time. I have spent the past week whittling away at various bugs and
paper cuts, mostly successful. The doggone speed of TDE, especially
Konqueror as a file manager and how fast all apps launch, are second to
none and difficult to walk away from.
I don't expect TDE to have zero paper cuts, but I want to eliminate as
many as practical for my lifestyle and expectations. I can change my
expectations but only if necessary. This default embedded viewer design
drives me nuts and drove me nuts in the KDE 3 days too. Too old school I
suppose. I guess most people like embedded viewing or do not give a
rat's end or the problem would have received more attention.
None of the other DEs have this problem because none of the other
developers design their file manager as a Swiss army knife. I am not
complaining about the wonderful multi-faceted design of Konqueror.
Nobody wants to change that. I am only advocating that there should be a
simple and sane way to change the default design so double-clicking
opens the file in a separate external tool.
Michele's idea of changing the all/allfiles file association attributes
seems to make sense and would seem that all would be necessary. But
there is a deep and complex pecking order how this all functions. Of
which I have yet to find a clear description or flow chart.
For example, the default for PDF files is embedded viewing. This makes
some sense considering the web browser role Konqueror supports. This
default is found in the tdelibs sources
(tdelibs/mimetypes/application/pdf.desktop: X-TDE-AutoEmbed=true).
Walking through the file association dialog groups indicates the default
is to use a separate external viewer -- unless a child mimetype
overrides to use embedded viewing -- such has PDF files. Seems most if
not all archive mimetypes default to embedded viewing.
Most of the file association parent groups default to showing files in a
separate viewer. Most of the child mimetypes default to using the
settings of the parent group.
TDE does not seem to use the user's mimeapps.list file. That file is
supposed to be part of being XDG and free desktop compliant. I don't
think that shortcoming is a show stopper. Even if TDE used that file, I
suspect that would cause conflict on a system with KDE installed. The
complex method used in TDE mostly works fine, even if nobody seems to
have to fully explained the madness. I'm willing to work with anybody
who wants to investigate and post a nice wiki article.
I tried walking through the tdelibs and tdebase sources looking for
AutoEmbed instances. I don't fully grok C++, but I get the feeling the
final code decision is to use embedded viewing unless explicitly
configured otherwise.
I'm going to keep playing with this in a clean TDE profile. As
previously mentioned, once upon a time I used the $TDEDIRS (plural)
method to create a collection of global override files. I still have
those files (pack rat!). I am hoping I can find a pattern to simplify
using those files rather than individually create a desktop file for
every single mimetype.
Thanks for trying to help!
10:46 p.m.
On Monday 17 of March 2025 22:52:19 Darrell Anderson via tde-users wrote:
None of the other DEs have this problem because none
of the other
developers design their file manager as a Swiss army knife. I am not
complaining about the wonderful multi-faceted design of Konqueror.
Nobody wants to change that. I am only advocating that there should be a
simple and sane way to change the default design so double-clicking
opens the file in a separate external tool.
Hi Darrell,
to open PDF, I learned a simple trick: If I don't mind opening the file as
embedded, I will use the left button. If I want PDF open in a separate
KPDF application, I use the middle button that opens in a new window by
default. In this case, the new window is a separate KPDF, not Konqueror.
The same is applied also to other file types - for example pictures - left
button opens embedded, middle button opens separate Kuickshow window.
Cheers
Slávek
--
11:53 p.m.
On Mon, Mar 17, 2025 at 23:46 (+0100), Slávek Banko via tde-users wrote:
On Monday 17 of March 2025 22:52:19 Darrell Anderson
via tde-users wrote:
> None of the other DEs have this problem because none of the other
> developers design their file manager as a Swiss army knife. I am not
> complaining about the wonderful multi-faceted design of Konqueror.
> Nobody wants to change that. I am only advocating that there should be a
> simple and sane way to change the default design so double-clicking
> opens the file in a separate external tool.
Hi Darrell,
to open PDF, I learned a simple trick: If I don't
mind opening the file as
embedded, I will use the left button. If I want PDF open in a separate
KPDF application, I use the middle button that opens in a new window by
default. In this case, the new window is a separate KPDF, not Konqueror.
The same is applied also to other file types - for example pictures - left
button opens embedded, middle button opens separate Kuickshow window.
I just tried looking at a PDF in konquerer. On my system, the text is not
sub-pixel rendered (SPR) like it is in firefox (and probably chrome) or in
the ancient Adobe acroread program I still have on my system.
Anyone care to chime in and tell me whether their version of konquerer does
sub-pixel rendering?
(If you don't know what I am talking about with SPR, bring up a PDF
document, and then using a program like xmag to zoom in on some of the
text, and see if vertical strokes are have coloured edges.)
Thanks.
Jim
18 Mar
18 Mar
midnight
On 3/17/25 5:46 PM, Slávek Banko via tde-users wrote:
On Monday 17 of March 2025 22:52:19 Darrell Anderson
via tde-users wrote:
Hi Slávek,
Good to hear from you. :)
I am aware of those options. An extra mouse click or two, but does avoid
primal screaming!
I'm still planning to look into the overall default embedded behavior
with a fresh profile.
Thanks!
None of the other DEs have this problem because
none of the other
developers design their file manager as a Swiss army knife. I am not
complaining about the wonderful multi-faceted design of Konqueror.
Nobody wants to change that. I am only advocating that there should be a
simple and sane way to change the default design so double-clicking
opens the file in a separate external tool.
to open PDF, I learned a simple trick: If I don't mind opening the file as
embedded, I will use the left button. If I want PDF open in a separate
KPDF application, I use the middle button that opens in a new window by
default. In this case, the new window is a separate KPDF, not Konqueror.
The same is applied also to other file types - for example pictures - left
button opens embedded, middle button opens separate Kuickshow window. 
17 Mar
17 Mar
11:20 p.m.
On Monday 17 March 2025 14:52:19 Darrell Anderson via tde-users wrote:
On 3/17/25 12:55 PM, WraithGlade via tde-users wrote:
I am a little unsure what the problem is that you describe, as I seem to have
solved these problems in my own way. And I have been using TDE (and before
that, KDE3) almost exclusively since about 2006 or so; or, that is, almost
exactly coinciding with when I decided to change from those other bad
proprietary operating systems that we all know and despise.
I have only briefly tried other Linux desktops; when KDE3 changed to KDE4, for
example, and I could no longer patch and hack and cobble together a working
system from my KDE 3.5 Hardy Heron 8.04x. Like you, I want to use TDE
exclusively, if possible; otherwise, I would probably rather give up
entirely, and quit using these infernal time-wasting machines for anything at
all ... except, our world nowadays pretty much demands that we use the latest
technology for everything, even when I can do it better and faster myself
with my own hands.
Just so you know where I stand on these issues ...
;-)
Now, I have tried to follow this thread, but maybe I have missed some details,
and maybe I don't grasp why you are going about this in a way that seems much
harder than necessary. And if I am totally missing the mark here, I
apologize. But here goes.
Try this: right-click on the item that you want to open with X [whatever your
desired viewer or program]. Then choose "Open With"; after which you will see
a list of your most likely choices. (The default choice will be at the top of
the list.)
To change the default choice to your own preference, look to the very bottom
of the list, where you will see "Other ..."; here you have several options.
1. There is a space to enter the name of the program you want; or you can
left-click on that little downwards-pointing arrow at the right, where you
may find a list of programs that you have already used before.
Before making any changes to your system, I would first look for your desired
program, to see if it is already in that list. Click on that to make sure
that it opens normally. If so, you can make it your permanent default choice
(for which, see the last step).
To the right of that, you will see a folder icon, where you can manually
search through your system for the program, but you will probably need to
look in /usr/bin, /usr/sbin/ or (for Trinity programs) /opt/trinity/bin
or /opt/trinity/sbin.
2. You can type in the name of a program; for example, to open a .jpg with
kuickshow or gwenview or gimp, as I describe above, and usually this works.
But sometimes you may encounter a glitch; to bypass such problems, you can
manually enter the whole path; e.g., /usr/bin/X [name of program] or
maybe /usr/sbin/X. For Trinity programs, you would enter /opt/trinity/bin/X
or /opt/trinity/sbin/X.
3. Once you have verified that your desired program opens the file you have
chosen, you may wish to make it permanent. To do so, repeat whatever step
worked to open that file (e.g., you want kuickshow to open .jpg files). That
is, (a) right-click on the file, choose "Open With" then go down to the
bottom and click on "Other ..."; or (b) manually type the name of the
program, if it comes up; or (c) manually enter the path to the program you
want; or (d) click on that folder at the right, and search through the system
(in /usr/bin/, /usr/sbin/ or /opt/trinity/bin/ or /opt/trinity/sbin/. These
are the steps that I already described above.
4. Last of all, to make these changes permanent, so that you can open a file
with your desired program just by clicking on it, or even by highlighting and
hitting "Enter": check the box at the bottom left corner, where it
says "Remember application association for this type of file"; then click OK,
and you're done.
You can always change your default preference by going through these steps
again; although, with a little practice, you probably will have it narrowed
down to one or two ways to get it done, and you won't have to search through
all possible methods, or to enter full paths, etc.
See attachment for a snapshot from my own machine.
I hope this helps; if not for yourself, then at least for some others out
there.
Slainté! (It's St Patrick's Day here.)
Later tonight, I will raise a toast to all my worthy friends, and even maybe
to some who are unworthy.
Bill
I don't know how to solve your issue itself,
but perhaps you could work
around it easily by ....
Thanks for replying. :)
All clever ideas (I relish people who think outside the box!), but in
the end all are work-arounds for a problem that should not exist.
For me the frustrating part is I am trying diligently to return to TDE
full time. 
18 Mar
18 Mar
7:44 p.m.
On 3/17/25 7:20 PM, William Morder via tde-users <users(a)trinitydesktop.org> wrote:
Now, I have tried to follow this thread, but maybe I have missed some details,
and maybe I don't grasp why you are going about this in a way that seems much
harder than necessary. And if I am totally missing the mark here, I
apologize. But here goes.
Try this: right-click on the item that you want to open with X [whatever your
desired viewer or program]. Then choose "Open With"; after which you will see
a list of your most likely choices. (The default choice will be at the top of
the list.)
...
Slainté! (It's St Patrick's Day here.)
Later tonight, I will raise a toast to all my worthy friends, and even maybe
to some who are unworthy.
Bill
Happy (belated) St. Patrick's Day to you as well Bill!
It is interesting that the thought of mentioning right clicking on the file type and
selecting "Open With..." didn't occur to me (or anyone else of us)
considering doing so is probably the most straightforward solution for at least most file
type association workflows. That is good thinking and good clarity of thought!
I suppose we got caught up in the implicit assumption that a more complex solution must be
needed and hence skipped over the most obvious and most standard solution in our minds.
Such are the quirks of the human mind, heh.
In any case, it has been a useful thought exercise to think about all the different
possible ways of approaching managing file associations and such, and it has at least been
a fruitful discussion in that regard, as it has made me (and probably others) much more
aware of additional possibilities I'd not have thought of otherwise or not have fully
mulled over with proper appreciation of the pros and cons of different approaches, etc.
Anyway though, today seems like a wonderful spring day (at least where I am) and I intend
to enjoy it. The sunlight is good for the body and the mind. And, on that note, I am
wishing you all (the TDE community) all the best today/tonight!
10:37 p.m.
On 3/18/25 2:44 PM, WraithGlade via tde-users wrote:
Anyway though, today seems like a wonderful spring day
(at least where I am) and I intend to enjoy it. The sunlight is good for the body and the
mind. And, on that note, I am wishing you all (the TDE community) all the best
today/tonight!
I too spend some hours outside this afternoon. The forecast is calling
for snow tomorrow though. :(
I found some helpful clues about the Konqueror embedded viewing behavior.
One side note is the user's profilerc has nothing to do with the
embedding issue. That file is used only to organize the user's external
app preferences. For example, KWrite is the default text editor rather
than Kate. If the user changes that order then profilerc gets created.
The profilerc does not exist if the user accepts all default preferences.
The easiest embedded viewer change is modifying image viewing behavior.
In KControl->TDE Components->File Associations, all parent groups
default to 'Show file in separate viewer' except the Image group that
defaults to 'Show file in embedded viewer'. To avoid embedded viewing,
toggle the parent setting to 'Show file in separate viewer'. Thereafter
double-clicking on image files launch the user's preferred image viewer.
Toggling that option creates an entry in the user's
$TDEHOME/config/konquerorrc file:
[EmbedSettings]
embed-image=false
Toggling other parent groups will create similar konquerorrc entries of
false|true. There is a comment in the tdebase code that inode mimetypes
should always be embedded. Probably best to leave those associations as is.
I don't know where the Image group embedded viewer default behavior is
configured in the code or desktop files. I think this is a hard-coded
presumption.
The archive mimetypes are more complicated.
In tdebase/libkonq/konq_settings.cpp:158 is a comment:
// Embedding is false by default except for image/* and for zip, tar etc.
In tdebase/kcontrol/filetypes/typeslistitem.cpp:116 is another comment:
// embed by default for zip, tar etc.
The associated code looks for the 'X-TDE-LocalProtocol' property in the
*.desktop file. Several archive related desktop files have this
property. So all of them are viewed embedded.
On my system (not a full install), there are 11 archive related desktop
files containing the 'X-TDE-LocalProtocol' property:
$TDEDIR/share/mimelnk/application/x-mimearchive.desktop
$TDEDIR/share/mimelnk/application/x-tar.desktop
$TDEDIR/share/mimelnk/application/x-tarz.desktop
$TDEDIR/share/mimelnk/application/x-tbz.desktop
$TDEDIR/share/mimelnk/application/x-tgz.desktop
$TDEDIR/share/mimelnk/application/x-tlz.desktop
$TDEDIR/share/mimelnk/application/x-tlzma.desktop
$TDEDIR/share/mimelnk/application/x-txz.desktop
$TDEDIR/share/mimelnk/application/x-webarchive.desktop
$TDEDIR/share/mimelnk/application/x-zip.desktop
$TDEDIR/share/mimelnk/fonts/package.desktop
On my system there are 22 more archive mimetypes that do not use the
'X-TDE-LocalProtocol' property:
$TDEDIR/share/mimelnk/application/x-7z.desktop
$TDEDIR/share/mimelnk/application/x-ace.desktop
$TDEDIR/share/mimelnk/application/x-arc.desktop
$TDEDIR/share/mimelnk/application/x-archive.desktop
$TDEDIR/share/mimelnk/application/x-arj.desktop
$TDEDIR/share/mimelnk/application/x-bz2dvi.desktop
$TDEDIR/share/mimelnk/application/x-bzip.desktop
$TDEDIR/share/mimelnk/application/x-bzip2.desktop
$TDEDIR/share/mimelnk/application/x-compress.desktop
$TDEDIR/share/mimelnk/application/x-cpio.desktop
$TDEDIR/share/mimelnk/application/x-gzdvi.desktop
$TDEDIR/share/mimelnk/application/x-gzip.desktop
$TDEDIR/share/mimelnk/application/x-gzpostscript.desktop
$TDEDIR/share/mimelnk/application/x-lha.desktop
$TDEDIR/share/mimelnk/application/x-lzip.desktop
$TDEDIR/share/mimelnk/application/x-lzma.desktop
$TDEDIR/share/mimelnk/application/x-lzop.desktop
$TDEDIR/share/mimelnk/application/x-pak.desktop
$TDEDIR/share/mimelnk/application/x-rar.desktop
$TDEDIR/share/mimelnk/application/x-tzo.desktop
$TDEDIR/share/mimelnk/application/x-xz.desktop
$TDEDIR/share/mimelnk/application/x-zoo.desktop
Those 22 mimetypes can be identified together using the desktop file key
'Icon=application-x-tarz'. I notice in the File Association dialog for
these individual archive mimetypes the option 'Use settings for
application group' is disabled/ghosted. The only option is to manually
toggle to 'Show file in separate viewer'. I don't know where this is
configured but I suspect hard-coded.
I do not have a full TDE install, but on my system I found 75 desktop
files explicitly using 'X-TDE-AutoEmbed=true' that are not image or
archive mimetypes. Likely there are more files with a full install. This
individual option overrides the parent group rule. Those related to my
personal inconvenience include:
$TDEDIR/share/mimelnk/application/postscript.desktop
$TDEDIR/share/mimelnk/application/pdf.desktop
$TDEDIR/share/mimelnk/application/x-jar.desktop
$TDEDIR/share/mimelnk/application/x-rpm.desktop
Excluding options such the Konqueror "right-click" context menu, in my
usage that is more than three dozen mimetypes that have to be modified
manually to avoid embedded viewing when I double-click on a respective
file. That is a lot of dialog walking and mouse button clicking. That
number might explain why I have been frustrated with the default
embedded behavior. :)
I understand some of the decisions from days of lore. Ark and image
viewers are not installed as part of tdebase. Theoretically users could
have a minimal install leaving them with no external viewers. So
embedded viewing makes some sense.
Any time the user modifies a mimetype embedded/separate viewer defaults,
there will be respective xyz.desktop group file created in
$TDEHOME/share/mimelnk. Those files will contain 'X-TDE-AutoEmbed=false'.
On a single user basis, resolving the embedded image file viewing is a
one-click fix.
Short of editing all related system archive desktop files with
explicitly adding 'X-TDE-AutoEmbed=false', seems the only way to use Ark
for archive mimetypes is manually change the behavior in the File
Associations dialog. Likewise with some of the hard-coded embedded
viewing mimetypes such as pdf.
I did not see a way to change default behavior other than walking
through the file association dialog tree to toggle the default embedding
behavior. Time consuming. From an admin perspective I wrote myself a
shell script to create the required mimelnk desktop files and avoid
manually walking through the dialog. The script works nicely. In about 5
seconds I save much time and avoid frustration.
If using external viewers for these mimetype files is desired to be a
global behavior for all user accounts, then the mimelnk desktop files
should be copied to a common $TDEDIRS directory. That environment
variable is not active by default and requires an admin to expend some
energy. The starttde script also needs attention because that variable
is ignored.
Being an old school grumpy old man means I am unlikely to quash my
dislike of embedded viewing. I now know that somebody long ago decided
image, archive, and a handful of other mimetype files should be viewed
embedded. My shell script quickly overrides that presumption. So for me,
finally, some peace of mind. :)
19 Mar
19 Mar
1:11 a.m.
ср, 19 мар. 2025 г., 01:37 Darrell Anderson via tde-users <
users(a)trinitydesktop.org>gt;:
On 3/18/25 2:44 PM, WraithGlade via tde-users wrote:
May be at some point in future there will be button named "switch all mime
types from built-in to external", if of course there is space in gui for
that.
Thanks for sharing both problem and solution, it was interesting read even
if right now I use Fluxbox/MATE /KDE4 hybrid on NetBSD (not ready for all
this fun from trying TDE here .. not yet, at least).
Anyway though, today seems like a wonderful
spring day (at least where I
am) and I intend to enjoy it. The sunlight is good for
the body and the
mind. And, on that note, I am wishing you all (the TDE community) all the
best today/tonight!
I too spend some hours outside this afternoon. The forecast is calling
for snow tomorrow though. :(
I found some helpful clues about the Konqueror embedded viewing behavior.
One side note is the user's profilerc has nothing to do with the
embedding issue. That file is used only to organize the user's external
app preferences. For example, KWrite is the default text editor rather
than Kate. If the user changes that order then profilerc gets created.
The profilerc does not exist if the user accepts all default preferences.
The easiest embedded viewer change is modifying image viewing behavior.
In KControl->TDE Components->File Associations, all parent groups
default to 'Show file in separate viewer' except the Image group that
defaults to 'Show file in embedded viewer'. To avoid embedded viewing,
toggle the parent setting to 'Show file in separate viewer'. Thereafter
double-clicking on image files launch the user's preferred image viewer.
Toggling that option creates an entry in the user's
$TDEHOME/config/konquerorrc file:
[EmbedSettings]
embed-image=false
Toggling other parent groups will create similar konquerorrc entries of
false|true. There is a comment in the tdebase code that inode mimetypes
should always be embedded. Probably best to leave those associations as is.
I don't know where the Image group embedded viewer default behavior is
configured in the code or desktop files. I think this is a hard-coded
presumption.
The archive mimetypes are more complicated.
In tdebase/libkonq/konq_settings.cpp:158 is a comment:
// Embedding is false by default except for image/* and for zip, tar etc.
In tdebase/kcontrol/filetypes/typeslistitem.cpp:116 is another comment:
// embed by default for zip, tar etc.
The associated code looks for the 'X-TDE-LocalProtocol' property in the
*.desktop file. Several archive related desktop files have this
property. So all of them are viewed embedded.
On my system (not a full install), there are 11 archive related desktop
files containing the 'X-TDE-LocalProtocol' property:
$TDEDIR/share/mimelnk/application/x-mimearchive.desktop
$TDEDIR/share/mimelnk/application/x-tar.desktop
$TDEDIR/share/mimelnk/application/x-tarz.desktop
$TDEDIR/share/mimelnk/application/x-tbz.desktop
$TDEDIR/share/mimelnk/application/x-tgz.desktop
$TDEDIR/share/mimelnk/application/x-tlz.desktop
$TDEDIR/share/mimelnk/application/x-tlzma.desktop
$TDEDIR/share/mimelnk/application/x-txz.desktop
$TDEDIR/share/mimelnk/application/x-webarchive.desktop
$TDEDIR/share/mimelnk/application/x-zip.desktop
$TDEDIR/share/mimelnk/fonts/package.desktop
On my system there are 22 more archive mimetypes that do not use the
'X-TDE-LocalProtocol' property:
$TDEDIR/share/mimelnk/application/x-7z.desktop
$TDEDIR/share/mimelnk/application/x-ace.desktop
$TDEDIR/share/mimelnk/application/x-arc.desktop
$TDEDIR/share/mimelnk/application/x-archive.desktop
$TDEDIR/share/mimelnk/application/x-arj.desktop
$TDEDIR/share/mimelnk/application/x-bz2dvi.desktop
$TDEDIR/share/mimelnk/application/x-bzip.desktop
$TDEDIR/share/mimelnk/application/x-bzip2.desktop
$TDEDIR/share/mimelnk/application/x-compress.desktop
$TDEDIR/share/mimelnk/application/x-cpio.desktop
$TDEDIR/share/mimelnk/application/x-gzdvi.desktop
$TDEDIR/share/mimelnk/application/x-gzip.desktop
$TDEDIR/share/mimelnk/application/x-gzpostscript.desktop
$TDEDIR/share/mimelnk/application/x-lha.desktop
$TDEDIR/share/mimelnk/application/x-lzip.desktop
$TDEDIR/share/mimelnk/application/x-lzma.desktop
$TDEDIR/share/mimelnk/application/x-lzop.desktop
$TDEDIR/share/mimelnk/application/x-pak.desktop
$TDEDIR/share/mimelnk/application/x-rar.desktop
$TDEDIR/share/mimelnk/application/x-tzo.desktop
$TDEDIR/share/mimelnk/application/x-xz.desktop
$TDEDIR/share/mimelnk/application/x-zoo.desktop
Those 22 mimetypes can be identified together using the desktop file key
'Icon=application-x-tarz'. I notice in the File Association dialog for
these individual archive mimetypes the option 'Use settings for
application group' is disabled/ghosted. The only option is to manually
toggle to 'Show file in separate viewer'. I don't know where this is
configured but I suspect hard-coded.
I do not have a full TDE install, but on my system I found 75 desktop
files explicitly using 'X-TDE-AutoEmbed=true' that are not image or
archive mimetypes. Likely there are more files with a full install. This
individual option overrides the parent group rule. Those related to my
personal inconvenience include:
$TDEDIR/share/mimelnk/application/postscript.desktop
$TDEDIR/share/mimelnk/application/pdf.desktop
$TDEDIR/share/mimelnk/application/x-jar.desktop
$TDEDIR/share/mimelnk/application/x-rpm.desktop
Excluding options such the Konqueror "right-click" context menu, in my
usage that is more than three dozen mimetypes that have to be modified
manually to avoid embedded viewing when I double-click on a respective
file. That is a lot of dialog walking and mouse button clicking. That
number might explain why I have been frustrated with the default
embedded behavior. :)
I understand some of the decisions from days of lore. Ark and image
viewers are not installed as part of tdebase. Theoretically users could
have a minimal install leaving them with no external viewers. So
embedded viewing makes some sense.
Any time the user modifies a mimetype embedded/separate viewer defaults,
there will be respective xyz.desktop group file created in
$TDEHOME/share/mimelnk. Those files will contain 'X-TDE-AutoEmbed=false'.
On a single user basis, resolving the embedded image file viewing is a
one-click fix.
Short of editing all related system archive desktop files with
explicitly adding 'X-TDE-AutoEmbed=false', seems the only way to use Ark
for archive mimetypes is manually change the behavior in the File
Associations dialog. Likewise with some of the hard-coded embedded
viewing mimetypes such as pdf.
I did not see a way to change default behavior other than walking
through the file association dialog tree to toggle the default embedding
behavior. Time consuming. From an admin perspective I wrote myself a
shell script to create the required mimelnk desktop files and avoid
manually walking through the dialog. The script works nicely. In about 5
seconds I save much time and avoid frustration.
If using external viewers for these mimetype files is desired to be a
global behavior for all user accounts, then the mimelnk desktop files
should be copied to a common $TDEDIRS directory. That environment
variable is not active by default and requires an admin to expend some
energy. The starttde script also needs attention because that variable
is ignored.
Being an old school grumpy old man means I am unlikely to quash my
dislike of embedded viewing. I now know that somebody long ago decided
image, archive, and a handful of other mimetype files should be viewed
embedded. My shell script quickly overrides that presumption. So for me,
finally, some peace of mind. :)
____________________________________________________
tde-users mailing list -- users(a)trinitydesktop.org
To unsubscribe send an email to users-leave(a)trinitydesktop.org
Web mail archive available at
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt…
1:16 a.m.
On Tuesday 18 March 2025 12:44:04 WraithGlade via tde-users wrote:
Glad that I could be of some help to somebody out there. I was beginning to
wonder if my emails were going through to the list.
It may be that Darrell has other needs, but I thought that I ought at least to
point out an easier way for the average user.
Don't get me wrong: I also like to know how things work, and I don't mind
digging into the settings and configuration files that were not intended to
be read by human beings.
Most of the time, though, I just want to get things done. My machines are
supposed to serve me, although sometimes I must show them who is the boss.
Bill
On 3/17/25 7:20 PM, William Morder via tde-users
<users(a)trinitydesktop.org>
wrote:
Now, I have
tried to follow this thread, but maybe I have missed some
details, and maybe I don't grasp why you are going about this in a way
that seems much harder than necessary. And if I am totally missing the
mark here, I apologize. But here goes.
Try this: right-click on the item that you want to open with X [whatever
your desired viewer or program]. Then choose "Open With"; after which you
will see a list of your most likely choices. (The default choice will be
at the top of the list.)
...
Slainté! (It's St Patrick's Day here.)
Later tonight, I will raise a toast to all my worthy friends, and even
maybe to some who are unworthy.
Bill
Happy (belated) St. Patrick's Day to you as well Bill!
It is interesting that the thought of mentioning right clicking on the file
type and selecting "Open With..." didn't occur to me (or anyone else of
us)
considering doing so is probably the most straightforward solution for at
least most file type association workflows. That is good thinking and good
clarity of thought!
I suppose we got caught up in the implicit assumption that a more complex
solution must be needed and hence skipped over the most obvious and most
standard solution in our minds. Such are the quirks of the human mind, heh.
In any case, it has been a useful thought exercise to think about all the
different possible ways of approaching managing file associations and such,
and it has at least been a fruitful discussion in that regard, as it has
made me (and probably others) much more aware of additional possibilities
I'd not have thought of otherwise or not have fully mulled over with proper
appreciation of the pros and cons of different approaches, etc.
Anyway though, today seems like a wonderful spring day (at least where I
am) and I intend to enjoy it. The sunlight is good for the body and the
mind. And, on that note, I am wishing you all (the TDE community) all the
best today/tonight!
14
days inactive
20
days old
15 comments
7 participants
participants (7)
-
Andrew Randrianasulu -
Darrell Anderson -
Jim -
Michele Calgaro -
Slávek Banko -
William Morder -
WraithGlade