pcb

hid/gtk: set cursor position labels size

Bug #1354662 reported by Sergey Alyoshin on 2014-08-09
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gEDA project
Wishlist
Unassigned
pcb
Medium
Bert Timmerman

Bug Description

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.

tags: added: gtk-gui
Bert Timmerman (bert-timmerman) wrote :

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.

Changed in pcb:
status: New → In Progress
status: In Progress → Triaged
importance: Undecided → Medium
milestone: none → next-bug-release
Traumflug (mah-jump-ing) on 2015-09-27
Changed in geda-project:
importance: Undecided → Wishlist
status: New → Triaged
Changed in pcb:
assignee: nobody → Bert Timmerman (bert-timmerman)
Changed in pcb:
milestone: next-bug-release → future-bug-release
Changed in pcb:
status: Triaged → In Progress
Chad Parker (parker-charles) wrote :

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) wrote :

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

Bert Timmerman (bert-timmerman) wrote :

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) 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.

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

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?

Changed in pcb:
milestone: pcb-4.1.1 → pcb-4.2.1
Chad Parker (parker-charles) wrote :

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers