Re: [Gimp-developer] GIMP crashes at changing of theme
Alexander Rabtchevich writes: > Grey icons from small theme become undistinguishable to me - they do not > have enough contrast between background and image. Kevin Payne writes: > Can you be more specific about which Icon Theme you are having the low > contrast problem with and what your system colours are, as the Small Theme > will use your system colours there is no way to know which Icon Theme is > going to work best for you. I have that problem with the Symbolic icons with all the Light or Lighter themes. When I first switched my initial reaction was "Why are all the Toolbox icons greyed out?!" Once I realized they weren't greyed out, they looked like that all the time, I tried to work with them, but I found that I really couldn't see the differences and had to hover over each icon to wait for the tooltip. Fortunately there are the Color and Legacy icon theme options. The Dark themes seem to have much more contrast, with Symbolic icons, than any of the Light themes. I think the dark themes would be usable, but they don't go well with the rest of my desktop. Another question about theme switching: every time I switch themes, my toolbox resizes to four icons across, so small that tooltips has to show a horizontal scrollbar for most tools. It has to be six icons across to avoid a scrollbar, and I always have to resize it larger after switching themes. Is this intentional, or should I file it as a bug? ...Akkana ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org
Andrew Toskin writes: > > On 2016-04-01 13:32, Pat David wrote: > > Jehan suggested that each script/plugin/asset have it's own git repo. > > This would be handy, particularly if script authors did this as well (as it > > considerably eases the inclusion of external repos as submodules). > > However, akk points out that many folks don't (won't?) organize their repos > > in this way (it gets a little... unwieldy pretty quickly if you have many > > scripts). > > Whether or not we can get plugin developers to follow it, separating > scripts and plugins into different repositories seems like a good > recommendation, for a number of reasons. For plugin and script authors, > it would make managing bugs and user feedback easier. It would make managing repositories much harder, though. I currently have roughly 20 GIMP scripts and plug-ins in my gimp-plugins repository, and would want to share maybe 15 of them (some are silly and not worth sharing). Please don't force me to create 20 different repositories, most containing only a single python script. It clutters my github (or, I assume, gitlab) profile, assuming they'd even let me create that many repos; it makes it hard to keep multiple machines current since I have to cd into each of those repos and make sure they're in sync; and it's harder to set up (I have to do things like edit .git/config by hand in 20 repos instead of just one to do things like make pushurl !- url). > For end users, > it's also annoying to clone a large repository when you're only > interested in a small subset of its contents. That's true. But nobody's suggesting that end users would be cloning git repos, are they? They'd just be running some friendly UI to say "give me the files I need for the foo plugin", and the backend downloads the right files and puts them in the right place. End users will never know they're using git at all. ...Akkana ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
Just agreeing with a few of Ofnuts' points: Ofnuts writes: > Author: > - communications with users: forum, etc. Mail notification necessary +1. With the current setup, I remember going to a page I'd made for one of my plug-ins and discovering there was a question there from four years earlier that I'd had no idea about. > - ability to share/transmit ownership Good one! > - I don't think this system should be a place to maintain/share the source > code. We could however enforce a FOSS/CC discipline and require the source > files to be provided (for some assets, this could mean the original XCF/SVG > file...) I like the experiments Pat has been doing with making links inside a repo that link to other repos. If the GIMP plugin repository can include files from a developer's site on github or wherever, that solves the problem of developers who are actively improving a plugin but forget that they also need to update the version on GIMP's repository. > User: > - straightforward, no-questions-asked downloads > - easy registration for forums > - semi-anonymous use of forums (guest mode without registration, but with > some more hurdles such as captchas) > - search capabilities - browse capabilities, by category or keyword: browsing all the plugins in the color category isn't the same as searching for everything that has the word "color" anywhere in the description, a major problem with the previous plug-in repository. And maybe also by date: browse the recently added plugins. ...Akkana ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
