git annotated tags

[Alexander Holler]

Hello,

in order to find out which layout changes in wxMSW have happened in
2.9.1 and 2.9.2 (in 2.9.1 a layout with several sizers, many controls
and fixed fonts (negative sizes) changed it's vertical size from 738 to
754 pixels and with 2.9.2 it even has changed to 794 pixels, making the
existing layout unusable on many screens), I'm currently digging through
the git repository.

While doing that, I've noticed that the very handy "git describe"
doesn't work.

It would be nice, if annotated tags could be used instead of simple
tags. Changing the existing tags to annotated tags could be considered
too, that doesn't change the commit history.

Regards,

Alexander

Btw., in the changelog for 3.0, there is mentioned that if someone uses
negative sizes for fonts (with wxMSW), he should mentioning that on this
list. Here I am. I'm using negative sizes for fonts in order to have a
fixed layout.

PS: Please don't start a discussion that I should not rely on fixed
sizes (for fonts and/or controls). While such is doable for many
layouts, it has it's limits when a lot of controls should be displayed
at once with a limited screen size.

[Vadim Zeitlin]

On Fri, 01 Feb 2013 11:34:51 +0100 Alexander Holler wrote:

AH> While doing that, I've noticed that the very handy "git describe"
AH> doesn't work.

No, git svn doesn't create git tags for svn tags.

AH> It would be nice, if annotated tags could be used instead of simple
AH> tags.

It doesn't even create simple tags, in fact. It would be nice if it did
but there is probably some good reason it doesn't...

AH> Btw., in the changelog for 3.0, there is mentioned that if someone uses
AH> negative sizes for fonts (with wxMSW), he should mentioning that on this
AH> list. Here I am. I'm using negative sizes for fonts in order to have a
AH> fixed layout.

But why do you need to use negative height for this? Using
wxFont::SetPixelSize() with positive argument still results in fixed
layout, it just specifies the cell size instead of text size. Do you
absolutely need the latter and, if so, why?

Thanks,
VZ

[Alexander Holler]

Am 01.02.2013 13:18, schrieb Vadim Zeitlin:
> On Fri, 01 Feb 2013 11:34:51 +0100 Alexander Holler wrote:
>
> AH> While doing that, I've noticed that the very handy "git describe"
> AH> doesn't work.
>
> No, git svn doesn't create git tags for svn tags.
>
> AH> It would be nice, if annotated tags could be used instead of simple
> AH> tags.
>
> It doesn't even create simple tags, in fact. It would be nice if it did
> but there is probably some good reason it doesn't...

Hmm, I'm not sure what role git svn plays here. On my side it plays no
role, I've cloned directly from github and none of the tags there seem
to be an annotated tag (they have to be created using git tag -a instead
of just git tag).

>
> AH> Btw., in the changelog for 3.0, there is mentioned that if someone uses
> AH> negative sizes for fonts (with wxMSW), he should mentioning that on this
> AH> list. Here I am. I'm using negative sizes for fonts in order to have a
> AH> fixed layout.
>
> But why do you need to use negative height for this? Using
> wxFont::SetPixelSize() with positive argument still results in fixed
> layout, it just specifies the cell size instead of text size. Do you
> absolutely need the latter and, if so, why?

Sorry, I'm not sure why I had to use the cell size instead of the text
size (on msw). But I'm pretty sure there was a reason, otherwise I
wouldn't have used such ugly ifdefs like below ;)

-------------
#ifdef __WXMSW__
font.SetPixelSize(wxSize(0, -11));
#else
font.SetPixelSize(wxSize(0, 11));
#endif
-------------

If I would have to make an assumption, I would say I've used the cell
size, because the cell size might vary over different fonts but one and
the same text size and the cell size is used to calculate positions. But
thats just an assumption, the code I've written is several years old and
I can't remember the reason. My knowledge about how fonts are used to
calculate sizes, borders etc. is gone too. And a first look at the
commit log didn't give me hint, maybe a further deeper look will do.

Regards,

Alexander

[Vadim Zeitlin]

On Fri, 01 Feb 2013 16:14:33 +0100 Alexander Holler wrote:

AH> Am 01.02.2013 13:18, schrieb Vadim Zeitlin:

AH> > On Fri, 01 Feb 2013 11:34:51 +0100 Alexander Holler wrote:
AH> >

AH> > AH> While doing that, I've noticed that the very handy "git describe"
AH> > AH> doesn't work.
AH> >
AH> > No, git svn doesn't create git tags for svn tags.
AH> >
AH> > AH> It would be nice, if annotated tags could be used instead of simple
AH> > AH> tags.
AH> >
AH> > It doesn't even create simple tags, in fact. It would be nice if it did
AH> > but there is probably some good reason it doesn't...
AH>
AH> Hmm, I'm not sure what role git svn plays here.

The Github repository is svn mirror kept up to date by git-svn.

AH> Sorry, I'm not sure why I had to use the cell size instead of the text
AH> size (on msw). But I'm pretty sure there was a reason, otherwise I
AH> wouldn't have used such ugly ifdefs like below ;)
AH>
AH> -------------
AH> #ifdef __WXMSW__
AH> font.SetPixelSize(wxSize(0, -11));
AH> #else
AH> font.SetPixelSize(wxSize(0, 11));
AH> #endif
AH> -------------

