Just wanted to let people know I'm in the middle of hacking on icon loading. My immediate goal was to get rid of the ugly rescaling and blurring of the stock icons. But in doing that I should also be able to get rid of all hardcoding of sizes.
So... all the SP_ICON_SIZE_* defines are about to dissapear, and their use should be replaced with the logical GTK_ICON_SIZE_* defines in many places. In many other places, hardcoded sizes should just dissappear.
On Mon, 2005-02-28 at 22:53 -0800, Jon A. Cruz wrote:
Just wanted to let people know I'm in the middle of hacking on icon loading. My immediate goal was to get rid of the ugly rescaling and blurring of the stock icons. But in doing that I should also be able to get rid of all hardcoding of sizes.
That's exciting to hear. Can't wait to jump on'em.
cheers
On Mon, Feb 28, 2005 at 10:53:13PM -0800, Jon A. Cruz wrote:
So... all the SP_ICON_SIZE_* defines are about to dissapear, and their use should be replaced with the logical GTK_ICON_SIZE_* defines in many places. In many other places, hardcoded sizes should just dissappear.
I'm pretty sure that gtk_icon_size_* is an enum, rather than sizes. I tried to do this a while back. :)
On Tue, 2005-03-01 at 19:38, Kees Cook wrote:
On Mon, Feb 28, 2005 at 10:53:13PM -0800, Jon A. Cruz wrote:
So... all the SP_ICON_SIZE_* defines are about to dissapear, and their use should be replaced with the logical GTK_ICON_SIZE_* defines in many places. In many other places, hardcoded sizes should just dissappear.
I'm pretty sure that gtk_icon_size_* is an enum, rather than sizes.
Sort of. The standard ones are enumerated in the enum, but you can register new sizes as well (you get back an opaque value that you can use wherever you would use the enum).
-mental
MenTaLguY wrote:
Sort of. The standard ones are enumerated in the enum, but you can register new sizes as well (you get back an opaque value that you can use wherever you would use the enum).
Yes. But I'd point out that one of the benefits of sticking to the enumed sizes is that thing will play nicer with themes. We also should try to use the expected sizes in the expected places, and thus increase our chances of getting stock icons that aren't scaled.
Kees Cook wrote:
On Mon, Feb 28, 2005 at 10:53:13PM -0800, Jon A. Cruz wrote:
So... all the SP_ICON_SIZE_* defines are about to dissapear, and their use should be replaced with the logical GTK_ICON_SIZE_* defines in many places. In many other places, hardcoded sizes should just dissappear.
I'm pretty sure that gtk_icon_size_* is an enum, rather than sizes. I tried to do this a while back. :)
Yes, GTK_ICON_SIZE_* are in an enum... but that's why they invented reinterpret_cast<>
:-)
Seriously, though, getting to an enum of logical sizes is a much better way to go. However, it does require a complete rework of icon.cpp. Of course, that's what I went and did. :-)
Now I'm just tracking down the callers who are not sending in proper stuff.
BTW, I believe that our main cause of fuzzy stock icons is from asking GTK+ to give us icons for buttons, but then placing them in a toolbar. If we ask for either the large or small toolbar versions, the default stock icons come in unblurred. That's probably due to there only being exact-sized versions for those in toolbar and menu sizes.
Jon A. Cruz wrote:
Seriously, though, getting to an enum of logical sizes is a much better way to go. However, it does require a complete rework of icon.cpp. Of course, that's what I went and did. :-)
Now I'm just tracking down the callers who are not sending in proper stuff.
All right. Round one of the refit is done. I've changed the icon.h/cpp stuff to use logical GtkIconSize enums. I also changed the places calling it. I *think* I did a fair job of giving proper logical sizes to things. However, this did undo some of the hardcoded UI fine tuning. So if there's anything people don't like the look of, let's point it out and get a 'proper' fix in.
On Wed, 02 Mar 2005 02:13:31 -0800, Jon A. Cruz <jon@...18...> wrote:
Jon A. Cruz wrote: All right. Round one of the refit is done. I've changed the icon.h/cpp stuff to use logical GtkIconSize enums. I also changed the places calling it. I *think* I did a fair job of giving proper logical sizes to things. However, this did undo some of the hardcoded UI fine tuning. So if there's anything people don't like the look of, let's point it out and get a 'proper' fix in.
Please give your reasons for (or failing that, please fix :) these issues:
- tool buttons are too small (actually I think we should provide a way to make them small, but only as an option) and some are truncated
- top toolbar buttons are too large (though not by much, so if it's the standard size, let it be; if not please revert the size)
- four toggle buttons in select toolbar (scaling stroke, corners, etc) are way too large, they are supposed to be small and different from the regular buttons
- in zoom and node tool controls, SVG icons are truncated
- in fill&stroke, icons on tabs are too large and truncated
- SVG icons in menus are too large and truncated
- eye and lock icons in the statusbar disappeared!
- all icons in Align&distribute disappeared!
bulia byak wrote:
Please give your reasons for (or failing that, please fix :) these issues:
- tool buttons are too small (actually I think we should provide a way
to make them small, but only as an option) and some are truncated
I believe this is due to some issues with the pixbuf cacheing in icon.cpp. It *should* go away with a little debugging. (I had noticed the same thing myself.
- top toolbar buttons are too large (though not by much, so if it's
the standard size, let it be; if not please revert the size)
Yes, that's the standard size. It's "GTK_ICON_SIZE_LARGE_TOOLBAR", and seems to go along with what other apps use in that position. One thing I used for a reference was gedit, to see how it compared and behaved in regards to different themes. I belive that for me, out of the box GNOME and Bluecurve set that to 24 and Inkscape had be using 20 for icons in that location. Small toolbar icons in the default are 18. So Inkscape was getting slightly rescaled bitmaps instead of the theme designer's intent, thus the blurry stock icons.
Of course, now the 'proper' fix to get Inkscape to use smaller icons there would be to either ovrride it in some gtkrc, or use a theme with smaller icons. :-)
- four toggle buttons in select toolbar (scaling stroke, corners, etc)
are way too large, they are supposed to be small and different from the regular buttons
We'll probably have to think about that one. At the moment they are small toolbar icons that are in a toolbar. Might be time to dig through the HIG.
- in zoom and node tool controls, SVG icons are truncated
I think it's that same cache issue as earlier.
- in fill&stroke, icons on tabs are too large and truncated
Yeah. The smallest size in default is the 16x16 menu size. Time to go HIG digging.
- SVG icons in menus are too large and truncated
The stock ones should be 16x16. I can't get a screenshot of my menus to check, but it seems about right. The SVG ones might be getting hit by some size caching issue, so I'll look at that.
- eye and lock icons in the statusbar disappeared!
Hmmm.... will have to look at that.
- all icons in Align&distribute disappeared!
Nope. They're still there.
It's just that they're now 2x2 pixels. Guess something is using the logical size for it's physical dimensions still. Definitely a bug.
Jon A. Cruz wrote:
bulia byak wrote:
- tool buttons are too small (actually I think we should provide a way
to make them small, but only as an option) and some are truncated
I believe this is due to some issues with the pixbuf cacheing in icon.cpp. It *should* go away with a little debugging. (I had noticed the same thing myself.
OK. I tracked it down. The icon stuff used to take two parameters, the target size for the UI and the source size from the SVG. I took out the second parameter, but hadn't compensated for it in the code, so it was always trying to render the svg's icons at 0.8 of their native size. For now I've done an ugly hack to get things scaled properly.
I also had setup some debugging things for the icon stuff. I'll leave it in for a bit, as it might come in handy. I added these preferences to my inkscape preferences manually: <group id="debug"> <group id="icons" dumpDefault="0" dumpCache="0" dumpSvg="0" dumpGtk="0" overlaySvg="0" overlayGtk="0" /> </group>
The dump ones will enable text output. The 'overlay' ones help figure the size being rendered.
Oh, and to make Bulia happy, I had done this one too: <group small="0" id="toolbox" />
Just make that a "1" to turn the top toolbar 'small' instead of 'large'
Quoting "Jon A. Cruz" <jon@...18...>:
Oh, and to make Bulia happy, I had done this one too: <group small="0" id="toolbox" />
Just make that a "1" to turn the top toolbar 'small' instead of 'large'
...your rationale for not defaulting to "small" being...?
I'd prefer we didn't try to mingle cleaning up the code and evaluating UI changes.
Let's get the code cleaned up so it yields (as close as is reasonably possible) the same appearance/behavior as before, and then we can debate changes to the UI.
-mental
mental@...3... wrote:
Quoting "Jon A. Cruz" <jon@...18...>:
Oh, and to make Bulia happy, I had done this one too: <group small="0" id="toolbox" />
Just make that a "1" to turn the top toolbar 'small' instead of 'large'
...your rationale for not defaulting to "small" being...?
Being that we were doing things wrong before. That was a main toolbar, but we were using a strange size. Also... the "small" size is 16 with the default Bluecurve theme, and "large" is 24. We were hardcoding things to 20. Given that the size we had was exactly in between those, I rounded in favor of the HIG.
I'd prefer we didn't try to mingle cleaning up the code and evaluating UI changes.
Let's get the code cleaned up so it yields (as close as is reasonably possible) the same appearance/behavior as before, and then we can debate changes to the UI.
Yes, I was trying to do that mainly. However this was one of the cases where we were doing things so strangely, they didn't map directly into any of the standard ways. If there is a standard way that gets us the same behavior, I'd go for that.
In general, however, the main UI approach should be to dump all kludges and move to using things cleanly using the proper mechanism. Then see if we can tweak those in standard ways to get the same look. Yes, we should default to as close as we were, but we need to do things cleanly internally first. This will also help with moving in the new UI stuff, and making things more configurable moving forwards.
Jon, now the left toolbar buttons are almost the right size. A bit smaller, but again, if it's a standard size, let it be. (But if there's another standard size a bit larger than this, I'd like to use it instead.) The icons on them, on the other hand, are larger than before. Can you please reduce them because: 1) they were pixel-optimized for the previous size and 2) they now look very cramped.
Oh, and the huge eye and lock look really scary in the statusbar :) Please restore the sizes.
And the Align&distribute icons are smaller than before, hard to read. Please enlarge them.
bulia byak wrote:
And the Align&distribute icons are smaller than before, hard to read. Please enlarge them.
Done. They had no size specified, so were defaulting to 'small toolbar' size. I changed that to 'large toolbar' since that seems to be close to how the dialog is using them.
bulia byak wrote:
Jon, now the left toolbar buttons are almost the right size. A bit smaller, but again, if it's a standard size, let it be. (But if there's another standard size a bit larger than this, I'd like to use it instead.)
Yes, that's the standard "large toolbar" size. Now is probably the point at which you tweak that size for Inkscape in your gtkrc, or switch to a theme that has sizes you like. Or make your own theme. :-)
The icons on them, on the other hand, are larger than before. Can you please reduce them because: 1) they were pixel-optimized for the previous size and 2) they now look very cramped.
Hmmm... Don't think that's the way to go here. Since they're svg, we really shouldn't count on being optimized for 20 pixel instead of 24. Just switch to the "Large Print" theme and see what uses may like. Our UI should "just work" for both large print and bulia sizes.
The way things are working now is that I just ask GTK+ what size it has for icons on "large toolbars". I render a pixbuf at that size and return it. That's all. GTK+ takes over on the sizing of the buttons and all, according to it's rules and theme preferences.
Oh, and for figuring out, here is the list of logical icon sizes. Note that some of the sizes are the same as each other in different themes:
16 | 16 | 32 | GTK_ICON_SIZE_MENU 18 | 16 | 32 | GTK_ICON_SIZE_SMALL_TOOLBAR 24 | 24 | 48 | GTK_ICON_SIZE_LARGE_TOOLBAR 20 | 20 | 32 | GTK_ICON_SIZE_BUTTON 32 | 32 | 48 | GTK_ICON_SIZE_DND 48 | 48 | 64 | GTK_ICON_SIZE_DIALOG
The first column is the size by the generic query function. The second column is the size with the default theme and icons (notice that small toolbar changed), and the third is the size when in the 'Large Print' theme. What does this all show? Not to use hard sizes. Instead pick the enum the reflects the UI Widget's functional purpose. The if you don't like the given sizes, you can just override them in the theme or gtkrc.
Oh, and the huge eye and lock look really scary in the statusbar :) Please restore the sizes.
Yeah., I know. Eeeeeeeeeeeek!!!
That is what making me think that perhaps we should add a single enum value to get a 'decoration' or some such size. We won't be getting stock sizes for that, but we probably could figure something out. Does everyone think that's a good idea?
On Fri, 04 Mar 2005 09:18:19 -0800, Jon A. Cruz <jon@...18...> wrote:
Hmmm... Don't think that's the way to go here. Since they're svg, we really shouldn't count on being optimized for 20 pixel instead of 24.
Then the SVG icons need to be rescaled down within their frames (invisible rectangles) and re-pixel-optimized for the new standard size. This needs to be done at least for the main toolbar icons, because they are very visible.
Any volunteers? It's a simple but necessary task.
That is what making me think that perhaps we should add a single enum value to get a 'decoration' or some such size. We won't be getting stock sizes for that, but we probably could figure something out. Does everyone think that's a good idea?
If there's no appropriate standard size, we have no other choice.
On Fri, 2005-03-04 at 14:03 -0400, bulia byak wrote:
On Fri, 04 Mar 2005 09:18:19 -0800, Jon A. Cruz <jon@...18...> wrote:
Hmmm... Don't think that's the way to go here. Since they're svg, we really shouldn't count on being optimized for 20 pixel instead of 24.
Then the SVG icons need to be rescaled down within their frames (invisible rectangles) and re-pixel-optimized for the new standard size. This needs to be done at least for the main toolbar icons, because they are very visible.
Any volunteers? It's a simple but necessary task.
I plan on doing a consistent, pixel optimised set, with style that shouldn't look alien on any major desktop platform (KDE, GNOME, Windows, OSX). Not sure I can do this in a timely matter, but my motivation to have this done is strong.
cheers
Jakub Steiner wrote:
On Fri, 2005-03-04 at 14:03 -0400, bulia byak wrote:
On Fri, 04 Mar 2005 09:18:19 -0800, Jon A. Cruz <jon@...18...> wrote:
Hmmm... Don't think that's the way to go here. Since they're svg, we really shouldn't count on being optimized for 20 pixel instead of 24.
Then the SVG icons need to be rescaled down within their frames (invisible rectangles) and re-pixel-optimized for the new standard size. This needs to be done at least for the main toolbar icons, because they are very visible.
Any volunteers? It's a simple but necessary task.
I plan on doing a consistent, pixel optimised set, with style that shouldn't look alien on any major desktop platform (KDE, GNOME, Windows, OSX). Not sure I can do this in a timely matter, but my motivation to have this done is strong.
cheers
I volunteer to help you out on this if you are intrested. This is really needed because of the cross platform issue. - Andreas
On Fri, Mar 04, 2005 at 09:18:19AM -0800, Jon A. Cruz wrote:
Oh, and the huge eye and lock look really scary in the statusbar :) Please restore the sizes.
Yeah., I know. Eeeeeeeeeeeek!!!
The giant eye has actually be growing on me. I kinda like it that big. :) It doesn't stretch the toolbar height at all, and it makes it really easy to see.
On Saturday 5 March 2005 18:12, Kees Cook wrote:
On Fri, Mar 04, 2005 at 09:18:19AM -0800, Jon A. Cruz wrote:
Oh, and the huge eye and lock look really scary in the statusbar :) Please restore the sizes.
The giant eye has actually be growing on me. I kinda like it that big.
I agree. I always found the icons much too small and for no reason I can think of.
Cheers, Jef
On Sat, 2005-03-05 at 20:30 +0100, Jean-François Lemaire wrote:
On Saturday 5 March 2005 18:12, Kees Cook wrote:
On Fri, Mar 04, 2005 at 09:18:19AM -0800, Jon A. Cruz wrote:
Oh, and the huge eye and lock look really scary in the statusbar :) Please restore the sizes.
The giant eye has actually be growing on me. I kinda like it that big.
I agree. I always found the icons much too small and for no reason I can think of.
C'mon it's huge! and as Kees wrote, it's scary... maybe some size in between? Like 3/4 small toolbar button?
Anyways: Thanks Jon! Now we have WYSIWYG for icon theming and the size on canvas doesn't matter anymore. Now, this causes some work for me, since I have to redo the icons with the stupid workarounds, but over all it's great for theming!
Since some icons look real ugly right now with my theme, I'll upload a new icon.svg tonight at some point... including the new gradient tool :)
Take care!
David
Jon, the truncating is fixed as far as I can see, so now remain to fix only the disappeared or pixel-size icons (eye/lock, Align&Distribute) and the sizes of the main toolbar on the left (too small) and the toggle buttons on the selector controls panel (H/W lock, scale strokes, scale corners, etc.)
bulia byak wrote:
Jon, the truncating is fixed as far as I can see, so now remain to fix only the disappeared or pixel-size icons (eye/lock, Align&Distribute)
What's happening is that the higher-level code was switched to use the physical sizes, but then the code it ends up calling down into is not a routine that I've modified yet. Time to track that down.
and the sizes of the main toolbar on the left (too small)
Fixed. I changed things larger, but left an preference to toggle it small again. We'll probably have to sit down and figure out how to organize and name those.
and the toggle buttons on the selector controls panel (H/W lock, scale strokes, scale corners, etc.)
That's the tricky one. Makes me think we might need some extra value. Or perhaps some strange type of widget. If the 'menu' size won't do for whatever we end up with using, then we could extend our own enum with an extra size or too, but I'm loathe to go that far. Hopefully we can get it fixed with a simpler solution.
Jon A. Cruz wrote:
bulia byak wrote:
Jon, the truncating is fixed as far as I can see, so now remain to fix only the disappeared or pixel-size icons (eye/lock, Align&Distribute)
What's happening is that the higher-level code was switched to use the physical sizes, but then the code it ends up calling down into is not a routine that I've modified yet. Time to track that down.
Ok. Bug tracked down and squished. Was the small class down there at the bottom of icon.cpp mised getting one line changed from 'size' to 'psize'
participants (9)
-
unknown＠example.com -
Andreas Nilsson -
bulia byak -
David Christian Berg -
Jakub Steiner -
Jean-François Lemaire -
Jon A. Cruz -
Kees Cook -
MenTaLguY