I’m also wondering if you can debug your code by adding breakpoints to the devtools. When I do that (pinegrow for linux) pinegrow closes as soon as I interact with any UI element, including the standard one.
I think the docs are still being reworked for Pinegrow version 4+ , and added to further. So hopefully at some point the Dev API and Plugins get discussed and documented further also.
These days, 99% of users worldwide are working at least with one framework-grid, so the need of plugins as I am defining them is probably not very high.
But if someone is like me (two or three persons should even live somewhere) - preferring the start from scratch (or even develop your own grid) - it would be heavily cool to flavor this world with more micro-plugins (comparable to Freeway’s action e.g.).
So having a stand-alone carousel or slider - or a google map - or a google analytics or any other lil helper would be of really cool.
Currently it’s for me nearby impossible to extract them from the big frameworks - I’m simply not good enough.
The above comment in a recent thread, once again brings into question when we might be able to expect proper documentation for the “Pinegrow Plugin / Developer API” ?
** Surely there must reside somewhere internally documentation or at least full code comments from when it was initially developed and implemented? ;–)
Discussion of providing proper documentation has been mentioned for some time:
More documentation will be available soon. —— February 15 2017
Another year has passed, and PG5 is now on the horizon.
I’m sure many have looked through all the available information, plugins, along with the files in the Pinegrow App Bundle itself. Yet so much is still vague as you try to piece together and trace the purpose, all the available function calls, events, properties, etc.
Please provide us with a complete and proper API listing and documentation. No doubt many would love to develop and add more plugins and features to Pinegrow if they were only better equipped to do so.
documentation and API are always heavily agreed and welcome - sure.
Personally spoken, “Trial and Error ” mostly sucks.
But there isn’t a better feeling figuring out something you fought for days. Hooray - it’s like being the of the .
Whatsoever! Another point to think about could be a (mainly) closed Slack discussion between manufacturer and plugin writers. Closed just because I think into another direction:
A plugin can be powerful. It can heavily extend PG and it could be even part of PG default. So on the one hand, a remote person is working on a task which is on developers plan anyway - so twice the work.
An example could be CSS-Grid. Recently, I tried to add a very basic version to my Reginald-Framework. Meanwhile @matjaz wrote a version thousands time better which is now part of to the APP core. Certainly a much better one - the greatest in market at the day of writing - just for the protocol, and thanks to @matjaz for wrapping its use with those nice video-screencasts.
Another thing could be the <picture> element I recently picked up (after years) once again as responsive images concept. It’s not part of the library so far. A basic version of it could be part of my framework as well. But it could be even part of the default lib - so twice the work again … or?
That’s why I tend not discussing all and everything on a public platform - keeping some smaller things kinda hidden. And who knows? Some of those discussion members even help building this API - or documentation or whatever job that needs to be done there (such as translating stuff or whatever).
A couple years down the road from the start of this thread but it now appears good news has finally emerged concerning this topic.
It looks like around the same time of those comments by by @RobM and @matjaz, that RobM was tasked by Matjaz to commence work on developing documentation for the Developer API.
So the forth coming Developer API documentation should end up being pretty comprehensive after seeing some of RobM’s previous work.
Great to see that @RobM is involved with the Developers API Documentation!
And really nice that they joined forces with him. Robert has proven that he got a good knowledge and understanding of it all with his advanced UIKit Plugin and development tutorials about it. Smart move from Pinegrow to put him on the job. And this way it also doesn’t cost the Pinegrow Team valuable development time, which they now can spend and continue to work on other things (that they can only do).
I excavate the entire web, hope that didn’t force things public before you had hoped.
Congratulations on the Docs and joining the Pinegrow team.
Interesting and ironic though wouldn’t you think that “picture & srcset” should have been part of the list that they would have done themselves long ago? Especailly since its been prevalent to the standard of web development and responsive design, with each being virtually are as old as the Pinegrow app itself. ;—)
By comparison its harder to quantify how many potential 3rd party developers, looked and then decided to walk away over the many years that the Dev API Doc’s were not in place. A solid documented API is one of many factors that go into choosing whether a person wants to invest time into extending other peoples products. The same could be said regarding general documentation and its upkeep regarding users deciding to use products. So perhaps @RobM will be tasked to assist there also to update and build out the general docs?
Now that the API is officially being documented, your right @Marf I’m anxious to see what things the Pinegrow team will be able to accomplish now that this will no longer be a burden on the to-do list after so many years. ;—P
Oh my! What did I say, sorry if I gave the wrong impression with my comment. But it was not meant to be ironic, sarcastic or whatever.
I’m not going to debate or find it useful to discuss about that specific feature, “Picture & Srcset”, and if it already had to be long ago be part of the Pinegrow Core or not. That is not relevant or important I think. And I have no opinion about that statement!
Simply said in general, it’s their app, they have their own to-do list, and it’s their decision what and in which order they release certain features!
They, Matjaz and the Pinegrow Team, know and oversee the “big picture” (internal roadmap), on which they act and choose when it’s the right moment for them to implement and release a certain feature. And sometimes a certain feature rely on other features, which they need to do first, before it can be implemented. Or a feature is too specific and only relevant for a small group, or the demand is not high enough (yet). Or there are other features that they find more important to implement and release first.
I’m certain they have a very long list of important and really impressive and relevant features and improvements on their to-do list, but they still have to do them one-by-one.
There is almost always a good reason (like the ones I mentioned above), why a certain feature is not implemented yet. I can not imagine they wait or hold back features on purpose, just to annoy and irritate you!
And what for one person is an essential or important feature is for somebody else not the case. Every person needs or want other things, and they simply can’t please always everybody!
I’m a positive person, and like more to focus on the things that are already available, or announced that are going to be released. Than rather put my time and energy in complaining about missing features, or even discussing about why certain features take that long!
For sure, there are features not implemented yet, that are already been requested multiple times by different people, I like to have also, but I don’t go complain about it or attack Matjaz and the Pinegrow Team. I wait patiently, and I’m happy with every new update and release they able to make available.
Me too, let’s wait and see, time will tell!
It’s also really nice to see that Matjaz is more active on the forum lately! And that he also announced some things they are working on, that we can expect later this year. They not did that before, being open about a roadmap.