My guess would be that you started without the ifdefs, then tested under
another platform and found that the code asserted there and added the
platform test. I could be wrong, of course.

Notice, however, that currently the code doesn't do the same thing under
MSW and other platforms. Ideal would be to provide some way to provide both
cell and text heights under all platforms but we don't have this way now,
so the recommended approach is to just use SetPixelSize(11) everywhere.

Regards,
VZ

[Bryan Petty]

On Fri, Feb 1, 2013 at 5:18 AM, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> It doesn't even create simple tags, in fact. It would be nice if it did
> but there is probably some good reason it doesn't...

Indeed, it doesn't, likely because tags are in fact branches in SVN.
git-svn does create those branches for the tags though. The script we
use that pushes git-svn changes up to the mirror also automatically
uses the latest tag branch ref to create a simple tag since git-svn
doesn't like making that assumption. It would be required to
force-push a tag if any tag was updated in SVN, and I'm betting that's
why it doesn't bother with it at all.

So the tags are there thankfully, but as Alexander points out, they
aren't annotated. Although, git typically looks at the tag's head
commit message instead with various log commands (see "git tag -ln")
if it's not annotated. Of course, there's nothing wrong with this
since it's exactly what we use in the commit message when we create a
tag in SVN.

I just want to clarify though that Alexander might also be trying to
describe a commit on master which isn't contained in any tag at all
(this happens frequently on stable branches too). In this case, it is
perfectly normal to see something like "fatal: No tags can describe
'236cff7...'." Using "git describe --all" will clarify exactly which
refs the given commit is actually contained in, confirming if it's
only on a specific branch and not in any tags.

Anyway, it's not a bad idea to add the relevant sections of
docs/changes.txt to tag annotations when we get around to switching to
git (also think of it like a release announcement). So that's
something to keep in mind, but not really anything we can do about it
right now.

Regards,
Bryan Petty

[Alexander Holler]

Am 01.02.2013 22:02, schrieb Bryan Petty:

> I just want to clarify though that Alexander might also be trying to
> describe a commit on master which isn't contained in any tag at all
> (this happens frequently on stable branches too). In this case, it is
> perfectly normal to see something like "fatal: No tags can describe
> '236cff7...'." Using "git describe --all" will clarify exactly which
> refs the given commit is actually contained in, confirming if it's
> only on a specific branch and not in any tags.
>
> Anyway, it's not a bad idea to add the relevant sections of
> docs/changes.txt to tag annotations when we get around to switching to
> git (also think of it like a release announcement). So that's
> something to keep in mind, but not really anything we can do about it
> right now.

I just wasn't sure why there are no annotated tags and wanted to mention
that git does make a difference between (simple) tags and annotated tags.

I'm used to just call "git describe" to see which version I've checked
out, therefor I have noticed it.

Regards,

Alexander

PS: The commit between 2.9.1 and 2.9.2, which added the first set of
additional (vertical) pixels to the layout on wxMSW (using Windows 7 and
Aero) is

b5791cc7af207a74deb0bea60f99cd97429bcb8c

I haven't had a deep look at what it does in particular, but font
calculations seem to be the culprit. This is also the commit which adds
the assert on negative font heights (which got removed later on again,
for downward compatibility as I assume).

I still haven't done a search for the second commit (between 2.9.2 and
2.9.3) which adds more vertical pixels to the layout, but I will post it
here (using another subject), if I know it (and what happened in
particular). Maybe there are more people like me, which still haven't
updated to 2.9.x before and it might help them if I describe the problem
(and maybe have found a solution).

[Vadim Zeitlin]

On Sat, 02 Feb 2013 02:28:30 +0100 Alexander Holler wrote:

AH> PS: The commit between 2.9.1 and 2.9.2, which added the first set of
AH> additional (vertical) pixels to the layout on wxMSW (using Windows 7 and
AH> Aero) is
AH>
AH> b5791cc7af207a74deb0bea60f99cd97429bcb8c

For future reference, that's http://trac.wxwidgets.org/changeset/59564

AH> I haven't had a deep look at what it does in particular, but font
AH> calculations seem to be the culprit. This is also the commit which adds
AH> the assert on negative font heights (which got removed later on again,
AH> for downward compatibility as I assume).
AH>
AH> I still haven't done a search for the second commit (between 2.9.2 and
AH> 2.9.3) which adds more vertical pixels to the layout, but I will post it
AH> here (using another subject), if I know it (and what happened in
AH> particular). Maybe there are more people like me, which still haven't
AH> updated to 2.9.x before and it might help them if I describe the problem
AH> (and maybe have found a solution).

I can understand that your layout would change if it depended on the font
size in pixels because of the cell/text height difference already
discussed. But I don't see why would it change because of the commit above
which doesn't seem to do anything.

Could you please explain how do you compute your layout, at least roughly?
I hope it's not a common problem (as I expect most people to just use
sizers and not compute their layout from the font sizes) but if we can fix
it to avoid unpleasant surprises after upgrading to 2.9 it would still be
nice.

Thanks,
VZ

[Alexander Holler]

