hid/gtk: set cursor position labels size

[Sergey Alyoshin]

Currently absolute and relative cursor position labels size is updated via
callback on size-request signal. This will change it to set cursor position
labels size based on grid units and PCB size.

[Bert Timmerman (bert-timmerman)]

Hi,

I pushed your patch to upstream topic branch LP1354662 for anyone to test.

I see that the relative cursor position label widget resizes and window size follows, and is padded generally.

Sometimes this is leads to the absolute position label widget to be truncated and a negative padding occurs here.

Kind regards,

Bert Timmerman.

[Chad Parker (parker-charles)]

I've reviewed this patch. I rebased it against master, and I fixed a small oversight in that the relative position format string wasn't being used in the original

I agree that it's a good idea to set the width of the box based on the workspace dimensions and the grid units.

I don't like that we have to test for changes every time we update the labels.

I would suggest using the code for computing size, but move it to the callbacks that were deleted in gui-top-window.c

[Chad Parker (parker-charles)]

I pushed a second commit that does what I've suggested. I think it would now be okay to merge.

[Bert Timmerman (bert-timmerman)]

Hi Charles,

Look at the screen shot from my 800x600px laptop (attached) ... the coord widget and mil/mm button fall over the right edge.

The application should respect available real estate.

Kind regards,

Bert Timmerman.

[Chad Parker (parker-charles)]

Well darn. I'm not sure that I can test on such a small screen. I can't actually resize the window to be that small, the WM won't let me.

Two questions:
1. Did the original patch do that too?
2. What does it look like in master?

[Sergey Alyoshin (alyoshin-s)]

On Sun, Feb 4, 2018 at 1:41 AM, Chad Parker <email address hidden> wrote:
> Well darn. I'm not sure that I can test on such a small screen. I can't
> actually resize the window to be that small, the WM won't let me.

You can try Xnest, but pcb should be compiled without OpenGL.

Xnest :2 -geometry 320x240
DISPLAY=:2 pcb

> Two questions:
> 1. Did the original patch do that too?
> 2. What does it look like in master?

[Chad Parker (parker-charles)]

This is happening because pcb is calculating the maximum possible width of the label, and forcing gtk to allocate that much space, instead of allowing the widget to dynamically resize with the window.

The conundrum here is that this behavior is actually intentional. That's the entire purpose of the functions "absolute_label_size_req_cb" and "relative_label_size_req_cb".

I'd still like to see what the widget looks like normally, and with the original patch.

I've rebased this branch against master and added a new commit. The commit basically allows the text of the label to wrap when it's computing the new size. Since this callback is only executed when the units change or the PCB size is changed, you can't go from unwrapped to wrapped by resizing the window. In order to do that, we would have to switch the widget back to a dynamically allocated size during the resize, and then return it to a static allocation afterwards. Some quick Googling hasn't produced any gtk events that I can tie into to make this happen. I've tried tweaking with the size-request signal a little bit, but so far haven't had success.

So, I still can't actually test this, but I think I might have fixed it. Could you please give it a try and see if it solves the problem?

[Bert Timmerman (bert-timmerman)]

Hi,

Just rebased this topic branch and tested on a 800x600 px resolution screen.

Th topic branch doesn't seem to improve the situation w.r.t. the behaviour in pcb-4.2.0, which seems to do the right thing when ticking the checkbox for "Alternate window layout to allow smaller horizontal size".

I'm marking this one as "won't fix".

Kind regards,

Bert Timmerman.