Okay, whoever decided to derive a view class from Gtk::Window ... that was NOT a good idea.
I'm open to suggestions how to split Gtk::Window away from it quickly, because among other things that is preventing us from migrating the UI::View::View hierarchy to the collector.
The build is broken until this gets fixed...
-mental
mental:
Okay, whoever decided to derive a view class from Gtk::Window ... that was NOT a good idea.
I do not understand. How would this class "derive" from Gtk::Window?
class View { public:
View(); virtual ~View();
The build is broken until this gets fixed...
Why fix it if you got the fact wrong?
Is this a joke or way too much over my head?
ralf
On Sep 28, 2005, at 12:44 AM, Ralf Stephan wrote:
mental:
Okay, whoever decided to derive a view class from Gtk::Window ... that was NOT a good idea.
I do not understand. How would this class "derive" from Gtk::Window?
class View { public:
View(); virtual ~View();
I think Mental meant Edit over in src/ui/view/edit.h
... namespace UI { namespace View {
class Edit : public Gtk::Window, View { ...
So you can see that Inkscape::UI::View::Edit is "a view class" (derives from Inkscape::UI::View::View) and at the same time also derives from Gtk::Window. I think the key word in there is "a" (easy to miss).
On Wed, Sep 28, 2005 at 09:44:01AM +0200, Ralf Stephan wrote:
mental:
Okay, whoever decided to derive a view class from Gtk::Window ... that was NOT a good idea.
I do not understand. How would this class "derive" from Gtk::Window?
class View { public:
View(); virtual ~View();
It took a bit of research to figure out what he was talking about. It turns out he was looking at an unused piece of code - the old Edit class. Prior to the SPDesktop refactoring work that you took over, we'd attempted a wholesale replacement of SPDesktop with the Edit class, however it proved difficult to integrate it due to its dependency on View, thus the change of strategy using the SPDesktop refactoring approach.
If there is anything useful to you in the Edit class, go ahead and copy it, otherwise delete it and replace it with your own SPDesktop refactoring work.
The build is broken until this gets fixed...
Why fix it if you got the fact wrong?
Is this a joke or way too much over my head?
I was wondering this as well.
Bryce
ah sorry you meant the view class UI::View::Edit, that is Bryce's baby, and I already hinted that it should have been named EditWidget in the "pattern" thread. It and Application::Editor is hooked in since the option --new-gui exists.
ralf
Quoting Ralf Stephan <ralf@...748...>:
mental:
Okay, whoever decided to derive a view class from Gtk::Window
... that
was NOT a good idea.
I do not understand. How would this class "derive" from Gtk::Window?
It was UI::View::Edit which derived from Gtk::Window and caused the problem -- it's a subclass of UI::View::View. Not your fault. I should have been more specific.
-mental
participants (5)
-
unknown＠example.com -
Bryce Harrington -
Jon A. Cruz -
MenTaLguY -
Ralf Stephan