Menu
▾
▴
bitpim-devel
|
From: Tom P. <mlp...@ea...> - 2004-03-14 14:20:19
|
Hi,
Running the current CVS version of bitpim under MacOSX 10.3 with
WxPython 2.4.2.4, I find that the phonebook entry-details view is
unreadable, because the font sizes are too small. First, is it really
just me, or do other people suffer from this, too? Second, it wasn't
obvious to me where in the code (or .xy files) this should be fixed.
But, I found that if I just removed the smallest two font sizes from
the basefonts list in the SetFontScale method of bphtml, things looked
ok in the details view without affecting the appearance anywhere else,
as far as I could notice. Here are the code changes I propose...
diff -w -c -r1.12 bphtml.py
*** bphtml.py 12 Mar 2004 19:42:34 -0000 1.12
--- bphtml.py 14 Mar 2004 13:42:09 -0000
***************
*** 43,53 ****
self.SetFontScale(relsize)
def SetFontScale(self, scale):
! # default sizes on windows
! basefonts=[7,8,10,12,16,22,30]
! # defaults on linux
if guihelper.IsGtk():
! basefonts=[10,13,17,20,23,27,30]
self.SetFonts("", "", [int(sz*scale) for sz in basefonts])
# the html widget clears itself if you set the scale
if len(self.thetext):
--- 43,55 ----
self.SetFontScale(relsize)
def SetFontScale(self, scale):
! # default font sizes
if guihelper.IsGtk():
! basefonts=[10,13,17,20,23,27,30] # Linux
! elif guihelper.IsMac():
! basefonts=[10,12,16,22,30] # MacOS
! else:
! basefonts=[7,8,10,12,16,22,30] # Windows
self.SetFonts("", "", [int(sz*scale) for sz in basefonts])
# the html widget clears itself if you set the scale
if len(self.thetext):
Cheers,
Tom
|
|
From: Steven P. <n9...@n9...> - 2004-03-14 14:47:19
|
On Mar 14, 2004, at 8:21 AM, Tom Pollard wrote: > I found that if I just removed the smallest two font sizes from the > basefonts list in the SetFontScale method of bphtml, things looked ok > in the details view without affecting the appearance anywhere else, as > far as I could notice. Here are the code changes I propose... Seems reasonable to me. I'll put that in for the next test release. |
|
From: Tom P. <mlp...@ea...> - 2004-03-14 14:56:13
|
On Mar 14, 2004, at 9:47 AM, Steven Palm wrote: >> I found that if I just removed the smallest two font sizes from the >> basefonts list in the SetFontScale method of bphtml, things looked ok >> in the details view without affecting the appearance anywhere else, >> as far as I could notice. Here are the code changes I propose... > > Seems reasonable to me. I'll put that in for the next test release. Thanks. Wasn't this a problem on your machine, too? Or, was there some other way you dealt with it? Tom |
|
From: Roger B. <ro...@ro...> - 2004-03-14 18:58:27
|
> But, I found that if I just removed the smallest two font sizes from
> the basefonts list in the SetFontScale method of bphtml, things looked
> ok in the details view without affecting the appearance anywhere else,
> as far as I could notice. Here are the code changes I propose...
Removing them is not the right fix for this. Those listings of base
size need to be exactly 7 items long and should correspond to the
7 sizes used in the wxWidgets code. They are used in a call to
wxHtmlWindow.SetFonts and are listed because there isn't a
wxHtmlWindow.GetFonts. Please read that documentation.
I think this is the list of base sizes for the Mac:
#define wxHTML_FONT_SIZE_1 9
#define wxHTML_FONT_SIZE_2 12
#define wxHTML_FONT_SIZE_3 14
#define wxHTML_FONT_SIZE_4 18
#define wxHTML_FONT_SIZE_5 24
#define wxHTML_FONT_SIZE_6 30
#define wxHTML_FONT_SIZE_7 36
If Mac fonts are too small, then you need to change the
default relative sizing in bphtml.HTMLWindow.__init__.
I would suggest making relsize=None and then inside
set it to 0.7 for non-Mac and whatever for Mac.
Roger
|
|
From: Tom P. <mlp...@ea...> - 2004-03-14 21:30:19
Attachments:
bphtml.py.patch
|
On Mar 14, 2004, at 1:59 PM, Roger Binns wrote: >> But, I found that if I just removed the smallest two font sizes from >> the basefonts list in the SetFontScale method of bphtml, things looked >> ok in the details view without affecting the appearance anywhere else, >> as far as I could notice. Here are the code changes I propose... > > Removing them is not the right fix for this. Those listings of base > size need to be exactly 7 items long and should correspond to the > 7 sizes used in the wxWidgets code. They are used in a call to > wxHtmlWindow.SetFonts and are listed because there isn't a > wxHtmlWindow.GetFonts. Please read that documentation. > > I think this is the list of base sizes for the Mac: > > #define wxHTML_FONT_SIZE_1 9 > #define wxHTML_FONT_SIZE_2 12 > #define wxHTML_FONT_SIZE_3 14 > #define wxHTML_FONT_SIZE_4 18 > #define wxHTML_FONT_SIZE_5 24 > #define wxHTML_FONT_SIZE_6 30 > #define wxHTML_FONT_SIZE_7 36 Ok, thanks. > If Mac fonts are too small, then you need to change the > default relative sizing in bphtml.HTMLWindow.__init__. > I would suggest making relsize=None and then inside > set it to 0.7 for non-Mac and whatever for Mac. Using the correct Mac font sizes, the smallest text in the phonebook details view is still readable. So I don't think it's necessary to adjust the font scaling specially for Macs. In case it's useful, I've attached an updated patch file below. Tom |
|
From: Steven P. <n9...@n9...> - 2004-03-14 21:33:42
|
On Mar 14, 2004, at 12:59 PM, Roger Binns wrote: > Removing them is not the right fix for this. Those listings of base > size need to be exactly 7 items long and should correspond to the > 7 sizes used in the wxWidgets code. They are used in a call to > wxHtmlWindow.SetFonts and are listed because there isn't a > wxHtmlWindow.GetFonts. Please read that documentation. Sorry to get pissy, but it's horribly frustrating when something is supposed to be "cross-platform" and you end up having to put in so many little exceptions for this that and the other thing. If there are platform differences, it SHOULD be handled transparently by the relevant libraries, not the end applications. With wxWidgets this is simply not the case, and it's infuriating at times. > I think this is the list of base sizes for the Mac: > > #define wxHTML_FONT_SIZE_1 9 > #define wxHTML_FONT_SIZE_2 12 > #define wxHTML_FONT_SIZE_3 14 > #define wxHTML_FONT_SIZE_4 18 > #define wxHTML_FONT_SIZE_5 24 > #define wxHTML_FONT_SIZE_6 30 > #define wxHTML_FONT_SIZE_7 36 Call me stupid, but if the base sizes are defined in a given platform's header file, why are they being redefined with arbitrary values in bphtml.py? Or is this something else entirely?? |
|
From: Roger B. <ro...@ro...> - 2004-03-14 22:40:35
|
> Sorry to get pissy, but it's horribly frustrating when something is > supposed to be "cross-platform" and you end up having to put in so many > little exceptions for this that and the other thing. They day you find a perfect piece of software, let us know :-) > If there are > platform differences, it SHOULD be handled transparently by the > relevant libraries, not the end applications. With wxWidgets this is > simply not the case, and it's infuriating at times. It *IS* being handled transparently by wxWidgets. wxWidgets even goes so far as to correct the base sizes for each platform so that the same HTML looks the same on all platforms. (Quite frankly if you ask for a 10 point font on the different platforms while using a 17" monitor, you will get different physical sizes hence the workaround in wxWidgets). However the wxWidgets API doesn't provide a GetFonts API. I dug into my old email and found that it does provide the settings as #defines which I quoted. However wxPython doesn't export those symbols, due to an oversight. I worked with Robin on this and he will be exporting them in the next wxPython release. > Call me stupid, but if the base sizes are defined in a given > platform's header file, why are they being redefined with arbitrary > values in bphtml.py? Or is this something else entirely?? They are not arbitrary values in bphtml. They are supposed to be *identical* to the ones in wxWidgets because of wxPython not exporting the values. Roger |
|
From: Steven P. <n9...@n9...> - 2004-03-14 22:57:45
|
On Mar 14, 2004, at 4:41 PM, Roger Binns wrote: > They day you find a perfect piece of software, let us know :-) Well, I certainly have never written or used one, so don't wait for that email. ;^) > However the wxWidgets API doesn't provide a GetFonts API. I > dug into my old email and found that it does provide the > settings as #defines which I quoted. > > However wxPython doesn't export those symbols, due to an oversight. > I worked with Robin on this and he will be exporting them > in the next wxPython release. I spent a good bit of time trying to figure out why I couldn't find them only to realize this myself this afternoon. :-) > They are not arbitrary values in bphtml. They are supposed to be > *identical* to the ones in wxWidgets because of wxPython not > exporting the values. I did a similar thing, then, and put in the values defined in wxMac:html/htmldefines.h. It seems to work well like that, so I'll leave it there. Sorry, it's been a terrible day and I ranted when I should have ducked out and coded some more. :-) Eventually I would have realized the bigger picture and now all is well. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X