Using insertItem to move item from toolbar palette to toolbar no longer works, what is replacement?
On Tue Apr 30 2019 03:21:18 GMT-0400 (Eastern Standard Time), Magnus
Melin mkmelin+mozilla@iki.fi wrote:
Another angle is that defaults are really powerful - most users don't
customize at all I'd bet.
I think you might lose that bet, but regardless, decisions that affect
everyone shouldn't be made based on 'I bet' feelings...
So if there are features that should be on the toolbars by default we
should add them there, and not avoid the issue by saying people can
customize it to their liking.
Really. I'm not sure if there is a language issue here, or if you are
really saying what you seem to be saying, but...
Just so you know, the way I am reading this is "If there are any
features that someone might want we should just put them all on the
toolbar, and to heck with everyone's ability to customize things the way
they want - we know better!"
I really don't think that is what you are saying, but that is how it
reads (to me at least).
Sure, everybody don't want the exact same setup, but most users will
just get a sub-par experience if the defaults aren't what they are
should be.
There is nothing wrong with defaults, but to then say that people
shouldn't be able to customize it to their liking - well, Mozilla used
to be all about customization.
I really, really hope I am reading this wrong, especially since I voted
for you.
Oh, boy, here we go with yet another iteration of the Thunderbird
developers asserting what users want and what is best for them without
actually asking the users about it, and asserting what add-on developers
want and what is best for them without actually asking the add-on
developers about it.
I've been around this merry-go-round so many times that I have no desire
to do it yet again, so this will be my final message in this thread.
Add-on maintiners can fix our code to "work like before" to the extent
that we can now add our customizations directly to the relevant hboxes
rather than putting them in the toolbar palette. But we can no longer
give users the ability to decide whether they want specific
customizations in a standard way that confirms to the mechanism they are
already familiar with for how to add things to toolbars. That
functionality is gone, gone, gone because of this change. It's not nothing.
Yes, I 100% agree that defaults should be sane, and that's why Folder
Pane View Switcher added its customizations to the folder pane toolbar
by default, but the user had the option of removing them (or putting
them back later) using the standard technique.
I just think it's hilarious that you took something away that was
actually benefiting users and add-on developers -- without asking users
or add-on developers about it first -- and are now claiming that taking
away this benefit is actually the benefit.
I 100% agree that Thunderbird should reuse Firefox code whenever
possible. If Firefox has a different way to handle toolbar
customization, then I 100% support modifying Thunderbird to use it, and
I am 100% willing as an add-on maintainer to adjust my add-ons to do
things the new way. But that's not what you did. Instead of switching to
a new mechanism for toolbar customization, you just got rid of the
toolbar customization completely.
As I said, we've been down this road before. There is a long proud
history of the Thunderbird maintainers making unnecessary changes that
impact users and add-on maintainers without consulting with them first,
and I see no reason why that would change. But at the same time, I feel
compelled not to sit by silently when it happens yet again. And so, I am
calling it out here.
fin
jik
On 4/30/19 3:21 AM, Magnus Melin wrote:
On 29-04-2019 23:21, Jonathan Kamens via Maildev wrote:
Hmm, I understand that some "crazy" toolbars got removed, like the
"Folder Pane Toolbar" where the "All Folders", "Unread Folders",
..., "Unified Folders" can be selected. This area shouldn't really
be customised,
Why not?
The removed customization of these toolbars (now hboxes) is really
about user-facing customizability of them. Add-ons can adjust the code
to make it work like before. We had a huge amount of these kind of
toolbars that were customizable toolbars just because. In practice,
there was not much or anything you could reasonably customize there.
Our toolbar customization code has unfortunately diverged pretty far
from what Firefox has at the moment. I think we should move in that
direction, and having random customization support makes that pretty
hard to support. Another angle is that defaults are really powerful -
most users don't customize at all I'd bet. So if there are features
that should be on the toolbars by default we should add them there,
and not avoid the issue by saying people can customize it to their
liking. Sure, everybody don't want the exact same setup, but most
users will just get a sub-par experience if the defaults aren't what
they are should be.
-Magnus
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
/I/ didn't decide this, just happened to be the one who made the change.
GL
On 30/04/19 07:12, Jonathan Kamens via Maildev wrote:
Update: the problem isn't that insertItem no longer exists for
toolbars. The problem is that folderPane-toolbar is no longer a
toolbar. Geoff decided that having it be a toolbar "provides no
benefit over <hbox>
https://hg.mozilla.org/comm-central/rev/3bdcf6d1a44527cdef3f0d953e0ce722d8f73c6c".
I guess the ability of add-on maintainers to provide optional
customizations for it using the standard toolbar palette /
customization mechanism is not considered a benefit?
Anyway, I've updated my add-on to reflect this change, but I can't say
I entirely agree with it.
jik
On 4/28/19 3:42 PM, Jonathan Kamens wrote:
One of my add-ons adds a button to a toolbar palette in XUL. Then in
code, it checks if that button has been added to the corresponding
toolbar, and if not, then it calls insertItem on the toolbar to add
the button, specifying the ID of the button.
This broke some time in the past few days, insertItem is no longer a
function on the toolbar object.
What should I do instead?
I tried to figure out how to use insertBefore, but that requires that
I specify the actual button that I want to add, not its ID. I don't
know how to get the button, since it's not actually in the document.
It's in the palette, whose children do not show up in searches done
with document.getElementById.
I've done a bit of searching and I can't figure out how to access the
palette from my JavaScript code.
I could take the button out of my XUL and construct it manually in my
JavaScript, but I'd rather avoid that if possible.
Suggestions?
Thanks,
Jonathan Kamens
On 30-04-2019 17:43, Jonathan Kamens via Maildev wrote:
Add-on maintiners can fix our code to "work like before" to the extent
that we can now add our customizations directly to the relevant hboxes
rather than putting them in the toolbar palette. But we can no longer
give users the ability to decide whether they want specific
customizations in a standard way that confirms to the mechanism they
are already familiar with for how to add things to toolbars. That
functionality is gone, gone, gone because of this change. It's not
nothing.
Yes, I 100% agree that defaults should be sane, and that's why Folder
Pane View Switcher added its customizations to the folder pane toolbar
by default, but the user had the option of removing them (or putting
them back later) using the standard technique.
If the user doesn't want that button on the folder pane, the easy (and
correct) solution is to disable/uninstall that add-on. It's the sole
purpose of it, no? There is no need for the user to do this
customization. The customization is done by the add-on: either he wants
the add-on or he doesn't. Sorry, but I do think that's very reasonable.
-Magnus
On 30-04-2019 17:35, Tanstaafl wrote:
Just so you know, the way I am reading this is "If there are any
features that someone might want we should just put them all on the
toolbar, and to heck with everyone's ability to customize things the way
they want - we know better!"
I don't think that's a correct interpretation.
There are things that can and should be end-user customizable, but there
are also places where end user customization (other than potentially
through add-ons) makes little sense. Of the removed "toolbars", there
were a few where all the things one can customize was empty space.
-Magnus
On 5/1/19 7:40 AM, Magnus Melin wrote:
On 30-04-2019 17:43, Jonathan Kamens via Maildev wrote:
Add-on maintiners can fix our code to "work like before" to the
extent that we can now add our customizations directly to the
relevant hboxes rather than putting them in the toolbar palette. But
we can no longer give users the ability to decide whether they want
specific customizations in a standard way that confirms to the
mechanism they are already familiar with for how to add things to
toolbars. That functionality is gone, gone, gone because of this
change. It's not nothing.
Yes, I 100% agree that defaults should be sane, and that's why Folder
Pane View Switcher added its customizations to the folder pane
toolbar by default, but the user had the option of removing them (or
putting them back later) using the standard technique.
If the user doesn't want that button on the folder pane, the easy (and
correct) solution is to disable/uninstall that add-on. It's the sole
purpose of it, no?
I know I said I wasn't going to comment again in this thread, but I'm
not going to let factual misstatements about my add-on go uncorrected.
No, the buttons are not the sole purpose of Folder Pane View Switcher.
Educate yourself before you make arguments based on falsehoods.
Not to mention that even if the buttons were the sole purpose of this
add-on, who's to say that there wouldn't be some other add-on at some
point in the future which provided buttons as well as other functionality?
Is the argument you're making now that it's inconceivable that add-ons
which provide optional buttons for toolbars might contain other
functionality as well? Or that such an add-on would simply be
unacceptable? Because Folder Pane View Switcher is an existence proof
that both of these arguments are simply false.
The TB developers really need to ask yourselves: if you have to go
through such contortions and make such strained arguments to justify a
change you've made, perhaps the change wasn't such a good idea?
jik
On 01/05/2019 12:40, Magnus Melin wrote:
On 30-04-2019 17:43, Jonathan Kamens via Maildev wrote:
Add-on maintiners can fix our code to "work like before" to the
extent that we can now add our customizations directly to the
relevant hboxes rather than putting them in the toolbar palette. But
we can no longer give users the ability to decide whether they want
specific customizations in a standard way that confirms to the
mechanism they are already familiar with for how to add things to
toolbars. That functionality is gone, gone, gone because of this
change. It's not nothing.
Yes, I 100% agree that defaults should be sane, and that's why Folder
Pane View Switcher added its customizations to the folder pane
toolbar by default, but the user had the option of removing them (or
putting them back later) using the standard technique.
If the user doesn't want that button on the folder pane, the easy (and
correct) solution is to disable/uninstall that add-on. It's the sole
purpose of it, no? There is no need for the user to do this
customization. The customization is done by the add-on: either he
wants the add-on or he doesn't. Sorry, but I do think that's very
reasonable.
Are you referring solely to the specific case of Jonathan's addon or to
addons in general? If the former then Jonathan has thoroughly addressed
his addon in his message above.
If the latter then surely it goes without saying that an addon may have
functionality that could be accessed via a variety of means. It could
have optional toolbar buttons, menu entries, key bindings, and so on.
Why shouldn't optional toolbar buttons be enabled or disabled by the
user using the normal and expected toolbar customisation features?
Expecting user to have to uninstall an addon merely to customise a
toolbar makes no sense whatsoever.
Changing what was, in effect, a toolbar to something that is now
'something-like-a-toolbar-but-not-really-a-toolbar' seems... odd. Is
commonality with the Firefox code base really worth attacking the one of
the key bases of Thunderbird's success, that is to say addon and
customisation flexibility?
--
Mark Rousell
On 30/04/2019 08:21, Magnus Melin wrote:
Our toolbar customization code has unfortunately diverged pretty far
from what Firefox has at the moment. I think we should move in that
direction, and having random customization support makes that pretty
hard to support.
Thunderbird is not Firefox.
Thunderbird cannot reasonably follow Firefox everywhere it goes.
Could it be that what you refer to here as "random customization
support" is not some random feature for its own sake but is, in fact,
one of those (small but nevertheless real) differentiating features
between Thunderbird and Firefox. It seems like it to me as a user of
Thunderbird.
Let's face it: Firefox is going its own way and it is surely both
inevitable and necessary for Thunderbird's code to increasingly diverge
from Firefox's.
Please do not let the Thunderbird project make the very same mistakes
that Mozilla is making with Firefox, merely in order to retain
potentially harmful or limiting commonality with Firefox.
So if there are features that should be on the toolbars by default we
should add them there, and not avoid the issue by saying people can
customize it to their liking.
Allowing customisation, either by the end user directly and/or by the
user installing addons, does not mean that default should not be good or
need not be good.
Sure, everybody don't want the exact same setup, but most users will
just get a sub-par experience if the defaults aren't what they are
should be.
Good. There hasn't been any suggestion that defaults should not be what
they should be, has there. The issue here is a seemingly arbitrary
change in base functionality merely to retain code commonality with a
different piece of software with a different set of goals.
I understand the desire for code commonality. It should save effort and
this is important where resources are very limited. But, as I observe
above, saving effort is no use whatsoever if the ultimate end result is
to eliminate the distinctive features that made Thunderbird successful
and allow it continue to be successful.
--
Mark Rousell
On 01-05-2019 22:25, Mark Rousell wrote:
Could it be that what you refer to here as "random customization
support" is not some random feature for its own sake
But it is/was. For something like the main toolbar a user could
reasonably expect to through some means change what's in there. Being
able to right click and add features on a a smaller UI element somewhere
is clearly unexpected - this is the "random" I'm talking about.
Let's face it: Firefox is going its own way and it is surely both
inevitable and necessary for Thunderbird's code to increasingly
diverge from Firefox's.
On the contrary, we're trying to converge as much as we can with Firefox
to be able to focus on the core Thunderbird functionality. Thunderbird
is about mail and open standard communication protocols. We're not in
the business to create or support a bunch of widgets we don't need.
You're drifting pretty heavily from the target if you want the main goal
to be a UI with lots of customization options. It's about easy efficient
communication and personal data management at a core, and much of the
rest is just added benefit.
-Magnus
On Thu May 02 2019 04:25:21 GMT-0400 (Eastern Standard Time), Magnus
Melin mkmelin+mozilla@iki.fi wrote:
It's about easy efficient communication and personal data management
at a core, and much of the rest is just added benefit.
Well, I would suggest that being able to customize the UI is what can
make communication easy and efficient. A UI you might find intuitive, I
might find clunky and totally unintuitive, and this is precisely why I
have always preferred Firefox and Thunderbird, because its UI has always
been heavily customizable - at least, almost as much as I have ever needed.