Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | fix ugly 'new' icon sizing ... (patch) | ||||||
---|---|---|---|---|---|---|---|
Product: | General | Reporter: | mmeeks <mmeeks> | ||||
Component: | code | Assignee: | pb | ||||
Status: | CLOSED FIXED | QA Contact: | issues@framework <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues, jens-heiner.rechtien, kendy, ooo | ||||
Version: | OOo 1.1 Beta2 | ||||||
Target Milestone: | OOo 2.0.2 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | PATCH | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
mmeeks
2003-06-02 15:20:02 UTC
TM->HR: Please have a look, thanks ! HR->CD: please comment. CD->OS: This patch corrects the problem with the 'New' icon having a different size than all other icons. But I think it's not the correct place to do it. The "SvFileInformationManager::GetImage" method provides the image so I think this function should scale the images correctly. It is used by many other code parts of OOo and then they also have to be adapted. So it makes more sense to implement scaling into "SvFileInformationManager::GetImage". As discussed, Oliver please take over. PB maintains the SvFileInformationManager class. You're a braver man than I to touch the SvFileInformationManager. That seems designed to track two icon sizes: 16x16 and 32x32. Many of the places it is used the 32x32 looks ~ok - eg. Tools->Options many pages have a header icon that looks 'good' at that size, I imagine the best quality result would be to pass a 'size' parameter to the API; specifying whether a 32x32,16x16 or 24x24 icon was required and scaling automatically. Having said that it'd very obviously be better to have new 24x24 artwork here rather than scaling the (rather scraggly) 32x32s to 24x24 IMHO. OS: Target, Prio, Platform and OS changed. Reassigned to PB. Accepted This really won't be fixed for a year and a half ? Ah; I see from another bug, that the 1.1.1 milestone was only added recently; is there any chance of re-assiging it to that ? - the toolbar looks somewhat horrifically bloated with the single out-sized 'new' icon in it. SBA: Target set to OOo Later. ok - so this is still looking uglier than the average backside; particularly with 24x24 'big' icons in the toolbar. Comments for how to make this more flexible (detecting the size of other toolbar icons etc.) appreciated: --- sfx2/source/toolbox/tbxitem.cxx +++ sfx2/source/toolbox/tbxitem.cxx @@ -1485,10 +1485,20 @@ aURL = sFallback; BOOL bBig = ( SfxImageManager::GetCurrentSymbolSet() == SFX_SYMBOLS_LARGE ); - GetToolBox().SetItemImage( GetId(), - SvFileInformationManager::GetImage( INetURLObject( aURL ), - bBig, - GetToolBox().GetBackground().GetColor().IsDark() ) ); + + Image aI = SvFileInformationManager::GetImage( INetURLObject( aURL ), bBig, + GetToolBox().GetBackground().GetColor().IsDark() ); + + Size aBigSize( 24, 24 ); + if ( bBig && aI.GetSizePixel() != aBigSize ) + { + BitmapEx aScaleBmpEx( aI.GetBitmapEx() ); + aScaleBmpEx.Scale( aBigSize, BMP_SCALE_INTERPOLATE ); + GetToolBox().SetItemImage( GetId(), Image( aScaleBmpEx ) ); + } + else + GetToolBox().SetItemImage( GetId(), aI); + aLastURL = aURL; } HTH. So - now when the iconswitching1 CWS is integrated (issue 36518), we can do it better - according to the used theme. Would the following patch be acceptable, please? Please note that the patch I am going to attach depends on the one from issue 41833. If it is acceptable, I'd like to commit it to CWS iconswitching2, and target it 2.0.2. Created attachment 33139 [details]
The patch for review.
Added ka to Cc: Committed to CWS iconswitching2. Works well for me & ka has approved the patch in a private mail. pb: integrated -> closed. |