Closed flying-sheep closed 7 years ago
huh, why did i close this?
hi @takluyver what do you think?
I think your persistence will inevitably outweigh my will to argue. :-P
I'm concerned that uic2.py has got several times longer. It was only meant to be a simple script to convert a couple of files, I'm worried that we're now reimplementing a build system badly. Is there a better way to do what you're trying to?
Start using uic2.py in setup.py to avoid checking in volatile files
Yes please, especially as this PR currently adds ~11k lines in the compiled resources file.
I think your persistence will inevitably outweigh my will to argue. :-P
haha i was actually unaware that you wanted to argue. i thought you were just dissatisfied with my previous design (#5) that didn’t incorporate a proper fallback icon theme.
I'm concerned that uic2.py has got several times longer. It was only meant to be a simple script to convert a couple of files, I'm worried that we're now reimplementing a build system badly. Is there a better way to do what you're trying to?
hmm, i see what you mean. it went from a relatively generic compiler to a pretty involved thing.
however, it’s not too project-specific. i think just spend quite some lines for creating an icon theme. as you’re the maintainer of pyxdg: do you think using it to create the theme .ini file would make our life easier here?
haha i was actually unaware that you wanted to argue. i thought you were just dissatisfied with my previous design (#5) that didn’t incorporate a proper fallback icon theme.
It's just a different approach to visual design - I approached it in more the web style, where the developer decides what the user will see; you're looking at it from the Linux desktop point of view, where the developer specifies a semantic category and the system finds an icon for that in the user's theme. I don't feel strongly about this, though.
however, it’s not too project-specific. i think just spend quite some lines for creating an icon theme. as you’re the maintainer of pyxdg: do you think using it to create the theme .ini file would make our life easier here?
I don't know if it has much to support that. I don't do much with pyxdg; I adopted it mostly to move Python 3 support forwards. Have a look if it can simplify what we're doing, but if not, it's not all that long.
I approached it in more the web style, where the developer decides what the user will see; you're looking at it from the Linux desktop point of view, where the developer specifies a semantic category and the system finds an icon for that in the user's theme.
my feelings about this: there’s a few applications that i allow to do their own things, namely ones that are the subject of all of your focus for long times:
everything smaller, everything you interact with only for seconds at a time, should be unobtrusive, blend in, and try to adhere to your system’s conventions as closely as possible.
This PR avoids the pitfalls of #5.
The default behavior is that the icons are taken from the theme if a theme is set (i.e. on Linux), and to load and use a builtin theme from the qrc file if not.
With this PR, the application icon will always be loaded in the “hicolor” fallback theme, so it’s used on Linux as well.
The default behavior can be overridden by setting the
NBMANAGER_IGNORE_THEME
environment variable to something. Then the builtin theme will even be used on Linux. (good for testing it or so)uic2.py
There was a bit of feature creep since I had to adapt this script to do more (generating the changed paths and so on).
But it’s worth it! Now the only source of truth is the file hierarchy in the
icons/
directory and the.ui
file. They’re used to recreate the.qrc
file, its compiled version, theindex.theme
files, and the OSX icon directory (which is no longer checked in)Alternatives
/usr/share/icons/hicolor
)