Backlogs and Real Life

The last three months have been a bit crazy, with far too much "real life" hitting us upside the head. Things have finally settled in a bit so that I'll be able to get my head above water and surface again. Aside from diving head first at the new day job and surviving the holidays, much had happened in the tech world.

I still haven't had time to finish my writeup of SVG Open (partly since I accepted the new day job while I was attending it up in Mountain View). Then there was the Google Summer of Code Mentors' summit. Great things happened there. Then I had to prep for our visit to New Zealand as co-organizer for a Libre Graphics Day miniconf and as a speaker at the main linux.conf.au. Then we had SCALE8x come 'round where I presented yet another talk and then also run the Inkscape booth on the show floor. Toss in getting a new tech (adaptive UI) going, starting a new project with other CREATE guys, and doing battle across the board to help get proper CMYK support out for end users everywhere.

Whew!

On top of all that was work for Inkscape and trying to get new features solid for the next release, 0.48. Thankfully I was able to squeeze the time in to finish up the basic support and UI for per-document color/swatch palettes. This allows for basic colors to be stored as a set in a given document, but also for gradients to be included in that. One big thing that inclusion accomplishes is breaking down the artificial barriers software engineers have imposed on artists for far too long. Assets had been artificially separated by their *implementation*, without regard for how artists actually are used to working. This also enabled many workflow enhancements including making art recoloring easier, indicating which swatches are in use on the selected object, etc.

Work on the new input devices dialog also came through. Aside from more end users getting their hands on tablets and such, we had a push in that the ugly outdated GTK+ dialog is being removed. And just in the nick of time we had Krzysztof step up and investigate some of the win32 tablet bugs and get some insight on the problem with Aiptek and others showing up with broken names. I was able to help refine the fixups there wile getting them set to be reimplemented in the new dialog.

And then there is the basic work on adaptive UI. This is a very promising area, and is just beginning to show the tip of the iceberg. I'm implementing internals based in part on Michael Terry's work with INGIMP he has presented at LGM. Though 0.48 will only expose a tiny bit of what can go on, the support in Inkscape will give it some very useful functionality in even the near term. We're looking at only giving 0.48 a few set layout modes, but with some handy logic behind the scenes to assist users getting what they need without having to think as much.

Unfortunately, though, we were unable to find time to work in support for Wii remotes, joysticks, and the SpaceNavigator someone at LCA lent me. We are on track to get more in, and 0.49 might even see some of that. Some of this (like using guitar game controllers) might sound a bit silly. However there are some very interesting ways these can be worked in and give Inkscape some nice functionality for average users. And, of course, more hardware toys always makes the geeks happier.

Read more!

Linux conf au one

Well, here it is. Another conference has come to a close, and it is time again to try to make sense of all the amazing things that were seen and discussed. Overall LCA was a great meet-up, although there was one big negative: there were so many good sessions to hit that it was impossible to not run into at least some scheduling conflicts. Of course the good news there is that the volunteers are working to get slides and video up for as many of the sessions that they were cleared to. One things are up, I'm sure I'll find even more to ponder.

Probably the first thing to hit is the topic I came down to speak on: Color Management. My presentation went pretty well, and I had a few people talk to me about it later (and that was despite being scheduled right next door to the Linux powered clarinet playing robot). Additionally Carl Worth introduced me to someone who has started poking around in Cairo, seeing about hooking in color management. We also got a chance to go over what's needed to get things hooked into Cairo and get some nice CMYK PDF output. The next step is to collect up some representative use cases so we can figure out exactly what the API changes will have to be supported. I'm going to be pestering the Scribus guys to see what they know of, but if anyone out there has any experience or needs of going to print, send off an email or comment so that we can be sure to cover things well.

Next up is extended input. I attended a talk by Peter Hutterer (of MPX) that went over a bit of the state of things and then the new changes that have been going in. Over the course of the conference I had ended up chatting with him a few times, and verified that I am on track with where I'm working on taking the new extended input support (good support will need to leverage D-Bus and HAL). He also had poked around for a couple of weeks with Wii remotes, but had since moved on. That actually was a fairly common story, and it seems that it's up to me to address the GUI and application levels.

