GNOME Bugzilla – Bug 94453
Window icons not shown unless window is full screen
Last modified: 2018-01-24 13:18:21 UTC
In the workspace switcher, for the application icon to be shown on the workspace switcher the window must be large enough for the icon to easily fit (ie. full screen, or nearly full screen). It must be possible to scale the icon for smaller windows - within reason - making it much easier to work out at a glance what's on a cluttered workspace.
Hi, I think that's the expected normal behaviour as icons are only displayed if the window in the task applet is greater than 16 pixels. I've created a small patch to make it display icons form 8 to 16 pixels scaling them down (lees than 8 pixels you can't really see anything :-). I've not noticed any CPU-power increase when re-scaling icons (i'm on a 900MHz laptop). Also, the re-scaling is only used re-computed when re-sizing the windows so should be OK). Anyways, the patch is still preliminary so if the maintainer thinks it's a nice feature I'll try to make a nicer one.
Created attachment 12461 [details] [review] patch for showing small icons on the workspace switcher
It's a reasonable idea I think, at least if the icons are still somewhat recognizable at the tiny size.
Hi, I also think the icons are perfectly recognisable with more than 8 pixels (at least the few I use :-) The best thing is that you can easily distinguish between them so knowing which workspace your app is becomes easier. Anyways, let me know what you think on the patch. I haven't used the icon cache as each window can have a different size so I thought wasn't really needed. The icon is only resized when the window is changed so I haven't noticed any increase in CPU.
Marking High/PATCH
Havoc: what about this patch ?
Havoc? This has been sitting here for more than six months now.
Created attachment 28122 [details] [review] Display small icons in pager windows
Above is a patch for the new libwnck 2.6.1 version. I don't know if anyone is really interested in this but I am so the above patch does it... :-)
patch *ping*
Comment on attachment 28122 [details] [review] Display small icons in pager windows Sorry to take a while to review, I half had the idea someone else was paying attention to libwnck bugs... Isn't this patch backward? Or am I just totally confused ;-) Style issues: spaces around operators ("w < 8"), space before all parentheses, newline just before function names, braces on their own line, function parameters on their own line, 2 space indentation. Match the rest of the code essentially. Not sure what the "jrh: " comments mean, are they supposed to remain in final patch? should not scale nano icon from mini icon, but from the original icon. I think this means you want to change wnck_read_icons() in xutils.c. Basically everywhere there's currently mini_icon you'd also add nano_icon with corresponding code.
Hi, I've fixed the style issues (also the comments) in the patch. I'm not that sure about scaling the nano icon from the original icon. The idea of the nano icon is to display the icon in small windows (when the mini icon does not fit) up to 8x8 pixels. As the nano icon is scaled down to the size of the window (it's not fixed as the mini icon) so it makes no sense to cache it :-( Also, the nano icon is quite small and the difference between scaling from the original and the mini-icon is virtually none...
Created attachment 28684 [details] [review] Fixed style issues
If scaling "on demand" to any size, maybe we should drop the mini icon etc. entirely and just keep around the original icon and scale it on the fly? Does that make sense? I guess the last size would have to be cached or we risk a performance problem. I missed that the nano icon is scaled on demand.
In the case of the nano icon the last size is kept so performance is ok. The good thing about the mini icon is that you get a "maximum" icon size but I guess you can also implement that on demand...
I'm trying to remember why it doesn't do on-demand right now - maybe the idea is to keep a 2:1 scaling ratio for highest quality? Hrm. I don't think it's right to have two fixed sizes, and then also on demand. If we're doing on demand we should just get rid of the fixed sizes don't you think?
I think we should go for on demand only, at least on my computer most of the time the window is so small you can not see any icons in the applet. The only problem I foresee is performance but if we keep the last size cached the only problem comes when resizing the window. I haven't notice any visual glitch or performance problems when resizing the nano icon on demand on window resize but the nano icon is resized from the mini icon so icon sizes are just very very small :-) If we care a lot about performance we can go for icon on demand and try to not update the icon while the user is resizing but only at the end of the resize.
Oh right, resize was probably part of the reason. Let's do this: - on demand only - but impose some restrictions on the size, i.e. rather than scaling to an arbitrary set of sizes, quantize it: - arbitrary sizes up to some minimum N pixels - then clamp to fixed sizes such as 16, 32, 48 - be sure the cached icon is used when the size doesn't change Then resizing should still work fine, but we remove a lot of the current code. Slow resize is a real problem so I think the optimization of clamping to some discrete sizes is worthwhile.
*** Bug 93505 has been marked as a duplicate of this bug. ***
Moving to right component. Sorry for the spam.
Marking patches according to the comments I see in the bug. Note that with the X extensions, we may be able to do a real thumbnail instead of icon... :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/15.