Am 02.02.2013 02:41, schrieb Vadim Zeitlin:
> On Sat, 02 Feb 2013 02:28:30 +0100 Alexander Holler wrote:
>
> AH> PS: The commit between 2.9.1 and 2.9.2, which added the first set of
> AH> additional (vertical) pixels to the layout on wxMSW (using Windows 7 and
> AH> Aero) is
> AH>
> AH> b5791cc7af207a74deb0bea60f99cd97429bcb8c
>
> For future reference, that's http://trac.wxwidgets.org/changeset/59564
>
> AH> I haven't had a deep look at what it does in particular, but font
> AH> calculations seem to be the culprit. This is also the commit which adds
> AH> the assert on negative font heights (which got removed later on again,
> AH> for downward compatibility as I assume).
> AH>
> AH> I still haven't done a search for the second commit (between 2.9.2 and
> AH> 2.9.3) which adds more vertical pixels to the layout, but I will post it
> AH> here (using another subject), if I know it (and what happened in
> AH> particular). Maybe there are more people like me, which still haven't
> AH> updated to 2.9.x before and it might help them if I describe the problem
> AH> (and maybe have found a solution).
>
> I can understand that your layout would change if it depended on the font
> size in pixels because of the cell/text height difference already
> discussed. But I don't see why would it change because of the commit above
> which doesn't seem to do anything.

I'm still wondering too. ;)

> Could you please explain how do you compute your layout, at least roughly?
> I hope it's not a common problem (as I expect most people to just use
> sizers and not compute their layout from the font sizes) but if we can fix
> it to avoid unpleasant surprises after upgrading to 2.9 it would still be
> nice.

Basically the window consists of several wxStaticBoxSizer inside a
wxBoxSizer. Some of those wxStaticBoxSize do contain another
wxStaticBoxSizer which contain e.g. a wxBitmap and a wxStaticText.
Explaining it thoroughly is hard, as I use all kind of objects (I will
make some pictures tomorrow or so). And to get around changes in the DPI
setting of windows, I'm using explicit fonts where I've used SetPixelSize.

E.g. at what I'm currently looking (which seem to have changed with that
commit) is the height of a wxBoxSizer which contains a wxStaticBitmap
and a wxStaticText.

What I'm doing is something like that (typed down, might contain errors):

wxFont font;
font = GetFont();
(...)
wxFont font9(font);
font9.SetPixelSize(wxSize(0, -9));
(...)
wxStaticBoxSizer sbox = new wxStaticBoxSizer(...);
for (...) { // 16
wxBoxSizer box = new wxBoxSizer(...);
bitmap = new wxStaticBitmap(...);
box->Add(bitmap, ...);
stext = new wxStaticText(...);
stext->SetFont(font9);
box->Add(stext, ...);
stext->setLabel(text);
sbox->Add(box, ...);
}

The bitmap is very small. The hole size of that wxStaticBoxSizer is
increased about 16 pixels with the above commit (so it looks like the
font height got increased by 1).

The problem could be the following commit
(bff248644eb51397254b796bee24fa995b8870b0) too. I couldn't compile wxMSW
at b5791cc7af207a74deb0bea60f99cd97429bcb8c, I've just assumed it's that
commit because the following commit (with which I could compile it)
looks innocent. (These are definitely the two commits where the
additional pixels in that layout from 2.9.1 to 2.9.2 do come from).

But more later, it's already late here. ;)

Regards,

Alexander

[Werner]

Hi Alexander,

I use wxPython and we had initially some problems with the wx.lib.masked
controls due to the default font change in 2.9.

http://trac.wxwidgets.org/ticket/9840

Python 2.6 with wxPython 2.8
font string: "0;-11;0;0;0;400;0;0;0;0;0;0;0;0;MS Shell Dlg 2"
font string: "0;-11;0;0;0;400;0;0;0;1;0;0;2;48;Courier New"

Python 2.7 with wxPython 2.9
font string: "0;-12;0;0;0;400;0;0;0;1;0;0;0;0;Segoe UI"
font string: "0;-12;0;0;0;400;0;0;0;1;0;0;2;48;Courier New"

Just a guess that this may be part of the problem you see.

Werner

[Vadim Zeitlin]

On Sat, 02 Feb 2013 04:02:06 +0100 Alexander Holler wrote:

AH> E.g. at what I'm currently looking (which seem to have changed with that
AH> commit) is the height of a wxBoxSizer which contains a wxStaticBitmap
AH> and a wxStaticText.

Well, wxStaticBitmap height really shouldn't have changed so it seems like
that of wxStaticText did. If this is the case, then just adding
wxStaticText to the minimal sample and printing its GetBestSize().y should
produce different results before and after that commit -- is this really
the case?

AH> What I'm doing is something like that (typed down, might contain errors):
AH>
AH> wxFont font;
AH> font = GetFont();
AH> (...)
AH> wxFont font9(font);
AH> font9.SetPixelSize(wxSize(0, -9));
AH> (...)
AH> wxStaticBoxSizer sbox = new wxStaticBoxSizer(...);

FWIW the size reserved for wxStaticBoxSizer margins could have changed as
well since 2.8 (although definitely not in this commit) so you might want
to test with just a plain wxBoxSizer to eliminate this possibility.

Regards,
VZ

[Alexander Holler]

