Okteta currently defaults (on my system at least) to ISO-8859-1 for the character encoding. I only use Okteta to view EBCDIC files so I have to change the encoding on every file I load. It would be useful for Okteta to do one of three things: 1. Remember the encoding set by the user via View->Char Coding 2. Allow a default setting to be set (this appears to require the existence of a Settings->Default menu) 3. Allow Okteta to accept a command line argument specifying the encoding of the document Perhaps #2 is the best option, since there are currently a few outstanding wishes that could also be placed there. Bug #441925, #462703, #421357, #170926, etc. Either way, the addition of this behavior would greatly help me in my work, and hopefully others.
Thanks for the feedback. Curious for now, had you discovered the feature "View Profiles" already and tried to solve your need using that? This feature includes selecting a certain charset. And one can set a certain View Profile as default in the View Profile managing dialog (Settings->Manage View Profiles...), to meet the most typical usecases. The proposed alternative solutions are something worth to consider as well, but before discussing and implementing support for that (and then needing to support that in the future because people rely on it) I prefer if people can get things easily done with the existing features :)
(In reply to Friedrich W. H. Kossebau from comment #1) > Thanks for the feedback. Curious for now, had you discovered the feature > "View Profiles" already and tried to solve your need using that? This > feature includes selecting a certain charset. And one can set a certain View > Profile as default in the View Profile managing dialog (Settings->Manage > View Profiles...), to meet the most typical usecases. > > The proposed alternative solutions are something worth to consider as well, > but before discussing and implementing support for that (and then needing to > support that in the future because people rely on it) I prefer if people can > get things easily done with the existing features :) Ooh, that's good! I saw View Profiles and thought it was something to do with colors and toolbars, but not something where I could set the default encoding. That will work nicely for me. Perhaps section 4.1.7 of the Okteta Handbook could be expanded to identify the types of things that the Profile can affect? I searched the Handbook for encoding, but it's not listed as something a Profile can change. Thanks!
Made a separate reminder to myself about the handbook by the new bug 465780, as I see how that might have helped. Now to your proposed solutions for your problem: #1 (remembering the last used setting) is something worth to considering next to the view profile system, for those who have not yet discovered it or prefer always the last manual settings over some configured default. After all the tools with parameters in recent versions also remember the last parameters manually set (do not remember though why the search/replace dialogs did not get that also). #2 (some central config dialog) is something I personally try to avoid, instead try to have any config as close as possible to the actiual UI. Even more as Okteta is made of elements which are designed to be embedded into other software, where the configuration also needs to be available (cmp. https://frinring.wordpress.com/2010/02/16/okteta-going-for-kdevelop-and-kate/ still valid a decade later :) ). Having separately another way via a central settings dialog for mass configuration makes sense to me also, but had not yet got to that, due to complexity when embedding/integrating into other applications. #3 (setting view properties as additional args on the commandline) might be interesting. Comes with the challenge that Okteta supports multiple documents (and even multiple views on the same document), so perhaps someone might want to have more fine control which document to show with which view settings. For this I first would like to gather a good set of use cases that need this very solution for other reasons to properly design the support. So after this first round of thinking, would keep this report open with the focus on the feature request for remembering the last manual view settings. Might take some time before I get to it, as currently working on other things. Happy to get more comments on the matter though to consider then at the time of going to implementation.