Somehow in all our discussions about refactoring, few if any mentions were made of the long-standing code duplication: the "new GUI" switch and the fact that src/widgets/desktop-widget has been duplicated in ui/view/edit-widget. This second copy lingers there for at least two years, unused, with little progress. Do we still need it? As I vaguely remember, at least one of the reasons for starting it was to get collapsable toolbars, but we have them now working fine with the old UI. Will anyone object if I remove ui/view/edit-widget and related unused code post-0.47?
2009/10/25 bulia byak <buliabyak@...400...>:
Somehow in all our discussions about refactoring, few if any mentions were made of the long-standing code duplication: the "new GUI" switch and the fact that src/widgets/desktop-widget has been duplicated in ui/view/edit-widget. This second copy lingers there for at least two years, unused, with little progress. Do we still need it?
I investigated this some time ago. Most (if not all) of this code is never called and dead. It will crash when run. I think that effort was really strange. It attempted to have a refactored version of code while keeping around the non-refactored version and allow to switch between them at runtime. It looks like somebody wanted to avoid creating an SVN branch at all costs.
As I vaguely remember, at least one of the reasons for starting it was to get collapsable toolbars, but we have them now working fine with the old UI. Will anyone object if I remove ui/view/edit-widget and related unused code post-0.47?
It is the logical way forward. It will be simpler to start from scratch than to repurpose that code for anything. I'm also not convinced about the additional level of abstraction above SPDesktop (Inkscape::UI::View::View, etc.). Ignoring the namespace proliferation issue for a moment, is having a static SVG view control really worth adding this abstraction? Is there enough functionality in common between a static view and a desktop to justify a common base class? I remember that the static view is used in Inkview (which, by the way, only barely useful) and on the About screen, which makes my teeth cringe when I need to wait 3 minutes for the artwork to render just to see the version number. It would be more user- and developer-friendly to prerender the artwork at build time instead (using Inkscape, of course).
Regards, Krzysztof
2009/10/25 Krzysztof Kosiński <tweenk.pl@...400...>:
only barely useful) and on the About screen, which makes my teeth cringe when I need to wait 3 minutes for the artwork to render just to see the version number. It would be more user- and developer-friendly to prerender the artwork at build time instead (using Inkscape, of course).
I disagree. Prerendering wouldn't be a honest tactic :) We must focus on our real rendering speed instead, not erect false walls. Also, I (and perhaps others) routinely use the About screen as a sort of quick and imprecise benchmark to get an idea of how fast a new computer is.
If you want to find out the version/build quickly, just run inkscape --version.
On Sun, Oct 25, 2009 at 05:01:50PM +0100, Krzysztof Kosi??ski wrote:
2009/10/25 bulia byak <buliabyak@...400...>: I investigated this some time ago. Most (if not all) of this code is never called and dead. It will crash when run. I think that effort was really strange. It attempted to have a refactored version of code while keeping around the non-refactored version and allow to switch between them at runtime. It looks like somebody wanted to avoid creating an SVN branch at all costs.
No, somebody had originally done this stuff in an SVN branch but was told SVN branches were bad because it made the code harder for other people to work on, and that the code should be integrated into the main codebase.
As I vaguely remember, at least one of the reasons for starting it was to get collapsable toolbars
That is incorrect. The reason was to convert the desktop code into C++/Gtkmm.
Bryce
Quoting bulia byak <buliabyak@...400...>:
Somehow in all our discussions about refactoring, few if any mentions were made of the long-standing code duplication: the "new GUI" switch and the fact that src/widgets/desktop-widget has been duplicated in ui/view/edit-widget. This second copy lingers there for at least two years, unused, with little progress. Do we still need it? As I vaguely remember, at least one of the reasons for starting it was to get collapsable toolbars, but we have them now working fine with the old UI. Will anyone object if I remove ui/view/edit-widget and related unused code post-0.47?
I have to wait until I'm back on a computer to check for sure, but the main reason I recall for the "new GUI" was the "gtkmmification" of the codebase.
I'll need to look over things with an eye for removall also since post-0.47 I was needing to replace the backing code of the icon preview to one of those subclasses.
participants (4)
-
unknown＠example.com -
Bryce Harrington -
bulia byak -
Krzysztof Kosiński