implement plugin system

[ksharindam]

I will implement a plugin system. This will make this app extensible while keeping it simple. most of filters in future will be added as plugins.

[zvezdochiot]

Hi @ksharindam .

:question: That is, you want to make the "face" separately, the "functions" separately?

:question: Is it worth splitting "photoquick" into "photoquick" + "photoquick-plugins" (2 repositories)?

[ksharindam]

this will be just like how plugin based image editors work. if you create and install a new filter plugin say "kuwahara filter". This will add a menu item, clicking the menu item may open a dialog and ask for values, then apply filter and return image. You dont have to touch the code of this program when you create a new filter.

[ksharindam]

Is it worth splitting "photoquick" into "photoquick" + "photoquick-plugins" (2 repositories)?

I have not decided yet. Either create a new repository or create a "plugins" folder inside photoquick project directory

[zvezdochiot]

Hi @ksharindam .

Then "photoquick" will become like "IrfanView". Experience of use shows that this is a very good solution. But it returns to the question of dividing into 2 repositories.

PS: This approach will allow you to immediately have your version of "Un-tilt" and mine. It's good. :+1:

[ksharindam]

I was trying to implement the plugin system. It seems either we have to link the plugins to libcanvas.so (from canvas.cpp) or we have to depend on signals and slots to access the functions of canvas object. Because if the plugin is not linked we can not call canvas->showScaled() to update image.

[ksharindam]

if we separately compile canvas.cpp to libcanvas.so , the program will no longer be a single independent executable. And if we use signals and slots instead, plugin code may look dirty.

Which one we should use?

[zvezdochiot]

Hi @ksharindam .

:question: Are you going to pass the Canvas object to the plugin? What for?

I saw passing to plugins either QImage, or some even simpler structure.

[ksharindam]

I am passing Canvas obj to access the current QImage. when a menu item is clicked, and the slot in the plugin is called, there is no way to pass the current QImage. Only way is to keep the pointer to Canvas obj when plugin is loaded and access the QImage anytime.

[zvezdochiot]

@ksharindam say:

there is no way to pass the current QImage.

https://github.com/ImageProcessing-ElectronicPublications/photoquick/blob/45a4640a0ebff945f69694375af5ed8c0e902d4f/src/canvas.h#L13 https://github.com/ImageProcessing-ElectronicPublications/photoquick/blob/45a4640a0ebff945f69694375af5ed8c0e902d4f/src/canvas.h#L16 https://github.com/ImageProcessing-ElectronicPublications/photoquick/blob/45a4640a0ebff945f69694375af5ed8c0e902d4f/src/canvas.h#L23 Not?

QImage *src = Canvas->image;
QImage *dst = plugin(src, params);
Canvas->image = dst;

[ksharindam]

its not that simple

QImage src = Canvas->image; QImage dst = plugin(src, params); Canvas->image = dst;

this piece of code must be inside a slot to which the menu item is connected. each one slot for each of the menu items. so the slot must be inside the plugin itself. you can not create a single slot inside Window object, and connect all menu items.

[zvezdochiot]

Hi @ksharindam .

:question: And if you make a global link to Canvas->image? Although unlikely. Then only through the QImage buffer.

PS: I do not like OOP.

[ksharindam]

check the main.cpp, plugin.h, plugins/* and try to implement src.zip

[zvezdochiot]

Hi @ksharindam .

The scheme is quite efficient and quite simple. Checked on two "plugins":

libgrayscale.so
libinvert.so

I did not check for more complex ones. Attempts to simplify led to a type conflict. I pass.

photoquick-plugin-grayscale.zip photoquick-plugin-invert.zip

QString
FilterPlugin:: menuItem()
{
    return QString("GrayScale");
}

:question: Maybe add?:

QString FilterPlugin:: menuGroup()
{
    return QString("Color");
}

PS: If the "Group" is missing, ignore it for now.

[ksharindam]

It is just the beginning. There is much more work to do. Instead of using another menu group function, I shall use filepath like string, and create menu tree form that.

QString
FilterPlugin:: menuItem()
{
    return QString("Filters/Color/GrayScale");
}

N.B - Effects menu will be renamed to Filters

[zvezdochiot]

@ksharindam say:

and create menu tree form that.

https://github.com/ImageProcessing-ElectronicPublications/photoquick/blob/45a4640a0ebff945f69694375af5ed8c0e902d4f/src/main.cpp#L43 and others will have to be replaced with an array of pointers with realloc.

Significant complication. Maybe not worth it yet?

[ksharindam]

why we have to replace with array of pointers?

[zvezdochiot]

Hi @ksharindam .

How else is it to compactly describe an extensible menu (I am new to Qt)? In GTK, I did this with array of links.

[ksharindam]

OOP is more efficient than procudural languages (at least to me). Programming with Qt requires less code typing than GTK. I will simply use a dictionary (QMap) to store the menu pointers. Can easily access the pointers by passing the path. Such as , store Filters/Color in a map like ... ("Filters/Color" : ptr); It it does not exist , create one, and store in the map.

[zvezdochiot]

Hi @ksharindam .

void Window:: loadPlugins()
{
    QDir pluginsDir(qApp->applicationDirPath());
    pluginsDir.cd("plugins");

:question: Maybe add verify system path? Example: /usr/lib/photoquick/plugins and $HOME/.local/photoquick/plugins.

[ksharindam]

Currently i am working only on the plugin system. Now it can create menu tree, and add multiple menu items inside single plugin. Will implement adding keyshortcut options. And at last i will fix the plugin path.

On Wed, 24 Jun, 2020, 1:45 PM звездочёт, notifications@github.com wrote:

Hi @ksharindam https://github.com/ksharindam .

void Window:: loadPlugins()

{

QDir pluginsDir(qApp->applicationDirPath());

pluginsDir.cd("plugins");

❓ Maybe add verify system path? Example: /usr/lib/photoquick/plugin.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ImageProcessing-ElectronicPublications/photoquick/issues/9#issuecomment-648670472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKWXPW7SIUJILVF4ETENRTRYGY2TANCNFSM4ODHJPUQ .