Re: Updated wishlist items

On Wed, 2005-02-16 at 19:34 -0800, Karsten M. Self wrote:
> For discussion, it's probably best to pick a particular item, change
> subject appropriately, and discuss it.

Bah, I'll just pick a few things which stand out to me (i.e., I
generally agree with anything not mentioned below):

>   - Keep notifications proximate to relevant events.  Substitute
>     notification bar on web page with pop-up dialogs, where appropriate
>     (e.g.:  cookie confirmation, authentication requests, SSL status,
>     SSL transition, SSL/non-SSL mixed data).

I don't understand this one. By "notification bar", do you mean the
statusbar? Or that yellow bar below Firefox's and IE's toolbars? In
either case, are you either:

a) advocating dialog boxes? If so, that's evil! If people expect dialog
boxes at every turn they will dismiss them without reading them,
rendering dialog boxes useless in *every* program on the user's system.

b) advocating the statusbar? If so, that's evil! The statusbar is barely
noticeable, and some people browse with the statusbar disabled.

c) advocating the yellow bar? If so, that's evil! It simply doesn't draw
enough attention (I have yet to find myself actually *noticing* it when
I browse with IE -- the only times I will are on web pages which say "If
this doesn't work, look for a yellow bar asking to enable ActiveX
controls"). And it leaves less room for the web page.

So IMO, all options are evil.

>      - Detachable menus.  Controls.  IIUC, this is a Gtk option.  It
>        would be nice to have detachable menus restored in Galeon.
>        
>        Severity:  2

I get detachable menus. Look
at /desktop/gnome/interface/menus_have_tearoff in GConf.

>      - Toggling off full-screen option.  State loss / Controls: F11 is a
>        reserved keybinding in WindowMaker.  There should be a control,
>        hotkey, escape key, or other option.  In 1.2.x, menu hotkeys
>        worked even when the menubar wasn't visible in fullscreen view.
>        In 1.3.x, they don't.  So:  <alt>-V-U (view => fUll screen) would
>        escape fullscreen mode in 1.2.  This should be restored.  Only
>        current option appears to be killing the entire browser session.
> 
>        Severity:  4

Have you tried <alt>-V-F? Works for me in Debian unstable.

> Confirmations
> -------------
> 
>     Allow specification for close confirmation.
> 
>     Rationale:  it's too easy to close a browser session by
>     inadvertantly hitting a window's close control, or by miskeying C-q
>     for C-w.  This can result in significant loss of session state,
>     particularly as browser sessions are not saved by default and
>     cannot be saved conditionally.  My own pref would be to have this
>     confirmation *on* by default, with a "don't ask me again" option.
> 
>     Severity:  5.

Epiphany, for one, removes C-q altogether. That solves the issue for me,
since I almost never close windows with the little X in the corner (C-w
all the way!)

>   - Push upstream to GNOME request that MIME management be customizable
>     on a per-application basis.  I may want different bindings for
>     different apps.  Should also be able to reset to "user defaults" (app
>     takes user's MIME prefs) and "system defaults" (app *and* user take
>     system MIME prefs).

Staring into my crystal ball, I predict this will *never* happen in
GNOME. File a bug for it and you'll get a WONTFIX right away.

>   - Provide ability to publish/import/use an external bookmarks manager.
>     This mostly calls for researching alternatives and providing
>     interface to same.

This could really benefit from Epiphany's extensions interface.

>   - Additionally, rather than the page load blocking on a new request,
>     the cookie should be provisionally accepted as a session cookie and
>     the page loaded.  If the cookie dialog is cancelled, the cookie is
>     discarded.  If the dialog is accepted, the cookie is retained as the
>     user prefers:  session or persistant.
>     Avoid Repeating.
> 
>     Rationale:  when opening a large number of sites, particularly over
>     a slow link, a single unanswered cookie confirmation may block
>     one or more page loads.  Complete the requested action (load the
>     page), store provisional data, and take subsequent action on
>     provisional data (the cookie) based on further user input.

Some people might not appreciate that from a privacy perspective.
Accepting a cookie and using it to load the rest of the page (maybe some
images, for example), you would be allowing the cookie to do exactly
what you don't want: invade upon your privacy.

*I* couldn't care less, but I think some privacy advocates might feel
unsafe. Maybe someone who knows more about cookies can comment.

> Firefox Extensions
> ------------------
> 
>     Firefox's extensions are useful.  Documenting how to use same,
>     and/or providing ability to use same, and/or providing a similar
>     extensions interface into Galeon would be a major win.

Look to Epiphany for a lot of work on extensions (including Python
extensions). Most Firefox extensions can't be used out-of-the-box. (And
most Firefox extensions are complete garbage, anyway.)

-- 
Adam Hooper <[email protected]>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCFDNz90GtBxQ61zARAsDFAJ0dg8hPeZ3wliL00Ctn8IVP+SbCJwCfZsAq
7A/ohobC37zU8GryNuTz6HA=
=jWpA
-----END PGP SIGNATURE-----