Menu
▾
▴
adobe-source-devel
|
From: David C. <unc...@un...> - 2005-03-31 16:30:12
|
I'm experimenting with a workaround for the GetBestControlRect problem: hard-code the height for small & mini buttons. It works, except that buttons get a little clipped when they're at the side or bottom of a group/tab box like the Update button in the Adam and Eve tabs of the main window. In Interface Builder I can place a control a lot closer to the edge than where these are getting clipped - and it still looks good in IB's Carbon Simulator, which I assume is a valid test - so I'm not sure where the clipping comes from. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Ralph T. <ra...@gm...> - 2005-03-31 18:29:22
|
I'm sorry that I don't know more about this problem on Mac (I know all about it on Windows ;-)). So, is the problem that you can't get widget metrics from GetThemeMetric for small controls? Because I think that you can use the HITheme* APIs to get the sizes of small and mini controls. There's more information here: http://developer.apple.com/releasenotes/Carbon/HIToolbox.html , but the real information is in the Carbon headers. Thanks! Ralph On Mar 31, 2005 8:30 AM, David Catmull <unc...@un...> wrote: > I'm experimenting with a workaround for the GetBestControlRect problem: > hard-code the height for small & mini buttons. It works, except that > buttons get a little clipped when they're at the side or bottom of a > group/tab box like the Update button in the Adam and Eve tabs of the > main window. > > In Interface Builder I can place a control a lot closer to the edge > than where these are getting clipped - and it still looks good in IB's > Carbon Simulator, which I assume is a valid test - so I'm not sure > where the clipping comes from. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/Info/Sentarus/hamr30 > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: David C. <unc...@un...> - 2005-03-31 19:07:02
Attachments:
smime.p7s
|
On Mar 31, 2005, at 10:29 AM, Ralph Thomas wrote: > So, is the problem that you can't get widget metrics from > GetThemeMetric for small controls? Hm, I should do that instead of hard-coding 17 and 14. I forgot about theme metrics. The problem is that GetBestControlRect doesn't properly account for a control being set to small or mini. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: David C. <unc...@un...> - 2005-03-31 19:49:24
|
GetThemeMetric isn't working so well after all. For mini pushbutton height, it returns 16, but it should be 14. Small buttons are 17 pixels high. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-31 18:37:11
|
All, I think the clipping is due to the fudge system being applied inappropriately. There's enough stuff massively broken in there that I'll be spending some time fixing it up after the ASL 1.0.2 release. I also aim to take some of what Ralph has been working on in Windows and trying to see what is applicable to the Mac-- I trust something good will come of it. Blessings, Foster On Mar 31, 2005, at 10:29a, Ralph Thomas wrote: > I'm sorry that I don't know more about this problem on Mac (I know all > about it on Windows ;-)). > > So, is the problem that you can't get widget metrics from > GetThemeMetric for small controls? Because I think that you can use > the HITheme* APIs to get the sizes of small and mini controls. There's > more information here: > http://developer.apple.com/releasenotes/Carbon/HIToolbox.html , but > the real information is in the Carbon headers. > > Thanks! > Ralph > > On Mar 31, 2005 8:30 AM, David Catmull <unc...@un...> > wrote: >> I'm experimenting with a workaround for the GetBestControlRect >> problem: >> hard-code the height for small & mini buttons. It works, except that >> buttons get a little clipped when they're at the side or bottom of a >> group/tab box like the Update button in the Adam and Eve tabs of the >> main window. >> >> In Interface Builder I can place a control a lot closer to the edge >> than where these are getting clipped - and it still looks good in IB's >> Carbon Simulator, which I assume is a valid test - so I'm not sure >> where the clipping comes from. >> >> -- >> David Catmull >> unc...@un... >> http://www.uncommonplace.com/ >> >> ------------------------------------------------------- >> This SF.net email is sponsored by Demarc: >> A global provider of Threat Management Solutions. >> Download our HomeAdmin security software for free today! >> http://www.demarc.com/Info/Sentarus/hamr30 >> _______________________________________________ >> Adobe-source-devel mailing list >> Ado...@li... >> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel >> > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/Info/Sentarus/hamr30 > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Foster T. B. <fbr...@ad...> - 2005-03-31 19:13:46
|
My idea is to remove GetBestControlRect because of its inherent bugginess, and replace it with a metric system similar to what I'm envisioning Ralph is using on Windows. It'll use calls to GetThemeMetric to calculate minimal sizes for controls, and then the best_bounds calls will add the size/baseline of the text. This should remove the fudge system entirely, or at least minimize it and systematize it so it's not so horrendous. Blessings, Foster On Mar 31, 2005, at 11:06a, David Catmull wrote: > On Mar 31, 2005, at 10:29 AM, Ralph Thomas wrote: >> So, is the problem that you can't get widget metrics from >> GetThemeMetric for small controls? > > Hm, I should do that instead of hard-coding 17 and 14. I forgot about > theme metrics. The problem is that GetBestControlRect doesn't properly > account for a control being set to small or mini. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ -- Foster T. Brereton <}}}>< Romans 3:21-26 A d o b e S o f t w a r e T e c h n o l o g y L a b "What 99 percent of programmers need to know is not how to build components but how to use them." -- Alexander Stepanov |
|
From: Sean P. <sp...@ad...> - 2005-04-01 04:56:05
|
I'm not sure this helps much if at all - The "fudge" factors still need to be applied for the most part to the outset. I think GetThemeMetric is most likely what GetBestControlRect calls so I doubt it saves you much. My recommendation would be to stop trying to share so much of the code, each widget is going to have to do some calculations and fundging - the hard coded values need to be made external, but otherwise just do the best you can. Go for a simple solution - not a clever one. Sean On Mar 31, 2005, at 11:13 AM, Foster T. Brereton wrote: > My idea is to remove GetBestControlRect because of its inherent > bugginess, and replace it with a metric system similar to what I'm > envisioning Ralph is using on Windows. It'll use calls to > GetThemeMetric to calculate minimal sizes for controls, and then the > best_bounds calls will add the size/baseline of the text. > > This should remove the fudge system entirely, or at least minimize it > and systematize it so it's not so horrendous. > > Blessings, > Foster > > On Mar 31, 2005, at 11:06a, David Catmull wrote: > >> On Mar 31, 2005, at 10:29 AM, Ralph Thomas wrote: >>> So, is the problem that you can't get widget metrics from >>> GetThemeMetric for small controls? >> >> Hm, I should do that instead of hard-coding 17 and 14. I forgot about >> theme metrics. The problem is that GetBestControlRect doesn't >> properly account for a control being set to small or mini. >> >> -- >> David Catmull >> unc...@un... >> http://www.uncommonplace.com/ > > -- > Foster T. Brereton <}}}>< Romans 3:21-26 > A d o b e S o f t w a r e T e c h n o l o g y L a b > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > > > ------------------------------------------------------- > This SF.net email is sponsored by Demarc: > A global provider of Threat Management Solutions. > Download our HomeAdmin security software for free today! > http://www.demarc.com/Info/Sentarus/hamr30 > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
|
From: Sean P. <sp...@ad...> - 2005-04-01 08:01:00
|
On Mar 31, 2005, at 8:30 AM, David Catmull wrote: > > In Interface Builder I can place a control a lot closer to the edge > than where these are getting clipped - and it still looks good in IB's > Carbon Simulator, which I assume is a valid test - so I'm not sure > where the clipping comes from. The clipping is happening because of the panels and outsets not being handled correctly. This seems to be a common point of breakage so I'll describe it here (and find a good place for it in the docs soon). The idea with the outsets for a widget is that they describe the visual area beyond the visual alignment box that the widget hangs. This space is for parts of the control that should hang into white space. Examples include: drop shadows on buttons the part of the check on a check box that sticks above the box the thin edge on the left side of a radio button (and right side if it has no label) to optically align it (the same way a letter "O" will hang a little into the margin in an app with good typography). The white space around a control that the OS imposes So the width and hight of the control should be the "tight visual bounds" - and the outset goes beyond that. Right now outsets are used for two purposes: To adjust panels so that they are big enough to hold their complete contents to correctly hide/show without clipping or shearing. To warn (currently with a rather hostile assert) when visual elements collide. A big problem seems to be how the first of these is handled - what currently happens is that when an outset of something in a container with no visual edge goes over the edge of the container, the outset of the container is increased to contain it. This means that containers with non-visible edges (such as a panel) need to compensate. This is done by growing the bounds to include the offset, adjusting the position (if the offset is on the top or left side), and, if the view system is hierarchical, adjusting the origin so 0,0 is in the same place as it would have been prior to adjusting the position. Right now, Eve in our example app is running flat (and the client code is adjusting the hierarchies of HI views). For most widgets you want to do the same steps as above to compensate for the outset except for adjusting the origin. The way the example code is written, adjusting the origin correctly is a pain - we should be running with Eve in hierarchical mode. I was considering when I started this e-mail changing Eve so that it would simply expand out the side of a panel rather than expanding the outset. The problem with this solution is it will fail for containers with some visual edges (consider a container with a divider line on the top - you don't want the line to grow some odd number of pixels on the left or right side to match the outsets of the content). So I don't have a better way to handle this - but hopefully this helps get the example code cleaned up. Sean |
×
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