Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-25 Thread pcg
On Wed, Jun 22, 2005 at 11:53:18PM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
  That is, I think the fundamental flaw. A user interface that works for the
  majority is a pretty idiotic goal. A user interface should work for ALL
  users, and likely should have features to support the majority.
 
 Yeah, of course. If it works for all users, that's even better. Are
 you trying to make an argument out of this now?

Are you trying to argue? Maybe there is hope for you then, although the
above is not an argument. It's better than activey ignoring what people
write.

  So that argument is *completely* and *utterly* bogus, firstly
  because you equate majority==newbies, and secondly because it's not
  a viable goal at all.
 
 So let's see then. The goal is to please you and ignore the majority?

You have weird ways of deliberately misinterpreting and twisting other
persons words. What does it buy you? Time? Ignorance? Shying away people?

 Developers are also users. But the same argument holds true for users.
 You can't find out facts about a user interface by discussing it.

Yeah, that should work, except here, as you immediately drive ad-hominem
attacks and spread FUD (again...). I don't think it's even remotely
possible to really discuss these issues with you.

 at any discussion out there. It is always a few people who are very
 loud at complaining. Are these users representative? No, they aren't.

You jump to conclusions. Maybe they are, maybe they are not. But I already
said that designing just for the majority is an idiotic goal, one that
gtk+ certainly _does not follow_, so telling me that that goal would be a
good goal contradicts reality.

 agree on. But that is not the case here. So, that's why I have made
 the offer of organizing a usability test with the goal to gather some
 facts on the current design compared to whatever we can come up with
 as an alternative. Feel free to ignore that offer.

Well, I certainly didn't ignore it, and unfortunately you know that.

 But if you do, don't expect me to ever discuss user interface issues
 with you again.

Yes, we *know* that your goal is to talk down and ignore this issue. Hint:
you did succeed again.

 The original problem was you accusing me of ignorance. That has been
 proven to be a lie. So please don't continue with it.

Just because you claim something doesn't mean it is proven. Sorry, but
that really is what I think is happening. It's far from being a lie.

 Still you failed so far to give a detailed and useful description of
 your problems.

That's another of _your_ lies. Sorry to use that word, it's really
not appropriate, but aybe if I talk in your language communicaqtion
improves? I even pointed you to working code that exactly reproduces the
desired behaviour (but it's not gtk+2 compatible, if you meant that. And
if you meant that, say so).

 You listed a few things but you never got further than
 half a sentence on each of them.

