With this patch there are too many theme options in preferences.
It is possible to use the colors from header, and avoid creating footer option in all the spaces.

edit:
No idea how to edit or delete inline comments. Just ignore them.
issues resolved with updated D4611

I think it's probably fine to re-use the same theme colors in header and footer.

If not, we are really overcrowding our themes unnecessarily I think.

@Brecht Van Lommel (brecht) @Pablo Vazquez (pablovazquez) thoughts?

And if you run it, can you check to see if the solution for the tools properties region is acceptable? With the header up and down change in size (resolution scale 1).

@George Vogiatzis (Gvgeo) Tested, it seems to work correct.

As for your question, I have no idea what you are referring to.

I was referring to the two comments I added in code above.
But that's fine, doesn't matter for now. I don't expect to stay the way it is, right now in this patch.

It's about when you click save as, the options on the lower left panel /* Tool props (aka operator) region */, can be moved up and down.
I changed the maximum height it can go up. And now is also different when the header is up or down.
Don't forget that in other places there are way more options and the window may be smaller.

To me this works great.

My main questions are:

• Do we really need separate theme entries for headers and footers, or could we just re-use the same theme for both?
• Is it a good idea or not to add the capability to all editors, if we just intend to actually add it to a handful of them?

I think we might add a footer to Text Editor, Clip Editor & File Browser. Can't think of any other editors where we are likely to add it, but even so, the solution in this patch may be the correct approach.

Adding it as a generic region that all editors can possibly use is fine. For the theme colors I would not add a separate entry, and just reuse the header colors. We already have too many of those.

@George Vogiatzis (Gvgeo) If you make the footer use the header theme colors, we could do final review. Again, thanks for the great contribution.

I tried to solve the problem In the two inline comments, and found bugs.
I updated D4611 with the fixes.
If I update this patch, for a proper review, now will need these fixes first. Or it won't run.

I mentioned the need of a footer region plenty of times, glad it's finally being done.

Seems like all issues have been addressed, but yes, no new theme settings please!

In D4601#104899, @William Reynish (billreynish) wrote:

The updated version seems good to me, using the header theme.

Ops... I just updated the summary and the comments.
Should be still marked as planned changes.
I have to wait for the D4611 to update the diff.

I can't see what D4611 has to do with this task - is there something in there that is blocking this patch from being completed?

Well, ok, it’s just that things can get a bit confusing I think if they are spread out over several patches, but maybe it’s fine.

@Jacques Lucke (JacquesLucke) Can you take a look at these two patches? Thanks

Personally, I'd prefer to see a decision on T61244 before adding footers...

I think the foot appearing on the opposite side of the header is fine. Removing bottom header is a separate discussion, this is trivial to adapt if needed so I see no reason to have it blocked.

In D4601#105197, @Brecht Van Lommel (brecht) wrote:

I think the foot appearing on the opposite side of the header is fine.

Always be opposite side or just the default setting?
Right now footer, can flip top or bottom independent from header.

It's fine as is in the patch I think. Don't really have a preference for this being automatic or not.

As long as the header is at the top and footer as at the bottom by default, I don't really care if you can move them or not. When testing this patch, everything seems to work just fine if you do flip things around, so that's good.

Before you start review the code, consider this.

I intend to update the patch with the same diff for this part, after you commit D4611.
Just to make sure there is no conflict. updated.

~~~~

Trying to be nicer, added couple inline comments to help with the review (although the whole patch is copy-paste).
Ignore the 2 comments marked as done (wish I could delete them).
Keep in mind that I have roughly 4 months in total experience, including python.
As such I might have comment on things you find easy. But if it helps, let me now.

~~~~
Offtopic:
I first started reading blender code about a month ago, but after 2 weeks of no progress, I gave up on blender.
Couple days later @Pablo Vazquez (pablovazquez) mention @Jacques Lucke (JacquesLucke)'s video in monday's stream, and decided to try again using it as a guide.
So... now you know who to blame, if I give you hard time reviewing the code.

Yes, dragging headers to close them was removed in 2.8, because many users would do this by mistake. You can still right-click and toggle them on/off, you you can't drag to close them anymore.

The two issues I still have are about:
a. ED_area_newspace (see the two inline comments added with this comment).

b. versioning_280.c -> Line 2977

ListBase *regionbase = (sl == sa->spacedata.first) ? &sa->regionbase : &sl->regionbase;

@Jacques Lucke (JacquesLucke)'s comment

is it correct, that sa->spacedata.first->regionbase is not "fixed"? I'd think the footer should be added everywhere.

Looks correct to me. This is what I found.

	/* A list of space links (editors) that were open in this area before. When
	 * changing the editor type, we try to reuse old editor data from this list.
	 * The first item is the active/visible one.
	 */
	/** #SpaceLink. */
	ListBase spacedata;
	/* NOTE: This region list is the one from the active/visible editor (first item in
	 * spacedata list). Use SpaceLink.regionbase if it's inactive (but only then)!
	 */
	/** #ARegion. */
	ListBase regionbase;

I'd think the footer should be added everywhere.

I have no idea what you mean with "everywhere". It is added in every SPACE_TEXT it can find, after header. Even if the Space is inactive. Is there a problem I cannot see?

The whole versioning part is direct copy from the RGN__TYPE_NAV_BAR added in 280, 29.

To me it looks like there are len(sa->spacedata) + 1 region bases in every area.
One in the sa->regionbase and the others in sl->regionbase.

It looks like, you would need to insert the footer in two different region bases, when it is currently active. I could be wrong though. Maybe @Brecht Van Lommel (brecht) or @Julian Eisel (Severin) can tell what's right.

I looked at ED_area_newspace, it does not seem to be the case, it swap regionbase and clears old data.
(there is 1 extra region base, but is unused)

Will fix the footer header order later.

Looks good to me now, code wise.

I found one versioning issue. When I'm in the default .blend file, and then switch to the Scripting workspace, the footer is not there.
Can you reproduce that?

I believe the issue is, that every workspace also stores a bScreen.
I just tried simply iterating over the workspaces in the versioning code, but got a segfault. Don't know why that is. Maybe the pointers are not correctly linked when the versioning code runs?
@Brecht Van Lommel (brecht), how should this be done?

Yeah, can confirm. I failed to check that part.
previous diff works fine.
Will try to understand why it stopped working.

All screens are in bmain->screens, so there must be another reason for this. I should not be needed to go from workspace to screen.

Regarding the crash if it would have been needed: datablock pointers are not resolved yet in do_versions() only in do_versions_after_linking().

I found the problem, but cannot say I know the reason.
No region will work after RGN_TYPE_WINDOW.

But with BLI_addhead now will reverse the alignment order in old space areas.

Will revert versioning file to add after header again.

Tried couple times the workspaces, but don't get any error.

So much about we don't depend on the order of regions -.-
Will test it again tomorrow, and then we can merge it, hopefully :)

I missed that comment, region order does indeed matter.

Yes.