BETA - Image Editor plugin

[seb_seb0]

Hello,

I have updated the SVN (revision 61)

Changes:

BUGS SOLVED:
    1 - DragImage solved, wxGTK + wxMSW (without #define conditionnal compilation)
    2 - Zoom > 200% + Selection overlaps on left edge: selection is only partially drawn.
    3 - Context menu: when a mouse click close the context menu, it should not send a mouse click event (because it clears the selection)
    4 - Resizing selection: resizing once will paste the selection
                            loss of quality when resizing to original solved. However, it comes at the price of loosing mask information

IMPROVEMENT:
    1 - replace m_Image pointer by a direct object instance (simplify the code in several place)


Now I have solved all the (known) bugs, and I have implemented everything I wanted. Therefore I move the status to BETA.

What remains to do:
   1 - some documentation
   2 - some speed improvement on wxGTK

Let me know what you think !

Sebastien

[seb_seb0]

Hello,

I have updated the svn repository (revision 64).

IMPROVEMENT:
    1 - catch events when environment settings are updated (to update wxAUI colors)
    2 - added some tooltips and help text (only in code. Not displayed yet). Work is still in progress.
    3 - SVN repository cleanup (removed the compiled files XPMEditor.cbplugin, XPMEditor.dll, XMPEditor.zip, test.bmp)

QUESTION FOR THE CODE::BLOCKS TEAM:
I am using wxAUI in my plugin. Since there are some Code::Blocks settings for wxAUI (menu Settings / environment / Docking system), I think it is better if the plugin uses the same settings as the IDE.
There are, at my knowledge, no events indicating that settings have been updated.
The only way I have found to know when settings are updated is to use a hack. I am using this notification update in Codeblocks/src/main.cpp
      

Code

void MainFrame::OnSettingsEnvironment()
                {
                  ...
                  Manager::Get()->GetLogManager()->NotifyUpdate(); 
                }
       

I have therefore created a fake logger: it derives from the class

Code

Logger

, but if does not create a control. It implements the UpdateSettings virtual methods, but none others. The result is that it works as expected, and it does not add an additionnal Tab in the log window.
In short, it does what I want.

However, I keep thinking it is a hack. Is it possible to add a Code::Blocks event when some settings are updated ?

Sebastien

[seb_seb0]

Hello,

I have updated the SVN (revision 65)

CHANGES:

1- corrected a bug in wxDragImageExt: the transparent (masked) pixels of the image were drawn
2 - added tooltips to all controls. Currently adding context help strings (strings added in code, display needs to be done).

I continue working on help text. Then I will write a few html pages for online help. And then I will try to improve performances on wxGTK.

Sebastien

[MortenMacFly]

QUESTION FOR THE CODE::BLOCKS TEAM:
There are, at my knowledge, no events indicating that settings have been updated.

That is true. If this makes sense for plugin we can think of an event. Nevertheless, you can always query configmanager if this setting is persisted (which is normally in the case for settings). That might be another option.

Besides that if you come up with a patch that's surely worth a look into.

[seb_seb0]

QUESTION FOR THE CODE::BLOCKS TEAM:
There are, at my knowledge, no events indicating that settings have been updated.

That is true. If this makes sense for plugin we can think of an event. Nevertheless, you can always query configmanager if this setting is persisted (which is normally in the case for settings). That might be another option.

Besides that if you come up with a patch that's surely worth a look into.

OK, I will try to do a patch - I believe it is a good functionnality.
I could also follow your other suggestion and regularly check the configuration file. But it is a bit overkill for just setting wxAUI colour. Therefore I will go with the patch.

Sebastien

[MortenMacFly]

But it is a bit overkill for just setting wxAUI colour. Therefore I will go with the patch.

Why? That's how C::B stores / reads the settings. I mean you should do this only once on startup. That might be sufficient.

[seb_seb0]

But it is a bit overkill for just setting wxAUI colour. Therefore I will go with the patch.

Why? That's how C::B stores / reads the settings. I mean you should do this only once on startup. That might be sufficient.

Maybe you misunderstood me. When I create an editor, I read the configuration to get the wxAUI settings (colours & size). See in XPMEditorPanel::BuildContent this line (at line 168):

Code

UpdateAUIColours();

It will read the configuration, and set the Font, Metrics and Colours for wxAUI.

So on creation, the user settings are respected.
However, if an image editor is already opened, and if the settings are changed by the user, then the new settings are not respected in the already opened editors. This is the only reason why I want to catch this event.

Sebastien

[seb_seb0]

Hello,

SVN has been updated (66)

Main changes:

1 - add a patched xpm handler: the one from wxWidgets does not read the images when they have comments inside

2 - added HELP

3 - Size of Tool Panel fixed.

To do:
improve performance on wxGTK (working on it)
do the html doc

Sebastien

[seb_seb0]

I have noticed a crash on Linux (this is why the plugin is still in Beta stage).

I cannot find the reason of the crash. The following piece of code is sufficient to make code::blocks crash:

Code

void XPMEditor::OnAttach()
{
     if (m_Singleton == NULL)
    {
        const FilesGroupsAndMasks *fm = Manager::Get()->GetProjectManager()->GetFilesGroupsAndMasks();
        wxString sMask;
        if (fm) sMask = fm->GetFileMasks(0);

        m_Singleton = this;
    }
}

with the following call stack:

Code

<frame level="0" function="wxFatalSignalHandler" offset="00000026"/>
<frame level="1"/>
<frame level="2" function="wxBaseArrayPtrVoid::GetCount() const" offset="00000006"/>
<frame level="3" function="FilesGroupsAndMasks::GetFileMasks(unsigned int) const" offset="00000021"/>
<frame level="4" function="XPMEditor::OnAttach()" offset="000001d2"/>

And whaterver workaround I try, I always receive a crash with either wxBaseArrayPtrVoid::GetCount() or wxBaseArrayPtrVoid::Add()

This crash does not occur on Windows, only on Linux. It is totally impossible to understand for me.
So since this feature is not critical (addition of a virtual folder in the project manager for images), I will simply skip this step for Linux.
But I would like to understand.
Does anybody have an idea on what is going on ?

Sebastien

[Jenna]

It works fine here, after some changes to the project-file to make it buildable from inside svn-tree and to use the same configurationa s the (most) contrib-plugins.

The second part of the project-file patch is most likely because of different line-endings.
In XPMEditor.cpp I just added your three lines and removed one unneeded space in a menu-entry.

[Jenna]

But I sometimes get a crash, if I close the editor-tab, it does not happen reliable.

I will see if I find a cause or a regularity, but at the moment it seems more or less random.

[seb_seb0]

But I sometimes get a crash, if I close the editor-tab, it does not happen reliable.

I will see if I find a cause or a regularity, but at the moment it seems more or less random.

Thanks for the patch, I will have a try.
For the irregular crash, I have noticed it also - I will track it once I have solved the other problem.

Sebastien

[seb_seb0]

The patch provoked a mistake in my build => Codeblocks was complaining of not being able to find "XPMEditor.zip" (I checked it was there).

EDIT: I have found the reason of the problem : a directory "home/.codeblocks" has been created, and the lib from the "cbplugin" file was copied there. Apparently it posed some problems since I used a self compiled version from Codeblocks on Linux (latest SVN now) to avoid SDK mismatch. Removing this directory seems to solve the problem for now. The plugin could not be loaded, and all other plugins as well... Is it a new feature on Linux ? Or was this directory already present in the past ?

So what I will do:
  - rebuild codeblocks on Linux (it is probable I have broken something, because compiler plugin disappeared also. Better to have a fresh start)
  - I will create a minimal plugin with the wizard in Linux - and probably try if the strange bug still happens.
  - I will migrate the XPMEditor plugin to Linux again

For wxGTK performance, I have found the bottleneck: the scaling of a bitmap takes a LOT of time - and it was done in the Paint handler...
So I have found a workaround, but it involves some rewriting of the paint methods.
It is not that much work.
Since I am there, I will add an option (compile time or runtime) to use 1 of the 2 behaviours
   - scaling during the paint handler : fast on Windows, takes less memory
   - scaling outside the paint event, meaning keeping a big bitmap around => takes more memory, but faster on Linux (I made a test: a bitmap 500 x 250 scaled to 1600% will increase memory consuption by 100 Mb).

Please be patient !

Sebastien

[Jenna]

 :oops: Forgot to write:
you need to put your sources into src/plugins/contrib with my patch and remove anything related to the plugin from ~/.codeblocks/share/codeblocks and ~/.codeblocks/share/codeblocks/plugins,  because the plugin will be placed in the output tree (below src/devel and src/output after running the update-script).

[seb_seb0]

OK, I managed to get the plugin to be installed, but I still have the crash.
Maybe it is something specific to my installation - I will continue to investigate...