[Usability]Re: [Gcm-devel] clipboard manager comments

[Philip Van Hoof <spam freax be>]

On Wed, 2002-10-09 at 22:13, Havoc Pennington wrote:


> I'm investigating better clipboard support for GNOME 2.2 or Red Hat
> Linux next-version, and the first thing I looked at was
> GNOME clipboard manager at http://gcm.sourceforge.net/.
 
> Here are the comments I had on it. The biggest point I think is to
> hide some of the X machinery (selections, targets) from the user.
 
> It might be nice if someone could post screenshots from similar apps
> on Mac and Windows and KDE and so on.

You have
	* Microsoft Visual Studio.NET's clipboard ring feature
	* Microsoft Office's multiple clipboards
	* netclip and netclipboard
	* Klipper on KDE

> Thanks to the GCM guys for the hard work, this is an important app.

Hi there Havoc and thanks for the interest that you have in GNOME
Clipboard Manager. This is the first time somebody is investigating the
use of GNOME Clipboard Manager in an environment like Red-Hat's GNOME
desktop and I really do appreciate your point of view. Not much people
have give me their point of view so far.. so at this moment most of the
UserInterface of GNOME Clipboard Manager is plain "My" point of view
while I was developping it. Because I am just a simple programmer I do
understand that this is not always the best solution to a problem. Most
programmers pretty much suck at designing a good UserInterface; So do I.
That is why I agree on most stuff that is explained in the HIG...not
because I am a user myself :-).

I will note a few things, before I begin this mail :

  a) I do know that this mail is long and I am sorry for that if you
     dislike long mails ;).

  b) My English is not very good so excuse me for any possible bad   
     English.

  c) I do agree on almost all requests and comments that you have
     send; But I must comment on it that at this moment I am the only
     developper actually working on GNOME Clipboard Manager. I wish 
     GNOME Clipboard Manager had more resources but I have noticed that
     finding such resources is not a very simple task at all.

 
>  - It seems like we could give better feedback to the user on exactly
>    what the program does and how it works. For example, after some
>    experimentation I determined that the currently-selected row in the
>    list view will be pasted if I paste in another app.  Can we somehow
>    make it more clear that the user is looking at the stuff they've
>    copied or cut, and that the selected one is currently-active? I'm
>    not sure how to do this but maybe others on the list have ideas.

Imho the very basics of the application must be understood before one
can use GNOME Clipboard Manager. For that, the users have a very basic
documentation which is located here :
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/gcm/gcm-2/doc/index.html
Other than that the best solution to explain what just happened after
selecting an item is to explain it in the statusbar. And the best
solution to learn users about the possibilities of GNOME Clipboard
Manager would be a "Hint" window. But then again, a lot GNOME
applications already have such popupwindows. I personally dislike that
nor use them at all (sometimes I should, but I don't).


>  - If the selected item is the one we'll paste, what does "Select All"
>    mean? It seems to result in pasting a random item from those
>    selected. Maybe you should only be able to select a single item.

That would break a lot features like deleting, merging, copypasting (in
gcm) and editing which are at this moment possible on multiple items. I
do agree that for a new user this could confuse and that is why the
multiselect option is a feature. Maybe it would be a good idea to turn
this feature off by default?

>  - It might be cleaner if the default double-click action on an item
>    was a super-simple "View item" in which you got a window containing
>    only a preview of the item - uneditable text, or just an image, or
>    whatever. Guessing that just wanting to see an item is the most
>    common action.

That is a funny request because I used to keep sources of a window that
would do exactly that in CVS. Because I found myself not implementing it
I decided to remove the sources from the Gcm-2 module in CVS. Now it has
become a feature request :-).So I will take a look at it...

>    Then that window would have an "edit item" button that opened 
>    an editor appropriate to the item type.
>    One advantage of this, aside from a simpler default window 
>    for the most common action, is that "Edit item" could open up 
>    the GIMP or AbiWord.

