GtkTreeViewColumn resizing based on contents - perl

So it turns out that we'd like to use fixed height mode, because it's faster and it doesn't constantly try to update the treeview — we saw a significant decrease in CPU use with a table that, unfortunately, may contain a few thousand rows and some 20-ish columns.
Oddly enough, merely turning off autosizing on all the columns doesn't help, one needs to set fixed height mode too.
But of course, the cell contents are of varying length (they're text and numbers), and it would be nice to update the column size time to time (ie. when I know they should be updated, and not all the time like autosizing unfortunately does).
So what I need is being able to figure out that the newly inserted row / cell has insufficient size (I guess something to do with the GtkCellRendererText and Pango will come handy), and then resize the affected GtkTreeViewColumn using set_fixed_width. I've looked at the source of GTK+ to see what they do when autosizing, but couldn't really make head or tails of it. My main problem here is getting to the text layout and/or the cell size requirements from a given TreeView/ListStore/iter combination.
I use perl-Gtk2, but answers are welcome in any commonly used language.

Related

How do I reduce the area of the bar graph and increase that of the text in Grafana? (make labels more readable)

I have long strings as labels which is the full identifier of each deployment. How do I increase the area that the strings occupy and reduce the area for the bar graphs in Grafana.
After many attempts, this is the closest that I have come to displaying label strings in a way that is readable. Ideally a table would also be nice, but I was unable to show a table in which the labels form a column (it always took the row)
You can't change that size. I would rather focus how to make labels shorter. (I would say that "max_Sum/" is not necessary there)
IMHO: the best option is to have a table panel for this - yes, you wasn't not able to achieve it, but you only need right query, result format + transformation eventually.

gtk treeview column resizing and horizontal scrollbar

I have a gtk treeview (inside a GtkScrolledWindow) with two columns.
If I set both columns to the default sizing policy, I have a horizontal scrollbar for the treeview but the columns can't be sized down by the user, which is impractical.
If I set both columns to setSizing Fixed, fixed width 120, I get a nice display and the columns can be resized, but there is no horizontal scrollbar in the treeview (since the columns size down to fit in the width of the treeview I guess).
If I set the first column to setSizing fixed, fixed width 120, the second one to automatic, only the second column is displayed (???).
I would like that by default the first column takes let's say at most 60% of the display, the second column can go all the way and I have a horizontal scrollbar. Certainly I want the user to be able to resize them up or down, not as with the default policy, that you can resize them down!
That's why I tried the first column fixed, the second automatic, it was promessing but I don't understand why the first column is not displayed at all in that configuration.
I add the cell renderers with packstart true, I tried false but it didn't change anything, also I tried setting the expand for the columns to true or false, which didn't have any effect.
Note I'm using the gtk2hs haskell bindings but I'm certain it would be the same in any other gtk binding. Just mentioning if people will ask for code samples.
I'm pretty sure this is a common problem... I'd say nautilus is fixing it the way I'd like to fix it, but I think digging in the nautilus source is going to be quite long...
EDIT well i've discovered the cell renderer's ellipsize setting also has an effect. Setting it to end for the first column and none for the second should be what i want but then the first column is very small and cannot be expanded through resize...
EDIT2 well for now i've moved to word wrapping for the cell renderer, that way i don't have to bother with a horizontal scrollbar... Still curious for the solution to that question though.

GTK+ 3: Restore TreeViewColumn widths without making them behave as if manually sized

I have a TreeView whose columns are all expandable with fixed-mode sizing. I would like to restore the widths of the columns when the user restarts the app. It seems that calling set_fixed_size is the way to do this, but:
If I set only the widths of the columns that the user resized, then the actual column widths end up different from what they were before.
If instead I set all column widths explicitly, then all columns behave as though they had been resized by the user, which is not ideal.
Is there a way to restore the column widths that gets around these problems?
It turns out that expand interferes with fixed_width. In my case, the solution was to set fixed_width and expand=false on columns that the user resized, and expand=true on the others.

TreeViewer no longer sizes properly when using StyledCellLabels

I was using a JFace TreeViewer perfectly well for a while.
It has a bunch of branches of varying lengths, but at the end of the day, the entire tree stretched to the size of its longest string. This was great.
Recently, I decided that the TreeItems labels should have some style to them fonts and highlights.
The trouble, is that the new fonts are a bit larger and stretch the size of the overall string. It seems that the Tree or TreeViewer doesn't recognize this expansion and still judges the size of the label by the amount of small characters in it. The result is that I get a TreeViewer with a horizontal scrollbar, which is highly inconvenient because now my users will have to scroll across each tree, rather than just being to quickly glance at the data.
Does anyone know how to get the Tree to properly fit the length of the longest string, and take into account the added length of the styling, etc?
Thanks!
While this is not a complete answer, I hope it will help jogs someone's memory who has more advanced knowledge on this:
When I set the font to the ViewerCell object to a font that is wide, the entire row properly resizes. It seems that the Tree measures its width by checking the length of the text and the font, but disregards the Style Ranges.

Get image width and height in pixels

so i have looked at a couple other questions like this and from what i saw none of the answers seemed to answer my question. I created a program that creates ASCII art, which is basically a picture of text instead of colors. the way i have the program set up at the moment you have to manually set the Width and Height of the pixels. If the width and height of the pixels is too large it simply wont work. so basically what i want to do is have a function to automatically set the width and height to the size of the picture. http://www.mediafire.com/?3nb8jfb8bhj8d is the link to the program now. I looked into pixel grabber but the constructor methods all needed a range of pixels. I also have another folder for the classes, http://www.mediafire.com/?2u7qt21xhbwtp
on another note this program is incredibly inefficient, i know that it is inefficient in the grayscaleValue() method, but i dont know if there is any better way to do this. Any suggestions on this program would be awesome too. Thanks in advance! (this program was all done on eclipse)
After you read the image into your BufferedImage, you can call getWidth() and getHeight() on it to get this information dynamically. See the JavaDocs. Also, Use a constructor for GetPixelColor to create the BufferedImage once and for all. This will avoid reading the entire file from disk for each channel of each pixel.
For further code clean up, change series of if statements to a switch construct, or an index into an array, whichever is more natural. See this for an explanation of the switch construct.
One last comment: anything inside a class that logically represents the state of an object should be declared non static. If, say, you wanted to render two images side by side, you would need to create to instances if GetPixelColor, and each one should have its own height and width attributes. Since they're currently declared static, each instance would be sharing the same data, which is clearly not desireable behavior.