We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Introducing AdaptableGIMP

00:00

Formal Metadata

Title
Introducing AdaptableGIMP
Title of Series
Part Number
37
Number of Parts
39
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Production PlaceMontreal

Content Metadata

Subject Area
Genre
Abstract
In this talk, we will present AdaptableGIMP, a new version of GIMP that introduces the notion of crowdsourced interface customizations to applications. Using AdaptableGIMP, users can customize the software for specific tasks. These customizations are instantly made available to all other users. Additionally, each customization has a corresponding wiki page, allowing tutorials to be created for each customization. We will describe the rationale behind the approach, demonstrate the new interface and its features, and discuss implications for this design.
Keywords
Universe (mathematics)TheoryRevision controlInterface (computing)Multiplication signSource codeFlow separationSet (mathematics)Different (Kate Ryan album)Metropolitan area networkRight angleDemo (music)Projective planeGame theoryTwitterUniform resource locatorTask (computing)Lecture/Conference
RectangleSquare numberTwin primeExecution unitChemical equationTask (computing)Set (mathematics)CuboidTrailTask (computing)Computer programmingMultiplication signCartesian coordinate systemPresentation of a groupInterface (computing)Shape (magazine)WikiNormal (geometry)Graph coloringMathematicsResultantQuicksortView (database)Set (mathematics)MereologyElectronic mailing listSoftwareSource codeWeb pageWordComputer clusterStandard deviationRevision controlWindow2 (number)AreaMessage passingGroup actionOpen setMenu (computing)Selectivity (electronic)32-bitWeb browserData structureDemo (music)Adaptive behaviorOcean currentComputer-assisted translationInformationSoftware testingDifferent (Kate Ryan album)Right angleBinary codeDescriptive statisticsMedical imagingVarianceLattice (order)Bit rateArithmetic meanPoint (geometry)AveragePhysical systemProjective planeInterrupt <Informatik>Sampling (statistics)Graph (mathematics)Coordinate systemAnnihilator (ring theory)Vector spaceComputer animationLecture/Conference
Annulus (mathematics)Interface (computing)WikiQuicksortDifferent (Kate Ryan album)Context awarenessCartesian coordinate systemTask (computing)Adaptive behaviorSet (mathematics)Direction (geometry)Point (geometry)ResultantEmbedded systemConnected spaceInclined planeModule (mathematics)Instance (computer science)SequenceRepository (publishing)Entire functionSoftwareLibrary (computing)Shift operatorDefault (computer science)PlanningFront and back endsTerm (mathematics)Type theoryMultiplication signMathematicsCodeConstraint (mathematics)Software engineeringSinc functionCAN busReduction of orderOnlinecommunityBasis <Mathematik>Key (cryptography)Message passingDescriptive statisticsRevision controlWeb pageMereologyOpen sourceExtension (kinesiology)Student's t-testRight angleObject (grammar)Streaming mediaPresentation of a groupIntegrated development environmentEndliche ModelltheorieMetropolitan area networkTheoryWordFile formatGoodness of fitCASE <Informatik>Product (business)TouchscreenComputer hardwareSemiconductor memoryPhysical systemPerspective (visual)Game theoryEvent horizonElectronic mailing listComputer animation
Execution unitMoment of inertiaoutputMaxima and minimaFloating pointValue-added networkTask (computing)Gamma functionGame theoryGroup actionTerm (mathematics)Software testingMultiplicationGoodness of fitQuicksortRight angleTask (computing)BitMathematicsWritingWikiRevision controlWebsitePrice indexLattice (order)Uniform resource locatorServer (computing)Proxy serverSlide ruleDirection (geometry)FeedbackCuboidDatabaseComputer configurationSet (mathematics)BlogState of matterFactory (trading post)Decision theoryCodeMedical imagingOcean currentAreaInformation securityElectronic mailing listLink (knot theory)Directed graphTouch typingType theory1 (number)Social classOrder (biology)Multiplication signRepresentation (politics)Arithmetic meanHypermediaOracleCollaborationismEndliche ModelltheorieInformation privacyBranch (computer science)Installation artOnline helpSynchronizationElectronic visual displayLocal ringAdaptive behaviorMacro (computer science)Computer animation
InformationUniform resource locatorProjective planeProduct (business)AreaComputer animation
CountingWikiEmailMultiplication signInformationWebsiteWindowDirected graphEmailWeb pageVideoconferencingComputer animation
Transcript: English(auto-generated)
So I'm Michael Terry from the University of Waterloo. You saw me briefly this morning. So this is my second talk. Mostly, Ben is going to be giving it, but I also want to introduce Phil because he's been working on the project as well. So about four years ago, I came to LGM and I said, hey, we have this version of GIMP that's instrumented
called InGIMP. We want to collect data about how people use it in practice. We collected several years worth of data. So thanks to everybody who downloaded and used it. And one of the most interesting findings was that people used about six different commands out of about 500 commands in GIMP. But they weren't the same six commands.
They were a different set of commands. So we couldn't just say, well, these are only six commands that people use. Let's just get rid of everything else and then we just have these six commands. No. Everyone used a different set of commands. And we said, well, what can we do with this finding? Obviously, interfaces are complex. It takes time to locate commands in the interface.
What can we do to help users? And one of the insights was that when you want to perform a particular task, the commands you need are scattered throughout the interface. So you have to go and grab a command here, grab a command here, grab a command there. They're not all centralized. And so what we're going to demo today is this new version
of GIMP called Adaptable GIMP. And I think we probably have to switch. It looks like we've got to switch sources. Is that right? Yeah. There we go. So we have a new version of GIMP
that we've been working on for over a year now, really, called Adaptable GIMP. It's available right now. You can download it. You can get the source code. You can get binaries for 32-bit Ubuntu. You can also get it for Windows. And so at this point, I'm going to hand it over to Ben.
And he's going to give you a live demo of Adaptable GIMP in action.
OK. Is that good? Or should I? It's good? All right. All right, great. So this is Adaptable GIMP. I've started it up here. The first thing that you'll notice is that we've got this standard GIMP
interface underneath. But we've got this Choose User window in front here. And that allows people to use users that they create on a wiki, which is associated with the application. Which I'll show the wiki in a second and explain how that all works in.
But just take it on faith for right now. You've got this concept of users and such. So click a user. Now we've got the normal GIMP interface. But a lot of things are different over on this side
here. We've got a modified toolbox. The first thing you might notice is we've got a sort of longer view for commands rather than the typical grid view. And part of the motivation for that is we're talking about customizing the interface for performing particular tasks.
And the inGIMP project, one of the things that we found was people typically use an average of about six commands to perform a task. So we created something where you can have extra detail on the commands that are included. And because of that result of only about six commands,
we could keep the size down. So the other thing, the more important thing, is we've got this search box up here. And this is for searching what we call task sets, which are customizations of the interface for performing particular tasks. So I'll just give a short example of using the program.
So I just created that. So Adam mentioned in his presentation this morning that drawing basic shapes in GIMP, this was something that a lot of people are searching for. So I just find that that's kind of a good example.
So typing into here, you get a list of different task sets. Selecting one customizes this toolbox for performing that task. So now I can grab that.
Stroke selection. And there. I don't know if there's ever been that much applause for drawing a rectangle, but. Sorry, please interrupt us with questions.
Yeah, yeah, yeah, about this as we go. Hi. Wow, yeah. So that's cool that you knew how to do that with those
tools, but how did you know to do that? How did I know to? The stroke selection was the right answer. Oh, that's so. Yeah, OK, so that's actually an excellent question. And we did not plant you in the office. So we have clicking there brings up in-application documentation.
You were going to say something? Just go ahead and do it again, because I think he was not watching. Oh, yeah, yeah, OK. So beside the current task that's loaded, we've got this info button. And that brings up documentation for the current task set. So this is where the whole thing
that I was talking about before about Wiki comes in. So this is actually documentation on a wiki at adaptablegimp.org. So if I click Open in Browser here, this is a wiki page.
We use a modified version of the MediaWiki software to implement this. You'll notice that, more or less, it's a normal wiki page. We've got this description area. You can edit it like a normal wiki page.
But also, on the right-hand side here, we have a list of the commands that are included in the task set. And so if I were to go and edit this wiki page, it'll take a second. But we have an interface on the wiki for adding and removing commands.
And the list of commands in a task set are actually stored as XML. That's actually how we do it, just underneath. It's stored as XML in the wiki text of the actual page.
And then you have the normal stuff for editing a wiki page down below. And so the nice thing about using a wiki for this is that we get all of the change tracking and all of the other things that wikis have evolved over time for coordinating effort of people contributing to documenting and creating
things. So that's back to the application. So we have a bunch of task sets created right now. The one that I like to use as an example
is a changing eye color one. And I like to use that as an example just because there's a cute cat in the thing here. So mostly right now, the task sets that we've got on here were created by us based on lists of common user needs.
But the goal, obviously, is to get a community of people creating them and documenting them. So as well as being able to create task sets on the wiki, you can create them inside of the application. So no, that's the wrong one.
So I'm just going to say, like, test task set. Does that work? OK, yeah.
GM demo, yeah, yeah, yeah. And then I'm just going to choose a few GIMP commands here and add them in. Now, we arranged the commands by the menu structure here, just because that's familiar to people using software.
And then you can optionally add some description, which will act as a seed. It will act as the text that starts off the wiki page. And when I click Save Changes here, it uploads it to the wiki. Now, we display this page at this point, or this message at this point,
because once you create a task set, you have a copy of it on your system, and it's created this wiki page version of it. And any changes to the wiki page version of it are not pushed down to your local version, because we felt that that would be kind of disconcerting
while you're using an application, or even between runs of the application, the commands and things that you have installed are changing it.
All right, so let me throw some buzz words out at you. The main idea here is we're essentially allowing for the crowdsourcing of interface customizations that are task-centric. So any customization of the application you make through adaptable GIMP, once you save it,
it's made available to the entire user community. So the idea is that everyone can learn from one another more easily than they do right now. So you have this idea for this customization. Maybe you want to create one for tilt shift photography.
So there's not one there. You create it. Once you save it, the entire community then has access to that. So you create the customization. When you create it locally, like Ben said, then it's uploaded to the wiki, where it has its own wiki page. So maybe you want to go to the wiki now and just show the one you just created.
To really prove that it's live and it's actually working. Yeah, so we have a little thing here that says that this has been uploaded. But I'll access it as I did before. And so one of the things that we hope
happens is that people's propensity or inclination to create documentation and tutorials can now be done through this. So the open source community has already
demonstrated that people will willingly create tutorials and documentation to support their software. Now you can do so in the context of the application where you're not only providing the documentation, you're also providing the ability for the user to customize the interface for that particular task.
So instead of having to go to a web page and say, OK, well, where is this particular command in the interface? Where do I find that? Everything's collected for you in one spot in a task set in the toolbar. So first of all, this is really awesome. And we definitely need to get this shit working in Blender because people are so confused by Blender.
And the Python API would make it really easy to, well, not super easy, but it would make it totally possible. But on a similar note, I would suspect you had, this is so cool that it would be great to see it really not die. And my fear is that, as I understand it, GIMP doesn't allow you to be able to do this stuff in there
without patching the back end. So how are you going to help make sure this dream stays alive? Well, how are you going to help make sure? I don't know. I'm kind of so devoted, but. So our original intention was to have these as a plugable set of modules.
And so Phil here was actually working as a co-op student with us the entire last term to get all this working. And as his co-op term started to run out, we said, OK, well, just get it working in GIMP, and then we'll worry about modularizing it later. So yeah, we would love to make these things
as a set of extensible modules that other people can use. The basic ideas are there, and so you can at least look at the ideas and maybe hack something up on your own. Can you add two instances of the same tool with different default settings? So we haven't integrated yet the ability
to change default settings, but that's something that we're really, really interested in, as well as changing the name of it in some way as well. We do have the ability to include multiple instances of the same tool because one of the nice things about this
is that we want to support having commands in the sequence that you'd use them. And sometimes you might use the same tool at different points in the sequence, so we do have support for including the same command twice. Gotcha. The reason I ask is in my community, we have a lot of people who like to do pixel art, which
uses a very reduced feature set. And I find that GIMP's features are really very good for that. If you can dig your way through all the other stuff that's totally unnecessary for it. But in that case, it would be nice to have different tools that are sort of the same tool but with different settings.
So you can use them quickly but in different ways. Yeah, that's really something that we're interested in doing. The other big thing that we want to extend and add in there is some sort of scripting so that certain tasks you're not going to need to do any human intervention in them.
They could just run in sequence. So we would like also the ability to have like collapse those into single things. The one key concern is these things should be sandboxed.
So if you start executing code, essentially code from the net, we need to make sure we do so in a way that's secure. OK, I have slightly different questions. Since in Inkscape I started implementing adaptability in a different way with a completely different concept. Well, coming at it from a completely different side,
and I see where you're hitting with this, who do we need to coordinate with to make sure we get a nice common library out of this stuff that is reusable so the common work like you have in here can be shared, especially the simple format, what to do, how to approach it, and then make it ubiquitous everywhere?
So that's a great question. I would say all three of us is who you would coordinate with. We do have a git repository of this made available. But if working with you helps us get to the point where we have these generic modules
faster, I think that would be great. So one of the steps in that direction is we want to create a microformat for representing customizations, because that would just be a nice step towards defining
how to embed descriptions of commands or other customizations into documentation. And that's a big part of this approach. From a back end perspective, part of the reason that it's XML is because it's extensible, so we can do things like eventually add in the per tool customizations that we're asked for
and be able to support things like other applications that may have very different needs. Because of time constraints and wanting to get some data on this, we did have to kind of, we started with this grand software engineering plan where everything was abstracted in the back end and everything was extensible to support any kind of object,
but at the end of the day we had to get something presentable, so we did have to sacrifice some of that. But I mean, on my to-do list, at the very bottom, the first thing I put on there was create lib adaptable, so it's still there. Yeah, this applause came for me, at least
because to see the connection between InGimp and this is really fantastic. Oh, thanks. Not to see that the data collection actually led to thinking about how you could literally start to make the interface adaptable.
So I'm curious if you have any ideas of what you will come present to us in 2013. Yeah, I don't know. So the next step really for this is to build a community around this. So I encourage you to download it, use it,
let us know what works and what doesn't work for you. If you don't want to use it for whatever reason, let us know so that we can make it more accessible and more attractive to people. So yeah, two years from now, I don't know. When I came here and talked about the InGimp project, I couldn't have imagined that this
is what the result would be. We need to really get the data in from people using it on a day-to-day basis. So I think there are a lot of really interesting questions we have that will inform what our message will be two years from now. But they will only be answered through usage. So for example, you have this idea of this great red eye
reduction. This other person has this great idea. What happens? Do people get in edit wars over what the canonical tasks should be? Or do they fork it? And so we don't know what's going to happen. And we're really interested in it. And we want to be reactive in terms of the design
and design to people's needs. Yeah, so this version is collecting data just like InGimp. And the data can actually fold into the use of the software more readily or in very interesting ways. So we can list the types of tasks
that people have installed, which ones they're actually using. We can look at how long people are using a particular task set and post order task sets in that manner. So by collecting the data about how people are using it, then we can feed that into task sets, the exploration
of task sets, as you see here, and so on. Another question over here? And while the mic's getting over there, I should say that. So Ben mentioned that we already have a set of task sets. The task sets that we have are actually informed by Adam's work, where we looked at what people are
searching for commonly on Google. And so then we implemented those particular task sets. How many duplicate red eye removal task sets have you already got? How many duplicate eye removal? Red eye removal task sets have you already got? So I don't know if we have any for red eye removal, but we do have multiple for sepia toning a image.
Can I ask one? I love that there are all these questions, because then we don't have to show boring slides. Yeah.
Yeah. You mentioned that when you uploaded a new task set that you just created, edits to the wiki would not be pulled down locally. But in general, are these new task sets created by other users made available locally? Because that could help prevent these duplicates,
basically. If you search for red eye and there's already a red eye, there is no reason, well, there's less reason to create a new red eye task set. Right. Yeah. Do you want to answer that? So when you're searching in the search box. Yeah, go to the. Yeah, so just the in here.
So when you're searching right there, that's a live search against the wiki. And so also when you're making a task set, I think there's some indication of has someone already created a task set with a specific name. With that very specific name, we don't have it more sort of fuzzy to say, yeah,
though that would be something that we could mention. Right, so to speak a bit more about this model of task sets and like local versus what's on the wiki. When you're searching here, you're searching the wiki. And then when you choose one, it pulls it down from the wiki
and installs it locally. Right. Now there's this real question of if I make changes to my local task set, should the rest of the community see that? Right. And we said, no, because if you pull something down and then the next day you start it up and it's changed,
it's going to confuse you. You'll be like, well, wait a minute. You know, the tools I have here changed, right. That doesn't mean you can't sync it. So you actually have the capability. Can you show that? Yeah, I can. When you edit your local task set after it's been created, you have the option of syncing it with the current community version.
So it's an explicit step so that you maintain constancy with your local task set once it's created. So here we have the task set that I created earlier in the talk here. And what we have is a thing where
you could find in this list the latest version.
And that's the latest version online on the wiki. And then we've got this Sync button where you click that and you can sync it. But the reason why we made it so that you could display on the one side the commands in the latest version and then the commands in the local version, if you've added one command because you added
a couple commands to it because you like to supplement that task with a couple of your own commands, you don't want those to be overwritten in a sync. So the idea is to give you an easy way of looking at the current state of the community version. You can do manual adding of changes if you want,
or you can just click the Sync button to click it. So this is, once again, it's totally wonderful. And I imagine you've thought of this, but it would appear to me that there needs to be an option to join multiple communities and switch between them.
And for example, for some private community, me and some collaborators who work on similar things, then I would want the changes when I switch my GIMP to this, I'm now a member of community X. Then for this community, I could say, whatever change anybody makes, I want to have it now.
Does that make sense? Then I could switch out of this community and join the community where the changes are not automatic. Does that make sense? Yeah, no, it's a really interesting idea. So this links really well with the federated communities talk from earlier this week. Because right now, the only way to do this is by going into the code and changing a URL
and then recompiling. But you can point your adaptable GIMP towards any server that's running our wiki modifications and the right database and work with that. Because we did consider the thought where corporations might have workflows that they use for specific tasks, very strict guidelines, and they want to keep that within their own community,
that's fine. You just change the URL, basically. It'd be nice to have more in-depth support for that. I just want to congratulate you guys. The applause to leave? No, no, that was just like, yeah, you're gonna get a lot of that.
Yeah, this is really exciting. They say that the GIMP is notorious as a follower and not a leader. And I just think that this is really heartwarming. No, I mean, seriously, this is something, you could never imagine this in proprietary software.
And well, maybe we'll try to put it in. But we had it first, and we can brag about that. And I just wanted to, yeah, I guess, just technically, whether wiki is the most suitable for something like this,
in terms of it sort of being a little monolithic, like maybe a branched distributed version control system of some sort. So one of the things that we played with that I would like to explore a little bit more is if we have a structured representation for a task that's like an XML representation,
then maybe we can just have it embedded in any sort of media, a blog post, a wiki, multiple wikis, any sort of medium, and then pull from that. Especially if we start getting into having macros in that, there are some security implications,
but those could be overcome, and that's an interesting idea. I think that's one direction. So I mean, there are so many possibilities this could go in, or so many possible directions this work could go in. What's gonna be important is for you to keep in touch with us and say, I really need this, right? Because hearing from you is gonna help us prioritize
our efforts moving forward. So on behalf of the GIMP team, I just want to thank you and I'm going to provide a little bit of proxied schizophrenic feedback. We guys think that you guys are on crack, but it's good crack.
We're not quite sure if it's the right crack for GIMP. So it's like, but it's very interesting ideas and it depends on things that we want to consider some of it and it's very interesting to see research done in the way you do it, and it's also very good that the way you do it in particular in GIMP and adaptable GIMP, since it has previous issues
that it is not the official GIMP, but we're also sometimes slightly concerned with these forks. Not only this fork, there's also a lot of people doing interesting work based off GIMP, in that sometimes people do that on rather old branches, so it's very difficult even to integrate changes, but in general, thank you.
And you have a full endorsement, but that is also partly because you don't actually label it directly as this is GIMP either. So thank you. Thanks, Bevan. So I think we're over time.
You're also amazing. So can you just throw up like the... URL for the project. So adaptablegimp.org, and there you can find like contact information. Whatever suggestions you might have
for building up the community, please let us know. Phil's got something to say too. Very important. If you are good with packaging, particularly DBA in packaging, we would love to hear from you. Our package is horribly broken because I don't know packaging and I just tried to change it from the GIMP one, so contact me.
That and building for Windows were two huge time sinks. Yeah, my email and website are on the video page. We'd like to talk to them. But yeah, here's the information, and we will.