Sven wrote:
just a quick note to inform you that the usability weekend was a great
success.
Thanks. Inspired by the weekend I thought it was about time I
joined this list. Sometimes (but not always) I will chip in
to inject some interaction concept into the discussion here.
I have blogged
GSR wrote:
One question: creating original art, from 'found images;' is
creating original art like concept art or full illustrations, be it
realistic, comic, abstract... (that is what I understand for original)
using references; or do collages and other photo composition (that is
what I would
GSR wrote:
The scenario for this actually includes the words 'collage' and
'wild brush work' to catch the vibe. The results need to be new
art, and we are sure that bitmaps, scans and/or vector graphics
need to be imported/opened in GIMP to do this successfully.
What is wild brush work?
the
GSR wrote:
There are other apps for icons too (a from scratch task in some cases,
btw).
We are sure that icons will be first constructed as vector graphics
and then finished in GIMP.
Seeing that one and not seeing painting, colouring or creating
textures looked strange among all the other
CMYK I find most unintuitive.
The purpose of the CMYK selector is not to allow intuitive color
selection.
Actually, during the user observations we found out that
print-oriented professionals have learned to thing in CYMK.
So we need this mode for them.
--ps
principal user
Paul Gnuyen wrote:
I don't know what full specifications look like for tools in the gimp
but here's a shot.
The Polygonal Selection Tool
Selects regions by connecting points clicked with line segments
There is a cost (complexity, usage of UI bandwidth) to every
tool that is added to GIMP.
Sven wrote:
If you feel that it's too early for a string freeze or have larger
string changes pending, speak up now!
If you want me to sort out and simplify the crop and
selection options berfore christmas, then I need the freedom
to change any string displayed there.
--ps
Sven wrote:
If you feel that it's too early for a string freeze or have larger
string changes pending, speak up now!
If you want me to sort out and simplify the crop and
selection options berfore christmas, then I need the freedom
to change any string displayed there.
I mentioned that
Bart wrote:
So what about if GIMP could recognized what was the last used image
window and if you press a specific shortcut that woks only on the
image
window GIMP will call the command on the last used image window?
A very reasonable request. Although Sven is surely going to tell
us that
Well what do you know?
At the moment Kamila and I are very busy with our (interaction
architecture) expert evaluation of the current GIMP, and this
morning we happen to stop by the screenshot plugin.
We actually took into account all comments made in this thread
up to that moment.
Here are our
Peck wrote:
peter sikking writes:
P At the moment Kamila and I are very busy with our (interaction
P architecture) expert evaluation of the current GIMP, and this
P morning we happen to stop by the screenshot plugin.
[ ... skip to end of message ... ]
P I think that puts an end to any doubts
Akkana wrote:
I am an interaction architect, I have to take a decision what is
the best solution for 1 million users. We spend time evaluating
this feature systematically. We especially focussed on your
use case. But we saw the cost in UI complexity to put in the
second delay. This
Thorsten Wilms wrote:
I think the Save_Image dialog should just disappear
after use, as both Cancel and Help are available on
the second dialog and what else would it be good for?
Yeah it can go. It would only make sense if a Cancel on
the jpeg options would get you back to the Save_Image
Thorsten Wilms wrote:
If we try to do an all in one, then the result has to
look and feel like a dialog, not like a main window,
because of the modal nature (finish this first) of the task.
But this would not be like your common dialog that disappears
after Cancel/OK, but rather a window
Helmut wrote:
Painting with a brush is just a way to select an area. And a very
nice
and intuitive one also. The problem with the current
implementation is
however that it tries to heal while you are painting. This doesn't
quite
work. I think it would be better if, while you are
Helmut wrote:
Hal wrote:
I wrote:
that means we can use exactly the same interaction as the clone
tool.
This is exactly the way this works in photoshop and I can't think
of any
reason to do it differently. In fact this is exactly what I would
expect as a user.
Let me explain the
Mark Lowry wrote:
It would be useful to add a temporary magnifying
window that would provide a zoomed-in view of the
area immediately surrounding the cursor.
like this?
http://www.creativepro.com/img/story/20051219_fg5.jpg
assigned to a spring-loaded key (push down: magnifier
appears,
Steve Stavropoulos wrote:
I really _miss_ this feature! One of the things I do all the time, is
selecting rectangular regions from an image, with pixel perfect
precision and then copy + paste as new.
The important things in implementing something like this are:
1) You have to have an
Mark Lowry wrote:
Good point. A GIMP magnifier such as we are
discussing should magnify the actual image, not just
the desktop portrayal of the image.
Yes of course. Sorry not to have explicitly written this.
If a second, stationary window is used rather than a
moving lens, I would
Sven wrote,
GIMP already has such a dialog among the dockables that the user
can add
to their docks. The easiest and the most consistent way for adding a
magnifier view is to add it as another dockable.
easiest to implement, yes.
It should be pretty
much straight-forward to do that and
Sven wrote,
Here are some comments to get us started:
Resource management
This looks like a nice project but perhaps needs to be specified
better.
This needs a concept, to start with, which will roll out of the
evaluation project. It is more about where do we want to go
with brushes,
Alexandre wrote:
On 3/6/07, peter sikking wrote:
On-canvas text editing
Nice, but pretty much depends on the port of the display code to
Cairo. Perhaps concentrate more on rich text support instead of
focusing on the on-canvas editing?
I am not sure on canvas-editing
guys + gals,
thanks to Sven, the GIMP UI redesign team has now a wiki
where everybody can follow our progress:
http://gui.gimp.org
Right now we are filling it with our raw evaluation notes.
Some of the latest added stuff is so raw that you can track
us clarifying it a couple of days afterwards.
Chris,
First off, I want to apologize - it's not my intention to be
combative, and I can be a total ass sometimes.
don't worry, I am also fired up about this one. here is why:
people have talked to me a week or more ago on the irc along the
line of: what's the big deal, one way or another
Sven wrote:
I am not sure if Sven wants another feature request in bugzilla.
If so I will write it.
Yes sure. We have discussed the feature here and now we should make a
useful bug report from it. That will help to remember the outcome
of the
discussion and it might attract a developer
Helmut Jarausch wrote:
My current plan encompasses a few steps outlined below. Perhaps
I'll add
a quick mode which would be similar to the clone tool lateron.
I have no idea who we will help with a non-quick mode.
I see that this tool can be integrated in the clone tool,
for an interaction
Guys and gals,
For our presentation at the LGM meeting we would like to show some
results from our UI redesign projects.
To keep it interesting for the GIMP crew and the users in the audience,
I would like to centre this around the top-10 most requested features
in GIMP. You know the ones that
I would like to thank Bill and Raphaël for their help.
From the further deafening silence I take that the consensus is that
they hit the nail on the head.
See the results at the LGM, or as a download afterwards...
--ps
principal user interaction architect
man + machine
guys + gals,
for all of you who missed our presentation at the lgm,
I have converted the talk into blog entries.
The first part (of three) is online now:
http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-
overview.html
ps Alexandre Prokoudine: you can link to these as the
Sven wrote:
for all of you who missed our presentation at the lgm,
I have converted the talk into blog entries.
Thanks a lot. To give this a wider audience, perhaps you should ask
Mukund to add your blog (or just a feed with GIMP related posts) to
http://graphicsplanet.org/.
I already have
Thorsten,
Image window and Save Changes dialog turned into one:
http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/
Somehow I do not know what structural problem you are trying to
solve for one million users.
I am all for reusing the main window (save for web, preparing a print)
Thorsten,
http://thorwil.wordpress.com/2007/05/18/save-changes-integrated/
Somehow I do not know what structural problem you are trying to
solve for one million users.
The current Save Changes dialog tends obscure the image.
It is a modal dialog situation: we need a decision now.
The
guys + gals,
part two of three of our lgm presentation is online:
http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-
requests.html
--ps
principal user interaction architect
man + machine interface works
http://mmiworks.net/blog : on
Thorsten wrote:
10. better printing support
Paper, maybe better called media, could be handled as special kind of
layer that is restricted to stay below all image layers (unless hiding
stuff below it makes any sense).
Think workflow, not about highjacking a image concept (layers):
Thorsten wrote:
10. better printing support
Paper, maybe better called media, could be handled as special
kind of
layer that is restricted to stay below all image layers (unless
hiding
stuff below it makes any sense).
Think workflow, not about highjacking a image concept (layers):
Saul wrote:
Quoting peter sikking's weblog:
(http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-
overview.html)
ALSO NOT PAINTER
the focus for GIMP is to work with ‘found’ images;
I do not understand the reason for this restriction. Myself, I am not
a painter. I do
guys + gals,
the final part of our lgm presentation is now online.
whew, that turned out to be a long post to write, more pictures than
ever:
http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-
requests_25.html
ps: I am enjoying the feedback I am receiving, here and in the
Thorsten wrote:
On Sat, May 26, 2007 at 01:49:52AM -0300, Guillermo Espertino wrote:
Turning Gimp into a MDI application will make several users happy,
but
IMO it won't benefit Gimp at all.
As far as I got it, this is all in line with what Peter has been
proposing. Where MDI would be an
damianzalewski wrote:
What gimp is not:
not a web page mock-up application
I brought up web mock-ups, but we realised that seriously
supporting this would mean introducing a ton of functionality;
it is better done in a specialised application
I really don't understand what tons of
Sven Neumann wrote:
On Fri, 2007-05-25 at 19:03 +0200, peter sikking wrote:
BTW, the dialogs that you consider to be unnecessary can
already be
skipped using the Shift key.
Then the perfect solution is that we reverse the logic of that
shift key. Only with the shift key down the dialog
Sven Neumann wrote:
On Sat, 2007-05-26 at 16:50 +0200, peter sikking wrote:
The choice it to make either the dialog or 'no dialog' a tricky power
feature. I choose, without a doubt, the former.
I explained you why that choice is not acceptable. If you did not
understand my last mail, why
Henning wrote:
I can see good software-engineering reasons to want to eliminate
indexed representation internally, but from a usability standpoint it
will be a loss not to be able to restrict the possible color values to
a predetermined palette.
I see it as a boost for usability when this
Alexander,
I have read your concerns and can tell you that at the end GIMP
will work as you like to.
I would prefer to have this feature switchable with a checkbox
the development of the tools is not finished.
I have to move first here, updating the spec of this feature and
filling in some
David,
peter sikking wrote:
We do imagine that a set of website graphics pieces gets _produced_
on a single canvas, and when everything works well together
graphically, with a single 'cutting mask' all pieces are cut out
and saved in the right web format, in a single action.
I don't see
David wrote:
peter sikking wrote:
can you tell me what you mean with manual work needs to be done?
that can help us with our work.
Well the most common case is simply selecting a slither of an area
to be tiled as a background image.
yep, we expect this kind of stuff to be your daily
Liam,
actually right now I am specifying how the selection tools should
deal
with long, very narrow selections, with the web guys in mind.
Please don't forget other users :-) I routinely have a selection
that's, say, 10,000 pixels by roughly 40 pixels. This might not
be a usual case for
Sven wrote:
you have been working on an updated specification for the rectangle
tools in GIMP 2.4. The current state is here:
http://gui.gimp.org/index.php/Specifications
under construction, btw...
First of all, could you please move this specification to its own page
and link to it from
Sven,
On Wed, 2007-07-04 at 17:24 +0200, peter sikking wrote:
If I want to reach the
corner, I aim for the highlighted rectangle. But when my mouse
reaches
it, it turns out that what was highlighted as the target area is
actually a dead area and nothing happens when I click and drag
Sven,
On Wed, 2007-07-04 at 21:04 +0200, peter sikking wrote:
by using different graphics (stipple) we avoid that these two lines
are interpreted as showing corner handles. They don't.
Well, if they don't show the corner handles, what do they show then?
The exact area where the side handle
guys, what a thread.
I say that the solution for all this lies in treating these lossy
(my spell-checker proposes lousy) formats the same we are (gonna)
handle indexed mode:
import + export only.
This would prevent the misunderstanding that there is a continuous
lossless workflow for these type
Raphaël wrote:
I say that the solution for all this lies in treating these lossy
(my spell-checker proposes lousy) formats the same we are (gonna)
handle indexed mode:
import + export only.
Eek! That would significantly break the flow for what must be the
most common image format for
gg, my dear agent provocateur,
creating interaction requires making hard choices, because you
cannot make an application for everybody. For that you use the
product vision that you set as a team at the beginning of the
project. And then you don't fudge when the moment is there.
You make hard
Raphaël wrote:
creating interaction requires making hard choices, because you
cannot make an application for everybody. For that you use the
product vision that you set as a team at the beginning of the
project. And then you don't fudge when the moment is there.
I would like to temper this
David,
first of all thanks for taking the time to give us input.
There is one phrase here that I am not sure how to interpret:
I'm not entirely sure how I'd go about designing a website in gimp
to deal with this problem
The designing a website in gimp sounds scary to me because I then
Raphaël wrote:
let's see how short I can keep this.
We also have to be humble and remember that writing down the current
vision only took us a couple of hours, not 5 years (basically one hour
of discussion at LGM plus some e-mail exchanges while we were
polishing the minutes).
Two hours.
Akkana wrote:
I'm seeing an unspoken assumption in this thread that most photos
are edited in multiple sessions: read into gimp, do a few
operations, write to disk, read back in (perhaps hours or days
later), do a few more operations, write back out, repeat.
I was more thinking from the
Esteban!
we talked on the ixDa list before, remember.
design.I am studying Computer Science and Product Design,
happy to see you took my advice on the latter.
later planning to study and work in Interaction/Interface. I would
like to volunteer for the UI design of GIMP.
I am afraid that
Guys,
the fixed ratio/width/height/size functionality is optimised for
applying that constraint many times over a period of time (all day
long).
You set it up, then you use it for a while.
If you quickly want to set the width/height/size of the bounding
rectangle
then there are the width
hey Enselic,
(It was an odd time stamp on your mail. are you back from vacation
yet?)
suddenly I am in Kansas, on a very cool project for 2 weeks.
The spec asks for ideas for good default values for the Fixed: Size
entries.
yeah, the 100x100 is arbitrary.
How about having 100x100 as
GIMPsters,
before my holiday (1-8-7) there was this email from Esteban, asking
where
he could show his ideas for GIMP. In my answer to that mail I see that
I already used the words 'visual brainstorming.'
During my holiday I thought about it some more, how this could work
and a cheap (in
Guillermo,
It's a good idea, but I think you should add a little explaination
thanks for reviewing, I will add some.
and a
voting system (like digg's one) to get some statistics of the
degree of
popular aproval of each idea (but I'm not saying that the voting
should
be considered for
Guillermo,
Comment your idea text balloon style,
instead of writing that long essay in your email
Ok, but...
Balloons are good for a few comments but they tend to clutter the
image and obstruct the legibility if they're too much.
More complex ideas will require more balloons or more
Henk,
those verdomde licences.
On 11/09/2007, peter sikking [EMAIL PROTECTED] wrote:
I see this working in a visual way. Because of the CC-SA-BY license,
anybody could take your image, modify it with their own ideas for
improvement, and send it back to the brainstorm.
I see one problem. CC
Igor,
I like Gimp a lot, and using it for every day job. I want to repay
to Gimp community by giving advices for making him better and
faster for use.
we have the GIMP UI brainstorm for this:
http://gimp-brainstorm.blogspot.com/
please send your contribution there.
Thanks,
--ps
David Gowers wrote:
there is http://gimp-brainstorm.blogspot.com/ for working out the UI
(and http://www.mmiworks.net/eng/publications/labels/GIMP.html , the
precursor).
let me clarify a bit:
http://gui.gimp.org is the place where the interaction team works.
GIMPsters,
2.4 is out and I want to thank Sven, Martin and Mitch for working
with me on realising a substantial part of the select/crop tools
specification.
For me the transition into the 2.6 development cycle also marks
the start of where working on the UI revamp of GIMP will be
more strategic,
hi all,
let me see what since friday has been said (UI-wise) concerning
the roadmap.
Martin wrote:
I suspect making use of Cairo won't impose significant changes to
the spec?
Well it does, because instead of the current 1-bit (invert) graphics
for displaying the UI on the canvas, we could
Esteban,
Hi all,
This is the 2º draft for the 1 Dimensional Menu:
http://www.zensui.org/IxD/1DM.html
in your honour we created the GIMP UI brainstorm:
http://gimp-brainstorm.blogspot.com/
please post your idea there.
On another note, is a new mailing list dedicated exclusively to
Chris Mohler wrote:
Sven Neumann wrote:
Currently we are drawing the rectangle using XOR. When we switch to
Cairo this should probably change. But I am not entirely sure how to
best draw a nice-looking outline that is visible on all images.
Perhaps
some of the artists out there could draw
Sven Neumann wrote:
Michael Grosberg wrote:
My second suggestion - I think it was discussed before - is to
switch the
functionality of the add layer button in the layers menu, at
least as
an option:
click will create a new empty layer, shift-click will open the new
layer
dialog.
I wrote:
I do take the hart of the matter [...] serious.
really, I did not mean an adult male deer,
I meant 'the heart of the matter...'
--ps
founder + principal interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction
Sven wrote:
So could we please stop talking about
some completely irrelevant article and instead deal with the actual
problem? Thank you.
since I am responsible for this 'department', I do want to say
something, but I'll keep it short.
I do take the hart of the matter, which is behind that
Michael Grosberg wrote:
Very simple: Peter has a blog, right? and very occasionaly, he
posts something
relevant to the Gimp UI, such as the post about the print dialog.
uhm, the print dialog stuff is for openPrinting. That project plots
the future of printing for all linux desktop systems.
GIMPsters,
I was away for a couple of days and I see that in the mean
more task were volunteered that have an UI impact:
* metadata stuff (jpeg dialog)
* iWarp tool (right-on Tor!)
* jitter and smudge
and something about text (layers), that is not so trivial in the UI btw,
text, svg and other
Sven wrote:
* solve user request #1, part 1: one menu bar, keep window with
menu bar open when no image is open, true floating inspectors,
transparency where inspectors overlap the image (found a way
how it can be faked);
I don't think that true floating inspectors are
Sven Neumann wrote:
Alexandre Prokoudine wrote:
I'm not sure this is the right time and place to argue, but from my
experience using Paint.Net, which has this functionality, transparent
palettes will absolutely useless and even annoying.
I agree. Transparency will be distracting.
counter
Sven Neumann wrote:
well, obviously where one works with colors in the inspector that
part is either never or on mouse-over not going to be transparent.
Where we are back at the point where this is not likely going to be
ever
possible on all supported platforms using the toolkit that we
Sven wrote:
On Thu, 2007-11-08 at 00:06 +0100, peter sikking wrote:
Where we are back at the point where this is not likely going to be
ever
possible on all supported platforms using the toolkit that we use
and
will continue to use.
I am used to development teams telling me 'can't do
Alexandre Prokoudine wrote:
Here is the list of proposed changes in 2.6 that Sven asked for:
Tools
- full use of cairo for the select/crop tools (?)
- color-neutral toolbox icons that are quick to recognise and work
with (?)
The ? character after a name means that exact intentions of
resending...
Sven wrote,
On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote:
One other smallf eature I will want to add is the ability to add
free- angled
guides. I have this almost complete on my codebase, just .XCF
saving for it
is missing. I should commit that early on 2.6
Sven Neumann wrote:
On Mon, 2007-11-12 at 08:29 -0500, Henk Boom wrote:
- vector layers (Henk Boom?)
I would be glad to continue work on this
Before we add this, we should get some feedback from the UI team.
Well, this topic is not so clear cut. There are many factors:
- the relationship
William Skaggs wrote:
I've been working on using the new rectangle tool interface
to allow changing the shape of a text layer by moving edges
around.
Sven suggests, and I agree, that it would be good to have input
from the UI team before making changes to SVN trunk, hence
this email.
When
Tobias Jakobs wrote:
On Dec 6, 2007 2:10 PM, peter sikking [EMAIL PROTECTED] wrote:
When 2.4 came out, I made a statement that that day was also the
end of fire brigade mode for the UI team. So can we do this in the
right order please:
That is only fair and I think the results will be better
GIMPsters,
This Wednesday (12‑12‑7) I will be presenting at the newthinking
store in berlin. It’s berlin‐usability‐stammtisch‐Wednesday
and I will do a lecture on GIMP, open source and interaction
architecture.
Apart from the announced focus on the run of the GIMP redesign
project thus
Hi all,
chiming in here (getting back to speed).
There are some traits that make Bill's idea obsolete. First one
is the hierarchical organisation of resources. A tagging system
allows multiple ways to find a resource again (instead of a unique
one) by attaching many different properties to it (a
Hey all,
sorry for fading out of view for a while. demanding projects
(ongoing), a big flue and christmas got in the way.
but that is just part of it.
The other part is the lack of a roadmap. the lack is now so
that I was prepared to write one myself, just to have something
to work with. But I
GIMPsters,
a couple of more things for this year:
First, Sven was right at my GIMP lecture last month here in berlin:
the UI team needs to grow. So I want to add two more UI professionals to
the team (double the size!). One more experienced person (3-5 years in
interaction design) and one junior
Sven wrote:
I think you misunderstood Peter's talk. These are the top 10 user
requests, not the top priorities. It is very important to analysize
user
requests but it would be wrong to use this list as the basis for a
discussion about the future roadmap. This should happen based on the
Sven wrote:
Merge toolbox and image menus
It would be very nice if we could get this done for 2.6. It
would be
a major user-visible change and as such it would give a clear sign
that GIMP is moving. What's needed here is a mockup that shows how
GIMP should look like with no
Sven wrote:
On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote:
and oh, note that the slider to set the alpha of what goes on in that
window will be there anyway...
This is not currently implementable, so I would rather not base the
spec
on this opacity slider.
just to clarify
GIMPsters,
I am very busy, so I am going to weed out the actual contributions of
y'all and respond to that:
Sven wrote:
We absolutely need to find a solution here that works for everyone.
very well said. that's why the gimmicks section is in the spec.
Thorsten raised a good point about the
Tobias Jakobs wrote:
I thought about it and I created this mock-up:
http://hagemaenner.de/stuff/gimp/PlanB/6.png
In the center of the area I've added a simpel text Drop Images
here to
open them. (Perhaps a native speaker should change the wording.)
I have been moving in the same
Bill wrote:
I have been experimenting with ways of simplifying the user
interface, and
one very simple change that I think gives a rather dramatic
improvement
in appearance is to remove the relief from the buttons that
appear at
the bottom of numerous dialogs. This is a request for
Bill wrote:
peter sikking wrote:
There are some deeper problems with those buttons (why are they
there,
allt the time, so prominently?), the ones in the layer dialog
excepted.
I agree with this. I too think it would be best to have buttons only
for the layers/channels/paths dialogs
Bill wrote:
It seems to me
that the separators are not that important, because the categories
are pretty artificial in the first place, and were really imposed
mostly
to give the very long list some structure, as far as I can see.
But this
is something that you should consider.
OK guys,
here comes the moment where I have to cut the crap.
Just like Sven or Mitch cut the crap when users keep discussing things
that are technically not possible, I have to cut the crap when we keep
discussing interaction that simply does not make sense.
That is why I listed the gimmicks at
sending this again:
Sven wrote:
Anyway, this is something that the UI team should specify. I hope that
we will get some more input from Peter on this soon.
after being drowned in work, I have time in the next days to
wrap up this spec.
writing a GIMP blog entry right now
--ps
Sven wrote:
Anyway, this is something that the UI team should specify. I hope that
we will get some more input from Peter on this soon.
after being drowned in work, I have time in the next days to
wrap up this spec.
writing a GIMP blog entry right now
--ps
founder + principal
GIMPsters,
some good news on this front, I have spent a couple of man-days
rethinking and re-specifying the ‘no image’ window situation.
It is now roughly complete:
http://gui.gimp.org/index.php/No_image_open_specification
If wrinkles need to be ironed out, let me know.
The further fall-out of
hey GIMPsters,
let me give you an update here.
in the last 10 days the concept and spec has matured quite a bit.
the feedback and plain old bug reports, both here and on the IRC
went into what is being built right now.
check it out when you have the chance.
thanks,
--ps
1 - 100 of 268 matches
Mail list logo