Another of your lies. You tactics is very simple: people complain
and explain, and you accuse them of not explaining and lieing. Then
people explain some more (because they have no idea which part of
their explanatiomn you didn't understand) and then they get some more
accusations.

In the end, you simply ignore them in good shape, as you always tried to
discuss, it's always the others who play bad and fail to explain their
issues.

 I still don't know what your complaints really are but

You should certainly know *that* by now, even if you might miss some
details. If you are really that dense, then for your sake just *ask*
instead of just producing more accusations. Just because you don't
understand something does _not_ mean people tried hard to explain it. Just
review tis thread.

But as your goal is not discussion but ignoring others (for whatever maybe
understandable reasons), this only drives people away again, with no
resolution for either side. It's just too frustrating to explain things
again and again and be told to stop whining and start explaining things.

 that you want the text entry back.

Well, at least that part got through.

 A useful complaint includes use cases, describes a
 certain workflow and outlines where the current UI gets into your way.

This has been done multiple times. You keep ignoring this and ask for it.
Maybe you don't receive all of the mails from this list?

In any case, I just tried to point out to you that you factually do
ignore this kind of discussion (in a very active way, actually, but
nevertheless), but you still don't get it. I won't intrude further into
your world, as all I wanted to do has been done, even though I couldn't
get through to you like so many others couldn't.

I am out of here again

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread jernej
On Thursday, June 23, 2005, 2:18:57, Robert L Krawitz wrote:

 Here's one: add a text entry box at the bottom of the screen, and use
 a different key (say, shift-tab) for completion.

My suggestion would be to use Tab for completion, but only if the user typed
a few characters first - if he didn't, use Tab to jump to the next widget.
Another possibility would be the End key - I noticed that on Linux, Ctrl+L
dialog autocompletes the currently entered text (in Ctrl+L dialog - it
doesn't do this on Windows) and that you can already use End to confirm this
completion.

 I've seen quite a number of people -- Marc, Alastair Robinson, Bill
 Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael
 Thaler, and myself -- complain more or less vociferously about this,
 for what appears to be more or less the same reason.  Alan Horkan
 appears to have at least some complaints about it, Dennis Bjorklund
 appears to be defending it mildly, and you're defending it strongly.
 So by my count, we have

There's definitely more of us - otherwise no Windows port of GTK+ programs
would offer native Win32 dialogs, and there wouldn't be a plug-in for Gimp
that adds native dialogs.

-- 
 Jernej Simoncic  http://deepthought.ena.si/ 

Always remember to pillage before you burn.
   -- Attila's Instruction

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Sven Neumann
Hi,

Robert L Krawitz [EMAIL PROTECTED] writes:

 Isn't that at least enough reason to take a closer look at the
 issue?

Are you as well starting with this accusation now? We are taking a
close look at this. We have already spent a lot of time on this,
probably way more than we should. I have been contributing patches and
suggestions to the file-chooser for quite a while now. This has turned
the dialog into something that works rather well for me. Perhaps it is
time that you start doing that as well.

The only reason why someone sensible would complain on this subject on
the gimp-developer mailing list is that he/she wants to discuss the
issue in the context of using the dialog from within GIMP. The goal of
such a discussion should be to prepare a proposal or even patches in
order to present them to the GTK+ developers.

You complain, we talk about your complaints. What did you expect to
happen?


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Michael Schumacher
 Von: Bill Kendrick [EMAIL PROTECTED]

   * Don't try to access my A: drive every time a dialog appears.
 If I really cared about the A: drive (I don't), I'll probably click
 on the icon for it!  I heard others complain here that the file
 dialogs take FOREVER, since they try to hit every network file share
 on their Windows system.  Yuck!

Is this the current version of GTK+? This didn't happen for me since 2.6.7,
iirc.


Michael

-- 
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden  testen ++ http://www.gmx.net/de/go/promail ++
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Thu, 23 Jun 2005 10:35:51 +0200

   Robert L Krawitz [EMAIL PROTECTED] writes:

Isn't that at least enough reason to take a closer look at the
issue?

   Are you as well starting with this accusation now? We are taking a
   close look at this. We have already spent a lot of time on this,
   probably way more than we should. I have been contributing patches
   and suggestions to the file-chooser for quite a while now. This has
   turned the dialog into something that works rather well for
   me. Perhaps it is time that you start doing that as well.

The context for this was:

   Marc, it is you who's being idiotic here. You state that there are
   a number of people. What number? How large is that number compared
   to the number of happy users? We can hardly decide anything unless
   we know the answer to these questions.

You asked how many people were involved here.  I went and looked at
how many people have posted on precisely this issue, and posted my
numbers.

I've been contributing suggestions both here and on the
bugzilla.gnome.org bug (whose number I forget).  Yes, it's true that
my suggestion boils down to bring back the text entry box! and not a
whole lot else.  Every time anyone here makes that suggestion you
dismiss it with You basically have no clue on how the new dialog
works or I have already explained [how a text entry with completion
would conflict with being able to use the file dialog's other
features] without really getting to the heart of the matter -- a lot
of people just plain want a text entry box, because it's such a
natural way to work (a filename, or pathname for that matter, is a
text string, and people just want to be able to type it in a natural
manner).

   The only reason why someone sensible would complain on this subject
   on the gimp-developer mailing list is that he/she wants to discuss
   the issue in the context of using the dialog from within GIMP. The
   goal of such a discussion should be to prepare a proposal or even
   patches in order to present them to the GTK+ developers.

The only GTK2 app that I use on any kind of routine basis that uses
this dialog is the GIMP.  This has given me a good reason to do
everything I can to avoid other GTK2 apps.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Robert L Krawitz
   Date: Thu, 23 Jun 2005 07:43:07 -0400
   From: Robert L Krawitz [EMAIL PROTECTED]

   I've been contributing suggestions both here and on the
   bugzilla.gnome.org bug (whose number I forget).  Yes, it's true that
   my suggestion boils down to bring back the text entry box! and not a
   whole lot else.  Every time anyone here makes that suggestion you
   dismiss it with You basically have no clue on how the new dialog
   works or I have already explained [how a text entry with completion
   would conflict with being able to use the file dialog's other
   features]

Actually, I should correct myself here: the second comment (explaining
how the text entry would conflict is a legitimate explanation, not
merely dismissing objections.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Alan Horkan

to the number of happy users? We can hardly decide anything unless
we know the answer to these questions.

 I've seen quite a number of people -- Marc, Alastair Robinson, Bill
 Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael
 Thaler, and myself -- complain more or less vociferously about this,
 for what appears to be more or less the same reason.  Alan Horkan
 appears to have at least some complaints about it,

I do not disagree with Sven on this.  Please do not count me in on this
arguement, I probably should not have commented at all.  On balance the
new file chooser is better, it just happens to be worse in some of the
ways the old file chooser was good and I do recognise it has issues.

On balance I support the new File Chooser.  I see the problems with it as
mostly GTK problem.  You cannot really argue against the merits of a clean
API that allows you to go ahead and write your own replacement.  Now that
i think if it GPE are one of the few groups who have gone ahead and done
this, and I am increasingly tempted to attempt it myself (but dont hold
your breath it would take me a long time to develop something I would be
willing to show in public).

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Robert L Krawitz
   Date: Thu, 23 Jun 2005 21:13:41 +0100 (BST)
   From: Alan Horkan [EMAIL PROTECTED]

   I do not disagree with Sven on this.  Please do not count me in on
   this arguement, I probably should not have commented at all.  On
   balance the new file chooser is better, it just happens to be worse
   in some of the ways the old file chooser was good and I do
   recognise it has issues.

Fair enough.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-23 Thread Sven Neumann
Hi,

Robert L Krawitz [EMAIL PROTECTED] writes:

 I've been contributing suggestions both here and on the
 bugzilla.gnome.org bug (whose number I forget).  Yes, it's true that
 my suggestion boils down to bring back the text entry box! and not a
 whole lot else.  Every time anyone here makes that suggestion you
 dismiss it with You basically have no clue on how the new dialog
 works or I have already explained [how a text entry with completion
 would conflict with being able to use the file dialog's other
 features] without really getting to the heart of the matter -- a lot
 of people just plain want a text entry box, because it's such a
 natural way to work (a filename, or pathname for that matter, is a
 text string, and people just want to be able to type it in a natural
 manner).

Hey, what the heck is this about? I accept the fact that a lot of
people want the text entry back but I am not the maintainer of the
GtkFileChooser dialog so why do you care about my opinion? I will
continue to tell people that I don't think the text entry should be
added back but of course I don't care if it is being added back as
long as I can switch it off. If you want the text entry back, go add
it back. I even expect the GTK+ developers to accept a patch if it
works well and uses XSettings to make it optional.

 The only GTK2 app that I use on any kind of routine basis that uses
 this dialog is the GIMP.  This has given me a good reason to do
 everything I can to avoid other GTK2 apps.

If only I could get rid of the few apps that I still have to use that
don't use the new file chooser yet...


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Dennis Bjorklund
On Wed, 22 Jun 2005, Sven Neumann wrote:

 keyboard focus. In Inkscape it doesn't have the focus initially so you
 need to press tab several times before you can start to use the
 entry. As soon as you tab into the entry, your keyboard focus is
 grabbed there (well, there's Ctrl-Tab to get out of an entry but we
 aren't really improving on discoverability here...).

In the gtk2 dialog when you start to type you get a popup entry widget 
where you can only type in entries that are in the current file list.

From a user perspective I don't see any drawbacks if one could type in any 
path in that entry box, with tab completion. Currently this popup entry 
box is tied to TreeView and I don't know how easy it is to customize, but 
it's all part of gtk so anything can be changed.

For the popup entry box TAB doesn't need to work to jump to another widget 
since it's a popup. It's one level above the other widgets and a proper 
way to get out if it is to press escape.

I want to just be able to start with gimp and press these buttons

CTRL-O- open dialog
/tmp  - ends up in the popup entry and you can use TAB-completion
ENTER - show the temp directory in the dialog

or

CTRL-O
/tmp/foo.png- here I used tab-completion :-)
ENTER   - dialog closes and image is opened

In this last example one could also have it just select the filename and
then you press enter again to open it. That's a cleaner design but one
might sacrifice that for speed since the above is fairly clear also.

Very little typeing and I don't see that it will interfer with the 
current behaviour. This would also replace the CTRL-L stuff so it can be 
forgotten once and for all.

There is a small drawback in that the popup entry is a TreeView feature,
that work in a lot of treeviews to select an entry. Here it will work in a
different way. But I don't really see that as a problem since the new
behaviour is a proper superset of the current behaviour.

-- 
/Dennis

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Sven Neumann
Hi,

Dennis Bjorklund [EMAIL PROTECTED] writes:

 In the gtk2 dialog when you start to type you get a popup entry
 widget where you can only type in entries that are in the current
 file list.

 From a user perspective I don't see any drawbacks if one could type
 in any path in that entry box, with tab completion. Currently this
 popup entry box is tied to TreeView and I don't know how easy it is
 to customize, but it's all part of gtk so anything can be changed.

IMO it is important that typeahead in the file chooser works just like
typeahead in all other list and tree views. I don't think that
changing the behaviour of typeahead is a good idea. I also doubt that
it will silent the people asking for an entry box.

 CTRL-O- open dialog
 /tmp  - ends up in the popup entry and you can use TAB-completion
 ENTER - show the temp directory in the dialog

Here's what I do to achieve that:  Ctrl-O, /t, Enter

 CTRL-O
 /tmp/foo.png- here I used tab-completion :-)
 ENTER   - dialog closes and image is opened

Here's what I do to achieve that:  Ctrl-O, /t, Enter, f, Enter

Your proposal makes some sense, I am not convinced that it is a good
idea but it should probably be considered.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Sven Neumann
Hi,

Robert L Krawitz [EMAIL PROTECTED] writes:

 Sven, you've been offered a solution -- just add an entry with tab
 completion.  You may not agree with it, but it's not accurate to say
 that noone has made a proposal on how such an entry should be
 integrated with the current dialog.  Just stick it on the bottom of
 the dialog, just above the OK/cancel boxes, and Marc and I will be
 happy to shut up.

This is not about making you and Marc shut up. This is about designing
a user interface that works for the majority of users. Whatever we do,
there will always be someone complaining. I don't really care who that
is.

 In what way is just adding an entry with Tab completion going to
 ruin the whole thing?  If it's there, but isn't used, it isn't
 going to interfere with anything else, is it?

It does indeed interfere with the rest of the dialog, otherwise it
would probably have been added a while ago already. But I already
explained the problems of this approach in another mail that I sent
last night.

 And why is it so important that there be a concept for the entire
 dialog beyond what works best for people?  The problem (to me, and
 I daresay to Marc) is very simple -- there's no obvious way to
 simply enter a pathname with a simple form of completion that's only
 activated on demand.  A file dialog without this is just plain
 fatally flawed.

The problem is to find out what works best for people. Trying to
decide this in an argument among developers is very certainly going to
fail.

 Make it a configuration option, if you like.

No, I don't like configuration options, I hate them. And it would also
not have to be me who adds it but the GTK+ developers. We are
certainly not going to fiddle with the internals of the GtkFileChooser
widget.

 My first experience with the new configuration dialog was absolutely
 brutal.  I couldn't believe that I was being presented with a file
 dialog that had no text entry box (I spent a while exploring it to try
 to find the button that would give me the entry box), and given the
 way I jumble everything together, searching around in a list entry is
 hopeless (I have about 1000 files in one directory; I know a lot of
 the filenames by memory, but being forced to do a linear search
 through that many files is simply absurd).  I more or less stopped
 using the GIMP altogether for a while; I used Cinepaint or xv (!)
 despite it being obsolete in many ways where I could, and otherwise
 started a new instance of the GIMP each time I had to use it, because
 dealing with the file dialog was so hopeless.  Eventually after poking
 around Google I found the ctrl-L hack, but it's still very clumsy
 compared to the simplicity of a text entry box.

I agree that the Ctrl-L is clumsy and I would like it to be removed
(of course after it has been completely obsoleted). But you don't
really need Ctrl-L to use the dialog. I am sorry that you made your
first experiences with the new dialog with the early versions that
were indeed rather akward to use.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Dennis Bjorklund
On Wed, 22 Jun 2005, Sven Neumann wrote:

 IMO it is important that typeahead in the file chooser works just like
 typeahead in all other list and tree views. I don't think that
 changing the behaviour of typeahead is a good idea.

One can also say that it's important that typing in a path always works
the same in the dialog and having different things happen when you type
paths starting with / then paths without is also not good.

For example, what happens if you type ../foo ?

Didn't someone point out that the dialog was fixed so that when you type
in something it uses the typahead of the file list (I complained that
sometimes the bookmark list is focused in my verion of gtk+/gimp when I
open the dialog). Does that mean that you can't use type ahead on the
bookmark list?

Well, I described how I want it to work. We all have our dreams.

-- 
/Dennis

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Sven Neumann
Hi,

Dennis Bjorklund [EMAIL PROTECTED] writes:

 Didn't someone point out that the dialog was fixed so that when
 you type in something it uses the typahead of the file list (I
 complained that sometimes the bookmark list is focused in my verion
 of gtk+/gimp when I open the dialog). Does that mean that you can't
 use type ahead on the bookmark list?

If the bookmarks list has the keyboard focus (which it shouldn't have
initially), then you can of course use typeahead on the bookmarks
list.  Not sure what fix you are referring to but this seems to be
some kind of rumour.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Dennis Bjorklund
On Wed, 22 Jun 2005, Sven Neumann wrote:

 If the bookmarks list has the keyboard focus (which it shouldn't have
 initially), then you can of course use typeahead on the bookmarks
 list.

Good.

 Not sure what fix you are referring to but this seems to be some kind
 of rumour.

I couldn't find the mail now but I think someone in the thread said that 
typeahead now worked in the open dialog no matter what widget in it had 
the focus. Not important anyway, this problem is fixed as far as I 
understand.


Just for fun I put in an enhancement bug in the gtk bugzilla for making
the type ahead in the file dialog specialized for paths. So that you can
type bar/foo in it and jump directly to that sub directory. bar/foo is
not an entry in the current list view, just bar is in this example so it
would not work with normal type ahead. But making the type ahead
specialized for paths in the file dialog is as I described it before a 
good idea to me.

I don't really expect it to change anything, but maybe one could get some
comment from the gtk+ developers about the idea.

  http://bugzilla.gnome.org/show_bug.cgi?id=308618

And if you guys want to add anything to the bug, please be polite and 
don't make it into a flame-bug :-)

-- 
/Dennis

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread pcg
On Wed, Jun 22, 2005 at 12:59:33AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 Hi,
 
 [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
 
  Not a _single_ problem I described been changed (I originally
  assumed that the kills the selection problem has gone away, but
  it's still there).
 
 What is kills the selection? I haven't been able to make anything
 out of that term.

No problem: make a selection, open the file dialog, start typing = the
selection is gone (this is an illness that generally started to spread
within the last 6 months, at least I have never seen programs doing that
before, now lots of programs do that).

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread pcg
On Wed, Jun 22, 2005 at 12:18:34AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 all that bad compared to the former. Most of the complaints seem to
 come from people who got accustomed to the old dialog and haven't
 really tried to approach the new one yet w/o leaving the old habits
 behind. Of course that's an assumption but the discussions that
 evolved around these complaints seem to show that.

In the case of tab completion, you don't seriously want people to leave
the old habits behind?

That argument has a problem: old habits are not bad at all. Habits are bad
if they can be improved. But in this case, making tab completion slower
and/or more clumsy and difficult to use is not really a useful option.

Or, put in other words: just becasue it's new and difefrent doesn'T
automatically make it better.

  Yes, this is subjective, but you need to accept that some people
 
 Of course. That has never been questioned.

Well, many of the things you say certainly sound as if there would be only
one valid workflow, and whoever doesn't use it is mistaken (for a very
mild example see the old habits argument above. There is no logical
connection between old habits and bad habits).

 But I am not concerned with that, at least not as much as with the
 usability of GIMP for new and infrequent users.

Well, if those features get in the way of more experienced people, I'd be
strictly against it. But we can easily disagree on this point...

  (3) Don't try to advertise the old GtkFileSelection dialog as being
  the solution that we should revert too.
 
  I didn't. I did advertise the way the old file selection dialog used
  it's text entry as the solution for me (and others with similar
  complaints).
 
 So far noone has made a proposal on how such an entry should be
 integrated with the current dialog.

Argh.

Lots of people have. If you look closely, many people just asked for a
text entry. Integrating that into the dialog would make tab completion the
old way very natural.

Given that there *are* proposals, a) why do you say no one proposed it and
b) what would the possible problems be?

I can easily understand that keyboard shortcuts get in the way, but right
now, typing creates a tetx entry, so entering characters is already reserved
for that. Is it a limitation inside gtk+?

It would be great if you could enlighten us why the proposals don't work.

 So I don't have much chance but to assume that what you have in mind is
 basically the behaviour of the old dialog.

The behaviour with regards to having an entry widget and how it
works. Yes, I guess you completely understood that then.

 Perhaps you aren't suggesting to revert to it code-wise,

Certainly not.
   
 but I haven't yet seen a detailed proposal on how an entry with Tab
 completion is supposed to work without bringing back the problems we
 had with the old dialog.

I am not aware of any problems with regards to tab completion in the old
dialog. Talking about that might be quite productive.

 I certainly wouldn't want to miss the current key-navigation
 behaviour. But perhaps you can offer a viable alternative?

What is the current key navigation behaviour? cursor keys? I don't really
need cursor keys when I do tab completion, and when I need them, I could
easily use my mouse to click.

 Such an alternative would have to be a concept for the whole
 dialog. Just adding an entry with Tab completion is going to ruin the
 whole thing.

Well, the simplest solution would be some (non-gimp) preferences to enable
a text entry for those people who prefer it.

(Remember that I don't ask for people to implement that. My primary
concern is that the existing problems and complaints are (or were) being
talked down).

  It's main problem was that it was completely unusable for
  newcomers.
 
  Probably. I admit am not concerned with that.
 
 See. That is the main problem with your approach. You are only
 concerned with your needs.

That's obviously wrong. If I were the only one who'd like to have an
effective tab completion I would be very very silent. So no, I am not just
concerned with my needs, but with the needs of at least some more people.

 That is all valid but you should at least try to look at the bigger
 picture or else I don't see how we can get anywhere if we are discussing
 user interfaces.

Well, I am mostly concerned with my needs (and have said a lot of times
that you semed to have missed that I do understand that other needs need
to be satisfied, too) and you said you are mostly concerned with newbie
needs, so what's the big difference here?

Why is it bad when I say it but good when you say it? That makes no
sense...

  Well, well... but the gtk+ people who designed the current dialog
  vividly disagree with you on that. After all, the current dialog is
  full of features that are not discoverable.
 
 The question here is if the dialog works w/o discovering these
 features or if it leaves the average user frustrated. IMO the new
 dialog 

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Wed, 22 Jun 2005 10:12:05 +0200

   Robert L Krawitz [EMAIL PROTECTED] writes:

Sven, you've been offered a solution -- just add an entry with tab
completion.  You may not agree with it, but it's not accurate to say
that noone has made a proposal on how such an entry should be
integrated with the current dialog.  Just stick it on the bottom of
the dialog, just above the OK/cancel boxes, and Marc and I will be
happy to shut up.

   This is not about making you and Marc shut up. This is about
   designing a user interface that works for the majority of
   users. Whatever we do, there will always be someone complaining. I
   don't really care who that is.

This one seems to be attracting a disproportionate share of
complaints.  Usually with other controversial interface issues I see a
few comments, and then people start to converge.  This one is
different.

In what way is just adding an entry with Tab completion going to
ruin the whole thing?  If it's there, but isn't used, it isn't
going to interfere with anything else, is it?

   It does indeed interfere with the rest of the dialog, otherwise it
   would probably have been added a while ago already. But I already
   explained the problems of this approach in another mail that I sent
   last night.

If I understood correctly, it's a conflict between the use of tab for
completion and tab for jumping between widgets?  If so, how about
using a different keystroke for completion (escape or ctrl-tab, for
example)?

Perhaps another approach would be for the integrated text input to be
initially hidden, but with a More button that makes it visible.
The state of the More button is saved, so that the next time the
dialog is popped up it has the same components as it did before.

And why is it so important that there be a concept for the entire
dialog beyond what works best for people?  The problem (to me,
and I daresay to Marc) is very simple -- there's no obvious way
to simply enter a pathname with a simple form of completion
that's only activated on demand.  A file dialog without this is
just plain fatally flawed.

   The problem is to find out what works best for people. Trying to
   decide this in an argument among developers is very certainly going
   to fail.

The problem is that there's no one method that works best for
people.  People like Marc and I find the old dialog much more suited
to our needs than the new one.

Make it a configuration option, if you like.

   No, I don't like configuration options, I hate them. And it would
   also not have to be me who adds it but the GTK+ developers. We are
   certainly not going to fiddle with the internals of the
   GtkFileChooser widget.

Obviously the problem is a GTK issue, not a GIMP issue.

My first experience with the new configuration dialog was absolutely
brutal.  I couldn't believe that I was being presented with a file
dialog that had no text entry box (I spent a while exploring it to try
to find the button that would give me the entry box), and given the
way I jumble everything together, searching around in a list entry is
hopeless (I have about 1000 files in one directory; I know a lot of
the filenames by memory, but being forced to do a linear search
through that many files is simply absurd).  I more or less stopped
using the GIMP altogether for a while; I used Cinepaint or xv (!)
despite it being obsolete in many ways where I could, and otherwise
started a new instance of the GIMP each time I had to use it, because
dealing with the file dialog was so hopeless.  Eventually after poking
around Google I found the ctrl-L hack, but it's still very clumsy
compared to the simplicity of a text entry box.

   I agree that the Ctrl-L is clumsy and I would like it to be removed
   (of course after it has been completely obsoleted). But you don't
   really need Ctrl-L to use the dialog. I am sorry that you made your
   first experiences with the new dialog with the early versions that
   were indeed rather akward to use.

Two problems with this:

1) There's no visual cue that typing in a filename will do anything.

2) The secondary popup is very annoying (either it's going to pop up
   under the mouse, in which case it's going to obscure other parts of
   the dialog, or it isn't going to have focus for those of us who use
   focus strictly follows mouse).

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread pcg
On Tue, Jun 21, 2005 at 09:53:20PM -0400, Robert L Krawitz [EMAIL PROTECTED] 
wrote:
 people?  The problem (to me, and I daresay to Marc) is very simple --
 there's no obvious way to simply enter a pathname with a simple form
 of completion that's only activated on demand.

Actually, the old file selector didn't just have an entry to type in. As a
matter of fact, most file dialogs I know are very hard and unintuitive to
use, I often end up activating all sorts of things and often have to close
and reopen it to get into a sane state. Most motif programs fall intot hat
category.

Whta made the old dialog so special was that you could just type in paths as
you could elswhere in unix - namely via tab completion.

For example replacing tab by enter completely wrecks this feature, as this
is not at all intuitive, because enter usually means do it (either in
the shell or in a dialog), so people are not quick at pressing enter and
using it as a key to press oftentimes slows down considerably.

The thing is, the old dialog had this tremendously great and useful and
fats and efficient (whatever) feature that make it distinct to most other
file dialogs and extremely easy and joyful to use for me and all the
people around me (who incidentally also use a terminal and vim to to most
of their other tasks. Those people are not by any means rare in the unix
world, and making their life worse by making gimp more windows-like in
behaviour (such as the current file dialog does) is imho a very wrong
direction: People are not used to press enter after pathname components,
people are not used to use cursor-down/up to select between components, as
both of those usually destroy what you were typing).

_Everybody_ I showed that tab feature (that they didn't expect in clumsy
graphical programs), wether on trade shows or in private, was immediately
drawn in to how great it was. Similarly to the dynamic keyboard shortcuts
which are not disabled by default.

Those fetaures had definitely a discoverability problem, but the new field
dialog is IMHO worse with respect to discovering those features.

I feel (And judging from the feedback I am not alone) that removing those
features (or making them harder to use) in the name of usability is the
wrong approach. Making everything easy for newbies most often means
making it more difficult for regular users. sometimes you can find a
compromise, such as with the menu bar (again, a discoverability problem),
sometimes you cannot (if tab completion is fundamentally incompatible with
newbie-support).  Incidentally, lots of those things have been solved by
supporting both styles and using preferences to switch, and while not a
perfect solution, it might well the achievable optimum.

 using the GIMP altogether for a while; I used Cinepaint or xv (!)
 despite it being obsolete in many ways where I could, and otherwise
 started a new instance of the GIMP each time I had to use it, because
 dealing with the file dialog was so hopeless.  Eventually after poking
 around Google I found the ctrl-L hack, but it's still very clumsy
 compared to the simplicity of a text entry box.

This experience is close to mine, and close to the experiences of the people
around me.

It seems sven's standpoint is that this just needs to some more
experience, or learning the new way of using the dialog, but I have to use
those dialogs for quite some time now, and I simply don't believe that
I am too dumb or too stubborn for the new dialog, but that it's simply
slowing me down at best.

 Bookmarks are of no use to me because I have a lot of files that I
 work with whose names I generally know by memory.

[Agree with all of that. The great thing is, however, that bookmarks don't
seem to collide with a text entry, so one could have both, which is just
great, and a win-win situation].

 Anyone who tells me that I should organize my files differently
 will be told (politely or otherwise) to fsck off.

The irony is that one gets told that the old way would be somehow inferior
without any evidence and lots of evidence to the contrary. It's new and
completely different, so it must be better.

 frankly I can't believe what I see there (e. g. file dialogs should go
 away, and everything should be done through the file manager or some
 such).  This is design for its own sake rather than design for what's
 actually usable.

A lot of people feel that way.

 I have half a mind to do a fork of GTK+ just to fix the file dialog.
 This would really be an insane thing for me to do.

Yes, it would :( It's a waste of time.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread pcg
On Wed, Jun 22, 2005 at 10:12:05AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 This is not about making you and Marc shut up. This is about designing
 a user interface that works for the majority of users. Whatever we do,
 there will always be someone complaining. I don't really care who that
 is.

That is, I think the fundamental flaw. A user interface that works for the
majority is a pretty idiotic goal. A user interface should work for ALL
users, and likely should have features to support the majority.

The simple goal of works for the majority is nothing short of a
dictatorship (while in a democracy the majority rules, the fundamental
point of democracy is minority rights).

If that *were* the goal, why have things like ATK, which are decidedly not
for the majority? And who decides what the majority is? The newbies? I am
not sure newbies are the majority of gimp users (but I am pretty sure at
some point in ther future this will be the case).

So that argument is *completely* and *utterly* bogus, firstly because you
equate majority==newbies, and secondly because it's not a viable goal at
all.

  And why is it so important that there be a concept for the entire
  dialog beyond what works best for people?  The problem (to me, and
  I daresay to Marc) is very simple -- there's no obvious way to
  simply enter a pathname with a simple form of completion that's only
  activated on demand.  A file dialog without this is just plain
  fatally flawed.
 
 The problem is to find out what works best for people. Trying to
 decide this in an argument among developers is very certainly going to
 fail.

I disagree, and I haven't actually seen evidence of that, despite hearing
that a lot, I don't think developers are somehow worse off then users.
Despite, I am unfortunately a mere gimp _user_ right now.

This is basically the same argument, where you exchanged the majority by
people, and it has the same flaws. I _am_ part of that people, as are
you and other developers.

The easiest way to find out is to try it, and see how it works. This is
currently what's being done, and you can't complain about the negative
(and also positive) feedback, so it seems to be the correct approach.

  Make it a configuration option, if you like.
 
 No, I don't like configuration options, I hate them.

Others would love them!

(In most cases there are unavoidable, wether it's themes or keyboard
layout.  Some people simply have different preferences. And while you hate
preferences some people would be rather better of with them).

 And it would also not have to be me who adds it but the GTK+
 developers. We are certainly not going to fiddle with the internals of
 the GtkFileChooser widget.

Yes, the discussion has become a little bit out of bounds for
gimp-developer again. Just remember that the original problem was the
attitude of yours with regards to user complaints (or suggestions).

  despite it being obsolete in many ways where I could, and otherwise
  started a new instance of the GIMP each time I had to use it, because
  dealing with the file dialog was so hopeless.  Eventually after poking
  around Google I found the ctrl-L hack, but it's still very clumsy
  compared to the simplicity of a text entry box.
 
 I agree that the Ctrl-L is clumsy and I would like it to be removed
 (of course after it has been completely obsoleted). But you don't
 really need Ctrl-L to use the dialog. I am sorry that you made your
 first experiences with the new dialog with the early versions that
 were indeed rather akward to use.

Well, it's not as if this has fundamentally changed till the current
version.  You seem to relate all the bad user experiences to old versions,
but that is not true. I based my initial response on gtk+-2.6.7, and now
used gtk+-2.6.8, which is exactly the version you asked people to try.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Leon Brooks
On Wednesday 22 June 2005 16:12, Sven Neumann wrote:
 Whatever we do, there will always be someone complaining. I don't
 really care who that is.

While it's fundamentally true, it's also a heavily defeatist approach. 
What I'd like is a complicated device folded down to simple proportions 
so that dolts don't hurt themselves with it - but that can be easily 
and permanently defaulted to something more useful for people who are 
not and never will be the lowest common denominator.

Cheers; Leon

-- 
http://cyberknights.com.au/ Modern tools; traditional dedication
http://plug.linux.org.au/   Member, Perth Linux User Group
http://slpwa.asn.au/Member, Linux Professionals WA
http://osia.net.au/ Member, Open Source Industry Australia
http://linux.org.au/Member, Linux Australia
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Joao S. O. Bueno Calligaris
On Tuesday 21 June 2005 20:30, Sven Neumann wrote:

 If you just add an entry to the current dialog you don't get the
 current dialog with the extra benefit of an entry with Tab
 completion. Unfortunately what you get is a dialog that has two
 orthogonal ways of navigating it with the keyboard and both ways
 keep getting into the way of each other.


Ok - What about this: Hitting the easy and intuitive CTRL + L, 
instead of cluttering everything else with a pop-up, make such an 
entry field to appear, with focus in it?

Therefore, nothing else would be on the way of one who can spend about 
a minute or two navigating the file structure and clicking on a file, 
while thos eint he know cna hit ctrl+L for soemthing actually 
usefull. 

Joao
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Alan Horkan

On Wed, 22 Jun 2005, Robert L Krawitz wrote:

 Date: Wed, 22 Jun 2005 07:32:11 -0400
 From: Robert L Krawitz [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: gimp-developer@lists.xcf.berkeley.edu
 Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of
 GIMP

From: Sven Neumann [EMAIL PROTECTED]
Date: Wed, 22 Jun 2005 10:12:05 +0200

Robert L Krawitz [EMAIL PROTECTED] writes:

 Sven, you've been offered a solution -- just add an entry with tab
 completion.  You may not agree with it, but it's not accurate to say
 that noone has made a proposal on how such an entry should be
 integrated with the current dialog.  Just stick it on the bottom of
 the dialog, just above the OK/cancel boxes, and Marc and I will be
 happy to shut up.

This is not about making you and Marc shut up. This is about
designing a user interface that works for the majority of
users. Whatever we do, there will always be someone complaining. I
don't really care who that is.

 This one seems to be attracting a disproportionate share of
 complaints.  Usually with other controversial interface issues I see a
 few comments, and then people start to converge.  This one is
 different.

It is unfortunate that the new file chooser is bad at exactly the things
the old file chooser was good at, a case of six of one half dozen of the
other.  (I always have a terminal open and make frequent use of
gimp-remote so I dont mind to the new file chooser too much.)

 In what way is just adding an entry with Tab completion going to
 ruin the whole thing?  If it's there, but isn't used, it isn't
 going to interfere with anything else, is it?

It does indeed interfere with the rest of the dialog, otherwise it
would probably have been added a while ago already. But I already
explained the problems of this approach in another mail that I sent
last night.

 If I understood correctly, it's a conflict between the use of tab for
 completion and tab for jumping between widgets?  If so, how about
 using a different keystroke for completion (escape or ctrl-tab, for
 example)?

 Perhaps another approach would be for the integrated text input to be
 initially hidden, but with a More button that makes it visible.
 The state of the More button is saved, so that the next time the
 dialog is popped up it has the same components as it did before.

 And why is it so important that there be a concept for the entire
 dialog beyond what works best for people?  The problem (to me,
 and I daresay to Marc) is very simple -- there's no obvious way
 to simply enter a pathname with a simple form of completion
 that's only activated on demand.  A file dialog without this is
 just plain fatally flawed.

The problem is to find out what works best for people. Trying to
decide this in an argument among developers is very certainly going
to fail.

 The problem is that there's no one method that works best for
 people.  People like Marc and I find the old dialog much more suited
 to our needs than the new one.

 Obviously the problem is a GTK issue, not a GIMP issue.

There seems to be a big benefit to developers in using the new File
Chooser API.  I am a little surprised no one has ported the old file
chooser to the new API, or written any alternative file choosers that work
with the new API.  (There was definately some talk of adding support for
the KDE file chooser to use the Gtk File Chooser API by developers
connected with Freedesktop.org or Redhat I think but I am pretty sure
nothing ever came out of those wild ideas but the Gtk Developers would be
the ones to ask I guess.)

I notice some projects have added support for the new file chooser to make
it a compile time option but mostly as a way to avoid forcing their users
to use the latest version of GTK.  I expect the gimp requires an up to
date version of GTK for other other reasons but perhaps support for the
old file chooser could be added as a compile time option (horribly
inelegant and another unpleasant configuration option I know but I wanted
to put it out there as a possibility).

- Alan H.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Alastair M. Robinson

Hi,
Alan Horkan wrote:


It is unfortunate that the new file chooser is bad at exactly the things
the old file chooser was good at, a case of six of one half dozen of the
other.  (I always have a terminal open and make frequent use of
gimp-remote so I dont mind to the new file chooser too much.)


Yes, I do that too.  I alias it to gr, so the only penalty is an extra 
mouse click and one extra keypress.


That we both go to these lengths to avoid using the new dialog says 
something.


To my mind the biggest problem with the old dialog was that it's 
*really* ugly to look at!  It also looks reminiscent of the old Windows 
3.1 file dialog, which is a big turn-off to some people...



I notice some projects have added support for the new file chooser to make
it a compile time option but mostly as a way to avoid forcing their users
to use the latest version of GTK.  I expect the gimp requires an up to
date version of GTK for other other reasons but perhaps support for the
old file chooser could be added as a compile time option (horribly
inelegant and another unpleasant configuration option I know but I wanted
to put it out there as a possibility).


I seem to remember early versions of Page Plus had a very good way of 
balancing the needs of experienced and new users; you could set the user 
interface between three modes, beginner, medium and expert, which 
determined how many of the advanced features were visible.


Later versions broke out in a nasty case of Wizarditis, but they at 
least had the sense to make it possible to disable them.


I think ultimately, something like this might be the answer - not for 
The GIMP, but for GTK+ - if I could set a flag in my .gtkrc file to say 
I'm not a novice, don't try and shield me from complexity I'd be a lot 
happier!


All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread jernej
On Wednesday, June 22, 2005, 13:47:03,  Marc)(A.)(Lehmann  wrote:

 Whta made the old dialog so special was that you could just type in paths as
 you could elswhere in unix - namely via tab completion.

 For example replacing tab by enter completely wrecks this feature, as this
 is not at all intuitive, because enter usually means do it (either in
 the shell or in a dialog), so people are not quick at pressing enter and
 using it as a key to press oftentimes slows down considerably.

I can think of 2 or 3 ways of doing autocompletion that would be more
intuitive than how it's currently implemented - Enter is the last thing I
tried, because in all other software that offers autocompletion with the
help of an automatic drop-down (not just in file dialogs), Enter will
confirm the current selection and dismiss the dialog. (btw, there are other
things that GTK+2 just does bothersome differently from every other piece of
software I use - including differently from GTK+1 programs).

 It seems sven's standpoint is that this just needs to some more
 experience, or learning the new way of using the dialog, but I have to use
 those dialogs for quite some time now, and I simply don't believe that
 I am too dumb or too stubborn for the new dialog, but that it's simply
 slowing me down at best.

I found it easier to use Windows' Exploder to navigate to the directory
where my images are and double-click the image there than to use Gimp's open
dialog (and I absolutely hate Explorer).

 [Agree with all of that. The great thing is, however, that bookmarks don't
 seem to collide with a text entry, so one could have both, which is just
 great, and a win-win situation].

IMHO, the bookmarks would be even more usable if they appeared at the top of
the list, not bottom - I've got a lot of network and physical drives, so I
need to scroll the list to get to the bookmarks (another argument for this
is that you can always create bookmarks for the default items in that list
if you want to have those at the top).

-- 
 Jernej Simoncic  http://deepthought.ena.si/ 

If the probability of success is not almost one, then it is damned near zero.
   -- Fourth Law of Thermodynamics

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread jernej
On Wednesday, June 22, 2005, 18:29:57, Alastair M. Robinson wrote:

 To my mind the biggest problem with the old dialog was that it's
 *really* ugly to look at!  It also looks reminiscent of the old Windows 
 3.1 file dialog, which is a big turn-off to some people...

That one was more useful - I liked having the directory tree separate, and
it had a text entry (although without any completion).

-- 
 Jernej Simoncic  http://deepthought.ena.si/ 

You're not drunk if you can lie on the floor without holding on.
   -- Dean Martin's Definition of Drunkenness

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Sven Neumann
Hi,

Robert L Krawitz [EMAIL PROTECTED] writes:

 The problem is that there's no one method that works best for
 people.  People like Marc and I find the old dialog much more suited
 to our needs than the new one.

The GtkFileChooser widget was designed to be modular from the very
beginning. There is a reason why the current implementation lives in a
file called gtkfilechooserdefault.c. What keeps you from writing a
different implementation that implements the GtkFileChooser interface?

 Two problems with this:

 1) There's no visual cue that typing in a filename will do anything.

I don't think that's a problem because the dialog is still usable
without knowing about this and sooner or later the user will find
out. After all typeahead is something that works in all list views.

 2) The secondary popup is very annoying (either it's going to pop up
under the mouse, in which case it's going to obscure other parts of
the dialog, or it isn't going to have focus for those of us who use
focus strictly follows mouse).

Didn't I say already that the secondary popup is bad and should go
away? What point are you trying to make?


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Sven Neumann
Hi,

Alastair M. Robinson [EMAIL PROTECTED] writes:

 I seem to remember early versions of Page Plus had a very good way of
 balancing the needs of experienced and new users; you could set the
 user interface between three modes, beginner, medium and expert, which
 determined how many of the advanced features were visible.

That has been tried several times (with nautilus for example) and it
has never worked. The problem is that you will very soon need a
feature that is only available in the Advanced mode and then you get
tons of expert features cluttering your user interface.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

 That is, I think the fundamental flaw. A user interface that works for the
 majority is a pretty idiotic goal. A user interface should work for ALL
 users, and likely should have features to support the majority.

Yeah, of course. If it works for all users, that's even better. Are
you trying to make an argument out of this now?

 So that argument is *completely* and *utterly* bogus, firstly
 because you equate majority==newbies, and secondly because it's not
 a viable goal at all.

So let's see then. The goal is to please you and ignore the majority?
Marc, you have yourself said that you don't care about other users.
Why should we care about you then?

 The problem is to find out what works best for people. Trying to
 decide this in an argument among developers is very certainly going
 to fail.

 I disagree, and I haven't actually seen evidence of that, despite
 hearing that a lot, I don't think developers are somehow worse off
 then users.

Developers are also users. But the same argument holds true for users.
You can't find out facts about a user interface by discussing it. Look
at any discussion out there. It is always a few people who are very
loud at complaining. Are these users representative? No, they aren't.
All the happy users will never join a mailing-list and tell us that
they like the user interface. You will only hear from them if you
actually change something. Then, given that they disagree with that
change, they will suddenly be there, loud and clear. So it should be
clear that it is a waste of time to discuss user interface questions
unless they can be boiled down to some simple rules that everyone can
agree on. But that is not the case here. So, that's why I have made
the offer of organizing a usability test with the goal to gather some
facts on the current design compared to whatever we can come up with
as an alternative. Feel free to ignore that offer. But if you do,
don't expect me to ever discuss user interface issues with you again.

 Yes, the discussion has become a little bit out of bounds for
 gimp-developer again. Just remember that the original problem was the
 attitude of yours with regards to user complaints (or suggestions).

The original problem was you accusing me of ignorance. That has been
proven to be a lie. So please don't continue with it.

 Well, it's not as if this has fundamentally changed till the current
 version.  You seem to relate all the bad user experiences to old
 versions, but that is not true. I based my initial response on
 gtk+-2.6.7, and now used gtk+-2.6.8, which is exactly the version
 you asked people to try.

