Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-04-01 Thread Robert Krawitz 
On Sat, 1 Apr 2017 11:57:30 +0200, Romano Giannetti wrote:
> On 01/04/17 08:38, Tobias Ellinghaus wrote:
>> Now, metadata editor is a little special as it both shows the data from the
>> selected images as well as allows editing. For that reason it applies your
>> entry whenever focus goes away so you don't need to confirm your edit.
> And this is quite surprising, let me tell you. I am quite old and geeky (is 
> there a single word for that?) so I am one of the 5 in the world that uses 
> focus-follow-mouse [FFM] in my normal desktop (and I had to develop a Gnome 
> extension to switch to click-to-focus for the buggy programs that needs it, 
> like all windows programs running under wine...), so I do not object to most 
> of the thing underlined in this thread.
>
> But in my opinion one thing is removing text input when mouse go away (which 
> I find natural, given the above) and another one commit changes. FFM is 
> useful because while I'm doing thing in a window, I can rapidly move the 
> mouse to, say, IRC to answer and go back. I expect that from the mouse (and 
> focus) exit to the re-enter nothing happens. It is a bit like if I am typing 
> "rm -f *.log" in a xterm, move to another one after typing the "*", and 
> having the command executed...

As a fellow focus-follows-mouse user, I agree -- simply moving your
mouse out of a widget should not apply changes.  Committing an edit
isn't something that should be done by an inadvertent action, like
moving your mouse outside of the window/widget; it should take an
explicit action (a save key/menu item, confirmation, or the like).
-- 
Robert Krawitz 

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-04-01 Thread Romano Giannetti 

Hi!

On 01/04/17 08:38, Tobias Ellinghaus wrote:

Now, metadata editor is a little special as it both shows the data from the
selected images as well as allows editing. For that reason it applies your
entry whenever focus goes away so you don't need to confirm your edit.
And this is quite surprising, let me tell you. I am quite old and geeky 
(is there a single word for that?) so I am one of the 5 in the world 
that uses focus-follow-mouse [FFM] in my normal desktop (and I had to 
develop a Gnome extension to switch to click-to-focus for the buggy 
programs that needs it, like all windows programs running under 
wine...), so I do not object to most of the thing underlined in this 
thread.


But in my opinion one thing is removing text input when mouse go away 
(which I find natural, given the above) and another one commit changes. 
FFM is useful because while I'm doing thing in a window, I can rapidly 
move the mouse to, say, IRC to answer and go back. I expect that from 
the mouse (and focus) exit to the re-enter nothing happens. It is a bit 
like if I am typing "rm -f *.log" in a xterm, move to another one after 
typing the "*", and having the command executed...


On a general way, the state of the undo in DT is, I think, getting 
better and better. I would like to see undo or (less optimal) 
confirmation on all destructive operations, and I think it will get 
there with time. It would be nice to simply have a "timemachine" folder 
where the last ten version of the xmp files where stored (they are small 
and cheap to store), and I had even tried to check some filesystem doing 
that (like the old yore VAX-VMS one...), to no avail. Maybe it is 
possible to do this with a LUA script?


Romano

--
Romano Giannetti
http://www.rgtti.com/


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-04-01 Thread Tobias Ellinghaus 
Am Freitag, 31. März 2017, 21:47:28 CEST schrieb Stéphane Gourichon:
> Le 31/03/2017 à 18:38, Stéphane Gourichon a écrit :
> > It looks like darktable UI implements some sort of
> > focus-follows-pointer behavior, which is uncommon these days. I do not
> > know of any other gtk app that does this (or any recent app, what was
> > the last one I saw behaving like this ... a Motif app maybe, 20 years
> > ago?).
> 
> Thank you all for your examples of UI behavior.
> 
> I was surprised no one mentioned side panels in lighttable, because it
> hit me many times.
> 
> Then I tested (it hit me actually always on the same spot). I observed
> the others are not affected and on experimenting I finally figured out
> what happens.
> 
> TL;DR: drop-downs steal focus and that's a pain on "export selected" module.
> 
> Where ? lighttable, right panel, module "export selected"
> 
> How to reproduce :
> 
> * open lighttable, move mouse to right panel, expand "export selected"
> * click on export path textbox (between "target storage" and "on conflict").
> * type some characters, they appear
> * move mouse pointer away
> * type some more characters
> 
> Expected : more characters appear
> Observed : as soon as the pointer is moved away, textbox is no longer
> focused, no characters are inserted

[...]

> Nevertheless, IHMO focus is not expected to be stolen away from textbox
> when move is moved away.

[...]