This feature has been on my own wishlist for a long time too. One
problem is that a lot applications simply have no option to feed it's
own Clipboard Data. Some applications, like The Gimp afaik, don't even
export their selection using the CLIPBOARD atom but instead use an
internal buffer for their copypaste data (it is possible that this has
changed, I don't use the latest versions of The GIMP). Corporation
between applications like AbiWord, OpenOffice.org, The GIMP and browsers
like Mozilla, Konqueror and Galeon should increase dramatically and in a
very short time if, for example Red-Hat and Mandrake, wants office-users
to start using their desktop. Explain me how to explain, that you cannot
copypaste the layout of a website to an E-mail when using linux, to
somebody in my company ;-) I don't know.. I really don't! End-users want
these bloatware features :-).


>  - Overall I think it exposes too many implementation details of the
>    clipboard. The GUI would be hugely improved if the need for the
>    following technical terms was eliminated (at least from anywhere
>    other than an "Advanced" tab):

>     - Selection (when used in the technical sense)

Agree

>     - Selection names (CLIPBOARD, SECONDARY, PRIMARY)
>       (No one uses SECONDARY, and PRIMARY doesn't really 
>       need to be harvested/stored - in fact things break if you do -
>       and I can't think of a use for "custom name" - so basically 
>       CLIPBOARD can just be used always)

I do use it for copypasting from terminals. Terminals like the GNOME
Terminal and Multi-Gnome-Terminal do not set the CLIPBOARD selection
:-). I use GNOME Clipboard Manager for converting this PRIMARY selection
to a CLIPBOARD selection actually. My opinion is that this feature
should then be moved to an 'Advanced' tab like you said.

>     - Atom
>     - Selection type names (COMPOUND_TEXT etc.)  (at least for common
>       types should convert to some user-friendly name. For all the
>       text types, should call the type Text, then make things just
>       work by storing data as Unicode and converting it when pasting)

Agree, one problem is that there are multiple TEXT targets: STRING,
TEXT, COMPOUND_TEXT, ... the most common is, indeed, the COMPOUND_TEXT
target. This is a list of common used TEXT targets :

COMPOUND_TEXT
TEXT
UTF8_STRING
STRING
UTF-8
text/plain;charset=utf-8

I have also no idea what the differences between them are and why some
applications set so may targets in stead of just the COMPOUND_TEXT
target. Afaik the only target that is supported by the receiving
application is COMPOUND_TEXT most of the times. The only application
that I know that is ready to support a specified target-type from
another application is Mozilla Composer with the text/html target. But
then again, Mozilla is unclear about the Encoding of their targets.
Afaik the encoding is UCS-2 but I had to find that out by examining the
data myself (afaik there is no documentation about this subject at all.
None of the applications I know so far document anything about the
encoding of the targets they export. This SHOULD change imho. Those
applications that are used a lot (Gimp, Office suites, Browsers) Should
agree on a standard and should document the formats they export when
copypasting)

 
>  - Preferences dialog should set transient parent
>    (gtk_window_set_transient_for())

Okay
 
>  - I would make these changes to toolbar button names to make the 
>    toolbar less spaced-out:
>     s/New item/New/
>     s/Delete items/Delete/
>     s/Edit item/Edit/
>     s/Clear list/Clear/

Okay
     
>  - "Get current" button on toolbar seems to expose an implementation
>    detail that need not be exposed. Or at least it could 
>    be hidden while "auto collect" is enabled.


The reason why that button is still there is that it is possible that
GNOME Clipboard Manager failed to claim the selection that she
retrieved. If that happens and there is no such button then Gcm is
rendered useless as it will no longer autocollect nor it has the
possibility to retrieve (and thus, restart the autocollecting) any new
selections. GNOME Clipboard Manager is not a poller; it will just wait
for another Window to take away her selectionownership, then get the new
selection and reclaim selectionownership.


>  - tooltip "get selection from window manager" doesn't make 
>    sense to me, there's no WM involved in the clipboard...

Okay

>  - the title of the main window should be simply "Clipboard Manager"
>    without "Gnome," as per HIG

Okay

 
>  - when it does appear GNOME should be all-caps, e.g. in the about
>    dialog

:-) Okay

>  - in about dialog, "GNU general public license" should be capitalized

Owkay
 
>  - Prefs dialog should be instant-apply as in HIG

Okay
 
>  - The "Selection type" option in prefs dialog should use an 
>    option menu instead of a combo; non-editable combos should 
>    never be used.

Added to TODO-list ;)

>  - When I create a "New item" and hit return to create the 
>    item, the new item dialog stays active and lets me 
>    create the item over and over

