Re: [Gimp-developer] it is time...
Simon Budig si...@budig.de wrote: Peter, thanks a lot for the work you have done for the GIMP. Simon, thanks for believing in what we did and even fighting for it. I hope we'll meet on the next libre graphics meetings, you seem to be involved in the metapolator project so there is a chance of hearing more from you :) I am doing a Metapolator talk at LGM, about designing UI for creative pros. I look forward to seeing you all there, with a new kind of peace in our hearts. --ps founder + interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] clean-up project
Joseph wrote: A horizontal tool option bar between the toolbox and menu bar is definitely handy as far as accessing properties settings is concerned. I was thinking about that, and then I realised that I am not exactly sure what you mean. do you mean that what is right now in the tool options panel should be layer out in a horizontal bar? --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Move tool
Alexandre wrote: Recently someone pinged me (again) about a certain inconsistency that I've seen affecting a considerable amount of users: that the Move tool doesn't move contents of selections. Frankly, I don't understand the logic behind this myself. Selection tools are for selecting. Move tool is for moving. But we made moving contents of selections part of selection tools for some reason, and we made this as non-obvious as possible. It looks like we assume that users actually read whatever is displayed in the status bar and do try various combinations of Shift, Alt, and Ctrl to see what happens. Clearly, this isn't working: I've seen users trying the (subjectively) logical way to use a selection tool to select, then switch to the move tool to move, fail, and give up. What does the usability department think of this? :) yes, first one gets the basics right: Selection tools are for selecting. Move tool is for moving. simple enough and a core convention in GIMP is that that avery operation (move in this case) is masked by the current selection. that is the basis to start from. on top of that it makes sense for a tool for ‘intense work’ like GIMP to build in some power cross-pollination for some straightforward operations: - so it is right that as an extra power mode the move tool can move the selection (the mask, not the content). - less logical, but still possible: as an extra power mode the selection tool can move the selected content. (less logical, because a further set of basic operations can be assembled that could get the same rights; e.g. immediately the question comes up why an extra power mode for resize is not there too) Michael Grosberg wrote: Another related issue though is moving a selection outside (partly or fully) the layer boundary. currently the selection content simply disappears. It would be nice if this somehow enlarged the boundary. with the current system of explicit layer boundaries, it is 50–50% whether the layer boundary should clip the content or be extended itself (just a competition of use cases). when we move to system of automatic layer boundaries (something I have encouraged for a long time), aka simply no layer boundaries, then the issue is solved by itself (the canvas size would clip material when exporting, however). --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Blend Tool UI
Michael wrote: hint: please do not make the endpoint handles small; think generous (more tens of pixels than single digits) and also show where the exact endpoint is in the centre of the handle (say, with a cross to aim). I had been imagining selection handles that are simply filled circles. In my early prototype, they look like this: http://i.imgur.com/t4g1zOE.png I think they are big enough, but they don't really show the exact location of the endpoint. I guess I'll need to experiment with this more. sorry, they are not big enough for the speed of working that is required of a tool like GIMP. remember, at that moment all that counts for users is reviewing the gradient and adjusting it. - you can drop the line because the gradient is there to represent itself; saves on clutter. - make the control points big (30–50px diameter) and essentially transparent; clearly mark the centre where the co-ordinate is. Maybe drawing circles most of the time, and then hiding the circles and switching to crosshairs while dragging the points, would be good? the alignment of the endpoint with the underlying content needs to also be reviewed when not moving the point. * The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked shaped) should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool. as far as my thoughts go: there will be more working with (vector) shapes in the future, and modifying those shapes with a gradient fill (by the gradient tool) could be the way to handle that. Hmm, you might have misunderstood what I meant by shapebursts. The shapebursts are special gradients that mimic the shape of your selection (currently labeled Shaped (angular), Shaped (spherical), and Shaped (dimpled)). Anyway, at this point I'm really conflicted as to what should be done with them. I'm not sure whether they belong in the blend tool or not right now. OK, I should have consulted the manual and now I have done it. I am now completely convinced that the shape burst belongs in the gradient tool. there is nothing contradictory about that. the gradient tool applies a gradient fill (as everything: modified by the selection) and Shape is a fill ‘mode’. and when talking interactive: next move would be to control these funky fill shapes on the canvas with a handle or two. Ofnuts wrote: good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_ This would be updating the gradient while using it, but a gradient can be much more complicated than one color at each end. And what do you do with gradient colors that are not explicit but bound to FG/BG colors? well, I imagined straightaway that the endpoints would be highlightable and then modifiable through the regular color selection dialog(s). this point - that (adjusted) color a more complex gradient is defined by ‘waypoints’ on the canvas, while working interactive, the position where these waypoints fall on the gradient can be shown. then each of them can be highlighted and color-adjusted. when the points are there anyway on the canvas, users can move them, in 2 dimensions. and gee, once you got that. users can build a complex gradient out of nothing by: - starting with a begin and end color; - set up a multi-point path (click, click, click, double-click or return; to begin with: a straight-segment path; intermediate colours get interpolated, based on distance along the path) - update the points’ position and colours; - commit (another double-click or return). if this overloads Michael: you can introduce this step-by-step. I like where this is going... --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Blend Tool UI
Michael Henning wrote: I'd like to make some incremental improvements to the blend tool. On IRC, Alexandre suggested to get the UI team involved, so I'm looking for feedback/advice from the UI team. let’s see how I can help you. Here are my general plans: * I'd like to make the blend tool generally more interactive. By this, I mean that after the user has created a gradient, they will be presented with handles that they can use to modify the endpoints of the gradient before committing their changes. good plan. combine it with updating the colours of the endpoints to make it truly adjustable to get it _right_ hint: please do not make the endpoint handles small; think generous (more tens of pixels than single digits) and also show where the exact endpoint is in the centre of the handle (say, with a cross to aim). * I'd also like to add a live preview to the blend tool so users can preview the gradient and experiment with different options, before committing their changes. yes, vital for making the previous point work. please make commit an implicit thing (moving on to another tool, starting another gradient) combined with explicit (e.g. return) as a backup. see handling of committing selections in the rectangular selection tool. * I'm also planning to add undo support within the tool. I hope you mean: step-by-step undo while not committed, after a commit undo the whole committed gradient. again: vital, to make other points above _really_ work. both for the interactive part and as a form of non-committing * The general consensus within the dev team seems to be that the shapebursts (all of the gradient types currently marked shaped) should be moved out of the blend tool. They would likely be moved into either a menu item, or (maybe?) within the fill tool. as far as my thoughts go: there will be more working with (vector) shapes in the future, and modifying those shapes with a gradient fill (by the gradient tool) could be the way to handle that. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Getting contributors via OpenHatch
scl wrote: And: contributions are not only coding. For example user support, bug reporting and triaging, documentation, translation, contributing high-quality assets, test and constructive user feedback/domain guidance, website maintenance are also contributions and they don't need knowledge of Linux application development. damn right, there are so many more ways to contribute. a structure for making sense of this: - define as a project which types of contributors we need to attract - be realistic, for each of these groups, about - which skills they need to bring (re building and code) - on what installation (latest release, or daily build?) they need to be - do they really need to build something as part of their contribution process? - evaluate what is there right now; note what is crummy and what is missing. then you know what needs to be done. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Creation of a set of operations item
hi all, Joao asked me personally to comment here, so here I am. I will do some horrible top-posting because I think I can summarise quite a bit what you wrote. I believe what you refer to below are ‘macros.’ simple enough: at any point in GIMP where an operation can be applied, a macro can also be applied. I intent to help GIMP users to make/edit macros in many ways: record them; grab a bunch of operations from the operations stack and put a name on it; write some source text in a file. do keep in mind that macros are nothing but a convenience for some GIMP users, not all GIMP users. a macro is never the single solution to a problem. first working with operations (see http://blog.mmiworks.net/2012/01/gimp-full-gegl-ahead.html for an old sketch, will be updated at lgm) has to work in a sufficient fashion before we can think of introducing macros. ps: first we would have to start supporting ‘export pipelines’ where users can define a series of operations for each pipeline, and save these to be used in different xcf files, before macros could be used in these pipelines. users should not have to learn macros to make use of these pipelines (a macro is never the single solution to a problem). Hi, I would like to discuss about the possibility of a Set of operations GIMP item - In the current state of GIMP, I think one nice thing to have would be the ability to specify sets of GEGL operations that could be re-used across the UI in some different places. One example of such Set of operations could be, for example, a gaussian blur filter - the set includes the parameters as well. Another example could be a Resample to 50% size, Unsharp mask set. Where could those be used? I thought of primarily two places - with more potential nice places to come along: 1. As an adjust layer - just that - have a special Layer class that encapsulates a set of Gegl operations, and apply then to the rendering of the layer imediatelly bellow. This would give us Adjustment layers as they are called in other software, essentialy for free 2. Attached to an image, as a set to be automatically applied before exporting the image to an specific format. Currently, the merge-visible-layers action is performed at this stage, for most formats. But in some mail-threads here it became clear that the ability to resize an image to an specific size, among other things, could greatly simplify the current workflow for keeping a high-quality XCF image, and exporting incremental versions of down-sampled/filtered versions for production. (Like in edit, save, resize to 50%, export as PNG - undo to further editing the image, and the resize is lost, and must be reapplied when exporting the new version) And there could be some bonus places to attach these sets of operations: 3. To patterns, before applying them - so that rotation and scaling of patterns would be easy 4. To brush masks, as part of the painting dynamics. Can we discuss this further along? I know Mitch is experimenting with operations attached to layers, but I don't know wether they are along thse lines, or more like recording all operations mad in a layer, in an early quest to non destructive editting. Maybe there is a roadmap for a similar thing already, that I am not aware of - but having the sets of operations behave as regular GIMP items that can be used - and being able to pick/create then at the layers dialog bucket fill tool options, export dialogs, could be a nice way of enabling the possibilities of GEGL and non-destructive editing to end users. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
On Jan 29, 2014, at 23:04, Michael Natterer wrote: All discussion aside, I have promised the guys that this would go in a long time ago, and just needs some cleanup. then it was a complete waste of my time and expertise to get involved. it should not have been asked, if no one wanted to know anyway. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Mitch wrote: I really don't know where the problem is here. now that I was asked to get involved, read the spec and made an analysis, here is what the problem is: TITo, as it stands today, is a UI subsystem for which it was never decided whether it was a search/help system or a command interpreter. trying to be both, it is simply substandard at either tasks. (yes, there is a hard trade-off between the two: a search/help system must be compassionate and forgiving, mapping a large set of search terms to a range of answers. a command interpreter has a tight, _designed_ command set whose only goal is to get users as fast a possible to one unique command to invoke.) since it is a 100% UI subsystem and I am involved anyway, I realised that the only thing I can do is to help the makers step by step to get TITo into a shape that makes sense to release. (OK, the other thing that I can do is to refuse that this goes into GIMP, but that is not constructive). we are at step one which is simple and hard at the same time: define what TITo is and why it makes sense in a GIMP context. already a couple of surprises came out of the woodwork, information that was not available to me before. for the rest it is slow going, ‘why does it make sense in GIMP?’ seem to be a fresh question, where the answers still need to be found. up to now various people have offered a lot of tautologies, and the fact that it has been implemented in completely other contexts. that is not convincing at all. also that answers from everyone have a different view on whether it is a search/help system or a command interpreter. this reflects exactly the jumbled state TITo is in. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Jehan, please read again what I wrote: let me first of all say this in general about the process we are doing. at this moment I feel we are still working backwards, i.e. you are answering to me what the code does. we have to work forward, else there will be no progress. this means we write down the goal/purpose/vision that you have for TITo (sorry, internal code name still rocks for discussions). you make the choices, I just make sure that what we end up with 1) makes sense in GIMP context 2) is internally consistent 3) is short, sharp and complete once we got this goal written down, it is possible to review the spec to see what is missing and what is getting in the way of the goal. now it would be good if we actually start doing that. On Tue, Jan 21, 2014 at 12:47 PM, Michael Natterer mi...@gimp.org wrote: action is meant as technical term here. A menu item is a view on an internal action, and they include: - all menu items - all tools - all menu-invokable dialogs - some esoteric stuff which we'd probably filter out to avoid confusion Indeed. if I read that right it still boils down to that you only want to search menu items. this needs to be called that way for clarification. No. As said above, actions are *not* just menu items. There are a wide list of commands that Mitch listed above. aha, that was completely not clear. now if I am wrong, and you do want to be able to search more like am the ‘actions’ in the dockable dialogs (example: Brushes dialog-Create a new brush) then you need to make that clear explicitly. Well, yes. We made it clear by saying we search all actions. :-) actions are a means to an end. we are in the process of clarifying the ‘end’ here, not the means (picking the means comes later). so now we better get busy. the word ‘actions’ is now loaded as an internal implementation detail. to avoid confusion, it cannot be used in a goal definition. you could take the wide-ranging option and say: ‘search all that users can perform and change in GIMP’ or get specific and make a complete list (‘types’, not ‘instances’) of what you want to be searched by TITo, for instance: - all menu items - everything that can be performed in dockable dialogs - all tool options - all operations tools can perform on the canvas - all settings in preferences and co. it needs to be in language that gets the point across exactly, without the reader being required to be a GIMP developer. it is better now to concentrate on _all_ the reasons you want this to be useful for GIMP users. now is the time for you to decide whether ‘when one knows they exist but can't find anymore’ is the one and only reason TITo is valuable/useful for GIMP users. if there is more, you have to clarify that mow. No it is not the only reason. This was more an example, thus an error on my side to cite here. The real goal is «searching and running» actions. And this by itself contains all the reasons I think it is useful for. Now searching can imply a lot of sub-reasons. yes, and we need to get these reasons on the table, because without them there is no point in introducing the tool (and certainly not claim a keyboard shortcut). The «I know this action exists (because I used it before, for instance) and I want to find it again» would indeed be a typical one. and here is where some QA form my side has to start: Another would be «I don't know GIMP by heart, but I know graphics editing, and there are usually blur effects. So instead of going through endless menus, I open the search and type blur and search through the 3/4 results I get». (first of all I think all blur examples have to be banned. there is nothing to search about blur, it is under Filters-blur, end of story. if it is not clear that it is to be found in the Filters menu, or as a toolbox tool, then this user needs an introductory course in GIMP, which can (today) only be delivered by a web browser or a book.) anyway, GIMP is a designed to be a tool for masters, or for users on their path to become a master (beginners, intermediates). any other use is not considered when designing the UI. so if someone comes to GIMP (s)he is either a master in another graphics app, or not. in the latter case (s)he can be considered and helped, as a beginner or intermediate GIMP user. from this there are 2 conclusions: - we really need to talk about how you envision TITo being useful for GIMP masters, beginners and intermediates; most of this will involve learning to use GIMP; - that leaves only masters of other programs coming to GIMP to consider in this discussion. since they are masters in another programme the will hate not being all-powerful in GIMP. so they will want to master GIMP as fast as they can (think of it as grokking). - for all the terms that GIMP has in common with other graphics programs (blur, dodge, fill, paint) the value of searching for them will be nearly zero, they are placed where
Re: [Gimp-developer] Search Action dialog feature
Sven wrote: look what I found in the former Google Summer of Code ideas: http://wiki.gimp.org/index.php/Hacking:GSoC/Future/Ideas#Make_menus_searchable I think it could perhaps shed some light about the Action Search Tools purpose and further treatment, at least it's an attempt. I think both the intentions of the developers and the code have moved on a lot from there. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Jehan, let me first of all say this in general about the process we are doing. at this moment I feel we are still working backwards, i.e. you are answering to me what the code does. we have to work forward, else there will be no progress. this means we write down the goal/purpose/vision that you have for TITo (sorry, internal code name still rocks for discussions). you make the choices, I just make sure that what we end up with 1) makes sense in GIMP context 2) is internally consistent 3) is short, sharp and complete once we got this goal written down, it is possible to review the spec to see what is missing and what is getting in the way of the goal. On Tue, Jan 21, 2014 at 12:47 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2014-01-21 at 00:10 +0100, peter sikking wrote: 1) you say “action search tool.” is it not menu item search tool? an _action_ search would search the toolbox tools, the layer stack and all dockable dialogs too (the latter being super useful). action is meant as technical term here. A menu item is a view on an internal action, and they include: - all menu items - all tools - all menu-invokable dialogs - some esoteric stuff which we'd probably filter out to avoid confusion Indeed. if I read that right it still boils down to that you only want to search menu items. this needs to be called that way for clarification. now if I am wrong, and you do want to be able to search more like am the ‘actions’ in the dockable dialogs (example: Brushes dialog-Create a new brush) then you need to make that clear explicitly. 2) you say “natural language text,” the definition of which is very wooly. similar as with ‘Text-based Intent driven Tool’ it promises way too much (e.g. user types in “blown highlights” and TITo responds with “burn tool”). you need to be very precise in defining how sophisticated you want to be here (want to be, not describing the actual bit you do right now). Please let's forget about the name TITO, it was a bad choice to begin with. Yes! Please all, stop saying tito, especially if that confuses you. TITO does not exist. This is an action search. I am not confused. you said “natural language text,” and I told you that is a huge can of worms if you put that in you goal. I think it is best to say “text search” for now. interim version: “The action search tool allows to search for, and run, menu items via text search. It is for searching tools, plugins and filters in GIMP when one knows they exist but can't find anymore.” it is better now to concentrate on _all_ the reasons you want this to be useful for GIMP users. now is the time for you to decide whether ‘when one knows they exist but can't find anymore’ is the one and only reason TITo is valuable/useful for GIMP users. if there is more, you have to clarify that mow. thanks, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Jehan, thank you for making this step. with some effort from me (moderating) and some from you (making clarifying choices) we will have this thing shaped. it will just take an email exchange. allow me to summarise what you said: The action search tool allows to search for and run commands in a natural way (with natural language text). It is for searching tools, plugins and filters in GIMP when one knows they exist but can't find anymore. (you see I removed everything that is not in GIMP context, they do not mean anything. context is _everything_ in interaction design) the statement above is not precise enough. so I am going to ask some questions to get us there: 1) you say “action search tool.” is it not menu item search tool? an _action_ search would search the toolbox tools, the layer stack and all dockable dialogs too (the latter being super useful). 2) you say “natural language text,” the definition of which is very wooly. similar as with ‘Text-based Intent driven Tool’ it promises way too much (e.g. user types in “blown highlights” and TITo responds with “burn tool”). you need to be very precise in defining how sophisticated you want to be here (want to be, not describing the actual bit you do right now). there are more questions, but these only make sense when you have answered the two above. thanks, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Sven, I appreciate that you want to mediate to make things go forward. Srihari has brought up this topic often and informed about the progress. Many people, including Peter, joined the discussion and the purpose was already discussed. So, many things are not really new. as things stand right now, the biggest thing that is wrong with TITo is that there seems to be no underlying purpose. lacking this it is a rather jumbled combination of features, which exactly expresses this purposelessness. if the purpose of TITo is so clear, then tell me what it is, including a few words why it is valuable for GIMP users. (anybody can contribute to this, it is just that Srihari and Jehan have to the final say on this definition, that is the right they earned by putting in the bulk of the code contribution) I give you an example, so you know what I am asking for: ‘the Undo system is valuable to GIMP users because it allows them to proceed without fear (of doing something wrong).’ you see I defined Undo not by its functionality, but by what it means to users. people have already asked me: ‘just say what should be changed about TITo.’ I can tell you, once I know what it should be. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Srihari Sriraman wrote: So yes, to a good extent I think I stirred up the cross cutting intentions, feature muddle for tito. Sorry.. G,DR ;) this matches what my conclusions is about TITo (having an internal code name that is as snappy as that is a good thing): moving goal posts up to the point where the completely vanished. However, we have come a long way since then, and Jehan has helped pull this together. Realistically, tito is what it is today. An action search dialog. I see you are trying to make it through step one of the structured process that I contributed, as part of making it possible that TITo actually makes it into a GIMP release. ‘An action search dialog’ is a pure functional statement, it does not express why GIMP users (that is the context, read http://gui.gimp.org/index.php/Vision_briefing to get in tune with that context) would find it valuable, and would bother to use it. it just takes a few extra words to express that. once you have completed step one, step two and three (rip out what does not belong there, and design that what makes TITo useful for GIMP users) becomes so much easier to define. sit down, think about it, and take step one. good luck, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Tobias Jakobs wrote: the problem with TITo is that as it stands now it is a conflicted mix of two intentions: 1) a help system via text search to learn using GIMP 2) a command-line system for operating GIMP Can you tell us which feature is 1) and which is 2)? I think you are proving my point. it is TITo, trying to be both. some note: - yes, for me 1) maps to ‘give these guys a break’ and 2) to ‘completely misguided’ sort term _and_ long term; - if you are serious about “Text-based Intent driven Tool” then you have to build a synonym list for all keywords, in all localisations; else you are just bluffing; Why? All command lines I use (Windows Start searchbox, Gnome 3 searchbox, Firefox Actionbar, the Terminal, a searchbox in the ERP-System at work) work nice without a synonym list for keywords. I think a synonym list could even be annoying, because it could give me too much search results. because it says “Text-based Intent driven Tool” not “a command line where you have to learn the ropes before it gets useful.” (see my other mail for the main point that we should be discussing; it does contain quite a few examples that you are asking for, I think) - if anyone is serious about solving how to help serious GIMP users with faster use of plugins and other sprawling stuff, let me know; it can be designed... I'm not a programmer, but I'm interested in the solution you would provide. the problem is concentrated on the plugins and GEGl operations. so what I am thinking of is a (maybe radical) redesign of the Filters menu. with the following goals: - faster and surer (slip of the mouse with sub-menus) invocation of all plugins and GEGl operations (and browsing them); - right-sized lists of recent items, recent items with values; most used items, favourites (?), all for direct + fast invocation; - user configuration (dicey theme); - an accompanying dockable dialog, for those with the space my 2¢ --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Fwd: [CREATE] Only 3 days left to submit your proposal for LGM!
Jon Nordby wrote: Don't forget, we want you at Libre Graphics Meeting in Leipzig in April! I did both, signed up and submitted a talk. The deadline for submitting proposals to LGM is Wednesday 15 January. Please don't forget to submit your proposal for a talk, workshop or meeting here: http://libregraphicsmeeting.org/2014/submit/ If you are planning to join us at LGM this year in Leipzig, you are welcome to sign up: http://libregraphicsmeeting.org/2014/register --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Srihari Sriraman wrote: Have we had a chance to look into this? On Sat, Nov 30, 2013 at 11:06 AM, Jehan Pagès jehan.marmott...@gmail.com wrote: Hello Peter, Some time ago, a contributor developed a very interesting feature, allowing to search actions with natural language keywords (https://bugzilla.gnome.org/show_bug.cgi?id=708174). I have also written an exhaustive specification draft of the current implementation: http://wiki.gimp.org/index.php/Specs:Action_Search_Dialog This specification details the search algorithm, and the GUI interaction. OK, I have looked at that spec. then I thought about it for hours, and here is why: this thing is still giving me a serious stomach ache (I hope you guys realise that when something that is 100% UI gives me a stomach ache, that is quite significant) even trying to explain to you (and me) why this gives me a stomach ache, gives me a stomach ache. I could talk long or short about all its aspects, but I have decided to cut it short and tell you this about it: when I read the spec or think about TITo, this comes to my mind, second by second: ‘that is OKish, give these guys a break’ ‘that is awful, completely misguided’ ‘that is OKish, give these guys a break’ ‘that is awful, completely misguided’ ‘that is OKish, give these guys a break’ ‘that is awful, completely misguided’ ‘that is OKish, give these guys a break’ ‘that is awful, completely misguided’ so after hours of thinking I have come to this conclusion: the problem with TITo is that as it stands now it is a conflicted mix of two intentions: 1) a help system via text search to learn using GIMP 2) a command-line system for operating GIMP some note: - yes, for me 1) maps to ‘give these guys a break’ and 2) to ‘completely misguided’ sort term _and_ long term; - if you are serious about “Text-based Intent driven Tool” then you have to build a synonym list for all keywords, in all localisations; else you are just bluffing; - with different people working on it, I suspect they have different intentions, or are conflicted internally themselves; - since TITo is right now a random mix of 1) and 2), it is really not working for either intentions; things implemented for 1) get in the way of 2) (and vice versa); when I had me face-to-face meeting with Mitch to patch things up we did talk about TITo (that’s how big an issue it is...). I said: when a version of GIMP comes out with TITo in it and the press writes about it: “GIMP now has a command-line system for operate it” then we have a all lost, big time, because a million users then expect that this will actually make sense (and btw: I lose the most, because this is a pure UI matter) when the press writes: “GIMP now has a help system via text search to learn” then we have a chance that this will be useful for a good chunk of our users, some of the time. all this is not about what we tell the press for that release, this is about what TITo _is_, what it is designed to be. being a conflicted mix of two intentions is certainly not going to help TITo in any way. some more things that are very important: - even if TITo response time is instant, keyword formulation - typing in a text based interface is not exactly fast; please drop the ‘its fast’ argument; - I read in the bug report that peple are contemplating changing labels of menu items to help TITo to perform better; that is the most dangerous thing I have heard in a long while; - if anyone is serious about solving how to help serious GIMP users with faster use of plugins and other sprawling stuff, let me know; it can be designed... --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
On Jan 14, 2014, at 22:43, Chris Mohler wrote: On Tue, Jan 14, 2014 at 12:52 PM, peter sikking pe...@mmiworks.net wrote: - even if TITo response time is instant, keyword formulation - typing in a text based interface is not exactly fast; please drop the ‘its fast’ argument; And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type Win-key,c,h,r,Enter and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily. let me give an example of what I mean in a GIMP context (because that is the only thing that counts). if a particular user uses Layer-New from Visible regularly, then invoking it with a mouse from the menu will be nigh impossible to beat with TITo, even if TITo manages to have a unique 2 char code for it in the given localisation (fat chance). the time loss is already there before the / shortcut is hit because it takes mental time and effort for users to get to the point of hitting that key (and you and I and all other users do not record that time loss, because we are so busy figuring out the shortcut; this means none of us is a reliable witness where it comes to how fast this stuff is) Nor do I see adding a text-driven action/menu system as any sort of UI failure. or being in the least bit misguided. What's inherently evil about adding shortcuts to get things done? now that you ask: I would be misguiding one million users by saying on the record: here is a way to use GIMP, for intense use. And if some labels aren't clear in TITo, might they need to be looked at anyway - maybe they really are ambiguous or could be worded better? The couple mentioned in the BZ report seemed a little funky. I am happy to change a menu label for any good reason (that is helping users), but never to help TITo out (which is helping a mechanical robot). --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Quick-edit workflow
Jehan wrote: Just checking master, currently when overwrite is shown, export-to is not grayed out but it is invisible. That means that it is active and can be run if you know the shortcut, but you can't export from the menu (for people who don't know shortcuts, new or casual users, etc.). Is it intended? I feel like this is a mistake and that Export To should always show up in the menu. I could easily fix this. yes this is intentional. the spec says: ‘The shortcut for the Export menu item shall remain active and map to invoking the Export As… command, sneaky, but true.’ I have done this so that users who press ctrl-E by habit are not stopped by nothing happening. Users who browse the menu see Export As... (the new label) and pick that. nobody gets hurt. things work as expected. sneaky, but true. In any case, I have written a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=712192 I guess you can tell if that's good for you Sorry Jehan, no. you change too much and I must say, with devastating effect. first of all I did my job and updated the spec: http://gui.gimp.org/index.php/Save_%2B_export_specification checked 98 occurrences of “export” (twice) and updated to the new situation. in a nutshell, all it is is a string change. Export... - Export As... (no other changes to this menu item or the code behind it. “Export to” - Export (when no export target) (this is the menu item where “Export to foo.xyz” and “Overwrite foo.xyz” are swapped in as appropriate) do not touch the Save menu items, they work fine, as-is, since 1984. Save is for the main window content and the name of that is in the title bar of that main window. and that is it. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Quick-edit workflow
Jehan wrote: Should I change the action's names to follow their label? In particular Export would correspond to file-export and Export As... corresponds to file-export-as (otherwise we would end up in the strange situation where Export = file-export-to and Export As... = file-export). I think it is better that the action names migrate with it. but better ask mitch what the rules are for changing this. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Default file name for file-export action
Jehan wrote: Actually Mitch, our maintainer proposed something similar (see https://bugzilla.gnome.org/show_bug.cgi?id=712194). So we could have a default of IMG_38210-1.jpg for instance. please don’t. there is two reasons that I am against tampering with this: 1) when using Export As... (new label), there are 3 things that can be changed: the location (say, directory), the name, the file type (extension) 2 out of 3 times, the name does not need changing. 2) the same ‘danger’ exists for Save As... but I think we all manage quite well with that one. Yes yes, I know that I'm not the target user and I probably will have to end up using something like darktable or similar (even if I prefer geeqie for browsing, directories for organizing and gimp for editing) but I want to [snip] So you see! You are the target user! ;-) no that is not what we are doing with this. it does not mean that the non-savers are target users now. what we are doing is a renewed effort to take all the friction out of the non-saving paths for as much as we can (without throwing away the clear separation principle), for the benefit of all users. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Quick-edit workflow
Richard Gitschlag wrote: PS: Can we get some accelerator keys put on those menu labels sometime? apart from Overwrite (by design), where are you missing one? --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] about that student work...
Alexia wrote: so you can guess my new motto: ‘from the first week we start building the real thing.’ Developers work in iterations. When you start you have a vague idea of what its going to be, a goal, but you never know how it will make sense to reach that goal in the end. So you iterate, without polish and beauty you make a draft, test, make sure the framework is solid, etc and then go over it again. At some point you run into a fundamental issue and need to discard a lot of the underpinnings and the code above up to and including UI concepts. I am all for making UI from rough to polished. after an initial analysis phase (which takes place in the first 20% of my work) I can guide this, rough to polished, from the first week of implementation, because I know exactly what we have to achieve and where we have to go. the throwing away of non-working UI concepts happens on my piece of paper, not in code written at much greater expense (in time and motivation). but you (I mean: all GIMP devs) have to let me guide you. you have to accept and trust that I can ‘see’, ‘feel’ and judge a UI idea/concept in a minute without it ever existing in code or even a drawing. that I am able to tell you how it will work, for users, three months after the release of the software. that I can separate 977 bullshit UI ideas from the 3 that will work, and concentrate us on making the best out of them. you have to let me guide you and at this moment there is, I believe, no developer at GIMP anymore that lets him or herself be guided. It also means that you do not wish to spend time polishing things that might get discarded - the work goes from rough to good - from general to specific and in an ideal world, so would UI and interaction design. It would start off as rough guidelines and complete in a finished product... Sofar, we have tried to make it work in reverse - that the UI/interatcion is fitted on top of a ready bit of code like a mask. And in my personal experience... That does not work. I am happy you say that. it is encouraging. UI is not a skin/decoration of back-end code. UI is the realisation of the product, in this case the GIMP project. A lot of needs from product, technology and users put a lot of requirements on the UI, which I juggle in the design of it. you notice that technology is only 1/3rd of the picture; of my puzzle. and by my experience, the UI design has also an impact on ~33% of the back-end code. if developers refuse to harmonise this back-end code with the UI design (as happens now) then the devs are implicitly shaping the UI... It creates frustration for both sides, because we cant get the mask to fit and you feel that we disrespect your work... And that is truly unfortunate, because we really really need your insights and input and I personally believe it's of most use when it is given in form of concepts, rules, insights and diagrams rather than ready made bitmap expectations of how it would have to look... I am happy to develop and tune new methods of working, but it starts with trust. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] about that student work...
Michael Schumacher wrote: of course I can do this design, and that includes addressing both user needs and developer needs. nice to hear from you. but I do not want to have the same disappointing experience of SoC as I had in the last few years. in particular, I do not want to be confronted by either student or technical mentor with the following: - I did not expect the UI was going to be like this, This is, I'd say, expected - if everyone knew how a particular UI would have to be like, it would just be done that way. yes, it is solid ‘duh’ territory. so now we have a problem; I'm not sure how to read this correctly. After going over your mail multiple times, it seems more and more likely that this is meant as a caption for the following points, I'm going to read it as such. no, it stands by itself. Although it was clear that the developers did not know what the UI should be like when I started designing, they did seem to have made up their mind about certain things, especially about exposing technological things directly in the UI and doing things ‘like always.’ when I—to address the needs of the project, users and developers, and make every part in the design work together—come up with something that is different, then the developers get really antsy about their foregone conclusions. - first we going to put in some provisional UI, later we do your design This, however, puzzles me a bit. I'll exaggerate to describe my confusion: This means that no sign of any non-finished UI might become available to the public through GIMP code. The developers working on it would do so under conditions which border on an NDA, and only commit code to the public repositories once the UI has been completely finished. good that you discuss this, because it is not what I mean at all. I wrote about this in a recent blog post: http://blog.mmiworks.net/2013/05/design-lessons-with-daft.html (actually that post is a lot about working on GIMP...) ‘Quite often developers like to first put some temporary—and highly technological—interaction while they sort out the non‑UI code. The real design will be implemented later. Then time ticks away, the design lands in a drawer and the ‘temporary’ UI gets shipped. ‘I do not think this is a malicious trick, but it happens so often that I do not buy it anymore. The only secret to getting interaction design implemented is to do it in the beginning.’ thus it is about what the initial energy of development is spent on: some clutch or the real thing? because after the initial energy has dissipated, inertia makes that whatever is there is the thing that gets shipped. so you can guess my new motto: ‘from the first week we start building the real thing.’ these are not just demands, it also comes with taking more responsibility from the design side, basically co-mentorship. Going back to GSoC, and taking the limited time frame of the program into account, how is the sheer inability to finish the UI due to time constraints to be taken into account? this is exactly what you want to ask the designer, exactly because of the following sentence: when UI is compromised to make it happen, it better be compromised by the designer, who can see _all_ the dimensions. assuming an agile way of working (which many do a little bit these days), it all starts in the first week of implementation: as a co-mentor the designer selects the first aspects of the design that are to be implemented. the designer understands the state development is in so there will be no unreasonable demands. it is even OK to not develop UI in the first week or so. it is not OK to develop clutch UI. if a ‘testing’ UI needs to be made first, the designer will happily design this for the developers, in a matter of hours. of course it will borough a lot of the ‘real thing’, that is why it is quick to design. it also ensures that energy is spent in the right direction. when it is time for (horrible) compromises because of time or technology, the designer will make these. the whole point is that the needs of the project, users and developers remain balanced, and that every part in the (reduced) design keeps working together. that is what you have designers for. that is how I see it working. I hope you can see that this is hardly a ‘designers paradise.’ it is about taking responsibility. Just one thing there: The issue of what communication channels to use has not been solved yet. You have mentioned that you prefer not to use low-width channels like mail or IRC, but what should be used instead? in recent weeks I made a couple of tries on irc to contact Mitch about the following: to either meet in person when he is in berlin, or to have a talk on the phone. I expect we will need several of these. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture
Re: [Gimp-developer] about that student work...
I wrote: ps: I am blogging the results of 2013 right now. done. ‘how quaint, there is not enough functionality!’ http://blog.mmiworks.net/2013/06/teaching-interaction-13.html --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] about that student work...
Michael Henning wrote: I agree; it would be beneficial for our SoC students to work with an experienced UI designer. I'm not involved in the SoC myself, but if an interaction designer were to offer their time to help out, I'm fairly certain it would be welcome. In particular, some people on irc have raised concerns about how well the combined selection tool will turn out if only programmers guide the student. of course I can do this design, and that includes addressing both user needs and developer needs. but I do not want to have the same disappointing experience of SoC as I had in the last few years. in particular, I do not want to be confronted by either student or technical mentor with the following: - I did not expect the UI was going to be like this, so now we have a problem; - the back-end is already fixed. no, we are not going to change it; - I never thought about that, so forget it; - first we going to put in some provisional UI, later we do your design these are not just demands, it also comes with taking more responsibility from the design side, basically co-mentorship. when UI is compromised to make it happen, it better be compromised by the designer, who can see _all_ the dimensions. this is an invitation to start working again... --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] about that student work...
Tobias Jakobs asked me in a comment on the blogpost http://blog.mmiworks.net/2012/05/teaching-interaction-12.html ‘What does this mean for the Gimp team? Is it a good idea to use one ob this to redesign the tool or does it need more work?’ I answered: ‘Good question. One has to value this work for what it is, student work from a class that ran one week. ‘One the one hand a certain part of GIMP—in 2012 seam carving—that has never received any interaction design thought, gets methodically worked on by 3 or 4 teams of talented designers. The results are a shot in the arm for GIMP. ‘On the other hand a week is very short and for the students it is their first introduction to interaction design. Thus the presented results are alway an _inspired_start_ but not complete and deep enough for implementation. ‘To do the methodical student work justice, the logical next step is that experienced interaction designers take the work forward and create a for-production design.’ This is of course relevant to the SoC. ps: I am blogging the results of 2013 right now. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Interaction design. Used to be: Re: gimp gradients
On Apr 3, 2013, at 22:49, Aleksandar Kovač wrote: Peter, and everyone else, excuse me for taking so long to reply. excuse me too, I was travelling the last week and a half (and no, it wasn’t the lgm) which always takes me ‘out of office’, including email. Aleksandar, thank you for actually keeping the discussion alive, because as we all might have noticed: anyone who has ever done development on GIMP user interface seems to be sitting out this thread, probably waiting for this to blow over. well, that will be a whole lot of sitting, because I am sitting too, in strike. if GIMP as a project likes to have interaction design and usability work done for it, then we need to recover the implicit understanding of a couple of years ago, when Sven reached out and recruited me to heal the patient (== GIMP) and endowed his maintainer authority to get it executed in code; when I had working ‘I help you, you help me’ relationships with developers. the outreach, endowment, the relationships, they need to be recovered and this time explicitly, in writing, here on this list, not in gone-tomorrow talk on irc. I will go into Aleksandar’s long analysis and argument another day (busy now), but if we want to recover, then GIMP user interface developers, past and precent, better get involved in this thread. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
sorry for the delayed reply, I had some deadlines to deal with. Aleksandar Kovac wrote: On 2013/03/12, at 0:45, peter sikking pe...@mmiworks.net wrote: well, as long as I get shown the middle finger where it comes to implementing the control frame of the tool, I think the situation is completely out of whack here where it comes to interaction design and usability. remember, it is open source: only successful contribution counts. please don't get me wrong on this one [...] not at all, I appreciate posting on this thread, a lot. I would like to remind you that open source is not about only successful contribution counts. We have seen a case or two where initially unsuccessful contribution made all the difference in the long run, when the time was right. That is fine in the open source. i.e. the fact that ideas evolve and flow and can wait for better times and purposes. We have the luxury of not having the strict economic constraints or market competition that commercial projects have, and I think that this is something to embrace. OK, let me explain better: I was trying to say that people who on this mailing list and irc obstinately imply that they also got the interaction design angle somehow covered, should maybe check their contributions, accomplishments and recognition by seasoned peers (all three in interaction design, of course, as should be the seasoned peers). because this is how it works in code in open source and the devs are taking no prisoners in this regard. meritocratic is how it is supposed to work. But rather, the open source is about open access to any development and implementation information for a final product. With that in mind, professionally, I am very much interested in your approach to designing interactions. Your work (and that of your students) has been inspiring, but unfortunately has been a bit of a black hole, too. [...] without any cynicism I say that I could use some evaluation and advice here from you Aleksandar, because all pointers say that you are indeed a peer, deep into open source and you are independent of me. without trying to convince you, that design was developed in the open at its wiki page: http://gui.gimp.org/index.php/Transformation_tool_specification even earlier sketches were blogged: http://blog.mmiworks.net/2009/03/working-on-gimp-transformation-tool.html there were quite few afternoons where I showed the design on irc and adapted it after critique—especially the handle design—until it dealt with the criticism without throwing out the innovation with the bathwater. also I linked to the design in progress on this list, of course looking for attention and feedback. Either way, that opaqueness of your team's design decision process puts your team undeservedly in a position where you have to announce/defend the solutions in front of the community everytime you deliver the solution. well, I would not like to see that this comes to that I have to be more catholic than the pope. developers, open the source for inspection and sharing. but they do not have to justify every micro decision of every line of code, certainly not to non-developers (heh, try...) the code has to work and get past the quality standards and technical architecture requirements of the maintainers. the interaction design has to work and get past the quality standards and interaction architecture requirements of the lead designer. it brings me to the actual point that is so galling for me at the moment. as a designer I have several long-term relationships with clients and partner companies. what I notice about them is the giant trust that comes with them: clients and partners trust that when I lead the design the problems (and they are always big and complex) will be solved and the results will be great; just build it; clients and partners can trust that I never let them down, I am always there for them when they need it. I am now 6 years active at the GIMP project (long term, I call that) and the trust is not there. I really would like to see an explanation for this. And no matter how smart and informed your solution is, there will always be some middle fingers raised. For various understandable reasons (some might not get it, some might hate it, some are cans, some have different ideas... etc.)... the unworkable thing is that the middle finger comes from the people who are supposed to be partners in this: developers. the implicit agreement—I scratch your back and you scratch mine—has been broken with that. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Alexandre wrote: Gradients in gimp are very very painful thing. Are you planing make gradient tool more user friendly? Planning would be a too strong word, perhaps, but we do want to improve that in the future. I must say I am thinking of picking either the gradient or align tool as the module for my students to design. both are simply up for grabs. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Michael Schumacher wrote: spec writing seems to be a waste of time, competence and enthusiasm at the moment. developers simply throw away a third of it and do what they want. this pattern has been growing at GIMP over the last years. My feeling as only occasional contributor is that it is currently hard to determine if a spec is fully implemented or not, and if not, what parts are missing. Some specs, like e.g., Save Export, seem to be next to complete. it is not about incomplete implementation. although that happens, is no fulfilling, but it at least gives a chance of ‘can be taken further, also in the design, next time.’ the problem is complete substitution of a third of the design by developer-made stuff. although the reasons for this may vary—straightforward implementation; ‘I know better’; or the need for tinkering—the result is always the same: a significant shift in the users-tech-project balance, in favour of tech and at the cost of users and the project. Others, like the Unified Transform Tool, are implemented up to a point where any further steps felt like removing existing functionality - and have thus are thus left the tool in an inconsistent state. it is not only the unified transform tool, although that is the one that broke my back, certainly after our Vienna BOF. it is the string of these things, and the ‘that’s the way it is’ cheerfulness that developers display with it, that is exhausting me. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] now: project ideas, was: unified transform tool
Alexandre Prokoudine wrote: On Sun, Feb 24, 2013 at 4:09 PM, peter sikking wrote: meanwhile, I am looking for a new small design project to put before my students in a months time. any ideas. It seems that folks who create textures for 3D projects really want us to build advanced features on top of the new save/export model. One such feature is mentioned in the GSoC2013 page: being able to export/overwrite from sets of layers. it would not be bad if some more ideas popped up. thanks, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] unified transform tool
free wrote: I just installed the gimp 2.9 in my computer to see the unified transform tool. Cool! thanks! I was wondering what are your plans towards the other separated transform tools - scale, rotate, etc. Are they coming together with the unified tool in 2.10 or they will be removed? part of the design and its goals is that most of the other transform tools are “removed” (see below); all will go except for rotate and perspective tools, which will need to be redesigned as precision rotate and precision perspective tools. actually next month I am teaching interaction again and will give my students the exercise ‘precision rotate and precision perspective one or two tools?’ including of course redesigning the tools. I will need some essential scenarios for that, beyond the obvious photo horizon correction and getting verticals vertical. it must be more complicated and the tool(s) should not end up as 2-trick pony(s). about “removed”: I can imagine that instead of radically tossed out, the removed transform tools will be simply (force-)unchecked to show up in the toolbox by default, but still be part of the installation. Also, the icon for the tool is final or another one will be designed? I have not got 2.9 running at the moment, but googling screenshots showed that the tool icon is at the moment totally not what it should be. also I see that the tool options have become the victim of bloat in the meanwhile. it was probably all well intended. it is up to me to work with the developer and clean that up. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] Gimp for casual users
Andreas Lemke wrote: I have done a simple usability study with a novice Gimp user (only one, not 1000 :-). Would it be ok if I post it on gui.gimp.org? But I would need to have an account. There doesn't seem to be an option to register. to be a usability study it needs to be a usability study. this does not take 1000 participants, one-way mirror labs and video cameras. but the bare minimum needs to be there: test participants recruited from the core user groups (these are well defined for GIMP, see: http://gui.gimp.org/index.php/Vision_briefing) yes, the participants can be serving their apprenticeships / be on the learning curve to the groups defined there, but on their way they must be. six or more participants (not the more the better, above 12 really the law of diminishing returns kicks in). beyond that a solid report with a clear test protocol description and clear outline of findings would convince me that it is really a usability study. usability folks know that, apart from the effort that goes into recruiting, what I ask for above is really easy, practical and minimal. when really a usability study was done or will get done, we can talk about how that can go into gui.gimp.org --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] text talk at lgm
GIMPsters, the final part of the write up of the lgm text lecture is up (OK, since a week or so, I was on holiday last week). the three parts are: http://blog.mmiworks.net/2012/05/rethinking-text-handling-in-gimp-1.html http://blog.mmiworks.net/2012/06/rethinking-text-handling-in.html http://blog.mmiworks.net/2012/07/rethinking-text-handling-in.html this is the result of the internship Dominique did in our team. A lot of ground is covered has been covered and it is a good milestone in the overall text project. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Ditch the Save a Copy command (really)
Richard Gitschlag wrote: Seriously -- I propose that the Save a Copy... command should be removed and its functionality merged into the Export As... command. seriously... how can you write that? when the core of the discussion (that you are actively following) is that Save does export anymore, and Export does not save. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] (no subject)
Alexandre wrote: P.S. Why is it a gimp-developer@ list material? I directed him here, because he wants to solve it in code. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
Elle wrote: There is one little interface change that would make things easier for me. I'll suggest it, most tentatively. At present, the order in the Gimp 2.9 drop-down menu is Save, Save as, Save a Copy, Revert, then a big line in the sand, then Export to, Export, Create Template (I can't check the 2.8 drop-down because I accidentally destroyed my 2.8 installation). you can see the old state also in the spec: http://gui.gimp.org/index.php/Save_%2B_export_specification#file_menu_changes So how would it be if the line between the Save options and the Export options disappeared? And if Revert and maybe Save a copy got moved to down below Export and Export to? first of all: why are there separators (that line) in menus? it is to divide menus in sections that can be readily digested by users. al lot of menu items in a row take longer to scan,and to find your way back when you choose a menu item for the 100th time. ‘a lot’ starts fundamentally at 7. keeping 5 or less items in section is a good design goal. I was not going to stick 7 items in a section, thus the separator is there. also of course the items in a section ‘belong together.’ this helps users to faster figure out what items stand for. so I needed to distribute 7 items over 2 sections and take 28 years of established File menu history into account. All the 3 Saves belong together, really no doubt about that. Revert belongs to the Saves, because it is ‘Revert to saved’ it is often even labeled like that. this is a nice demonstration of the value of the new save + export. in 2.6 you have the strudel that if you ‘Saved’ to png (with losses) and you Revert, what are you going to get? your paths and layers? in 2.8 the situation is 100% clear: the last save to the xcf, which contains ‘everything.’ thus the Save section is getting full, and the 2 Export items go in the second section. it is really something different. Modern apps using Export do the same. Create template is also a derivation process, so I put it also in the second section. btw: putting the Export items in their own section makes users find and hit them faster than when they were the Nth items in the Save section. It also might ease the pain of transitioning to a new way of doing things if Save read as Save xcf, Save a Copy read Save xcf Copy, xcf serving as a gentle reminder of what will really will happen. 28 years of File menu say that that is too much belts and braces. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
Richard Gitschlag wrote: So if I may throw an echo into the room and ask why the particular message box CAN NOT provide a yes/no prompt, with Yes transferring control to the Export box and No cancelling back to the Save dialog? as I said before: no trip through Save if it is not safe. it is simply not allowed to ‘feel’ safe. seriously. in the long run (and that is how I am thinking) going cold turkey on this, with no fudges, is in the best interest of users. one of the biggest usability attributes of save + export is that the model is very clean: inside GIMP there is only xcf, which can be safely saved. everything else is import/export. no gotchas. no fudging. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Important misfunction in gimp scaling tool
Liam wrote: I don't think you should view it as written in stone no, you just have to take it up with your own, personal Moses™ ;^} work on the unified geometry tool has been kicked into another gear this week. Mikael and I are discussing different aspects and the spec is taking strides again. so yes, ‘from centre’ is gone and now scaling and shearing can be done (optionally) from the rotation axis, which has been relabelled ‘pivot’ for its new, multi-purpose role. http://gui.gimp.org/index.php/Transformation_tool_specification --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
Nicolas wrote: It also appears to me that a dedicated export and close shortcut pretty much kills this debate. you are on a roll with brainstorming, aren’t you? taking that a bit further, that would be ‘export + force close’ or ‘overwrite and force close’. the combinations; the integration in the file menu; and the edge case-ness all give me stomach ache. interaction stomach ache. but Force close, that could be useful to a lot more people. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
gg wrote: I think the whole problem here is that there are two different uses which are being presented as one. Save (as gimp internal format) and Export (to original format) is clear , though I would say it's back to front. However, the ambiguity is in File | Open let’s get some facts clear: - what you see inside a GIMP window is always, always, always in GIMP format, even if the only thing you did was open (= import, as it shows in the interaction) a png file and nothing more. - it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format. - I would be yanking the chain of one million users if I specced that the only way to get a non-GIMP file into GIMP is by File-Import... also drag and drop behaviour of ‘start a new file from a non-GIMP file’ would come into question (at minimum, it would have become a curve ball). - all we can do is make sure that every bit of interaction in GIMP communicates that there are no png/jpeg/tiff/etc files inside GIMP. anything that is not on-message? let me know, it is a bug. as Kate confirmed, the concept of ‘Work’ that Nicholas brainstormed his way into is exactly the line of our thinking at the moment. Work is so much better than Project because projects is an organisation form of (teams of) GIMP users and a project can contain many Works. what bugs me right now is that the interaction of GIMP still talks about ‘image’ when communicating about GIMP files. This could right now be migrated to talk about ‘work’, while still calling all non-GIMP files ‘image’. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
Nicolas wrote: Peter: I think you misunderstood what gg is suggesting: no I did not. I pointed out some facts that close many, many routes in this kind of reasoning. closed and done, yes. let me first make a statement: _every_ time (yes, that is around a hundred times now) that I see this kind of user feedback (that it is normal to open a non-GIMP file, do some edits, then save it to the same format) I start to think like interaction designers should: let’s assume he is right. make it ‘just work.’ and every time I run into the same problems, that are giant usability bloopers. - to really Save the contents of the file has to match what is on the screen (save, quit, restart, open file: no change--undo history excepted). this is not just a good idea, this is the law. breaking the law: usability blooper. - this means that either all users would have to have intimate knowledge of file formats to know why the option to save to them disappear as edits are done (usability blooper. bit of alpha is introduced? no more jpeg; any layers? no more png; paths and layers? tiff is still there???) or one is doing the whole export thing anyway, so what is the difference (exporting is not safe, remember?) where are the extra hoops? - the alternative would be to limit things: - it is 100% impossible to arrange it for popular non-GIMP files (png/jpeg/tiff) there would be a mode where one could Open one, make edits within the limits of the file format, and write the bits straight back to a file in the same format. a multi-personality application: complete usability disaster. and that is where it stops. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
Richard Gitschlag wrote: I doubt that would violate the terms of the Save/Export spec that the dev team swears by. yes it does. you cannot go through save if it is not safe. Well, the spec only says: Save, ‘Save as’ and ‘Save a copy’ shall only save to (compressed) GIMP formats, which shall be the only available format choices in the Save dialog. Only Save and ‘Save as’ shall change the saved-status of the document and replace the document–to–file association. that is why I wrote the clarification above. it is the whole _route_ of Save that is off-limits to things that re not safe. see my other posts of today. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
Liam wrote: I'd be OK if it *told* me, File Untitled has not been saved as xcf. It has been exported as paisley.jpg [300x500px] so that I knew the status and the warning was useful. something similar to that (without the pixels) has been applied as a patch for 2.8.1. (Bug 675399) --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
Richard Gitschlag wrote: The term Import also has a well-entrenched meaning of copy and paste from source file into current document. GIMP already has such a function, the Open As (Layer/etc)... commands. I think you are very selective there what conventions surround Import. simply importing a an excel sheet into a non-ms program (open office, apple’s numbers) comes with a host of fears and promises. the fact that it has to be portrayed as an import (even though it can and is done via the Open command) meshes with the fact that these imports are lossy, non-perfect. let’s be clear: the primary reason that there is both Open and Open As (Layer/etc) is to steer new document creation or new layer/etc creation. the rest is secondary. Various apps that still support saving in other than their preferred native formats [snip] I have already explained today where the flaw is in this (for GIMP, context is everything). here we stop going in circles. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] present xcf as what it is, a gimp project file format
gg wrote: So now you are completely ignoring what I suggested and going off somewhere else. yes. because it is not fruitful to have a line-by-line refuting match. instead, I showed where the real meat of the argument is. the ‘match’ is played in a completely different ballpark than where you wanted to kick around a bit with this topic. sorry. this is the best I could do to keep things constructive here. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
(Gez) wrote: That being said, I do agree that the overwrite function is somewhat odd (it hasn't a default keystroke, it disappears once you used it and becomes export). I did not put keystroke by default to be on the safe side. for those who overwriting is actually part of their routine, they can assign it themselves. on balance I think the effort involved in assigning is a good thing. disappears once you used is a bug that has been fixed for 2.8.1. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Bring back normal handling of other file formats
On Jun 14, 2012, at 16:37, Richard Gitschlag wrote: I still believe GIMP should, instead of merely informing the user that Save operates in XCF only, offer an export/save xcf/cancel option which would alleviate the need to go back and use a different dialog as a separate step. (You never know if a user might actually WANT to save their GIMP file under a non-XCF filename) I doubt that would violate the terms of the Save/Export spec that the dev team swears by. yes it does. you cannot go through save if it is not safe. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] hesitant about compiling a list...
Bruce wrote: [I will snip here quite a bit to keep this post from ballooning] Hi guys, I'm the Bruce that Peter referred to in the first post in this thread. How open does it make sense to be? I think a good approach is to be open to the degree where it is constructive and feels good, not just for the sake of it. I have an idea for how we can have public flags in the ground in terms of what can be improved (which are helpful for reference purposes, and also for communicating this is something we feel we could improve), I have ben thinking for the last weeks that this list should not be called the issue list, but the to-do list. this matches how the project is run. the UI team is simply working its way through areas of GIMP, older ones and brand new ones. when we get there, we design it, and make it work. Can we do this in a way that is sensitive to the efforts of GIMP developers, and if so, how? Well, I think one way to approach it is how things are communicated. E.g. You can communicate things in a constructive and positive way (i.e. here are some cool directions we would like to go in in regards to the various UI elements of Gimp; sort of like the UI Brainstorm does), or you can communicate things in a remedial way with a focus on deficit (i.e. this is broken and needs to be fixed). well, design is not about cool, it is about identifying the problem and then solving it (the hard design part). talking about design in such terms is for me important; it is about respect for what interaction design is and the value it brings to software. thus it needs to be said that ‘this is broken.’ but let’s introduce the convention that it can only written down that ‘this’ is broken, when the next sentence discusses the (beginning of a) solution. this means there is always light at the end of the tunnel, that the UI team is able to put direction into the UI work, and that any contributor has the chance to start from this direction. So, here's my idea: As you already do, you could allow people to submit ideas to the UI brainstorm in the form of mock-up images. This keeps things solution-oriented. The idea would be to have all UI suggestions and ideas go through the brainstorm in the form of images that propose solutions. there really is an ocean sized gap between the anything-goes world of UI brainstorming and the rigour of interaction design. anyone can participate in the brainstorming, that is the purpose of it. the only way to bridge the gap from brainstorming idea to interaction that is designed and can be implemented is to _design_ it. the whole discussion about opening up this design process to more contributors is in the ‘contribution processes’ thread. Then, you could create a page at http://gui.gimp.org gui.gimp.org is a repository, of interaction designs, usability projects and documentation of interaction design projects and processes. similar to a code repository, the integrity of gui.gimp.org must be maintained or else it is worth nothing. this means there is no place for ‘ideas’ on gui.gimp.org, just as there is no place for ‘casual talk about code’ in a code repository. the to-do list fits gui.gimp.org, it contains already quite a bit of contribution by interaction designers: the evaluation and analysis where the real issue is, and by showing the light at the end of the tunnel. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] contribution processes...
I have now given the whole thing a big push: http://gui.gimp.org/index.php/Interaction_design_patch not complete yet, but a start. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] contribution processes...
let's pick up this discussion again, sorry for the delay. Saul Goode wrote: In my opinion the language of the draft is not very inviting to contribution. the draft is a _description_ of the current code process, not a manual/invitation page for new contributors. it describes how things are in the code world, so I can derive an interaction design process from it, that is just as open as the code process. At minimum, each of the has tos should be changed to either shoulds or should strive tos. maybe this exactly demonstrates the sizeable gap there is between the people that can, and do, contribute, and users and other observers. the points listed there are about minimum decent software engineering, thus to software engineers it is logical that they _have to_ be met, or else the codebase goes to hell. to users and other observers, each one of these is a barrier of entry, and I find it good that that becomes clear to all parties. but to be able to contribute, one has to be able to meet the requirements, i.e. one has to be able to do the _work_ of software engineering. note that the shorter (less ambitious) the patch, the easier it is to meet the requirements. Also, it is unclear whether the final does not have to be perfect trumps any or all of the previous seven bullet points -- if it does not then the requirements are indeed exceedingly stringent. I have refined that point now in the wiki. Especially problematic is the sixth bullet. just sticking with the libs that GIMP normally uses and not start using platform-specific ones, and not use platform-specific compiler features goes a long way towards writing non-platform-specific patches. it is again about simply decent software engineering. [I snipped the rest because it was about changing the code patch workflow, which is not what I intent to achive.] --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] file open and create
Liam R E Quin wrote: Goal: I'm sure I'm not alone in finding file-open and file-create confusing, along with file-create-from webpage being different from File-Open Location, both of which take a URI... it's a mess. File-Create is not related at all to File-Open. it is related to File-New. it is New with the size (and maybe other) parameters set, and the specified content (which is always _not_ a file) in the first layer. I maintain it is very important to have a direct menu item to do: File-Create from clipboard from webpage screenshot xsane device dialog xsane epkowa:usb:003:002 xsane v4l:'dev'video0 with shortcuts (for the stable items I guess) being assignable and no penalty of dialogs (if possible). we can discuss again how Create was named (I was involved, so it ain't half bad); it was to not to have New... and under it New (with a submenu). --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] file open and create
Srihari Sriraman wrote: How about: Import from URI clipboard webpage xsane device dialog xsane epkowa:usb:003:002 xsane v4l:'dev'video0 and Create Buttons Logos Pattern the word Import is, again, related to Open, and that is exactly not how it works (for users, mind). so this should not be communicated. always, always, always the word New needs to be there, or to be implied (like it is with Create). File-Create is not related at all to File-Open. it is related to File-New. it is New with the size (and maybe other) parameters set, and the specified content (which is always _not_ a file) in the first layer. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] file open and create
El 31/05/12 04:31, peter sikking escribió: we can discuss again how Create was named (I was involved, so it ain't half bad); it was to not to have New... and under it New (with a submenu). What about File New from... Submenu well, the ellipsis is forbidden for a menu item that just shows a sub menu (it is the law, and they are right, I say). then this has to be looked at always with the submenu next to it: from clipboard from webpage screenshot xsane device dialog xsane epkowa:usb:003:002 xsane v4l:'dev'video0 you see that the from is in the submenu to have flexibility whether something is created from a resource that is not an image file (clipboard, webpage) or by initiating a capture (screenshot, scan). a more correct submenu would be: from clipboard from webpage screenshot scan--xsane device dialog scan--xsane epkowa:usb:003:002 scan--xsane v4l:'dev'video0 (the ‘--’ being an am dash, but this is monospace email. but this discussion fragmentation takes the attention from another point Liam made: Goal: I'm sure I'm not alone in finding file-open and file-create confusing, along with file-create-from webpage being different from File-Open Location, both of which take a URI... it's a mess. ah, the difference between: file-create-from webpage and File-Open Location same kind of confusion, no between an open (location) from an URI which opens/imports image files, and a new file with a rendering (from webpage, a non image file). is the root of all this evil for Laim that Create does not express New file enough? --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
Michael Grosberg wrote: I knew what GEGL is, but I thought that was just the engine and that you'd put some sort of layer-based facade on it so people could, like, actually use it. not to worry, you will not be abducted by boxes and hoses. GIMP is an image manipulation program, not a 3D or broadcast post processing app. so its UI is designed according to it. but the full power of GEGL will be at your fingertips... --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
gfxuser wrote: This would be tricky. People can use professional workflows and not be paid for the work they do. In German we have the idiom of 'unprofitable art' and unfortunately this says a lot about payment for creatives for long ;-( It's understandable, that they'd like to have an affordable tool. I have updated the briefing to deal with the ‘professionals’ chestnut. ‘It is more useful to define that GIMP is for intense use.’ that gets us a lot further. I see from the last sentence above that also a sentence or two needs to be added about GIMP not being a zero-cost copy/replacement of an expensive piece of commercial software. correct me if I am wrong, but GIMP being ‘free as in beer’ is a side effect of GIMP being ‘free as in speech,’ which is the open source spirit why contributors contribute. Why is painting from scratch not a top level part of the product vision? Are we going to miss someone? AFAIK there are already many other (semi-)professional affordable photo tools for Linux (RawTherapee, Darktable, Digikam, Photivo?, AfterShot, Lightzone etc.) but there seem to be much less high-end painting apps (MyPaint, Krita?, Pinta?). having been the moderator at both the vision sessions of GIMP and Krita, I know how very, very different both teams define what painting means for them. I also can say that the way Krita means painting is not reconcilable in one application with the way that GIMP means that one of our top goals is ‘high-end photo manipulation.’ the painting system in GIMP can be made fantastically powerful, I believe some people are working on that, and it will have the secondary effect that painting from scratch in GIMP is pretty damn good. but all the decisions about the painting system must take into account that it is simply part of the image manipulation goals of GIMP. painting is a means, not and end. I am happy there is Krita (see their vision on their front web page), and MyPaint and more. they can kick ass in painting from scratch. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Quasimode Adjustments -- fastest adjustments [demo included]
yahvuu wrote: for your inspiration, here's the fastest way to perform adjustments that i can think of: While pressing a shortcut key - the corresponding slider gets displayed right under the pointer - moving the pointer left-right immediately performs the adjustment. To commit, simply release the key. nice brainstorm. there are quite a few catches, but I am not going to spoil the brainstorm spirit with those. to push this forward: I see this fully relies on the dialog being there (for multiple reasons) with the sliders (and other controls) being there (and taking screen real estate) and then the shortcuts show one slider/control at the time. the question is: can that be combined? that is the next level... --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
gfxuser wrote: the last thread reminded me of a question, which I had for some longer and I couldn't find the right answer yet: Who is the targeted audience of GIMP? since I am used to doing a briefing on this, for GIMP design projects and also recently the start of a university usability surveying project, I thought I could write some of that down: http://gui.gimp.org/index.php/Vision_briefing --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Liquid rescale
gfxuser wrote: I read the news about Liquid rescale's UI redesign at GIMP's main site and Peter's blog. It looks very promising. Especially I like team's no. 3 results. Are there plans to take these changes over to the current plugin and/or make Liquid rescale an official tool/plugin of GIMP? the developer of Liquid rescale was also inspired by the results. I have offered design support when he really wants to overhaul the tool. but for now, porting the tool to integrate with GEGL seems to be his priority. One thing that could be changed are the many options 'advanced settings', 'rigidity' and 'algorithm parameters'. They look complicated. Perhaps more meaningful names could be found or they will be discarded in the UI and replaced internally by appropriate defaults. that is what my gut feeling said initially. but 5 minutes into the project, checking the docs and tutorial pages to get a feeling for the functionality, I figured out why all those parameters are there. they need to be; it befits GIMP that they are there. this is again expressed in the 4 scenarios. you can see in the different designs of the students how to make them ‘disappear’ (collapsed sections) when they are simply set to their default values. IMHO there should be one intuitive way with a few very easy steps, just like the current scale tool. They are: optionally make a selection on the image, show an outline with clickable handles to change dimensions, optionally paint discard and preservation masks, confirm or cancel. I you like I can provide a screenshot of the IMHO quite intuitive way of the equivalent tool in Photoshop Elements, but I think team's #3 proposal matches this best. that the simple (default) way of using it should remain simple was expressed in the first scenario that we used. this is where I pushed (and will push further) that to begin with, it is just a scale tool. but from there, it gets much more cool and powerful, see the other 3 scenarios. Peter, if you are looking for more things to change and use in your interaction design courses I suggest to look around in the current GIMPs dialogs. There are many unintuitive options, which look too scientific for an average user. Or could you explain blindfolded the difference between IIR and RLE in the Gaussian blur dialog, even if the results most times look the same? How about the dialog 'Path to selection' (see https://bugzilla.gnome.org/show_bug.cgi?id=671152)? These results could then go back into GIMP, with benefits for all. I would like to read more from your courses. ah, you mean this dialog: http://docs.gimp.org/en/gimp-selection-dialog.html (second half of that page). already special how you get there: press shift at the right moment. maybe being this hidden was the point: it seems to be for mathematicians only. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] hesitant about compiling a list...
guys, a couple of days ago Bruce appeared on irc and we had a chat. (Bruce is now subscribed to this list) within a minute we were talking about whether GIMP has a list of known UI design issues. as far as I know we do not have one, it is certainly not part of gui.gimp.org. (I am not talking about a bug list, with nuts and bolts issues, I am talking about a list of medium level to big-picture issues and to-dos. the kind of design tasks I pick for my teaching are medium size ones, see http://blog.mmiworks.net/search/label/teaching ) Immediately I realised this list is missing and that there are real benefits to maintaining a list like that: - a clear list of design tasks to pick one from for people who want to contribute or run projects in interaction design; - GIMP as a project says clearly ‘yes, we know we have problem with XYZ in the UI.’ this can make certain discussions a lot shorter, by pointing at the list. also I feel that _part_ of the ‘GIMP has so far to go’ feedback that the 2.8 release gets is caused by us not communicating ‘yes, we have problems.’ - coordinating between open technical project work (GEGL migration, etc.) and interaction design project work. - the big picture concerning UI becomes clearer because it is written down. so far so good. but while talking to Bruce I realised that there are a couple of side effects to this list that make me hesitate to just go and get started with compiling it: - just thinking of what I can contribute to this list, I know that this list is _not_ going to be short. also because all the issues that I can put on it are ‘medium level to big-picture,’ none of them are going to be trivial to solve. thus my hesitation is what this is going to make GIMP look like, and if the definitions of open worked where meant to stretch this far. - all of the issues that will end up on the list have been created by contributors to GIMP. some of these issues have been created 10 years ago, some of them last month. I wonder what it will feel like to GIMP contributors when something they just made, almost ‘immediately and automatically,’ (at least, feels like that to them) ends up on the UI issue list. so I would like to hear some opinion on this. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] wilber in the toolbar
On May 13, 2012, at 7:22, Liam R E Quin wrote some very wise words: Useability does not operate in a vacuum - branding is part of the user experience. Useable is aslo not always the same as immediately comfortable. Please, let's not attack people. for which I am grateful. also Liam is right about that the dropping areas (toolbox and n-i-w) can use some feedback when files are dragged over them. this could be as simple as swapping fg and bg colors. I do think that if gtk had an explicit drop files here widget, maybe like the one Sun and ATT experimented with some 15 years ago (theirs also had a drag out from here button that changed when the document was non-empty) then the demands on Wilber might change, both in the toolbox and in the no-image-window, but such a drag widget would need to be used elsewhere, e.g in the gnome text editor, file manager, etc. The useability studies at the time were very promising. I was thinking of the same SUN widget, I used an editor a lot that had that little receiving stamp widget. that is also the reason that I maintain that the whole toolbox needs to be the drop target. it is simply both faster and securer to use, simply a much bigger target. yes, at the cost of ease of learning. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] wilber in the toolbar
guys, the answer is yes, yes, yes. yes, wilber in the toolbox is suppose to help remember that it is a drag + drop area for opening files (as new document). does it (and the n-i-w) have a tooltip for it? yes, it is also a bit of branding. wilber is watching you. (btw, if someone wants to implement that on date == friday the 13th wilber's eyes follow the mouse pointer all the time, like good old xeyes, then be my guest) yes, it eats space. one row of toolbox icons, all the time. I can see how users want that space back for something else. a setting in toolbox configuration to switch it off? fine with me. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] contribution processes...
guys, lately I have been thinking about introducing a new process. this thinking has been accelerated by the GIMP bof at the lgm, where GIMP project members expressed concern about lack of openness and transparency in the current UI redesign work, and I expressed concern about lack of valuation and respect for the field of interaction design. the discussion at lgm was constructive, and I think that everybody should just act to address all of the concerns. I think that the new process that I am thinking about can contribute to that. this process is an ‘interaction design patch/contribution’ for new, fresh contributors, that I want to model it one-to-one on the established code patch/contribution process (for new, fresh contributors). so first we need a good description of this code contribution process, before adapting it. I have given it a first stab: http://gui.gimp.org/index.php/Interaction_design_patch I like to discuss it here on this mailing list and get it in a shape that is beyond reasonable doubt. after that the next steps can be taken. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] wilber in the toolbar
Liam wrote: drop images text message would me more efficient and explicit or probably an icon representing the drag and drop action... now that would be really annoying, looking at that 40 hours a week, every week of the year, no? A gtk+ drop target might be a better approach. is that a standard widget? I have trouble googling it. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] wilber in the toolbar
gfxuser wrote: peter sikking wrote: well, usability is a lot more than ‘what can do people find out in the first 5 minutes’ (ease of learning). GIMP is designed for other goals: speed of use, the freedom to create, etc. can you explain this in more detail, please? I'm honestly interested and like to understand the backgrounds of the GIMP UI discussions a bit more. your question is general enough that the answer could grow textbook size. narrowing it down could give am chance to answer it. meanwhile, I did find an old blog post that may go into what you want to know: http://blog.mmiworks.net/2007/05/lgm-gimp-project-overview.html (watch out that the top-10 list that it segues into is heavily outdated and superseded; not useful to start discussions about that anymore) --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] new interaction project starting...
hey guys, hot on the heels of the first GIMP interaction internship, for which we presented the results at the lgm (blog posts coming), a second one is starting. Marinus Schraal, from Holland, will be with us for the next 10 weeks. his project subject will be picked by him in the next couple of days. if you see ‘foser’ on irc, that’s him. he will be happy to talk to you about it. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Demo] Porting MyPaint brush engines to the GIMP.
sigetch wrote: MyPaint brush engine has three four advantages: 2. It has 9 inputs, 42 setting parameters, and 30 internal states to determine the timing, position, size, color, and blend mode. nice for you, but for users I would swear that this should show up on the disadvantages list. 3. All parameters are defined as brush parameters, while in gimp, those parameters are not managed in one object, brush dynamics and tool options manages some of those parameters. true, presets management in painting is a mess right now. 4. Its implementation is very simple and well designed. This is the most important things for developers! ...but one million users do not care. And It has some disadvantages: 3. It lacks paint mode at all. (But who uses the painting mode of the paint brush?) can I point out the vision of the GIMP team? http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision within GIMP painting is _part of_ image manipulation, that's why it is so general purpose and must have the modes. painting is never an objective in itself in GIMP. here GIMP is 100% different from krita, or mypaint. of course when you want to make your painting engine an extension to GIMP, and distribute it separately, you can do whatever want. it is a free/libre world. if you are aiming to get your engine _inside_ GIMP and have it in its standard distribution, then your technology (which seems to be your focus) must be adopted to the GIMP vision (see above), be adopted to the new technical architecture of GIMP (see GEGL) and fit the interaction architecture of GIMP (no giant panel with 42 big sliders; adapt to the tool options, integrate (how?) with the paint tools, etc). this can all be done, but takes strategic thinking and then a lot of design work (technical and interaction) before development makes sense. so you have to ask yourself which route you want to take, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] that typing business...
OK, I cannot resist quoting this review: http://www.theregister.co.uk/2012/04/27/ubuntu_12_04_lts_review/ it uses GIMP to discuss ubuntu’s HUD. but then: ‘Of course GIMP is an app that lends itself to the mouse so switching to the keyboard to use the HUD isn't always faster.’ if a software reviewer, with (I postulate) nowhere near the speed demands of our core users, can see the flaw, then... yes, context is everything in interaction design, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gsoc - Slicing Tool
noob7 wrote: Hey there! Iam interested in this year gsoc. I would like to take slicing tool idea which I heard that its one of most requested features. I get the main conept of this tool. Ive tested guillotine action and slice filter on compiled trunk version. I found that slice filter still have some issues. On irc I was told to talk to ,,guiguru which is mitch? about gui for this tool. Do you have any comments about slice tool ? I would love to hear some feedback. this one has been brewing for a long time. Let's have look what is minimally needed and then you can gauge if you are up for this: let's call this tool ‘cutting mask’, because that what it is. it is a glorious export function, so it should live in the File menu. there needs to be a setup of the cutting mask and and execution of the cutting mask (the mass export). just to make this clear: in the UI the cutting mask has nothing to do with the guides, is not a layer nor a channel (which are saved selections, really). how you do it on the _inside_, technically, is fully up to you, your mentor and mitch. the cutting mask (let's say one per file, to keep it simple) is a mask that consist of any number of rectangles (again, simple and practical). these rectangles are vectors (can be changed for ever) and can overlap. the size of the cutting mask is that of the canvas (unless somebody protests). when the setup of the cutting mask is invoked, the mask is drawn over the canvas and rectangles can be added, deleted and edited. setting the position and size of each rectangle is both interactive on the mask and via numerical input. this can work a lot like the rectangle selection tool does (I expect that code can be reused for that). but: it is _not_ the rectangle tool does the actual editing. it is the property of the mask setup mode that working with these vector rectangles is highlighting one, dragging its handles or changing its coordinate numbers. also minimally needed in setup mode is that for each rectangle a filename and type is specified by users. the mask setup is OK'ed or cancelled and the mask projection ‘folds away.’ executing the cutting mask means users setting a folder name and location (via a file dialog). this folder will be created and all the files end up in it. overwrite existing folder if users wish to do so. users set in the same dialog whether to cut the current layer or a merge of all visible layers. the export settings for each file type that is in the mask (png, jpeg, tiff, the list goes on) must be set for each execution of the mask. I propose to keep things simple and do one setting dialog for each file type present on the mask and apply to all files of that type in the cut. file name clashes should be dealt with automatically. I think this is a nice beginning of a tool like this. yes, a lot more advanced feature could be added, but this is the core of it. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] An update on the menu search
Srihari Sriraman wrote: A command system would really boost the speed of interaction. now that would really depend a lot on how you design this. I must admit there is a tiny opportunity to come out faster than mousing the menus for a plugin without a shortcut key (ctrl-...). where is comes to menu items with shortcut keys, I am not sure you ever can. so let's see, you have an opportunity to do something good for a minority part of the menu structure, which by itself forms 1/3 of the GIMP interaction system. is that worth it? this of course apart form the help/explore/documentation system we talked about here and on irc. I thought we had understand each other during those talks. We're headed there. Blender's and Rhino's systems are great, so we'll be taking inputs from their design too. that does not sound like a confident approach to designing this for GIMP. think about the whole context of GIMP, its vision and its core users. all the work on the canvas. it starts with that realisation that you are working on what is a minority part of 1/3 of GIMP's interaction. Currently we're thinking of using a command syntax similar to that of ImageMagick.. Would be great if we could pool in ideas regarding the command system here... (Will probably start a new thread on that soon). Just to note, Tito has this handy feature. If you enter 2 letters, it matches those actions with those 2 letters as the first letters of its words... Ex: You can Apply Canvas by typing in AC and hitting enter. Or say Gaussian Blur by just GB. have you run statistic on how many clashes (same 2 or 3 letters for different commands) in english? and then on to other languages, where the 2 or 3 words english needs to describe something (a peculiarity) is localised with a single word. there is 76 localisations of GIMP, I would not blame you if it can be made to work for all languages apart from urdu (or something like that). but if at the end it only works for 5 languages out of 76, then it would of course go nowhere. then on to non-latin input methods, on those standard latin keyboards computers are sold with. how would that be fast? --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GSoC - 2012 - Implement the combined selection tool
Robert, I suggest we do the same as for the 2011 student work: http://blog.mmiworks.net/2011/07/teaching-interaction-11.html the work was taken further by my design team in a 3-day design sprint: http://gui.gimp.org/index.php/Warp_tool_specification The 2010's Voralberg's research is about combining four selection tools (fuzzy select, select by color, intelligent scrissors and foreground selection). The suggestion from Peter Sikking was to do as the 2011 student's have done. This research is about iWarp tool. I've read also this research, and also studied the work of the design team. No I suggested that the same procedure is followed, not the same project content. That means: if the SoC work goes forward on the combined four selection tools, my team does a design sprint, taking the design of the combined four selection tools forward. this would be a solid basis to for you to work from. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] What is this new p-l-a-n-n-e-d thing? Another buzzword for managers? :)
Alexandre wrote: Planning with the current amount of active developers would be rather pointless. I'd say roadmapping work even when there is only one developer, on a half-time basis. it is simply about what needs to be done for the next version. and just as important, that no non-trivial effort is spent on things that are not on the roadmap. over the years I have seen GIMP being very good at ignoring efforts. enough for me to also say: to remain motivated I also pick my own topics that I want to work on (instead of just playing fireman for non-roadmapped development that keeps popping up). I think it has been pointed out in the last days here that this knack for ignoring roadmaps has not helped the release frequency of GIMP. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] What is this new p-l-a-n-n-e-d thing? Another buzzword for managers? :)
Prokoudine wrote: On Tue, Mar 13, 2012 at 1:58 AM, peter sikking wrote: I'd say roadmapping work even when there is only one developer, on a half-time basis. it is simply about what needs to be done for the next version. and just as important, that no non-trivial effort is spent on things that are not on the roadmap. Which is our plan for post-2.8 :) famous last words... --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] How much money to make a dent in GIMP 2.8?
Alexandre wrote: Personally, what I really need is CMYK Everyone wants CMYK, few mention what they need specifically :) yeah, beware of the schmuck: http://blog.mmiworks.net/2009/05/gimp-enter.html --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] does gimp have a liquify equiavlent module in the working
Alexandre wrote: On Sat, Mar 3, 2012 at 10:11 AM, supratim chakraborty wrote: I would like to know whether the liquify equivalent module exists in the making or not It was a successful GSoC2011 project and will become part of 2.10 or 3.0. hell yeah, we did a design sprint on it: http://gui.gimp.org/index.php/Warp_tool_specification after initial student work: http://blog.mmiworks.net/2011/07/teaching-interaction-11.html --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] something's starting, it is the text tool
hey guys, another attempt at having a discussion about text in GIMP work. although it was useful to read about features, niggles and going to other apps to work with text (the latter being a huge smoking gun for GIMP), it was not what I was looking for. I was looking for what text means in the context of serious image manipulation. let's see if I can stimulate this a bit. within the UI team we are discussing about the following: ‘text never is the main purpose in GIMP work (like it is in scribus or libreOffice writer), it only plays a supporting role within a graphical work’ please share you thoughts, --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] something's starting, it is the text tool
wow, Thorsten Wilms' reply is exactly the type of information I am looking for. I could see myself using text in GIMP for - text in mockups - annotations - as integral part of ... poster design For mockups, I prefer Inkscape, these days. GIMP only wins for some modifications of screenshots. With annotations I mean simple text placed on images. Usually small and without any effect or only effects like drop shadow or blurring the background for better legibility. This is all about convenience: to not have an additional export/import/export with another application involved. For text as integral part of a poster (or similar setting), it's hard to compete with the flexibility and rich functionality of vector graphics applications like Inkscape. Reasons to use GIMP could be a need for tricky blending and pixel-based effects like grungy edges. That would be text that is primarily an element of a graphical composition, then. In contrast to text where its exact shape and placement are secondary. I would not speak of a supporting role, as the text might well take center stage and/or be the backbone of the work. Such text, that is all about explicit shapes and exact/direct placement, is the opposite to the result of some raw string of text with a set of formatting rules applied to it. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] something's starting...
I wrote: Alexandre Prokoudine wrote: Personally I would like the team to come to final agreement about non-destructive editing. you triggered me into laying my cards on the table about that one. I am working on a blog post about it. done: http://blog.mmiworks.net/2012/01/gimp-full-gegl-ahead.html --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
