I need a CodeMirror editor which starts with a certain width and then grows automatically to the right to match the maximum line length. I.e. roughly what CodeMirror does when height is set to auto, but with width.
Here's a self-contained example. The editor grows automatically along the y-axis fine, but not along the x-axis. By tweaking the CSS, I can either have a fixed width editor with a scrollbar, or one which fills the entire width of the browser, but not one which grows as you type. I assume overflow-x is relevant, but I don't understand how it interacts with other CSS size properties set on parent elements. I also tried setting that property on CodeMirror-scroll, but it didn't help.
I believe this can be done using CSS properties alone. In fact I have this behaviour in my application already, but growing to the left, rather than the right, but I don't understand why it happens, or how to reproduce it in a small example.
This question is essentially the same, but for the vertical scrollbar.
Simply add float:left to the CodeMirror div.
<div id="here" style="float:left"></div>
This is not something CodeMirror supports. You may be able to get something working by setting .CodeMirror's width to (-webkit-)fit-content, but there will likely be corner cases where this breaks the scrollbars or cursor placement.
Related
Background: we have TinyMCE React inside a few contexts where the parent element is manually resized by the user (resizable modal dialog, etc.) and we want the TinyMCE component to resize appropriately. In older versions, we did this using the resizeTo functionality documented here. However, that no longer seems to be available after the upgrade.
My previous attempt to resolve this involved using a key based on concatenating the width and height of the editor with a debounce while it was resizing. Basically, whenever the size changed by enough, I tore down the old component and rendered a new one whose config options included the new size. While this is largely effective, it causes an issue where, when you attempt to edit the field after resizing, it flickers and loses focus initially.
Unfortunately, we are using pixel-based size calculations, so specifying the height in percentages instead of pixels won't work.
What is the new official way to do this? Ideally, there would be some new version of editor.theme.resizeTo that we could use instead and dispatch with the key-based solution entirely, but I was unable to find it in any of the documentation.
Just wrap the editor in a div which has the calculated height and width, and then set the editor to height and width of 100%.
I have a select menu on a responsive page, which is set with a fluid width (% value). Everything looks fine until i decrease the page size, when the default value of the select menu (i.e when it's not focussed or clicked on) becomes squashed in the container and overflows, causing part of the text to be hidden, like this. Ideally, this needs to be solved.
I was thinking of incoporarting a line-break, using CSS/Javascript whenever the text overflows. However, I can not think of an appropriate CSS property or JS method to do this on a select element. Does anyone have experience with this or know how to solve it? You don't need to use my suggestion, feel free to come up with something else. The main thing is the text needs to be shown in it's entirety all the time on any screen size.
I have a jsfiddle link here, which uses CSS animations to simulate the page size decreasing.
We have many screens where different types of GWT panels are used.
One common problem across many screens is that, content size is derived at runtime. So, if I define a height for a panel(Vertical/Horizontal/DockPanel) and when any new components are getting added within panel or content is more, panel height remains the same. So we are not able to see the contents. UI look and feel becomes worst.
How do we handle the height problems? Do we have to manually code to adjust every panel/widget height when something gets changed in screen. Is it not a very bad way of coding?
Also, now we have datagrids at some places, if no of records are very less, we see a huge space left out below datagrid, not sure how do we handle these cases?
Updated below with few examples as per the comment:
Do you mean to say that whenever we know that content grows vertically, we can always choose FlowPanel. Because, some of the screens we have used Vertical panel/Horizontal Panel and inside that when user clicks something a new fields getting added and shown. So Vertical Panel/Horizontal Panel height automatically not getting adjusted. One more example is that we have main Vertical Panel within a Dock Layout Panel content area and inside that there are some widgets whose content may vary. So now if I use a FlowPanel to the content which varies in size, what about outer panels? Will get it adjusted? Again to say the kind of panels we have used - Dock Layout Panel is used with fixed header, footer, left menu and Content area. A scroll panel is used within Content area. All our different widgets go inside this which is mix and match of horizontal/vertical/datagrids..etc.
In GWT (and HTML) you can either set the height of a panel or let it expand naturally. In general, once you set the height of something, you lose the ability to let it expand naturally.
Some Panels in GWT implicitly set their own height (or require that you set their height) and so are never good choices for dynamically sized content. LayoutPanels and ScrollPanels, for example, can never adjust dynamically, and expect you to provide size information programmatically. FlowPanels and HTMLPanels, on the other hand, are great for dynamic heights and would rather you not set their height explicitly.
If you want a scrolling panel, of course you have to define how high it should be - how else could it know when to scroll and when to just get bigger? But, you can put a FlowPanel (which expands automatically) inside a ScrollPanel (which you have set at 800px or whatever). Then, as you add content to the FlowPanel, it will expand inside the ScrollPanel. Users can then scroll to see different parts of the FlowPanel.
Trouble-shooting tips:
Make sure you aren't setting the height on panels that you want to expand naturally
Make sure you ARE setting the height on panels that should always be the same size
Try using FlowPanels instead of Horizontal/VerticalPanels
*LayoutPanels and AbsolutePanels always need explicit sizes and can never grow dynamically as you add more content. Anything you want to grow with content should probably be a FlowPanel or HTMLPanel.
I want to create a custom panel/layout and it's seeming pretty impossible at this point. I need the components to start in the upper left corner and stack downward until they fill the panel vertically, then wrap to the top of the next column and so on until they eventually fill the screen and create a horizontal scrollbar. After an entire day of trying I've decided it's only possible by abusing GWT (and I assume the whole web browser) adding crippling complexity and terrible performance. Please let me know if I'm missing something and layout like this is possible. Thank you!
Lame solution: Have a small (almost invisible) AbsolutePanel where every string is displayed within a div and measured (getClientWidth/height()). Then each panel can calculate it's size based on the strinsg, borders, padding, etc. it contains. Once each panel knows it's size, they can be layed out relative to the sizes of the other panels in the contianer.
Check out FlexTable, which allows you to specify the row,column for the widget to be added
I'm using a TreeViewer within a jface WizardPage and the initial input into the tree causes the WizardPage to grow vertically so that it can show all of the tree's values. When expanding one of the tree's values, then the vertical scrollbar works as expected. I'd like to be able to set the tree's size initially so that it is fixed and the scrollbar is already shown when the WizardPage is first drawn, but doing this isn't particularly obvious to me - the setSize method on the TreeViewer's Tree doesn't seem to do anything.
Any help would be appreciated!
Just for the records for this old question:
We solve this problem in our applications by using an own layout manager which we can set fixed sizes for certain controls (with Swing we had done that by using component.setPreferredSize(size)). If no such fixed size is used, we calculate the preferred size of the control while performing the layout. This prevents making controls getting more and more space depending on the control's content when the user resizes the application window or dialog.