Yes I meant just that, and "HUD" is a good term for it, more specific than just pop-up. In Inkscape's case for text, it would be some kind of poup that pops up nearby the text in question (using a keycombo or the context menu or something) and you set text properties right then and there.
Hmm the feedback was just generally, if there are any comments on the plan or whether something should be added, or if someone else is already working on something that i've proposed. But it seems the contract is now almost finalized so this point is moot. I also think now Mr. Dexter was more speaking about peer review of the code (which of course will happen naturally, I think best would be working in an SVN branch?).
I'm going to write very generic code, it's just the way I write stuff these days. Not absurdly abstract APIs but generic enough so that e.g. the dropdown can be used independently of whatever provides the actual font previews, and so on (have an enumerator/adaptor interface that bridges a specific library for providing the fonts, with the list widget). With this I hope that the dropdown could be maybe reused in the future for other projects that don't use libnrtype, and so on.
On 02/08/2009 03:19 PM, Milosz Derezynski wrote:
On Sun, Feb 8, 2009 at 9:53 PM, Josh Andler <email@example.com <mailto:firstname.lastname@example.org>> wrote:
Isn't it a goal to get the on-canvas text editing via the Text
Tool to a point that the Text & Font dialog can be removed? I'm
mainly wondering because it seems like if that is the case, the
proposed work to the dialog would effectively be a waste of resources.
Do you mean something like context menus or perhaps (what I'd rather have in mind) popup windows which pop up next to the text items and from which you can edit the properties, sort of like a pop-up ribbon maybe? That sounds like a great idea! Is it that what you meant?
No, I was speaking specifically about the Tool Controls bar for the Text Tool, I believe the only two things in the text and font dialog it lacks is the line spacing widget and the ability to spell-check (which currently is not done on canvas). Honestly though I would be somewhat intrigued by a pop-up hud that could be called by a keypress that perhaps had either the basic text controls or maybe an advanced set. One example with an art program that has one hud element I'm aware of (it's pretty nifty) is one of the color pickers in MyPaint:
With a key press the color picker encircles the tool to allow color selection with minimal mouse movement, another key press (same key) and it's dismissed.Also, what type of feedback are you looking for since the negotiations appear to be at such a late stage? And as usual, the more generic and reusable code is, the better. :)
Long time no see! I hope all is well. Do you have any idea as to
the scope of what they will be funding? Is it depending on what is
proposed, or is there a set amount of money allotted?
It depends really on what has been proposed. I don't know about the general amount of money they can spend.
I'm not sure if we can still change the scope of what I'm about to do because the negotiations seem to be in a final stage, however if this should not be possible, I can take care of coding whatever I'll be doing now so that it could be easily rearranged into the aforementioned popups, the widgets used and the "frontend backend" code will just have to be generic enough.