This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There are two reasons to make icons transparent: 1) Visual impact on non-default themes. Imagine user that will change OS color theme to some non default (I saw a lot of people doing this!) Then non-transparent icons will look ugly due to their "hardcoded" background. 2) Performance - when transparent, there could be 3x less icons, and also programmatic code will be simpler. However performance gain is not that significant, it's about 100ms.
ad 1) We can test a transparent mockup, but change of OS colors isn't frequent case from my point of view. Icons should look raised (pressed) and then should contain different colors inside then colors of area under them (at least for XP L&F). That's why I think the transparency will be confusing. ad 2) We would like to create design as best we can and this point seems to me unsatisfactory if there is no big performance or implementation problem. And do we solve the transparency for other parts of our IDE currently?
> but change of OS colors isn't frequent case from my point of view. I read in several books that people like to change color themes, and popularity and existence of "skins" for OS and other apps clearly proove this to be true. > no big performance or implementation problem Actually there *are* both big problems, if you view this in context, we are talking about one tiny icon. And it is currently represented by ~100 icons, if you sum across LFs. Each icon loads in 10-20ms. Yes I view it being rather big problem. I'm not UI designer, but I already saw pressed effect done on transparent icons? Actually I think all icons should be designed primarily as transparent, for reasons I stated above. Please try to find transparent solution with pressed effect, this is big issue for us. > And do we solve the transparency for other parts of our IDE > currently? You mean for icons on other places? I'm not sure, but yes we should have all icons transparent if we claim we are looking "native". And we do.
>Actually there *are* both big problems, if you view this in context, >we are talking about one tiny icon. And it is currently represented >by >~100 icons, if you sum across LFs. Each icon loads in 10-20ms. Yes I >view it being rather big problem. As I remember Petr Nejedly talked about 4-10ms for 1 icon and suggested perfect solution of loading 1 picture with more icons inside. Then each icon could be taken from this picture programmatically. He mentioned, that this is a standard solution in a case, when more icons are needed. But, let's discuss other possible ways below. >I'm not UI designer, but I already saw pressed effect done on >transparent icons? Yes, we can create special ugly transparent icon with shadow (or light maybe) in alpha layer, which definitely won't fit into XP L&F. Do you really want to create this one? >Actually I think all icons should be designed primarily as >transparent, for reasons I stated above. >Please try to find transparent solution with pressed effect, this is >big issue for us. I suppose a different way. I noticed, that Tim draw some icons programmatically. It could be the right solution for our problems here. It will reduce amount of icons and could support possibility of change OS theme. What do you think about it?
OK, so only problem with transparent icons is on Windows XP, where is somehow not possible to create transparent icons in a way so that they fit with XP "feel". Is that right? Then I suggest to create transparent icons for other LFs and discuss XP further. Now answers to your questions: > As I remember Petr Nejedly talked about 4-10ms for 1 icon and > suggested perfect solution of loading 1 picture with more icons > inside. Yes, numbers may be 4-10ms for 1 icon, it actually doesn't matter too much, each 1 ms counts. Nejedly's solution is far from perfect: - it doesn't solve problem with non-default color schemes. - is harder to implement and fragile. - not friendly to the NB as a platform (icons are harder to change) - to really make a performance gain worth such extra handling, *all* application icons should be in such overall image. All in all, such solution is hardly maintainable for app like Netbeans. > I suppose a different way. I noticed, that Tim draw some icons > programmatically. It could be the right solution for our problems > here. It will reduce amount of icons and could support possibility > of change OS theme. What do you think about it? I'm not sure it solves anything. Drawing icons programmatically or not, it doesn't matter. What matters is if icon will fill its background or not. All this discussion is starting to look strange to me - perhaps we just don't understand what I mean by saying "transparent icon"? It's icon with unpainted background, more precisely with background set to transparent color, which is not painted, and as result background of bottom surface shines through. There is no need for alpha channel, GIF transparent background color is enough. This is de-facto standard in nearly all applications. Either icons are rectangular or they have transparent background.
>OK, so only problem with transparent icons is on Windows XP, where is >somehow not possible to create transparent icons in a way so that >they fit with XP "feel". Is that right? To be concrete...Problem with transparent icons exists on each L&F, which support pressed state (or mouse over state) containing different color of icon's background, then color of bottom surface (see attachments below with clear example please). And it's true that XP L&F has more special effects (it means gradients and lights and shadows) by those two states. >Yes, numbers may be 4-10ms for 1 icon, it actually doesn't matter too >much, each 1 ms counts. Nejedly's solution is far from perfect: I meant perfect in the case when more icons are needed of course...And Yes, it could solve only performance problem, not problem with non-default color schemes. That's why I suggested another solution (see below). >> I suppose a different way. I noticed, that Tim draw some icons >> programmatically. It could be the right solution for our problems >> here. It will reduce amount of icons and could support possibility >> of change OS theme. What do you think about it? >I'm not sure it solves anything. Drawing icons programmatically or >not, it doesn't matter. What matters is if icon will fill its >background or not. How I mentioned...This solution solves your two big problems from the start of this discussion: 1) Problem with performance of icons loading could be solved by drawing them programmatically, but I agree, that we should test how faster it could be compare with loading of icons. 2) Problem with changing of OS themes could be solved by drawing gradients and shadows programmatically with respect to a selected theme. It means you can take (or derive) colors from that theme. >All this discussion is starting to look strange to me - perhaps we >just don't understand what I mean by saying "transparent icon"? It's >icon with unpainted background, more precisely with background set to >transparent color, which is not painted, and as result background of >bottom surface shines through. There is no need for alpha channel, >GIF transparent background color is enough. This is de-facto >standard in nearly all applications. Either icons are rectangular or >they have transparent background. I understand your transparency completely, because we talked about it in detail together before a few weeks. But you know, I can't recommend it, because it doesn't fit OS L&Fs and that transparent icons will stamp out effect for pressed state of buttons and mouse over states for some L&F. It looks like that solution satisfying your two starting requests and our request of icons which fit OS L&F is tangible...You can try to create icons programmatically at least. It means to create not only outlines of icons but background of icons too (plus gradients and shadows for XP L&F).
Created attachment 16158 [details] Example with sliding icons in Metal L&F
Created attachment 16159 [details] Example with sliding icons in XP L&F
Why this is still a task? re 1) current icons are ugly with a non-default color scheme (chicken or egg problem - user don't change defaults because the software does not work well with it or oposite way?) re 2) current implementation is expensive - too many (small) resources has to be loaded, more Images in memory (+caching overhead, resource names,...), jar files with more entries. It means both time and memory are affected. Some comments about icon handling: currently all images created by JDK should be managed images (operations on them are accelerated, http://weblogs.java.net/pub/wlg/1739) so it is not clear if direct painting will be faster or not and it is questionable if painting of a small portion of bigger image is as fast as paint of whole image. A really big image grouping many icons may even not get the same level of acceleration. And a personal note: current icons are not intuitive IMO. Pin button shuld look like pin.
This issue had *1 votes* before move to platform component