Re: Updated wishlist items

on Thu, Feb 17, 2005 at 10:30:09AM +0000, Crispin Flowerday ([email protected]) wrote:
> On Wed, 2005-02-16 at 19:34 -0800, Karsten M. Self wrote:
> 
> >     - 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.
> >
> This works fine for me.

Sorry, what works?  The suggestion, or the actions described have the
desired effect?  Are menu items visible when hitting <alt>-V in
full-screen mode?

FYI: v. 1.3.19, it doesn't work.

Would you mind testing this under WindowMaker?

How about a toggle fullscreen on the main view page context menu?

 
> >Menus
> >-----
> >
> >    Enable detachable menus.
> >
> As AdamH pointed out this is easily enabled.

Right.  Consider this resolved.

 
> >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.
> >
> We have though about this before, but one thing I can't stand about some
> browsers is them poping up "are you sure you want to close this window"
> alerts. We warn when the user will lose data they have typed in
> (although this isn't perfect). Having "Don't ask me again" options
> aren't very good either, as you then need a UI somewhere else to turn on
> the dialog again.

The dialog request is either for closing multiple open windows in one
swell foop, or for killing an entire window with multiple open tabs.

The latter might occur relatively frequently.  The latter is pretty
infrequent thoug:  I close out a browser session once every few days to
few weeks.  Even for, say, an office or lab user who had to close out
their session at end-of-day, we're talking a few times a day tops.

The inconvenience of seeing an occasional dialog is *far* less than the
inconvenience of losing state of several score open tabs.

 
> 
> >Tabbed Browsing
> >---------------
> >
> >  - Navigation.  Allow scrolling of tabslist *without* changing current
> >    tab focus.  
> This is GtkNotebook behaviour

Which changes the question:  can GtkNotebook be changed, can a more
apporpriate control be used, or can a new control be written?
Preferably in about that order.  The behavior is inconsistent with use
of the feature in question.
 
 
> >Allow context-action (e.g.: right click)  on tab
> >    *without* changing current tab focus.  
> >
> In other parts of a Gtk UI, when you right click on an item it gets
> selected, this is the behaviour we are following, and this was a
> conscious decision .

It's the wrong decision.  

You're being slave to your ideal conceptual model, and it doesn't fit
the domain space.

If you followed this reasoning to its logical conclusion, right-clicking
on a browser page would change the pointer / highlight / search focus to
the location clicked on.  This doesn't happen.

The "item" in this case is the tabbar, and the collection of tabs.   The
tabbar is acting like an overloaded scrollbar, in that the user can
select actions on it.  Because I've context-clicked a particular
location on a scrollbar doesn't mean I want my viewscreen to immediately
move to that location.  *That* is an action I indicate by *moving* the
bar.  In the tabbar context:  I right click the tabbar to access tab
features.  I _left_ click a particular tab to select *that* tab.


> >  - Tab submenu.  Provide tablist on tab context menu.
> >
> A context menu is supposed to act on the object, that's why it is called
> a 'context' menu. I never thought the tablist fitted when we did have
> it, it changes the current view, so really shouldn't be on the context
> menu.
 
Again you're slave to a poorly-fitting conceptual model.  Tabs are a
high-profile aspect of the Galeon UI.  They should be ascribed a
correspondingly large target area (Tog's Law).  Tab list on context menu
makes sense in this context.  It's a much easier to hit target than
finding the "Tabs" menu (sized to four letters) on the menubar.

 
> >MIME types / Open With
> >----------------------
> >
> >  - If MIME types are going to be managed within GNOME, *DO* provide
> >    access to the GNOME MIME type editor from within Galeon.  Similar to
> >    the proxy configuration tool.
> >
> There is no Gnome MIME editor at the moment, I'm not saying I like that
> situation (because I don't).

Any suggestions at resolution?

 
> >Bookmarks
> >---------
> >
> >  - Restore sub-portal feature of My Portal.
> >
> >    <strike>Severity:  2.</strike>
> >    Completed.
> >
> >
> >  - Provide a bookmarks search capability.  A keyword/filter similar to
> >    how the about:config window or history window would be useful.
> 
> Huh, what about the Find box in the bookmark editor ?

Doh!  I'm blind.

OK, resolved.

 
> >Cookies
> >-------
> >
> >  - Current cookie management (Remove / Remove and block) 
> >    Controls, Privacy.  Is _painfully_ slow.  I'm seeing a minute or
> >    more to delete a single cookie.  Any reason for this?  Makes
> >    operations pretty much infeasible.  Improve performance.
> 
> I don't know why it takes a while, perhaps someone would care to do some
> research.

Please.  Can you confirm the behavior?

This is with a relatively small number of cookies as well -- a dozen or
two tops.

 
> >  - There's also the question of where cookie dialogs should appear.  My
> >    suggestion is that a separate popup window should be replaced with a
> >    dialog bar across the requesting webpage or tab.  
> >    Controls.
> >
> You need to have a popup, as the page load _has_ to block until the user
> has decided what to do with the cookie (Imagine a site that sets a
> cookie on the main page, then expects it to be there when loading
> images).

Wrong.

This is the "do the sensible, least-harm thing with least user input".

  - Accepting a session cookie as a default preference offers minimal
    privacy risk, and preserves functionality for virtually all sites.

  - On user input, changing the session cookie to a persistant one
    allows for _that_ preference.

  - Allowing a default "deny all" cookies preference should satisfy
    those who want no cookies saved.

Again:  what are you trying to provide, what are the risks of an assumed
action, and what are the downsides of inaction.

In this case, I load enough browser pages on a sufficiently slow
connection that there's no good way to correlate a given cookie prefs
popup with the website it's associated with.  There is, for example, no
way to navigate from the popup to the requesting page.

If I _don't_ catch the dialog, that page fails to load.  Not sure if
this blocks loading of other pages as well, I think that it doesn't.


 
> >  - 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.
> 
> I don't understand what you mean here, we have options in the cookie
> dialog for remembering the option.

The difference is that the browser automatically preforms the
least-harm, highest benefit action (don't save persistant user
information on a remote site, _do_ load the page).  The existing
preferences setting needs to be set, in advance of page load, for each
site visited.


> >Passwords
> >---------
> >
> >    Performance is as with cookies:  painfully slow.  Improve.
> >    Controls, Privacy.
> Again, if anyone can research this we would be grateful.
> 
> >    Ability to search for specific sites / users (e.g.:  history search)
> >    would be useful.  I need to weed out some dupe entries.
> You can search for passwords...

So it is.  OK, mostly resolved.

What's not possible is to call up the username/password tuple for
editing.  Which all considered is probably a Good Thing.

 
> 
> >Advanced features.

Note that a lot of this was wishlisting / heads-up stype stuff.  The
plugins bit is really largely a docs issue, though automating d/l /
install _might_ (security and root access issues minded) be possible.
Scott Berkun's essay as possibly interesting commentary.


> >------------------------------------------------------------------------
> >
> >The following features are advanced and/or somewhat undefined, but
> >should be kept in mind in looking at future Galeon development.
> >
> >
> >
> >RSS
> >---
> >
> >   Galeon largely lacks RSS features.  I'm not entirely sure what we
> >   want to see here, but it's a topic which should be on the table.
> 
> There are certainly more important things to do before implementing RSS
> feeds.
> 
> 
> >
> >Google
> >------
> >
> >   Google is becoming one of the major factors in pushing web features,
> >   with its smart search, gmail, maps, and other features, and is become
> >   a de facto establisher of standards.  Making Galeon compatible with
> >   the tricks Google is shoving down browser-designer's throats is going
> >   to be an increasing concern.
> >
> Do you have any particular problems with galeon and google ? or are you
> just spreading FUD ?

Well, the maps feature apparently didn't like by browser, or browser
string:


    Your browser is not supported by Google Maps just yet. We currently
    support the following browsers:

        * IE 5.5+ (download: Windows)
        * Firefox 0.8+ (download: Windows Mac Linux)
        * Netscape 7.1+ (download: Windows Mac Linux)
        * Mozilla 1.4+ (download: Windows Mac Linux)

    We are working on supporting Safari. Regardless of your browser
    type, you must have JavaScript enabled to use Google Maps.

    We recommend you download one of the browsers above, or you can try
    to load Google Maps in your current browser.

Hrm.  May just have been Javascript.  Seems to be working, but slowly.



Also:  this wasn't stated as a "it doesn't work" situation, it was as a
"Google is starting to rule the Web, we're going to want to pay
attention to it".   My understanding is that Google's playing at the
edge of some features in creating rapid-feedback interactive apps, not
sure if they're violating standards in doing it.

Suggest you mellow the attitude, Crispin, I'm trying to be helpful.

 
 
> >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.
> 
> There is no way that most FF extensions can (or ever will work). I have
> toyed with adding an interface similar to Ephy's extensions interface to
> galeon, but time is always lacking ....

I suspected that might be the case, but wanted to ask.
 
 
> Although there are some good ideas here, most are just pipe-dreams
> unless the number of active galeon developers increases.

Right.
 
> Actually in the long-term I would like to see Epiphany and Galeon
> merging back together. 

If that happens, I'm pretty much certainly going elsewhere.  GNOME isn't
_my_ future.

> Epiphany has (IMO) been slated as not providing lots of features, and
> it is true that it doesn't provide as many as Galeon, however it does
> have:
> 
>  - An extension interface (with python bindings, and the start of mono
>    bindings)
>  - More active development (chpe is just amazing).
> 
> Of course, there are things in Epiphany that I don't like, and I'm
> hoping that in the next Ephy release cycle I can sit down with chpe
> and work out how best to add hooks for extensions to alter things. I
> would love to see a 'Galeon' extension to epiphany to bring back all
> the things galeon provides.
> 
> The above doesn't mean I'm going to stop developing galeon, but I
> haven't been quite as active recently due to various other 'life'
> distractions.

Fair 'nuf.


Peace.

-- 
Karsten M. Self <[email protected]>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    So don't deal with it.  Don't use software that uses it.
    - Jeff Waugh, offering preferred GNOME usability workaround.
       http://zgp.org/pipermail/linux-elitists/2004-January/008588.html

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

iD8DBQFCFK6aefG8443k044RAsENAKCAZJdyBeAcUV8G/4kCdIhu1swLYgCfSErm
FoGZWuU2s6NjYeoymDFzefE=
=MFby
-----END PGP SIGNATURE-----