I've added a link to this interesting page on
http://wiki.gimp.org/wiki/Hacking:Plugin_registry
Ed J
-Original Message-
From: Tobias Jakobs
Sent: Thursday, June 12, 2014 10:28 AM
To: scl
Cc: gimp-developer
Subject: Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi,
Richard H
Hi,
Richard Hughes wrote a specification to add meta-information to plugins:
http://blogs.gnome.org/hughsie/2014/06/11/application-addons-in-gnome-software/
I think this could be useful for Gimp plugins and the Gimp Registry.
Regards
Tobias
2014-04-13 21:57 GMT+02:00 scl :
> On 9.4.2014 at
Hi Sven (and GIMP developers),
> 'GIMP is easily user-extendable, by ‘one-click’ installation of
> plug-ins.' is a part of our product-vision and as far as I remember
> there have already been many ideas on this topic, dating back to 2003.
And now it is possible, as of Gimp-Perl 2.30_05
(http://
On 9.4.2014 at 5:42 PM Ingo Lütkebohle wrote:
If anybody could put up a wiki page for that, that'd be great. Does The
GIMP have a wiki?
Hi,
I've just created that page, see
http://wiki.gimp.org/index.php/Hacking:Plugin_registry
Kind regards,
Sven
___
On 04/12/2014 02:36 AM, Joao S. O. Bueno wrote:
Just for the record, I second all of Jehan's concerns -
Although I don't think the "GIMP authenticated server" should be the only
possible way to install managed plug-ins:
Users should be given an option to change the plug-in server to
"unofficial"
Hi,
On Sat, Apr 12, 2014 at 12:36 PM, Joao S. O. Bueno wrote:
> Just for the record, I second all of Jehan's concerns -
> Although I don't think the "GIMP authenticated server" should be the only
> possible way to install managed plug-ins:
>
> Users should be given an option to change the plug-in
Just for the record, I second all of Jehan's concerns -
Although I don't think the "GIMP authenticated server" should be the only
possible way to install managed plug-ins:
Users should be given an option to change the plug-in server to
"unofficial" ones.
They just should be very clearly warned on
Hi,
On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle wrote:
> Oh, and just to clarify, I also mean that effort for *authors* should be
> taken into account.
Ok well I understood everything until your "clarification". What
effort for which authors?
> On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebo
Oh, and just to clarify, I also mean that effort for *authors* should be
taken into account.
On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebohle wrote:
> Jehan,
>
> I wholeheartedly support your concerns, but I would advise trying to think
> of ways of approaching this in a simpler way. If the reg
Jehan,
I wholeheartedly support your concerns, but I would advise trying to think
of ways of approaching this in a simpler way. If the registry can support
you in that, let me know.
Other than that, the whole searching and browsing UI is likely far from
trivial as you suggest.
cheers
On Fri,
Hi,
On Thu, Apr 10, 2014 at 4:06 PM, scl wrote:
> Hi,
>
> it's interesting to see what interest such a post can trigger ;-)
> To be honest, it wasn't me who started the discussion, I just forwarded
> Ingo's call to the mailing list.
>
> 'GIMP is easily user-extendable, by ‘one-click’ installation
Hi,
it's interesting to see what interest such a post can trigger ;-)
To be honest, it wasn't me who started the discussion, I just forwarded
Ingo's call to the mailing list.
'GIMP is easily user-extendable, by ‘one-click’ installation of
plug-ins.' is a part of our product-vision and as far as
To better understand what I mean about tree see the following URLs.
https://ci.jenkins-ci.org/api/json?pretty=true&tree=jobs[name,url]
versus
https://ci.jenkins-ci.org/api/json?pretty=true
SAM
On Wed, Apr 9, 2014 at 2:24 PM, Sam Gleske wrote:
> On Wed, Apr 9, 2014 at 12:06 PM, Michael Schum
On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher wrote:
> On 09.04.2014 18:03, Seth Burgess wrote:
> > Are we trying to reinvent a package manager here? A lot of the issues I
> > could see coming up have already been addressed by apt/yum/etc - would
> > adapting one of these be a better appro
On 09.04.2014 18:03, Seth Burgess wrote:
> Are we trying to reinvent a package manager here? A lot of the issues I
> could see coming up have already been addressed by apt/yum/etc - would
> adapting one of these be a better approach than reinventing the wheel?
If there is one that can be shipped
On 09.04.2014 17:42, Ingo Lütkebohle wrote:
> If anybody could put up a wiki page for that, that'd be great. Does The
> GIMP have a wiki?
Yes, as Alexandre has mentioned already. And it is also not "The GIMP",
only "GIMP". For ages :)
P.S. I think everyone is subscribed to the list, no need for
Are we trying to reinvent a package manager here? A lot of the issues I
could see coming up have already been addressed by apt/yum/etc - would
adapting one of these be a better approach than reinventing the wheel?
This would facilitate curating a list of trusted/mature plug-ins,
experimental ones
> P.S. Also, there is no such application as The GIMP anymore, for years :)
>
so i've been told many times, but finger memory dies hard ;-)
--
Ingo Lütkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitar
On Wed, Apr 9, 2014 at 7:42 PM, Ingo Lütkebohle wrote:
> If anybody could put up a wiki page for that, that'd be great. Does The
> GIMP have a wiki?
wiki.gimp.org :-P
P.S. Also, there is no such application as The GIMP anymore, for years :)
Alexandre
I would suggest going with a basic REST api (i.e., GET/POST/PUT), which
then means we "only" have to think about the data format. That's a more
difficult discussion, of course.
If anybody could put up a wiki page for that, that'd be great. Does The
GIMP have a wiki?
On Wed, Apr 9, 2014 at 3:2
What are the current statistics of uploaded scripts/plugins? It might help
us to formulate a plan if we knew a little better what the current state of
influx is. (Are we seeing ~5 uploads a week? 10? 20?).
Also, I'm of the opinion that the registry, whatever it ends up becoming,
should be focu
Hi Sven -
It is nice to read this -
I am very interested in having it working on "the client side" - that is, a
GIMP plug-in that
could make one-click download of plug-ins, scripts and other resources
(brushes, tool settings, gradients and so on).
Having an API SPEC for the registry would be some
On 09.04.2014 14:51, Alexandre Prokoudine wrote:
> The expected effect of that will be a huge increase of deployed
> extensions and, as a consequence, an increased interest to GIMP from
> people who write exploits. My concern is how this interest can
> realistically be handled, because we shall be
On Wed, Apr 9, 2014 at 4:43 PM, Tobias Jakobs wrote:
>> It's a wee bit more complicated. Think of e.g. security concerns.
>> Sure, you can sit down and analyze the code of every submitted plugin,
>> but this solution is not scalable, and a scalable solution (as in
>> "automated check for exploits"
On 09.04.2014 14:43, Tobias Jakobs wrote:
>> It's a wee bit more complicated. Think of e.g. security concerns.
>> Sure, you can sit down and analyze the code of every submitted plugin,
>> but this solution is not scalable, and a scalable solution (as in
>> "automated check for exploits") is likely
Hi!
2014-04-09 14:14 GMT+02:00 Alexandre Prokoudine <
alexandre.prokoud...@gmail.com>:
> On Wed, Apr 9, 2014 at 3:57 PM, Ingo Lütkebohle wrote:
> > Alexander,
> >
> > the Registry currently has support for uploading binary plugins, so those
> > could be downloaded over the interface as well.
> >
On Wed, Apr 9, 2014 at 3:57 PM, Ingo Lütkebohle wrote:
> Alexander,
>
> the Registry currently has support for uploading binary plugins, so those
> could be downloaded over the interface as well.
>
> How the binary plugins arrive in the registry is a different issue. I don't
> have much to offer on
Alexander,
the Registry currently has support for uploading binary plugins, so those
could be downloaded over the interface as well.
How the binary plugins arrive in the registry is a different issue. I don't
have much to offer on that front, because I can't compile for Windows and
Mac OS X. Howe
..
> I think, if Ingo is talking about plugins, he is talking about Gimp
> plugins and not about plugins in CMS systems.
>
> Regards
>
..and I mean Drupal plugins for developing / improving the functionality of
the actual gimp registry website - BTW - we all know that gimp plungin
registry is abo
On Wed, Apr 9, 2014 at 3:27 PM, Ingo Lütkebohle wrote:
> Regarding the server-side, my preference would be to keep Drupal right now.
> We can fairly easily expose the existing database through the "Services"
> module (see https://drupal.org/project/services). Once we have a clear
> interface, chan
2014-04-09 13:04 GMT+02:00 SorinN :
> Can be taken - but a web(designer/developer) need good specs before
> starting this task.
>
> There are plenty of CMS'es on the wild - most of them with many ready-made
> modules Joomla / Word Press/ CMSMS - they are the easy to implement (and
> not hard to mo
Hi,
I understand and support your request for a clear specification, but would
say that it is something to be discussed jointly. I wouldn't presume to
"demand" anything of a client-side developer. This would be more of a talk,
where we see what's possible easily, what would be more effort, etc. It
Can be taken - but a web(designer/developer) need good specs before
starting this task.
There are plenty of CMS'es on the wild - most of them with many ready-made
modules Joomla / Word Press/ CMSMS - they are the easy to implement (and
not hard to modify).
Drupal is solid and well documented for
On 8.4.2014 at 10:44 AM wrote:
Gimp Registry Future
Dear Registry Users,
I have maintained the registry for over 15 years now, and for the last
couple of years we have had an excellent team of co-maintainers who took
on a lot of the work. However, there are some much needed improvements
whic
34 matches
Mail list logo