Still you failed so far to give a detailed and useful description of
your problems. You listed a few things but you never got further than
half a sentence on each of them. I still don't know what your
complaints really are but that you want the text entry back. A useful
complaint includes use cases, describes a certain workflow and
outlines where the current UI gets into your way.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Thu, 23 Jun 2005 00:09:06 +0200

   [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

Lots of people have.

   Sorry but I haven't seen a detailed and complete proposal yet. If
   you can point me to one, please do.

Here's one: add a text entry box at the bottom of the screen, and use
a different key (say, shift-tab) for completion.

Attach this label to the entry box:

Filename: (to complete, type shift-tab)

I certainly wouldn't want to miss the current key-navigation
behaviour. But perhaps you can offer a viable alternative?
   
What is the current key navigation behaviour? cursor keys? I
don't really need cursor keys when I do tab completion, and when
I need them, I could easily use my mouse to click.

   Oh well. I had the impression all along this discussion. You
   basically have no clue on how the new dialog works. That doesn't
   shed a good light on the new dialog but it also shows that you are
   rather ignorant. I think I asked you and everyone else to actually
   try to work with the dialog. I guess I will have to sit down and
   write a manual since you obviously haven't understood how it works.

I could just as easily say that you have no clue how Marc or I work --
please keep the personal attacks out of it.  You did ask Marc to try
to work with the new dialog, he complied, and found it didn't help
him.

Or, put difefretly: in what ways would a tetx entry with
completion conflict with being able to use the file dialogs other
features with the mouse (and then: with the keyboard).

   I have already explained that in all details. See my other mail in
   this thread in case you missed earlier explanations.

As best as I can tell, the only substantive issue is the fact that the
tab key, if used for completion, would conflict with the tab key, as
used to jump around the other widgets.  I propose using a different
key sequence -- shift-tab -- for completion.

If a number of users complain about usability issues, askign them to make
scientific studies before their complaints can be taken seriously is just
plain idiotic.
   
What counts is reality, and the current file dialogs, wether they worked
in studies or not, fail this for quite a number of people.

   Marc, it is you who's being idiotic here. You state that there are
   a number of people. What number? How large is that number compared
   to the number of happy users? We can hardly decide anything unless
   we know the answer to these questions.

I've seen quite a number of people -- Marc, Alastair Robinson, Bill
Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael
Thaler, and myself -- complain more or less vociferously about this,
for what appears to be more or less the same reason.  Alan Horkan
appears to have at least some complaints about it, Dennis Bjorklund
appears to be defending it mildly, and you're defending it strongly.
So by my count, we have

Oppose/strongly oppose 7
Mildly oppose  1
Mildly support 1
Strongly support   1

Is this proof?  No.  Perhaps the majority of GIMP/GTK users who are
not on the list strongly prefer the new dialog.  However, my
experience on the net suggests that if there were other people on the
list who strongly support the new dialog that at least a few of them
would have popped up by now.  What's more, the complaints are all very
specific, and are focused on exactly the same issue -- the lack of a
text entry box for a filename.  Nobody here is complaining about
anything else.  Isn't that at least enough reason to take a closer
look at the issue?

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Bill Kendrick

On Wed, Jun 22, 2005 at 08:18:57PM -0400, Robert L Krawitz wrote:
 Here's one: add a text entry box at the bottom of the screen, and use
 a different key (say, shift-tab) for completion.

The problem with Shift-Tab is that it's often used to navigate backwards
through widgets in GUIs.

Honestly, isn't this the kind of thing that should be getting standardized,
e.g. by FreeDesktop.org?

-bill!
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Bill Kendrick
On Wed, Jun 22, 2005 at 08:18:57PM -0400, Robert L Krawitz wrote:
 Nobody here is complaining about anything else.

Actually, at least with Gimp 2.2 on WinXP (which is what I'm sitting in
front of right now), I have issues with Save As behaviour:

  * Once I've saved a newly-created image in a particular place, use THAT as
the default Save-As location, not My Pictures.  If I'm doing artwork for
a video game, for example, I have to add Yet Another Bookmark to the Save
dialog, or navigate around for EVERY new image I make.  I'd love it if it
would remember between sessions, too!

  * Don't try to access my A: drive every time a dialog appears.
If I really cared about the A: drive (I don't), I'll probably click
on the icon for it!  I heard others complain here that the file
dialogs take FOREVER, since they try to hit every network file share
on their Windows system.  Yuck!

Thx :)

-bill!
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread pcg
On Tue, Jun 21, 2005 at 01:02:34AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
  I don't know what I am smoking, but this very compaint has come up
  a number of times, and your only reaction is to talk it down.
 
 That is a blatant lie. The reaction to these concerns is that me and

This is the end of reasonable discussion with you again. Too bad you
immediately call other people liars and worse. Couldn'T you simply be
reasonable?

 these concern with Federico and other GTK+ developers, entering bug
 reports and writing patches to fix them. The fact that you completely
 ignore this and stick to your lies is becoming rather insulting.

I did not even claim that you didn't and where did I ignore this.

What's your problem? Accusing me of saying things I clearly haven't again?
Accusing me of not having said things that you assume I think? Come on,
get a life...

  No, it does not at all work surprisingly well. It is *extremely*
  slow, it hinders, it flickers, it destroys the selection, it pops up
  a window. It feels like an ugly kludge and certainly does not wor
  surprisingly well.
 
 I cannot reproduce most of your problems.

Which would be? Why does your inability to partly reproduce problems mean
that I cannot be taken seriously?

 At least not from this description. If you want to be taken seriously,
 then please come up with serious descriptions and make sure that
 comprehensive and useful bug reports exist for them.

You cannot reproduce some aspect of my description but others so claim
I can't be taken seriously. That is *exactly* the kind of tactics that
annoys so many people: They report sth., you have a problem with some
aspect of their descriptino so you dismiss it all.

Don't other people simply deserve to be taken seriously, especially if
_so_many_people_ report the same kind of problems? It's juts as I said: you
ignore or talk down these issues.

Fact is, people agree that the way the gtk+-1 file selector worked with
regards to text entry and tab completion has no problems. So all this
wiggly-waggly we don't know what you mean is pretty dumb:

I repeat: The behaviour of thre gtk+-1.0 file dialog with regards to text
entry and tab completion is *exactly* what people want, and even if it
weren't, it's most close. It's exactly what I said earlier, too.

All the questions on what to do are completely superfluous, as there even
exists working code that explains what people need.

What happens instead is that we see kludge after kludge and claims that
these kludges would be superior. If the gtk+ developers would want to help
they would just listen to the users.

And you accuse me of lieing and claim I can't be taken seriously. Don't
you realize something? Just because you can bully other people and silence
them (well, not all fortunately) does not mean you are right. But I said
that before, and you simply don't want to understand that or improve the
situation. You need a serious attitude change when dealing with people.

  You also said file dialogs should go away (in some distant future) and
  people should use dragdrop.
 
 You misunderstood me.

If you say so, then it is so. If I were you I'd just accuse you of lieing
:(
  
Sorry, but that's not at all funny.

 I didn't say that DND is going to replace file choosers. I said that
 sooner or later most people will not even know about the concept of
 hierarchical file systems. That doesn't mean that they will be dragging
 in files from file managers. File managers will also cease to exist (at
 least for a large user group).

Yeah, I have seriously misinterpretetd what you said when you actually
meant that.

Have fun!

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread jernej
On Tuesday, June 21, 2005, 1:02:34, Sven Neumann wrote:

 No, it does not at all work surprisingly well. It is *extremely*
 slow, it hinders, it flickers, it destroys the selection, it pops up
 a window. It feels like an ugly kludge and certainly does not wor
 surprisingly well.
 I cannot reproduce most of your problems. At least not from this
 description. If you want to be taken seriously, then please come up
 with serious descriptions and make sure that comprehensive and useful
 bug reports exist for them.

I definitely can - typing paths in the Ctrl+L dialog looks like this to me:
type a drive letter and :, see them both appear while typing, continue
typing, but see no feedback for several seconds while it's checking the
files - the native Win32 dialog boxes show the autocomplete list both much
faster, and doesn't interfere with my input even when it takes a few seconds
for the list to appear.

I'll write a more complete list of the things that bother me in the file
dialog in the evening.

-- 
 Jernej Simoncic  http://deepthought.ena.si/ 

Logic is a systematic method of coming to the wrong conclusion with confidence.
   -- Manley's Maxim

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Jakub Steiner
On Tue, 2005-06-21 at 13:02 +0200, [EMAIL PROTECTED] wrote:
 On Tuesday, June 21, 2005, 1:02:34, Sven Neumann wrote:
 
  No, it does not at all work surprisingly well. It is *extremely*
  slow, it hinders, it flickers, it destroys the selection, it pops up
  a window. It feels like an ugly kludge and certainly does not wor
  surprisingly well.
  I cannot reproduce most of your problems. At least not from this
  description. If you want to be taken seriously, then please come up
  with serious descriptions and make sure that comprehensive and useful
  bug reports exist for them.
 
 I definitely can - typing paths in the Ctrl+L dialog looks like this to me:
 type a drive letter and :, see them both appear while typing, continue
 typing, but see no feedback for several seconds while it's checking the
 files - the native Win32 dialog boxes show the autocomplete list both much
 faster, and doesn't interfere with my input even when it takes a few seconds
 for the list to appear.
 
 I'll write a more complete list of the things that bother me in the file
 dialog in the evening.

Hi Jernej,
I believe you missed the type-ahead functionality:

http://jimmac.musichall.cz/demos/gimp/file-dialog-rocks.avi

Some notes about the video which may not be obvious - the focus issues
are history and the dialog accepts input even if you clicked on the
shortcuts. At one point I messed up and entered the wrong directory. I
used the nautilus shortcut alt+up to go up.

The new file dialog is a pleasure to use to me, mainly because of the
bookmarks. I spend less time browsing deep hierarchies and achieve
file-related tasks faster than I used to. 

cheers

-- 
Jakub Steiner [EMAIL PROTECTED]
Novell, Inc.

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread jernej
On Tuesday, June 21, 2005, 17:29:52, Jakub Steiner wrote:

 I believe you missed the type-ahead functionality:

I know of type-ahead, but it's not an adequate replacement for a real
path+file text entry. This is how I usually browse for files:
http://deeperthought.ena.si/autocompletion.htm (I only used Enter key
once, when I had the complete path to file entered and wanted to open the
file).

-- 
 Jernej Simoncic  http://deepthought.ena.si/ 

At any level of traffic, any delay is intolerable.
   -- Brigg's Law of Traffic

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Tino Schwarze
On Tue, Jun 21, 2005 at 07:16:25PM +0200, [EMAIL PROTECTED] wrote:
 On Tuesday, June 21, 2005, 17:29:52, Jakub Steiner wrote:
 
  I believe you missed the type-ahead functionality:
 
 I know of type-ahead, but it's not an adequate replacement for a real
 path+file text entry. This is how I usually browse for files:
 http://deeperthought.ena.si/autocompletion.htm (I only used Enter key
 once, when I had the complete path to file entered and wanted to open the
 file).

I liked the way a lot it was with GIMP 2.0 (GTK 2.2 IIRC): Just type
parts of file or directry, hit tab, voila, just like the shell (the
dropdown with possible completions is optional).

Bye, Tino.

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

 This is the end of reasonable discussion with you again. Too bad you
 immediately call other people liars and worse. Couldn'T you simply be
 reasonable?

Huh? Is it all over already? That would be a pity.

 these concern with Federico and other GTK+ developers, entering bug
 reports and writing patches to fix them. The fact that you completely
 ignore this and stick to your lies is becoming rather insulting.

 I did not even claim that you didn't and where did I ignore this.

Well, you said that I would be deliberately ignoring user complaints
and that is just plain wrong. I may tend to disagree with a lot of the
complaints but that is mostly because I also hated the new filechooser
dialogs in the beginning but over time the widgets have matured and in
the meantime I really like them. I completely agree that the dialogs
were pretty much unsuable when they appeared in GTK+ 2.4 and I feel
sad whenever I learn that people are still using GIMP with GTK+ 2.4.
But there isn't really anything I can do about that.

 I cannot reproduce most of your problems.

 Which would be? Why does your inability to partly reproduce problems
 mean that I cannot be taken seriously?

I simply want you and anyone else who wants to have a discussion on
the file-chooser to do three things:

(1) Use the latest GTK+ 2.6 release. Most of the problems that you and
others mentioned have been addressed in the meantime and it
doesn't really make sense to have a discussion on bugs that are
already fixed.

(2) Take a step back and try to understand the concepts behind the new
dialog. There is room for improvement but the overall design is
good. It is good because it works for newcomers and it still has a
lot to offer to the expert user.

(3) Don't try to advertise the old GtkFileSelection dialog as being
the solution that we should revert too. That widget sucked badly.
It's main problem was that it was completely unusable for
newcomers. It had exactly one feature to overcome its limitations
and that was Tab completion. Without Tab completion the old dialog
was pretty much unusable. The problem here is that Tab completion
is not something that people can discover. At least not the larger
part of our userbase. So if you want to revert to the old dialog,
don't expect to be taken seriously. If you insist on being taken
seriously with this approach, please show me evidence to back up
your claims. I might trust a usability test but I am certainly not
taking your word on what is good user interface and what's a bad
one.

So as long as you can try to even consider these three points, we can
probably have a very interesting discussion and perhaps it might even
lead to something useful.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread pcg
On Tue, Jun 21, 2005 at 10:48:15PM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 Huh? Is it all over already? That would be a pity.

I won't let you drga me down to that level of discussion. So when you want
to rant about lies and accusations, feel free to do so without me.

  I cannot reproduce most of your problems.
 
  Which would be? Why does your inability to partly reproduce problems
  mean that I cannot be taken seriously?
 
 I simply want you and anyone else who wants to have a discussion on
 the file-chooser to do three things:
 
 (1) Use the latest GTK+ 2.6 release. Most of the problems that you and
 others mentioned have been addressed in the meantime and it
 doesn't really make sense to have a discussion on bugs that are
 already fixed.

While there are some changes, fundamentally it's the same behaviour as in
2.6.7. It's simply slowing down users who just want to type in paths.

 (2) Take a step back and try to understand the concepts behind the new
 dialog. There is room for improvement but the overall design is
 good. It is good because it works for newcomers and it still has a
 lot to offer to the expert user.

As I told you before: for using the dialogs, it doesn't matter wether the
design is a beauty in itself or wether it is spaghetti code. What counts is
how it works for the user. And the new dialog is still not up to the level
of usefulness as the gtk+-1.0 one, despite your continual claims to the
contrary.

Yes, this is subjective, but you need to accept that some people have
different workflows and different styles of user interaction, and for some
people, the above statement is true.

 (3) Don't try to advertise the old GtkFileSelection dialog as being
 the solution that we should revert too.

I didn't. I did advertise the way the old file selection dialog used it's
text entry as the solution for me (and others with similar complaints).

For some reason you really want to misinterpret that again and again, but
I am convinced that enough people have made this clear, so there really
is no reason to imply that those who complain want to revert tot he old
dialog.

 That widget sucked badly.

Well, it sucked much less than the current dialog in some important
respects, like text entry and completion.

 It's main problem was that it was completely unusable for
 newcomers.

Probably. I admit am not concerned with that.

 It had exactly one feature to overcome its limitations
 and that was Tab completion.

That was really great, and was ripped from the users, to be put back step
for step and in a still very suboptimal fashion.

 Without Tab completion the old dialog
 was pretty much unusable.

Well, that's quite subjective, but I think it sufficed quite nicely for
the simple task of selecting files. It was no worse than most other file
dialogs around. The new dialogs have many more potentially useful features
(even for me). The pity is that the old pretty unusable file dialog was
much more supportive than the current one (again, for me, and at least the
few others who have complained similalry).

I'd take it back everyday, regardless of what it means for other
I'users.

Now, before you accuse me of asking you to revert the dialog *again*: no,
I did not mean to say that, and I did not say that, if you read closely.

 The problem here is that Tab completion
 is not something that people can discover. At least not the larger
 part of our userbase. So if you want to revert to the old dialog,
 don't expect to be taken seriously.

Well, well... but the gtk+ people who designed the current dialog vividly
disagree with you on that. After all, the current dialog is full of
features that are not discoverable.

You should explain why you outright refuse to consider tab completion
(I interpret not taken seriously as an refusal to seriously consider
something), even though it's part of the current design and despite the fact
that people actualyl complain about discoverability issues with the *new*
file dialogs.

If discoverability of features is the goal of the new dialogs, they
clearly failed.

 If you insist on being taken seriously with this approach, please
 show me evidence to back up your claims.

I, and others, did so. I know you want to ignore it (and you do). I just
find it annoying of you to ask or details again and again and the accuse
people of not providing details (or worse). If you want to ignore it
anyways, just say so, so people can stop wasting their time.

It should be *extremely* and *crystal* clear of what people want: a
visible text entry, and tab completion as in the old gtk+ file selector.
There is even code that shows the behaviour.

I don't know what evidence you want, to be taken seriously. Isn't people
arguing for it all the evidence you need?

 So as long as you can try to even consider these three points, we can
 probably have a very interesting discussion and perhaps it might even
 lead to 

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

 As I told you before: for using the dialogs, it doesn't matter
 wether the design is a beauty in itself or wether it is spaghetti
 code. What counts is how it works for the user. And the new dialog
 is still not up to the level of usefulness as the gtk+-1.0 one,
 despite your continual claims to the contrary.

I believe that we got more complaints about the old dialog than we got
about the new one. At least not since the worst problems of the new
dialog have been fixed. That makes me think that the new dialog isn't
all that bad compared to the former. Most of the complaints seem to
come from people who got accustomed to the old dialog and haven't
really tried to approach the new one yet w/o leaving the old habits
behind. Of course that's an assumption but the discussions that
evolved around these complaints seem to show that.

 Yes, this is subjective, but you need to accept that some people
 have different workflows and different styles of user interaction,
 and for some people, the above statement is true.

Of course. That has never been questioned. But I am not concerned with
that, at least not as much as with the usability of GIMP for new and
infrequent users.

 (3) Don't try to advertise the old GtkFileSelection dialog as being
 the solution that we should revert too.

 I didn't. I did advertise the way the old file selection dialog used
 it's text entry as the solution for me (and others with similar
 complaints).

So far noone has made a proposal on how such an entry should be
integrated with the current dialog. So I don't have much chance but to
assume that what you have in mind is basically the behaviour of the
old dialog. Perhaps you aren't suggesting to revert to it code-wise,
but I haven't yet seen a detailed proposal on how an entry with Tab
completion is supposed to work without bringing back the problems we
had with the old dialog. I certainly wouldn't want to miss the current
key-navigation behaviour. But perhaps you can offer a viable
alternative? Such an alternative would have to be a concept for the
whole dialog. Just adding an entry with Tab completion is going to
ruin the whole thing.

 It's main problem was that it was completely unusable for
 newcomers.

 Probably. I admit am not concerned with that.

See. That is the main problem with your approach. You are only
concerned with your needs. That is all valid but you should at least
try to look at the bigger picture or else I don't see how we can get
anywhere if we are discussing user interfaces.

 Well, well... but the gtk+ people who designed the current dialog
 vividly disagree with you on that. After all, the current dialog is
 full of features that are not discoverable.

The question here is if the dialog works w/o discovering these
features or if it leaves the average user frustrated. IMO the new
dialog does a better job because it works somewhat better even before
you discover that it can be used without the mouse.

 You should explain why you outright refuse to consider tab
 completion (I interpret not taken seriously as an refusal to
 seriously consider something), even though it's part of the current
 design and despite the fact that people actualyl complain about
 discoverability issues with the *new* file dialogs.

Your interpretation is nuts then. I have never said anything against
Tab completion. Actually I very much welcome the changes to the
completion behaviour in the Save dialog that came with GTK+ 2.6.8. If
you tried, you might have noticed that you can finally use the Tab key
to expand to the common prefix of existing files. That was one of the
concerns that were taken from GIMP users to the people actually
working on the file-chooser. It took a while but I think that it now
works quite well.

 If discoverability of features is the goal of the new dialogs, they
 clearly failed.

I agree that there are too many undiscoverable features, like Ctrl-L
(which is probably just there to kill the trolls) and the more useful
keybindings which are carefully hidden away.

 If you insist on being taken seriously with this approach,
 please show me evidence to back up your claims.

 I, and others, did so.

Marc, I am sorry, but your own personal user experience is not
evidence. Nor is mine or anyone else's. I admit that it isn't fair to
ask for evidence here because you and me both don't have the resources
to deliver facts about the usability of these dialogs. It would
certainly be interesting, and probably helpful, to actually collect
such data and compare different file dialogs in carefully designed
tests with a variety of users.

If you or someone else can come up with a detailed mockup of an
alternative dialog and if we could write a prototype that actually
works, I am quite confident that we could persuade someone to do a
usability test on it.


Sven
___
Gimp-developer mailing list

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread jernej
On Wednesday, June 22, 2005, 0:18:34, Sven Neumann wrote:

 So far noone has made a proposal on how such an entry should be
 integrated with the current dialog.

What's wrong with the place Inkscape puts it?

-- 
 Jernej Simoncic  http://deepthought.ena.si/ 

All inanimate objects can move just enough to get in your way.
   -- Law of Inanimate Mobility

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

 Not a _single_ problem I described been changed (I originally
 assumed that the kills the selection problem has gone away, but
 it's still there).

What is kills the selection? I haven't been able to make anything
out of that term.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] writes:

 So far noone has made a proposal on how such an entry should be
 integrated with the current dialog.

 What's wrong with the place Inkscape puts it?

The place is probably OK, despite my feeling that it adds clutter. The
real problem though is that an entry only makes sense if it has the
keyboard focus. In Inkscape it doesn't have the focus initially so you
need to press tab several times before you can start to use the
entry. As soon as you tab into the entry, your keyboard focus is
grabbed there (well, there's Ctrl-Tab to get out of an entry but we
aren't really improving on discoverability here...). Of course one
could focus the entry initially but then you wouldn't be able to
navigate the file list with the keyboard any longer or use typeahead
which IMO gives more direct feedback than Tab completion.

If you just add an entry to the current dialog you don't get the
current dialog with the extra benefit of an entry with Tab
completion. Unfortunately what you get is a dialog that has two
orthogonal ways of navigating it with the keyboard and both ways keep
getting into the way of each other.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-21 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Wed, 22 Jun 2005 00:18:34 +0200

(3) Don't try to advertise the old GtkFileSelection dialog as being
the solution that we should revert too.
   
I didn't. I did advertise the way the old file selection dialog used
it's text entry as the solution for me (and others with similar
complaints).

   So far noone has made a proposal on how such an entry should be
   integrated with the current dialog. So I don't have much chance but
   to assume that what you have in mind is basically the behaviour of
   the old dialog. Perhaps you aren't suggesting to revert to it
   code-wise, but I haven't yet seen a detailed proposal on how an
   entry with Tab completion is supposed to work without bringing back
   the problems we had with the old dialog. I certainly wouldn't want
   to miss the current key-navigation behaviour. But perhaps you can
   offer a viable alternative? Such an alternative would have to be a
   concept for the whole dialog. Just adding an entry with Tab
   completion is going to ruin the whole thing.

Sven, you've been offered a solution -- just add an entry with tab
completion.  You may not agree with it, but it's not accurate to say
that noone has made a proposal on how such an entry should be
integrated with the current dialog.  Just stick it on the bottom of
the dialog, just above the OK/cancel boxes, and Marc and I will be
happy to shut up.

In what way is just adding an entry with Tab completion going to ruin
the whole thing?  If it's there, but isn't used, it isn't going to
interfere with anything else, is it?  And why is it so important that
there be a concept for the entire dialog beyond what works best for
people?  The problem (to me, and I daresay to Marc) is very simple --
there's no obvious way to simply enter a pathname with a simple form
of completion that's only activated on demand.  A file dialog without
this is just plain fatally flawed.

Make it a configuration option, if you like.  Just stick the text
entry box with tab completion anywhere on the dialog -- I really don't
care where, as long as it's part of the dialog, not some silly pop-up
box, and I don't have to do something each time that I want to
activate it (since I'm personally going to use the text entry box
every time I want to open a file, even one extra keystroke or mouse
gesture adds up over time, while if it's a configuration option I only
have to do it once).

My first experience with the new configuration dialog was absolutely
brutal.  I couldn't believe that I was being presented with a file
dialog that had no text entry box (I spent a while exploring it to try
to find the button that would give me the entry box), and given the
way I jumble everything together, searching around in a list entry is
hopeless (I have about 1000 files in one directory; I know a lot of
the filenames by memory, but being forced to do a linear search
through that many files is simply absurd).  I more or less stopped
using the GIMP altogether for a while; I used Cinepaint or xv (!)
despite it being obsolete in many ways where I could, and otherwise
started a new instance of the GIMP each time I had to use it, because
dealing with the file dialog was so hopeless.  Eventually after poking
around Google I found the ctrl-L hack, but it's still very clumsy
compared to the simplicity of a text entry box.

Bookmarks are of no use to me because I have a lot of files that I
work with whose names I generally know by memory.  They don't scale;
after you have more than maybe 10-20 of them it runs into the same
problem of searching, whereas my memory for my own images is
associative (reasonably close to constant time lookup).  I'm also
absolutely hopeless at maintaining any kind of organization of this
kind.  Anyone who tells me that I should organize my files differently
will be told (politely or otherwise) to fsck off.  I've used emacs for
over 20 years (hence the preference for a simple filename entry with
tab completion), and this form of organization for much longer than
that (long before I knew what a computer was), and this way of working
is by now completely ingrained into me.  I'm a slob who simply dumps
things wherever it's convenient.  In addition to having to remember
where files were, if I were to reorganize everything I'd have to mess
around with kimdaba for a while to get everything back to how I have
it.

I've read some of the stuff on the GNOME mailing lists, and quite
frankly I can't believe what I see there (e. g. file dialogs should go
away, and everything should be done through the file manager or some
such).  This is design for its own sake rather than design for what's
actually usable.

I have half a mind to do a fork of GTK+ just to fix the file dialog.
This would really be an insane thing for me to do.  I really need to
put my very limited free software time into Gutenprint, or at least
dcraw, not this.  If I'm so exasperated by the file dialog that I

Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread pcg
On Mon, Jun 20, 2005 at 12:40:37AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 Perhaps you should stop looking at the dialog and just blindly enter
 paths. It works surprisingly well.

I just told you that this is not true.

Then you told me you'd not ignore complaints.

Now you tell me what I should do instead and that it would work surprisingly
well.

I don't know what I am smoking, but this very compaint has come up a number
of times, and your only reaction is to talk it down.

No, it does not at all work surprisingly well. It is *extremely* slow, it
hinders, it flickers, it destroys the selection, it pops up a window. It
feels like an ugly kludge and certainly does not wor surprisingly well.

But you should know that.

We can argue wether it works surprisingly well because it's not clear
what it means. To me, this surprisingly well working input is an annoyance
and slow-down compared to the simple and fast gtk+1.0 selector. Just
compare it to your typical shell: path input time: very few seconds. gtk+:
ranging form 5+ seconds to minutes (not counting the time it takes to open
the dialog). And no flickering in the shell, no extra popups and it does
not even destroy your selection.

Obvously, the very term surprisingly well is meaningless because other
people have different definitons for what works well.

And you keep ignoring this. Really. Maybe you just don't understand it. I
don't know. I am 100% sure it's not malice!

One thing is that people, and _many_ people, just want their location
entry back, for lots of reasons: discoverability, pastability and so
on. But for some reason this simply does not happen.

This is an example where lots of people continually *are* being ignored
because the new design is supposedly better.

 There's no such atttitude. The new file chooser has bugs and they need
 to be fixed. Asking us to revert to the old widget is however not an
 option.

That might be true, but *if* the old widget was better for the users it
should be reverted, no question to be asked. Again, there is an *if* in
that sentence.

(Also, I really don't see the many bugs. I see misdesign, but I would not
call that a bug. There were design decisions involved, and these might be
good for some uses and bad for others. At least the problems I have with
the dialogs do not seem to be bugs at all, but simply design decisions).

I often heard argumnts like it was a lot of work to design and
implement, but there is a logical fallacy in that (a red herring): no
matter how much work it was, if the result is bad, it is bad.

(Now, there are probably good sides to the new file dialog, but none of
the new features mean anything to me, so for me it is only negative).

You also said file dialogs should go away (in some distant future) and
people should use dragdrop. This is another very bad way to force
unnatural (for some) workflow on people: for one thing, dragdrop
doesn't work very wlel under X, for another thing it is quite difficult
to actually dragdrop while prpessing your mouse button for some
people. Even I who can easily do drgadrop find for example the selection
much easier, because I can do things in etween and do not have to press
hte button all the time, which improves my aim.

The new file dialog gets more and more byzantine, without offering the
simple and effective interface that the old dialog. Now I hear in the long
term people should switch from it completey.

That is the wrong direction, IMHO.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread Dennis Bjorklund
On Mon, 20 Jun 2005, Marc wrote:

 One thing is that people, and _many_ people, just want their location
 entry back, for lots of reasons: discoverability, pastability and so
 on. But for some reason this simply does not happen.

Do you want this only in gimp or in all programs that use the gtk+ 
widgets and dialogs?

I think the gtk dialog can be made better and should be improved for all 
applications, not just gimp.

Things I don't like: 

* In fedora 3 I can type in a filename and it selects that file in the
file tree view and it just works. It does not work with full paths so I
either have to navigate to the correct directory first (which I usually do
using a bookmark) or have to use the hidden feature of Ctrl-L (almost
never do this). If one fixes so one can type in any path directly, and not
just filenames in the current selected dir, then the Ctrl-L is not needed
anymore.

* The file tree view does not always have input focus when the dialog is
opened. So sometimes when I type in a filename the focus is in the
bookmark part of the dialog and it matches a bookmark instead. Also, some
keys to fast give bookmarks and filelist input focus would be nice (and
tab:ing to the right widget is too much work).


I've not filed any bugs for the above and I don't know if maybe this have
already been improved in later versions of gtk+ then what's in FC3.  It's
simply not a big enough problem for me that I've done that but I still 
would want these things to be improved.

The battle for you to fight is with gtk2 and not with gimp. If gimp
started to use another dialog then what other gtk2 programs did, then
people would start a fight about that.

I also think that some of you in this thread are unfair to Sven. From my
point of view he tries to help as much as he can.

For you reverting to the old dialog is a solution, for me that would make
the dialog a lot worse. I love the bookmark feature. I usually just use a
couple of directories in total and I have these as bookmarks.

Currently not everyone is happy with the new dialog but hopefully it can
be improved so most of us are happy in the future. If not, then what do 
you suggest? Either way you choose someone will be unhappy.

-- 
/Dennis

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread Robert L Krawitz
   Date: Mon, 20 Jun 2005 11:14:03 +0200 (CEST)
   From: Dennis Bjorklund [EMAIL PROTECTED]

   On Mon, 20 Jun 2005, Marc wrote:

One thing is that people, and _many_ people, just want their location
entry back, for lots of reasons: discoverability, pastability and so
on. But for some reason this simply does not happen.

   Do you want this only in gimp or in all programs that use the gtk+
   widgets and dialogs?

Obviously this is a GTK2 issue.

   Currently not everyone is happy with the new dialog but hopefully
   it can be improved so most of us are happy in the future. If not,
   then what do you suggest? Either way you choose someone will be
   unhappy.

Adding a simple file (text) entry box with tab completion (and a
preference to turn on autocompletion) would, IMHO, solve virtually all
of the problems.  People who don't like using text entry boxes
wouldn't have to use it.  The ctrl-L popup has lots of problems; not
only is it not apparent how to get to it (there's nothing that points
at ctrl-L), but it's very clumsy to use (you have to type ctrl-L, type
in the filename -- while having to deal with its quirks -- and then
click OK twice).

And no, bookmarks are NOT a complete solution to this.  I have
probably 200 bookmarks in Firefox (for example), and finding the right
bookmark in the list takes a while (I have to scan through the list
and find the one I want).  As far as images go, I currently have about
70 directories with images (65 subdirectories for my digital camera,
and some miscellaneous ones).  The camera ones have 100-200 each (in a
lot of cases I have two copies of each image, one the JPEG file
extracted from the raw image and another one converted using my
hacked-up dcraw), and a couple of the others have 1000 each.
Navigating through all of this is a real pain; the ones I'm most
interested in I simply memorize.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread Dennis Bjorklund
On Mon, 20 Jun 2005, Robert L Krawitz wrote:

 Adding a simple file (text) entry box with tab completion (and a
 preference to turn on autocompletion) would, IMHO, solve virtually all
 of the problems.

Or just make the current system work better. In my installation you can 
type in a filename, one just need to add tab-completion to it and make it 
support full paths. For example, I want to just be able to type /tmp and 
press enter and then the dialog changes to that dir. I can't do that 
today.

As I said, I don't know what happend in later versions of gtk then what is
in FC3, it might already be improved (you can always hope :-).

 The ctrl-L popup has lots of problems; not only is it not apparent how
 to get to it (there's nothing that points at ctrl-L), but it's very
 clumsy to use (you have to type ctrl-L, type in the filename -- while
 having to deal with its quirks -- and then click OK twice).

No one say that the CTRL-L is any good. It's just a workaround for those
of us that are used to tab completion, until we have something better. I 
hope it can work as explained above in the future.
 
 and find the one I want).  As far as images go, I currently have about
 70 directories with images (65 subdirectories for my digital camera,
 and some miscellaneous ones).

Maybe you need one bookmark to the parent and not 65 bookmarks to all 
subdirectories,

 Navigating through all of this is a real pain; the ones I'm most
 interested in I simply memorize.

Right, and I make bookmarks of the places I use the most.

Anyway, what I said was just that going back to the old dialog removes the
bookmark feature that I use a lot. So no matter if you use the new or old
dialog one of us will be unhappy. Not that going back seems to be an 
option, but if it was I would be against it.

-- 
/Dennis

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread John Cupitt
On 6/20/05, Dennis Bjorklund [EMAIL PROTECTED] wrote:
 On Mon, 20 Jun 2005, Robert L Krawitz wrote:
 
  Adding a simple file (text) entry box with tab completion (and a
  preference to turn on autocompletion) would, IMHO, solve virtually all
  of the problems.
 
 Or just make the current system work better. In my installation you can
 type in a filename, one just need to add tab-completion to it and make it
 support full paths. For example, I want to just be able to type /tmp and
 press enter and then the dialog changes to that dir. I can't do that
 today.
 
 As I said, I don't know what happend in later versions of gtk then what is
 in FC3, it might already be improved (you can always hope :-).

Yes, this works fine the the current gtk2, although with drop-down
completion rather than tab completion.

John
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread Robert L Krawitz
   Date: Mon, 20 Jun 2005 13:59:44 +0200 (CEST)
   From: Dennis Bjorklund [EMAIL PROTECTED]

The ctrl-L popup has lots of problems; not only is it not
apparent how to get to it (there's nothing that points at
ctrl-L), but it's very clumsy to use (you have to type ctrl-L,
type in the filename -- while having to deal with its quirks --
and then click OK twice).

   No one say that the CTRL-L is any good. It's just a workaround for
   those of us that are used to tab completion, until we have
   something better. I hope it can work as explained above in the
   future.

Unless they've changed it further, you still don't have the text entry
box visible.

and find the one I want).  As far as images go, I currently have
about 70 directories with images (65 subdirectories for my
digital camera, and some miscellaneous ones).

   Maybe you need one bookmark to the parent and not 65 bookmarks to
   all subdirectories,

I don't really need bookmarks at all for this.  I simply want to type

/images/dcim/138canon/crw_3888.jpg

(to identify a particularly interesting photo of a sunset in Bermuda,
for example) without the dialog trying to helpfully (and slowly)
autocomplete through all of that mess and without having to open a
second, modal dialog (I thought that modal dialogs are supposed to be
really bad juju?).

Actually, the more common issue I deal with as Gutenprint lead
developer is that I print an image named colors4.tif to a file
(usually I name it /tmp/b.prn).  I then run a command named unprint
to generate a .pnm file from the output:

unprint  /tmp/b.prn  /tmp/b.pnm

following which I want to inspect that file (to see the effect that
changes I've made to the Gutenprint source have made certain changes
to the output, without having to waste a lot of ink and paper).  The
problem here is that colors4.tif lives in /images, so if I open a file
from that context, I'm in /images whereas I really want to open a file
in /tmp (as you can guess, a file named /tmp/b.pnm can be opened very
quickly with 11 keystrokes if the dialog doesn't get in my way).

A variation I might do is to look at just one color plane.  While
working on the Epson Stylus Photo R800 with its red and blue inks,
for example, I might want to see the effect that changes in this code
have on the red ink generation:

unprint -m 100  /tmp/b.prn  /tmp/b100.pnm

or even

for f in 1 2 4 8 100 200 ; do unprint -m $f  /tmp/b.prn  /tmp/b$f.pnm

to get individual PNM's of each color plane separately (needless to
say, I don't retype that command each time; I use ctrl-p in bash for
that purpose).  Since /tmp is usually full of all kinds of garbage,
scrolling around in there in the new dialog isn't much fun.  I
sometimes use Cinepaint (taking the hit in extra memory consumption
from having both the GIMP and Cinepaint running at the same time) to
view these files just because the GTK2 dialog is so unwieldly for my
purpose.

Again: adding a simple text entry box for the filename, with tab
completion but not autocompletion, would entirely solve my problem
here!

Navigating through all of this is a real pain; the ones I'm most
interested in I simply memorize.

   Right, and I make bookmarks of the places I use the most.

   Anyway, what I said was just that going back to the old dialog
   removes the bookmark feature that I use a lot. So no matter if you
   use the new or old dialog one of us will be unhappy. Not that going
   back seems to be an option, but if it was I would be against it.

I have no problem with bookmarks, but I just don't think they're a
panacea.  The reason I mentioned bookmarks is that the various bug
reports, mailing list discussions, etc. seem to promote bookmarks
heavily.  For my purpose (at least with the GIMP) they're not useful.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread Dennis Bjorklund
On Mon, 20 Jun 2005, Robert L Krawitz wrote:

 Again: adding a simple text entry box for the filename, with tab
 completion but not autocompletion, would entirely solve my problem
 here!

And I would be happy if you could enter these things in the entry box that 
pop up when you just start to type.

Maybe one should do some hacking and simply make some LD_PRELOAD hack that 
replaces the dialog in gtk with almost the same one but with an entry 
box added. Not very pretty but it could help some people.. Maybe a project 
for someone to play with during some lonely weekend.

-- 
/Dennis

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread pcg
On Mon, Jun 20, 2005 at 11:14:03AM +0200, Dennis Bjorklund [EMAIL PROTECTED] 
wrote:
  One thing is that people, and _many_ people, just want their location
  entry back, for lots of reasons: discoverability, pastability and so
  on. But for some reason this simply does not happen.
 
 Do you want this only in gimp or in all programs that use the gtk+ 
 widgets and dialogs?

My understanding is that the dialog (mostly) resides in gtk+, and yes, I
would want this functionality everywhere.

 I think the gtk dialog can be made better and should be improved for all 
 applications, not just gimp.

Agree.

 * In fedora 3 I can type in a filename and it selects that file in the
 file tree view and it just works. It does not work with full paths so I

At leats in gtk+-2.6 (probably earlier, too), you can start typing the path
and a location window will pop up. For absolute paths, start with /.

 never do this). If one fixes so one can type in any path directly, and not
 just filenames in the current selected dir, then the Ctrl-L is not needed
 anymore.

That should be done in gtk+-2.6 already.

 * The file tree view does not always have input focus when the dialog is
 opened. So sometimes when I type in a filename the focus is in the
 bookmark part of the dialog and it matches a bookmark instead.

I guess if the focus is that inconsistent you should check wether it's still
behaving that way in gtk+-2.6 and report it as a bug if it is.

 I've not filed any bugs for the above and I don't know if maybe this have
 already been improved in later versions of gtk+ then what's in FC3.  It's
 simply not a big enough problem for me that I've done that but I still 
 would want these things to be improved.

Well, eventually newer versins will arrive at your desktop. If you report it
by then that should be fine. The more annoying a problem is the earlier it
will be reported (and, unfortunately more often).

 The battle for you to fight is with gtk2 and not with gimp. If gimp
 started to use another dialog then what other gtk2 programs did, then
 people would start a fight about that.

I'm not trying to battle with either the gimp or gtk+. I am trying to
battle the continuous attitude of neglecting that there are problems for
some users.

My understanding here is that the new file dialog has nice features that
improve it for many users. I am willing to pay the price of having a less
optimal interface in favour of supporting most (hopefully) other users.

The reasoning is that I often have a different workflow than the majority
so what's good for me is not necessarily good for others. One could change
behaviou base don some preferences, but that would priarily be my job to
code. As long as I don't code it as I want it, I cannot complain that others
don't do it for me.

I think I can complain, however, whe other people claim that problems don't
exist.

 For you reverting to the old dialog is a solution,
   
If I think about it, yes, that would be by far the best solution for me.
   
 for me that would make
 the dialog a lot worse.

I am fully aware of some features beign useful to others. That's why I always
and clearly wrote me when refering to the usefulness of any such features.

 be improved so most of us are happy in the future. If not, then what do 
 you suggest? Either way you choose someone will be unhappy.

No, you can still go the preferences way and support both (or more) UI
interactions. I am not complaining about missing code, I am merely
complaining about neglecting that problems exist repeatedly, which
unncessarily drives people mad.

The most negative side effect of such comments is that you get endless
threads on the issue: every comment of the style it works will provoke
reactions like no, it doesn't.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-20 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

 I don't know what I am smoking, but this very compaint has come up
 a number of times, and your only reaction is to talk it down.

That is a blatant lie. The reaction to these concerns is that me and
other GIMP developers have spent a lot of our free time discussing
these concern with Federico and other GTK+ developers, entering bug
reports and writing patches to fix them. The fact that you completely
ignore this and stick to your lies is becoming rather insulting.

 No, it does not at all work surprisingly well. It is *extremely*
 slow, it hinders, it flickers, it destroys the selection, it pops up
 a window. It feels like an ugly kludge and certainly does not wor
 surprisingly well.

I cannot reproduce most of your problems. At least not from this
description. If you want to be taken seriously, then please come up
with serious descriptions and make sure that comprehensive and useful
bug reports exist for them.

 You also said file dialogs should go away (in some distant future) and
 people should use dragdrop.

