Start a new topic

REQ: Horizontal scrollbars are evil / only when less than x px

When working with a 27 inch screen, CT tneds to set horizontal scrollbars when having about 5 tabs side by side (= ca. 10 cm screen width for each tab, even if CT is not in full screen).


This is a bit annoying, especially to detect differences in matches.

Is there any known limit, maybe also depending on type size? Or maybe something like "only use horizontal scrollbars with less than 20 characters" (always difficult with CCJK languages, I assume).

I can't see the whole window but the horizontal scrollbar has nothing to do with the number of tabs but rather with wrapping of some long words or unusual characters. 

No long words or unusual words here:



Maybe because of these (another segment, I forgot to record the horizontal scrollbar above):


Wasn't that resolved some time ago?

Wasn't that resolved some time ago?

Sure, it was. The user (you?) complained that the hit numbers wrapped. :)

Yes, it was me, but the problem was slightly different.

And wouldn't it even be better to wrap really long words such as Donaudampfschiffahrtsgesellschaftskapitän or Donaudampfschiffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft? Hans might have much more problems with these small linguistic monsters.


Yes, it was me, but the problem was slightly different.

Its resolution led to a slightly wider pane. The words wrapping behavior is usually determined by the underlying Java component, which in turn depends on the language family. The developer can hack it to some extent but wouldn't it be faster if you resized your pane a bit. CT offers tens of layout possibilities.  I am sure it can accommodate even " Donaudampfschiffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft".  

Well, that is not so nice for translators from German, though these very large words are not so frequent nowadays.


However, concerning the scrollbars even without "some long words or unusual characters" will remain? I can understand if there must be a hard coded limit for the minimum width, but about 12 cm appears quite wide to me. Another strange thing is when frist opened and showing the contents and number of segments, the corresponsing table fits perfectly into the same tab...

The corresponding pics for „Another strange thing is when first opened and showing the contents and number of segments, the corresponding table fits perfectly into the same tab...“:



Same tab, no changes of the width were made.

You seem to have opposite and conflicting requests. The HITS numbers (1 to 10) are displayed in one row causing the horizontal bar appear correctly if you narrow the pane too much (as in your second screenshot).

However, before you did not like the HITS number wrapping in two rows in the past CT versions, which in turn did not cause the horizontal bar appear. That's Catch 22 case. Just widen your pane to let display all the 10 hits (in the results) and the horizontal bar will be gone. The display of 10 numbers in one row is not that wide!

Ah, I understand, and I see the problem. The wrapping before this Catch 22 was arbitray, not
FRAGMENT | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
FRAGMENT | 1 | 2 | 3 | 4 | 5 |
6 | 7 |
2 | 3 | 4 | 5 | 6 | 7 |

or even
2 |
3 |
4 |
5 | 6 | 7 |

despite of having enough width.

Am I right assuming that after Catch 22 there is no more carriage return between the numbers allowed?

See here:


The spacing between the "|" and the numbers appears rather wide, it is &nsbp; I assume.

Any chances to get this shorter (in the sense of a clean GUI). Proposals (to be combined or not)

  1. Make the wording shorter: H instead of Hits, F instead of Fragments, VF instead of Virtual Fragements, including a hovering effect
  2. Give them (Matches, Hits, Fragments, virtual Fragments) slightly different colors
  3. Give the user a chance to define these size fonts and colors himself (one setting only for Matches, Hits, Fragments, virtual Fragments)
  4. Give them (Matches, Hits, Fragments, virtual Fragments) slightly different background colors
  5. Make the numbers shorter, perhaps no   or only one behind the number (if this does not break again the existing behaviour)
  6. Make the numbers smaller (but still easy clickable)
  7. The heretic way: make a GUI revolution – only a small, colored line between the matches (the color could differentiate the following match/hit) and a kind o hover effect to discover the occurrences
  8. The not so heretic way: make a half GUI revolution – only a small, colored line for Hits, Fragments, virtual Fragments, but not for matches

Being a developer can be painful and stressful, I see. Hope you see some ideas.


Just another 2 cents for less clutter on the GUI: Only set the percentage instead of the word MATCH. It should be rather clear even for rookies that is a match then.
MATCH 100 %
100 %

 See here:


Why not simply set

100% Different source

(with the same superscript, of course. Freshdesk does not allow this ad hoc).

This would put more emphasis on "Different source", and we translators are anyway conditioned on "100%", aren't we? Another possibility would be underlining the percentage in case of 100%, 101% and 102% matches:

100% Different source

What about this? Or a green or blue hook instead of "MATCH"?

(with setting an emoticon CT could become trendy, but IMHO this is too childish)

1 person likes this
Yay. Nice to see this. One step forward.



Login to post a comment