The reason why we take away keyboard focus when the mouse leaves a widget (or 
enters the central area) is quite simple: to make keyboard shortcuts work. In 
the past we had a ton of issues where shortcuts stopped working once you 
entered any text into a textbox. They came back when you clicked on certain 
parts of the gui to give back keyboard focus to the whole program. Those were 
dark times. What we have now isn't ideal either, but it's better than what 
there was before.
Now, metadata editor is a little special as it both shows the data from the 
selected images as well as allows editing. For that reason it applies your 
entry whenever focus goes away so you don't need to confirm your edit.

Tobias

signature.asc
Description: This is a digitally signed message part.

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread dt-list 
Stéphane Gourichon (2017-Mar-31, excerpt):
> It appears that the real cause is not the mouse pointer exiting the
> textbox, but entering the drop-downs above and below. It's not that
> the mouse leave the textbox, it's that entering a dropdown steals
> focus.

Interesting observation.  Additionally, the focus is not given back
when you move the mouse back to the text box.  But it's also not with
the dropdown any more, because the mouse wheel does not change the
dropdown.  We might argue forever over whether focus-follows-pointer
is good or bad, but this is just inconsistent.

> Nevertheless, IHMO focus is not expected to be stolen away from
> textbox when move is moved away.

Agree.


-- 
http://stefan-klinger.de  o/X
Send plain text messages only, not exceeding 32kB./\/
\

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread Stéphane Gourichon 

Le 31/03/2017 à 18:38, Stéphane Gourichon a écrit :


It looks like darktable UI implements some sort of 
focus-follows-pointer behavior, which is uncommon these days. I do not 
know of any other gtk app that does this (or any recent app, what was 
the last one I saw behaving like this ... a Motif app maybe, 20 years 
ago?). 


Thank you all for your examples of UI behavior.

I was surprised no one mentioned side panels in lighttable, because it 
hit me many times.


Then I tested (it hit me actually always on the same spot). I observed 
the others are not affected and on experimenting I finally figured out 
what happens.


TL;DR: drop-downs steal focus and that's a pain on "export selected" module.

Where ? lighttable, right panel, module "export selected"

How to reproduce :

* open lighttable, move mouse to right panel, expand "export selected"
* click on export path textbox (between "target storage" and "on conflict").
* type some characters, they appear
* move mouse pointer away
* type some more characters

Expected : more characters appear
Observed : as soon as the pointer is moved away, textbox is no longer 
focused, no characters are inserted


On closer analysis it appears that this happens only when the move is 
moved up or down, not when it leaves the textbox sideways.


It appears that the real cause is not the mouse pointer exiting the 
textbox, but entering the drop-downs above and below. It's not that the 
mouse leave the textbox, it's that entering a dropdown steals focus.


This explains why it does not happen on other modules, like "collect 
images", "metadata editor", "tagging", "geotagging" : they have no 
drop-downs above or below.


Nevertheless, IHMO focus is not expected to be stolen away from textbox 
when move is moved away.



Question: Why do drop-downs steal focus? Do they have a good reason? 
Would a "click to focus" be enough?


--
Stéphane Gourichon


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread Jean-Luc CECCOLI 
As I admit being able to see informations on pictures that are not selected is 
of great value, being able to modify pictures that are not selected would in no 
way have to be possible.

Two suggestions :

a- implement undo for every operation, should it concern one or all the 
pictures in the library. Quite complex and memory consuming, I guess.

b- don't allow destructive operations on pictures that are not selected without 
explicit user confirmation.

Yes, I know, suggestions are easy, doing is harder (I remember having been a 
programmer very long time ago...).

 

Regards,

 

J.-Luc

 

 

 

> Message du 31/03/17 19:22
> De : dt-l...@stefan-klinger.de
> A : darktable-user@lists.darktable.org
> Copie à : 
> Objet : Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing 
> history stack paste.)
> 
> Colin Adams (2017-Mar-31, excerpt):
> > On Fri, 31 Mar 2017 at 17:58 Pascal Obry 
wrote:
> > > This looks like a feature to me and I use it this way to mark multiple
> > > photos very close with the same rating and/or color.
> > >
> > 
> > Whereas to me it's a bug.
> 
> I have to admit, Pascal does have a point here. They make the
> software the way they like it. However quaint that may appear to me
> and you, we could code our own solution.
> 
> Actually I once tried to get into DT's code to find out why XMP and
> database content can diverge, but when a DT-dev suggested to overwrite
> a file although it has the ro-flag set, I gave up...
> 
> Yes, to me it's a bug, too.
> 
> 
> -- 
> http://stefan-klinger.de o/X
> Send plain text messages only, not exceeding 32kB. /\/
> \
> 
> darktable user mailing list
> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
> 
>

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread August Schwerdfeger 
For the particular issue I raised, changing how widget focus is handled
would not really fix it properly -- without confirmation dialogs or some
other safety mechanism for the "discard" and "paste all" commands, it would
still be possible to, effectively, destroy one's database with a single
keystroke or click.

