[Gimp-developer] adding calculator widget to gimp
As a part of academics we are asked to choose a free open source s/w and bring about some mere changes by changing playing with its source code. can you guide us, we want to add a calculator widget in GIMP. and we don't have any idea about it. Thanks ___ 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
[Gimp-developer] Third-party module installation
Hi, GIMP developers! I've been writing a color selector module for GIMP that allows users to pick colors using ICC profiles. The color selector is working despite the little documentation available. I'm not writing, however, to complain about the GIMP API documentation. I want my module to be installed together with message catalog, sample ICC profiles and, of course, some user manuals, but I don't know where to install the module itself. Could you give me some advice? ___ 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
Hello, On Fri, Apr 1, 2016 at 10:52 PM, Joao S. O. Bueno wrote: > An asset manager is undoubtedly something needed very badly - > > There are some features that would be needed - which Jehan summarized quite > well in an e-mail sent about 2 years ago (I remember the date because I was > just > back from Leipzig) Yes, as you remind, plugin management is indeed a topic I have thought about for several years now. I wrote/draw many pages of UI, code and infrastructure design about the topic. Unfortunately I never came to write much of the actual code. I hope I can make time soon, but it really depends how will go my current project (ZeMarmot). > At first, I think requiring all assets to be in a git repository (git > uses URLs - no need > to require a specific provider) - would itself be overkill. So maybe, > just make content > 'uploadable" might be enough. On the other hand, gitlab might provide > ownership and content meta-information in a way we would not need to > care about them - > just a system for one to enter a git (gitlab) URL and branch name - maybe > requiring certain information to be in the repository. In my original design, a plugin developer would have the choice to either upload archives for new releases (leaving them the possibility to host wherever one want), or optionally to be hosted by the GIMP project. The idea behind tis second possibility came from my experience with Wordpress plugins. Wordpress offers a code repository to host plugins (SVN repository, since this is an old system from before git really becomes popular, but everything can be done with a git-based system). The webpage for the repository is automatically built from the README (similarly to github, and I suppose gitlab. They did not invent the concept). And the very cool stuff was that you could release a new version of your plugin by tagging your repository (this too, github did not invent). So what would happen is that you tag your repository, and any wordpress in the world with this plugin would get a notification that there is an update available. From a developer point of view, this is cool because I really dislike having to fire up the web browser. So when Patdavid proposed to use gitlab, I thought "oh why not, we could retarget gitlab to host our plugins". I'm not going to write for too long, because I am tired and want to go to bed. And I'd like to discuss these things later at LGM. I really can't make the time these days for this. > Curation of assets remains one of the hardest points - it might be a > _lot_ of _boring_ work - > and even somewhat dangerous - but still, I can imagine 2 categories of assets > - > one endorsed by the "GIMP team" - - i.e. curated - with no dangerous > scripts/plug-ins, > and a "watch yourself" mode in which anything could be downloadable. This is exactly what I said on IRC. I actually completely disagree about a fully curated system. I think it makes no sense. Firefox or Wordpress or any system with a huge plugin ecosystem never would have gone that far if their first idea had been to do a fully-curated system where only manually validated plugins could make it through to the users. So yes, letting all, there will be a lot of crappy code, and even security risks. But there are ways to limit risks: automatic code audit, the eyes of many users (who can click a button "Dangerous content"). Moreover we don't have the manpower. I will say it immediately: I won't spend my time on plugin code checking! Will Patdavid and a few others be the ones validating everything? Quality but also code (for potential intentional backdoors or security leaks)? But yes, as you say, I could completely see the advantage of some curation, with a list of plugins which have been audited. We could have monthly "Pick of the team" to promote some specific high quality/value plugins, etc. And we could have checkboxes to see only curated plugins. But there has to be a possibility to also see non curated plugins. I don't want a system where only a limited set of people have upload rights. > Either way- wathever is designed to register GIMO assets server side, > a Python program can be made, to > run as a GIMP plug-in, that would provide a search, download and > install interface for things > registered on the server side. This program is not a huge thing to do > and would effectively provide GIMP > with its own "asset-store". > > Anyway - just to get the ball rolling - > I suppose this could be a topic with its own BoF session in London Definitely. Jehan > On 1 April 2016 at 17:32, Pat David wrote: >> Continuing on some discussions from irc... >> >> Registry.gimp.org is down for the count. >> >> I was thinking recently about some ideas for a possible replacement. >> Mostly thinking along the lines of what made the registry work well for >> folks. >> >> In the rest of this email, I'll use the term "asset(s)" to refer to things >> like plug-ins, scripts, or brushes/gradients/curves/other assets.
Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org
Hi, On Fri, Apr 1, 2016 at 11:41 PM, Andrew Toskin wrote: > > > I rather like GitLab, and this seems like at least as good a solution > for a plugin registry as any other solution we've considered so far. > > In fact, I think GitLab (or some similar solution) would also be a major > improvement for tracking the core GIMP software. As an occasional > contributor just to the documentation, I find Bugzilla, and the process > of creating and uploading patch files, cumbersome and weirdly > old-fashioned. GitLab could do everything Bugzilla or cgit can, and much > more, _and_ it's got a much better UI and workflow. The discussion is not about core GIMP and I don't think there are any advantages in migrating GIMP out of GNOME infrastructure. I mean, if there were several long-term contributors willing to maintain our own infrastructure, and which we can trust to not disappear in a few months, why not. And even so, I'm not sure what would be the gain there. Bugzilla works very well, in my opinion. The patch process is like 100x better than the weird fork logics that github imposes. And I don't see anything in the web UI that I can't do 1000x better in my terminal. Anyway this thread is about plugins and since there is nearly no chance for GIMP migrating to a gitlab hosting, let's not diverge the topic. Thanks. Jehan > ~Andrew > > On 2016-04-01 13:32, Pat David wrote: > >> Continuing on some discussions from irc... >> >> Registry.gimp.org is down for the count. >> >> I was thinking recently about some ideas for a possible replacement. >> Mostly thinking along the lines of what made the registry work well for >> folks. >> >> In the rest of this email, I'll use the term "asset(s)" to refer to things >> like plug-ins, scripts, or brushes/gradients/curves/other assets. >> >> Some essential functionality based on the old registry drupal instance: >> >> 1. Upload/Download assets for GIMP. >> 2. Describe the asset (usually by the uploader). >> 3. Comment on the assets. >> >> This was handled previously by using drupal, which treated each entry as a >> post/node that included the ability to upload files, write about the files >> as a post, and had comment threads below it. >> >> Keeping this functionality would be good, I think. The ability to post an >> asset is a given, but the ability to interact around it helps foster the >> community (and provides nice feedback for the authors). >> >> From those thoughts, what would be nice to have in a replacement: >> >> 1. Provide at least the same previous functionality (as listed above). >> 2. Managed or easier to manage and keep updated. >> 3. Easier account management. >> 4. Collaborative environment for shared assets >> 5. Support possible GIMP integration in the future (one-click asset >> install?). >> >> GitLab? >> == >> >> Initially, I had thought Github might be a good option for this but given >> its closed-source nature decided to investigate something like GitLab >> instead. >> >> I like this idea personally due to some nice infrastructure: >> >> 1. The service is hosted + managed (and available as Free Software just in >> case we felt we needed to break out and host it ourselves). >> 2. The service integrates OAuth sign-in using a few different account types >> (lowers barrier to entry to participate). >> a. they use accounts, Google, Twitter, Github, or bitbucket accounts >> for sign-in. >> 3. Projects maintain all the git-goodness for control and tracking >> 4. Projects created as a git project can have a full description/README >> along with issue tracking integrated in the site >> >> So, we can fulfill the original registry functionality and get the added >> benefit of a git infrastructure for those wanting to contribute, user >> accounts using OAuth to make it easy to participate, and the ability to do >> some interesting things (git submodules). >> >> In speaking with Jehan about this, we should also consider what might be >> needed to support the ability to install assets from within GIMP in the >> future easily. >> >> Organization >> = >> >> 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). >> >> I'd like some input on what would make the most sense or work best for >> possible organization of repos. >> >> I was also thinking that we could include some simple metadata in both any >> script files and the README.md files as a means to possibly help parsing >> relevant information for automated inclusion at a later date (GIMP plug-ins >> installer type of idea). >> >> Curation >> == >> >> Initially I was thinking that curating the scripts for inclusion would be >> important. It's certainly possible for a smaller
Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org
I rather like GitLab, and this seems like at least as good a solution for a plugin registry as any other solution we've considered so far. In fact, I think GitLab (or some similar solution) would also be a major improvement for tracking the core GIMP software. As an occasional contributor just to the documentation, I find Bugzilla, and the process of creating and uploading patch files, cumbersome and weirdly old-fashioned. GitLab could do everything Bugzilla or cgit can, and much more, _and_ it's got a much better UI and workflow. ~Andrew On 2016-04-01 13:32, Pat David wrote: > Continuing on some discussions from irc... > > Registry.gimp.org is down for the count. > > I was thinking recently about some ideas for a possible replacement. > Mostly thinking along the lines of what made the registry work well for > folks. > > In the rest of this email, I'll use the term "asset(s)" to refer to things > like plug-ins, scripts, or brushes/gradients/curves/other assets. > > Some essential functionality based on the old registry drupal instance: > > 1. Upload/Download assets for GIMP. > 2. Describe the asset (usually by the uploader). > 3. Comment on the assets. > > This was handled previously by using drupal, which treated each entry as a > post/node that included the ability to upload files, write about the files > as a post, and had comment threads below it. > > Keeping this functionality would be good, I think. The ability to post an > asset is a given, but the ability to interact around it helps foster the > community (and provides nice feedback for the authors). > > From those thoughts, what would be nice to have in a replacement: > > 1. Provide at least the same previous functionality (as listed above). > 2. Managed or easier to manage and keep updated. > 3. Easier account management. > 4. Collaborative environment for shared assets > 5. Support possible GIMP integration in the future (one-click asset > install?). > > GitLab? > == > > Initially, I had thought Github might be a good option for this but given > its closed-source nature decided to investigate something like GitLab > instead. > > I like this idea personally due to some nice infrastructure: > > 1. The service is hosted + managed (and available as Free Software just in > case we felt we needed to break out and host it ourselves). > 2. The service integrates OAuth sign-in using a few different account types > (lowers barrier to entry to participate). > a. they use accounts, Google, Twitter, Github, or bitbucket accounts > for sign-in. > 3. Projects maintain all the git-goodness for control and tracking > 4. Projects created as a git project can have a full description/README > along with issue tracking integrated in the site > > So, we can fulfill the original registry functionality and get the added > benefit of a git infrastructure for those wanting to contribute, user > accounts using OAuth to make it easy to participate, and the ability to do > some interesting things (git submodules). > > In speaking with Jehan about this, we should also consider what might be > needed to support the ability to install assets from within GIMP in the > future easily. > > Organization > = > > 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). > > I'd like some input on what would make the most sense or work best for > possible organization of repos. > > I was also thinking that we could include some simple metadata in both any > script files and the README.md files as a means to possibly help parsing > relevant information for automated inclusion at a later date (GIMP plug-ins > installer type of idea). > > Curation > == > > Initially I was thinking that curating the scripts for inclusion would be > important. It's certainly possible for a smaller subset of all of the > available scripts from the registry now to pick out ones that we use and > check that they're not malicious and properly tagged/included. For > instance, there's a handful of scripts that I personally find myself using > often and can help validate/curate for inclusion. I don't mind doing more > as needed. > > I just wanted to get a discussion started about how we might consider > moving forward on something like this. I think the scripts/plug-ins are > important enough to users that it would be good to try and get something up > and running soon. > > I have started experimenting with including submodules from other author > repos and how it might look here: > > https://gitlab.com/GIMP/GIMP-Scripts/tree/master [1] > > I look forward to hearing some thoughts on this! > > pat Links: -- [1] https://gitlab.com/GIMP/G
Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org
On 1 April 2016 at 18:14, Kasim Ahmic wrote: > I personally am a huge supporter of redoing the registry, and I like the > ideas you've proposed here. My only concern is one that was actually brought > up by someone else a few months ago; registry integration within GIMP and the > possibility of viruses. > > I don't quite remember who mentioned it, but they brought up that registry > integration within GIMP itself could potentially open the doors to viruses > unless a virus detection feature was built into GIMP as well. Now, I'm not > entirely sure how true this is but I would like to hear a final say on this > whether this is an actual issue or not. > > If it is an issue, what would be the best way to handle it? I'd imagine that > building virus scanning within GIMP would take quite a long time and be > pretty impractical. As such, I would suggest that we go with a self hosted > solution so that we could incorporate a virus scanner on there to scan all > the uploaded assets. Either that, or a hosted solution like GitLab that come > with a virus scanning option along with it. > > Again, not sure how much of an issue this even is. Just a thought. So - this would be one of the main purposes of a "curation" - Only non-malicious assets would be made available as "safe" from the server-side. Having security features on the client side (i.e. on the computer of the person running GIMP), is not feasible: one single line of code in a rogue plug-in can wipe the user harddrive. . Assuring assets are safe, even if few, and can't be maliciously modified, in the repository is hard enough - but can be done. The hard-to-balance thing is allowing publication of assets by a large amount of people, and having process/volunteers to ensure these assets are safe. Either way, I think the download and install should be done with a few clicks from wthin GIMP itself - we don't have to burden users to locate the file in a browser, download it, copy it to the right folder, set its file properties if that is not needed. If the assets represent a danger, they will represent an equal danger in this "manual way". > > - Kasim Ahmić > > Sent from my iPhone > >> On Apr 1, 2016, at 4:32 PM, Pat David wrote: >> >> Continuing on some discussions from irc... >> >> Registry.gimp.org is down for the count. >> >> I was thinking recently about some ideas for a possible replacement. >> Mostly thinking along the lines of what made the registry work well for >> folks. >> >> In the rest of this email, I'll use the term "asset(s)" to refer to things >> like plug-ins, scripts, or brushes/gradients/curves/other assets. >> >> Some essential functionality based on the old registry drupal instance: >> >> 1. Upload/Download assets for GIMP. >> 2. Describe the asset (usually by the uploader). >> 3. Comment on the assets. >> >> This was handled previously by using drupal, which treated each entry as a >> post/node that included the ability to upload files, write about the files >> as a post, and had comment threads below it. >> >> Keeping this functionality would be good, I think. The ability to post an >> asset is a given, but the ability to interact around it helps foster the >> community (and provides nice feedback for the authors). >> >> From those thoughts, what would be nice to have in a replacement: >> >> 1. Provide at least the same previous functionality (as listed above). >> 2. Managed or easier to manage and keep updated. >> 3. Easier account management. >> 4. Collaborative environment for shared assets >> 5. Support possible GIMP integration in the future (one-click asset >> install?). >> >> >> >> GitLab? >> == >> >> Initially, I had thought Github might be a good option for this but given >> its closed-source nature decided to investigate something like GitLab >> instead. >> >> I like this idea personally due to some nice infrastructure: >> >> 1. The service is hosted + managed (and available as Free Software just in >> case we felt we needed to break out and host it ourselves). >> 2. The service integrates OAuth sign-in using a few different account types >> (lowers barrier to entry to participate). >>a. they use accounts, Google, Twitter, Github, or bitbucket accounts >> for sign-in. >> 3. Projects maintain all the git-goodness for control and tracking >> 4. Projects created as a git project can have a full description/README >> along with issue tracking integrated in the site >> >> So, we can fulfill the original registry functionality and get the added >> benefit of a git infrastructure for those wanting to contribute, user >> accounts using OAuth to make it easy to participate, and the ability to do >> some interesting things (git submodules). >> >> In speaking with Jehan about this, we should also consider what might be >> needed to support the ability to install assets from within GIMP in the >> future easily. >> >> >> Organization >> = >> >> Jehan suggested that each script/plugin/asset have it's own git
Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for registry.gimp.org
I personally am a huge supporter of redoing the registry, and I like the ideas you've proposed here. My only concern is one that was actually brought up by someone else a few months ago; registry integration within GIMP and the possibility of viruses. I don't quite remember who mentioned it, but they brought up that registry integration within GIMP itself could potentially open the doors to viruses unless a virus detection feature was built into GIMP as well. Now, I'm not entirely sure how true this is but I would like to hear a final say on this whether this is an actual issue or not. If it is an issue, what would be the best way to handle it? I'd imagine that building virus scanning within GIMP would take quite a long time and be pretty impractical. As such, I would suggest that we go with a self hosted solution so that we could incorporate a virus scanner on there to scan all the uploaded assets. Either that, or a hosted solution like GitLab that come with a virus scanning option along with it. Again, not sure how much of an issue this even is. Just a thought. - Kasim Ahmić Sent from my iPhone > On Apr 1, 2016, at 4:32 PM, Pat David wrote: > > Continuing on some discussions from irc... > > Registry.gimp.org is down for the count. > > I was thinking recently about some ideas for a possible replacement. > Mostly thinking along the lines of what made the registry work well for > folks. > > In the rest of this email, I'll use the term "asset(s)" to refer to things > like plug-ins, scripts, or brushes/gradients/curves/other assets. > > Some essential functionality based on the old registry drupal instance: > > 1. Upload/Download assets for GIMP. > 2. Describe the asset (usually by the uploader). > 3. Comment on the assets. > > This was handled previously by using drupal, which treated each entry as a > post/node that included the ability to upload files, write about the files > as a post, and had comment threads below it. > > Keeping this functionality would be good, I think. The ability to post an > asset is a given, but the ability to interact around it helps foster the > community (and provides nice feedback for the authors). > > From those thoughts, what would be nice to have in a replacement: > > 1. Provide at least the same previous functionality (as listed above). > 2. Managed or easier to manage and keep updated. > 3. Easier account management. > 4. Collaborative environment for shared assets > 5. Support possible GIMP integration in the future (one-click asset > install?). > > > > GitLab? > == > > Initially, I had thought Github might be a good option for this but given > its closed-source nature decided to investigate something like GitLab > instead. > > I like this idea personally due to some nice infrastructure: > > 1. The service is hosted + managed (and available as Free Software just in > case we felt we needed to break out and host it ourselves). > 2. The service integrates OAuth sign-in using a few different account types > (lowers barrier to entry to participate). >a. they use accounts, Google, Twitter, Github, or bitbucket accounts > for sign-in. > 3. Projects maintain all the git-goodness for control and tracking > 4. Projects created as a git project can have a full description/README > along with issue tracking integrated in the site > > So, we can fulfill the original registry functionality and get the added > benefit of a git infrastructure for those wanting to contribute, user > accounts using OAuth to make it easy to participate, and the ability to do > some interesting things (git submodules). > > In speaking with Jehan about this, we should also consider what might be > needed to support the ability to install assets from within GIMP in the > future easily. > > > Organization > = > > 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). > > I'd like some input on what would make the most sense or work best for > possible organization of repos. > > I was also thinking that we could include some simple metadata in both any > script files and the README.md files as a means to possibly help parsing > relevant information for automated inclusion at a later date (GIMP plug-ins > installer type of idea). > > > Curation > == > > Initially I was thinking that curating the scripts for inclusion would be > important. It's certainly possible for a smaller subset of all of the > available scripts from the registry now to pick out ones that we use and > check that they're not malicious and properly tagged/included. For > instance, there's a handful of scripts that I personally find myself using > often a
Re: [Gimp-developer] Gitlab as a replacement for registry.gimp.org
An asset manager is undoubtedly something needed very badly - There are some features that would be needed - which Jehan summarized quite well in an e-mail sent about 2 years ago (I remember the date because I was just back from Leipzig) At first, I think requiring all assets to be in a git repository (git uses URLs - no need to require a specific provider) - would itself be overkill. So maybe, just make content 'uploadable" might be enough. On the other hand, gitlab might provide ownership and content meta-information in a way we would not need to care about them - just a system for one to enter a git (gitlab) URL and branch name - maybe requiring certain information to be in the repository. Curation of assets remains one of the hardest points - it might be a _lot_ of _boring_ work - and even somewhat dangerous - but still, I can imagine 2 categories of assets - one endorsed by the "GIMP team" - - i.e. curated - with no dangerous scripts/plug-ins, and a "watch yourself" mode in which anything could be downloadable. Either way- wathever is designed to register GIMO assets server side, a Python program can be made, to run as a GIMP plug-in, that would provide a search, download and install interface for things registered on the server side. This program is not a huge thing to do and would effectively provide GIMP with its own "asset-store". Anyway - just to get the ball rolling - I suppose this could be a topic with its own BoF session in London On 1 April 2016 at 17:32, Pat David wrote: > Continuing on some discussions from irc... > > Registry.gimp.org is down for the count. > > I was thinking recently about some ideas for a possible replacement. > Mostly thinking along the lines of what made the registry work well for > folks. > > In the rest of this email, I'll use the term "asset(s)" to refer to things > like plug-ins, scripts, or brushes/gradients/curves/other assets. > > Some essential functionality based on the old registry drupal instance: > > 1. Upload/Download assets for GIMP. > 2. Describe the asset (usually by the uploader). > 3. Comment on the assets. > > This was handled previously by using drupal, which treated each entry as a > post/node that included the ability to upload files, write about the files > as a post, and had comment threads below it. > > Keeping this functionality would be good, I think. The ability to post an > asset is a given, but the ability to interact around it helps foster the > community (and provides nice feedback for the authors). > > From those thoughts, what would be nice to have in a replacement: > > 1. Provide at least the same previous functionality (as listed above). > 2. Managed or easier to manage and keep updated. > 3. Easier account management. > 4. Collaborative environment for shared assets > 5. Support possible GIMP integration in the future (one-click asset > install?). > > > > GitLab? > == > > Initially, I had thought Github might be a good option for this but given > its closed-source nature decided to investigate something like GitLab > instead. > > I like this idea personally due to some nice infrastructure: > > 1. The service is hosted + managed (and available as Free Software just in > case we felt we needed to break out and host it ourselves). > 2. The service integrates OAuth sign-in using a few different account types > (lowers barrier to entry to participate). > a. they use accounts, Google, Twitter, Github, or bitbucket accounts > for sign-in. > 3. Projects maintain all the git-goodness for control and tracking > 4. Projects created as a git project can have a full description/README > along with issue tracking integrated in the site > > So, we can fulfill the original registry functionality and get the added > benefit of a git infrastructure for those wanting to contribute, user > accounts using OAuth to make it easy to participate, and the ability to do > some interesting things (git submodules). > > In speaking with Jehan about this, we should also consider what might be > needed to support the ability to install assets from within GIMP in the > future easily. > > > Organization > = > > 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). > > I'd like some input on what would make the most sense or work best for > possible organization of repos. > > I was also thinking that we could include some simple metadata in both any > script files and the README.md files as a means to possibly help parsing > relevant information for automated inclusion at a later date (GIMP plug-ins > installer type of idea). > > > Curation > == > > Initially I was thinking that curating the scripts for inclusi
[Gimp-developer] Gitlab as a replacement for registry.gimp.org
Continuing on some discussions from irc... Registry.gimp.org is down for the count. I was thinking recently about some ideas for a possible replacement. Mostly thinking along the lines of what made the registry work well for folks. In the rest of this email, I'll use the term "asset(s)" to refer to things like plug-ins, scripts, or brushes/gradients/curves/other assets. Some essential functionality based on the old registry drupal instance: 1. Upload/Download assets for GIMP. 2. Describe the asset (usually by the uploader). 3. Comment on the assets. This was handled previously by using drupal, which treated each entry as a post/node that included the ability to upload files, write about the files as a post, and had comment threads below it. Keeping this functionality would be good, I think. The ability to post an asset is a given, but the ability to interact around it helps foster the community (and provides nice feedback for the authors). >From those thoughts, what would be nice to have in a replacement: 1. Provide at least the same previous functionality (as listed above). 2. Managed or easier to manage and keep updated. 3. Easier account management. 4. Collaborative environment for shared assets 5. Support possible GIMP integration in the future (one-click asset install?). GitLab? == Initially, I had thought Github might be a good option for this but given its closed-source nature decided to investigate something like GitLab instead. I like this idea personally due to some nice infrastructure: 1. The service is hosted + managed (and available as Free Software just in case we felt we needed to break out and host it ourselves). 2. The service integrates OAuth sign-in using a few different account types (lowers barrier to entry to participate). a. they use accounts, Google, Twitter, Github, or bitbucket accounts for sign-in. 3. Projects maintain all the git-goodness for control and tracking 4. Projects created as a git project can have a full description/README along with issue tracking integrated in the site So, we can fulfill the original registry functionality and get the added benefit of a git infrastructure for those wanting to contribute, user accounts using OAuth to make it easy to participate, and the ability to do some interesting things (git submodules). In speaking with Jehan about this, we should also consider what might be needed to support the ability to install assets from within GIMP in the future easily. Organization = 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). I'd like some input on what would make the most sense or work best for possible organization of repos. I was also thinking that we could include some simple metadata in both any script files and the README.md files as a means to possibly help parsing relevant information for automated inclusion at a later date (GIMP plug-ins installer type of idea). Curation == Initially I was thinking that curating the scripts for inclusion would be important. It's certainly possible for a smaller subset of all of the available scripts from the registry now to pick out ones that we use and check that they're not malicious and properly tagged/included. For instance, there's a handful of scripts that I personally find myself using often and can help validate/curate for inclusion. I don't mind doing more as needed. I just wanted to get a discussion started about how we might consider moving forward on something like this. I think the scripts/plug-ins are important enough to users that it would be good to try and get something up and running soon. I have started experimenting with including submodules from other author repos and how it might look here: https://gitlab.com/GIMP/GIMP-Scripts/tree/master I look forward to hearing some thoughts on this! pat -- Pat David https://pixls.us http://blog.patdavid.net ___ 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 crashes at changing of theme
Hello
Kevin Payne wrote:
Can you be more specific about which Icon Theme you are having the low contrast
problem with
I have such a problem with the small icon theme. It can be switched to
the default theme. The default theme is more recognizable due its bigger
size. Both themes look as gray signs over the gray background. Toolbox
and icons background have the same gray color, so the icons visually
select only by their signs.
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.
Here is the screenshot of my GIMP view with the default theme.
https://yadi.sk/i/Lvtkcqgcqfh8a
And does the crash happen when you change Theme from Small to any other Theme,
or only when you change from Small to a specific Theme and when you then
re-start GIMP, does it start OK with the new Theme?
Crash occurs when I switch to any of the new numbered themes: Lighter...
Darker... Switching between the small and default themes is okay. When
switching to the new theme, dialog becomes redrawn, but for a while, and
the program crashes.
gimp_display_shell_profile_update
gimp_display_shell_profile_update
[New Thread 0x7fffbddca700 (LWP 10723)]
[New Thread 0x7fffbd5c9700 (LWP 10724)]
[New Thread 0x7fffa679f700 (LWP 10725)]
[New Thread 0x7fffa5f9e700 (LWP 10726)]
[New Thread 0x7fffa579d700 (LWP 10727)]
[New Thread 0x7fffa4b4a700 (LWP 10728)]
[New Thread 0x7fff8700 (LWP 10729)]
[New Thread 0x7fff8f7fe700 (LWP 10730)]
[Thread 0x7fff8f7fe700 (LWP 10730) exited]
[Thread 0x7fffa679f700 (LWP 10725) exited]
[Thread 0x7fffa4b4a700 (LWP 10728) exited]
[Thread 0x7fffbddca700 (LWP 10723) exited]
[Thread 0x7fffc498b700 (LWP 10708) exited]
[Thread 0x7fff8700 (LWP 10729) exited]
[Thread 0x7fffbd5c9700 (LWP 10724) exited]
[Thread 0x7fffa5f9e700 (LWP 10726) exited]
[New Thread 0x7fffa5f9e700 (LWP 10733)]
[New Thread 0x7fffbd5c9700 (LWP 10734)]
[New Thread 0x7fff8700 (LWP 10735)]
[New Thread 0x7fffc498b700 (LWP 10736)]
[New Thread 0x7fffbddca700 (LWP 10737)]
[New Thread 0x7fffa7e5a700 (LWP 10738)]
[New Thread 0x7fffa7659700 (LWP 10739)]
**
Gdk:ERROR:/build/gtk+2.0-KsZSEA/gtk+2.0-2.24.23/gdk/gdkregion-generic.c:1114:miUnionNonO:
assertion failed: (r->x1 < r->x2)
Program received signal SIGABRT, Aborted.
0x73210cc9 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) thread apply all bt full
Thread 19 (Thread 0x7fffa7659700 (LWP 10739)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
No locals.
#1 0x741cdce5 in g_cond_wait_until ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2 0x741621c1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3 0x741b1862 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4 0x741b0f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#5 0x735a7182 in start_thread (arg=0x7fffa7659700)
at pthread_create.c:312
__res =
pd = 0x7fffa7659700
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736001840896,
2687345097883791521, 1, 0, 140736001841600,
140736001840896,
-2687504472841637727, -2687320130784186207},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
---Type to continue, or q to quit---
data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
pagesize_m1 =
sp =
freesize =
__PRETTY_FUNCTION__ = "start_thread"
#6 0x732d447d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
Thread 18 (Thread 0x7fffa7e5a700 (LWP 10738)):
#0 pthread_cond_timedwait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
No locals.
#1 0x741cdce5 in g_cond_wait_until ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#2 0x741621c1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#3 0x741b1862 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4 0x741b0f05 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
---Type to continue, or q to quit---
#5 0x735a7182 in start_thread (arg=0x7fffa7e5a700)
at pthread_create.c:312
__res =
pd = 0x7fffa7e5a700
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736010233600,
2687345097883791521, 1, 0, 140736010234304,
140736010233600,
-2687503372793139039, -2687320130784186207},
mask_was_saved = 0}}, priv = {pad = {0x
[Gimp-developer] Oooo, fast!
I'm enjoying the added speed boost with the recent updates to gimp-edge repo. GIMP is feeling more and more like a luxury sports car. :) Great work, and thanks! -C ___ 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
