[all] specifying font size in pixels
Vadim Zeitlin
The situation with wxFont::SetPixelSize() under MSW is currently not
really satisfactory: the height passed to this function is interpreted as
"cell height" by Windows font matcher and not as "character height". I.e.
the height of the font characters is actually smaller than this size. I'd
like to change it to use cell height because IMO this is more expected
behaviour and it would also me to get the fonts right in wxWebKit by simply
using the same value (in pixels) that WebKit itself uses when creating wx
fonts. Otherwise the fonts under MSW are way too small because creating a
standard 16px (100%/default/normal/medium) font effectively creates a ~12px
font.
OTOH it looks like the generic implementation in wxFontBase::SetPixelSize()
uses the interpretation of the height consistent with the current code. So
changing this could make MSW inconsistent with other ports (although in
practice it seems like using "cell height" is more compatible with Mac than
the old version, although it's difficult to be sure because of heavy AA-ing
used under Mac). Is it important enough to prevent us from changing MSW?
Finally, let me note that it used to be possible to select between the two
interpretations under MSW in the same way as it's possible to do it in MSW
API: by specifying negative height you could request matching to the cell
height while positive height was matched with the character height. In 2.9
this doesn't work any more because an assert checks that the height is
positive. So a backwards compatible solution would be to continue allowing
negative heights under MSW. And we probably could support them in the
generic version too if we used descent+height+leading instead of just
height in wxFontBase::SetPixelSize(). Personally I think that using
negative heights like this would be rather ugly and would prefer to just
always use the cell height (which seems to be much more commonly used in
general) but OTOH this wouldn't be the first time wx would follow MSW API.
What do you think should be done? Does anybody know about how could
creation of font from size in pixels be implemented for GTK/OS X? I could
only find some commented out code in src/gtk/font.cpp using
pango_font_description_set_absolute_size() but I don't know if it
interprets its parameter as cell or character height (I think it's cell but
I'm not sure).
Thanks for any thoughts about this,
VZ
Kevin Ollivier
On Oct 22, 2009, at 9:08 AM, Vadim Zeitlin wrote:
> Hello,
>
> The situation with wxFont::SetPixelSize() under MSW is currently not
> really satisfactory: the height passed to this function is
> interpreted as
> "cell height" by Windows font matcher and not as "character height".
> I.e.
> the height of the font characters is actually smaller than this
> size. I'd
> like to change it to use cell height because IMO this is more expected
> behaviour and it would also me to get the fonts right in wxWebKit by
> simply
> using the same value (in pixels) that WebKit itself uses when
> creating wx
> fonts. Otherwise the fonts under MSW are way too small because
> creating a
> standard 16px (100%/default/normal/medium) font effectively creates
> a ~12px
> font.
Thanks for looking into this! I knew there was a reason for making the
font size negative on MSW but it was so long ago I had forgotten it. :(
> OTOH it looks like the generic implementation in
> wxFontBase::SetPixelSize()
> uses the interpretation of the height consistent with the current
> code. So
> changing this could make MSW inconsistent with other ports (although
> in
> practice it seems like using "cell height" is more compatible with
> Mac than
> the old version, although it's difficult to be sure because of heavy
> AA-ing
> used under Mac). Is it important enough to prevent us from changing
> MSW?
I actually wasn't aware of the distinction between character and cell
heights, and I somewhat think a lot of other developers aren't either.
Since it seems to be an MSW-only construct, I think the best solution
would be to use cell size as the default, and have a
MSWSetCharacterSize API and corresponding MSWGetCharacterSize
(assuming that MSW will report the same size, with signed int, back).
Since the pixel argument in the constructor should take a value that
makes sense for all platforms. and GTK and Mac seem to be roughly on
the same page, I think we should just have the default constructor in
MSW use the cell height as GTK and Mac do. TBH, after some googling,
even on MSW I see a lot of docs talking about cell heights, so I think
it's probably the best way to go for common API.
BTW, as a side note, it'd be nice for platform-specific APIs like
MSWSetCharacterSize (if we agree upon it) if we could have the
function in the base class API as a stub and then just override the
behavior on the platform that implements it, so that wxPython (and
other language) bindings are easier to write and there are less
#ifdefs in user code.
My understanding up until now was that pixel height always refers to
the cell height. On Mac, it's actually pretty straightforward since
the Mac APIs assume a DPI value of 72, which means pixels == points,
and thus the points constructor behavior could just be used for the
pixel construction. (I think Mac actually under the hood adjusts the
pixel value to the actual system DPI value) I'm not sure if Pango does
that or not, but the assumption has at least held so far while
developing wxWebKit on wxGTK. BTW, I think the problem with the code
in src/gtk/font.cpp is that it's multiplying size * PANGO_SCALE. The
docs are a bit confusing IMHO, but from my reading, it wants "Pango
units" and not "device units", but size * PANGO_SCALE gives you
"device units".
Anyway, my gut is that the intuitive thing to do is to make cell
height the default for pixel construction on all platforms so that we
can use one constructor everywhere with consistent results. :-)
Thanks,
Kevin
Vadim Zeitlin
KO> Thanks for looking into this! I knew there was a reason for making the
KO> font size negative on MSW but it was so long ago I had forgotten it. :(
Hello,
Thanks for your feedback, I appreciate it but I'd also still like to hear
from as many people as possible before changing this because it seems like
a rather important issue and I remain far from sure about the best way to
fix it. Please at least have a look at the screenshot below and the
questions at the end of this message. TIA!
KO> I actually wasn't aware of the distinction between character and cell
KO> heights, and I somewhat think a lot of other developers aren't either.
KO> Since it seems to be an MSW-only construct, I think the best solution
KO> would be to use cell size as the default, and have a
KO> MSWSetCharacterSize API and corresponding MSWGetCharacterSize
KO> (assuming that MSW will report the same size, with signed int, back).
I don't think it does this although I could be wrong.
KO> Since the pixel argument in the constructor should take a value that
KO> makes sense for all platforms. and GTK and Mac seem to be roughly on
KO> the same page, I think we should just have the default constructor in
KO> MSW use the cell height as GTK and Mac do.
We have a strange situation because although the absolute size of the
fonts created using character height under MSW matches the sizes of the
fonts under the other platforms right now, it still does seem that using
cell height would result in better portability. Look at these screenshots:
http://www.tt-solutions.com/vz/wx/fonts.html (sorry for not creating an
AJAX-ified animating gallery but hopefully this should be clear enough...).
While the absolute size of 'T' in 18px font is 9*11 pixels under all of
GTK, OS X and MSW currently (and becomes 10*13 with the proposed change),
the _relative_ sizes of the fonts created using size in pixels and points
looks to be more consistent in lower right screenshot than in the lower
left one, doesn't it?
BTW, obviously MSW uses different DPI setting than the other systems but
the size in points used by wx is correct one in the sense that it's the
same when you select a font of, say, 12pt size, in any other MSW
application (e.g. Notepad).
KO> BTW, as a side note, it'd be nice for platform-specific APIs like
KO> MSWSetCharacterSize (if we agree upon it) if we could have the
KO> function in the base class API as a stub and then just override the
KO> behavior on the platform that implements it, so that wxPython (and
KO> other language) bindings are easier to write and there are less
KO> #ifdefs in user code.
I don't like this very much as I'd rather make the code fail to compile
under other platforms. What sense does it make to call such functions
there? But it's a topic for another thread...
KO> My understanding up until now was that pixel height always refers to
KO> the cell height. On Mac, it's actually pretty straightforward since
KO> the Mac APIs assume a DPI value of 72, which means pixels == points,
The screenshot shows that this is not true for this (10.5) system. Of
course, maybe wxOSX code is buggy.
KO> Anyway, my gut is that the intuitive thing to do is to make cell
KO> height the default for pixel construction on all platforms so that we
KO> can use one constructor everywhere with consistent results. :-)
I think I'm convinced by this so I propose to change MSW to implicitly
convert the (positive) value passed to wxFont to negative value before
passing it to Windows. This is incompatible with the existing behaviour but
more compatible with the other ports and just seems to make more sense.
Assuming we agree to do this, there are 2 more questions so let me list
all of them together:
0. Do we agree to change the meaning of pixel size parameter in wxFont
ctor/SetPixelSize() to mean cell height instead of character height
under MSW?
1. Do we assert if negative size is used in ctor/SetPixelSize() or just
silently use it as is for compatibility?
2. Do we provide some (MSW-specific?) way to specify the character height
of the font in pixels?
My own answers -- at this moment -- are:
0. Yes
1. Don't assert, existing code probably uses this.
2. Don't do this until someone really asks for it.
Any other opinions?
Thanks,
VZ
Kevin Ollivier
Not to me, really. The lower left fonts look to me, size-wise, more
like the GTK and Mac font sizes. But this is why I'd say not to use
visual impression to decide.
Another problem with this comparison is that GTK and Mac are not doing
the right thing, so once SetPixelSize is fixed on those platforms the
results will surely change. (More below.)
> BTW, obviously MSW uses different DPI setting than the other systems
> but
> the size in points used by wx is correct one in the sense that it's
> the
> same when you select a font of, say, 12pt size, in any other MSW
> application (e.g. Notepad).
>
> KO> BTW, as a side note, it'd be nice for platform-specific APIs like
> KO> MSWSetCharacterSize (if we agree upon it) if we could have the
> KO> function in the base class API as a stub and then just override
> the
> KO> behavior on the platform that implements it, so that wxPython (and
> KO> other language) bindings are easier to write and there are less
> KO> #ifdefs in user code.
>
> I don't like this very much as I'd rather make the code fail to
> compile
> under other platforms. What sense does it make to call such functions
> there? But it's a topic for another thread...
How do you make code fail to compile for wxPython users, is my
question. :-) That's the problem with compile-time fixes - they work
for C++ users, but are useless or extra work for people using or
maintaining bindings in other languages. And the more "platform X has
API A but platform Y doesn't" rules you have, the harder it is to try
and automate bindings generation and the more manual maintenance work
you have to do.
> KO> My understanding up until now was that pixel height always
> refers to
> KO> the cell height. On Mac, it's actually pretty straightforward
> since
> KO> the Mac APIs assume a DPI value of 72, which means pixels ==
> points,
>
> The screenshot shows that this is not true for this (10.5) system. Of
> course, maybe wxOSX code is buggy.
It is buggy, but it's not just wxOSX. For what wxGTK and wxOSX do (and
IIUC just about any platform besides wxMSW), see
wxFontBase::SetPixelSize, which is clearly not the approach we should
be taking. Rather than convert between system DPI and 72 DPI to
convert pixels to points, it instead basically keeps setting font
sizes and measuring the characters based on some algorithm that looks
more like guesswork based on some assumptions about the relationship
between pixel and point sizes than any sort of defined conversion
routine. Of course, just using the native support available for GTK
and Mac would be even better. :-)
This sounds about right to me.
Thanks,
Kevin
> Thanks,
> VZ
Julian Smart
Vadim Zeitlin wrote:
> Hello,
>
> The situation with wxFont::SetPixelSize() under MSW is currently not
> really satisfactory: the height passed to this function is interpreted as
> "cell height" by Windows font matcher and not as "character height". I.e.
> the height of the font characters is actually smaller than this size. I'd
> like to change it to use cell height because IMO this is more expected
>
I'm slightly confused there, since you say the current interpretation is
cell height, but you want to change it to use cell height.
According to http://support.microsoft.com/kb/200262, character height
can be better than cell height, depending on what you're trying to do:
"If possible, programs should scale the font by using the metric that
scales linearly: the character height (negative lfHeight values)."
Intuitively, it seems likely that sometimes you really do want to
specify a font height that fits in a given space, and that seems a more
common interpretation than "fits in a given space plus some arbitrary
internal leading dimension". OTOH, if you're writing a multiline-text
control, presumably you're interesting the internal leading so as to
space out the lines appropriately.
It would certainly be nice to allow both interpretations, so I'd be in
favour of using the negative value on as many platforms as possible. But
if it's not possible to specify character height for all platforms, then
at least consistency across platforms using cell height would be a good
thing.
Thanks,
Julian
Kevin Ollivier
Thanks for clarifying! Then character and cell height are indeed
getting mixed up in this thread. wxWebKit currently uses the negative
value by necessity, so according to this, that means we use character
height rather than cell height.
> Intuitively, it seems likely that sometimes you really do want to
> specify a font height that fits in a given space, and that seems a
> more common interpretation than "fits in a given space plus some
> arbitrary internal leading dimension". OTOH, if you're writing a
> multiline-text control, presumably you're interesting the internal
> leading so as to space out the lines appropriately.
Well, wxWebKit is essentially a multiline text (well, very rich text!)
control, and it wants character height. The internal leading can still
be obtained by getting the text metrics of the font and grabbing its
ascent value, then subtracting the character height of the character
or string. However, I suspect the ascent value is probably enough for
doing proper line spacing. There's a wxFontProperties class in
wxWebKit that should be able to be moved to wx that provides access to
font metrics like ascent.
BTW, I found this link helpful in illustrating the various metrics:
http://support.microsoft.com/kb/32667
> It would certainly be nice to allow both interpretations, so I'd be
> in favour of using the negative value on as many platforms as
> possible. But if it's not possible to specify character height for
> all platforms, then at least consistency across platforms using cell
> height would be a good thing.
It is certainly possible to specify character height for all
platforms, at least when DPI is 72, as wxWebKit does just this; it's
cell height I'm not sure about. Again, we can calculate the value on
other platforms using the font metrics, but "out of the box" GTK and
Mac seem to work with character height. (And in fact, in my googling I
saw a patch to Win32 Cairo that added negative signs to the
logical_size when constructing the native font on Win32.)
In short, I think adding wxFontProperties to wx (though I'd actually
like to rename it wxFontMetrics) would provide people with all the
metrics they'd need to calculate various line spacing attributes.
Thanks,
Kevin
> Thanks,
>
> Julian
Vadim Zeitlin
JS> Vadim Zeitlin wrote:
JS> > Hello,
JS> >
JS> > The situation with wxFont::SetPixelSize() under MSW is currently not
JS> > really satisfactory: the height passed to this function is interpreted as
JS> > "cell height" by Windows font matcher and not as "character height". I.e.
JS> > the height of the font characters is actually smaller than this size. I'd
JS> > like to change it to use cell height because IMO this is more expected
JS> >
JS> I'm slightly confused there, since you say the current interpretation is
JS> cell height, but you want to change it to use cell height.
Sorry, I keep mixing up the two which clearly doesn't help the discussion
:-( In spite of what I wrote above, I'd like to change wxMSW to use
*character* height, i.e. negative value with MSW API.
JS> According to http://support.microsoft.com/kb/200262, character height
JS> can be better than cell height,
Yes, this is what I think too.
JS> Intuitively, it seems likely that sometimes you really do want to
JS> specify a font height that fits in a given space,
This would be a cell height. And yes, I can agree that it may be useful
but OTOH it seems that in practice just about everyone means cell height
when they speak of "font of size N pixels".
JS> It would certainly be nice to allow both interpretations,
Nice, no question. But is it really necessary? I am not sure about this
considering that platforms other than MSW never provided this functionality
before anyhow. And being lazy I'd rather not implement it if possible.
JS> so I'd be in favour of using the negative value on as many platforms as
JS> possible.
The problem with this is that if we allow negative values at all we really
must use the same convention as MSW because otherwise everybody will become
hopelessly confused. And this means that the positive height will continue
to mean not what most people expect it to and this is why I don't like
this.
JS> But if it's not possible to specify character height for all platforms,
JS> then at least consistency across platforms using cell height would be a
JS> good thing.
The generic code which tries to find the font closes to the requested
height could probably be adapted to do both (provided GetTextExtent()
returns the correct values for external leading and descent). But the
problem is that at the API level this would mean that you'd need to specify
the negative height in the more common case and IMO this is not ideal.
Regards,
VZ
Vadim Zeitlin
KO> Well, wxWebKit is essentially a multiline text (well, very rich text!)
KO> control, and it wants character height.
Thinking more about this, it's actually pretty rare to select a font which
fits in the provided line height. Usually you compute the line height from
the font height and you don't need to specify font size in pixels at all
for this, you just need to use GetTextExtent() and properly account for the
external leading and descent.
KO> There's a wxFontProperties class in wxWebKit that should be able to be
KO> moved to wx that provides access to font metrics like ascent.
We could add this to wx and provide a GetTextExtent() overload returning
it, it's would definitely be nicer to use than passing 6 parameters to it.
KO> BTW, I found this link helpful in illustrating the various metrics:
KO>
KO> http://support.microsoft.com/kb/32667
Thanks, this is indeed useful. And, just to repeat, currently we interpret
the font height as character (greater) height in wxMSW. Using negative
values would rather interpret it as cell (smaller) height -- resulting in
bigger fonts.
KO> In short, I think adding wxFontProperties to wx (though I'd actually
KO> like to rename it wxFontMetrics) would provide people with all the
KO> metrics they'd need to calculate various line spacing attributes.
AFAICS this class is completely trivial, the functionality itself is all
in GetTextExtent(). But I still agree that it would be nicer to have it
(and I also prefer to name it wxFontMetrics FWIW).
Regards,
VZ
Julian Smart
Vadim Zeitlin wrote:
> Thanks, this is indeed useful. And, just to repeat, currently we interpret
> the font height as character (greater) height in wxMSW. Using negative
> values would rather interpret it as cell (smaller) height -- resulting in
> bigger fonts.
>
OK, now I'm confused again. Surely the cell height is the larger height,
since it includes internal leading? According to the Microsoft diagram
anyway... I think if you switch character and cell in the above, it's
what was intended.
Looking at the diagram again, the character height without internal
leading seems pretty useless, because umlauts etc. would not be taken
into account and could get clipped if you relied on character height alone.
> KO> In short, I think adding wxFontProperties to wx (though I'd actually
> KO> like to rename it wxFontMetrics) would provide people with all the
> KO> metrics they'd need to calculate various line spacing attributes.
>
> AFAICS this class is completely trivial, the functionality itself is all
> in GetTextExtent(). But I still agree that it would be nicer to have it
> (and I also prefer to name it wxFontMetrics FWIW).
>
Absolutely, this would be good to have.
Regards,
Julian
Kevin Ollivier
On Oct 27, 2009, at 9:59 AM, Vadim Zeitlin wrote:
> On Tue, 27 Oct 2009 09:48:01 -0700 Kevin Ollivier <kevin...@theolliviers.com
> > wrote:
>
> KO> Well, wxWebKit is essentially a multiline text (well, very rich
> text!)
> KO> control, and it wants character height.
>
> Thinking more about this, it's actually pretty rare to select a font
> which
> fits in the provided line height. Usually you compute the line
> height from
> the font height and you don't need to specify font size in pixels at
> all
> for this, you just need to use GetTextExtent() and properly account
> for the
> external leading and descent.
>
> KO> There's a wxFontProperties class in wxWebKit that should be
> able to be
> KO> moved to wx that provides access to font metrics like ascent.
>
> We could add this to wx and provide a GetTextExtent() overload
> returning
> it, it's would definitely be nicer to use than passing 6 parameters
> to it.
Actually, the metrics for a particular font family and size will be
constant regardless of the text string passed in, so there's no need
to tie this to GetTextExtent() and force creation of a wxDC, which is
prohibitively expensive (outside a paint event) on Mac.
wxFont::GetMetrics() I think would be the right place for this.
> KO> BTW, I found this link helpful in illustrating the various
> metrics:
> KO>
> KO> http://support.microsoft.com/kb/32667
>
> Thanks, this is indeed useful. And, just to repeat, currently we
> interpret
> the font height as character (greater) height in wxMSW. Using negative
> values would rather interpret it as cell (smaller) height --
> resulting in
> bigger fonts.
Be careful. :-) Character height is what is gotten using the negative
value, not cell height. Though whether cell height is smaller or
bigger depends on your frame of reference. Specifying 12 px as the
cell height will certainly create a smaller looking font than
specifying 12 px as the character height. But when you are measuring,
the cell height will be greater than the character height.
> KO> In short, I think adding wxFontProperties to wx (though I'd
> actually
> KO> like to rename it wxFontMetrics) would provide people with all the
> KO> metrics they'd need to calculate various line spacing attributes.
>
> AFAICS this class is completely trivial, the functionality itself is
> all
> in GetTextExtent().
Yes, though like I said earlier, having it there causes problems for
wxWebKit, and really for any text engine that needs to be high
performance on all platforms. We have wxGC::Create, but we still can't
use that everywhere yet; in fact, it only gives us proper measurements
on Mac right now, though I haven't had time to dig into why that is.
> But I still agree that it would be nicer to have it
> (and I also prefer to name it wxFontMetrics FWIW).
Okay, thanks!
Kevin
> Regards,
> VZ
Kevin Ollivier
On Oct 27, 2009, at 10:17 AM, Julian Smart wrote:
>
> Hi Vadim,
>
> Vadim Zeitlin wrote:
>> Thanks, this is indeed useful. And, just to repeat, currently we
>> interpret
>> the font height as character (greater) height in wxMSW. Using
>> negative
>> values would rather interpret it as cell (smaller) height --
>> resulting in
>> bigger fonts.
>>
> OK, now I'm confused again. Surely the cell height is the larger
> height, since it includes internal leading? According to the
> Microsoft diagram anyway... I think if you switch character and cell
> in the above, it's what was intended.
>
> Looking at the diagram again, the character height without internal
> leading seems pretty useless, because umlauts etc. would not be
> taken into account and could get clipped if you relied on character
> height alone.
Yes, but I'm not sure how this is relevant. All we're talking about
right now in terms of character height vs. cell height is how the
wxFont::New(wxSize pixelSize, ...) constructor should behave. The
question is whether, by definition, the pixel size of a font includes
the internal leading in its value. According to this site, it does not:
http://www.emdpi.com/fontsize.html
(Note the distinction between size, and height, where "size" is what
we've been calling character height and "height" is cell height.)
Plus, the pixel sizes WebKit uses do not include internal leading in
their size, either, so there's some practical evidence this is how
pixel sizes are defined and interpreted as well. As such, all the
evidence I have found so far suggests that the most correct behavior
for a wxFont constructor taking a pixel size is to interpret that size
as not including the internal leading; in other words, to consider it
as the character height (negative value) on Windows.
BTW, to be clear, none of this will require changes to text
measurement code, which I think is the main perspective you're looking
at things from. The only thing that will change is that a 12 px font
created in a wx app will look exactly the same size as a 12 px font in
other apps, assuming those other apps use the same definition of pixel
size. I know that all major web browsers do.
Thanks,
Kevin
Vadim Zeitlin
JS> Vadim Zeitlin wrote:
JS> > Thanks, this is indeed useful. And, just to repeat, currently we interpret
JS> > the font height as character (greater) height in wxMSW. Using negative
JS> > values would rather interpret it as cell (smaller) height -- resulting in
JS> > bigger fonts.
JS> >
JS> OK, now I'm confused again. Surely the cell height is the larger height,
JS> since it includes internal leading?
Yes :-( I was in a hurry when writing this message and made the same
mistake once again, really sorry.
JS> According to the Microsoft diagram
JS> anyway... I think if you switch character and cell in the above, it's
JS> what was intended.
Yes. Let's just accept that whenever I write something in this thread that
seems to be wrong, it's because it really is.
JS> Looking at the diagram again, the character height without internal
JS> leading seems pretty useless, because umlauts etc. would not be taken
JS> into account and could get clipped if you relied on character height alone.
I agree with Kevin here so I won't reproduce what he wrote.
Regards,
VZ
Vadim Zeitlin
KO> Actually, the metrics for a particular font family and size will be
KO> constant regardless of the text string passed in, so there's no need
KO> to tie this to GetTextExtent() and force creation of a wxDC, which is
KO> prohibitively expensive (outside a paint event) on Mac.
KO> wxFont::GetMetrics() I think would be the right place for this.
Ah, I see. Yes, it's a good point and while I still think we should have
GetTextExtent() overload returning wxFontMetrics too (if only because the
generic implementation of wxFont::GetMetrics() would use it...) I agree
that it makes sense to provide it in wxFont itself.
KO> > KO> BTW, I found this link helpful in illustrating the various
KO> > metrics:
KO> > KO>
KO> > KO> http://support.microsoft.com/kb/32667
KO> >
KO> > Thanks, this is indeed useful. And, just to repeat, currently we
KO> > interpret the font height as character (greater) height in wxMSW.
KO> > Using negative values would rather interpret it as cell (smaller)
KO> > height -- resulting in bigger fonts.
KO>
KO> Be careful. :-) Character height is what is gotten using the negative
KO> value, not cell height. Though whether cell height is smaller or
KO> bigger depends on your frame of reference. Specifying 12 px as the
KO> cell height will certainly create a smaller looking font than
KO> specifying 12 px as the character height. But when you are measuring,
KO> the cell height will be greater than the character height.
Yes, you're totally right and I was wrong once again. I'll just avoid the
use of the words "character" and "cell" in this thread, I seem to mix them
up exactly 50% of times. You know what I mean better than me by now anyhow.
Sorry again.
Regards,
VZ
Vadim Zeitlin
KO> It is buggy, but it's not just wxOSX. For what wxGTK and wxOSX do (and
KO> IIUC just about any platform besides wxMSW), see
KO> wxFontBase::SetPixelSize, which is clearly not the approach we should
KO> be taking. Rather than convert between system DPI and 72 DPI to
KO> convert pixels to points, it instead basically keeps setting font
KO> sizes and measuring the characters based on some algorithm that looks
KO> more like guesswork based on some assumptions about the relationship
KO> between pixel and point sizes than any sort of defined conversion
KO> routine.
Sorry, I may be missing something here but I don't see why is this code
(which I did read, of course, I even mentioned that it could be modified to
behave as MSW currently does in the initial message in this thread) wrong
in principle. The idea is to find the size in points such that the size of
this font in pixels is closest to the requested one and the code seems to
do it in a straightforward way. Why not?
KO> Of course, just using the native support available for GTK
KO> and Mac would be even better. :-)
No doubt about this.
KO> > I think I'm convinced by this so I propose to change MSW to implicitly
KO> > convert the (positive) value passed to wxFont to negative value before
KO> > passing it to Windows. This is incompatible with the existing
KO> > behaviour but more compatible with the other ports and just seems to
KO> > make more sense.
KO> >
KO> > Assuming we agree to do this, there are 2 more questions so let me
KO> > list all of them together:
KO> >
KO> > 0. Do we agree to change the meaning of pixel size parameter in wxFont
KO> > ctor/SetPixelSize() to mean cell height instead of character height
KO> > under MSW?
KO> > 1. Do we assert if negative size is used in ctor/SetPixelSize() or
KO> > just silently use it as is for compatibility?
KO> > 2. Do we provide some (MSW-specific?) way to specify the character
KO> > height of the font in pixels?
KO> >
KO> > My own answers -- at this moment -- are:
KO> >
KO> > 0. Yes
KO> > 1. Don't assert, existing code probably uses this.
KO> > 2. Don't do this until someone really asks for it.
KO> >
KO> > Any other opinions?
KO>
KO> This sounds about right to me.
I've checked this in as r62566.
Regards,
VZ
Kevin Ollivier
How do you determine which size in points is closest to the pixel
value without even knowing what DPI the pixels are being measured in?
Thanks!
Kevin
> Regards,
> VZ
Vadim Zeitlin
KO> How do you determine which size in points is closest to the pixel
KO> value without even knowing what DPI the pixels are being measured in?
wxDC::GetCharHeight() knows it hopefully and this is what this code uses.
I do assume GetCharHeight() works correctly but AFAIK this is the case, do
you have any reason to believe it doesn't?
Regards,
VZ
Ed Musgrove
I tried to start a discussion on the wxWidgets' forum to see if other developers using wxWidgets had any comments, but was told by the moderator not to expect any replies.
Here is a link to the post; it has two pictures and a description of the problem:
http://wxforum.shadonet.com/viewtopic.php?t=26025
I had a quick look at the wxWidgets source code for the wxSlider and saw where these text strings are built but was unable to figure out how to make the proposed modification.
Is this a reasonable GUI improvement? If so, is there a venerable wxWidgets developer who could easily make this change, or better yet give me enough help to make the change myself?
-Ed Musgrove
Vadim Zeitlin
On Sun, 8 Nov 2009 00:55:26 -0800 (PST) Ed Musgrove <edgarm...@yahoo.com> wrote:
EM> I tried to start a discussion on the wxWidgets' forum to see if other
EM> developers using wxWidgets had any comments, but was told by the
EM> moderator not to expect any replies.
Hello,
It's true that the forum is mostly for wx users and discussing development
of wx itself is better done here.
EM> Here is a link to the post; it has two pictures and a description of
EM> the problem:
EM>
EM> http://wxforum.shadonet.com/viewtopic.php?t=26025
It's true that the current labels look rather confusingly. I wonder if
there is any UI standard under Windows for placing them. During a brief
search in shell/IE/some other Microsoft programs dialogs I couldn't find a
single slider with labels so I don't really know what is the usual way of
placing them. Personally I don't like the proposed change much because it
makes the slider take more space and because I'm pretty sure I've never
seen underlined text used like this.
If I had to choose myself I'd probably prefer to do something like
current
min |------------------| max
for the horizontal slider and
min
___
|
|
| current
|
|
|
|
___
max
for the vertical ones.
But, again, ideal would be to use the platform standard -- whatever it is.
EM> I had a quick look at the wxWidgets source code for the wxSlider and
EM> saw where these text strings are built but was unable to figure out how
EM> to make the proposed modification.
EM>
EM> Is this a reasonable GUI improvement? If so, is there a venerable
EM> wxWidgets developer who could easily make this change, or better yet
EM> give me enough help to make the change myself?
The labels are positioned quite explicitly in wxSlider::DoMoveWindow() in
src/msw/slider.cpp and I don't really know how to help you further with
understanding this code. Do you have any particular questions?
The only possibly non obvious thing I see is that in addition to changing
DoMoveWindow() you also need to update DoGetBestSize() to account for the
changes in the global size if there are going to be any.
Regards,
VZ
Ed Musgrove
http://wxforum.shadonet.com/viewtopic.php?t=26025
The "default" Microsoft Visual Studio 2008 "slider" (TrackBar) has no provision
for labels, range values nor current value. These items must all be added at
the developer's discretion (see the example in the top right-hand corner
inside the green outline).
----- Original Message ----
> From: Vadim Zeitlin <va...@wxwidgets.org>
> To: wx-...@googlegroups.com
> Sent: Sun, November 8, 2009 7:44:06 AM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
> [could you please set your word wrap to 76 or less, thank you]
>
I have included a few examples from Microsoft and other developers.
The MS Paint vertical slider does not use the default "handle"; it has no range
values; the current value readouts allow direct entry for the value (editable);
there is no label.
The MS Office 2010 horizontal slider has range values (non-text) at each end
of the slider; its current value readout is non-editable and placed to the left of
the slider; there is no label.
The ImgBurn examples show two slightly different implementations of a horizontal
slider; there are no range values; the current value readouts are non-editable, one
is on the right side and the other is below; the label is above.
The AudioFire vertical slider has multiple range values to the right; the current
value readout is editable and at the bottom; the label is above.
The Paint.NET horizontal sliders have no range values; the current value readouts
are editable; the labels are on the left.
The MediaMonkey horizontal slider has range values below; there is no current
value readout; the label is above.
As you can see from this there is absolutely no standardization. WxWidgets may
set its own design standard.
[ --Ed ]
Sorry, Yahoo!Mail does not allow outgoing wordwrap--will try to manually do it when I remember.
> It's true that the current labels look rather confusingly. I wonder if
> there is any UI standard under Windows for placing them. During a brief
> search in shell/IE/some other Microsoft programs dialogs I couldn't find a
> single slider with labels so I don't really know what is the usual way of
> placing them. Personally I don't like the proposed change much because it
> makes the slider take more space and because I'm pretty sure I've never
> seen underlined text used like this.
>
[ --Ed ]
The proposed change of moving the current value readout up one line does
not change the size required. If you look closely at the first two pictures you
will see that there is already considerable blank space between the
label line and the range value line -- more than a whole life text in height.
I underlined the current value readout only as an example of one method to set it
off visually; other options would be to use a different font color and/or
font background color or surrounded with a box.
> If I had to choose myself I'd probably prefer to do something like
>
this is the label text placed above
> current
> min |------------------| max
>
> for the horizontal slider and
t
> h
> i min
> s ___ (Note this gap would not exist, it is an artifact of plain text -- Ed.)
> |
> t |
> h | current
> e |
> |
> l |
> a |
> b | ___
> e max
> l
> for the vertical ones.
>
> But, again, ideal would be to use the platform standard -- whatever it is.
>
[ --Ed ]
I agree fully with your little sketchs as far as placement of the range values.
I like the concept of placing the current value text appropriately on the
slider range.
> current
> min |------------------| max
this is the label text placed below
>
> for the horizontal slider and
> t
> min h
> ___ i
> | s
> |
> current | i
> | s
> |
> | t
> | h
> | e
> ___
> max l
> a
> EM> I had a quick look at the wxWidgets source code for the wxSlider and
> EM> saw where these text strings are built but was unable to figure out how
> EM> to make the proposed modification.
>
> The labels are positioned quite explicitly in wxSlider::DoMoveWindow() in
> src/msw/slider.cpp and I don't really know how to help you further with
> understanding this code. Do you have any particular questions?
>
> The only possibly non obvious thing I see is that in addition to changing
> DoMoveWindow() you also need to update DoGetBestSize() to account for the
> changes in the global size if there are going to be any.
>
> Regards,
> VZ
I will go back and look at those functions and see if I can come up with
a proposal for code change to demonstrate these.
-Ed Musgrove
You did not implement slider labels in your sketches, I added them to
your sketches. It looks ugly with proportional fonts! Additional options:
Vadim Zeitlin
EM> The "default" Microsoft Visual Studio 2008 "slider" (TrackBar) has no provision
EM> for labels, range values nor current value. These items must all be added at
EM> the developer's discretion (see the example in the top right-hand corner
EM> inside the green outline).
Yes, I realize this. But I hoped that maybe there was some de facto
standard for their placement. Unfortunately this doesn't seem to be the
case.
EM> I have included a few examples from Microsoft and other developers.
Unfortunately I don't see any example which would use the labels in the
way we do among them. Actually maybe it can give us another idea: instead
of trying to rearrange the labels, maybe we shouldn't use the current label
at all? If we replaced the current value label with middle value one (which
would be similar to the "thread priority" slider in the lower right example
at http://wxforum.shadonet.com/viewtopic.php?t=26025) then the problem
wouldn't arise. And if there is one thing common to all the examples you
found, it's that the current value is displayed separately if it's
displayed at all.
EM> As you can see from this there is absolutely no standardization.
EM> WxWidgets may set its own design standard.
In this case it would be nice to come up with something that makes sense
for the other platforms too. GTK+ does show the current label but current
label only (see http://library.gnome.org/devel/gtk/unstable/GtkScale.html)
so it's not consistent with MSW even now. And OS X version doesn't seem to
handle any labels at all natively and we manage them ourselves, just as
under MSW. Interestingly enough, you can read at
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Slider/Concepts/AboutSliders.html
that
You should use text fields to display the slider’s name, minimum
value, maximum value, and tick-mark value. Although you can set a
title for a slider that’s displayed automatically, it’s displayed
right in the slider’s bar and is easily obscured by the knob. There
is no way for a slider to display automatically its minimum,
maximum, and tick-mark values.
But to summarize, I'm still not sure what to do. I think there are the
following options:
0. Do nothing.
1. Use
x
min |----------| max
labels positioning I already proposed
2. Use
x
|-------------|
min mid max
schema, i.e. put the current labels on the other side to make it clear
that it's different from the others.
3. Remove min and max labels entirely.
(0) is appealing because it's the simplest but not ideal from any other
point. (1) is almost certainly the simplest to implement. (2) is probably
the nicest looking one but will require adding another label and will also
make the control larger. Finally (3) is consistent with GTK and is
appealing by its minimality but I guess not really acceptable if people do
want their min/max values to be shown (OTOH you can always drag the slider
to the left/right to see them, can't you?).
I.e. the safe choice is (1) or (2) but I could agree with (3) too. Of
course, it's entirely possible that there are other, better options that
I'm missing.
Regards,
VZ
rob...@roebling.de
I'd favor either 1.) or 3.) the latter for consistency. Maybe
3.) should be the default and 1.) an extra option that is
mentioned to only have effect on some platforms.
Vadim wrote:
<<<<<<
1. Use
x
min |----------| max
labels positioning I already proposed
3. Remove min and max labels entirely.
Vadim Zeitlin
r> I'd favor either 1.) or 3.) the latter for consistency. Maybe
r> 3.) should be the default and 1.) an extra option that is
r> mentioned to only have effect on some platforms.
r>
r> Vadim wrote:
r>
r> <<<<<<
r>
r> 1. Use
r> x
r> min |----------| max
r>
r> labels positioning I already proposed
r>
r> 3. Remove min and max labels entirely.
Notice that we already have wxSL_LABELS options without which no labels
are used at all. Do you suggest having wxSL_MIN_MAX_LABELS and wxSL_LABEL
(meaning show the label for the current value only) with wxSL_LABELS ==
wxSL_MIN_MAX_LABELS + wxSL_LABEL or did I misunderstand you?
Thanks,
VZ
Robert Roebling
Vadim Zeitlin wrote:
> RR wrote:
>
> r> I'd favor either 1.) or 3.) the latter for consistency. Maybe
> r> 3.) should be the default and 1.) an extra option that is
> r> mentioned to only have effect on some platforms.
> r>
> r> Vadim wrote:
> r>
> r> <<<<<<
> r>
> r> 1. Use
> r> x
> r> min |----------| max
> r>
> r> labels positioning I already proposed
> r>
> r> 3. Remove min and max labels entirely.
>
> Notice that we already have wxSL_LABELS options without which no labels
> are used at all. Do you suggest having wxSL_MIN_MAX_LABELS and wxSL_LABEL
> (meaning show the label for the current value only) with wxSL_LABELS ==
> wxSL_MIN_MAX_LABELS + wxSL_LABEL or did I misunderstand you?
Since the position of the labels is not specified by any "default"
under MSW, we might consider to use the GTK+ positions to make
the appearance more similar. We might also add min/max labels to
the GTK+ control by making it composite of wxSL_MIN_MAX_LABELS is
used. I forgot again how labels are handled under OSX/Cocoa and
or OSX/Cocoa, but it would be nice to get the same options there.
But before adding min/max labels everywhere, having a wxSL_LABEL
option with just the current value in all ports would already
be an improvement, I think. Users have probably been surprised
or annoyed that the control uses greatly differing amounts of
space under different ports (it already annoyed me).
Robert
Vadim Zeitlin
RR> Since the position of the labels is not specified by any "default"
RR> under MSW, we might consider to use the GTK+ positions to make
RR> the appearance more similar.
But GTK+ doesn't have any standard positions neither except for the
current label AFAICS.
RR> We might also add min/max labels to
RR> the GTK+ control by making it composite of wxSL_MIN_MAX_LABELS is
RR> used.
Yes, this would be definitely the right thing to do anyhow as now GTK is
different from both MSW and OSX.
RR> I forgot again how labels are handled under OSX/Cocoa and
RR> or OSX/Cocoa, but it would be nice to get the same options there.
I still didn't test it myself but we do everything manually these too so
we could change it to behave as we want.
We probably also need to refactor the code to move the management of at
least the min/max labels to the common code, no sense to duplicate them in
all ports...
RR> But before adding min/max labels everywhere, having a wxSL_LABEL
RR> option with just the current value in all ports would already
RR> be an improvement, I think. Users have probably been surprised
RR> or annoyed that the control uses greatly differing amounts of
RR> space under different ports (it already annoyed me).
Yes, me too, and I definitely agree that having wxSL_LABEL would be an
improvement. Min/max labels can always be added by hand if necessary but
currently you just can't get the same behaviour under all platforms if you
want any labels at all. I've created http://trac.wxwidgets.org/ticket/11427
to avoid forgetting about this (which doesn't mean that we shouldn't
continue discussing it further, of course, but AFAICS we all pretty much
agree on what needs to be done already).
Regards,
VZ
Ed Musgrove
Please look below in the quoted text for questions and comments...
>
> On Mon, 09 Nov 2009 13:26:38 +0100 Robert Roebling wrote:
>
> RR> Since the position of the labels is not specified by any "default"
> RR> under MSW, we might consider to use the GTK+ positions to make
> RR> the appearance more similar.
> But GTK+ doesn't have any standard positions neither except for the
> current label AFAICS.
Is there any "standard" in the GTK (Linux??) world of apps? How about the Mac apps?
> RR> having an...option with just the current value in all ports would already
> RR> be an improvement
> Yes, me too [VZ -ed.][_____ --Ed _____] Me too.
This will probably look really ugly:This is the constructor as shown in the manual right now:
wxSlider(wxWindow* parent, wxWindowID id, int value , int minValue,
int maxValue, const wxPoint& point = wxDefaultPosition,
const wxSize& size = wxDefaultSize, long style = wxSL_HORIZONTAL,
const wxValidator& validator = wxDefaultValidator, const wxString& name = "slider")
This is my first attempt at a new constructor:
wxSlider(wxWindow* parent, wxWindowID id, int value , int minValue,
int maxValue, const wxPoint& point = wxDefaultPosition,
const wxSize& size = wxDefaultSize, long style = wxSL_HORIZONTAL,
const wxValidator& validator = wxDefaultValidator, const wxString& name = wxEmptyString,
const valuePosition = wxTopPosition, const bool& minMaxPosition = wxEndsPosition)
discussion (keep everything the same until here:)
const wxString& name = "slider" ==> const wxString& name = wxEmptyString
just thinking here...would this break older apps? The slider's "name" might
be unnecessary if it's use is obvious from context.
const valuePosition = wxTopPosition
wxLeftPosition == GTK_POS_LEFT The feature is at the left edge.
wxRightPosition == GTK_POS_RIGHT The feature is at the right edge.
wxTopPosition (could this be somehow equivalent to wxDefaultPosition?)
== GTK_POS_TOP The feature is at the top edge.
wxBottomPosition == GTK_POS_BOTTOM
wxNoShowValue (there probably already exists some other wx defined
equivalent I am guessing that wxTopPosition et al or their
equivalents already exist)
const bool& minMaxPosition = wxEndsPosition
wxEndsMinMaxPosition, min top/left to accommodate gtk_range_set_inverted ()
wxEndsMaxMinPosition, max top/left
wxTopPosition, wxBottomPosition, wxNoShowValue as above
>http://trac.wxwidgets.org/ticket/11427
-Ed Musgrove
Kevin Ollivier
I don't, but it doesn't matter, because you're stepping through sizes
in points, not pixels (the size you're trying to find). How many
pixels are in a point (or vice versa) is dependent on what the
device's DPI is, and hence so too is the function's accuracy in
finding the right point size to match a pixel.
If the DPI is 72, this should be somewhat accurate, but imagine if the
DPI is larger than 100, or even something like 600, as a print device
may have. (And AFAICT this method would be used with fonts set for
wxPrinterDC too.) At 600 DPI, for example, 1 pixel is 0.0016 inches. A
point, however, is 0.0138 inches. So in that case, going from a size
of 1 point to 2 points jumps from 0.0138 to 0.0276, which is about 13
pixel sizes, meaning you'll never get much closer than 10 pixel sizes
or so to the pixel size one you want. Even at 96 DPI, it's 0.0104 in,
meaning that for every three point sizes you iterate over, you jump
1.3 pixels. And since DPI varies from machine to machine, and can even
be changed by the user in some cases, the results you get on your
machine won't necessarily match those on a different user's machine,
meaning it can "look right to you" then you ship it out and some user
is complaining that the font sizes are weird. I bet if you replaced
wxMSW's native support with this method, you'd find the results to be
unsatisfactory, particularly when the user changed their system DPI.
Regards,
Kevin
> Regards,
> VZ
Vadim Zeitlin
KO> > KO> How do you determine which size in points is closest to the pixel
KO> > KO> value without even knowing what DPI the pixels are being
KO> > measured in?
KO> >
KO> > wxDC::GetCharHeight() knows it hopefully and this is what this code
KO> > uses. I do assume GetCharHeight() works correctly but AFAIK this is
KO> > the case, do you have any reason to believe it doesn't?
KO>
KO> I don't, but it doesn't matter, because you're stepping through sizes
KO> in points, not pixels (the size you're trying to find).
Ok, yes, it's imprecise, I do agree with this. I thought you saw some
other problem with it.
Anyhow, I definitely agree that it would be better to support creation of
fonts from pixel size directly. Again, for GTK it seems Pango does support
it (but I didn't have time to test your suggestion yet) but I have no idea
about Mac, especially considering that I don't know which font/text/
typography API should be used for which OS version and all that...
Regards,
VZ
Vadim Zeitlin
EM> Is there any "standard" in the GTK (Linux??) world of apps?
It seems that the standard is to use the current label only, see the
screenshots at http://library.gnome.org/devel/gtk/unstable/GtkScale.html
which I had already mentioned.
EM> How about the Mac apps?
I don't know... I'd really appreciate input from anybody more familiar
than me with OS X UI here.
EM> This is my first attempt at a new constructor:
EM> wxSlider(wxWindow* parent, wxWindowID id, int value , int minValue,
EM> int maxValue, const wxPoint& point = wxDefaultPosition,
EM> const wxSize& size = wxDefaultSize, long style = wxSL_HORIZONTAL,
EM> const wxValidator& validator = wxDefaultValidator, const wxString& name = wxEmptyString,
EM> const valuePosition = wxTopPosition, const bool& minMaxPosition = wxEndsPosition)
Sorry, why exactly do we need a new constructor? Surely things like labels
presence and/or positioning are exactly what the styles are used for in wx
API so we just need to add more wxSL_XXX constants. And adding yet more
parameters to an already long ctor arguments list should really be avoided
if possible.
Regards,
VZ
Ed Musgrove
> Sent: Mon, November 9, 2009 6:06:41 PM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
> EM> Is there any "standard" in the GTK (Linux??) world of apps?
>
> It seems that the standard is to use the current label only, see the
> screenshots at http://library.gnome.org/devel/gtk/unstable/GtkScale.html
> which I had already mentioned.
>
> EM> How about the Mac apps?
>
> I don't know... I'd really appreciate input from anybody more familiar
> than me with OS X UI here.
>
Let me ask one of the Audacity Mac beta testers...
> EM> This is my first attempt at a new constructor:
> EM> wxSlider(wxWindow* parent, wxWindowID id, int value , int minValue,
> EM> int maxValue, const wxPoint& point = wxDefaultPosition,
> EM> const wxSize& size = wxDefaultSize, long style = wxSL_HORIZONTAL,
> EM> const wxValidator& validator = wxDefaultValidator, const wxString& name =
> wxEmptyString,
> EM> const valuePosition = wxTopPosition, const bool& minMaxPosition =
> wxEndsPosition)
>
> Sorry, why exactly do we need a new constructor? Surely things like labels
> presence and/or positioning are exactly what the styles are used for in wx
> API so we just need to add more wxSL_XXX constants. And adding yet more
> parameters to an already long ctor arguments list should really be avoided
> if possible.
>
Certainly, putting everything in "style" via constants is fine. The only real problem I find with that is the possibility that the programmer can accidentally used two value constants or two range constants instead of one of each. I understand that in the days of limited RAM and small hard drives doing a lot with a little made sense. Since the advent of C++ and the ability to have multiple constructors, I lean toward adding a new constructor especially when it is a situation like this one. How about this then:
wxSL_VALUE_TOP (Centered)
wxSL_VALUE_BOTTOM (Centered)
wxSL_VALUE_LEFT
wxSL_VALUE_RIGHT
(if none of the above then do not show value)
wxSL_MIN_MAX_ENDS
wxSL_MIN_MAX_TOP
wxSL_MIN_MAX_BOTTOM
wxSL_MAX_MIN_ENDS
wxSL_MAX_MIN_TOP
wxSL_MAX_MIN_BOTTOM
(if none of the above then do not show ranges)
-Ed Musgrove
>
> Regards,
> VZ
Vadim Zeitlin
EM> Certainly, putting everything in "style" via constants is fine. The
EM> only real problem I find with that is the possibility that the
EM> programmer can accidentally used two value constants or two range
EM> constants instead of one of each. I understand that in the days of
EM> limited RAM and small hard drives doing a lot with a little made sense.
EM> Since the advent of C++ and the ability to have multiple constructors,
EM> I lean toward adding a new constructor especially when it is a
EM> situation like this one.
Few wx GUI classes have multiple constructors and, in any case, the main
problem I have with this approach is not that there is a new ctor but that
this ctor has a dozen or so arguments. This is IMO unusable, no function
should take more than 6-7 of them (and if possible much less).
EM> How about this then:
EM>
EM> wxSL_VALUE_TOP (Centered)
EM> wxSL_VALUE_BOTTOM (Centered)
EM> wxSL_VALUE_LEFT
EM> wxSL_VALUE_RIGHT
EM> (if none of the above then do not show value)
EM> wxSL_MIN_MAX_ENDS
EM> wxSL_MIN_MAX_TOP
EM> wxSL_MIN_MAX_BOTTOM
EM> wxSL_MAX_MIN_ENDS
EM> wxSL_MAX_MIN_TOP
EM> wxSL_MAX_MIN_BOTTOM
EM> (if none of the above then do not show ranges)
Sorry, this sounds needlessly complicated to me. IMO we just need
wxSL_LABEL and wxSL_MIN_MAX_LABELS (with wxSL_LABELS defined as their sum
for compatibility) and the positioning should be chosen by the library as
appropriate for the platform.
Regards,
VZ
Ed Musgrove
----- Original Message ----
> From: Vadim Zeitlin <va...@wxwidgets.org>
> To: wx-...@googlegroups.com
> Sent: Tue, November 10, 2009 9:50:53 AM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
> EM> Certainly, putting everything in "style" via constants is fine...
> EM> I lean toward adding a new constructor especially when it is a
> EM> situation like this one.
>
> Few wx GUI classes have multiple constructors and, in any case, the main
> problem I have with this approach is not that there is a new ctor but that
> this ctor has a dozen or so arguments. This is IMO unusable, no function
> should take more than 6-7 of them (and if possible much less).
>
defaults and can be ignored most of the time. It is certainly no big deal to me.
> IMO we just need
> wxSL_LABEL and wxSL_MIN_MAX_LABELS (with wxSL_LABELS defined as their sum
> for compatibility) and the positioning should be chosen by the library as
> appropriate for the platform.
OK, though part of the problem is there is no obvious "appropriate for the platform" it seems.
One minor change I would make for clarity:
wxSL_LABEL ==> wxSL_VALUE_LABEL
-Ed
Vadim Zeitlin
EM> > IMO we just need
EM> > wxSL_LABEL and wxSL_MIN_MAX_LABELS (with wxSL_LABELS defined as their sum
EM> > for compatibility) and the positioning should be chosen by the library as
EM> > appropriate for the platform.
EM>
EM> OK, though part of the problem is there is no obvious "appropriate for
EM> the platform" it seems.
Yes, but we need to solve it in some way inside wx instead of forcing each
and every programmer using it to solve it himself. Besides, implementing
just one positioning is much simpler than supporting all of them too.
EM> One minor change I would make for clarity:
EM> wxSL_LABEL ==> wxSL_VALUE_LABEL
Yes, I agree, it's a better name.
Regards,
VZ
Ed Musgrove
> From: Vadim Zeitlin <va...@wxwidgets.org>
> Sent: Tue, November 10, 2009 11:23:18 AM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
> and every programmer using it to solve it himself. Besides, implementing
> just one positioning is much simpler than supporting all of them too.
>
> EM> One minor change I would make for clarity:
> EM> wxSL_LABEL ==> wxSL_VALUE_LABEL
>
> Yes, I agree, it's a better name.
OK,here is my take on this:
If you look back at the pictures on the forum you will see that the current sliderpanel
has at least one full line of blank space above the currenttext (and since we are
moving the range text down it is really two full lines) we could leave the value
text right where it is and even recoup some of the "wasted" space that is
currently there.
(max)
|
|
|
|
| value
|
|
> |
|
|
(min)
or
(max)
|
|
|
|
value |
|
|
|<
|
|
(min)
Minimum Value is always on the bottom and Maximum Value is always on the
top but the programmer has the option not to display those at all.
Value is always opposite the slider knob (I have not seen a vertical
wxSlider implemented) and is always centered; no option to
display -- always displayed.
value
(min) ---------------------------------- ---- (max)
^
Minimum Value is always on the left and Maximum Value is always on the right but the programmer has the option not to display those at all.
Value is always above (opposite) the slider knob and is always centered; no option
to display -- always displayed.
-Ed Musgrove
Vadim Zeitlin
EM> OK,here is my take on this:
This is fine with me, somebody will probably like something else more but
if you can implement this layout you'd definitely have a big advantage over
whoever else suggesting something else :-)
The important thing is to make the display less confusing and, also, to
make behaviour more consistent between ports. I'm sure that if we need to
slightly adjust positions later it wouldn't be a big problem to do it.
Any patches (please read http://trac.wxwidgets.org/wiki/HowToSubmitPatches
if you hadn't submitted patches to wx before) implementing this would be
gratefully accepted, please just attach them to the previously mentioned
ticket.
TIA,
VZ
rob...@roebling.de
Hi,
Please note that the native GTK+ control displays
the current value on top (in the case of a vertical
slider) or to the right (otherwise) so this layout
cannot be done there. Put differently, if we only
have the wxSL_VALUE_LABEL but not the min/max
labels, I suggest to use the GTK+ layout for all
platforms.
Ed wrote:
>>>>
(max)
|
|
|
|
| value
|
|
> |
|
|
(min)
Ed Musgrove
Thanks Robert, I see what you mean. It's probably the best choice. Will head that way.
Attached is a little picture (is that cool with the list?) mock-up for Windows and GTX+. Currently I cannot compile for Mac and Linux.
-Ed Musgrove
----- Original Message ----
> From: "rob...@roebling.de" <rob...@roebling.de>
> To: wx-...@googlegroups.com
> Sent: Tue, November 10, 2009 11:28:29 PM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
>
iko...@earthlink.net
If you look at the Windows desktop properties property sheet for the
screen resilution control you will see that selecting the control with
mouse will draw the focus rectangle only around the slider itself,
leaving all texts out.
Will it be the same in you implementation?
I don't know what the GTK+ behavior here is, but I can reboot the machine
and check...
Thank you.
Vadim Zeitlin
EM> Thanks Robert, I see what you mean. It's probably the best choice.
EM> Will head that way.
Sorry, I still have a couple of comments:
1. "Name" label shouldn't be included in wxSlider API at all, it's easy
enough to just create a standalone wxStaticText nearby. We need just
the min/max ones (and maybe an optional middle one?) and the current
value label.
2. You won't be able to implement it like this under GTK+ in vertical
layout as the current value will always be directly near the slider, so
it will rather look like
000 123
123 000
--- ---
| |
| |
| (and not like | that you showed)
| |
| |
| |
--- ---
999 999
This probably will look confusing in either case so maybe it's worth
putting the min/max labels on the side in vertical case? OTOH I think
very few sliders are vertical and use these labels so maybe it doesn't
matter anyhow.
EM> Attached is a little picture (is that cool with the list?)
(Generally only very small pictures are, larger ones should be uploaded
somewhere and a link to them provided).
Thanks,
VZ
Ed Musgrove
the screen resilution control". Is this something in the wxWidgets examples/sample
folder? I think I see what you are talking about. If you click on the knob
or press tab enough times to cycle around to where the slider has focus,a
rectangle is drawn around the slider gadget which excludes the text. I would
expect to maintain the exact same behavior, although, like you I have no idea
what happens on GTK+, not to mention Mac.
I am a (very junior) developer with the Audacity software team. We use
wxWidgets's wxSlider in at least one place; I think we might be building the
text ourselves. If so, we are not doing a very good job of it as the
implementation the user sees is confusing. It does update the value text as
the knob is being moved.
The major problem is that the range text and the value text are all on one
line above the slider and it can almost look like one big long number; at
first glance it looks like the value is the center range label. It looks
something like this:
-Ed Musgrove
----- Original Message ----
> From: "iko...@earthlink.net" <iko...@earthlink.net>
> To: wx-...@googlegroups.com; wx-...@googlegroups.com
> Sent: Wed, November 11, 2009 9:28:05 AM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
123 456 987
------^------
Ed Musgrove
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
> EM> Thanks Robert, I see what you mean. It's probably the best choice.
> EM> Will head that way.
>
> Sorry, I still have a couple of comments:
>
> 1. "Name" label shouldn't be included in wxSlider API at all, it's easy
> enough to just create a standalone wxStaticText nearby. We need just
> the min/max ones (and maybe an optional middle one?) and the current
> value label.
>
things out before code is written.
Here is the current constructor:
wxSlider(wxWindow* parent, wxWindowID id, int value , int minValue,
int maxValue, const wxPoint& point = wxDefaultPosition,
const wxSize& size = wxDefaultSize, long style = wxSL_HORIZONTAL,
const wxValidator& validator = wxDefaultValidator, const wxString& name = "slider")
Note that the very last itemis "name". I was assuming, since it was part of the constructor
> 2. You won't be able to implement it like this under GTK+ in vertical
> layout as the current value will always be directly near the slider, so
> it will rather look like
>
> 000 123
> 123 000
> --- ---
> | |
> | |
> | (and not like | that you showed)
> | |
> | |
> | |
> --- ---
> 999 999
>
> This probably will look confusing in either case so maybe it's worth
> putting the min/max labels on the side in vertical case? OTOH I think
> very few sliders are vertical and use these labels so maybe it doesn't
> matter anyhow.
>
I see what you're saying and wondered about that. If there is no way to adjust the spacing in GTK+ then forcing the range value labeling to the side seems the best. We could get tricky (but I don't think I like it):
> (Generally only very small pictures are, larger ones should be uploaded
> somewhere and a link to them provided).
>
> Thanks,
> VZ
500
1 |
2 |
3 |
|
|
>|<
|
|
9 |
9 |
9 |
I can post images on my website and provide links to them -- will do that from now on.
-Ed Musgrove
that we would deal with it. Personally, I think we should, but, being lazy I will not argue
the point.
iko...@earthlink.net
-----Original Message-----
>From: Ed Musgrove <edgarm...@yahoo.com>
>Sent: Nov 11, 2009 5:57 PM
>To: wx-...@googlegroups.com
>Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
>I am not sure what you mean by "Windows desktop properties property sheet for
>the screen resilution control". Is this something in the wxWidgets examples/sample
>folder? I think I see what you are talking about. If you click on the knob
>or press tab enough times to cycle around to where the slider has focus,a
>rectangle is drawn around the slider gadget which excludes the text. I would
>expect to maintain the exact same behavior, although, like you I have no idea
>what happens on GTK+, not to mention Mac.
If you in Windows minimize all you open windows you will see a desktop.
Now right-click anywhere on empty space. In the popup menu, select "Properties"
In the property sheet dialog that will be shown select "Settings" sheet.
There you will see a slider inside "Screen Resolution" box.
The minimal value is written a little to the left and top of the control
(word "Less"), and the maximum value written a little right and top of the
control (word "More"). There is also a "current value" text that is written
underneath the control itself and it's cenetered (mine says "1280x800pixels").
If you click on the slider knob only the slder will have the focus rectangle,
all surrounding text will be outside of this rectangle.
The same behavior can be seen if you go to "Start"->"Control Panel"->
"Sound And Audio Devices". On the very first sheet "Volume", there is a
slider with just minimum and maximum values, but they located right
underneath the control and centered by the left and right margin of it.
But again selecting the slider by mouse shows the focus rectangle
drawn around slider only and the labels are outside of it.
Thank you.
>
>I am a (very junior) developer with the Audacity software team. We use
>wxWidgets's wxSlider in at least one place; I think we might be building the
>text ourselves. If so, we are not doing a very good job of it as the
>implementation the user sees is confusing. It does update the value text as
>the knob is being moved.
>
>The major problem is that the range text and the value text are all on one
>line above the slider and it can almost look like one big long number; at
>first glance it looks like the value is the center range label. It looks
>something like this:
>-Ed Musgrove
>
>
>
>----- Original Message ----
>> From: "iko...@earthlink.net" <iko...@earthlink.net>
>> To: wx-...@googlegroups.com; wx-...@googlegroups.com
>> Sent: Wed, November 11, 2009 9:28:05 AM
>> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>>
>>
>> Hi, Ed,
>> If you look at the Windows desktop properties property sheet for the
>> screen resilution control you will see that selecting the control with
>> mouse will draw the focus rectangle only around the slider itself,
>> leaving all texts out.
>>
>> Will it be the same in you implementation?
>>
>> I don't know what the GTK+ behavior here is, but I can reboot the machine
>> and check...
>>
>> Thank you.
>>
>> -----Original Message-----
>> >From: Ed Musgrove
>> >Sent: Nov 11, 2009 8:25 AM
>> >To: wx-...@googlegroups.com
>> >Subject: [wx-dev] Re: wxSlider minor GUI improvement
>> >
>> >
>> >Thanks Robert, I see what you mean. It's probably the best choice. Will head
>> that way.
>> >
>> >Attached is a little picture (is that cool with the list?) mock-up for Windows
>> and GTX+. Currently I cannot compile for Mac and Linux.
>> >-Ed Musgrove
>> >
>> >
>> >
>> >----- Original Message ----
>> >> From: "rob...@roebling.de"
>> >> To: wx-...@googlegroups.com
>> >> Sent: Tue, November 10, 2009 11:28:29 PM
>> >> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>> >>
>> >>
>> >>
Vadim Zeitlin
EM> Here is the current constructor:
EM>
EM> wxSlider(wxWindow* parent, wxWindowID id, int value , int minValue,
EM> int maxValue, const wxPoint& point = wxDefaultPosition,
EM> const wxSize& size = wxDefaultSize, long style = wxSL_HORIZONTAL,
EM> const wxValidator& validator = wxDefaultValidator, const wxString& name = "slider")
EM>
EM> Note that the very last itemis "name". I was assuming, since it was part of the constructor
This name is internally used unique identifier of the object and doesn't
refer to any GUI element, in particular it's completely separate from the
label or title, so don't let this confuse you.
EM> I see what you're saying and wondered about that. If there is no way to
EM> adjust the spacing in GTK+
Actually looking at http://library.gnome.org/devel/gtk/unstable/GtkScale.html
one again I see gtk_scale_set_value_pos() there. And I just tested it and
it works fine, i.e. we can use it with GTK_POS_LEFT to position the label
in the left of the (vertical) slider. IOW we can have exactly the same look
as under Windows with GTK.
EM> then forcing the range value labeling to the side seems the best. We
EM> could get tricky (but I don't think I like it):
EM>
EM> 500
EM> 1 |
EM> 2 |
EM> 3 |
EM> |
EM> |
EM> >|<
EM> |
EM> |
EM> 9 |
EM> 9 |
EM> 9 |
No, please let's not do this.
Regards,
VZ
Ed Musgrove
Still, I am almost certain I understand what you mean. When the slider has focus, the focus rectangle does not include the text for the range values nor the current value. This behavior will be maintained.
-Ed Musgrove
----- Original Message ----
> From: "iko...@earthlink.net" <iko...@earthlink.net>
> To: wx-...@googlegroups.com; wx-...@googlegroups.com
> Sent: Wed, November 11, 2009 4:17:32 PM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
Ed Musgrove
> From: Vadim Zeitlin va...@wxwidgets.org
> Sent: Wed, November 11, 2009 5:31:00 PM
> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
> EM> Here is the current constructor:
> EM>
> EM> I was assuming
Bad on me!
> This name is internally used unique identifier of the object
>
> Actually looking at http://library.gnome.org/devel/gtk/unstable/GtkScale.html
> one again I see gtk_scale_set_value_pos() there. And I just tested it and
> it works fine, i.e. we can use it with GTK_POS_LEFT to position the label
> in the left of the (vertical) slider. IOW we can have exactly the same look
> as under Windows with GTK.
Great.
> EM> We could get tricky (but I don't think I like it):
>
> No, please let's not do this.
Thank you for the sanity check!
Audacity is days away from a stable release. We are all working very hard on that right now. As soon as things slow down a bit I will dig into the wxWidgets code and see what I can learn.
-Ed Musgrove
iko...@earthlink.net
-----Original Message-----
>From: Ed Musgrove <edgarm...@yahoo.com>
>Sent: Nov 12, 2009 12:09 AM
>To: wx-...@googlegroups.com
>Subject: [wx-dev] Re: wxSlider minor GUI improvement
>
>
>I am running Windows 7 with an ATI Radeon 3870 graphics cardand an AudioFire external FireWire sound pod. With this configuration I do not have access to either of the two Control Panel items that you mention.
>
>Still, I am almost certain I understand what you mean. When the slider has focus, the focus rectangle does not include the text for the range values nor the current value. This behavior will be maintained.
> -Ed Musgrove
What is the current behavior of the GTK+ applications in regards to this?
And how the Mac behaves?
If the behavior is not the same as on Windows, should we preserve it?
Thank you.
>
>
>
>----- Original Message ----
>> From: "iko...@earthlink.net" <iko...@earthlink.net>
>> To: wx-...@googlegroups.com; wx-...@googlegroups.com
>> Sent: Wed, November 11, 2009 4:17:32 PM
>> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>>
>>
>> Ed,
>>
>> -----Original Message-----
>> >From: Ed Musgrove
>> >Sent: Nov 11, 2009 5:57 PM
>> >To: wx-...@googlegroups.com
>> >Subject: [wx-dev] Re: wxSlider minor GUI improvement
>> >
>> >
>> >----- Original Message ----
>> >> From: "iko...@earthlink.net"
>> >> To: wx-...@googlegroups.com; wx-...@googlegroups.com
>> >> Sent: Wed, November 11, 2009 9:28:05 AM
>> >> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>> >>
>> >>
>> >> Hi, Ed,
>> >> If you look at the Windows desktop properties property sheet for the
>> >> screen resilution control you will see that selecting the control with
>> >> mouse will draw the focus rectangle only around the slider itself,
>> >> leaving all texts out.
>> >>
>> >> Will it be the same in you implementation?
>> >>
>> >> I don't know what the GTK+ behavior here is, but I can reboot the machine
>> >> and check...
>> >>
>> >> Thank you.
>> >>
>> >> -----Original Message-----
>> >> >From: Ed Musgrove
>> >> >Sent: Nov 11, 2009 8:25 AM
>> >> >To: wx-...@googlegroups.com
>> >> >Subject: [wx-dev] Re: wxSlider minor GUI improvement
>> >> >
>> >> >
>> >> >Thanks Robert, I see what you mean. It's probably the best choice. Will
>> head
>> >> that way.
>> >> >
>> >> >Attached is a little picture (is that cool with the list?) mock-up for
>> Windows
>> >> and GTX+. Currently I cannot compile for Mac and Linux.
>> >> >-Ed Musgrove
>> >> >
>> >> >
>> >> >
>> >> >----- Original Message ----
>> >> >> From: "rob...@roebling.de"
>> >> >> To: wx-...@googlegroups.com
>> >> >> Sent: Tue, November 10, 2009 11:28:29 PM
>> >> >> Subject: [wx-dev] Re: wxSlider minor GUI improvement
>> >> >>
>> >> >>
>> >> >>
Robert Roebling
Hi,
after some playing with various layouts, I've now implemented
the following under GTK+. The code is easy to change and I'm
not opposed to different suggestions, but I'd prefer it like
this:
With wxSL_VALUE_LABEL and wxSL_MIN_MAX_LABEL
> --- 0
> |
> 2 |
> |
> |
> |
> |
> --- 10
Only wxSL_MIN_MAX_LABEL
> --- 0
> |
> |
> |
> |
> |
> |
> --- 10
Only wxSL_VALUE_LABEL
> 2
> ---
> |
> |
> |
> |
> |
> |
> ---
Robert Roebling
Ed Musgrove wrote:
> [...] confusion over the labeling of the range of the wxSlider.
>
> http://wxforum.shadonet.com/viewtopic.php?t=26025
I've just changed the MSW code minimally so that you can
choose to just not show either the "value" or the "min/max"
fields. I didn't touch the positioning as I'm really not
sure what the best solution is, especially if you have
both ticks below the slider and min/max fields above it -
as in your example.
Robert
Vadim Zeitlin
RR> after some playing with various layouts, I've now implemented
RR> the following under GTK+. The code is easy to change and I'm
RR> not opposed to different suggestions, but I'd prefer it like
RR> this:
RR>
RR> With wxSL_VALUE_LABEL and wxSL_MIN_MAX_LABEL
RR>
RR> > --- 0
RR> > |
RR> > 2 |
RR> > |
RR> > |
RR> > |
RR> > |
RR> > --- 10
RR>
RR> Only wxSL_MIN_MAX_LABEL
RR>
RR> > --- 0
RR> > |
RR> > |
RR> > |
RR> > |
RR> > |
RR> > |
RR> > --- 10
Those look perfect, thanks!
RR> Only wxSL_VALUE_LABEL
RR>
RR> > 2
RR> > ---
RR> > |
RR> > |
RR> > |
RR> > |
RR> > |
RR> > |
RR> > ---
Is there any reason to not position the label on the left in this case? I
think it goes beyond subjective preference (which I certainly have for the
leftward position): why should the meaning of one flag (wxSL_VALUE_LABEL)
be influenced by the presence or absence of another one? AFAIK no other
flags work like this in wx...
Other than that I think we also need to have the new styles in
src/xrc/xh_slidr.cpp. And it would be great to have the possibility to
select them in samples/widgets/slider.cpp to test/see them in action.
And maybe we should remove wxSL_{LEFT,TOP,RIGHT,BOTTOM} from it as they
don't work anyhow (and don't seem particularly useful).
Thanks,
VZ
Robert Roebling
Vadim Zeitlin wrote:
> RR> Only wxSL_VALUE_LABEL
> RR>
> RR> > 2
> RR> > ---
> RR> > |
> RR> > |
> RR> > |
> RR> > |
> RR> > |
> RR> > |
> RR> > ---
>
> Is there any reason to not position the label on the left
It seems to be something like a GTK+ default, no other reason.
> And it would be great to have the possibility to
> select them in samples/widgets/slider.cpp to test/see
> them in action.
I already did that.
> And maybe we should remove wxSL_{LEFT,TOP,RIGHT,BOTTOM}
> from it as they don't work anyhow
They do work (for positioning the ticks under MSW).
Robert
Vadim Zeitlin
RR> Vadim Zeitlin wrote:
RR>
RR> > RR> Only wxSL_VALUE_LABEL
RR> > RR>
RR> > RR> > 2
RR> > RR> > ---
RR> > RR> > |
RR> > RR> > |
RR> > RR> > |
RR> > RR> > |
RR> > RR> > |
RR> > RR> > |
RR> > RR> > ---
RR> >
RR> > Is there any reason to not position the label on the left
RR>
RR> It seems to be something like a GTK+ default, no other reason.
My hypothesis is that GTK+ uses GTK_POS_TOP as default position and it
does it because it's the natural choice for horizontal sliders which are
IME more common than vertical ones. I think it would make more sense to use
GTK_POS_LEFT for vertical orientation, especially considering that we
already do if wxSL_MIN_MAX_LABELS is used.
RR> > And it would be great to have the possibility to
RR> > select them in samples/widgets/slider.cpp to test/see
RR> > them in action.
RR>
RR> I already did that.
Either I am blind or you forgot to commit it because I had grepped the
sample for the new constants before and I rebuilt and ran it now and I
don't see them there...
RR> > And maybe we should remove wxSL_{LEFT,TOP,RIGHT,BOTTOM}
RR> > from it as they don't work anyhow
RR>
RR> They do work (for positioning the ticks under MSW).
Yes, sorry, I meant "don't work under all ports". OTOH there is probably
no harm in keeping them for MSW only...
Regards,
VZ
Robert Roebling
Vadim Zeitlin wrote:
> I think it would make more sense to use GTK_POS_LEFT for
> vertical orientation, especially considering that we
> already do if wxSL_MIN_MAX_LABELS is used.
OK, I just did that.
> RR> > And it would be great to have the possibility to
> RR> > select them in samples/widgets/slider.cpp to see
> RR> > them in action.
> RR>
> RR> I already did that.
>
> Either I am blind or you forgot to commit it
Ah, commited now.
Robert
Vadim Zeitlin
RR> > RR> > And it would be great to have the possibility to
RR> > RR> > select them in samples/widgets/slider.cpp to see
RR> > RR> > them in action.
RR> > RR>
RR> > RR> I already did that.
RR> >
RR> > Either I am blind or you forgot to commit it
RR>
RR> Ah, commited now.
Sorry but now I do see the checkboxes but I don't see the label(s). At
all. Do they work for you?
FWIW my GTK+ version is 2.12, I can test with 2.18 too if it can be
useful.
Thanks,
VZ
Robert Roebling
Vadim Zeitlin wrote:
> RR> > RR> > And it would be great to have the possibility to
> RR> > RR> > select them in samples/widgets/slider.cpp to see
> RR> > RR> > them in action.
> RR> > RR>
> RR> > RR> I already did that.
> RR> >
> RR> > Either I am blind or you forgot to commit it
> RR>
> RR> Ah, commited now.
>
> Sorry but now I do see the checkboxes but I don't see the label(s).
Hm, I just corrected a small problem, but I did see the labels
even before. You should see lots of label code in gtk/slider.cpp
Robert
Vadim Zeitlin
RR> Hm, I just corrected a small problem, but I did see the labels
RR> even before. You should see lots of label code in gtk/slider.cpp
Sorry, apparently I was on a wrong branch when I rebuilt or something like
this. I do see them now. It's a pity the top/left/right/bottom radio items
in the sample didn't do anything though so I quickly implemented support
for them -- not terribly useful probably but OTOH why not have consistent
behaviour across all platforms.
BTW, wxSL_LEFT &c names are rather confusing as it's the _ticks_ (not
shown by GTK version at all) which are on the left and the labels are
actually on the _right_ when this style is used. Maybe we should rename it
(and the other ones) to something like wxSL_TICKS_LEFT to make it more
clear?
I also wonder what should happen if wxSL_VERTICAL is combined with
wxSL_TOP... This doesn't seem to make any sense, I think we could just
redefine wxSL_VERTICAL as wxSL_LEFT for compatibility and get rid of it
completely.
Regards,
VZ
Ed Musgrove
From: Vadim Zeitlin <vadim@...>
Subject: Re: wxSlider minor GUI improvement
Date: 2009-11-14 23:09:36 GMT (2 weeks, 1 day and 24 minutes ago)
Vadim wrote:
<BTW, wxSL_LEFT &c names are rather confusing as it's the _ticks_ (not
<shown by GTK version at all) which are on the left and the labels are
<actually on the _right_ when this style is used. Maybe we should rename it
<(and the other ones) to something like wxSL_TICKS_LEFT to make it more
<clear?
Is this what you had in mind? And do we need to retain the old values for backwards compatibility, as I do here?
#define wxSL_TICKS 0x0010
#define wxSL_AUTOTICKS wxSL_TICKS // we don't support manual ticks
#define wxSL_TICKS_LEFT 0x0040
#define wxSL_LEFT 0x0040 //backwards compatible
#define wxSL_TICKS_TOP 0x0080
#define wxSL_TOP 0x0080
#define wxSL_TICKS_RIGHT 0x0100
#define wxSL_RIGHT 0x0100
#define wxSL_TICKS_BOTTOM 0x0200
#define wxSL_BOTTOM 0x0200
#define wxSL_TICKS_BOTH 0x0400
#define wxSL_BOTH 0x0400
-Ed Musgrove
Vadim Zeitlin
EM> Vadim wrote:
EM> >BTW, wxSL_LEFT &c names are rather confusing as it's the ticks (not
EM> >shown by GTK version at all) which are on the left and the labels are
EM> >actually on the right when this style is used. Maybe we should rename it
EM> >(and the other ones) to something like wxSL_TICKS_LEFT to make it more
EM> >clear?
EM>
EM> Is this what you had in mind?
Yes (but we'd also need to update the documentation, of course). I think
wxSL_TICKS_XXX names are more clear.
EM> And do we need to retain the old values
EM> for backwards compatibility, as I do here?
Keeping them can't hurt so unless there is a good reason to change the
values let's indeed preserve them.
EM> #define wxSL_TICKS 0x0010
EM> #define wxSL_AUTOTICKS wxSL_TICKS // we don't support manual ticks
EM> #define wxSL_TICKS_LEFT 0x0040
EM> #define wxSL_LEFT 0x0040 //backwards compatible
I'd define wxSL_LEFT as wxSL_TICKS_LEFT instead of reusing the constant.
Thanks,
VZ