Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G
gtkmm
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 26
    • Issues 26
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 3
    • Merge Requests 3
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • gtkmm
  • Issues
  • #49

Closed
Open
Opened Jun 23, 2019 by Daniel Boles@dbolesDeveloper

Make `Gtk::Widget::draw(Cairo::RefPtr<CairoContext> const&)` public

moving here from the mailing list

It would also be worth checking whether the same thing can be done in master already, although I haven't yet.

Daniel Boles

I have a small widget that can be a drag/drop source/sink. When it's dragged, I want it to be the drag-icon, so you can see that you're dragging that particular widget (and its particular label, etc.)

However, Gtk::Widget::draw(Cairo::RefPtr<Cairo::Context> const&) is protected in gtkmm, so it seems that in order to draw the widget onto a surface that I can then set as drag-icon, I must do:

auto const allocation = m_box_label.get_allocation();
auto const surface = Cairo::ImageSurface::create(
  Cairo::FORMAT_ARGB32, allocation.get_width(), allocation.get_height() );
auto const cairoContext = Cairo::Context::create(surface);
gtk_widget_draw( reinterpret_cast<GtkWidget*>( m_box_label.gobj() ), cairoContext->cobj() );
dragContext->set_icon(surface);

Is there any better way that I didn't think of, any way to make this nicer in gtkmm, or is it just a fact of life at this point? (Since gtkmm-3 is stable and master is probably very different here.)


Kjell Ahlstedt

I don't know why Widget::draw() is protected. Perhaps someone misunderstood it, and thought that it draws from the cairo context to the widget, instead of the other way.

gtk_widget_draw() and Gtk::Widget::draw() don't exist in gtk4/gtkmm4.

An alternative, not necessarily better, but without C code:

class MyBoxLabel : public TheTypeOf_m_box_label
{
public:
  using TheTypeOf_m_box_label::TheTypeOf_m_box_label // same constructors as the base class
  void draw(const ::Cairo::RefPtr< ::Cairo::Context>& cr)
  {
    Gtk::Widget::draw(cr);
  }
};

This might work, but I'm not sure:

class MyBoxLabel : public TheTypeOf_m_box_label
{
public:
  using TheTypeOf_m_box_label::TheTypeOf_m_box_label // same constructors as the base class
  using Gtk::Widget::draw;
};

Daniel Boles

I don't know why Widget::draw() is protected. Perhaps someone misunderstood it, and thought that it draws from the cairo context to the widget, instead of the other way.

Yeah, it doesn't seem like it's 'protecting' anything by not being usable publicly. Can the access specifier perhaps be changed in a future stable release, or is that too much?

gtk_widget_draw() and Gtk::Widget::draw() don't exist in gtk4/gtkmm4.

Yeah, it's all snapshots and whatnot now. I haven't looked into that stuff much. I wonder if the equivalent pattern is already possible against GTK master without problems.

An alternative, not necessarily better, but without C code:

Right, good point. Personally I'm not using inheritance in this case and would prefer not to, but that could work fine for other users who might have the same question later. Thanks!


Kjell Ahlstedt

I suppose the access specifier can be changed from protected to public in gtkmm 3.26. That would not break anything, just add API. Access specifiers don't affect mangled method names, as far as I know. I see no reason why they should.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/gtkmm#49