I'm contemplating a reimplementation of OSX menu integration using external tools that rely on Gtk::UIManager and GtkAction. This seems orthogonal to the current Verbs+SPAction custom framework used by Inkscape. I would like to start with a simple question: What is the benefit of Verbs versus GtkAction? In the Wiki there is this idea of being able to attach a Verb to a View. -Julien/Gellule
On Jul 1, 2011, at 12:39 AM, Gellule Xg wrote:
I'm contemplating a reimplementation of OSX menu integration using external tools that rely on Gtk::UIManager and GtkAction. This seems orthogonal to the current Verbs+SPAction custom framework used by Inkscape. I would like to start with a simple question: What is the benefit of Verbs versus GtkAction? In the Wiki there is this idea of being able to attach a Verb to a View.
Well, the first issue was that verbs predate GtkAction. So we had started before any other solution was in GTK itself.
However, there are a few things that the verbs do that GtkAction does not. Conceptually it is slightly higher level. Also being able to be associated with more than a single view can be helpful. Consider the case where you have a single document, but multiple windows open editing that at the same time.
I'll try to dig up more details for you. It's been a while since I looked into it. But I can say that the last time I reviewed things, my desire was to get rid of things in favor of GtkAction, but it did not give us the same benefit.
A different issue you should look into is exactly *which* GtkActions are allowed. Some systems only support stock GtkAction classes that come with Gtk, whereas Inkscape has several custom GtkAction subclasses.
Oh, and we need to try to avoid exposing Gtk::UIManager's XML, as it is a very bad structure. You can see elsewhere in our code that we use it but keep it hidden from the users so that something better can be exposed and committed to.
2011/7/1 Jon Cruz <jon@...18...>:
However, there are a few things that the verbs do that GtkAction does not. Conceptually it is slightly higher level. Also being able to be associated with more than a single view can be helpful. Consider the case where you have a single document, but multiple windows open editing that at the same time.
GTK docs say in this case you should create a separate set of GtkActions for each window.
A different issue you should look into is exactly *which* GtkActions are allowed. Some systems only support stock GtkAction classes that come with Gtk, whereas Inkscape has several custom GtkAction subclasses.
Which "some systems"? If you can compile a GTK application, you can also write custom subclasses of GtkAction, for example EgeAdjustmentAction could be rewritten as a subclass of GtkAction. The only caveat is that gtkmm might not expose 100% of functionality available through the C API.
Regards, Krzysztof
On Jul 3, 2011, at 12:37 PM, Krzysztof Kosiński wrote:
2011/7/1 Jon Cruz <jon@...18...>:
However, there are a few things that the verbs do that GtkAction does not. Conceptually it is slightly higher level. Also being able to be associated with more than a single view can be helpful. Consider the case where you have a single document, but multiple windows open editing that at the same time.
GTK docs say in this case you should create a separate set of GtkActions for each window.
Yes, exactly. So that is at a *lower* level of the physical UI widgets of a single window. Verbs operate at the higher level of potential operations on a document.
So if a verb for a specific document is disabled, then multiple actions in multiple windows can automatically cascade to be disabled, etc.
If an author is writing some code to operate on a document, then having to stop and think about chasing down multiple UI widgets and owning instances gets bad. It also breaks modularity and encapsulation.
One key point here is that verbs are abstract and operating at the document level. They do not directly deal with any UI issues (aside from the two methods get_action() and delete_view() which need to be refactored to live elsewhere). Contrast that with a GtkAction object which is completely about UI issues, including being able to create and maintain other GtkWidgets on demand for various UI scenarios. So a GtkAction ties up some abstract functionality along with a lot of UI specifics. This is similar to Java's Action interface or Qt's QAction class, but with the addition of GtkAction also having the methods to act as a factory where Qt and Java left that pattern separated.
*Also* using separate GtkActions for each window is essentially what we have going in our code now. There are per-window GtkActions in use, and then we also have the legacy per-View SPAction that is more a one-to-one correlation to GtkAction. SPAction is the main class that is a candidate for folding into replacement with GtkAction, while Verb is still conceptually different..
A different issue you should look into is exactly *which* GtkActions are allowed. Some systems only support stock GtkAction classes that come with Gtk, whereas Inkscape has several custom GtkAction subclasses.
Which "some systems"? If you can compile a GTK application, you can also write custom subclasses of GtkAction, for example EgeAdjustmentAction could be rewritten as a subclass of GtkAction. The only caveat is that gtkmm might not expose 100% of functionality available through the C API.
I think you missed a bit of the subtle issues here.
Currently EgeAdjustmentAction already *is* a custom subclass of GtkAction. It adds a fair bit of functionality, however certain other code that *consumes* GtkActions may not handle things that EgeAdjustmentAction does. For example, some revisions of GTK itself had problems dealing with GtkWidgets created from custom GtkActions. Some of the GTK code itself was incorrectly assuming the created widgets would be of a specific base type and we would see hundreds of warnings thrown out on the command line when running under versions of GTK that did not yet have that fixed.
So in this case "some systems" includes "even certain subsystems of GTK itself", in addition to various third-party extended tools.
My guess, though, is that It appears you were thinking of C subclassing and of C++ and Gtkmm where one might want to rewrite EgeAdjustmentAction as a subclass of Gtk::Action (not GtkAction). In that case we get a far worse problem than the the one that you started to point out. The worse problem is where gtkmm objects often will only behave in an extended way if one *only* calls them from the gtkmm C++ pointers and will lose all extended behavior when called from the wrapped C object. (A simple way to test that is to take a C++ gtkmm subclass pointer and call gobj() on it. Use the returned C instance pointer with the C GTK API and see what breaks).
For many things, as soon as one switches from the C++ world and back to plain C GTK+ land, all extending gets lost. So if one wanted to use gtkmm subclassing of Gtk::Action one would need to only use tools (e.g. for OSX menu integration) that were solely C++ and gtkmm and could not count on general GTK-based ones. *However* one would also have to keep in mind that any C/C++ mismatch problems would be in addition to the common ones of using extended GtkAction subclasses that were solely operating via C. So you would end up with two or three sets of problems and not just one.
(oh and when you said "EgeAdjustmentAction could be rewirtten" did you not catch that it was already a subclass of GtkAction, or were you thinking of using C++ and rewriting it as a subclass of Gtk::Action?)
W dniu 4 lipca 2011 00:29 użytkownik Jon Cruz <jon@...18...> napisał:
So if a verb for a specific document is disabled, then multiple actions in multiple windows can automatically cascade to be disabled, etc.
I digress a bit, but the concept of having multiple editing windows for one document is fundamentally broken on very many levels; not only does this introduce additional complications, it can introduce severe confusion and lead to accidental data loss. (E.g. you opened the same document 2 times, made some changes to one of the versions and saved it, you then wanted to make different changes in the second window but the original was gone - FAIL)
One key point here is that verbs are abstract and operating at the document level. They do not directly deal with any UI issues (aside from the two methods get_action() and delete_view() which need to be refactored to live elsewhere). Contrast that with a GtkAction object which is completely about UI issues, including being able to create and maintain other GtkWidgets on demand for various UI scenarios.
GTK 3 has a GAction interface implemented by GtkAction, there is also a GSimpleAction implementation which can be used in non-GUI applications when there is no use for the UI stuff. Using GtkAction does not require a working X display as long as you initialize GTK correctly (there is a different init function that doesn't open the display) and don't create any proxy widgets.
So in this case "some systems" includes "even certain subsystems of GTK itself", in addition to various third-party extended tools.
When you wrote "systems" I was thinking about platforms (e.g. Mac, Windows) rather than functions in GTK. I hope this is improved with recent releases of GTK.
My guess, though, is that It appears you were thinking of C subclassing and of C++ and Gtkmm where one might want to rewrite EgeAdjustmentAction as a subclass of Gtk::Action (not GtkAction). In that case we get a far worse problem than the the one that you started to point out. The worse problem is where gtkmm objects often will only behave in an extended way if one *only* calls them from the gtkmm C++ pointers and will lose all extended behavior when called from the wrapped C object.
This only happens when the gtkmm bindings don't support the relevant GObject virtual functions / signals. Subclasses of Gtk::Action work as expected, while subclasses of Gio::InputStream don't (no vfunc support for this object).
(oh and when you said "EgeAdjustmentAction could be rewirtten" did you not catch that it was already a subclass of GtkAction, or were you thinking of using C++ and rewriting it as a subclass of Gtk::Action?)
I didn't catch that it was a GtkAction already, I think I confused it with something else. But subclassing Gtk::Action instead would also be an improvement.
Regards, Krzysztof
2011/7/5 Krzysztof Kosiński <tweenk.pl@...400...>
W dniu 4 lipca 2011 00:29 użytkownik Jon Cruz <jon@...18...> napisał:
So if a verb for a specific document is disabled, then multiple actions
in multiple windows can automatically cascade to be disabled, etc.
I digress a bit, but the concept of having multiple editing windows for one document is fundamentally broken on very many levels; not only does this introduce additional complications, it can introduce severe confusion and lead to accidental data loss. (E.g. you opened the same document 2 times, made some changes to one of the versions and saved it, you then wanted to make different changes in the second window but the original was gone - FAIL)
While I'm not a huge fan of multiple windows like that, I see where it's useful, and typically that's where someone will just open another view of the same document. I think the issue you're describing could be dealt with by us detecting changed files on disk (much like how gedit does it)... this would especially be nice if files linked to your doc are changed on-disk and giving a notification and offering to refresh the view of them. Just a thought.
Cheers, Josh
W dniu 6 lipca 2011 01:48 użytkownik Josh Andler <scislac@...400...> napisał:
While I'm not a huge fan of multiple windows like that, I see where it's useful, and typically that's where someone will just open another view of the same document.
Opening the same file two times is perfectly OK and there are valid use cases for this. What's not OK is propagating changes between those two "views", which appears to be the intention of the separation between "documents" and "windows" and Jon's implicit suggestion that one document (in the sense of SP tree, not a file) can be edited in more than one window.
I hope someone understands what I'm talking about. It's not about opening the same file two times, which is OK, it is about something like synchronizing the view of this file in those two windows, and I think it's very bad. At the moment Inkscape does not do the latter, but there are some code structures intended to allow it.
I think the issue you're describing could be dealt with by us detecting changed files on disk (much like how gedit does it)... this would especially be nice if files linked to your doc are changed on-disk and giving a notification and offering to refresh the view of them. Just a thought.
That would be an interesting feature to have.
Regards, Krzysztof
2011/7/5 Krzysztof Kosiński <tweenk.pl@...400...>
W dniu 6 lipca 2011 01:48 użytkownik Josh Andler <scislac@...400...> napisał:
While I'm not a huge fan of multiple windows like that, I see where it's useful, and typically that's where someone will just open another view of the same document.
Opening the same file two times is perfectly OK and there are valid use cases for this. What's not OK is propagating changes between those two "views", which appears to be the intention of the separation between "documents" and "windows" and Jon's implicit suggestion that one document (in the sense of SP tree, not a file) can be edited in more than one window.
I agree that opening the same file two times is indeed something that there are valid use cases for. However, the multiple views alternative workflow is also a valid (and widely used) feature. Illustrator does it, GIMP does it, various office/productivity suites do it, etc. It's not uncommon at all.
One use-case scenario is with a dual monitor setup, on Monitor A I can be zoomed in and working on details, while on Monitor B I have the zoomed out view of the full document, so I can see how it looks overall while working on it without fiddling between zoom levels. In "Productivity" apps, such as Word, you can have different pages of the same document pulled up in different windows and make changes in either view and it's only still editing the one copy of the document.
I hope someone understands what I'm talking about. It's not about
opening the same file two times, which is OK, it is about something like synchronizing the view of this file in those two windows, and I think it's very bad. At the moment Inkscape does not do the latter, but there are some code structures intended to allow it.
I hope my explanation above helps to show the reason why synchronizing between views can be useful.
Cheers, Josh
W dniu 6 lipca 2011 03:28 użytkownik Josh Andler <scislac@...400...> napisał:
One use-case scenario is with a dual monitor setup, on Monitor A I can be zoomed in and working on details, while on Monitor B I have the zoomed out view of the full document, so I can see how it looks overall while working on it without fiddling between zoom levels. In "Productivity" apps, such as Word, you can have different pages of the same document pulled up in different windows and make changes in either view and it's only still editing the one copy of the document.
That sounds sensible, though I don't have any idea how to make clear that the windows are editing the same thing and the changes will propagate.
Regards, Krzysztof
2011/7/5 Krzysztof Kosiński <tweenk.pl@...400...>
W dniu 6 lipca 2011 03:28 użytkownik Josh Andler <scislac@...400...> napisał:
One use-case scenario is with a dual monitor setup, on Monitor A I can be zoomed in and working on details, while on Monitor B I have the zoomed
out
view of the full document, so I can see how it looks overall while
working
on it without fiddling between zoom levels. In "Productivity" apps, such
as
Word, you can have different pages of the same document pulled up in different windows and make changes in either view and it's only still editing the one copy of the document.
That sounds sensible, though I don't have any idea how to make clear that the windows are editing the same thing and the changes will propagate.
We already do this (and it's similar to how other apps work). If you open a document in Inkscape, when you go to View>Duplicate View it opens the other window with the same name of the document and a ": 2"... or ": 3" or whatever number view that it is.
Cheers, Josh
On Jul 5, 2011, at 5:39 PM, Krzysztof Kosiński wrote:
W dniu 6 lipca 2011 01:48 użytkownik Josh Andler <scislac@...400...> napisał:
While I'm not a huge fan of multiple windows like that, I see where it's useful, and typically that's where someone will just open another view of the same document.
Opening the same file two times is perfectly OK and there are valid use cases for this. What's not OK is propagating changes between those two "views", which appears to be the intention of the separation between "documents" and "windows" and Jon's implicit suggestion that one document (in the sense of SP tree, not a file) can be edited in more than one window.
I hope someone understands what I'm talking about. It's not about opening the same file two times, which is OK, it is about something like synchronizing the view of this file in those two windows, and I think it's very bad. At the moment Inkscape does not do the latter, but there are some code structures intended to allow it.
I think it comes down to your personal preference not to work that way, but for the users out there who desire that workflow, we *need* to be sure it is properly supported.
A *key* to most all modern software is separation and modularity so the abstract (a 'document' in this case) can be reused in multiple ways (including multiple 'views' in this case). Every single piece of modern software that I have checked has supported this multi-view workflow, including GIMP, Photoshop, Illustrator, OpenOffice, and even Microsoft Word.
*ALL* of these apps propagate changes between the views simultaneously in realtime. Stating that it is not desired or is very bad is actually misunderstanding the problem. Many people need this workflow, and the applications all support it for those who chose to work that way. If one does not like to work that way, one just does not need to open additional views/windows. *However* if one *does* work that way, then the application needs to support that.
SP trees are also supposed to be easy to update in multiple views. That is a key point of our architecture. That does require one to do the proper thing at the proper level... but it is how Inkscape has worked and is supposed to work. If it does not work for editing a single SP Tree in more than one window then bugs have been introduced and need to be fixed.
For some helpful diagrams, the Java classes used for document editing are quite good:
http://download.oracle.com/javase/6/docs/api/javax/swing/text/Document.html (notice the section on "Notification" and its corresponding diagram)
http://download.oracle.com/javase/6/docs/api/javax/swing/text/JTextComponent... (take note of the model/view separation and diagram)
participants (4)
-
Gellule Xg -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński