Plugin development : markers in custom plugin (C++, Qt)

Comments

• Matthias

  September 17

  Hi Alessio,

  do you have some code you can share?

  Right now, markers do not survive a change of the files inside the view. Markers are not intended as persisting objects, but rather short-lived annotations - such as error markers.

  Maybe you can register your plugin to listen to events on the view and regenerate the markers after such a change, or you use a QTimer to regularly check if the marker is still alive. But I have not tried one of these options myself.

  I guess it's possible to change the KLayout code to have markers survive a file operation. But that's worth a ticket on GitHub.

  Regards,

  Matthias
• alecacciatori

  September 18

  Hi Matthias,

  Thanks for the prompt follow up.

  The issue is that, even if we create a new marker (after the layout has been loaded), it's not visible.

  Here follows the relevant code:
  1. at beginning (empty layout) and
  2. after layout load we switch to our plugin which is created from its factory with top (0) priority

  if (my_mode_id >=0)
          m_layoutView->switch_mode(my_mode_id);
  
   lay::Plugin* active = m_layoutView->active_plugin();
   m_layoutView->show_markers(true);
  

  Then here the handler of mouse event (overriding edt::Service)

  bool    myCustomPlugin::mouse_move_event(const db::DPoint &p, unsigned int buttons, bool )
  {
    // Check if left button is kept down
    if ((buttons & lay::LeftButton))
    {
      if (!m_dragging)
      {
        m_dragging   = true;
        m_drag_start = m_last_snapped;
      }
      m_drag_box = db::DBox(m_drag_start, m_last_snapped);
    }
  
    update_cursor_markers();
  
    emit  signal_mouse_position(m_last_snapped);
  
    return false;
  }
  

  Procedure to update mouse cursor and (hopefully) marker:

  /**
   * @brief myCustomPlugin::update_cursor_markers
   */
  void  myCustomPlugin::update_cursor_markers()
  {
    clear_mouse_cursors();
  
    add_mouse_cursor(m_last_snapped, false);
  
    update_marker();
  
  }
  

  Procedure to update the marker

      /**
       * @brief myCustomPlugin::update_marker
       */
      void  myCustomPlugin::update_marker()
      {
        if (!m_dragging) return;
  
        if (m_marker==nullptr)
          create_marker();
  
        if (m_marker!=nullptr)
        {
          m_marker->set(m_drag_box,db::DCplxTrans());
          m_marker->visible(true);
        }
        mp_view->show_markers(true);
      }
  

  This is called each time mouse is pressed

  /**
   * @brief myCustomPlugin::create_marker
   */
  void        myCustomPlugin::create_marker()
  {
  
    if (m_marker!=nullptr) return;
    if (mp_view==nullptr) return;
  
    m_marker = new lay::Marker(mp_view, mp_view->active_cellview_index());
  
    unsigned int fillColor  = 0x00cc00;
    unsigned int frameColor = 0x00cc00;
    int dither    = 0;          // solid
    int lineStyle = 3;
    int width     = 1;
  
    m_marker->set_color (brighter_color(fillColor));
    m_marker->set_frame_color(brighter_color(frameColor));
    m_marker->set_dither_pattern(dither);         
    m_marker->set_line_style(lineStyle);
    m_marker->set_line_width(width);           
    m_marker->set_vertex_size(1);
    m_marker->set_halo(1);
  }
  

  This is called each time mouse is release (delete the marker)

      /**
       * @brief myCustomPlugin::delete_marker
       */
      void        myCustomPlugin::delete_marker()
      {
  
        if (m_marker==nullptr) return;
        delete m_marker;
        v = nullptr;
  
      }
  

  At mouse release we cancel the marker

  bool        myCustomPlugin::mouse_release_event(const db::DPoint &p, unsigned int buttons, bool /*prio*/)
  {
      if (!m_dragging)
        return false;
  
      m_dragging = false;
  
      db::DBox box(m_drag_start, p);
  
      delete_marker();
  
      update_cursor_markers();
  
      return true;
  }
  

  So, as you can see, the code is (or should be) pretty straightforward. This means that we are doing something wrong but we really cannot figure out what.

  Thank you very much!

  Alessio
• alecacciatori

  September 21 edited September 21

  Hi Matthias,

  I have found something that I don't understand. If I create the marker with

  lay::Marker(mp_view, mp_view->active_cellview_index(), true)
  

  It behaves in the "wrong" way (e.g. I am not able to add custom markers after a file is loaded, as described above).

  But, if I use the following construction

  lay::Marker(my_view,1, true)
  

  (e.g. forcing the cellview_index to 1 in the marker creator)

  everything works fine.

  Do you see any drawback in the second approach?

  Thank you for your precious time.

  Best

  Alessio
• Matthias

  September 21

  Hi Alessio,

  I'm sorry, but I can't support you this way. I need the full code and I need to be able to reproduce the problem in order to debug it. Just some code snippets aren't enough.

  I also see you're writing C++ plugins - this is also something I don't support. Please use Python or Ruby - this is the only API that is supported and stable. There is very little documentation apart from the code. I take the freedom to change the C++ API without notice and there is no warranty about compatibility or functionality. Please also be aware of the license implications: there is no license exception for C++ plugins. Your C++ plugin needs to be published under the GPL conditions.

  I sense that technically the problem in your case is transfer of the ownership of the marker to the view, but it's hard to investigate without a running system. I guess the object is lost when you load a file due to filetime ties with the layout object. It is very easy to introduce memory corruption problems in C++, specifically if ownership is not handled carefully. Objects may seem to be functional, but in reality they are already dead. Setting the cellview to 1 may change the way the marker object's lifetimes are tied to the layout objects, but again, it is very difficult to guess what is happening with a partial code base and don't assume the C++ API is very consistent.

  Matthias
• alecacciatori

  September 22

  I understand that C++ API is not supported.
  Anyway, thank you for the follow up and, yes, we are aware of the GPL obligations.