Hi All,
I'm just beginning to look at a strategy for implementing the fillet mini-tool. From my current understanding it would best to implement the tool with a tool context similar to all the other tools.
Now looking at the code for the tools, they're currently all implemented in C with C pseudo-classes. I'm wondering is there any plan to transition these tools over to C++ to use true classes? and if so, if I'm creating a new pseudo-tool, would it be best to take a C++ approach, or to keep consistency with the C stuff until someone transitions all the tools over?
Any thoughts Joel
On Mon, 11 Feb 2008 23:41:06 +0000, Joel Holdsworth <joel@...1709...> wrote:
Now looking at the code for the tools, they're currently all implemented in C with C pseudo-classes. I'm wondering is there any plan to transition these tools over to C++ to use true classes?
Yes.
and if so, if I'm creating a new pseudo-tool, would it be best to take a C++ approach, or to keep consistency with the C stuff until someone transitions all the tools over?
As long as you aren't duplicating any existing code, the C++ approach is probably fine. Remember to put any new C++ classes in the Inkscape:: namespace, and be sure that you understand that constructors/destructors of members of C-style "classes" must be called manually, as they will not be called automatically.
-mental
On Mon, Feb 11, 2008 at 03:49:40PM -0800, MenTaLguY wrote:
On Mon, 11 Feb 2008 23:41:06 +0000, Joel Holdsworth <joel@...1709...> wrote:
Now looking at the code for the tools, they're currently all implemented in C with C pseudo-classes. I'm wondering is there any plan to transition these tools over to C++ to use true classes?
Yes.
and if so, if I'm creating a new pseudo-tool, would it be best to take a C++ approach, or to keep consistency with the C stuff until someone transitions all the tools over?
As long as you aren't duplicating any existing code, the C++ approach is probably fine. Remember to put any new C++ classes in the Inkscape:: namespace, and be sure that you understand that constructors/destructors of members of C-style "classes" must be called manually, as they will not be called automatically.
If we do proceed with this, please move the new C++-ified tools into a subdir, not directly in src/ as that's too crowded presently.
Bryce
On Mon, Feb 11, 2008 at 04:10:33PM -0800, MenTaLguY wrote:
On Mon, 11 Feb 2008 16:04:27 -0800, Bryce Harrington <bryce@...961...> wrote:
If we do proceed with this, please move the new C++-ified tools into a subdir, not directly in src/ as that's too crowded presently.
src/tools ?
-mental
Works for me.
Bryce
That all sounds sensible.
Thanks!
On Mon, 2008-02-11 at 15:49 -0800, MenTaLguY wrote:
On Mon, 11 Feb 2008 23:41:06 +0000, Joel Holdsworth <joel@...1709...> wrote:
Now looking at the code for the tools, they're currently all implemented in C with C pseudo-classes. I'm wondering is there any plan to transition these tools over to C++ to use true classes?
Yes.
and if so, if I'm creating a new pseudo-tool, would it be best to take a C++ approach, or to keep consistency with the C stuff until someone transitions all the tools over?
As long as you aren't duplicating any existing code, the C++ approach is probably fine. Remember to put any new C++ classes in the Inkscape:: namespace, and be sure that you understand that constructors/destructors of members of C-style "classes" must be called manually, as they will not be called automatically.
-mental
On Mon, Feb 11, 2008 at 11:41:06PM +0000, Joel Holdsworth wrote:
Hi All,
I'm just beginning to look at a strategy for implementing the fillet mini-tool. From my current understanding it would best to implement the tool with a tool context similar to all the other tools.
Now looking at the code for the tools, they're currently all implemented in C with C pseudo-classes. I'm wondering is there any plan to transition these tools over to C++ to use true classes? and if so, if I'm creating a new pseudo-tool, would it be best to take a C++ approach, or to keep consistency with the C stuff until someone transitions all the tools over?
We've talked about it, but there's no near-term plans for doing that. For now, try to keep consistent with the C stuff.
(It would probably be most sensible to get the Gtk->Gtkmm dialog conversion stuff completed before we tackle another big C++ification project.)
Bryce
participants (4)
-
Alexandre Prokoudine -
Bryce Harrington -
Joel Holdsworth -
MenTaLguY