On 11/08/2017 21:34, neandr via Maildev wrote:
You need to place an icon on the menu bar. Please use the TB hambg
menu to open the Perferences --> Toolbar Layout and d&d the
"vContacts" icon onto one of your menu/toolbars. Start with that
getting two default contacts.
Currently there is another problem, you need to use TB Daily, my
current version is 56.0a1.
Others like 45.8.0, 52.2.1, 54.0a2 don't work for me, I'm on Mint 17.3.
Hey, today is the first time I saw this working \o/ !! Thank you so
much, and sorry about my negative words.
As you know from my weekly report, I won't have any time to dedicate to
this, I'm basically in this thread since Enrico asked.
Jörg.
Hi Jörg,
thanks for the feedback and good to see you was able to get it running.
For sure I'm following the team's and your reports. It's amazing to see
your workload and outcome .. GREAT!
Two remarks:
with my previous post I added the vContacts problems because I
expect it's because of some code changes of the Moz/fx teams, f.ex.
promises. Hope to find the cause about that.
as mentioned I would like to see the tb-planning team making
progress with defining the future of TB (revised or new) and how to
modernize parts of TB. Most hopefully we get some elements forward
like "front-end thread pane" (Kent), "moving to web technologies"
(Magnus) and with the vContacts project I try to push a bit for that.
Anyhow, thanks for your posts, keep your strong work going on 8-)
Günter
Am 11.08.17 um 21:52 schrieb Jörg Knobloch via Maildev:
On 11/08/2017 21:34, neandr via Maildev wrote:
You need to place an icon on the menu bar. Please use the TB hambg
menu to open the Perferences --> Toolbar Layout and d&d the
"vContacts" icon onto one of your menu/toolbars. Start with that
getting two default contacts.
Currently there is another problem, you need to use TB Daily, my
current version is 56.0a1.
Others like 45.8.0, 52.2.1, 54.0a2 don't work for me, I'm on Mint 17.3.
Hey, today is the first time I saw this working \o/ !! Thank you so
much, and sorry about my negative words.
As you know from my weekly report, I won't have any time to dedicate
to this, I'm basically in this thread since Enrico asked.
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 8/11/17 12:18 AM, Enrico Weigelt, metux IT consult via Maildev wrote:
Is there anything that Tbird really needs from newer Gecko in the
near future ?
Security updates of all kinds. And of course you'd also be cut of from
all future JavaScript (and other web feature) improvements.
You can't "pause at current Gecko" (more than very very short times).
We'd never be able to get back on track.
-Magnus
On 13/08/2017 21:38, Magnus Melin via Maildev wrote:
You can't "pause at current Gecko" (more than very very short times).
We'd never be able to get back on track.
Currently we just take all Gecko changes 100% trusting that Mozilla
would do the right thing re. security.
If we stopped, we'd create two problems: Since their code is moving
fast, it would be increasingly hard to merge changes we want into our
fork. The other problem is that we'd have to become Gecko and security
experts to know which changes include.
Many have tried and many have failed, and this has also been discussed
many times.
Jörg.
On 13.08.2017 22:20, Jörg Knobloch via Maildev wrote:
On 13/08/2017 21:38, Magnus Melin via Maildev wrote:
You can't "pause at current Gecko" (more than very very short times).
We'd never be able to get back on track.
Currently we just take all Gecko changes 100% trusting that Mozilla
would do the right thing re. security.
Isn't es52 still receiving security fixes for quite a while ?
If we stopped, we'd create two problems: Since their code is moving
fast, it would be increasingly hard to merge changes we want into our
fork. The other problem is that we'd have to become Gecko and security
experts to know which changes include.
Why not just always base on esr branches ?
--mtx
On 14.08.2017 03:36, Enrico Weigelt, metux IT consult via Maildev wrote:
Why not just always base on esr branches ?
We are basing on ESR > TB 52. Until ESR for 52 phases-out.
All later TB versions are to follow the M-C changes successively. If we
would wait until 59, the next ESR, will be out and then adapt our code
to 59, we would never have the time to do it in one rush. It would also
be very hard work on it as all the changes can interfere together.
Richard