Re: Galeon 1.2.5 to 1.3.19 conveersion a couple of questions

On Sat, 2005-02-05 at 21:19 -0800, Karsten M. Self wrote:

>   - Tab navigation.  1.2 allowed scrolling the tablist without changing
>     the focused tab.  That was a win.  Is this on 1.3's ToDo?

This is standard GtkNotebook widget behavior, and if I recall correctly
the behavior was changed between gtk1 and gtk2 for usability and/or
accessibility reasons.   We are not going to start messing with it.  If
the notebook behavior bothers you, you should raise the issue on more
relevant mailing list, like gtk-devel or usability.


>   - Open With.  Browser associations were managed within the browser in
>     1.2, it's done within GNOME in 1.3.  Worse, the system's fallen
>     apart in the past few months for Debian users where few if any
>     associations work, and many handlers aren't available.  1.2 allowed
>     specifying "always ask/never ask" and "always use/never use", 1.3
>     doesn't.

Yeah, many packages needed to be updated to the new mime registry in
gnome 2.something (nothing to do with Galeon, though.)

The latter part is rather unfortunate.  Since the mime handlers are now
managed in nautilus, the kind of "always do foo" additional flag belongs
in there as well.  But as it is a small enhancement (saves one click) in
relatively rarely used place, and getting it done right takes effort,
it's not getting much attention...


>   - FFX is desktop agnostic.  No GNOME deps.  No KDE deps.  No GNUstep
>     deps.  No Evolution deps.  No Motif deps.  Sweet.  There's a lesson
>     here, people.

Yeah, being desktop independent forces you to reinvent everything
instead of being able to reuse existing and more widely used, and
therefore tested, codebase.

OTOH depending on GNOME frees the little resources we have to
concentrate on the browser itself rather than figuring out how to do X
session management, or how to seamlessly integrate with file managers
(though, the nautilus bonobo component is no longer as relevant) GConf
avoids introducing yet another way of managing preferences, and so on.

We'd even like to separate the bookmarks management off the browser,
because the bookmarks shouldn't be tied to a browser.  Sure there should
still be a way to integrate the bookmarks service thingie and the
browser, but really the browser should only load bookmarks and be able
to add bookmarks.  The frontend and backend should really be separated.


> > Sessions are _NOT_ bookmarks, OK they are at best a superset of bookmarks.
> > I've played with this a bit today, and I might be able to get some of
> > the functionality back using this, but.
> > 
> > I have sessions for various browsers (home work etc), an the browsers
> > start up and auto open all the appropriate pages I'll be refering to
> > on a regular bassis from there. Can I even acomplish this, mutch less
> > conveintently switch between these "sessions" with the new way of
> > doing this?
> 
> I think you've got a fair gripe here.  If you could spell out session
> management features you'd like to see, we might see them back.

The problem is how one defines a "session" .. you get to interesting
cases when you include different workspaces and such.  It's also very
unclear how much responsibility belongs to window manager, as it is the
only entity that *really* knows window positions.

When we last were working on sessions, the majority considered sessions
equal to a set of tabs ina  single window.  And support for that was
eventually implemented.

Now redefining session to mean something else than most expect is going
to cause confusion and additional complexity.  One should think hard if
that is really worth it.


-- 
Tommi Komulainen                                 [email protected]
GPG 1024D/68388EE6    6FD6 DD79 EB38 BF6F 3533  09C0 04A8 9871 6838 8EE6

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

iD8DBQBCBiPXBKiYcWg4juYRAqS8AKCdecqMdoB+hAMFWMNbJ1AQZ8knxgCgqlFa
5TfX9Gi7fN44EuVuDfx/EVY=
=OZb2
-----END PGP SIGNATURE-----