Hey Josh!

On Sun, Feb 8, 2009 at 9:53 PM, Josh Andler <scislac@...400...> wrote:

Bulia,

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?

Milosz,

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.

Cheers, Josh

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.

M.

On Mon, Feb 9, 2009 at 9:34 PM, Josh Andler <scislac@...400...> wrote:

On 02/08/2009 03:19 PM, Milosz Derezynski wrote:

...

Hey Josh!

On Sun, Feb 8, 2009 at 9:53 PM, Josh Andler <scislac@...400... mailto: scislac@...400...> wrote:

Bulia,

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:

http://mypaint.intilinux.com/wp-content/uploads/2009/02/mypaint060b.jpg

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.

...

Milosz,

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.

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. :)

Cheers, Josh

Congrats on getting the contract Milosz. :-)

http://www.linuxtoday.com/news_story.php3?ltsn=2009-02-24-005-35-PR-CY

Bryce

On Mon, Feb 09, 2009 at 02:21:12PM -0700, Josh Andler wrote:

On 02/09/2009 02:04 PM, Milosz Derezynski wrote:

...

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?).

No one is currently working on the items mentioned that they've announced (at least not that I recall seeing). As for peer review of code, I'm sure it will not be an issue. With regard to best place to work on it, if you are looking for peer review or testing throughout the process it would be good to do in a branch until it is functionally equivalent to (or better than) what's in trunk. Basically the key is not losing any functionality in trunk... so if you could even work on it there and perhaps have a config option to compile it with your stuff instead (thus not breaking normal functionality), I don't think anyone would have any issues with that option either.

...

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.

Sounds good. :)

Cheers, Josh

---

Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel