134799 - Make any bookmark folder into a bookmark group from folder properties window

Status: RESOLVED EXPIRED

(SeaMonkey :: Bookmarks & History, enhancement)

Description

[Hixie (not reading bugmail)]

It would be cool if you could make any bookmark folder into a bookmark group
from the bookmark folder properties window.

Comment 1

[xyzzy]

The folder context menu is where I expect to find this capability.  Do you not
want it there?  If not, please explain.

Also, the ability to translate back should be provided.  Should I file a new bug
for that?

Comment 2

[xyzzy]

If the folder we are applying the translation to already contains a bookmark
group, I think we should nest bookmark groups similarly to folders.  When
opening, the list could be flattened, and opened in seperate tabs.  This would
make it easier to reuse groups of bookmarks, especially if we ever get bookmark
aliases working.

Comment 3

[Eric Light]

I like this idea

Adding myself to CC:

Comment 4

[HJ]

I don't think this is a good idea. It should be possible to open _any_ bookmark
folder as folder and group, without the need to 'convert' or 'duplicate' a given
folder. Doing it like this will be a major advantage for the "mom" users out in
the field. Why make things more complicated than they already are? Why not ad
some code to support: "Open Bookmarks Folder as Group" ?

FYI: this is the way MultiZilla solved this problem, months ago now.

Comment 5

[Nick_Jenkins]

If I'm understanding comment # 4 correctly, then I wholeheartedly agree with the
author.

There is no real requirement for the existence of group bookmarks as
differentiated from normal bookmarks.

I've used a tabbed-browser add-on for IE for a while now, and it has something
similar to "Open Bookmarks Folder as Group", except they call it "Open all
favourites". This item appears as the first item in any bookmarks folder when
using the favourites/bookmarks dropdown menu. Choosing it opens any bookmarks in
the current bookmark folder, in new tabs.

This does away with the need for group bookmarks, and it means that you can just
move bookmarks into and out of (say) a "Check the morning news" folder. This is
much nicer (to use, as well as implement I would imagine, since there it does
away with a whole special category of bookmarks). It would also simplify "Manage
Bookmarks" tool I imagine too, plus it also does away with the need for the
"File as group" tick box when adding a bookmark.

Plus, as comment #4 pointed out, this would ensure there is no duplication /
conversion / synchronisation going on between 'normal' bookmarks and 'group'
bookmarks. I've used this kind of thing for literally years now, and it really
does work very well, as well as being simpler.

Comment 6

[Hixie (not reading bugmail)]

You can already move bookmarks in and out of bookmark groups, I do it all the
time. However, the great feature of bookmark groups which other suggested
mechanisms don't allow is the ability to single click the bookmark in the
sidebar and have it open all the tabs. I don't use the Bookmarks menu, because
it requires too many mouse movements.

Comment 7

[Nick_Jenkins]

Re comment #6:
I can see that clicking on a group bookmark in the sidebar could be a handy
setup that could work well whilst keeping the number of mouse clicks low.
However, couldn't the sidebar use the same possible idea as the bookmarks
dropdown menu, and have an inbuilt first item in any folder that means "open
everything in this folder"? Alternatively, if screen space is at a premium, how
about instead of having an extra item appear, a middle mouse click (say) on a
folder could equate to the same "open everything in this folder" action. That
way you get the generality of folders, but the power of groups (and there's no
need to move anything around at all once a setup has been reached that the user
is happy with). Thoughts?

Comment 8

[Hixie (not reading bugmail)]

I don't have my bookmark groups open, if I did they couldn't all fit on the
screen at once. Also, I don't have a middle button.

What is wrong with the current behaviour?

Note that this really should be discussed in another bug.

Comment 9

[Jonas Jørgensen]

See also bug 141619, "[RFE] Treat bookmark folders as bookmark groups.", about
eliminating the "bookmarks group" concept in favour of being able to open all
bookmarks in *any* folder in new tabs.

Comment 10

[Nick_Jenkins]

Re comment #9 : Thanks, yes, that's what I had in mind.

Re comment #8:
Essentially, I don't see why there should be any distinction at all between
bookmark groups and folders. What distinction there is seems quite limited and
arbitrary to me.

Consider:
The current idea seems to be that folders are just containers - they store
bookmarks, bookmarks groups, and other folders. However, they themselves can't
currently be opened as a group. Furthermore, they can be expanded in the
bookmarks dropdown menu, as well as in the sidebar.

Bookmark groups also store bookmarks inside them, as well as folders, and also
other bookmark groups. So, in other words, they too are containers. However,
bookmark groups have the property that they can open every bookmark directly
underneath them in one go. Furthermore, bookmark groups cannot be expand using
the bookmarks dropdown menu, but they can be using the sidebar.

Why is there such an arbitrary and minute distinction?

I don't see why they shouldn't be identical, interchangeable, undistinguishable,
one and the same.