Am 02.02.2013 14:41, schrieb Vadim Zeitlin:
> On Sat, 02 Feb 2013 04:02:06 +0100 Alexander Holler wrote:
>
> AH> E.g. at what I'm currently looking (which seem to have changed with that
> AH> commit) is the height of a wxBoxSizer which contains a wxStaticBitmap
> AH> and a wxStaticText.
>
> Well, wxStaticBitmap height really shouldn't have changed so it seems like
> that of wxStaticText did. If this is the case, then just adding
> wxStaticText to the minimal sample and printing its GetBestSize().y should
> produce different results before and after that commit -- is this really
> the case?

Yes, thats what I've already had find out this night after I've written
the last message.

The code fragment

wxFont font(GetFont());
font.SetPixelSize(wxSize(0, 9));
wxStaticText* stext = new wxStaticText(this, wxID_ANY, "foo");
stext->setFont(font);
wxSize sz(stext->GetBestSize());

gives (10, 9) for sz with commit 2fd7161 and (10, 9) with bff2486.

BUT with font.SetPixelSize(wxSize(0, -9)) I get

(13, 11) for sz with commit 2fd7161 and (16, 13) with bff2486.

So the first set of additional vertical pixels in the layout (between
2.9.0 and 2.9.1) is explained (at least kind of, still haven't looked at
why that GetBestSize() got changed for negative values). I will now
checkout how to change the font.SetPixelSize() without actually changing
the font and/or layout. Afterwards I will see if I will still get
additional pixels when further advancing to 2.9.2+.

Regards,

Alexander

[Alexander Holler]

Am 02.02.2013 16:16, schrieb Alexander Holler:

> the font and/or layout. Afterwards I will see if I will still get
> additional pixels when further advancing to 2.9.2+.

Found it. The culprit is commit e279a9. That one is at least easy
revertable. ;)

Now to check what really happened through commit b5791c which seems to
change at lot more than his comment suggests.

Regards,

Alexander

[Vadim Zeitlin]

On Sun, 03 Feb 2013 13:13:29 +0100 Alexander Holler wrote:

AH> Am 02.02.2013 16:16, schrieb Alexander Holler:
AH>
AH> > the font and/or layout. Afterwards I will see if I will still get
AH> > additional pixels when further advancing to 2.9.2+.
AH>
AH> Found it. The culprit is commit e279a9.

Thanks for your investigation and sorry for completely forgetting about
this one (it's r66452 for future reference).

AH> That one is at least easy revertable. ;)

Yes. But I don't think reverting it would be a good idea because it fixes
a real, even if not immediately obvious, problem: before, the text in a
commonly used "Label: [Text field]" layout wasn't vertically aligned if you
vertically centred both wxStaticText and wxTextCtrl. The difference was
just a single pixel, so, again, this wasn't very visible but it was still
there and the change above is the only way I know of fixing this.

So we'll just have to live with the change in wxStaticText height, I
think. It's hard to imagine a situation in which it would be a really big
problem. The change in layout compared to 2.8 is annoying but hopefully not
catastrophic, is it?

AH> Now to check what really happened through commit b5791c which seems to
AH> change at lot more than his comment suggests.

Yes, I'd still be curious about this.

Thanks,
VZ

[Alexander Holler]

Am 04.02.2013 14:11, schrieb Vadim Zeitlin:
> On Sun, 03 Feb 2013 13:13:29 +0100 Alexander Holler wrote:
>
> AH> Am 02.02.2013 16:16, schrieb Alexander Holler:
> AH>
> AH> > the font and/or layout. Afterwards I will see if I will still get
> AH> > additional pixels when further advancing to 2.9.2+.
> AH>
> AH> Found it. The culprit is commit e279a9.
>
> Thanks for your investigation and sorry for completely forgetting about
> this one (it's r66452 for future reference).
>
> AH> That one is at least easy revertable. ;)
>
> Yes. But I don't think reverting it would be a good idea because it fixes
> a real, even if not immediately obvious, problem: before, the text in a
> commonly used "Label: [Text field]" layout wasn't vertically aligned if you
> vertically centred both wxStaticText and wxTextCtrl. The difference was
> just a single pixel, so, again, this wasn't very visible but it was still
> there and the change above is the only way I know of fixing this.
>
> So we'll just have to live with the change in wxStaticText height, I
> think. It's hard to imagine a situation in which it would be a really big
> problem. The change in layout compared to 2.8 is annoying but hopefully not
> catastrophic, is it?

I think it is. 2 pixels doesn't sound a lot, but if you count that over
several wxStaticText's, the combined vertical size of them are reaching
fast the very limited count of available vertical pixels (e.g. just
600(-sizeof-windows-taskbar) is quiet common today).

And together with the (still unexplained/unexplored) change in
fontsizes, it currently is almost impossible to build a vertical small
wxStaticText with around 11 pixels (the necessary small font would just
become unreadable), because the margins above and below are so large.

I haven't looked at the alignment problem which seems to only affect the
wxStaticText in combination with wxTextCtrl, but maybe another solution
would be possible, which doesn't affect all wxStaticText's, like an
additional attribute for wxStaticText (wich only increases the margins
if used).

In regard to the font calculations, I still haven't looked at the
difference between 2.9.0 and 2.9.1+. I've only seen that in 2.9.4
negative sizes are now used internally (-abs(fontheight)), so something
might have changed there between 2.9.1 and 2.9.4 again.

To explain the problem visual, I've uploaded a picture with what I'm
currently dealing: http://ahsoftware.de/wx_2_9_0_vs_wx_2_9_2.png

Regards,

Alexander

[Alexander Holler]

Am 04.02.2013 14:56, schrieb Alexander Holler:

> To explain the problem visual, I've uploaded a picture with what I'm
> currently dealing: http://ahsoftware.de/wx_2_9_0_vs_wx_2_9_2.png

Hmm, I've named the picture wrong, 2.9.2 is on the left side and 2.9.0
on the right side.

Regards,

Alexander

[Vadim Zeitlin]

On Mon, 04 Feb 2013 14:56:39 +0100 Alexander Holler wrote:

AH> > So we'll just have to live with the change in wxStaticText height, I
AH> > think. It's hard to imagine a situation in which it would be a really big
AH> > problem. The change in layout compared to 2.8 is annoying but hopefully not
AH> > catastrophic, is it?
AH>
AH> I think it is. 2 pixels doesn't sound a lot, but if you count that over
AH> several wxStaticText's, the combined vertical size of them are reaching
AH> fast the very limited count of available vertical pixels (e.g. just
AH> 600(-sizeof-windows-taskbar) is quiet common today).

I regret the collective folly that resulted in an actual reduction in the
amount of vertical space on computer displays since 10 years or so as much
as anybody else[*] but I don't think here is the right place to account for
it. If this is an important problem for your application -- and I can
perfectly well understand that it could be -- then surely it would be much
more efficient to reduce the number of controls or use a different layout
strategy, e.g. 2 columns instead of one.

AH> And together with the (still unexplained/unexplored) change in
AH> fontsizes, it currently is almost impossible to build a vertical small
AH> wxStaticText with around 11 pixels (the necessary small font would just
AH> become unreadable), because the margins above and below are so large.

I don't think it's related to this change though (r66452). This just
changes the best size used by default, if you set the size explicitly to 10
or 11 pixels, this code doesn't enter into play at all. So if the margins
are too big, and bigger than in 2.8, this is yet another, unrelated change.

AH> I haven't looked at the alignment problem which seems to only affect the
AH> wxStaticText in combination with wxTextCtrl,

No, it's just the most common example. Even in your own screenshot you can
see perfectly well (once you look for it) that the alignment has changed.
It's still not centred perfectly because the text height is 7 in your case
and the bitmap height is 10 (i.e. they can't be perfectly aligned
vertically) but the text is one pixel higher now which is IMHO
aesthetically more pleasing as it seemed to be too low before.

And the alignment problem is the same with any control placed at the same
level as wxStaticText, be it wxTextCtrl, wxStaticBitmap (your case, I
imagine), wxComboBox or anything else.

Regards,
VZ

[*] This is a polite way of saying that it makes me absolutely mad that I
simply can't buy any 15'' notebook with 1600*1200 resolution that I was
using 10 years ago or even 1920*1200 one (which is a bit too small)
that I bought 3 years ago. Well, with one exception that I'm really
loath to consider but which seems to be the only choice...

[Alexander Holler]

Am 04.02.2013 15:17, schrieb Vadim Zeitlin:
> On Mon, 04 Feb 2013 14:56:39 +0100 Alexander Holler wrote:
>
> AH> > So we'll just have to live with the change in wxStaticText height, I
> AH> > think. It's hard to imagine a situation in which it would be a really big
> AH> > problem. The change in layout compared to 2.8 is annoying but hopefully not
> AH> > catastrophic, is it?
> AH>
> AH> I think it is. 2 pixels doesn't sound a lot, but if you count that over
> AH> several wxStaticText's, the combined vertical size of them are reaching
> AH> fast the very limited count of available vertical pixels (e.g. just
> AH> 600(-sizeof-windows-taskbar) is quiet common today).
>
> I regret the collective folly that resulted in an actual reduction in the
> amount of vertical space on computer displays since 10 years or so as much
> as anybody else[*] but I don't think here is the right place to account for
> it. If this is an important problem for your application -- and I can

Display manufacturerers are just using the same argument as you. They
say just change your design. Taking in account that displays got
vertical smaller, it is (imho) contraproductive that wxWidgets now needs
more vertical pixels for almost any widget.

> I don't think it's related to this change though (r66452). This just
> changes the best size used by default, if you set the size explicitly to 10
> or 11 pixels, this code doesn't enter into play at all. So if the margins
> are too big, and bigger than in 2.8, this is yet another, unrelated change.

Hmm, sorry, I can't talk about svn change numbers as the official
repository (and what I'm using) is now git (which doesn't show the svn
numbers). But with commit b5791 (the one which changed something for
fonts) the following happened:

http://ahsoftware.de/wx_2_9_1_vs_wx_2_9_0.png

>
> AH> I haven't looked at the alignment problem which seems to only affect the
> AH> wxStaticText in combination with wxTextCtrl,
>
> No, it's just the most common example. Even in your own screenshot you can
> see perfectly well (once you look for it) that the alignment has changed.
> It's still not centred perfectly because the text height is 7 in your case
> and the bitmap height is 10 (i.e. they can't be perfectly aligned
> vertically) but the text is one pixel higher now which is IMHO
> aesthetically more pleasing as it seemed to be too low before.
>
> And the alignment problem is the same with any control placed at the same
> level as wxStaticText, be it wxTextCtrl, wxStaticBitmap (your case, I
> imagine), wxComboBox or anything else.

