I was looking into adding better bitmaps for the toolbar controls in hhctrl.ocx (now that we have fancy alpha transparency support) and I wanted to make sure that the bitmaps used matched everywhere else in Wine. Looking into how this works currently, I noticed that keeping all the toolbar bitmaps in sync is currently done manually. For example, dlls/shell32/idb_tb_large.bmp uses older icons for backward and forward where dlls/shdocvw/ietoolbar.bmp and dlls/comctl32/idb_std_large.bmp use the new icons. So, my thought was that it might be desirable to split apart the individual icons, move them all to one centralized location, and then institute a makefile rule for chaining the icons together into toolbar bitmaps. Any other thoughts? Does this sound reasonable and worth pursuing?
Erich Hoover ehoover@mines.edu
Erich Hoover ehoover@mines.edu writes:
I was looking into adding better bitmaps for the toolbar controls in hhctrl.ocx (now that we have fancy alpha transparency support) and I wanted to make sure that the bitmaps used matched everywhere else in Wine. Looking into how this works currently, I noticed that keeping all the toolbar bitmaps in sync is currently done manually. For example, dlls/shell32/idb_tb_large.bmp uses older icons for backward and forward where dlls/shdocvw/ietoolbar.bmp and dlls/comctl32/idb_std_large.bmp use the new icons. So, my thought was that it might be desirable to split apart the individual icons, move them all to one centralized location, and then institute a makefile rule for chaining the icons together into toolbar bitmaps. Any other thoughts? Does this sound reasonable and worth pursuing?
Probably not. It would be fairly complex and create dependencies on external tools. What you can do though is load the bitmaps from comctl32 at run-time for things that would be duplicated.
On Fri, Dec 10, 2010 at 3:28 AM, Alexandre Julliard julliard@winehq.org wrote:
Erich Hoover ehoover@mines.edu writes:
... So, my thought was that it might be desirable to split apart the individual icons, move them all to one centralized location, and then institute a makefile rule for chaining the icons together into toolbar bitmaps. Any other thoughts? Does this sound reasonable and worth pursuing?
Probably not. It would be fairly complex and create dependencies on external tools. What you can do though is load the bitmaps from comctl32 at run-time for things that would be duplicated.
Wine already requires all the build tools you would need to do this in order to build icons. It would essentially be the same procedure except that you'd want to have a "source" toolbar bitmap file describing the size to use and the list of icons to pull. Once you pull out the correct size from each icon then you just feed that list to ImageMagick: http://www.imagemagick.org/Usage/layers/#append
I'm aware that some of these bitmaps are available through comctl32, but hhctrl.ocx shares a bunch of icons with IE (home, stop, refresh, etc.). I imagine you would not approve of adding custom image lists to comctl32 for handling the icons that overlap between IE and hhctrl.ocx.
Erich Hoover ehoover@mines.edu
Erich Hoover ehoover@mines.edu writes:
On Fri, Dec 10, 2010 at 3:28 AM, Alexandre Julliard julliard@winehq.org wrote:
Erich Hoover ehoover@mines.edu writes:
... So, my thought was that it might be desirable to split apart the individual icons, move them all to one centralized location, and then institute a makefile rule for chaining the icons together into toolbar bitmaps. Any other thoughts? Does this sound reasonable and worth pursuing?
Probably not. It would be fairly complex and create dependencies on external tools. What you can do though is load the bitmaps from comctl32 at run-time for things that would be duplicated.
Wine already requires all the build tools you would need to do this in order to build icons. It would essentially be the same procedure except that you'd want to have a "source" toolbar bitmap file describing the size to use and the list of icons to pull.
I don't think it's worth the trouble. Copying a few bitmaps is not a big deal.