Maximizing window causes info panel to open partially #37463

New Issue

gandalf3 · 2013-11-15T04:15:41+01:00

gandalf3 commented

2013-11-15 04:15:41 +01:00

System Information
Archlinux 64bit with KDE

Blender Version

Broken: Blender 2.69 from the Arch repos

Short description of error

Full screening blender makes the info window drop down partway.
This is a very small annoyance, but it is still annoying closing it back up every time I maximize blender.

Exact steps for others to reproduce the error

Start blender.
Maximize the blender window. The info panel will end up partway down. If it started full screen, unfullscreen it and then maximize/fullscreen again.

**System Information** Archlinux 64bit with KDE **Blender Version** Broken: Blender 2.69 from the Arch repos **Short description of error** Full screening blender makes the info window drop down partway. This is a very small annoyance, but it is still annoying closing it back up every time I maximize blender. **Exact steps for others to reproduce the error** 1. Start blender. 2. Maximize the blender window. The info panel will end up partway down. If it started full screen, unfullscreen it and then maximize/fullscreen again.

gandalf3 commented

2013-11-15 04:15:41 +01:00

Changed status to: 'Open'

gandalf3 commented

2013-11-15 04:15:41 +01:00

Added subscriber: @gandalf3

Thomas Dinges commented

2013-11-15 04:48:41 +01:00

Added subscriber: @ThomasDinges

Thomas Dinges commented

2013-11-15 04:48:41 +01:00

Confirmed on OS X.

We should somehow glue the info bar to the top. Sometimes (after a new startup.blend has committed) or on some screens, there is a gap too.

Confirmed on OS X. We should somehow glue the info bar to the top. Sometimes (after a new startup.blend has committed) or on some screens, there is a gap too.

CodeManX commented

2013-11-19 01:40:47 +01:00

Added subscriber: @CodeManX

CodeManX commented

2013-11-19 01:40:47 +01:00

Not sure if i should create a new report for this:

Operator log is often not scrolled to the bottom and behaves weird on area resize (scrollbar should stick to the end to show latest entry by default).

Not sure if i should create a new report for this: Operator log is often not scrolled to the bottom and behaves weird on area resize (scrollbar should stick to the end to show latest entry by default).

Anthony Edlin commented

2013-11-21 23:04:37 +01:00

Added subscriber: @AnthonyEdlin

Bartosz Moniewski commented

2013-11-25 19:07:38 +01:00

Added subscriber: @BartekMoniewski

Bartosz Moniewski commented

2013-11-25 19:07:38 +01:00

@ThomasDinges is right. If editor height is as tall as header this editor shouldn't scale.

Anthony Edlin commented

2013-11-25 20:38:13 +01:00

Yeah it's a pretty old problem going back a long ways. Currently the screen scaling code just doesn't consider what type of area is being scaled. It's just inherent in the current design of screen verts/edges that don't link to the areas at all.

It may be possible to change the design slightly. Such as make screen edges more prominent and include links to what is on each side of the split edge, another edge or an area. Then you could traverse the screen edges in some scaling algorithm and scale based on the type of areas traversed.

It might also be better to just replace the design with something else entirely. The screen verts/edges code is pretty old, in fact, the structs in the header file go back to the initial revision in 2002. But a bigger redesign would touch a lot more code.

Either way it's not really a small change. Any change would probably require touching area drawing code, area move/split ops, resize/scaling code, and dna screen vert/edge structs would probably have to change, which would require proper setup for backwards/forward compatibility. All this work for just this issue, which isn't that big in the scheme of things. If there were more things to fix in the UI with a bigger design change it would maybe be more worth it.

I looked into this a long time ago, but there wasn't really any action in the UI at the time, so it's kind of been out of my mind. I'll try to ponder this again now and see if I can think of an easier way to do this or if there are more benefits to a larger design change.

Yeah it's a pretty old problem going back a long ways. Currently the screen scaling code just doesn't consider what type of area is being scaled. It's just inherent in the current design of screen verts/edges that don't link to the areas at all. It may be possible to change the design slightly. Such as make screen edges more prominent and include links to what is on each side of the split edge, another edge or an area. Then you could traverse the screen edges in some scaling algorithm and scale based on the type of areas traversed. It might also be better to just replace the design with something else entirely. The screen verts/edges code is pretty old, in fact, the structs in the header file go back to the initial revision in 2002. But a bigger redesign would touch a lot more code. Either way it's not really a small change. Any change would probably require touching area drawing code, area move/split ops, resize/scaling code, and dna screen vert/edge structs would probably have to change, which would require proper setup for backwards/forward compatibility. All this work for just this issue, which isn't that big in the scheme of things. If there were more things to fix in the UI with a bigger design change it would maybe be more worth it. I looked into this a long time ago, but there wasn't really any action in the UI at the time, so it's kind of been out of my mind. I'll try to ponder this again now and see if I can think of an easier way to do this or if there are more benefits to a larger design change.

