Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

[Guillermo Espertino]

Fist of all, I want to thank Peter for his excellent work. I'm glad to 
see that several problems of GIMP's GUI are being revisited and most of 
the solutions suggested will be welcome in future releases.
I don't agree with #1 request, though. I know that this has been a 
frequent request for years, but I think it's just a matter of habit. I'm 
a Photoshop user, and a Gimp user, too. After a couple of days I could 
understand the power of floating windows. Switching between floating 
windows and fullscreen with F11 is fast and easy, and my workflow is far 
better this way.
And when I connected a second monitor it was even better. Floating 
windows ROCK!
Turning Gimp into a MDI application will make several users happy, but 
IMO it won't benefit Gimp at all.
I think it would be better to improve the way those floating windows work:
- by creating only one item in the windows list, grouping GIMP's 
windows, instead of one item for each panel (it's quite confusing)
- by making toolbox and dockers dependant of the "canvas" window.
As it was discussed before, this brings a new problem: where should the 
menu bar be placed. Of course, the document window is the most ovbious 
choice, but as we use floating windows, it won't be any document window 
when we open the program.
Maybe the best option is to create a new kind of splashscreen, where we 
get as options:
-Create a new image (if you choose this, the new image dialog appears, 
with dimensions, templates, color mode, etc.)
-Open existing image/s (if you choose this, the filer appears, letting 
you pick an image or a group of images).
Once you made your choice, the toolbox and dockers will appear along the 
document/s window/s.
(I'm thinking about something like the latest Adobe Premiere Pro initial 
screen, for instance, but in the GTK/floating windows fashion)

Another thing that was covered in your work is the use of the screen 
space. I agree that the current menu layout is a waste of pixels.
But this is already possible to improve in Gimp using the small theme 
and putting the tool options panel in the docker window. This allows you 
to shrink the toolbox, gaining much window space.
You can see a screenshot of my current tool layout in gimp using that 
idea here:
http://www.ohweb.com.ar/screenshots/Gimp-Screenshot.jpg

Well, just my two cents.
Thanks again for your work!

Gez

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Problems with GIMP from latest SVN

[Renan Birck]

Hello,

I built GIMP from latest SVN on Ubuntu 7.04 i386. It works almost OK,
but when I try to create a new layer with layer fill type set to
"Transparency", it crashes with this output in the console:

*** glibc detected *** gimp: double free or corruption (!prev):
0x0a2bb568 ***
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6[0xb74d87cd]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb74dbe30]
/usr/lib/libglib-2.0.so.0(g_free+0x31)[0xb75fe131]
/usr/lib/libgobject-2.0.so.0[0xb772cfa1]
/usr/lib/libglib-2.0.so.0(g_datalist_id_set_data_full+0x347)[0xb75e4b87]
/usr/lib/libgobject-2.0.so.0[0xb772d689]
/usr/lib/libgtk-x11-2.0.so.0[0xb7bc2e31]
/usr/lib/libgtk-x11-2.0.so.0[0xb7cbe4a1]
/usr/lib/libgtk-x11-2.0.so.0[0xb7cca826]
/usr/local/lib/libgimpwidgets-2.0.so.0[0xb7e2d60c]
/usr/lib/libgobject-2.0.so.0(g_object_run_dispose+0x50)[0xb772dcc0]
/usr/lib/libgtk-x11-2.0.so.0(gtk_object_destroy+0x7e)[0xb7bc2b2e]
/usr/lib/libgtk-x11-2.0.so.0(gtk_widget_destroy+0x45)[0xb7cbe755]
/usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__INT
+0x59)[0xb7738729]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb772b62b]
/usr/lib/libgobject-2.0.so.0[0xb773c103]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0xb773d627]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb773d7e9]
/usr/lib/libgtk-x11-2.0.so.0(gtk_dialog_response+0x5a)[0xb7b1e13a]
/usr/lib/libgtk-x11-2.0.so.0[0xb7b1e195]
/usr/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID
+0x49)[0xb77389d9]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb772b62b]
/usr/lib/libgobject-2.0.so.0[0xb773c103]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0xb773d627]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb773d7e9]
/usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x53)[0xb7ad2163]
/usr/lib/libgtk-x11-2.0.so.0[0xb7ad3bd5]
/usr/lib/libgtk-x11-2.0.so.0[0xb7ad3c9c]
/usr/lib/libgtk-x11-2.0.so.0(_gtk_marshal_BOOLEAN__BOXED
+0x60)[0xb7ba26b0]
/usr/lib/libgobject-2.0.so.0[0xb7729e49]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0xb772b62b]
/usr/lib/libgobject-2.0.so.0[0xb773c753]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0xb773d3ef]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0xb773d7e9]
/usr/lib/libgtk-x11-2.0.so.0[0xb7cb6e18]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x19a)[0xb7b9b9da]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x317)[0xb7b9cbc7]
/usr/lib/libgdk-x11-2.0.so.0[0xb7a1e12a]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0xb75f6df2]
/usr/lib/libglib-2.0.so.0[0xb75f9dcf]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0xb75fa179]
gimp[0x80671e9]
gimp[0x80681a3]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc)[0xb7486ebc]
gimp[0x8066ee1]
=== Memory map: 
08048000-083b7000 r-xp  08:01 212414 /usr/local/bin/gimp-2.3
083b7000-083cb000 rw-p 0036e000 08:01 212414 /usr/local/bin/gimp-2.3
083cb000-0a6e2000 rw-p 083cb000 00:00 0  [heap]
afe75000-afe8 r-xp  08:01 2234   /lib/libgcc_s.so.1
afe8-afe81000 rw-p a000 08:01 2234   /lib/libgcc_s.so.1
afe92000-b0743000 rw-p afe92000 00:00 0 
b0743000-b074a000 rw-p b51dc000 00:00 0 
b074a000-b0751000 rw-p b074a000 00:00 0 
b0751000-b078c000 rw-p b0751000 00:00 0 
b078c000-b0792000 rw-p b078e000 00:00 0 
b0792000-b0a43000 rw-p b0792000 00:00 0 
b0a43000-b0a44000 r-xp  08:01
9924   /usr/lib/gtk-2.0/2.10.0/immodules/im-cedilla.so
b0a44000-b0a45000 rw-p  08:01
9924   /usr/lib/gtk-2.0/2.10.0/immodules/im-cedilla.so
b0a45000-b0ce1000 r--p  08:01
211330 /usr/share/icons/hicolor/icon-theme.cache
b0ce1000-b1388000 r--p  08:01
58233  /usr/share/icons/gnome/icon-theme.cache
b1388000-b15ad000 rw-p b1388000 00:00 0 
b15ae000-b16cc000 rw-p b15ae000 00:00 0 
b16cc000-b16f6000 r-xp  08:01
7734   /usr/lib/liblcms.so.1.0.15
b16f6000-b16f7000 rw-p 00029000 08:01
7734   /usr/lib/liblcms.so.1.0.15
b16f7000-b1e2a000 rw-p b16f7000 00:00 0 
b1e2b000-b1e34000 rw-p b1e2b000 00:00 0 
b1e34000-b1e36000 r-xp  08:01
212422 /usr/local/lib/gimp/2.0/modules/libcolorsel_water.so
b1e36000-b1e37000 rw-p 2000 08:01
212422 /usr/local/lib/gimp/2.0/modules/libcolorsel_water.so
b1e37000-b1e39000 r-xp  08:01
212419 /usr/local/lib/gimp/2.0/modules/libcolorsel_cmyk.so
b1e39000-b1e3a000 rw-p 2000 08:01 212419 /usgimp: terminated:
Cancelado
[EMAIL PROTECTED]:~/gimp$ 
(script-fu:23889): LibGimpBase-WARNING **: script-fu: wire_read(): error