You misunderstood me. I didn't say that DND is going to replace file
choosers. I said that sooner or later most people will not even know
about the concept of hierarchical file systems. That doesn't mean that
they will be dragging in files from file managers. File managers will
also cease to exist (at least for a large user group).


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [gwidion@mpc.com.br: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-19 Thread Sven Neumann
Hi,

[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:

 to be the case with the early implementations but certainly not with
 the latest GTK+ 2.6 releases. The file dialog is getting better and
 better with each release.

 You keep repeating this as if it were some kind of religion - why do you
 ignore the people who simply disagree? Of course the new dialogs have many
 more features, but they are _much_ less usable for _some_ people. This is
 a simple fact.

 You should really accept that, even if it works for you, and even if you
 cannot understand it.

I do accept that but I would like people to point out exactly what
problems they have instead of just saying that they dislike the new
dialogs. Without detailed complaints we can't do anything to improve
the situation.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-19 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
[Fileselector]
 I do accept that but I would like people to point out exactly what
 problems they have instead of just saying that they dislike the new
 dialogs. Without detailed complaints we can't do anything to improve
 the situation.

What occurred to me recently: The absence of a discoverable filename
entry makes it quite hard to paste a filename into the fileselector.

(plus the extra popping up window is quite annoying)

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-19 Thread pcg
On Sun, Jun 19, 2005 at 11:53:32AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
  You should really accept that, even if it works for you, and even if you
  cannot understand it.
 
 I do accept that

For some reaosn I cna hardly believe that after reading your original
posting. You simply show no sign of understanding for the preferences
other people have, as if one-size-fits-all would be the perfect solution.

 but I would like people to point out exactly what
 problems they have instead of just saying that they dislike the new
 dialogs.

... but people do that. And you tell them this is the gimp and not the
right place to do that. This is contradictory.

 Without detailed complaints we can't do anything to improve
 the situation.

Well, let's make an example (this has been said before):

I would like to have the file open and save dialogs work the same as the
ones in gtk+-1.0, with typing paths into the dialog and tab completion.

If you want details then exactly as in gtk+-1.0 should suffice, because
that dialog simply worked. No extra window, no slow extra popups that you
have to wait for, no fancy and distracting _hiliting_, no stealing of the
current selection etc. etc. Basically I want to be able to blindly enter
paths as I could with gimp-1.0, press enter and presto - saved or loaded,
with no other die effects.

Now, lots of people want other things, for example bookmarks etc. I don't,
and some others don't either. There is great diversity. I am not even able
to find out wether the file dialog I would like to have is even remotely
compatible with the file dialogs other people want to have. I can only say
that nice features I found both cool and supportive have been removed, and
not been put back in, with the new file dialogs.

I am not telling you to go and fix it (it ain't even broken!). Other
features have been removed or made more difficult or different to use as
well and it seems the majority of users found this an improvement. I can
live with that.

What I simply find annoying is this there is no problem attitude. I
would find a there are problems, but we will not go back to that for the
very few users who liked it attitude much much better.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [gwidion@mpc.com.br: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-19 Thread Sven Neumann
Hi,

Marc Lehmann [EMAIL PROTECTED] writes:

 For some reaosn I cna hardly believe that after reading your original
 posting. You simply show no sign of understanding for the preferences
 other people have, as if one-size-fits-all would be the perfect solution.

Huh? I've been collecting the wishes and problems regarding the file
selector, making sure that the GTK+ developers are aware of the
problem and even patching the file selector myself. We have also done
quite some changes to the gimp file dialogs since the switch to the
new GtkFileChooser widget. If you want to suggest that I would be
ignoring the complaints, I really don't know what you've been smoking.

 If you want details then exactly as in gtk+-1.0 should suffice,
 because that dialog simply worked. No extra window, no slow extra
 popups that you have to wait for, no fancy and distracting
 _hiliting_, no stealing of the current selection etc. etc. Basically
 I want to be able to blindly enter paths as I could with gimp-1.0,
 press enter and presto - saved or loaded, with no other die effects.

Perhaps you should stop looking at the dialog and just blindly enter
paths. It works surprisingly well.

 What I simply find annoying is this there is no problem
 attitude. I would find a there are problems, but we will not go
 back to that for the very few users who liked it attitude much much
 better.

There's no such atttitude. The new file chooser has bugs and they need
to be fixed. Asking us to revert to the old widget is however not an
option.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-19 Thread Robert L Krawitz
   From: Sven Neumann [EMAIL PROTECTED]
   Date: Mon, 20 Jun 2005 00:40:37 +0200

If you want details then exactly as in gtk+-1.0 should suffice,
because that dialog simply worked. No extra window, no slow extra
popups that you have to wait for, no fancy and distracting
_hiliting_, no stealing of the current selection
etc. etc. Basically I want to be able to blindly enter paths as I
could with gimp-1.0, press enter and presto - saved or loaded,
with no other die effects.

   Perhaps you should stop looking at the dialog and just blindly
   enter paths. It works surprisingly well.

Did this change in GTK 2.6?  In GTK 2.4, I tried doing precisely
that.  I typed ctrl-O while in an image named colors4.tif; I tried
to type skier.tifenter and got another copy of colors4.tif.  I
don't much mind blindly entering paths, as long as I can see what I'm
typing in case I make a mistake.

-- 
Robert Krawitz [EMAIL PROTECTED]

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [gwidion@mpc.com.br: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-18 Thread Sven Neumann
Hi,

Bill Kendrick [EMAIL PROTECTED] writes:

 I'd love it if Gimp used KDE's file dialogs.  The new Gimp one is
 quite annoying, compared to both the older Gimp file dialogs and the
 latest KDE ones.

Asking the GIMP developers to implement native file selection dialogs
is just silly. The new GTK+ file-chooser was designed in a way that
allows for platform-specific implementations. If you really think that
the file-chooser needs to be integrated better with KDE, then you can
write a KDE-specific GtkFileChooser implementation. There is nothing
that would have to be changed in GIMP.

And, you aren't seriously trying to argue that the new GtkFileChooser
would be worse than the old file selection widget, are you? That used
to be the case with the early implementations but certainly not with
the latest GTK+ 2.6 releases. The file dialog is getting better and
better with each release.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-18 Thread Alan Horkan

On Fri, 17 Jun 2005, Leon Brooks wrote:

 Date: Fri, 17 Jun 2005 09:05:30 +0800
 From: Leon Brooks [EMAIL PROTECTED]
 To: gimp-developer@lists.xcf.berkeley.edu
 Subject: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

 This may seem like an oxymoron, given GIMP's heavy defacto relationship
 with GNOME-flavoured GTK, but is there any GIMP equivalent to
 OpenOffice's KDE integration (http://kde.openoffice.org/)?

 The closest I could find was a vague reference to a pre-2.0 KDEified
 version of The GIMP, apparently called KIMP...

 http://dot.kde.org/1096230607/1096270511/

 ...and this discussion, which is obviously approaching the issue from
 the KDE end and not the GIMP end of things (IMESHO, starting from the
 wrong end):

 http://lists.kde.org/?l=kde-develm=92756018422117w=2

 I am guessing that a zero overhead (at least for GTK, I'd envision
 this as a 1:1 mapping using #defines) toolkit mapping layer at the
 source-code level would make ports for Qt/KDE, Carbon, wxWidgets or
 whatever considerably easier. Then there'd be only alternative shims to
 maintain, not a whole raft of debris integrated with The GIMP proper,
 and toolkit bugs would all be located in very few files.

I am optimistic project like metatheme will help improve consistency
between Gtk and KDE applications and help leave the choice of toolkits to
the developers.  If you are interested in looking into it futher here is
their website:

http://metatheme.advel.cz/

Sincerely

Alan Horkan

Inkscape http://inkscape.org
Abiword http://www.abisource.com
Dia http://gnome.org/projects/dia/
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-18 Thread Leon Brooks
On Friday 17 June 2005 22:25, Carol Spears wrote:
 On Fri, Jun 17, 2005 at 09:05:30AM +0800, Leon Brooks wrote:
 This may seem like an oxymoron, given GIMP's heavy defacto
 relationship with GNOME-flavoured GTK, but is there any GIMP
 equivalent to OpenOffice's KDE integration
 (http://kde.openoffice.org/)?

 do you know what GTK stands for?

Yes.

Hopefully one day GEGL will also be useful enough used by lots of GNOME 
apps as if it were a part of GNOME. I regularly use GTK apps (yes, 
including The GIMP) on MS-Windows.

Cheers; Leon

-- 
http://cyberknights.com.au/ Modern tools; traditional dedication
http://plug.linux.org.au/   Member, Perth Linux User Group
http://slpwa.asn.au/Member, Linux Professionals WA
http://osia.net.au/ Member, Open Source Industry Australia
http://linux.org.au/Member, Linux Australia
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-18 Thread Leon Brooks
On Saturday 18 June 2005 09:08, Sven Neumann wrote:
 What aboout DND, the clipboard?

Reporting on GIMP 2.2.7 under KDE 3.4.1.

DND from GIMP does not work. The cursor changes but nothing happens if I 
drop onto (e.g.) KMail. Konqueror asks for a name, then turns a layer 
into a 2-byte file (0x0034, for the curious).

DND to GIMP works, the result is a new image.

Copy and Paste works both ways, at least for a whole image. Haven't 
tried things like masks or layers.

 Do images opened in GIMP show up in the KDE recent documents list?

No.

 Does Konqueror show the thumbnails we created?

No.

 Can I  drag a layer out of the development version of GIMP and drop
 it into KOffice?

Don't know about a development version, but not with this one.

 Does Klipper support the Clipboard Management Specification? 

Klipper can crash The GIMP, but doesn't seem to be able to meaningfully 
interact with it otherwise.

Cheers; Leon

--
http://cyberknights.com.au/ Modern tools; traditional dedication
http://plug.linux.org.au/   Member, Perth Linux User Group
http://slpwa.asn.au/Member, Linux Professionals WA
http://osia.net.au/ Member, Open Source Industry Australia
http://linux.org.au/Member, Linux Australia
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-18 Thread Carol Spears
On Sat, Jun 18, 2005 at 10:13:26PM +0800, Leon Brooks wrote:
 On Friday 17 June 2005 22:25, Carol Spears wrote:
  On Fri, Jun 17, 2005 at 09:05:30AM +0800, Leon Brooks wrote:
  This may seem like an oxymoron, given GIMP's heavy defacto
  relationship with GNOME-flavoured GTK, but is there any GIMP
  equivalent to OpenOffice's KDE integration
  (http://kde.openoffice.org/)?
 
  do you know what GTK stands for?
 
 Yes.
 
 Hopefully one day GEGL will also be useful enough used by lots of GNOME 
 apps as if it were a part of GNOME. I regularly use GTK apps (yes, 
 including The GIMP) on MS-Windows.
 
the point is, GNOME is GIMP-flavored.

thanks,
carol

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-18 Thread pcg
[This is a re-sent because my reent mails had been sent for moderation ut
never appeared on-list: is the list still moderated?]

On Sat, Jun 18, 2005 at 03:23:02PM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 And, you aren't seriously trying to argue that the new GtkFileChooser
 would be worse than the old file selection widget, are you? That used

Lots of people have expressed that the new filechooser feels worse for
them.  I, for example, as a heavy unix shell user (probably a totally
unimportant part of the gimp user community as I am no graphics artist),
still find the old (gtk+-1) file dialogs much easier and more intuitive to
use, with less clutter. The best file dialogs ever, because they never got
in my way. The new (gtk+-2.6) dialogs _do_ come in my way. They work like
ms windows, they feel like ms windows, and they feel clumsy, in the parts
that I use: entering filenames.

(Despite still blocking for ages due to excessive stat() ing for remote
filesystems not in the directory I started them, and many more minor
annoyances that certainly _will_ be fixed, or at least be improved, but
still make it slow business with gtk+-2.6.4).

Other things (workflow) will not get fixed because the target (me!) is not
the majority, and not important either. But that doesn't magically make
the dialogs useful for me and claiming so again and again makes that more
and more grotesque.

 to be the case with the early implementations but certainly not with
 the latest GTK+ 2.6 releases. The file dialog is getting better and
 better with each release.

You keep repeating this as if it were some kind of religion - why do you
ignore the people who simply disagree? Of course the new dialogs have many
more features, but they are _much_ less usable for _some_ people. This is
a simple fact.

You should really accept that, even if it works for you, and even if you
cannot understand it.

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-17 Thread Michael Schumacher
 Von: Leon Brooks [EMAIL PROTECTED]
 
 This may seem like an oxymoron, given GIMP's heavy defacto relationship 
 with GNOME-flavoured GTK, but is there any GIMP equivalent to 
 OpenOffice's KDE integration (http://kde.openoffice.org/)?

If KDE/Qt and GNOME/GTK+ both adhere to the freedesktop.org standards, you
won't have to change anything to achieve integration.


Michael

-- 
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden  testen ++ http://www.gmx.net/de/go/promail ++
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-17 Thread Carol Spears
On Fri, Jun 17, 2005 at 09:05:30AM +0800, Leon Brooks wrote:
 This may seem like an oxymoron, given GIMP's heavy defacto relationship 
 with GNOME-flavoured GTK, but is there any GIMP equivalent to 
 OpenOffice's KDE integration (http://kde.openoffice.org/)?
 
do you know what GTK stands for?

carol

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]

2005-06-17 Thread Bill Kendrick
Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote:
 
 I actually run the GIMP on KDE, and it works just fine. Minor bug 
 related to KDE integration are reported form time to time to 
 bugzilla, and that is all there is that doesn't work.

I'd love it if Gimp used KDE's file dialogs.  The new Gimp one is quite
annoying, compared to both the older Gimp file dialogs and the latest
KDE ones.

-bill!
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer