Userscripts.org

Hi Tertioptus, can I add an option to hide spam unread count on pilot mode?

I'd love to have a way to disable the label pop-out behavior. My labels fit just fine, and it annoys me, because it makes the other widgets in the left column pop up and down

Funny, it used to happen with me too, but it doesn't anymore.
Do you have labs enabled? I think it has something to do with "Navbar drag and drop" and "Tasks"
Because the tasks link changes the way drag and drop works (i.e. it can be placed between label and chat box)
But I can't reproduce it anymore, my chat box stays put when I mouse over the label box.

Wierd - now I can't reproduce it. I wonder if something changed w/ offline enabled. Or maybe I'm just hallucinating.

A little bug is happening with me. If a have a label with two parents, lets say:
subLabelC:labelA,labelB
If I open labelA and labelB nodes, subLabelC will show only under one of them, the other one will have a blank space.
Have you already noticed that?

I want to put a commonly used label name (e.g., Admin) inside several different labels (e.g., Project1, Project2, Project3), but I want each version of Admin (and everything beneath it) to be specific to the particular parent label (i.e., the project label). However, LL4G seems to think each version of Admin is the same one -- it will only display Admin under one of the project labels at a time (the others get a blank line). Furthermore, if I want to create a sublabel under Admin, LL4G puts that sublabel under all instances of Admin, even if I just want it to be specific to one of the projects. For example, if I want Project1/Admin/Contacts, I have to create a label called Contacts:Admin -- but LL4G shows Contacts under all 3 instances of Admin instead of just under Project1 (because it doesn't know which parent of Admin I want it under). Even worse, there's no way to specify a separate Contacts label for each Admin label. I know one solution would be to use more uniquely identifying labels (e.g., Project1/Project1Admin/Project1Contacts), but that starts to make for some very long labels (which easily exceed Gmail's label length limit). It can also be hard to anticipate ahead of time, so you end up having to go back and rename labels when you realize you've got some duplicates.

I'm not sure if there is an easy solution to this, as it seems to be an inherent problem when you allow labels themselves to have multiple labels. I wonder if there could be a way to specify that a new label is intended to be nested only within a particular part of the label hierarchy. For example, Contacts:Admin:Project1 (which says this Contacts label is a member of the Admin label that is a member of Project1). To make Contacts a member of two separate Admin labels, you could use Contacts:Admin:Project1,Admin:Project2 -- or to be more clear, maybe Contacts:(Admin:Project1),(Admin:Project2).

I haven't thought this through, but I'm wondering if anyone else has encountered this issue and if there are any thoughts on possible solutions/alternatives.

The first thing is that you have misconception of LL4G. Labels are NOT folders! Just like and e-mail can be labeled by many labels at once, a label can be under many labels at once, and it's the same. Although LL4G have some limitations that we're working on, that is to label a e-mail based on its hierarchy and label the e-mail automatically with all top level labels, but this doesn't change the 1st concept.
The problem of the blank line when you open two or more top labels of a sublabel, it will show on once! That's a known issue, but it has a good point that is to show you that there's only ONE label! The concept above that I tried to explain.
Concluding, this 'Admin, Contacts' structure is a folder structure, not labels! Maybe you want to use Folder4Gmail http://userscripts.org/scripts/show/8810

Thanks for the bug fixes (separate topic) and for your discussion of the LL4G philosophy. I understand that LL4G is labels and not folders. But the whole purpose of allowing hierarchical labels is to replicate some of the functionality available with folders. Labels let you put a given email (or even label) into more than one category, and folders allow you to create a hierarchical structure for ease of navigation and cognitive processing. I don't want to give up the label functionality and move strictly to folders. I think what I articulated is a legitimate use case -- sometimes you want a label to be strictly nested within a particular part of the hierarchy rather than being global. One shouldn't have to give up the general flexibility of the label metaphor to do that. The best of both worlds would be to keep the full labeling functionality but also allow for some labels to be specified in a more folder-like structure.

With regard to the blank lines, I understand the rationale for that when the multiple instances are actually references to the same exact label, but in the case I described, they are in fact completely different labels with completely different sets of emails assigned to them. The labels are Admin:Project1, Admin:Project2, and Admin:Project3 -- each instance of Admin is indeed a distinct label with different emails, so there is no reason to only allow one of them to be visible at a time. LL4G mistakenly treats them as the same label, but they're not (they just happen to have the same name). The point is that it would sometimes be useful to be able to re-use common/standard label names but still have the different instances be treated as different labels.

I do prefer LL4G over F4G because LL4G has some additional neat functionality, such as the expanding label box and top-level searches (not to mention the ability to show a given label below more than one other label). Also, LL4G's method of specifying the hierarchical structure doesn't require including the entire path in the label name for labels deep in the structure -- this is helpful because Gmail limits label length, and with a deep structure, F4G quickly starts hitting the label length limit.

Yeah, I agree with you that LL4G could add more functionalities to label hierarchical structure, but I still think its the same label. Let's take the music organization example (I think its easy to understand). Say we have labels for music genres: rock and classic, and we also have labels to bands e.g. myBand and yourBand.
'till now there's no problem with folders, but if myBand that usually plays rock make a classical cd, I'm in trouble, I'd have to creat another folder for myBand under rock folder, with labels we don't have this problem. Now if we use labellinks to organize our labels, and create the top level with genres and second level with bands that play that genres, my band should be placed both in rock and classic top levels, and if I click o myBand label, no matter what is it parent, labellinks will show us all myBand musics no matter its genre, which is a good thing, but if I want to see only rock music of myBand I'd have to do a search, labelLinks could be enhanced and provide this search, like it does with the top levels labels. This require that we always label our music/mail within the structure, I mean, on both top and sub labels. But there's no easy way to LL4G to do this since the sublabel is just one and we should add this labels manually in other for this to work.
If we always label our mails like this, the actual powersearch will be useless.
Obviously the behavior of clicking the label or powersearch could be switched, it's just a how you look at it.
Sorry if I'm being redundant, but do you understood me well?
I emphasize once more, the label must be the same to allowed us finding all myBand musics, if they were different we'd have to do a much more complicated and error-prone search. Anyway, this 2nd powersearch (e.g. myBand AND rock) can be implemented, but to me it's not so useful since I don't always label my mails on both top and sub labels.

When I posted the above, CloudKicker's post had not showed in my browser and I obviously didn't read it.

Henrique, you provide a good illustration of the benefits and power of LL4G. However, your example isn't quite the same as mine. In your example myBand is a single unique category. It can be a subcategory of rock or classic, but under either rock or classic, it still essentially refers to the same entity (namely, myBand). In my example, the three instances of Admin are not the same. Admin for Project1 has absolutely nothing to do with Admin for Project2, and I wouldn't have any reason to ever group all the Admin stuff together across projects. I might even use Admin in an entirely different context in which it doesn't even have anything to do with projects. Perhaps a more clear example is use of a label like Misc. You might want to use Misc as a sublabel within all different types of categories, but there would be no reason to assume that there's any conceptual connection between Misc items from category to category. Generally, you would have no interest in a general high-level collection of Misc items across all the different areas of your hierarchy -- they wouldn't be related in any way. A particular instance of Misc only has meaning within the context of some specific higher level category. Examples of other very generic labels might be Notes, Info, or Archive. The bottom line is that if I'm in the Project1 part of the tree and I click on Admin, Misc, or Notes, I only want to see Admin, Misc, or Notes items associated with Project1. It would be burdensome to have to wade through a bunch of items not associated with Project1, entirely defeating the purpose of allowing the hierarchical structure.

You do offer a clever solution, which is for LL4G to include a special link to click on the Admin label that would execute a search showing only the Admin items associated with the current project (i.e., if I click the Admin link under Project1, it does a search for Admin AND Project1). But as you point out, that's not ideal because it requires adding the higher level label (e.g., Project1) too, which among other things defeats the purpose of the current top level power search.

CloudKicker, thanks for spelling out a possible label configuration to meet this need. That's roughly what I'm doing. What I don't like about it is that it requires unique names for Admin and Contacts (e.g., AdminProject1). I don't like the look of that, and it makes the labels unnecessarily long (and risks exceeding the Gmail length limit, though I suppose my proposed solution could have that problem as well). The other downside is that it requires foresight -- you have to know ahead of time that some label you plan to use within one part of the hierarchy may be used somewhere else. If you fail to anticipate this, then you've got to go back and do a lot of renaming after the fact (which is what happened to me).

I guess I haven't really tried to work it out in detail, but at least at a conceptual level, I think my suggestion might work. Currently, when a new label is created, a colon is added followed by a list of existing higher level labels it is a member of. The limitation is that the list of higher level labels cannot itself include any colons. What if we just allow colons in the higher level labels? Suppose I've got labels Admin:Project1 and Admin:Project2. Now I create Contacts and want to assign it specifically to Admin:Project1, so I use Contacts:Admin:Project1. That's equivalent to saying assign this version of Contacts to the Admin:Project1 label only. Admin:Project1 is an existing label, so why not allow it to be placed after the colon for Contacts? You could still create a label such as Contacts:Admin, which would put Contacts beneath all versions of Admin if that's what is desired. Perhaps I'm not thinking it through properly, but it seems to work at a conceptual level. I don't think it breaks or conflicts with existing functionality or syntax -- it just adds an additional possibility. The question is, how difficult would it be to implement? I have no idea about that -- maybe it's relatively straightforward, maybe it's complicated.

Anyway, I hope I'm not sounding too nit picky. I think LL4G is great and has some nice advantages over Folders4Gmail. This is just one use case that is highly relevant to me.

As of today, or yesterday actually, LL4G stopped working for me. Anyone with a similar problem? If I am the only one I can provide the details of my configuration. I just wanted to check first if there was some update in Gmail that made LL4G fail for everyone.

Yes, it stopped working for me too. And its consuming huge processing, firefox is not operable with it.
I've checked error console and it's repeating this message every sec.
lastNode is not defined
Have you experienced it too CloudKicker?

Yes, I've got the same problem -- it no longer works and is eating up my processor. Hope we can fix this. I'm on Windows XP Professional SP3, Firefox 3.0.6, and GreaseMonkey 0.8.20090123.1.

It's definitely a Gmail change, I've tried 2.8 script version and the problem persisted.

I just tried the update, and now none of my labels appear in the label box (just a small empty box). However, it does properly display the labels in the inbox (i.e., it cuts off everything after the colon).