--
August Schwerdfeger
aug...@schwerdfeger.name


On Fri, Mar 31, 2017 at 12:26 PM, I. Ivanov  wrote:

> The simple point is - DT can be catastrophic in certain cases.
>
> As the original question pointed - if the user intends to copy / paste
> metadata information and instead copy / paste image stack - even by
> accident - the results can be drastic and very unpleasant.
>
> If you have 1000-2000 images - all corrected and then just editing the
> metadata - 2 cases can happen - wrongly override the history stack (and
> never notice) then all corrections are wrong - so you can end up printing
> wrong pictures. Or wrongly override history stack and notice it - then
> invest hours or days to figure out what image should be where on the
> correction state. Either case is very much not acceptable.
>
> FYI - I do edit metadata last as considerable amount of images are
> discarded and the metadata do vary from image to image with some common
> parts in it.
>
> So - while DT takes extreme care to preserve the RAW file - it leaves the
> .XML side cart very vulnerable to a user mistake. In my opinion it would be
> very nice to have some change of behavior to be safer.
>
> Regards,
>
> B
>
> On 2017-03-31 10:10 AM, Colin Adams wrote:
>
> On Fri, 31 Mar 2017 at 17:58 Pascal Obry  wrote:
>
>> Colin,
>>
>> > In darkroom, using the film-strip to select the photo to be edited.
>> > If I press a Function key to set the colour label, or a numeric to
>> > set the star rating, the setting is made on the photo which has the
>> > mouse pointer over it in the film strip. Not the selected photo (i.e.
>> > the one visible in the darkroom).
>> > This seems wrong to me, and causes me problems. I've NEVER want to
>> > set the rating for a photo that is not visible in the darkroom.
>>
>> This looks like a feature to me and I use it this way to mark multiple
>> photos very close with the same rating and/or color.
>>
>
> Whereas to me it's a bug.
> A simple solution to make everyone happy is to make it a configurable
> option.
>
>
>
>> > Here's another. In the lighttable, the Image information in the left-
>> > hand pane shows the information for the photo under the pointer. Not
>> > the selected photo. In this case, I can't see any other behaviour
>> > makes sense, as there maybe multiple selections.
>>
>> Again, this is a feature. Quite handy.
>>
>> I understand that you may not like it but it is quite convenient to
>>
> I said I can't see that any other behaviour makes sense, so I don't know
> why you think I don't like it. (I do get confused by it sometimes).
>
>
>> look for information on some picture quite fast without having to
>> select them.
>>
>> The problem with the UI and behavior is that we have all a different
>> way to see things.
>>
>
> So configuration options can tackle that.
>
> 
> darktable user mailing list to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org
>
>
>
> 
> darktable user mailing list to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org
>


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread dt-list 
Colin Adams (2017-Mar-31, excerpt):
> On Fri, 31 Mar 2017 at 17:58 Pascal Obry  wrote:
> > This looks like a feature to me and I use it this way to mark multiple
> > photos very close with the same rating and/or color.
> >
> 
> Whereas to me it's a bug.

I have to admit, Pascal does have a point here.  They make the
software the way they like it.  However quaint that may appear to me
and you, we could code our own solution.

Actually I once tried to get into DT's code to find out why XMP and
database content can diverge, but when a DT-dev suggested to overwrite
a file although it has the ro-flag set, I gave up...

Yes, to me it's a bug, too.


-- 
http://stefan-klinger.de  o/X
Send plain text messages only, not exceeding 32kB./\/
\

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread Colin Adams 
On Fri, 31 Mar 2017 at 17:58 Pascal Obry  wrote:

> Colin,
>
> > In darkroom, using the film-strip to select the photo to be edited.
> > If I press a Function key to set the colour label, or a numeric to
> > set the star rating, the setting is made on the photo which has the
> > mouse pointer over it in the film strip. Not the selected photo (i.e.
> > the one visible in the darkroom).
> > This seems wrong to me, and causes me problems. I've NEVER want to
> > set the rating for a photo that is not visible in the darkroom.
>
> This looks like a feature to me and I use it this way to mark multiple
> photos very close with the same rating and/or color.
>

Whereas to me it's a bug.
A simple solution to make everyone happy is to make it a configurable
option.