In other words, everything that can be done with a group bookmarks should be
able to be done with folders (such as opening all it's immediate sub-contents at
once), and everything that can be done with folders should be able to be done
with group bookmarks (such as expanding it's contents in the bookmarks dropdown).

This might seem to be unrelated to the current bug, but it's really not. Once
there are indistinguishable, there is automatically no requirement to convert
between them, and therefore there would be no requirement for the conversion
behaviour requested in this bug.

Comment 11

[Claudius Gayle]

I found this bug because I was going to write an enhancement request to be able
to right-click a folder and make it a group and vice-versa. Taking that action
also implies several additional UI changes - like the aforementioned properties
window addition and some tweaks of the menus(maybe bug 156153).

When bookmark groups first got the UE design treatment this ability was a
fundamental part of the plan - but somehow went missing.

Two questions arise:

1. Is it worth adding a bunch of UI and behaviors vs. simply making BM Groups
and folders indistinguishable as mentioned earlier in this bug?

2. What happens when one opens a BMGroup that contains bookmarks and another
nested folder? Has anyone seen this in multizilla or the IE add-on?

nominating for nsbeta1. I believe solving the problem of seamless integration of
Bookmark Groups into overall Bookmarks Management is the final piece in this
great feature (tabs+ bookmark groups).

Comment 12

[HJ]

1. no, it's not worth the time at all, if you ask me
2. we, multizilla, have two ways of handling the BMgroups, see my two screenshots

Comment 13

[HJ]

Attachment: without bookmarks folder filter enabled

Comment 14

[HJ]

Attachment: with bookmarks folder filter enabled

Comment 15

[HJ]

With the first set (bookmarks menu/button) you cannot only see the content of
the group but it is also plain easy to select only one bookmark, and that seems
to be used a lot in MultiZilla. The second set filters the folders out of it and
you can't select bookmarks, but that is because this is called "Load Tab Group"
and so completely different to plain bookmarks.

note: It's really easy to change the template, even I did it, but the JS
functions needs to be changed also, just to let you know.

Q: why should we hide the content of a bookmarks group to the user? What is so
handy about that 'feature'? 

"I believe solving the problem of seamless integration of Bookmark Groups into
overall Bookmarks Management is the final piece in this great feature"

What about Loading Tab Groups at startup, like in MultiZilla?

Comment 16

[Jason Bassford]

I'm completely in favour of HJ's UI, with the one caveat that I'd put "Open The
Folder As Group" at the *bottom* of the bookmark list rather than at the top. 
That way you have to explicity move the mouse cursor to get to it.  (If people
have bookmark folders that haven't changed in a while and they've "trained"
themselves to always open a bookmark within by automatically moving a certain
distance to it, putting the "Folder As Group" won't interfere with this.)

Comment 17

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 18

[home]

It seems to me that the following would be a suitable compromise:

1) Folders and Groups are one and the same entity.
2) Folder properties dialog contains a checkbox labelled "Treat as Group".
3) If the box is checked, then the default behaviour of a left click on the
folder in any of the various dialogs (with the exception perhaps of 'Manage
Bookmarks' dialog) is to open a group of tabs, and the associated icon is the
groups icon. If the box is unchecked, treat the folder as a folder in the usual
way. 
4) An accelerator key could be used to invoke the alternate behaviour (eg CTRL
Left click).

However, there is one fundamental difference between Groups and Folders, Groups
are essentially bottom level elements, whereas folders can contain subfolders.
Hence, some additional constraints would be:

a) The checkbox would be greyed out on a folder which contains subfolders.
b) Subfolders cannot be added if the checkbox is checked.

Alternatively, subfolders are permitted, but must be ignored when opening a
folder as a group. This is probably preferred.

Comment 19

[timeless]

A. Is it worth adding a bunch of UI and behaviors? imo, no.
B. simply making BM Groups and folders indistinguishable as mentioned earlier in
this bug?                                          imo, this makes more sense.
2. What happens when one opens a BMGroup that contains bookmarks and another
nested folder?                                     I'd just ignore nested folders.

Oh, i'd also drop the word 'groups' and just have "Open these bookmarks as tabs".

Comment 20

[Jason Bassford]

FWIW: If the decision here is to make "BM Groups and folders indistinguishable"
then this bug is really just a dupe of bug 141619.

Comment 21

[Hixie (not reading bugmail)]

This bug is just about adding a checkbox to the properties window, nothing more.

Comment 22

[Jason Bassford]

> This bug is just about adding a checkbox to the properties window

So this is NOT about making them indistinguishable.

The Bookmark Manager currently considers Bookmark Groups and Bookmark Folders to
be separate entities (look at the recently checked in code for help text).  For
them to be considered "indistinguishable" - as per comment 19 (point B) that
distinction would have to be dropped.  (Bookmark Groups, as separate entity,
removed altogether.)

But more to my original point in comment 20: If a fix for bug 141619 were to be
checked in - would this bug then become obsolete?  (And/or vice-versa - are they
mutually exclusive?)  Or would there be some reason to continue with a
"checkbox" implementation anyway?

Comment 23

[Chris Lyon]

*** Bug 167414 has been marked as a duplicate of this bug. ***

Comment 24

[Jan Varga [:janv]]

reassigning

Comment 25

[Pham]

bug 174778 makes more sense then this.

Comment 26

[Jan Varga [:janv]]

This is blocked by a bug in the XUL template builder.
The only difference between a folder and group is that the latter
has the NC:FolderGroup property set to true.
The problem here is that we have multiple rules in bookmark templates and one of
them is checking for NC:FolderGroup. So once we change the property it should
match a different rule, but that actually doesn't work correctly (the UI is not
rebuilt correctly).

I suspect it may be related to these comments:
http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTemplateBuilder.cpp#421
http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTemplateBuilder.cpp#512

I'll ask waterson what he thinks about it.

Comment 27

[Samir Gehani]

adt: nsbeta1-

Comment 28

[Serge Gautherie (:sgautherie)]

Based on comment 21,

and after reading the whole bugs, I'm not sure of the best solution(s),
but you may see related bug 141619 comment 33.

Comment 29

[Worcester12345]

(In reply to comment #26)
...
> I'll ask waterson what he thinks about it.
> 

What did he ever say about it anyhow?

Comment 30

[Jan Varga [:janv]]

I can't remember what he said and unfortunetely I lost my IMAP folders at that
time (July 2003).
But I still think it has something to do with this comment:
http://lxr.mozilla.org/seamonkey/source/content/xul/templates/src/nsXULTemplateBuilder.cpp#512

Comment 31

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 32

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420