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.