Hi all,
I am currently playing around with the code to get familiar with it and find out how things work. Sometimes I stumble across a piece of functionality that is apparently missing (or I am not able to find it). The most recent example is that I wanted to flip an entire path horizontally about one of its selected nodes - AFAICT from the code, flipping is only supported about the center of a selection. So I went ahead and tried to implement that, which worked surprisingly well.
Now I wonder if other people might be interested in this, too. I read about the "patch first, ask later" policy. I'm not entirely sure, however, how something like this would best be integrated in terms of both menu structure and the precise functionality - for example, what to do when several nodes are selected; I have come across situations where it is convenient to choose between the left-/right- or top-/bottommost node, but that clutters up the menus quite a bit.
Anyway, I still reckon it's better to come up with a patch first and ask for feedback afterwards, right? In this case I'd just arrange things so that they seem convenient to me. Would I send this kind of patch to this mailing list or should I already submit it to the patch tracker?
Thanks for your advice, Max
From MAILER-DAEMON Thu Mar 29 10:48:02 2007
Date: Thu, 29 Mar 2007 19:47:26 +0200 From: Thorsten Wilms <t_w_@...123...> To: inkscape-devel@lists.sourceforge.net Message-ID: <20070329174725.GC4679@...1413...> References: <460AABE4.1030309@...173...> <20070328182237.GC4676@...1413...> <460BF118.20107@...173...> MIME-Version: 1.0 In-Reply-To: <460BF118.20107@...173...> Priority: normal X-Mailer: Mutt User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 Subject: Re: [Inkscape-devel] SoC 3D box tool - website updated X-BeenThere: inkscape-devel@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list Reply-To: t_w_@...123... List-Id: <inkscape-devel.lists.sourceforge.net> List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-devel, mailto:inkscape-devel-request@lists.sourceforge.net?subject=unsubscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=inkscape-devel List-Post: mailto:inkscape-devel@lists.sourceforge.net List-Help: mailto:inkscape-devel-request@lists.sourceforge.net?subject=help List-Subscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-devel, mailto:inkscape-devel-request@lists.sourceforge.net?subject=subscribe X-List-Received-Date: Thu, 29 Mar 2007 17:48:03 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline
On Thu, Mar 29, 2007 at 07:02:16PM +0200, Maximilian Albert wrote:
Just some idea of a slightly different organisation:
- Don't have the user add VPs or a box, but a perspective
object
I'm not sure if I get you right here. Why would it be more convenient to add an "abstract" perspective object rather than just adjusting some VPs with a few drags, where you can _see_ what happens? Or do you mean that you want to be able to treat perspectives as objects of their own?
You can't have a box without VPs and VPs are useless if there is no box. Additionaly the VPs of a perspective share a horizon.
Regarding adding a box by dragging, I'm a bit concerned about the need for 3 drags in a row. Simply adding a box with default size would work around this (where the 'default' size should actually take the zoom level into account).
Internally, perspectives will be separated from boxes anyway. This makes it possible to compare perspectives for different boxes, to copy them from one box to another (here some care must of course be taken as to which corners should remain fixed), to define a default perspective, etc. But boxes are a very convenient way to define perspectives, so why not use them for this purpose?
If any number of boxes can be tied to a 3-VP/horizon system, I think this clearly establishes that there are separate entities. The user can't form the right expectations if you try to cover this up.
- The perspective object could come with 2 VPs on a horizon and
one box per default.
That kind of perspective will be the default when dragging a box anyway (at least, in the beginning). You may be right, however, that one could try and separate the concepts a bit more from the user's point of view, too. But only if this doesn't make things less intuitive or more complicated to grasp. I'll give it some further thoughts.
- The number of VPs would be a parameter of the perspective
object like corners are for stars/polygons.
Hmm, I think the number of VPs should be three unconditionally. However, each of them should be toggleable between 'finite' and 'infinite', i.e. the PLs either meet in a point or they are parallel. This provides a way to keep track of the _direction_ of parallel PLs, too. It's just an internal thing, though.
Well, where I said 2 VPs, I actually meant 2 'finite' and one 'infinite', as I have a hard time thinking of a point if I see parallel lines ;)
Hmm, for setups with several boxes in different perspectives, VPs have to be organised in groups.
For what purpose exactly?
'have to be' is maybe a bit hard, but say you have 3 boxes, all on the same plane. 2 have parallel edges, the 3rd is rotated. The 2 share all 3 VPs, but the 3rd only has the nadir in common with them. For additional boxes, you could choose between 2 groups of VPs (or create additional VPs). The alternative would be to select 3 VPs for a new box, one by one.
On 3/29/07, Maximilian Albert <Anhalter42@...173...> wrote:
Hi all,
I am currently playing around with the code to get familiar with it and find out how things work. Sometimes I stumble across a piece of functionality that is apparently missing (or I am not able to find it). The most recent example is that I wanted to flip an entire path horizontally about one of its selected nodes - AFAICT from the code, flipping is only supported about the center of a selection. So I went ahead and tried to implement that, which worked surprisingly well.
Not really surprisingly, implementing simple things in Inkscape is usually easy :)
I don't remember anyone requesting this particular feature, but it makes perfect sense. What about the UI, though? (I cannot try your patch right now, as I'm in the middle of an upgrade and cannot yet compile.) I propose the following: pressing H and V in the Node tool already flips the selected nodes; all you need to do is to check if any of the selected nodes is mouseovered and if so, use it as the center. This way you can flip only the selected nodes or the entire path if you select all nodes. It does not require any new menu commands and is very easy to do; also it will be consistent with other similar actions - for example, when you join two nodes, usually both go half-way to join, but if you mouseover one of the nodes, it stays put and the other one jumps up to it.
Also in Selector, there's such thing as the rotation axis that can be freely dragged in rotate mode (and it's remembered and saved for each object). The selector's flip functions (also called by H and V) do not use it at the moment for flipping, but I think they should.
Anyway, I still reckon it's better to come up with a patch first and ask for feedback afterwards, right? In this case I'd just arrange things so that they seem convenient to me. Would I send this kind of patch to this mailing list or should I already submit it to the patch tracker?
Usually, use the patch tracker and mailing list for those changes that you are not sure are desirable and/or safe. For something simple and obvious, you can just commit your changes directly as soon as you get svn write access (I will give it to you after I review and commit your second patch - our policy is write access after two successful patches).
Thanks!
I don't remember anyone requesting this particular feature, but it makes perfect sense. What about the UI, though? (I cannot try your patch right now, as I'm in the middle of an upgrade and cannot yet compile.) I propose the following: pressing H and V in the Node tool already flips the selected nodes; all you need to do is to check if any of the selected nodes is mouseovered and if so, use it as the center. This way you can flip only the selected nodes or the entire path if you select all nodes. It does not require any new menu commands and is very easy to do; also it will be consistent with other similar actions - for example, when you join two nodes, usually both go half-way to join, but if you mouseover one of the nodes, it stays put and the other one jumps up to it.
Also in Selector, there's such thing as the rotation axis that can be freely dragged in rotate mode (and it's remembered and saved for each object). The selector's flip functions (also called by H and V) do not use it at the moment for flipping, but I think they should.
This would have been my suggestion... use the rotation centre for flipping and have it snap to nodes with some short cut (or even standard and have a shortcut overrule it, since it already snaps to corners etc, which I consider to be great). It's just the most logical thing, I can think of right now.
Thanks!
David
On 3/29/07, David Christian Berg <david@...407...> wrote:
This would have been my suggestion... use the rotation centre for flipping and have it snap to nodes
Of course - both snap the center to nodes and snap the entire object by its rotation center would be good. Diederik, as you're working on it, can you please ensure that the item->getCenter() is added to the item's special snappoints in sp_item_snappoints?
I propose the following: pressing H and V in the Node tool already flips the selected nodes; all you need to do is to check if any of the selected nodes is mouseovered and if so, use it as the center.
Thanks for this suggestion! IMHO it's indeed the best way to do it. Just one question: What is the best way to easily obtain the current active (= mouseovered) node (if there is any)? The variable active_node in nodepath.cpp seems to serve precisely this purpose. But it's declared global static, so it can't be accessed from other files. Is there a good reason for this? Why not make it a static member of, say, Inkscape::NodePath::Path? This was my first approach, and it works perfectly. But I want to make sure I'm not missing anything.
Thanks, Max
On 4/1/07, Maximilian Albert <Anhalter42@...173...> wrote:
I propose the following: pressing H and V in the Node tool already flips the selected nodes; all you need to do is to check if any of the selected nodes is mouseovered and if so, use it as the center.
Thanks for this suggestion! IMHO it's indeed the best way to do it. Just one question: What is the best way to easily obtain the current active (= mouseovered) node (if there is any)?
Like I said, it's already used in the code. So for node a, the check is:
if (a->knot && SP_KNOT_IS_MOUSEOVER(a->knot)) {
The variable active_node in nodepath.cpp seems to serve precisely this purpose. But it's declared global static, so it can't be accessed from other files. Is there a good reason for this? Why not make it a static member of, say, Inkscape::NodePath::Path? This was my first approach, and it works perfectly. But I want to make sure I'm not missing anything.
I didn't add this variable, so I was actually unaware of it :) If it works, that is, is properly updated by all relevant code, then indeed there's no reason not to use it and not to make it a public member of Inkscape::NodePath::Path.
bulia byak schrieb:
Like I said, it's already used in the code. So for node a, the check is:
if (a->knot && SP_KNOT_IS_MOUSEOVER(a->knot)) {
Yes, I found that piece of code. But I considered it a bit cumbersome having to run through all selected nodes just in order to check if any of them is mouseovered when there is already a variable containing what I am looking for. :) That's why I was wondering ...
If it works, that is, is properly updated by all relevant code, then indeed there's no reason not to use it and not to make it a public member of Inkscape::NodePath::Path.
So I'm going to do that and use it to make the suggested change for the flipping behaviour (also for the selector's flip function to take the rotation center into account). The patches will go to the tracker (may take a day or two, though - my thesis is calling :)).
Thanks! Max
participants (3)
-
bulia byak -
David Christian Berg -
Maximilian Albert