I've looked in the gtk source code and the header height is private. I've tried something but it didn't work as wanted (the heightWithHeader is 1?!)
Glib::RefPtr<Gdk::Window> pWindow = treeView.get_bin_window();
treeView.set_headers_visible(true);
pWindow->get_size(width, heightWithHeader);
treeView.set_headers_visible(false);
pWindow->get_size(width, heightWithoutHeader);
r_treeView.set_headers_visible(true);
returnValue = heightWithHeader - heightWithoutHeader;
Can you help me with another solution or a fix to my code?
Update: I have to adjust the height of the treeview to display a fixed number of rows. I do this by adjusting the size of the container (a scrolledwindow) to headerHeight + numberRowsToDisplay * heightOfRow.
The reason your code doesn't work is very probably that you're being "too impatient", not giving GTK+ time to do the redraw of the widgets before you make the headers invisible again.
GTK+ doesn't draw immediately when you do a call that requires a redraw. Instead redraws are queued, and then done all at once from the GTK+ main loop. This way, doing two changes to widgets in sequence does not cause two redraws, but only one.
It's a bit of a hack, but you could try the "classic" GTK+ event-flushing trick, by inserting a loop like this after you turn on the headers:
while(gtk_events_pending())
gtk_main_iteration();
This simply loops for as long as there are events in GTK+'s queue (the draw changes mentioned above are events, internally), and flushes them, then gives control back to you. This will very probably result in some visual flicker, though.
Related
https://imgur.com/X2gEMqO
Check out the video to see what I'm talking about ⤴
Before I start making custom widgets I wanted to see if anyone knew a way to fix this with vanilla Flutter. It seems to be something related to the TextEditingController but I'm not entirely sure.
When the TextField is set to centre or right align it seems to work just fine, but when on left / start / justify it always seems to have that slight jitter.
Thanks in advance! ~ I may post this to the Github repository as well
Edit: You can see that the cursor jitters only when it moves to the left of the textfield. When it is moving within the string it does not jitter at all. I was testing this on a simulated iPhone 11
This problem has two parts to it. First, the cursorOffset of the text_field.dart for whatever reason has a negative x value.
This causes the cursor to be jammed into it's container making the width look weird. Second, the TextStyle.height property causes the cursor to jump.
I figured out how to fix this thanks to Pavel!
TextField - Font Size 50.0 / Height 1.30
https://imgur.com/gallery/G9bkcIf
TextField - Font Size 20.0 / Height 1.30
https://imgur.com/gallery/x7a5nzM
Fix Cursor Offset
The cursorOffset value is stored within the text_field.dart file. In
order to edit it, you should probably create a duplicate of the
text_field.dart file to customize. Here's how to do that,
although you might find better answers with a Google
Once you have the file ready to edit navigate to cursorOffset
within TargetPlatform.iOS. It should be around line 924-ish if
your file is unmodified.
Change the values of Offset(...) to 0 & 0 (x, y) respectively or
whatever you think is appropriate.
If you duplicated the text_field.dart file correctly then it should
be working right away!
Fix Cursor Jump
This fix is a lot less work. Simply add in a TextStyle widget to the
style: property of a TextField widget.
Then, just fill in the height property of your TextStyle widget
with whatever you think! I found 1.3 was a good median but pick the
best height for your fontSize. Here's some information on
height:
Github Issue Regarding This
https://github.com/flutter/flutter/issues/31661
I have a flow panel with many photo-widgets inside (gallery with random number of rows and columns, depends on screen size) for which I want to implement drag and drop behavior to change their order. I am using gwt-dnd library. Its FlowPanelDropController allows you to define your own positioner (delimiter) which shows the candidate location for dropping the dragged widget.
I want this positioner to be the empty space with defined width, and the challenging thing is to implement sliding animation effect for the when positioner is added and removed.
If you are a desktop Picasa app user you know what I mean: the target row slides both sides (little to the left, little to the right) extending the space between the items where you are going to drop a photo.
The whole thing is complex enough, but any help related to how to apply the animation for positioner attach/detach is appreciated. Maybe I need to use a different approach (e.g., use GWT native dnd instead of gwt-dnd lib and no "positioners" at all) if you have any ideas how this could be helpful.
Thanks.
Well, I ended up overriding AbstractPositioningDropController (parent of FlowPanelDropController) and adding some extra features.
1) newPositioner() method now builds the Label, which is vertical space with some small width, height and decoration. This widget's element has constant id (say, "POSITIONER"), which helps to distinguish between multiple positioners if you plan to have several of them while navigating with a drag object over multiple drop targets. Also some transition CSS effects were applied to the Label, which will be responsible for handling animated extension of Label's width.
2) in onEnter() I do the following
...
removePositioner(getPositionerElement());
Widget positioner = newPositioner();
dropTarget.insert(positioner, targetIndex);
animatePositionerExtension();
where getPositionerElement() returns DOM.getElementById(POSITIONER)
At the same time removePositioner(..) resets the id of this element to something abstract and ideally should provide some animation before calling .removeFromParent(). But I didn't have enough time to properly debug this so ended up just removing the old positioner with no animation.
Method animatePositionerExtension() contains the code that changes the width of the positioner widget, so that CSS transition will catch that and provides animation.
All access to positioner widget in the class should be provided through updated methods.
3) onLeave() contains line removePositioner(getPositionerElement());
4) In the end of onMove() I added a couple of lines:
galleryWidget.extendHoveredRow(targetIndex - 1);
animatePositionerExtension();
where extendHoveredRow(hoveredWidgetOrdinal) implemented the logic to "limit" the sliding effect in the single line:
int rowHovered = -1;
public void extendHoveredRow(int hoveredWidgetOrdinal) {
int newRowHovered = getRowByOrdinalHovered(hoveredWidgetOrdinal);
if (rowHovered != newRowHovered) {
// adjust position of items in the previously hovered row
int firstInPreviouslyHoveredRow = (rowHovered - 1) * itemsInARow;
shiftFirstItemLeft(firstInPreviouslyHoveredRow, false);
rowHovered = newRowHovered;
// extend this row
int firstInThisRow = getOrdinalFirstInThisRowByOrdinal(hoveredWidgetOrdinal);
shiftFirstItemLeft(firstInThisRow, true);
}
}
This is in short how I did the thing. And still there's some room for improvements, like adding animated removal.
Again, it's all about overriding DropController and manipulations with elements inside the "gallery" widget. The benefit of this approach is that I remain in the gwt-dnd operations framework, and also reused a bunch of existent code.
Some notes:
CSS transition is not supported in IE pre-9, but this is unrelated to
this topic.
Put a transparent "glass" div on top of the Image widget if you use it
as a face of dragProxy. This will save you tons of time trying to
understand why either setting element's draggable to false, or
calling event.preventDefault() somewhere else, or other workarounds don't work in one or several browsers and the image itself is being dragged instead of the whole dragProxy widget.
Since I'm using gtk3 and gtkmm3 on embedded I would like to have the scrollbar of a scrolledwindow wider.
I tried many ways but couldn't find a working solution.
Particularly I had a partial result with the following lines of code:
Gtk::Scrollbar *p_tableScrollbar = mp_scrolledwindowTable->get_vscrollbar();
p_tableScrollbar->set_size_request(50, -1);
but while the frame of the scrollbar becomes bigger, the slider remains narrow and part of the scrollbar area.
Then I tried the CSS way with the code:
Glib::RefPtr<Gtk::CssProvider> r_cssProvider = Gtk::CssProvider::create();
r_cssProvider->load_from_data("* {\n -GtkRange-slider-width: 50;\n }\n");
but still no result.
If anybody knows how to obtain the result please help.
It's gtk not gtkmm but here you go.
http://www.gtkforums.com/viewtopic.php?f=3&t=988&p=195381#p195381
I am using GWT 2.4's new DataGrid in a project. I configured the DataGrid with a pagesize of 50.
The available screen is not big enough to display all items and thus a vertical scrollbar is shown (this is actually the main purpose for using a DataGrid in the first place).
I attached a SingleSelectionModel to the DataGrid in order to be able to select items.
This works fine so far.
However I also have another widget with which the user can interact. Based on that user action a item from the DataGrid should be selected.
Sometimes the selected item is not in the visible screen region and the user has to scroll down in the DataGrid to see it.
Is there any way to automatically or manually scroll down, so that the selected item is visible?
I checked the JavaDocs of the DataGrid and found no appropriate method or function for doing that.
Don't know if this works, but you could try to get the row element for the selection and use the scrollIntoView Method.
Example Code:
dataGrid.getRowElement(INDEX_OF_SELECTED_ITEM).scrollIntoView();
The answer above works pretty well, though if the grid is wider than your window and has a horizontal scroll bar, it also scrolls all the way to the right which is pretty annoying. I was able to get it to scroll down and stay scrolled left by getting the first cell in the selected row and then having it scroll that into view.
dataGrid.getRowElement(dataGrid.getVisibleItems().indexOf(object)).getCells().getItem(0).scrollIntoView();
Don't have time to try it out, but DataGrid implements the interface HasRows, and HasRows has, among other things, a method called setVisibleRange. You just need to figure out the row number of the item that you want to focus on, and then set the visible range from that number n to n+50. That way the DataGrid will reset to put that item at the top (or near the top if it is in the last 50 elements of the list backing the DataGrid). Don't forget to redraw your DataGrid.
Have you already looked at this? If so, I'd be surprised that it didn't work.
Oh, and since this is one widget talking to another, you probably have some messaging set up and some message handlers so that when the user interacts with that second widget and "selects" the item, the message fires on the EventBus and a handler for that message fixes up the DataGrid along the lines I've described. I think you'll have to do this wiring yourself.
My solution, a little better:
dataGrid.getRow(model).scrollIntoView();
I got a Out of bounds exception doing the above.
I solved it getting the ScrollPanel in the DataGrid and used .scrollToTop() and so on on the ScrollPanel. However, to access the ScrollPanel in the DataGrid I had to use this comment:
http://code.google.com/p/google-web-toolkit/issues/detail?id=6865
As Kem pointed out, it's annoying the "scrollToRight" effect after the scrollIntoView. After me, Kem's solution gives a better behaviour than the base one as usually the first columns in a table are the more meaningful.
I improved a bit his approach, which scrolls horizontally to the first column of the row we want to be visible, by calculating the first visible column on the left before applying the scroll and then scrolling to it.
A final note: Columns absolute left is tested against "51". This is a value I found "experimentally" by looking the JS values in the browser's developer tool, I think it depends on the table's style, you may need to change/calculate it.
Below the code:
public void scrollIntoView(T next) {
int index = datagrid.getVisibleItems().indexOf(next);
NodeList<TableCellElement> cells = datagrid.getRowElement(index).getCells();
int firstVisibleIndex = -1;
for(int i=0; i<cells.getLength() && firstVisibleIndex<0;i++)
if(UIObject.isVisible(cells.getItem(i)) && (cells.getItem(i).getAbsoluteLeft() > 51) && (cells.getItem(i).getAbsoluteTop() > 0))
firstVisibleIndex = i;
cells.getItem(firstVisibleIndex>=0? firstVisibleIndex : 0).scrollIntoView();
}
In GTK (or pygtk or gtkmm...)
How can I detect that an application window has been manually resized by the user, as is typically done by dragging the window's edge?
I need to find a way to differentiate manual resizes from resizes that originate from gtk, such as changes in window content.
Have you tried connecting to the GDK_CONFIGURE event?
Check out this example under the
"Moving window" section. The example shows a callback doing something when the window is moved, but the configure event is a catch-all for moving, resizing and stack order events.
I managed to pull this off by watching for size_allocate and size_request signals on the GtkWindow. If size_request ever got smaller, I called resize(1,1). If size_allocate was ever bigger than expected, I turned the system off.
One thing I made sure to handle was size_request returning big, then small, and having size_allocate be big and then small. I don't know if this is possible, but I fixed it by making sure to only decrease the expected values for size_allocate when I got a smaller size_allocate, not when I got a smaller size_request.
Make sure that your size_request handler comes after the base class' handler so that you get the right values. I did this by overriding the method and then calling the base class method first.
I've tried this in both 1 and 2 dimensions and it seems to work either way.
In my case I was trying to distinguish between a user resizing a Gtk.Paned from the user resizing the whole window. Both emitted the notify::position signal.
My solution was, since I can't know if the user is resizing the window from the widget, reverse what I wanted to know. Record if the user has re-positioned the widget and ignore updates if the user didn't initiate them on my widget.
That is to say, instead of testing "if window being resized" I recorded the button-press-event and button-release-event's locally so I could instead test "if widget being re-positioned"
from gi.repository import Gtk
class MyPaned(Gtk.Paned):
_user_activated = False
def on_position(self, _, gparamspec):
if self._user_activated:
# widget touched
else:
# window resized (probably)
def on_button_press(self, *_):
self._user_activated = True
def on_button_release(self, *_):
self._user_activated = False
dev __init__(self, *args):
super(MyPaned, self).__init__(*args)
self.connect('notify::position', self.on_position)
self.connect('button-press-event', self.on_button_press)
self.connect('button-release-event', self.on_button_release)
Effectively by recorded when the user started and ended interacting with my widget directly, I could assume the rest of the time was due to the window being resized. (Until I find more cases)
In PyGTK, I've always watched for the expose_event for a window resize, then use the get_allocation method to get the new size.
You may be able to throw something together by using gdk_window_get_root_origin to get the top left corner of the window and gdk_window_get_geometry to get the width and height. Then you could hook a callback into the GDK_BUTTON_PRESS_MASK and check to see if the button press occurs near/on one of the edges of the window.
Of course, this seems quite hackish and it really bothers me that I couldn't find some simple way in the documentation for GdkWindow to do this. There is a gdk_window_begin_resize_drag function which really makes me think there's a cleaner way to do this, but I didn't see anything more obvious than my answer.