> > Here's another. In the lighttable, the Image information in the left-
> > hand pane shows the information for the photo under the pointer. Not
> > the selected photo. In this case, I can't see any other behaviour
> > makes sense, as there maybe multiple selections.
>
> Again, this is a feature. Quite handy.
>
> I understand that you may not like it but it is quite convenient to
>
I said I can't see that any other behaviour makes sense, so I don't know
why you think I don't like it. (I do get confused by it sometimes).


> look for information on some picture quite fast without having to
> select them.
>
> The problem with the UI and behavior is that we have all a different
> way to see things.
>

So configuration options can tackle that.


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread dt-list 
Stéphane Gourichon (2017-Mar-31, excerpt):
> I like the idea of keeping things simple, but can you tell a
> solution that does not increase complexity?

I'd be happy if I had to click somewhere before it accepts input.
I.e., focus-does-NOT-follow-mouse.

Lighttable, click on one image.  If you press a number, the image gets
rated, *unless* you have moved the pointer to another image, which
will be rated instead, *unless* you have moved the pointer to, say,
the collection pane, in which case the selected image gets rated.
This is convoluted.  Just rate the selected image and nothing else.

> It looks like darktable UI implements some sort of focus-follows-pointer
> behavior, which is uncommon these days. I do not know of any other gtk app
> that does this

Some window managers allow this, and I have to admit I use it my self.
I do like it at the granularity of windows (using “sloppy focus”,
i.e., leaving a window does not take away focus, only entering another
one moves focus there), but that approach fails me at the granularity
of individual, tiny widgets.

> > Honestly I'd prefer it to be a little bit more traditional.
> 
> Looks like "focus follows mouse" is so traditional and forgotten that "new"
> users think it's something new?

With more traditional I meant less trigger happy at tossing previous
work.  E.g., I fail to get used to DT always saving the XMP file.  I
prefer to explicitly save when I'm satisfied with my work, and maybe
chose a different file name then.


-- 
http://stefan-klinger.de  o/X
Send plain text messages only, not exceeding 32kB./\/
\

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread Colin Adams 
I can supply one scenario.

In darkroom, using the film-strip to select the photo to be edited.
If I press a Function key to set the colour label, or a numeric to set the
star rating, the setting is made on the photo which has the mouse pointer
over it in the film strip. Not the selected photo (i.e. the one visible in
the darkroom).
This seems wrong to me, and causes me problems. I've NEVER want to set the
rating for a photo that is not visible in the darkroom.

Here's another. In the lighttable, the Image information in the left-hand
pane shows the information for the photo under the pointer. Not the
selected photo. In this case, I can't see any other behaviour makes sense,
as there maybe multiple selections.

On Fri, 31 Mar 2017 at 17:46 Pascal Obry  wrote:

> Le vendredi 31 mars 2017 à 18:38 +0200, Stéphane Gourichon a écrit :
> > To DT developers: how comes that darktable UI has some sort of
> > focus-follows-pointer behavior, while other gtk apps don't have that?
>
> All this discussion is quite generic. Please come up with a precise
> scenario. One such error was introduced by myself some time ago but is
> now fixed on master.
>
> --
>   Pascal Obry /  Magny Les Hameaux (78)
>
>   The best way to travel is by means of imagination
>
>   http://www.obry.net
>
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>
> 
> darktable user mailing list
> to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org
>
>


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

focus-follows-mouse in DT UI (Re: [darktable-user] Reversing history stack paste.)

2017-03-31 Thread Stéphane Gourichon 

Le 31/03/2017 à 18:16, dt-l...@stefan-klinger.de a écrit :

In this thread we're just throwing more complexity (backups, undo in
lighttable) at a problem that arose from DT's user interface.  An
application should protect a user from involuntarily causing damage,
and in that respect DT is an adversary.


I like the idea of keeping things simple, but can you tell a solution 
that does not increase complexity?



IMNSHO the root cause for August's problem is that DT does too much
when moving the mouse pointer.  After clicking on an input field, the
pointer has to stay there, otherwise editing is cancelled.


This one has been an annoyance to me since day 1 of discovering darktable.

It looks like darktable UI implements some sort of focus-follows-pointer 
behavior, which is uncommon these days. I do not know of any other gtk 
app that does this (or any recent app, what was the last one I saw 
behaving like this ... a Motif app maybe, 20 years ago?).



   Another
example [1] is that the selection gets cleared when you move the
pointer "incorrectly".  You can observe this by trying to select and
middle-click paste the path of an image from the image information
pane.  I've been bitten by DT's UI repeatedly.  Honestly I'd prefer it
to be a little bit more traditional.


Looks like "focus follows mouse" is so traditional and forgotten that 
"new" users think it's something new?


To DT developers: how comes that darktable UI has some sort of 
focus-follows-pointer behavior, while other gtk apps don't have that?



--
Stéphane Gourichon


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org