<div dir="ltr"><div dir="ltr"><div>Hi Elle Stone,</div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 26, 2019 at 7:10 PM Elle Stone <<a href="mailto:ellestone@ninedegreesbelow.com" target="_blank">ellestone@ninedegreesbelow.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It seems to me that "it" depends entirely on what a person actually uses <br>
GIMP for. Speaking for myself, I don't even have Inkscape, Scribus, or <br>
SwatchBooker installed on my computer. Instead I use GIMP for painting <br>
and photography, in conjunction with RawTherapee, darktable, PhotoFlow, <br>
Krita, Hugin, Exiftool, digiKam, etc, etc.<br>
<br>
How would your proposed changes to GIMP cohere with workflows that don't <br>
involve DTP and instead center around other tasks and goals for which <br>
people use GIMP, such as photography/painting/HDR processing/fits/fine <br>
art print production/video display output/image retouching, and etc?<br></blockquote><div><br></div><div>I agree and understand well. Changing something for particular kind of users</div><div>(DTP users) leaving others (Digital artists& Photographers) that what I don't mean.<br></div><div>Even I don't saying to change everything to give consistence. I understand how much</div><div>difficult to do that. Even changing something can create problems to exiting users</div><div>how they use these programs in which way.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> 3. Different Task Flow<br>
> 4. Different Tools Manipulators Flow(can create understanding problem)<br>
<br>
Could you elaborate more on what you mean by "task flow" and "tools <br>
manipulators flow"?<br>
<br>
It's not clear to me that a program like GIMP - which is used for such a <br>
hugely diverse array of editing tasks and output goals - should be or <br>
even could be optimized/shoe-horned into a set task flow.<br></blockquote><div><br></div><div>These points tends to hard to explain without going on deep research on each</div><div>programs but I will try to explain in much simple way. What a user want from these</div><div>programs is their goal(final image vector, raster, pdf, etc). Now Goals are divided into</div><div>activities which in turn divided into tasks which again divided into actions.</div><div><br></div><div>Now lets take an example for aligning objects, In GIMP, align options you will find in tool box.</div><div>In Inkscape, align options it is dialog access from object menu. In Scribus, it is in dialog access</div><div>from window menu. Now the task is same but actions are different for each application. Which </div><div>will create confusing for first time users where to find align options. Now I am not saying about </div><div>complete UI, I am approaching to little details that can solve for consistency. But I can't say which</div><div>approach is better.</div><div><br></div><div>For that purpose only, I have share idea for having a website (common communication channel )</div><div>for creative applications so users can share ideas where he can get feedback and vote for their </div><div>features and share how to solving existed approach (like blender community right click select).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> 5. One have that feature another not and etc.<br>
> 6. (Everything that create inconsistency in these applications)<br>
<br>
Why do you want all these programs to have the same features?<br>
<br>
Do you want to throw away the "not in common" features? Or do you want <br>
to add all the features from all the programs to all the programs?<br>
<br></blockquote><div><br></div><div>No No, I am not saying to bundle all the features to all the application so it hard to distinguish</div><div>what is for what purpose. It is set of some common features that some or these graphics</div><div>programs can share. Let's say I really like to have GIMP perspective tool in Inkscape. Maybe,</div><div>In future someone added perspective tool in Inkscape but it did't behave like GIMP perspective</div><div>tool. It some 3d circular manipulator(like 3d software have for scaling rotating).</div><div><br></div><div>From all these years, each team has approach to their own way of doing things. Maybe in future</div><div>these teams approach same way of doing things by having and finding ideas from one website</div><div>that is center communication for all these graphics applications.</div><div>  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>I don't know about Scribus or Inkscape. But GIMP interface is already <br>
highly configurable, and "DTP-oriented" configurations could be <br>
distributed as config files and themes/icons.<br>
<br>
If the already available array of configuration options for GIMP isn't <br>
sufficient to set GIMP up for use in an envisioned seamless DTP <br>
workflow, then a specific list of what's missing would be a good place <br>
to start.<br>
<br>
Which brings the discussion around to Jehan's awesome idea of being able <br>
to easily exchange files between programs. The ability to easily <br>
exchange files between programs is something that would make imaging <br>
workflows in general (not just DTP workflows) considerably easier. It <br>
would be awesome to have the option to easily switch back and forth <br>
between different applications, for example sending a flattened version <br>
of the current image from GIMP to Krita to RawTherapee and back to GIMP, <br>
etc, or from Scribus to GIMP and back, or etc.<br></blockquote><div><br></div><div>Yes,  Even Jehan's Idea is a part to give consistency. Like same way their is lot's of</div><div>way to follow but for all these atleast we need common hub communication for </div><div>discussions between these teams and users. What is the need of saying these all to</div><div>one team if another teams and users have just unaware of it.</div><div><br></div><div>Ok, Developers want to solve specific bug report and feature request maybe that </div><div>feature is common feature and it can benefit all these graphics applications but never </div><div>discussed before that how it works and just added in one program. Maybe other have </div><div>implemented the same feature with changes how it works. These things can be discussed </div><div>other teams.</div><div><br></div><div>Thanks</div><div>Vikash </div><div><br></div><div><br></div></div>
</div></div>