Smaller Extension Preferences

Alexandre asked this week if it would be possible to use combo boxes instead of radio buttons in the preferences UI for extension dialogs. Aside from that being a good suggestion for UI improvement, there were a few good factors in its favor. First of all, things have been cleanly abstracted enough so that hooking in such a change would not be much work (thanks, Ted). So a good UI benefit with minimal coding effort is generally a good thing. Second is that I've done things like this before, and have been thinking about general ways to improve the dynamic UI like this. So I've already had my mind wrapped around the problem. That's always a big hurdle to starting a coding project, even one as small as this. And finally, this just happens to line up exactly with my plans for world domination via XForms implementation. Moving forward on world domination is good, so it became a requirement for me to code it on up. :-) Here it is: On this one dialog the vertical size shrank about 30%, which seems quite helpful. I think the Eee PC users will gain some benefit here too. The other dialog I tried it on changed from 700 pixels tall to only 530, saving about 25%. More important than the percentage, though, is that this case will help those running at 1024x768 (aka LCD monitor users and such). The C++ part of implementation was not too much at all, and seems rather trivial to me (maybe around 75 lines of code). Using the change, however, is very simple. Just add appearance="minimal" to an existing optiongroup in a .inx file and it will switch over to the combo instead of radio buttons. That's the beauty of XForms... it's mainly a way to use existing technology to gain strong benefits. And on the subject of XForms, I find Micah Dubinko's "O'Reilly XForms Essentials" a very good book on XForms specifically and on lightweight UI design in general.

Read more!

Next eraser toggle

I'd forgotten to point out that the mode toggle for the eraser tool showed up in SVN, along with the main eraser mode that it enables: When that mode is enabled (which should be the default) the eraser tool acts more like a vector eraser than a raster eraser: As you can see, it allows someone to zig-zag around and delete objects very selectively. The functional details need to be tuned up a bit, as it doesn't behave well with clicks as opposed to drags. However, it should be enough to see what the feel is and how it's different from the other mode. Now all I have to do is get my tablet happy with Hardy and I can get those details like width, etc., nailed down.

Read more!

Adding another little feature

So here I go, finally adding a little feature that's been kicking around for some time now. The first half of it is done, but it's the half that notices changes and reloads that still needs to be worked on. Oh, and then there is also the half of trying to figure out what to invoke, and the half of needing to deal with embedded images... Well... it's a start. Feedback on that bug would help get more things going.

Read more!

First phase of tool committed

Here it is... The first part of the code for my new "eraser tool" for Inkscape is in trunk now. I've been working on the use cases probably more than the code even. However this is now a starting point for people to look at and start complaining. :-) This first part only adds in the functionality to cut away parts of objects you have selected. It won't do anything if you don't have something selected, and it won't do anything if the first mode is selected (the sub-toolbar has toggles for the two modes). However it does commit all the infrastructure changes including the new icons, new drawing context, verbs, switching, etc. I had been wanting to get that in first to shake down bugs in that support work. Moving forward I'll implement the "touch-delete" mode, and support for working when no selection is made. Probably a few more enhancements will come in as people try it out and give some feedback. I'm most excited about the pending "touch-delete", since it has a feel that strikes me as very "vector" and can differentiate the usage from raster drawing packages.

Read more!

Freedom from size tyranny

Inkscape now has tweaked toolbar size preferences. Why is this? Well the main thing is that it makes the UI more usable on Ubuntu again. There have been some ongoing issues with size, many of which are due to the use of custom toolbars from before GTK+ had stock ones. A while back I added some options to use 'secondary toolbar' size for the main tools on the left (and the top bar also), but for some users that did not help. Between Inkscape 0.46 being released and me recently getting a laptop with a very small screen (thanks Dice and LugRadio Live), I've been getting more done on that front. After seeing more bug report activity on it, especially from people running on fixed 1024x768 monitors, I tracked down a bit more. The main issue is that while Inkscape is properly respecting the user's GTK+ theme for sizes of icons, the people setting those themes up for Ubuntu, among others, had chosen to set the two toolbar icons sizes to the same. So switching from using the primary size to the secondary size did nothing to help, as it just switched from 24x24 to 24x24. So on the one hand the theme designers are imposing their idea of how things will be pretty, but on the other we were facing imposing our idea on what would make things more functional. Either way seems bad. So after splitting this specific issue to its own bug (#221676), I settled in and added enough preferences so that now the end user can decide what they want to do, and on a per-platform basis. The change reduced the minimum size from the old 652x735 to now be 600x583, just over a 20% reduction in vertical size required. The big gain there is that it should no longer be pushing things for Ubuntu users on lower-res LCD monitors. Additionally now when I flip over from OS X to Linux, I'll be able to keep the smaller icons showing up that make my workflow go faster. Of course that does tend to mess with the crispness of some of the icons... but if people care about that they can just set the sizes back. In the long run we have plans to address that, but for now at least the work-arounds should be sufficient.

Read more!

LugRadio Live is on

LugRadio Live USA has opened, and the first day is done. All the prep didn't come of quite as we wanted, but things still worked out well. Inkscape got a nice placement near the front, right next to OpenSuSE (who has really nice Banshee shirts). The event is shaping up to be very good, and had many different people come by the booth. Early on Stuart Langridge stopped and gave hearty thanks to all you who make Inkscape possible. He'd picked it up and whipped up a graphic and banner for the event (blogged under "Coming to America" at the LugRadio Live blog). Overall things are better than I'd expected. Though the attendance might be smaller that some shows, the people attending seem very savvy. Then again, we also have a lot more people basically coming by to say Inkscape rocks. There were a few people teaching or knowing of people teaching it, and looking for more materials. A there were few people from different projects I got to talk to, including Behdad of Cairo. Several people had things we might want to look at adding or enhancing. Hopefully we'll get the details coming from them. For example, Miguel de Icaza came by with a few things he got from recently seeing some artists in action, and it struck me as possibly something to tie in with animation and possibly the script Ed Halley was recently doing. I've been taking notes, and will get some details out to the mailing list this coming week. More later...

Read more!

What's This?

Interesting... so what's this that is showing up in my tools bar on the left, making Inkscape suck up even more vertical space? Interesting... could it be something I'm coding, but haven't quite finished due to prep for LugRadio Live USA? Could be.

Read more!