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.
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:
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:
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:
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
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:
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:
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
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/13/25 2:30 AM, Michele Calgaro via tde-users wrote:
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:
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:
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.
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/14/25 11:58 PM, Darrell Anderson via tde-users wrote:
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:
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:
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.
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.
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. :)
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!
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!
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 --
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
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:
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.
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!
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 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 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
On 3/17/25 7:20 PM, William Morder via tde-users users@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!
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 мар. 2025 г., 01:37 Darrell Anderson via tde-users < users@trinitydesktop.org>:
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. :)
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).
tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskto...
On Tuesday 18 March 2025 12:44:04 WraithGlade via tde-users wrote:
On 3/17/25 7:20 PM, William Morder via tde-users users@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!
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
-
Andrew Randrianasulu -
Darrell Anderson -
Jim -
Michele Calgaro -
Slávek Banko -
William Morder -
WraithGlade