Would be helpful, if either
- the line was shorted and fully shown on mouse-over
- the first column was using line breaks
- there was more width
- at least the shortcut name was also printed on the settings dialogue below, this time fully readable
Thanks
I guess it happens after changing the font? I’ve noticed that lines get chopped if the font doesn’t quite fit, the GUI being optimized/hardcoded for the deja vu size/width. It can happen at quite a few places in the GUI actually - like DSP parameters, adv edit and whatnot. I can imagine it would take quite a bit of work to change all columns (and full structure above each column) to auto-resize. Maybe not difficult if it’s already nicely structured similarly to a good viewbuilder structure, but I doubt that.
EDIT: point above might be irrelevant.
Huh, so you mean this is not dejavu anymore? I thought you only can change the pattern font, not the general gui font.
All fonts can be changed AFAIK. There are two .xml files. Not sure if the default setting handles these long lines properly, but it might be worth verifying it’s not a font issue first. (just mentioning since I know you dabbled with font settings).
If not, +1
If this works the same as in window tools, the reason is that the width of the text is not updated when its parent envelope, in this case an envelope column (probably), resizes.
This implies that, wherever there is changing text or resizable window in width, or a tree list, it is necessary that the width of the text be updated according to its envelope. It must be programmed in each case. Being a tree list, it is the tree that moves the text.
When we build window tools with variable width this is a common problem that has a solution (resize the text every time your envelope changes). I remember @Ledger once asked about this months ago. When well designed, the text should appear like this (with a double point at the end):
Empty envelope (a column?):
[____________________________________]
Original text:
[_text_text_text_text_text_text______]
Envelope resized:
[_text_text_tex..]
I suppose that under the hood of Renoise it works the same way. So it is not strange to find this situation in several parts.
By the way, I suppose this is the main cause that Renoise does not offer a way to change the font size from the Preferences window. Here is not only the horizontal dimension, but also the vertical one.
If you change the font type (manipulating the XML file), its width may also change (and height).
Renoise should have a new functionality in text boxes that updates automatically the “maximum width” of the text according to the width of its parent envelope. If this existed, there would be no problem in any text box.
In the window tools, it is to update automatically the “width property” inside the text box. As this does not exist, it is necessary to review that “width” in particular.
By the way, this would not happen if these types of windows were larger. I have already commented on more than one occasion that they should be bigger. The preferences window I consider it too small. But the frames of “Keys”, “MIDI Mapping” and the like should have a detachable window.
Another more sophisticated solution is to use “a marquee” inside the text box, in case the text does not fit.
Personally I would prefer line breaks simply, a table row doesn’t need to be anally one line only… Numbers and Excel cando line breaks, too! It’s like a whole new experience.
For the tree a line break would be feasible. But for a text box, forcing the envelope to be twice as tall or more could damage the rest of the objects below. The multi-text adds a vertical slider to the right, valid for a fixed height.
The simplest thing is that the text box will work automatically by cutting the text with the double point, without having to check / update its width.
If you want to experiment extensively with this problem, increase the font size in the XML file. You will see what happens in many places.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.