<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1"> </HEAD> <BODY TEXT="#000000" BGCOLOR="#ffffff"> Ühel kenal päeval, T, 2009-12-08 kell 10:32, kirjutas Ingo Luetkebohle: <BLOCKQUOTE TYPE=CITE> Hi Mattias, I beg to differ on some of your points ;-) </BLOCKQUOTE> Opinions allowed. (Just kidding, who am I to prohibit it <IMG SRC="cid:1260265840.21384.405.camel@antiloop" ALIGN="middle" ALT=":)" BORDER="0"> ) <BLOCKQUOTE TYPE=CITE> Of course, discussing user interface issues in terms of personal preferences is somewhat moot, but there we go... There is something to be said for consistency, but Shotwell also does some things better right now. See below for two comments. </BLOCKQUOTE> Apologize me, I first forgot to title the table right. It should be named "Mouse related actions in fullscreen or slideshow mode, proposal draft Nº 1" <IMG SRC="cid:1260267760.21384.438.camel@antiloop" ALIGN="middle" ALT="B-)" BORDER="0"> Also, <BLOCKQUOTE TYPE=CITE> Mattias Põldaru schrieb: <BLOCKQUOTE TYPE=CITE> Ühel kenal päeval, E, 2009-12-07 kell 08:45, kirjutas Adam Dingle: <BLOCKQUOTE TYPE=CITE> <PRE> Mattias, I'm glad you like Shotwell so far! Thanks for your many suggestions. Here's some feedback: > 1. Quite a number of keyboards and mouses have back and forward buttons, > which are mostly useful for browsing web. These keys could be used in > Shotwell too, for navigating in 10 or 20 item history. > It's a good idea to support the mouse back/forward buttons in some way. We could either (a) make these buttons equivalent to the Previous Photo and Next Photo buttons in full-window mode, or (b) use them to navigate through the history of pages recently viewed. With (b), the back button might take you to the previous viewed event, for example. Are you suggesting (b) rather than (a)? </PRE> </BLOCKQUOTE> I would prefer b (back/forward for moving in history), with some additional features. It could be called "Navimouse enabled" or something <IMG SRC="cid:part1.06030404.00000400@techfak.uni-bielefeld.de" ALIGN="middle" ALT=":)" BORDER="0"> Mouse buttons usage: <TABLE CELLSPACING="0" CELLPADDING="5" WIDTH="100%" BORDER="1"> <TR> <TD WIDTH="9%" VALIGN="top"> </TD> <TD WIDTH="13%" VALIGN="top"> Proposal for Shotwell </TD> <TD WIDTH="9%" VALIGN="top"> F-Spot </TD> <TD WIDTH="9%" VALIGN="top"> Picasa </TD> <TD WIDTH="8%" VALIGN="top"> Irfanview </TD> <TD WIDTH="8%" VALIGN="top"> Eye of Gnome </TD> <TD WIDTH="8%" VALIGN="top"> gThumb </TD> <TD WIDTH="8%" VALIGN="top"> QIV </TD> <TD WIDTH="8%" VALIGN="top"> Feh </TD> <TD WIDTH="8%" VALIGN="top"> Gwenview </TD> <TD WIDTH="8%" VALIGN="top"> Digikam </TD> <TD WIDTH="8%" VALIGN="top"> Windows picture viewer </TD> </TR> <TR> <TD WIDTH="9%" VALIGN="top"> LMB click </TD> <TD WIDTH="13%" VALIGN="top"> Next photo </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Prev </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Next </TD> <TD WIDTH="8%" VALIGN="top"> Next </TD> <TD WIDTH="8%" VALIGN="top"> Next </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Next </TD> <TD WIDTH="8%" VALIGN="top"> Next </TD> </TR> <TR> <TD WIDTH="9%" VALIGN="top"> LMB double click </TD> <TD WIDTH="13%" VALIGN="top"> Advance 10 pictures </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Prev </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Exit fullscreen </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> </TR> <TR> </TR> </TABLE> </BLOCKQUOTE> Could there be a pattern here that edit-capable applications do not forward on mouse-click, while non-edit-capable apps do? </BLOCKQUOTE> <BLOCKQUOTE TYPE=CITE> Also, left double-click is already used to toggle fullscreen in shotwell. </BLOCKQUOTE> At least in 0.3.2 it toggles full-window state, not fullscreen. When you press F11 and doubleclick there, nothing happens. <BLOCKQUOTE TYPE=CITE> <BLOCKQUOTE TYPE=CITE> <TABLE CELLSPACING="0" CELLPADDING="5" WIDTH="100%" BORDER="1"> <TR> <TD WIDTH="9%" VALIGN="top"> LMB triple click </TD> <TD WIDTH="13%" VALIGN="top"> Advance to next event </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> </TR> <TR> <TD WIDTH="9%" VALIGN="top"> LMB drag </TD> <TD WIDTH="13%" VALIGN="top"> Mark cropping area. Adjust from handles. Click in center to end selection, click outbounds to cancel. </TD> <TD WIDTH="9%" VALIGN="top"> Mark cropping area, no way to confirm using mouse </TD> <TD WIDTH="9%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Prev </TD> <TD WIDTH="8%" VALIGN="top"> Starts dragging the image file </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> Pan image </TD> <TD WIDTH="8%" VALIGN="top"> Pan </TD> <TD WIDTH="8%" VALIGN="top"> Pan </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> <TD WIDTH="8%" VALIGN="top"> - </TD> </TR> <TR> </TR> </TABLE> </BLOCKQUOTE> Drag is used for drag'n'drop. Shotwell is the /only/ Linux photo manager that works fine with drag'n'drop right now. Please don't break that... </BLOCKQUOTE> I couldn't live with myself, if I end up doing so. <BLOCKQUOTE TYPE=CITE> Alternatively, one could use click-then-move-then-click for selecting rectangles. </BLOCKQUOTE> This sounds excellent for the fullwindow image mode, and for consistency should be used in fullscreen too. As you see, I have not thought it all the way through, but controlling slideshow or fullscreen view remotely while presenting pictures to your family or friends sounds like a nice thing to achieve. So controlling remotely using only mouse and at the same time do basic edit live with no unwanted disturbance on the screen is far from being impossible. Some goals 1. Basic usage easy (no tripleclicks or drags) 2. Basic usage possible with not fancy mouses (LMB and RMB only) 3. Keeping the same triggers wherever possible 4. Minimal disturbance on screen All the best Mattias </BODY> </HTML>