Kate/Kwrite: unable to select any font style other than first listed #271

The other styles are greyed out and not selectable. This is not a problem for fonts whose first style is "Regular" but there are many fonts whose first style is something less acceptable like "Light".

In comparison, Konsole does not have to have this problem. See attached screenshots.

TDE version: TDE: R14.1.0, commit 821cad21a2
Distribution: Gentoo

Select Font - Kate.jpg

82 KiB

Select Font - Konsole.jpg

45 KiB

I can confirm this as well. Same problem affects also KWrite, while in TDevelop the "Configure editor" menu entry is grayed out.
I wonder if it happens in R14.0.x as well or not?

Can confirm it for all installed fonts (on master). Looks like the style selection is just disabled (relevant code line here).

I assume this was done so that one could not select Italic and Bold variants, when fonts used to have only those. Now when many fonts have multiple weights the code that handles font styles in TDEFontDialog must be reworked (in comparison, TQFontDialog handles this just fine).

Even so, this limitation in Kate does not seem reasonable, taking in consideration that Konsole works just fine with italic and bold variants. I propose to just enable font style selection in Kate.

It is possible that the choice of style is disabled because bold and italic styles can be used for syntax highlight and therefore the selection of font is limited to family selection, but not style.

Okay, makes sense, but should the choice really be restricted? Maybe providing a drop-down of available styles instead of B and I checkboxes would be better? (e.g. one would be able to also select light or semi-bold or ultra-bold styles).

Can confirm it for all installed fonts (on master). Looks like the style selection is just disabled (relevant code line here).

Yes, that looks like the culprit.

It is possible that the choice of style is disabled because bold and italic styles can be used for syntax highlight and therefore the selection of font is limited to family selection, but not style.

Since kate/kwrite can be used as general text editors (versus programmer text editors), I think the simplest thing to do is to just allow selection of any available style without filtering. That's what KDE's kate does, not that we have to follow what they do :)

Even currently, a user can do strange things like configure kwrite to use cursive font like Edwardian Script ITC. The syntax highlighting still works because of the font colorization. And now that I just proved that point to myself, I need to change that setting back to a monospace font before my eyes burn out!

Yes, surely, such justification does not seem to be very convincing. This seems better to assume a sane user, do not limit it and leave the option to the user.

It is possible that the choice of style is disabled because bold and italic styles can be used for syntax highlight and therefore the selection of font is limited to family selection, but not style.

I don't think that is the reason, since in a different tab of the font config module it is possible to select/deselect bold, italic and other styles for various part of the text.

I also agree that it would be better to give the user the ability to choose whatever style he prefers.

For info, I did a test in Lenny with KDE 3.5.10 and the same limitation was already there. So it is a long standing thing.

Latest commit should enable font style selection for all applications using the Kate editor part.

I think we should have tested the commit better before merging it.
The commit indeed works, in that it allows to select other styles. But it now opens up another problem, which is the interaction between the selected style and the modifiers in the other tabs of the same config module.
For example:

I have strings set as normal text.
I select a font style bold+italics: everything turns bold and italics
I go to the "normal text style" config tab. I turn bold and italics on and off for the string element. Now strings are shown in normal characters (non bold, non italics)
I change the font style (in Font config tab) to normal and then back to bold+Italics. The strings are still shown in normal characters, as per action on point 3. I don't see any option to reset/ignore the changes done in point 3 and have the behavior of 2) enforced again.

The point I am making is that what we choose in "font" tab must work together with what is chosen in the other two tabs. We should discuss what is the best way of cooperation (OR logic, XOR logic, "font" settings lower priority + reset).

@MicheleC

I think we should have tested the commit better before merging it.
The commit indeed works, in that it allows to select other styles. But it now opens up another problem, which is the interaction between the selected style and the modifiers in the other tabs of the same config module.
For example:

I have strings set as normal text.

I select a font style bold+italics: everything turns bold and italics

I go to the "normal text style" config tab. I turn bold and italics on and off for the string element. Now strings are shown in normal characters (non bold, non italics)

I change the font style (in Font config tab) to normal and then back to bold+Italics. The strings are still shown in normal characters, as per action on point 3. I don't see any option to reset/ignore the changes done in point 3 and have the behavior of 2) enforced again.

The point I am making is that what we choose in "font" tab must work together with what is chosen in the other two tabs. We should discuss what is the best way of cooperation (OR logic, XOR logic, "font" settings lower priority + reset).

As I said earlier the B and I checkboxes are limiting. Maybe having dropdowns with available font styles would be better instead. As for the cooperation, I think syntax highlighting options should just override any settings in the Font tab.

I thought about this last night. I think a possible solution would be for the B/I/.. checkboxes to be tristate. They would do the following thing:

if checked: option is active. For example text would be in bold or italics
if not checked (white color): option is not active. For example text would not be in bold or italics
if grayed out: option is ignored and setting of font style is used. Text would be in bold or italics if that was the style of font selected on the "font" tab.

This gives the user full control on what to enable in every situation. What do you think?

EDIT: the current default "not checked" state would have to be changed to "grayed out" to preserve current behavior.

Well, looks like these are no ordinary checkboxes in the Normal text style tab: https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/src/branch/master/kate/part/kateschema.cpp#L1500

As such the tristate mechanism would have to be copied/reimplemented :-(

Also, if you right-click one of the styles, a popup menu comes up with these same options, and checkable popup menu items cannot be tristate per the TQt docs.

Thanks for the feedback, looks like there is quite a fair bit of work to do to implement this.
Where should we go from here?

Maybe we should consider the "override" option?

Override is fine as long as it is sync, that is if a user sets a checkbox, it overrides the value from the font tab. But from my previous testing (as described in previous comments), it seems that this is not the case. Settings in the font tab sometimes overrides the checkboxes, while sometimes is the opposite. Hence the previous suggestion of the tri-state cehckbox. If gray --> use font tab settings, if not gray (either checked or not) --> override the font tab settings.

I looked at this problem and I think there are only two options:

three-state checkboxes
disable font style modification

Override checkboxes do not seem suitable here, because there would have to be checkbox for override together with checkbox of the choice – that would be strange.

At the moment I do not have ideas for any other solution that would be usable and user friendly.

disable font style modification

Removing this may not be the best idea. Users may be used to use it, so taking this away may lead to complains and requests to put it back in.
3-state checkboxes seems the best option, as far as I can say.

Although the basis of the problem has been solved, this requires further effort. That's why I remove it from milestone R14.0.13.