[Epiphany] Re: Tabs options
- From: "David Adam Bordoley" <bordoley msu edu>
- To: epiphany mozdev org
- Subject: [Epiphany] Re: Tabs options
- Date: Fri, 29 Aug 2003 14:50:43 -0400
Marco Pesenti Gritti writes:
>
> Trying to summarize, there are 4 boolean preferences:
>
> Ever show the tab bar
>
> I consider it a work around pref to avoid page movement when opening
> second tab -> it should only be in gconf, no ui for it.
> Dave suggested that tab bar on the bottom could solve the actual problem.
Right. Plus its worth noting that task switching is traditionally at the
bottom of screen. Another app that does this is X-Chat. I'm not claiming
that X-Chat is a pillar of usability (heheh) but it does show that people
use this without complaining too much.
>
> Open popups in tab
>
> This is more controversial. It can be considered a work around for
> lacking popups blocking or a way to do popup blocking that better feel
> some people needs. I'd tend to say gconf only but I'm not super strong
> feeling
This should be hidden imo, if it exists at all. I still consider it a hack,
since most popups that users might actually use are more
internet-application like and the usual browser chrome etc. doesn't apply to
them.
>
> External links in tabs
>
> There are people that use only one window with tabs, like true MDI.
> I dont think supporting MDI make much sense in epiphany... so this would
> be just a make hackers happy thing. It could be grouped with popups
> (resulting in a MDI switch) or we could just keep current command line
> option.
My only opinion is that this shouldn't be a visible pref. Personally I don't
think it is worth the bugs and code complexity in order to appease a small
usage group. To be honest until redhat/suse/sun or one of the other large
linux distros starts distroing ephy we won't really have real world test
results. Right now most bugs (well in general too) come from technically
savvy users due to the fact that you either need to a) build it from
cvs/tars, b) be using debian, c)installing non-stock rpms.
> Finally the only interesting thing from an interface design pov here is
> the middle click->open in tab by default thing. I think it make sense because
> if we support tabs as a threaded navigation tool, we should definately use
> it by default when opening links in another "page".
> Also we would have a complete "tabs as threaded navigation tool" implementation,
> without need of tweaking settings.
I think this is a good idea. Imo the usage scenario of tabs really is task
based groupings of related pages, which is particularly useful for mailing
lists and webmail. I should add that this should also apply to alt+click
(alot of users still only have 2 button mice and mac users only have one).
> This obviously imply tabs are a good tool for threaded navigation.
> (but if they arent, why we support them ?)
Because window managers are broken and tabs should really be implemented
there but oh well, we're stuck for the time being :P
>
> /me is sort of worried of the flames we will get if we remove the
> last tab pref :)
Sort of related to this conversation is my proposal in bug 116528. Heres a
copy and paste of my proposal for all to see.
--------------------------------------------------------
Well considering that file->close only closes the current tab, I think it
might be a good idea to make this consistent with window border close. The
issues here are similar to the quit issue.
debate:
1. Close button close closes all tabs: Convenient when you have many tabs
open and just want to close the browser window, but not at all forgiving to
the user. Exposes the MDI nature of the app. Used as quit by most users so
its more of an application action than document action.
2. Close button closes only current tab: Slightly redundant with existing
tab close. Inconvenient to a power user because it requires them to close
each and every tab instead of groups of tabs. Xan has some anectdotal
evidence that suggests that this might be better for newer users. Is more
forgiving to user mistakes. Closing more than one tab simply requires the
user to hammer the window close button a few times (not that hard really).
Consistent with file->close.
The best argument imo is that making it close only the current tab is much
more forgiving to users who have multiple tabs already open and want to
close just one but out of muscle memory developed using most non mdi apps
tend towards the window border close button as oppose to the tab close
button and lose all their open documents.
Another option is to provide a menu entry in the tabs menu that closes the
window. Considering that the tabs menu will most likely only be used by
more skillful users, this might be a good comprimise.
--------------------------------------------------------------------------
dave
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]