Whatever the alignment problem is, the solution to make every
wxStatixText (and thus almost every widget) 2 pixels higher isn't very
good (imho) and breaks backward compatibility.

And redesigning an application is often a very time consuming task, as
many peoples might be involved. Of course, that's not your problem, but
it is what many devs are confronted with. Most of the time they can't
change designs on their own (in contrast to change code).

I don't want to say that the new visual appearance isn't better, I'm
only talking about backwards compatibility which currently seems to be
broken for many designs.

Anyway, as already said, I will likely have a look about how to
circumvent the font handling changes and will post a solution, if I've
found one. In regard to the 2 additional pixels, I might just patch the
used wxwidgets source to be backwards compatible.

Regards,

Alexander

[Bryan Petty]

On Mon, Feb 4, 2013 at 8:03 AM, Alexander Holler <hol...@ahsoftware.de> wrote:
> Hmm, sorry, I can't talk about svn change numbers as the official repository
> (and what I'm using) is now git (which doesn't show the svn numbers).

Actually, the GitHub repository is just a *mirror*, and it's only
there for convenience. The Subversion repository is still the official
source for wxWidgets development.

Also, the GitHub mirror contains SVN revision numbers, check the
git-svn-id lines:

$ git log --grep @66452
commit e279a9e799c3808b221dc459a3a81bd2c19b36ea
Author: Vadim Zeitlin <va...@wxwidgets.org>
Date: Sun Dec 26 16:29:22 2010 +0000

Increase wxStaticText height in wxMSW to align its text with wxTextCtrl.

The base lines of the text in wxTextCtrl and wxStaticText which were
themselves vertically aligned didn't align, the text in the latter was one
pixel too low. This seems to be happening because we don't give enough
vertical space to the native static control by default and so,
while the text
wasn't truncated, it was positioned differently than usual.

Work around this problem by allocating two extra pixels to wxStaticText
height. While the exact explanation of the problem remains mysterious, this
hack does result in correct appearance which seems to be sufficiently
important to apply it.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@66452
c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

> Whatever the alignment problem is, the solution to make every wxStatixText
> (and thus almost every widget) 2 pixels higher isn't very good (imho) and
> breaks backward compatibility.

The 2.9.2 release is off of a development branch, and is not intended
to be backwards compatible with the 2.8 branch or even 2.9 releases
before it. It's perfectly acceptable to break backwards compatibility
in these releases in situations like this. If you don't like that, you
can always switch back to the latest stable release (2.8.12).

> I don't want to say that the new visual appearance isn't better, I'm only
> talking about backwards compatibility which currently seems to be broken for
> many designs.

In a majority of wxWidgets applications, sizers have been used with
the intention of layouts being flexible to minor changes and
especially for changes in translations depending on application
locale. Most applications won't need to change anything in their
applications regardless of this change. You are in the minority here
that just happened to incorrectly assume that sizer layout was a very
static asset rather than relying on a custom rendered control with
absolute positioning (which you could still switch to).

> Anyway, as already said, I will likely have a look about how to circumvent
> the font handling changes and will post a solution, if I've found one. In
> regard to the 2 additional pixels, I might just patch the used wxwidgets
> source to be backwards compatible.

This is perfectly acceptable too, but I wouldn't count on that patch
ever making it into wxWidgets itself, so you might be maintaining that
custom patch for a long time, and it will restrict your options for
application deployment.

Regards,
Bryan Petty

[Vadim Zeitlin]

On Mon, 04 Feb 2013 16:03:38 +0100 Alexander Holler wrote:

AH> Display manufacturerers are just using the same argument as you. They
AH> say just change your design. Taking in account that displays got
AH> vertical smaller, it is (imho) contraproductive that wxWidgets now needs
AH> more vertical pixels for almost any widget.

It's not ideal but IMO correct alignment is more important, if only
because there is no workaround in this case.

AH> > I don't think it's related to this change though (r66452). This just
AH> > changes the best size used by default, if you set the size explicitly to 10
AH> > or 11 pixels, this code doesn't enter into play at all. So if the margins
AH> > are too big, and bigger than in 2.8, this is yet another, unrelated change.
AH>
AH> Hmm, sorry, I can't talk about svn change numbers as the official
AH> repository (and what I'm using) is now git (which doesn't show the svn
AH> numbers). But with commit b5791 (the one which changed something for
AH> fonts) the following happened:
AH>
AH> http://ahsoftware.de/wx_2_9_1_vs_wx_2_9_0.png

Sorry, I'm not sure what is this supposed to illustrate but I still stand
by my words above, i.e. this change (r66452) shouldn't affect you at all if
you explicitly set the size of your wxStaticTexts. You should see no
changes in the layout if you revert it in this case.

AH> Whatever the alignment problem is, the solution to make every
AH> wxStatixText (and thus almost every widget) 2 pixels higher isn't very
AH> good (imho) and breaks backward compatibility.

As Bryan wrote, backward compatibility never extended to pixel positions
of different controls so these words are too strong here. Nevertheless, I'd
prefer to avoid this change if it were possible, i.e. if we could find some
way to use the previous, smaller size but still align wxStatixText contents
properly. Unfortunately I don't know how to do it and, as I already
mentioned, for me using the correct alignment is more important than
minimizing wxStatixText height.