Bartosz Moniewski commented

2013-11-25 22:20:09 +01:00

I suppose that can be solved without linking areas to editor types. We get size of screen and every area and check which elements are "one header" tall. Then exclude them from scaling operation. Converting pixels to DPI points will be required to do this.
Nevertheless this concept will work only when info bar will stay one header tall. Check this: #37450 (Tool settings panel location in the UI) According to this discussion we can assume that info bar will be 2 to 3 times higher than actual. Then Krash scenario will come true eventually.

I suppose that can be solved without linking areas to editor types. We get size of screen and every area and check which elements are "one header" tall. Then exclude them from scaling operation. Converting pixels to DPI points will be required to do this. Nevertheless this concept will work only when info bar will stay one header tall. Check this: #37450 (Tool settings panel location in the UI) According to this discussion we can assume that info bar will be 2 to 3 times higher than actual. Then Krash scenario will come true eventually.

Anthony Edlin commented

2013-11-26 01:25:53 +01:00

Realistically, you could just add a hack that would just go through after the current scale algorithm and just scale back any verts for the info space type. That would probably be less then 30 lines of code. In fact, here is the code that does it.

	/* scale back info header areas if we scaled up */
	if (facy > 1.0) {
		for (sa = sc->areabase.first; sa; sa = sa->next) {
			if(sa->spacetype == SPACE_INFO) {
				int size = sa->v2->vec.y - sa->v1->vec.y;
				ScrEdge *se = screen_findedge(sc, sa->v4, sa->v1);
				
				/* get size if we were to rescale back down */
				tempf = ((float)size) / facy;
				size = (short)(tempf + 0.5);
			
				/* raise edge, but make sure it's not an edge along the bottom of window*/
				if (se && sa->v1 != sa->v2 && sa->v1->vec.y > 0) {
					int yval;
					
					select_connected_scredge(sc, se);
					
					/* all selected vertices get the right offset */
					yval = sa->v2->vec.y - size;
					sv = sc->vertbase.first;
					while (sv) {
						/* if is a collapsed area */
						if (sv != sa->v2 && sv != sa->v3) {
							if (sv->flag) sv->vec.y = yval;
						}
						sv = sv->next;
					}
				}
			}
		}
	}

Doing this actually solves this particular issue. But I personally wouldn't want to do this, as it only solves this one problem and in a very brute force manner. You can quickly break it down if you try to do non-standard areas. If people always do this type of stuff, then blender source will become unmaintainable. A more general solution and consideration of the entire system is needed I think, which is the part I was trying to think about in my previous comment.

Realistically, you could just add a hack that would just go through after the current scale algorithm and just scale back any verts for the info space type. That would probably be less then 30 lines of code. In fact, here is the code that does it. ``` /* scale back info header areas if we scaled up */ if (facy > 1.0) { for (sa = sc->areabase.first; sa; sa = sa->next) { if(sa->spacetype == SPACE_INFO) { int size = sa->v2->vec.y - sa->v1->vec.y; ScrEdge *se = screen_findedge(sc, sa->v4, sa->v1); /* get size if we were to rescale back down */ tempf = ((float)size) / facy; size = (short)(tempf + 0.5); /* raise edge, but make sure it's not an edge along the bottom of window*/ if (se && sa->v1 != sa->v2 && sa->v1->vec.y > 0) { int yval; select_connected_scredge(sc, se); /* all selected vertices get the right offset */ yval = sa->v2->vec.y - size; sv = sc->vertbase.first; while (sv) { /* if is a collapsed area */ if (sv != sa->v2 && sv != sa->v3) { if (sv->flag) sv->vec.y = yval; } sv = sv->next; } } } } } ``` Doing this actually solves this particular issue. But I personally wouldn't want to do this, as it only solves this one problem and in a very brute force manner. You can quickly break it down if you try to do non-standard areas. If people always do this type of stuff, then blender source will become unmaintainable. A more general solution and consideration of the entire system is needed I think, which is the part I was trying to think about in my previous comment.

blender-admin commented

2013-12-10 13:54:33 +01:00

This issue was referenced by blender/blender-addons-contrib@91d8519c47

This issue was referenced by blender/blender-addons-contrib@91d8519c478252f06f4043a68060f5c60ed6c6a1

blender-admin commented

2013-12-10 13:54:33 +01:00

This issue was referenced by 91d8519c47

This issue was referenced by 91d8519c478252f06f4043a68060f5c60ed6c6a1

Campbell Barton commented

2013-12-10 13:55:48 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue