Re: [Gimp-developer] New asset / extension manager
Ouch, so the "Gimp extension format" is already 2 years old... https://gitlab.gnome.org/search?project_id=1848=commits=Gimp+extension On Sat, Dec 4, 2021, 22:33 Michal Vašut wrote: > Joao, yes I'm aware of some plugin that did this job. Is it somewhere on > the web or in public repository? > > I would like to help with something, but entire thing is either frozen or > done privately. > > I know (and I was multiple times told) that Gimp devs are not employees in > some corporate and they are doing things in their spare time, but there are > some things that should be IMHO more open, like > > - project goals - what's the result of the project (e.g. extension file > format and it's integration to gimp, desktop client, server backend, Web > app,...) > - analysis - what's already done, what needs to be done (like details of > the project goals,...), some interface specs,... > - GUI drafts > > This would IMHO help a lot. > > Nobody says this all must be done by core devs - well only 1st point > (project goals) and following moderation of the project. > > On Sat, Dec 4, 2021, 18:30 Joao S. O. Bueno wrote: > >> No progress - >> But I've been talking to Americo over the last 2-3 weeks to start some >> movement on that direction. >> >> I had some work done in 2018, but it was a Python 2 plug-in with >> requirements for a server-side API - >> maybe I will revisit some of that >> >> I did not even know about this extension format in the ChangeLog you >> pointed. It certainly will be useful. >> >> On Sat, 4 Dec 2021 at 12:31, Michal Vašut via gimp-developer-list < >> gimp-developer-list@gnome.org> wrote: >> >>> Huh, just found some info on gitlab, but not sure, how old it is (those >>> commit messages are not very descriptive): >>> >>> - New extension format support (.gex a.k.a. GIMP Extension) which is >>> an archive containing various supported data. So far, it can >>> package: brushes, MyPaint brushes, dynamics, patterns, gradients, >>> palettes, tool presets, plug-ins, splash images and themes. >>> - New extension manager allowing to enable, disable or uninstall >>> installed extensions, with a dialog available in `Edit > Manage >>> Extensions`. >>> >>> https://gitlab.gnome.org/GNOME/gimp/-/blob/master/NEWS#L540 >>> >>> >>> I will dig in... >>> >>> >>> >>> On Sat, Dec 4, 2021, 15:56 Michal Vašut wrote: >>> >>> > Any progress here? (not pushing, just asking) >>> > >>> > On Wed, Jan 8, 2020, 21:51 Ofnuts wrote: >>> > >>> >> On 1/8/20 11:00 AM, Jehan Pagès via gimp-developer-list wrote: >>> >> > Unless by priority you mean throwing my family, friends and life >>> under >>> >> the >>> >> > bus to get it done yesterday, because yeah I don't have any of >>> these and >>> >> > won't ever have. >>> >> > >>> >> And you haven't even got a bus right now :) >>> >> >>> >> ___ >>> >> 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-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-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] New asset / extension manager
Joao, yes I'm aware of some plugin that did this job. Is it somewhere on the web or in public repository? I would like to help with something, but entire thing is either frozen or done privately. I know (and I was multiple times told) that Gimp devs are not employees in some corporate and they are doing things in their spare time, but there are some things that should be IMHO more open, like - project goals - what's the result of the project (e.g. extension file format and it's integration to gimp, desktop client, server backend, Web app,...) - analysis - what's already done, what needs to be done (like details of the project goals,...), some interface specs,... - GUI drafts This would IMHO help a lot. Nobody says this all must be done by core devs - well only 1st point (project goals) and following moderation of the project. On Sat, Dec 4, 2021, 18:30 Joao S. O. Bueno wrote: > No progress - > But I've been talking to Americo over the last 2-3 weeks to start some > movement on that direction. > > I had some work done in 2018, but it was a Python 2 plug-in with > requirements for a server-side API - > maybe I will revisit some of that > > I did not even know about this extension format in the ChangeLog you > pointed. It certainly will be useful. > > On Sat, 4 Dec 2021 at 12:31, Michal Vašut via gimp-developer-list < > gimp-developer-list@gnome.org> wrote: > >> Huh, just found some info on gitlab, but not sure, how old it is (those >> commit messages are not very descriptive): >> >> - New extension format support (.gex a.k.a. GIMP Extension) which is >> an archive containing various supported data. So far, it can >> package: brushes, MyPaint brushes, dynamics, patterns, gradients, >> palettes, tool presets, plug-ins, splash images and themes. >> - New extension manager allowing to enable, disable or uninstall >> installed extensions, with a dialog available in `Edit > Manage >> Extensions`. >> >> https://gitlab.gnome.org/GNOME/gimp/-/blob/master/NEWS#L540 >> >> >> I will dig in... >> >> >> >> On Sat, Dec 4, 2021, 15:56 Michal Vašut wrote: >> >> > Any progress here? (not pushing, just asking) >> > >> > On Wed, Jan 8, 2020, 21:51 Ofnuts wrote: >> > >> >> On 1/8/20 11:00 AM, Jehan Pagès via gimp-developer-list wrote: >> >> > Unless by priority you mean throwing my family, friends and life >> under >> >> the >> >> > bus to get it done yesterday, because yeah I don't have any of these >> and >> >> > won't ever have. >> >> > >> >> And you haven't even got a bus right now :) >> >> >> >> ___ >> >> 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-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-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] New asset / extension manager
Huh, just found some info on gitlab, but not sure, how old it is (those commit messages are not very descriptive): - New extension format support (.gex a.k.a. GIMP Extension) which is an archive containing various supported data. So far, it can package: brushes, MyPaint brushes, dynamics, patterns, gradients, palettes, tool presets, plug-ins, splash images and themes. - New extension manager allowing to enable, disable or uninstall installed extensions, with a dialog available in `Edit > Manage Extensions`. https://gitlab.gnome.org/GNOME/gimp/-/blob/master/NEWS#L540 I will dig in... On Sat, Dec 4, 2021, 15:56 Michal Vašut wrote: > Any progress here? (not pushing, just asking) > > On Wed, Jan 8, 2020, 21:51 Ofnuts wrote: > >> On 1/8/20 11:00 AM, Jehan Pagès via gimp-developer-list wrote: >> > Unless by priority you mean throwing my family, friends and life under >> the >> > bus to get it done yesterday, because yeah I don't have any of these and >> > won't ever have. >> > >> And you haven't even got a bus right now :) >> >> ___ >> 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-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] New asset / extension manager
Any progress here? (not pushing, just asking) On Wed, Jan 8, 2020, 21:51 Ofnuts wrote: > On 1/8/20 11:00 AM, Jehan Pagès via gimp-developer-list wrote: > > Unless by priority you mean throwing my family, friends and life under > the > > bus to get it done yesterday, because yeah I don't have any of these and > > won't ever have. > > > And you haven't even got a bus right now :) > > ___ > 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-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] New asset / extension manager
Thanks Alex, that makes it clearer. Just one thing. Could you please Copy this text to Gimp.org? You've put a lot of effort into it and it would be pity not to share it with the world. Here it will be forgotten (lost) very soon. On Wed, Jan 8, 2020, 18:04 Alexandre Prokoudine via gimp-developer-list < gimp-developer-list@gnome.org> wrote: > On Wed, Jan 8, 2020 at 7:17 PM Michal Vašut wrote: > > > > > By priority I meant that Gimp team is pushing new features (that don't > look > > like prerequisites for that manager) > > > Over the years, I've heard a lot of interesting ideas that suggest that > GIMP team members can replace each other or work on each other's tasks. > > You seem to be under the same kind of impression. Perhaps we should > communicate our roles and interests better. > > - Mitch knows GIMP in and out, can hack both back-end and front-end code, > but currently focuses on refactoring, all things color management, and > reviewing patches coming from other people. > > - Jehan has a wide range of interests mostly stemming from stuff his wife > needs for their animation project. He does both back-end and front-end work > related to painting and animation. But since plugins management is pain, > that's also among things he wants to improve. While he has a long history > of fixing bugs, he mostly works on new features. > > - Ell focuses on performance and new features that involve interaction on > the canvas. He understands the back-end very well and contributes to GEGL > as well. > > - Pippin has a comparatively light footprint in GIMP's source code, GEGL > and babl are the libraries where his contributions mostly go. Hence his > work directly affects how GIMP pushes pixels around and whether pixels get > pushed where they ought to be. > > - Thomas Manni works mostly on GEGL operations and also has a light > footprint in GIMP's code. But his work helps GIMP provide sensible, useful, > and fast filters for end-users. > > That's 5 top contributors in terms of code. Every one of them has his own > interests and specialization — an area where they shine. > > There are more contributors, like Massimo and Elle. Maybe they are supposed > to work towards plugin management. Well, nope. Let me tell you about them. > > Massimo is a prolific contributor of small sane patches that apply cleanly > and work very well. He mastered this art, and we treasure him for sticking > around and doing just that. We'd never expect him to do some massive work > involving redesigning GIMP, because, as far as I can tell, he's not exactly > interested in big stuff. > > Elle is amazing at what she understands very well — color science. Color > space converison, LAB/xyY/etc. spaces support in the color picker and > sample points — that's the kind of work she does. > > So when you are looking at Ell adding a 3D Transform tool or Thomas adding > a new GEGL filter, or Elle adding Yu'v' (CIE 1976 UCS) support to GIMP > color picker, please do not expect them to drop everything and start > hacking on something that is out of scope of their interest. This is not > how it works. > > I hoped I cleared this up a little. If you have more questions, shoot :) > > P.S. You did not say anything of the kind, but since this is related and > still preying on my mind, to everyone who thinks contributors should have > worked on CMYK support or non-destructive image editing instead of > designing the greyscale icon theme I'll just say this: P :) > > Alex > ___ > 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-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] New asset / extension manager
Hey dude, calm down. Where have I written about "throwing your family, friends and life under the bus" or "black magic instant coding" ? Why are you angry (offended)? Of course I don't know what you're doing. (only what you expose on Gitlab or blog) By priority I meant that Gimp team is pushing new features (that don't look like prerequisites for that manager) and that one that I'm looking for the most looks freezed (at least from outside). So I assume it's only your priority (not priority of the whole team). In that case I understand that creating something new (besides bugfixing, infrastructure maintenance,...) takes some time. I'm developer myself, trust me, I know well how it works. ✌️ On Wed, Jan 8, 2020, 11:01 Jehan Pagès wrote: > Hi, > > On Wed, Jan 8, 2020 at 7:10 AM Michal Vašut > wrote: > >> Ok, so it's not priority... >> > > I re-read my email. Nowhere do I say such thing. I consider this project > to be one of my main priorities (I'd say it's easy in the top 10 of the > GIMP-related things I want to see happening as soon as possible). Hence I > talk about it in posts, I started implementing it and so on. We have been > discussing this stuff for years and years. Priority does not mean "black > magic instant coding". > Not giving deadlines does not mean not priority either. > > Unless by priority you mean throwing my family, friends and life under the > bus to get it done yesterday, because yeah I don't have any of these and > won't ever have. > > It's a pity, I think it would be much more useful and beneficial for Gimp >> that other things you guys do. But, it's your choice how you spend your >> free time... >> > > How do you know what else I do? I don't think you can decide that this > project is more important than any other things I've been doing, sorry. :-) > > Anyway, thanks for answer a have a successful 2020. >> > > Same for you, have a happy 2020! > > Jehan > > >> On Tue, Jan 7, 2020, 11:25 Jehan Pagès >> wrote: >> >>> Hi, >>> >>> On Sun, Jan 5, 2020 at 11:37 PM Michal Vašut >>> wrote: >>> Hello Jehan, I know you've made some work on new extension manager - you've presented some GUI prototypes in the past and I also read about some huge backend refactoring, fixes and added support for JS and Lua for extension scripting. How far is it? Or better, how close to be released? It's without doubt huge task, and I understand how difficult is to work with such old codebase and don't mess up something else, so I don't want to put any pressure on you. Only thing I want to know is some rough estimate when it will be done.1st half of 2020? Second half? Next year? >>> >>> I'm sorry, we don't do dates. We don't do rough estimates either. >>> >>> Things will be done when it's ready, that's it. I haven't taken the time >>> to work on this particular feature the last few months as I was doing other >>> stuff. I will continue implementing the feature. I can't tell when this >>> will happen and when this will be finished. I don't know either. >>> >>> Jehan >>> >>> -- >>> ZeMarmot open animation film >>> http://film.zemarmot.net >>> Liberapay: https://liberapay.com/ZeMarmot/ >>> Patreon: https://patreon.com/zemarmot >>> Tipeee: https://www.tipeee.com/zemarmot >>> >> > > -- > ZeMarmot open animation film > http://film.zemarmot.net > Liberapay: https://liberapay.com/ZeMarmot/ > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > ___ 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] New asset / extension manager
Ok, so it's not priority... It's a pity, I think it would be much more useful and beneficial for Gimp that other things you guys do. But, it's your choice how you spend your free time... Anyway, thanks for answer a have a successful 2020. On Tue, Jan 7, 2020, 11:25 Jehan Pagès wrote: > Hi, > > On Sun, Jan 5, 2020 at 11:37 PM Michal Vašut > wrote: > >> Hello Jehan, I know you've made some work on new extension manager - >> you've presented some GUI prototypes in the past and I also read about some >> huge backend refactoring, fixes and added support for JS and Lua for >> extension scripting. How far is it? Or better, how close to be released? >> It's without doubt huge task, and I understand how difficult is to work >> with such old codebase and don't mess up something else, so I don't want to >> put any pressure on you. Only thing I want to know is some rough estimate >> when it will be done.1st half of 2020? Second half? Next year? >> > > I'm sorry, we don't do dates. We don't do rough estimates either. > > Things will be done when it's ready, that's it. I haven't taken the time > to work on this particular feature the last few months as I was doing other > stuff. I will continue implementing the feature. I can't tell when this > will happen and when this will be finished. I don't know either. > > Jehan > > -- > ZeMarmot open animation film > http://film.zemarmot.net > Liberapay: https://liberapay.com/ZeMarmot/ > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > ___ 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] New asset / extension manager
Hello Jehan, I know you've made some work on new extension manager - you've presented some GUI prototypes in the past and I also read about some huge backend refactoring, fixes and added support for JS and Lua for extension scripting. How far is it? Or better, how close to be released? It's without doubt huge task, and I understand how difficult is to work with such old codebase and don't mess up something else, so I don't want to put any pressure on you. Only thing I want to know is some rough estimate when it will be done.1st half of 2020? Second half? Next year? ___ 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] When writing a GIMP Plugin using Python, can the Plugin display a GIMP based Dialog box informing the user if they haven't provided an argument?
You should IMHO prevent performing an operation when the input is invalid. Yes, it's definitely easier to throw an exception, but those are IMHO rather to deal with some unexpected errors. On Sat, May 11, 2019, 23:44 Ofnuts wrote: > If the plugin is for public use, gimp.message() is a better solution > because it will display in a dialog box or in the Gimp message console > depending on user preferences. You don't really need to drag in all the > GTK support just to display an error message. > > On the other hand, I don't see how you pass a list of files to a > plugin.. If this is a batch script, things are a bit different, but then > there may be no UI at all, and the message would be better printed to > the console. > > On 5/9/19 1:32 AM, Craig Sanders via gimp-developer-list wrote: > > Ahhh. I didn't even think that it might be able to be done that way - but > > your solution is exactly what I was looking for. Thankyou very much. > > > > I was thinking that there might be a GIMP Procedure such as; > > > > pdb.display_dialog(...) > > > > or something similar. > > > > After I submitted my question, I found a snippet of Python code on the > > Internet which did what I needed, but nowhere near as nicely as your > > answer. When I modified this snippet of Python code, it looked as > follows; > > > > import gtk > > > > # A whole lot of code has been left out here!!! > > > > errDialog = gtk.MessageDialog( > > > > None, > > > > 0, > > > > gtk.MESSAGE_ERROR, > > > > gtk.BUTTONS_OK, > > > > "You must specify at least one file." > > > > ) > > > > errDialog.show_all() > > > > errDialog.run() > > > > # And a whole lot of code has been left out here!!! > > > > Thanks once again for your assistance. It is most appreciated. > > > > On Thu, May 9, 2019 at 1:22 AM Carol Spears > wrote: > > > >> > >> On Wednesday, May 8, 2019, Craig Sanders via gimp-developer-list < > >> gimp-developer-list@gnome.org> wrote: > >> > >>> Hello. > >>> > >>> I am writing a GIMP Plugin using Python, and this Plugin expects to > >>> receive > >>> a list of files as one of its arguments. My question is, if the user > >>> doesn't provide any files as arguments, can my Plugin display a GIMP > based > >>> Dialog box informing them of this? > >>> > >> gimp.message(You did not provide files) > >> > >> The message part should be in quotes probably > >> > > ___ > > 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-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-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] UV mapping of OBJ???
Hello, I've just read an article at Gimp site ( https://www.gimp.org/news/2019/01/02/gimp-and-gegl-in-2018/ ) and here is proposal of possible new feature mentioned there: "There are all sorts of other interesting ideas for plug-ins, like UV unwrapping from OBJ files for texturing." Is that really necessary in 2D editor? Let the 3D artist export UV wireframe in 3D software of his / her choice into some 2D format and then he / she can work on texture even with current version of Gimp. 3D software suites today already have functionality for UV mapping and even painting directly on the surface of model (resp. on mapped texture). What would be benefits of such thing in Gimp? Thanks for answer, Michal. ___ 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] Progress of Asset / Plugin manager
Happy new year, I have 2 questions about plugin manager and since there is already thread, I will use it. 1. Will the manager support binary extensions? ... Well scripts will run anywhere (I think), but binary (compiled) extensions are platform specific and there are some devs, that only creates extensions in their platform and don't care about others. Wouldn't that (platform support) be somehow marked in metadata? 2. Will the manager support dealing with dependencies (like if the extension requires some library I will download it or if no one uses this library I will remove it) or every extension will have to contain every library it needs? Thanks for answer. Michal On Wed, Dec 19, 2018, 15:40 Michal Vašut Ok, no problem... > > Yeah, the best way is to do without asking, but that is problem when you > don't have skill :-D <=> that was also reason why I was asking in the first > place - Gimp (its C code) is quiet hardcore and therefore there is so few > devs capable (and willing) to contribute. > Ok, thanks for making it little bit more clearer and have a nice Xmas > holidays. > > Michal > > On Wed, Dec 19, 2018, 13:12 Jehan Pagès >> Hi! >> >> On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut >> wrote: >> >>> Uff, I have feeling (from your text) like I've been pierced by thousands >>> of swords. I've meant no offense nor asked from you to do anything. I've >>> only asked the reason why and from your response I've found the reason is >>> historical. That's all I've wanted to hear and I fully understand that >>> transition to some modern technology is pretty resource expensive or >>> impossible (in my work me and team, we are maintaining and improving 20+ >>> years old legacy monster code written in Delphi, so be ensured that I quiet >>> know what you are talking about) >>> >> >> Yes sorry. My answer was definitely a bit annoyed, I should not have >> written it this way. >> It's just that we get this question once every few months (maybe more, I >> don't follow all discussions/ML much) and regular requests to change to >> this or that language (whatever is the current fashion, javascript, python, >> rust…). It's just a bit annoying. Also the time I wrote this answer (10PM) >> probably did not help. >> >> But in any case, I should not have written away any frustration to you. >> So, sorry again for this. >> As you say, yeah the shorter answer is "it's historical". >> Let's keep it at it and pretend I have not written the previous answer. >> ;-) >> Thanks! >> >> Jehan >> >> P.S.: this said, I really meant it when I say I am all for genius >> contributions proving us wrong. For this or other topics, the best option >> is often to just propose a patch. Of course it's a risk and is high work >> (like really really; I would expect this to take many many many months full >> time to port every single bit), but that's also what I do when I want to >> contribute to some other software. I don't wait for approval, I do and hope >> for the best. :-) >> >> On Tue, Dec 18, 2018, 22:00 Jehan Pagès >> wrote: >>> Hi! On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut wrote: > Cool, thanks for info. I've checked the page on your blog and have > some notes to metadata that would be included: > > > org.gimp.GIMP > > > I assume that "ge" value of "compare" attribute means "greater or > equal". That's the possible way to do it. Here is another way how other > systems deals with the same problem: > https://madewithlove.be/tilde-and-caret-constraints/ > And here some related tester: https://semver.npmjs.com > I am not going to change the appdata format. If you absolutely wish to go this way, you can contribute to the format specification (they are hosted at freedesktop), though to be fair, I doubt they are going to change it (it has been used for years now, and is widely spread on Linux distributions: basically all software management is based on this nowadays), nor do I see much need (as you say yourself even!). I don't say one way is better than other, it's just to prevent you > reinventing the wheel (in case you are not aware of this way). > Well the whole point is to not reinvent any wheel, which is why I am not going to change anything here. > 2nd thing, I'm missing Tags section in metadata, it's not necessary, > but nice to have - great sorting / grouping ability. > That's what the `` tag is for, I believe. --- > > BTW I've also checked the code in repo (for the 1st time) and realized > that it's written in C. Just out of curiosity, why is that? Historical > reasons? Performance reasons? IMHO it brings huge complexity > For the same reason I am not going to change the appdata format: when you contribute to a software, you don't try to change all its basics. And GIMP is indeed written in C. This has
Re: [Gimp-developer] Progress of Asset / Plugin manager
Ok, no problem... Yeah, the best way is to do without asking, but that is problem when you don't have skill :-D <=> that was also reason why I was asking in the first place - Gimp (its C code) is quiet hardcore and therefore there is so few devs capable (and willing) to contribute. Ok, thanks for making it little bit more clearer and have a nice Xmas holidays. Michal On Wed, Dec 19, 2018, 13:12 Jehan Pagès Hi! > > On Wed, Dec 19, 2018 at 1:16 AM Michal Vašut > wrote: > >> Uff, I have feeling (from your text) like I've been pierced by thousands >> of swords. I've meant no offense nor asked from you to do anything. I've >> only asked the reason why and from your response I've found the reason is >> historical. That's all I've wanted to hear and I fully understand that >> transition to some modern technology is pretty resource expensive or >> impossible (in my work me and team, we are maintaining and improving 20+ >> years old legacy monster code written in Delphi, so be ensured that I quiet >> know what you are talking about) >> > > Yes sorry. My answer was definitely a bit annoyed, I should not have > written it this way. > It's just that we get this question once every few months (maybe more, I > don't follow all discussions/ML much) and regular requests to change to > this or that language (whatever is the current fashion, javascript, python, > rust…). It's just a bit annoying. Also the time I wrote this answer (10PM) > probably did not help. > > But in any case, I should not have written away any frustration to you. > So, sorry again for this. > As you say, yeah the shorter answer is "it's historical". > Let's keep it at it and pretend I have not written the previous answer. ;-) > Thanks! > > Jehan > > P.S.: this said, I really meant it when I say I am all for genius > contributions proving us wrong. For this or other topics, the best option > is often to just propose a patch. Of course it's a risk and is high work > (like really really; I would expect this to take many many many months full > time to port every single bit), but that's also what I do when I want to > contribute to some other software. I don't wait for approval, I do and hope > for the best. :-) > > On Tue, Dec 18, 2018, 22:00 Jehan Pagès > >>> Hi! >>> >>> On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut >>> wrote: >>> Cool, thanks for info. I've checked the page on your blog and have some notes to metadata that would be included: org.gimp.GIMP I assume that "ge" value of "compare" attribute means "greater or equal". That's the possible way to do it. Here is another way how other systems deals with the same problem: https://madewithlove.be/tilde-and-caret-constraints/ And here some related tester: https://semver.npmjs.com >>> >>> I am not going to change the appdata format. If you absolutely wish to >>> go this way, you can contribute to the format specification (they are >>> hosted at freedesktop), though to be fair, I doubt they are going to change >>> it (it has been used for years now, and is widely spread on Linux >>> distributions: basically all software management is based on this >>> nowadays), nor do I see much need (as you say yourself even!). >>> >>> I don't say one way is better than other, it's just to prevent you reinventing the wheel (in case you are not aware of this way). >>> >>> Well the whole point is to not reinvent any wheel, which is why I am not >>> going to change anything here. >>> >>> 2nd thing, I'm missing Tags section in metadata, it's not necessary, but nice to have - great sorting / grouping ability. >>> >>> That's what the `` tag is for, I believe. >>> >>> --- BTW I've also checked the code in repo (for the 1st time) and realized that it's written in C. Just out of curiosity, why is that? Historical reasons? Performance reasons? IMHO it brings huge complexity >>> >>> For the same reason I am not going to change the appdata format: when >>> you contribute to a software, you don't try to change all its basics. And >>> GIMP is indeed written in C. This has been so for 23 years now. I don't see >>> why it is complex by the way. I have programmed in a lot of languages (many >>> script languages as well, I even maintain some software mostly made in >>> Python, etc.) and I find C just fine. >>> >>> * in code itself - only emulation of OOP through GObject creates lot of code * for developers - the graphical math, theorises algorithms are difficult on its own, now here is C code that is in this age quiet hardcore to use with its non-OOP / structured paradigm ( most of devs code in OOP languages these days). Well I can definitely read and understand what's going on in the Gimp code, but it would take quiet long time to write something useful. > >>> I am not interested in discussing a port of GIMP to some language X, if >>> not for the first reason
Re: [Gimp-developer] Progress of Asset / Plugin manager
Uff, I have feeling (from your text) like I've been pierced by thousands of swords. I've meant no offense nor asked from you to do anything. I've only asked the reason why and from your response I've found the reason is historical. That's all I've wanted to hear and I fully understand that transition to some modern technology is pretty resource expensive or impossible (in my work me and team, we are maintaining and improving 20+ years old legacy monster code written in Delphi, so be ensured that I quiet know what you are talking about) On Tue, Dec 18, 2018, 22:00 Jehan Pagès Hi! > > On Tue, Dec 18, 2018 at 9:05 PM Michal Vašut > wrote: > >> Cool, thanks for info. I've checked the page on your blog and have some >> notes to metadata that would be included: >> >> >> org.gimp.GIMP >> >> >> I assume that "ge" value of "compare" attribute means "greater or equal". >> That's the possible way to do it. Here is another way how other systems >> deals with the same problem: >> https://madewithlove.be/tilde-and-caret-constraints/ >> And here some related tester: https://semver.npmjs.com >> > > I am not going to change the appdata format. If you absolutely wish to go > this way, you can contribute to the format specification (they are hosted > at freedesktop), though to be fair, I doubt they are going to change it (it > has been used for years now, and is widely spread on Linux distributions: > basically all software management is based on this nowadays), nor do I see > much need (as you say yourself even!). > > I don't say one way is better than other, it's just to prevent you >> reinventing the wheel (in case you are not aware of this way). >> > > Well the whole point is to not reinvent any wheel, which is why I am not > going to change anything here. > > >> 2nd thing, I'm missing Tags section in metadata, it's not necessary, but >> nice to have - great sorting / grouping ability. >> > > That's what the `` tag is for, I believe. > > --- >> >> BTW I've also checked the code in repo (for the 1st time) and realized >> that it's written in C. Just out of curiosity, why is that? Historical >> reasons? Performance reasons? IMHO it brings huge complexity >> > > For the same reason I am not going to change the appdata format: when you > contribute to a software, you don't try to change all its basics. And GIMP > is indeed written in C. This has been so for 23 years now. I don't see why > it is complex by the way. I have programmed in a lot of languages (many > script languages as well, I even maintain some software mostly made in > Python, etc.) and I find C just fine. > > >> * in code itself - only emulation of OOP through GObject creates lot of >> code >> * for developers - the graphical math, theorises algorithms are difficult >> on its own, now here is C code that is in this age quiet hardcore to use >> with its non-OOP / structured paradigm ( most of devs code in OOP languages >> these days). Well I can definitely read and understand what's going on in >> the Gimp code, but it would take quiet long time to write something useful. >> >>> > I am not interested in discussing a port of GIMP to some language X, if > not for the first reason that the work required to do such port would just > block us for years (and you would not see GIMP 3 for like 10 years?! > Neither the extension manager as well of course, since we'd have no time to > implement it anymore, nor any of the cool new features we are bringing in > nowadays). > > Now I am happy to be wrong, and if someone were to port the GUI part of > GIMP into some well maintained and interesting/powerful/simple language, > making any graphics change easier, without any regression or feature loss, > if this person contributes us a working patch tomorrow, I test it, it just > works and keeps all the "promises", then I'd be the first to consider the > patch for inclusion (though I would not be the only one to decide). But > other than this, please don't ask us to do some work which we find not > useful. I have a lot of things where I want to see GIMP improve (see my > signature; we are making an animation film, as a professional studio, and > my main worry is not the language of GIMP but what it can do and how, and > if it is stable/fast) and spending years to change our base language is > certainly not one of these. > Sorry. :-) > > Jehan > > -- > ZeMarmot open animation film > http://film.zemarmot.net > Liberapay: https://liberapay.com/ZeMarmot/ > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > ___ 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] Progress of Asset / Plugin manager
Cool, thanks for info. I've checked the page on your blog and have some notes to metadata that would be included: org.gimp.GIMP I assume that "ge" value of "compare" attribute means "greater or equal". That's the possible way to do it. Here is another way how other systems deals with the same problem: https://madewithlove.be/tilde-and-caret-constraints/ And here some related tester: https://semver.npmjs.com I don't say one way is better than other, it's just to prevent you reinventing the wheel (in case you are not aware of this way). 2nd thing, I'm missing Tags section in metadata, it's not necessary, but nice to have - great sorting / grouping ability. --- BTW I've also checked the code in repo (for the 1st time) and realized that it's written in C. Just out of curiosity, why is that? Historical reasons? Performance reasons? IMHO it brings huge complexity * in code itself - only emulation of OOP through GObject creates lot of code * for developers - the graphical math, theorises algorithms are difficult on its own, now here is C code that is in this age quiet hardcore to use with its non-OOP / structured paradigm ( most of devs code in OOP languages these days). Well I can definitely read and understand what's going on in the Gimp code, but it would take quiet long time to write something useful. > ___ 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] Progress of Asset / Plugin manager
Hi Jehan, thanks for answer. Do you have the code in some public repository to take a peek? On Fri, Dec 14, 2018, 11:49 PM Jehan Pagès Hi, > > If in the past means 2/3 months ago, then yes. That's work-in-progress > which I am resuming these days and I hope we should be able to have > something in a few months. > > Jehan > > > On Fri, Dec 14, 2018 at 6:37 PM Michal Vašut via gimp-developer-list < > gimp-developer-list@gnome.org> wrote: > >> I think Jehan did some work on this in the past. Is there some progress on >> this? Or maybe some Windows binary to test it out? ;-) >> ___ >> 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 >> > > > -- > ZeMarmot open animation film > http://film.zemarmot.net > Liberapay: https://liberapay.com/ZeMarmot/ > Patreon: https://patreon.com/zemarmot > Tipeee: https://www.tipeee.com/zemarmot > ___ 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] Progress of Asset / Plugin manager
I think Jehan did some work on this in the past. Is there some progress on this? Or maybe some Windows binary to test it out? ;-) ___ 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