And to keep things short for now, there's one last point I want to cover: technical drawing. Of people I talked to who were not using Inkscape or not using as much as they could, the most common question seemed to be with technical drawing. We could probably pick up a good usability boost and garner another user segment if we just tune up things to make technical drawing and diagramming better. Most of what we need to do is probably already well known to us. However, we could benefit from a quick review and a little refocusing. I think one person's question really summed up the viewpoint we need to use when looking into this: “So, will Inkscape let me finally move off of Xfig now?” The people we could help with that are probably using Xfig or Dia (or nothing yet) for simple charts, diagramming, home layout and the like. Perhaps focusing down on some casual use-cases like that will help us sight some low-laying fruit and get a jump up in this area.

As usual, I'll send out more info as I digest things and get them settled out in my head. In the mean time, feel free to ask about any specifics you might care about. Perhaps Peter or Andy or some of the other Inkscapers who were there might chime in also.

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!

Tablet Test Area

I've gotten a bit more committed to SVN for the new input devices dialog. It does tracking of buttons and axes now, with different graphics to show ones that have been seen, ones that have not, and ones that are currently active. There are two main benefits right off the bat (aside from the gratuitous "oooh, pretty lights" factor). First is that it allows a simple way to determine what inputs any given device really has, as opposed to what is reported to GTK+. For example, my tablet's pen says it can handle 7 macros, but it only has 3 buttons. And I've seen that although the driver reports six axes, I only get data on five (aka there is one 'dead' input axis). The second main functionality is to allow a user to see which physical parts of his devices are hooked up to what. For example, an Intuos3 tablet has buttons and touch strips on the tablet itself, but it may not be immediately obvious how those are configured. Under Linux, I see those strips as the x-tilt and y-tilt axes. Also using the visual feedback it is easy to see which buttons have which numbers. Then below I'm using progress bars to show the current values of the axes, so it's easy to get an idea of how those values range on different physical changes. I still need to add some visual feedback for those that have no bounds, but those are usually the ones mapped to x and y, so are already being used for positioning. Now the next thing is to get some feedback on how this works for other people. That will also help for the "Configuration" tab which will allow setting of things such as screen versus window mode, button actions, etc. Those may change with the user's current task, but the hardware usually will stay in one (or a very few) combination.

Read more!

New Tablet Config

I've got the initial cut of the new replacement for GTK+'s extended devices input config done.
The old dialog has been around for quite some time, and is really good for a low-level view of things. However, the needs of users have moved more and more into the high-level artist-centric viewpoint. This is a bit nice for me as a software engineer, but definitely is not as nice for my artist side. X? 1? 6? Which do I need? What do they mean? Also "pad"? Why is part of my tablet showing up just like my tip of my pen does? And for that matter, why does my eraser show up as something separate from the front of the same pen?
The work on a replacement has progressed to a point where something is visible and initially functional. One minor point is that the dialog is now dockable... but that's a minor item. The first functional point of note is a separation of hardware from configuration. The more common case will be that a user has a single tablet, but a few different ways of working with it. The next point is the Test Area. I've found that it is a bit hard to tell what's going on with tablet config. Currently the area should switch to indicate the device currently active on the tablet. Additionally it will dump events to stdout. This will allow for checking things like button numbers, axis values, etc.
This is in the current sources now, but needs USE_NEW_INPUT_DEVICES defined in verbs.cpp to turn it on (hint: this is for those of you able to build). So the next thing is to get some user feedback to see if it reports events correctly, detects actual devices, etc. So have at it and have fun. :-)

Read more!

Enhancing tablet support

For some time I have been wanting to help with tablet support in Inkscape. Things have finally come together enough for me to get started. We've had at least one RFE on this for a while (bug #171265) The first step of this is in, and now has a preference setting to enable switching the Inkscape tool as different devices are used on the tablet (pen tip, eraser, mouse, etc.) The implementation will probably need a bit of testing and refinement, but it should be ready for users to check out. The coding is not that difficult; most of the real effort is with figuring out the behavior that needs to happen. At the moment the tool switched to is always the same for the same tool, but very shortly it will remember the last tool used. In the long run I'll probably be replacing our use of GdkInputDialog to provide easier configuration. However, the main thing missing is how different tablet setups are configured. Multiple pens, multiple tablets, non-Wacom tablets, etc. That's where feedback from end-users and testers really comes in handy.

Read more!