AH> Anyway, as already said, I will likely have a look about how to
AH> circumvent the font handling changes and will post a solution, if I've
AH> found one. In regard to the 2 additional pixels, I might just patch the
AH> used wxwidgets source to be backwards compatible.

Again, if you use explicit sizes, this won't change anything.

Regards,
VZ

[Alexander Holler]

Am 04.02.2013 16:34, schrieb Bryan Petty:
> On Mon, Feb 4, 2013 at 8:03 AM, Alexander Holler <hol...@ahsoftware.de> wrote:
>> Hmm, sorry, I can't talk about svn change numbers as the official repository
>> (and what I'm using) is now git (which doesn't show the svn numbers).
>
> Actually, the GitHub repository is just a *mirror*, and it's only
> there for convenience. The Subversion repository is still the official
> source for wxWidgets development.

Sources (in the menu bar on the right side) at wxwidgets.org are
pointing to github (happily, as even the SVN maintainers are
discouraging the use of SVN since quiet some time).

>
> Also, the GitHub mirror contains SVN revision numbers, check the
> git-svn-id lines:

Ah, yes, you are right. Have overseen that. Sorry.

>> Anyway, as already said, I will likely have a look about how to circumvent
>> the font handling changes and will post a solution, if I've found one. In
>> regard to the 2 additional pixels, I might just patch the used wxwidgets
>> source to be backwards compatible.
>
> This is perfectly acceptable too, but I wouldn't count on that patch
> ever making it into wxWidgets itself, so you might be maintaining that
> custom patch for a long time, and it will restrict your options for
> application deployment.

I'm aware of such. But a design change might even end up in just not
using wxWidgets anymore (because a design change might be as much work
as rewriting the whole carefully designed application using something
which might better fit in todays and future environments (or devs).

And to bet on the case that some patches might be accepted by some
(absolutely not involved) maintainers is and was always impossible and
isn't something I do. I've just discovered that most widgets do now need
more vertical space and have searched why, to be able to discuss
possible options how to go further. Unfortunately just still using
wxWidgets 2.8 isn't an option, as the OS (and compilers) changed too.

Anyway, that isn't something which needs to be discussed here. We all
have to deal with changes in IT environments (we are unable to control).

Regards,

Alexander

[Alexander Holler]

Am 04.02.2013 17:05, schrieb Vadim Zeitlin:
> On Mon, 04 Feb 2013 16:03:38 +0100 Alexander Holler wrote:

> AH> > I don't think it's related to this change though (r66452). This just
> AH> > changes the best size used by default, if you set the size explicitly to 10
> AH> > or 11 pixels, this code doesn't enter into play at all. So if the margins
> AH> > are too big, and bigger than in 2.8, this is yet another, unrelated change.
> AH>
> AH> Hmm, sorry, I can't talk about svn change numbers as the official
> AH> repository (and what I'm using) is now git (which doesn't show the svn
> AH> numbers). But with commit b5791 (the one which changed something for
> AH> fonts) the following happened:
> AH>
> AH> http://ahsoftware.de/wx_2_9_1_vs_wx_2_9_0.png
>
> Sorry, I'm not sure what is this supposed to illustrate but I still stand
> by my words above, i.e. this change (r66452) shouldn't affect you at all if
> you explicitly set the size of your wxStaticTexts. You should see no
> changes in the layout if you revert it in this case.

I didn't used epxlicit sizes (nor do I want) but I care for the minimal
size while still having readable fonts (using smaller fonts isn't an
option). If I understand your suggestion correctly, I should change the
code to explicit set all sizes to something smaller than GetMinHeight()
or getBestSize() to get around the otherwise larger sizes. I'm not sure
if that is possible or maintainable but will have a look at it.

> AH> Whatever the alignment problem is, the solution to make every
> AH> wxStatixText (and thus almost every widget) 2 pixels higher isn't very
> AH> good (imho) and breaks backward compatibility.
>
> As Bryan wrote, backward compatibility never extended to pixel positions
> of different controls so these words are too strong here. Nevertheless, I'd

It isn't about pixel positions, but about overall sizes. Currently it
looks as if every widget (with text) increased it's (minimal) vertical
size (by 3 or 4 pixels in my case) when the same font(size) is used.

Of course, that application uses explicit positions (and sizes)
somewhere else too, but that is something I even haven't looked at now.

Regards,

Alexander

[Vadim Zeitlin]

On Mon, 04 Feb 2013 18:06:32 +0100 Alexander Holler wrote:

AH> I didn't used epxlicit sizes (nor do I want) but I care for the minimal
AH> size while still having readable fonts (using smaller fonts isn't an
AH> option). If I understand your suggestion correctly, I should change the
AH> code to explicit set all sizes to something smaller than GetMinHeight()
AH> or getBestSize() to get around the otherwise larger sizes. I'm not sure
AH> if that is possible or maintainable but will have a look at it.

It should be pretty simple, just set the height of all your static texts
to the height of the icons you use alongside them.

AH> It isn't about pixel positions, but about overall sizes. Currently it
AH> looks as if every widget (with text) increased it's (minimal) vertical
AH> size (by 3 or 4 pixels in my case) when the same font(size) is used.

Yes, this is not covered by "backwards compatibility" neither. It's not
really useful anyhow because the sizes of the control differ between
different platforms, without speaking about the font sizes.

Regards,
VZ

[Alexander Holler]

Good to know that an increase of almost 50% horizontal size (on the same
platform) isn't covered by "backward compatibility". ;)

Regards,

Alexander

[Vadim Zeitlin]

On Tue, 05 Feb 2013 07:53:32 +0100 Alexander Holler wrote:

AH> Good to know that an increase of almost 50% horizontal size (on the same
AH> platform) isn't covered by "backward compatibility". ;)

I have no idea where does the 50% number come from, but no, it isn't.
Again, the whole point of using sizers is to isolate you from the details
of the pixel sizes of different controls. If you want to have pixel-perfect
layouts, neither sizers nor wxWidgets is the right tool for you, you should
manually draw everything in an image editor instead, wxWidgets is too high
level for this.

Regards,
VZ

[Alexander Holler]

Sorry, the whole point is about the abilitiy to create vertical small
widgets with readable fonts insides sizers, not about playing with
pixels and positions.

Alexander

[Alexander Holler]

And those two changes I identified are now making it impossible to use
sizers for such, because the minimal size increased that much, thus
requiring to go down to app-design on a pixel-level. Just what you said
wxWidgets isn't for.

Alexander

[Werner]

Hi Alexander,

Maybe a different voice might help to get you in sync with Vadim;-) .

If I understand Vadim's point then you should be able to work around the
problem by passing in the size to wx.StaticText you want and whatever
has changed in the default size and/or sizer handling should no longer
affect you.

Isn't that the case?

Werner

[Vadim Zeitlin]

On Tue, 05 Feb 2013 17:21:32 +0100 Alexander Holler wrote:

AH> Am 05.02.2013 17:12, schrieb Alexander Holler:
AH> > Am 05.02.2013 15:32, schrieb Vadim Zeitlin:

AH> >> On Tue, 05 Feb 2013 07:53:32 +0100 Alexander Holler wrote:
AH> >>

AH> >> AH> Good to know that an increase of almost 50% horizontal size (on
AH> >> the same
AH> >> AH> platform) isn't covered by "backward compatibility". ;)
AH> >>
AH> >> I have no idea where does the 50% number come from, but no, it isn't.
AH> >> Again, the whole point of using sizers is to isolate you from the details
AH> >> of the pixel sizes of different controls. If you want to have
AH> >> pixel-perfect
AH> >> layouts, neither sizers nor wxWidgets is the right tool for you, you
AH> >> should
AH> >> manually draw everything in an image editor instead, wxWidgets is too
AH> >> high
AH> >> level for this.
AH> >
AH> > Sorry, the whole point is about the abilitiy to create vertical small
AH> > widgets with readable fonts insides sizers, not about playing with
AH> > pixels and positions.
AH>
AH> And those two changes I identified are now making it impossible to use
AH> sizers for such, because the minimal size increased that much, thus
AH> requiring to go down to app-design on a pixel-level. Just what you said
AH> wxWidgets isn't for.

Sorry, this is getting completely counterproductive. Let's summarize the
findings so far:

1. The bug fix for wxStaticText text vertical alignment has increased the
total size of this control by 2 pixels.

2. Some other, as of yet unidentified, change resulted in further change
in vertical direction.


I'd be interested in the following things:

(a) Finding an alternative fix for the vertical alignment bug which doesn't
result in the vertical size increase.

(b) Finding the change that resulted in 2.


Unfortunately (a) risks being difficult to do, at least I have no idea
about how to fix this bug in any other way as the native static control
doesn't provide any way to configure its margins AFAIK. As for (b), it
should hopefully be relatively easy to do but requires time, which I
currently don't have. If you could help with either of these, it would be
welcome. But I really can't continue spending time on discussion of
potentially very interesting but practically useless philosophical
questions unrelated to this.

Regards,
VZ

[Alexander Holler]

Sorry, I still haven't tried it (in addition to not like that idea). I
first have to look at what changed with those font calculations (in
order to understand the new problem). But instead of doing so, I had to
defend me against those accusations that I do design by counting pixels.
I've counted those pixels only because I had to find out why the
vertical size of many (previously small) widgets has increased that much.

In regard to those 2 additional pixels which seem to be necessary to
align static text with whatever, I would suggest using some

#define WX_MSW_ALIGN_STATIC_TEXTS

or similiar in config.h, which is set by default to true. This would
offer people backward compatibility by just defining it as false in
config.h.

I will now stop with this discussion until I've found out how to
circumvent the new font calculations (and thus still being able to use
sizers).

Regards,

Alexander

[Alexander Holler]

Am 05.02.2013 17:33, schrieb Vadim Zeitlin:

> 2. Some other, as of yet unidentified, change resulted in further change
> in vertical direction.
>

I've already identified it:

http://article.gmane.org/gmane.comp.lib.wxwidgets.devel/147005

I've used a negative font size for WX_MSW before, for whatever the
reason was (that app is several years old and started with wxWindows 2.5
or even less).

But since something changed after that commit too (e.g. the use of
-abs(size) instead of an assert), I will now check out the difference
between the actual trunk and 2.9.0 (which still worked) in regard to the
minimal (vertical) size when using the same font size.

Alexander