I have originally built GIMP with -O3 for CFLAGS, so I tried rebuilding
it again without any specific CFLAGS setting, but still no luck.

How cna I fix that?

Thanks.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Webdesign is wrong

[damianzalewski]

 What gimp is not:

"not a web page mock-up application
I brought up web mock-ups, but we realised that seriously supporting this would 
mean introducing a ton of functionality;
it is better done in a specialised application"

   I really don't understand what tons of functionality you mean.
   The most bothering shortcoming for webdesign workflow is slice tool
   and save for web (integrated into one app).

   Maybe your research methods are wrong.

   Webdesigners DO NOT design elements of page separately.
   Webdesigners DO NOT slice page and then open sliced files to save
   them for web. It would be great waste of time.

   As a matter of fact approach 'not a web page mock-up application'
   means that gimp is useless for any modern form of
   webdesign.


   PS I didn't intend to offend anyone.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

[Thorsten Wilms]

On Fri, May 25, 2007 at 05:25:14PM +0200, [EMAIL PROTECTED] wrote:
 
> If everything ends up "dockable" and there is no longer the freedom to  
> place windows where you _need_ then to be
> I think it should stay as it is. Maybe that was the fundemental reason for  
> this rather unusual set up in the first place.

I talked about dockable, not forcing things to be docked. The only necessary 
restriction of placement of floating palette windows would be palette headers 
right above docking areas (as that should trigger docking). I'm confident 
this could be arranged to be no issue in actual use.
Actually, if you think about it, docking would happen when you move a palette 
close to the bottom or side of another palette, so the then docked pallette 
ends up pretty much where you move it to, but tightly arranged, most space 
efficient. Or if you moved it on top of another palette, you get a tab and 
can easily switch to what would be completely obscured otherwise.