So it should disappear and have a normal "Ok" button in stead of an
"Apply" button ? One of the reasons was debugging the application :-).
It is more easy to add a lot items and test memory this way :-)). Ack oh
well.. 


>  - In the Edit Item dialog displaying TARGETS exposes a technical
>    implementation detail to the user.

This Edit dialog is a rather technical dialog so maybe I should hide
this dialog for the more common users? I do want to give the users the
possibility to modify as much targets as possible. That is what GNOME
Clipboard Manager is all about for me (Search/Replace, Crop, etc etc). I
started GNOME Clipboard Manager for personal use only ;) and editing the
COMPOUND_TEXT target was it's first real feature... So I dislike
removing it, in stead hiding it for the common user would be better I
think... (added to TODO)


>  - There are missing mnemonics in prefs dialog and in Edit item GUI

>  - Statusbar text "I don't own the selection" is hard to understand
>    due to technical terminology. I would suggest that the highlighting
>    in the list always corresponds to ownership of CLIPBOARD. That is,
>    whenever an item is highlighted, choosing Paste in any app will
>    paste that item. When no item is highlighted, choosing Paste won't
>    paste from the clipboard manager.

So unselect all when I lost the selectionownership...
  
>  - Shouldn't the "max amount of collected items" be limited by
>    default to avoid mega-memory-usage?

Yes :).. I will make this a default in the next release. For example 40
items ?!

>  - I don't think "Misc" is a good name for a tab in the prefs dialog, 
>    I would use "Advanced" perhaps.

Okay

>  - I don't understand any of the Advanced preferences, even though I
>    understand how the X clipboard works in some detail. So I think 
>    these are very, very advanced. ;-)

They are more UserInterface issues then clipboard issues actually. I
should, indeed, hide them for the more common user. The hiding of these
features could be done using an "Expert Mode" setting like Nautillus
has.


>  - there seems to be a tooltip "Preferences" set for the entire 
>    preferences dialog? Probably just a glade glitch.

Oeps..

>  - should there be (or is there already) a way to extend the types
>    handled by the clipboard manager from third-party packages.  For
>    example, could GIMP install a handler that supported a "View item"
>    preview for GIMP data, and that launched the GIMP when selecting
>    "Edit item" on GIMP data?
> 


There is no such handler at this moment..I think that corporation with
existing applications like OpenOffice.org, The GIMP, AbiWord, etc etc is
necessary for this to work correctly. For example the "Paste New From
Clipboard" feature in The GIMP could be used by GNOME Clipboard Manager
when at "GNOME Clipboard Manager" the user requested to "Edit" the item.
But then again, I have no idea how to launch and activate this feature
nor how to feed The GIMP the data into it's Clipboard buffer. To get the
whole GNOME desktop integrating this I think that the GtkClipboard
object should be extended AND this new functionality should be used by
the applications.



Changes in CVS since the latest release of GNOME Clipboard Manager :
(Note that most/all requests from Havoc will be added to CVS pretty
soon)

Fixes :
	* UUEncoding and UUDecoding of targets while saving them to XML
	* Fixes in the Edit window (this window tends to crash when
 	  the text/html data is large. Looks like a libgtkhml error to
 	  me as the text that I feed the widget is converted from UCS-2
	  using to UTF-8 g_convert() and validated as UTF-8) 


The temporary fix :) :

if (g_utf8_validate (text, newdata->length, end)) {
  newdata->data = text;
} else {
  gint i;
  newdata->data = g_convert (text, data->length,"UTF-8", "UCS-2"  
    ,NULL,&i, NULL);
...

 if ((newdata->data == NULL)||
    (!(g_utf8_validate (newdata->data, i, end))))
 {
   GtkWidget *label = gtk_label_new("Converting to UTF-8 failed");

...

 } else {

...

  if (newdata->length < 300) { /* or libgtkhtml crashes */

    html_document_write_stream (ttwin->doc, newdata->data, -1);

  or

    html_document_write_stream (ttwin->doc, newdata->data,
    newdata->length);

  } else {
    html_document_write_stream (ttwin->doc, "Html data to large", -1);
  }


}

}


-- 
Philip Van Hoof a.k.a. freax
mailto: me at freax dot org
http://www.freax.eu.org