inkboard abandoned files? cleanup needed.
I commited small patch in order to be able to compile using the "./configure --enable-inkboard" option: rev 20788
It looks that the files that I commented out have no effect in the code and are not in use. Could one please investigate in this?
Using this patch inkscape opens the connect dialog. I can not prove that it works because I do not know how to connect.
Thx, Adib. ---
file: src/ui/dialog/Makefile_insert
adib@...2145...:~/Projekte/Inkscape/inkscape_dev/src/ui/dialog$ svn diff Index: Makefile_insert =================================================================== --- Makefile_insert (Revision 20786) +++ Makefile_insert (Arbeitskopie) @@ -1,13 +1,13 @@ ## Makefile.am fragment sourced by src/Makefile.am.
if WITH_INKBOARD -inkboard_dialogs = \ - ui/dialog/whiteboard-connect.cpp \ - ui/dialog/whiteboard-connect.h \ - ui/dialog/whiteboard-sharewithchat.cpp \ - ui/dialog/whiteboard-sharewithchat.h \ - ui/dialog/whiteboard-sharewithuser.cpp \ - ui/dialog/whiteboard-sharewithuser.h +## inkboard_dialogs = \ +## ui/dialog/whiteboard-connect.cpp \ +## ui/dialog/whiteboard-connect.h \ +## ui/dialog/whiteboard-sharewithchat.cpp \ +## ui/dialog/whiteboard-sharewithchat.h \ +## ui/dialog/whiteboard-sharewithuser.cpp \ +## ui/dialog/whiteboard-sharewithuser.h endif
ink_common_sources += \
the Adib wrote:
I commited small patch in order to be able to compile using the "./configure --enable-inkboard" option: rev 20788
It looks that the files that I commented out have no effect in the code and are not in use. Could one please investigate in this?
You just removed the Inkboard dialogs, making it impossible to actually use Inkboard. However, Inkboard dialogs don't have verbs defined, so they wouldn't be accessible anyway.
I have a solution that would allow us to get rid of the centralized verbs.h file and of header files for dialogs along with some proof-of-concept code, but for now I have to fix the icon related issues.
Regards, Krzysztof Kosiński
On Feb 27, 2009, at 8:20 AM, Krzysztof Kosiński wrote:
I have a solution that would allow us to get rid of the centralized verbs.h file and of header files for dialogs along with some proof-of- concept code, but for now I have to fix the icon related issues.
FYI, this aspect has been looked into, and the consensus was to switch from C constants to strings. We can leverage the GQuark where appropriate.
Most important, however, is the naming scheme to use. We need to be consistent, and to allow for namespaced values. This will provide needed hooks for extensions and plugins. It will especially make it easy to move more core functionality into plugins, as per some original design goals.
Consider extensions accessing internals via a live DOM object. Scheme, ECMAScript, Java, Python, Perl, etc. Names really help there.
Jon A. Cruz wrote:
FYI, this aspect has been looked into, and the consensus was to switch from C constants to strings. We can leverage the GQuark where appropriate.
What we use for unique IDs isn't that important. I was talking about something more fundamental. Currently everything has to be explicitly called from main() or its descendant function at some point. This means that even if you define verbs in different files you still have to have headers for them to be able to call their init functions or construct them. This means we have some files that just list everything that has to be initialized (e.g. extension/init.cpp).
My solution involves creating a class for each verb/action (derived from Gtk::Action) and adding a statically initialized "entry object" that, upon construction, will put the action's static constructor (e.g. a static function that returns a new action) on the list of actions to initialize. This would automagically build lists of global actions and per-document actions to create.
A similar approach could be used for tools, path effects, toolbars, internal extensions, dialogs, etc., effectively turning Inkscape into a collection of statically linked plugins. I posted about this a while ago but there was no reply.
What do you think about this general idea (let's call it "Static Plugin Pattern")?
Regards, Krzysztof Kosiński
On Feb 27, 2009, at 10:09 AM, Krzysztof Kosiński wrote:
My solution involves creating a class for each verb/action (derived from Gtk::Action) and adding a statically initialized "entry object" that, upon construction, will put the action's static constructor (e.g. a static function that returns a new action) on the list of actions to initialize. This would automagically build lists of global actions and per- document actions to create.
In general that sounds good, however they should not derive from Gtk::Action.
For most, a specific subclass that provides Gtk::Action would be good, but basing on Gtk::Action directly will cause MI problems among other things.
Jon A. Cruz wrote:
In general that sounds good, however they should not derive from Gtk::Action. For most, a specific subclass that provides Gtk::Action would be good, but basing on Gtk::Action directly will cause MI problems among other things.
I'm not exactly sure what problems would multiple inheritance used with Gtk::Action cause. It shouldn't cause any as long all classes inherit from only one GObject-based class. In fact multiple inheritance is used in glibmm itself (look at e.g. Gtk::RecentAction).
Regards, Krzysztof Kosiński
On Sat, 2009-02-28 at 17:39 -0800, Krzysztof Kosiński wrote:
Jon A. Cruz wrote:
In general that sounds good, however they should not derive from Gtk::Action. For most, a specific subclass that provides Gtk::Action would be good, but basing on Gtk::Action directly will cause MI problems among other things.
I'm not exactly sure what problems would multiple inheritance used with Gtk::Action cause. It shouldn't cause any as long all classes inherit from only one GObject-based class. In fact multiple inheritance is used in glibmm itself (look at e.g. Gtk::RecentAction).
Oh, yes. I'm very familiar with multiple inheritance.
However... most guru's who really know MI tend to avoid MI.
Java had a much better approach with its Interfaces. More modern C++ usage of MI are abstract base classes used in place of Java Interfaces.
Also... a much better C++ approach is to avoid GObject-based classes overall. That gives better reuse and more functionality.
Jon A. Cruz wrote:
Java had a much better approach with its Interfaces. More modern C++ usage of MI are abstract base classes used in place of Java Interfaces.
OK, now we're getting into religious issues :) I have seen several problems that can be solved cleanly with MI but become very ugly with single inheritance. For example it allows you to implement mixins. The argument against it seems to be similar to operator overloading, e.g. we shouldn't use it because many people don't use it correctly, and sometimes we might stumble upon classes two classes we want to inherit from that define a method with the same name. The first just doesn't convince me because it's like banning knives because somebody might get hurt. The second isn't convincing either because at least in C++ there are trival workarounds. Anyway, this issue is tangential to my original point.
Also... a much better C++ approach is to avoid GObject-based classes overall. That gives better reuse and more functionality.
I didn't mean GObject based classes as in SPObject. I meant that e.g. you can't simultaneously derive from two gtkmm classes like Gtk::Action and Gtk::MenuItem, because GType doesn't support multiple inheritance. However, you can still derive from one gtkmm class and any number of non-gtkmm classes without any problems, because GType only cares about the gtkmm class. It's even used in gtkmm itself.
Regards, Krzysztof Kosiński
On Fri, 2009-02-27 at 10:09 -0800, Krzysztof Kosiński wrote:
A similar approach could be used for tools, path effects, toolbars, internal extensions, dialogs, etc., effectively turning Inkscape into a collection of statically linked plugins. I posted about this a while ago but there was no reply.
I think statically linked is not that good. The original intent was for things to be dynamically linked. Ted has done a lot on this front. But again, one key design goal from the beginning was to get to the point where the bulk of the functionality was in plugins/extensions.
What do you think about this general idea (let's call it "Static Plugin Pattern")?
Personally I'd avoid the term "pattern" unless it was actually a generally recognized design pattern. Since in software engineering "pattern" has a very specific and agreed upon meaning.
Jon A. Cruz wrote:
I think statically linked is not that good. The original intent was for things to be dynamically linked. Ted has done a lot on this front. But again, one key design goal from the beginning was to get to the point where the bulk of the functionality was in plugins/extensions.
The same principle can be used with dynamically linked libraries, as long as GCC takes care of static initialization in C++ DLLs. I think it does, like all other compilers. What's important is that once "static plugins" are implemented, converting from statically linked object files to dynamic libraries will be as easy as altering the Makefile. It could even be configurable at build time.
Personally I'd avoid the term "pattern" unless it was actually a generally recognized design pattern. Since in software engineering "pattern" has a very specific and agreed upon meaning.
That's why I put it in quotes :)
Regards, Krzysztof Kosiński
On Sat, 2009-02-28 at 16:21 -0800, Krzysztof Kosiński wrote:
What's important is that once "static plugins" are implemented, converting from statically linked object files to dynamic libraries will be as easy as altering the Makefile. It could even be configurable at build time.
However... that's still static.
What Ted has worked out and is improving on is dynamic. It does the equivalent, but with no need of linking in. At *runtime* things are discovered and loaded... even ones done in languages that are not C++.
Jon A. Cruz wrote:
What Ted has worked out and is improving on is dynamic. It does the equivalent, but with no need of linking in. At *runtime* things are discovered and loaded... even ones done in languages that are not C++.
The difference is that the current implementation of extensions has to go through an API layer which explicitly defines the extension points, and cannot directly call functions in Inkscape. Moreover my proposition doesn't intend to replace the existing extension framework; it's just a way to better organize our internal code.
Regards, Krzysztof Kosiński
On Sat, 2009-02-28 at 17:22 -0800, Krzysztof Kosiński wrote:
The difference is that the current implementation of extensions has to go through an API layer which explicitly defines the extension points, and cannot directly call functions in Inkscape. Moreover my proposition doesn't intend to replace the existing extension framework; it's just a way to better organize our internal code.
Ah, yes. But that is exactly the point.
The key is that we have that layer that is *intended* to allow things to call functions in Inkscape. The internal code needs to be migrated to that, not a new dead-end API.
Yes, the internal code needs to be reorganized. However it should just be done once, and to the final API, not twice.
Again, the extension API was designed from the beginning to allow for the internal code to migrated to it. Just reorg once, and we'll be good.
Hello!
I don't want to interfere with developers' talk and this is not the goal of this message :-)
I just wanted to inform the interested persons on the list that in the last available win32 build ( http://inkscape.modevia.com/win32/Inkscape20711-0902171746.7z ) , the inkboard, although missing any icon, does connect. cleary from the irc channel and I tested it, it was fun! :-)
You can't register with it on gristle.org (at least it didn't work for me and cleary), but you can connect to the server (gristle.org) and then use "Group chat" to enter the room with the bridge (inkscape on conference.gristle.org).
Attempts to share crash Inkscape always if the other person isn't on your roaster, and do not crash it if the person is on it. But you don't share a drawing, you just see a white new document titled "Inkboard...".
All in all, it is good news - I remember crashes happened much more on the 0.46 whiteboard! :-)
Thank you all for the great work!
--- On Fri, 2/27/09, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
From: Krzysztof Kosiński <tweenk.pl@...400...> Subject: Re: [Inkscape-devel] inkboard abandoned files? cleanup needed. To: inkscape-devel@lists.sourceforge.net Date: Friday, February 27, 2009, 11:20 AM the Adib wrote:
I commited small patch in order to be able to compile
using the
"./configure --enable-inkboard" option: rev
20788
It looks that the files that I commented out have no
effect in the
code and are not in use. Could one please investigate in this?
You just removed the Inkboard dialogs, making it impossible to actually use Inkboard. However, Inkboard dialogs don't have verbs defined, so they wouldn't be accessible anyway.
I have a solution that would allow us to get rid of the centralized verbs.h file and of header files for dialogs along with some proof-of-concept code, but for now I have to fix the icon related issues.
Regards, Krzysztof Kosiński
View this message in context: http://www.nabble.com/inkboard-abandoned-files--cleanup-needed.-tp22235902p2... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
Jon A. Cruz -
Krzysztof Kosiński -
the Adib -
worms invasion