> I know this sort of thing is possible in win32 API but I dont seem to be  
> able to find any linux progs, gtk+ or qt derived, that have freely  
> floating windows or panels.

So what if GIMP became the first?


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

[peter sikking]

Thorsten wrote:

>> > requests_25.html>
>
> On 4. better painting tools:
>
> So you propose to have brush models in tools like dodge/burn.
> Why would this be preferable to having modes like dodge/burn inside
> brush tools?

because dodge/burn matches users' goal as a primary selector,
and because within that certain task (brighten/darken) the
image content dictates which brush model work best in a certain
part. So main mode = dodge/burn, sub-mode = switch through
the brush models fits that best.

> Maybe brush model and mode should be handled separately?
>
> A: The region/scope to work on
>   - whole image
>   - a layer/group/set
>   - a selection
>   - brush strokes as they happen
> B: Options for above
>   - mainly brush model with parameters comes to mind
> C: The action or drawing mode to apply
>   - transformations
>   - filters
>   - paint

the whole puzzle is about decomposing ortogonal modes, and then
flattening these multidimensional tool spaces again. Our only guide
can be here the graphics concepts our product vision users think in.

> On power modes
>
> Sounds like a rather vague distinction, makes me wonder if
> is such a good idea to split the modes based on it.
> Shouldn't layer and paint modes be kept the same?

Not necessary to keep both the same. With the brush tools you
have this opportunity to take out the modes with natural
descriptions (vs. mathematical) and make unhide it out of these
modes and integrate into an existing or new brush tool, that
matches a user goal directly.

no such chance for layer modes.

> dipping and smearing
>
> Considering GIMP is not and shall not be painter ... but this would
> be very nice especially for drawing from scratch ;)

fine with me. but you can see how this solution came about,
straight from the product vision, via the user scenarios.

> Regarding adjustment layers and GEGL
>
> GEGL is graph based, somewhat comparable to the nodes in Blender,
> right? If so, the concept of a layer stack does not match GEGL.
> I would propose to go all nodes and have no layers, if the layer
> stack wouldn't match the common case so nicely.

I was very happy when I reached a consensus with pippin and mitch
on hat the GEGL graph is an internal technical representation that
is not exposed in the UI. Maybe, only, to the developing users who
use GIMP as stated in the third point of the product vision:

"GIMP is a platform for programming cutting-edge image processing
algorithms, by scientists and artists;"

So yes, the graph is more flexible than a image->layers->operation  
history
structure. But I am convinced that the latter will help users more
in getting the job done.

> On window management
>
> I have been thinking: What if GIMP was represented by a window with
> just the main menu. Image windows could be dockable palettes. Requires
> docking side-by-side. For SDI style, one would dock one image window
> and the inspectors all to the main window. Several images could docked
> together to have tabs.

Although I will have to push the boundaries of the look + feel
guidelines every once and a while, I do prefer to stay 90% within
the law. It does not hurt to go far out for an hour, but after
applying some sane laws like "the menu bar sits at the top of the
main window, on linux and windows," I am mostly back where I am
in the last blog entry.

 --ps

 principal user interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm 07, top‑5 GIMP user requ ests...

[peter sikking]

Sven,

> On Fri, 2007-05-25 at 02:15 +0200, peter sikking wrote:
>
>> > requests_25.html>
>
> BTW, the dialogs that you consider to be "unnecessary" can already be
> skipped using the Shift key.

Then the perfect solution is that we reverse the logic of that
shift key. Only with the shift key down the dialog is shown.

Our users will be eternally grateful...

> Sure, perhaps not the most intuitive and
> discoverable approach, but it works well for our power users.

Like I said, there is no such thing as intuitive >^}

> And
> sometimes the dialogs are not that unnecessary at all. So we can't  
> just
> remove them. At least not all of them.

After the provocative statements that needed to go in the lgm talk,
I will be incredibly careful about recommending removing any of these.

But if like with the layers dialog, I see zero function 99% of the time,
then I want us to try this out in an early (2.odd.2) development  
version,
wait a month (learning period) and then evaluate if that was the right
choice.

> Some UI streamlining is definitely needed, but the solutions aren't
> necessarily as simple as you put them. Actually a lot of what you  
> say in
> your blog entry is well-known and there are bug reports for it  
> already:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=85579
> http://bugzilla.gnome.org/show_bug.cgi?id=109929
> http://bugzilla.gnome.org/show_bug.cgi?id=121087
>
> These things are on our TODO for quite a while now. The problem is  
> that
> they are very difficult to implement.

Yes, the top-10 user request shows that on the user side there is a
demand for change. And that the developers are thinking of the same
things will only make it easier for us to go ahead and work together
in the same direction.

But because of the work my team of usability and interaction
professionals has put into this project since October the
status of the issues we are talking about has changed.

Now they are no longer 'anybody's guess', they are official.

And my team is there to work with the developers to find solutions
that can be realised, not pie in the sky. We are also there to
make sure that our dear developer resources are not wasted on
purely cosmetic UI makeover, and to make sure that the described
productivity stoppers do not get shelved as an enhancement, but
are treated as the GIMP-value reducers they are.

 --ps

 principal user interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Plugin compilation problems on 64 bit system

[Sven Neumann]

Hi,

On Fri, 2007-05-25 at 17:56 +1000, David Hodson wrote:

> Should be all gimp-2.2, AFAIK. I'll ask him to check that everything 
> matches.

I've checked gimptool-2.0 in the 2.2 branch and indeed the --libs output
was missing the appropriate linker flags to also link against
libgimpmodule. Since libgimpui uses symbols from libgimpmodule, plug-ins
also need to link against it. I have now fixed this oversight in the
gimp-2-2 branch and 2.2.15 (to be released soon) will have this fix.

I recommend though that you change your Makefile to use pkg-config
instead of gimptool-2.0. The syntax is very similar and pkg-config is
well established nowadays.

So instead of using
  gimptool-2.0 --cflags --libs
please use
  pkg-config --cflags --libs gimpui-2.0


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm 07, top???5 GIMP user requests...

[Thorsten Wilms]

On Fri, May 25, 2007 at 02:15:32AM +0200, peter sikking wrote:

>  requests_25.html>

On 4. better painting tools:

So you propose to have brush models in tools like dodge/burn.
Why would this be preferable to having modes like dodge/burn inside 
brush tools?
Maybe brush model and mode should be handled separately?

A: The region/scope to work on
  - whole image
  - a layer/group/set
  - a selection
  - brush strokes as they happen
B: Options for above
  - mainly brush model with parameters comes to mind
C: The action or drawing mode to apply
  - transformations
  - filters
  - paint


On power modes

Sounds like a rather vague distinction, makes me wonder if 
is such a good idea to split the modes based on it.
Shouldn't layer and paint modes be kept the same?


dipping and smearing

Considering GIMP is not and shall not be painter ... but this would 
be very nice especially for drawing from scratch ;)


On versions and approaches

I have been using layers for versioning, backup, too. It just works.
Of course real, branched versioning would rock. How much I would like 
to see it everywhere. Maybe there's a chance of pushing part of the 
functionality out, so it can become part the environment and have 
a wider developer pool?


Regarding adjustment layers and GEGL

GEGL is graph based, somewhat comparable to the nodes in Blender, 
right? If so, the concept of a layer stack does not match GEGL.
I would propose to go all nodes and have no layers, if the layer 
stack wouldn't match the common case so nicely.


On window management

I have been thinking: What if GIMP was represented by a window with 
just the main menu. Image windows could be dockable palettes. Requires 
docking side-by-side. For SDI style, one would dock one image window 
and the inspectors all to the main window. Several images could docked 
together to have tabs.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Plugin compilation problems on 64 bit system

[David Hodson]

Sven Neumann wrote:

> Most probably a confusion with the development version. Is he/she trying
> to compile against gimp-2.2 or gimp-2.3?

Should be all gimp-2.2, AFAIK. I'll ask him to check that everything 
matches.


-- 
David Hodson  --  this night wounds time
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer