SeaMonkey @ FOSDEM 2006
Robert Kaiser
As some of you might know, a bunch of SeaMonkey people (CTho, biesi,
Mnyromyr and me among others) met in Brussels last weekend in the
Mozilla developer room at this year's FOSDEM conference.
I presented the SeaMonkey project to the crowd, my slides are available
at http://kairo.mozdev.org/slides/fosdem2006/ - for those who want to
see the "special intro" I couldn't show at FOSDEM due to laptop
problems, see http://kairo.mozdev.org/slides/fosdem2006/intro.html (and
click on the page once you're ready).
The pictures I made this weekend are up at
http://dev.seamonkey.at/fosdem2006
Overall, I think we've shown the dev community that the project is alive
and that's an important step - and a big difference to one year ago :)
I'd like to note some unordered SeaMonkey discussion and side talk
topics and results here in this message - they may not be complete, so
please anyone who's been there feel free to add something to the list.
Also, if you got some comment to those topics, feel free to use your
news reader's "reply" button ;-)
- Enigmail is basically ready for landing in the mozilla.org, according
to its maintainer Patrick. The IPC-pipe code it uses should even be
reviewed (but we'd need someone to own it official - that's why it's not
been checked in yet). The Enigmail code itself (rebranded to "OpenPGP",
IIRC) is still to be reviewed. We hope we can get this in for trunk and
1.8 branch, so we can ship SeaMonkey 1.1 with PGP/GPG support.
- Paul Kim (Firefox marketing, mozilla.com website owner) strongly
supports mozilla.org being more foxused on pojects instead of
mozilla.com products, even wondered why SeaMonkey isn't on the
mozilla.org front page. Currently nobody feels responsible for
mozilla.org website content though, and we'll need someone who does.
Paul would prefer "someone from the community" to take over that
responsibility.
- Gerv (one of the 3 direct MoFo employees) stated that (especially
after the split from the Corporation) Mozilla Foundation feels its
responsibility for the exisiting projects at mozilla.org, which include
Camino, SeaMonkey and Bugzilla among others. They want to support those
projects and surely will not drop them as long as there's community
interest behind them. He applauded Camino and us for showing up in the
public with our 1.0 releases.
- Gerv, who's also resposible for MoFo's licensing stuff, and the
SeaMonkey Council people agreed on "heavily basing" our trademark policy
on the ubuntu trademark policy, which is up at
http://www.ubuntu.com/ubuntu/TrademarkPolicy - we hope to get our new
policy up soon so that people know under which terms they can use e.g.
our logo.
- all of us SeaMonkey people agreed that we should start the real work
on the "toolkit transition" stuff very soon. We still would need people
to help with that, though.
- On one hand, that transition needs us to go through all XBL widgets
and have a look on their diffs between toolkit and XPFE. Where we
(basically) don't differ and have no improvements compared to toolkit,
we should just make our jar.mn use the toolkit version. Where we have
improvements, we should get them into the toolkit version before
switching over to it. Where there are significantly differing
implementations, we should fork our own implementation into
suite/common, probably basing on the toolkit version as much as possible.
- On the other hand (and in the broader view), we should prepare for
turning the MOZ_XUL_APP flag on for SeaMonkey. This will get us lots of
the new infrastructure, but we don't know yet what will break in what
way. Someone of us would need to turn it on and find out. Who will do
that? We then should try to get us building and working well enough with
that flag turned on (using the MOZ_SUITE flag in #ifdefs where the other
flag was misused for detecton "non-suite" builds, and using it where we
don't want to switch yet). Once those patches are all in, we finally can
flip that switch in trunk completely, and have nightly build with the
new infrastructure.
- We should replace our old passwordmanager and wallet with the new
paswdmgr/satchel code, as our old implementations there are basically
unowned, known to be ugly code, and the new stuff has no problems
compared to ours - from what we know.
- Some changes like that satchel stuff will probably make profiles not
backwards-compatible, which will be the point where we also should
switch to the new profile code, using our own, separate profile
directory (.mozilla/seamonkey/ etc.) and adopt the profile migration
code of Firefox and Thunderbird to fit us.
- Reviews seem to be our main bottleneck regarding 1.1 features, and we
expect the same for the migration stuff. It might be a good idea to fo
for reviewing each other's stuff internally and learning the changes
code along the way. At least that might be the best compromise between
ditching reviews have getting shiny new stuff fast with bad code quality
and getting only very little stuff done but with really high code
quality. Once again, we'd be happy to grow our team enough that this
problem gets smaller.
- People again requested that we should move to a different icon set for
our default theme...
OK, this is where my brain stops being able to think of other stuff
we've been talking about. I guess I'll stop here for now, and add other
stuff if it comes back to my mind later on.
I hope we'll get lots of stuff done in the near future!
Robert Kaiser
Gijs Kruitbosch ("Hannibal")
> I'd like to note some unordered SeaMonkey discussion and side talk
> topics and results here in this message - they may not be complete, so
> please anyone who's been there feel free to add something to the list.
> Also, if you got some comment to those topics, feel free to use your
> news reader's "reply" button ;-)
I'm not sure whether I was the only one who asked you about this at that
point, but we (as in, you and me) discussed some of the localization
stuff? It might be good to note here if anything else was discussed /
decided on that matter.
-- Gijs
Gijs Kruitbosch ("Hannibal")
> some of the localization stuff?
I just realized this was about as nondescript as possible. I meant the
effort to get the locale moved out of the mozilla module in the main
tree, and into the l10n module in the locale tree (from what I recall,
KaiRo told me that Firefox and Thunderbird already do this). See bug 286110.
-- Gijs
Standard8
> - On the other hand (and in the broader view), we should prepare for
> turning the MOZ_XUL_APP flag on for SeaMonkey. This will get us lots of
> the new infrastructure, but we don't know yet what will break in what
> way. Someone of us would need to turn it on and find out. Who will do
> that? We then should try to get us building and working well enough with
> that flag turned on (using the MOZ_SUITE flag in #ifdefs where the other
> flag was misused for detecton "non-suite" builds, and using it where we
> don't want to switch yet). Once those patches are all in, we finally can
> flip that switch in trunk completely, and have nightly build with the
> new infrastructure.
I can try turning this on with a special build (looks like a configure
hack and a mozconfig flag), don't know how often I will be able to build
it but will be able to get you some feedback/patches hopefully.
Standard8
Standard8
Ok, so it just built in about 5 mins (normal SeaMonkey build 1-2 hours
on my machine) and no seamonkey executable. Guess we're going to need
some patches ;-)
I'll start looking into lxr tomorrow and see if I can figure some of it out.
Johannes Kastl
> - Enigmail is basically ready for landing in the mozilla.org, according
> to its maintainer Patrick. The IPC-pipe code it uses should even be
> reviewed (but we'd need someone to own it official - that's why it's not
> been checked in yet). The Enigmail code itself (rebranded to "OpenPGP",
> IIRC) is still to be reviewed. We hope we can get this in for trunk and
> 1.8 branch, so we can ship SeaMonkey 1.1 with PGP/GPG support.
Nice to hear that. I would be glad if it would work without the
linux-gtk2-compiler issues. but I could solve that by compiling myself...
> mozilla.com products, even wondered why SeaMonkey isn't on the
> mozilla.org front page. Currently nobody feels responsible for
> mozilla.org website content though, and we'll need someone who does.
Wow. I never thought that would happen ;-)
> - Gerv (one of the 3 direct MoFo employees) stated that (especially
> after the split from the Corporation) Mozilla Foundation feels its
> responsibility for the exisiting projects at mozilla.org, which include
> Camino, SeaMonkey and Bugzilla among others. They want to support those
> projects and surely will not drop them as long as there's community
> interest behind them. He applauded Camino and us for showing up in the
> public with our 1.0 releases.
Nice to hear.
> - We should replace our old passwordmanager and wallet with the new
> paswdmgr/satchel code, as our old implementations there are basically
> unowned, known to be ugly code, and the new stuff has no problems
> compared to ours - from what we know.
I hope it will be "just a backend change", cos I like the password
manager as is. But go on, I can find it bad afterwards ;-)
> - Some changes like that satchel stuff will probably make profiles not
> backwards-compatible, which will be the point where we also should
> switch to the new profile code, using our own, separate profile
> directory (.mozilla/seamonkey/ etc.) and adopt the profile migration
> code of Firefox and Thunderbird to fit us.
Wow.
Nice work, Robert. Tell all your fellows what a great job they are doing.
OJ
--
"Don't, Ginny, we'll send you loads of owls." "We'll send you a
Hogwarts toilet seat." "George!" "Only joking, Mum." (Harry Potter and
the Philosopher's Stone)
Robert Kaiser
True, we discussed that. Localizers will be happy for this to happen,
but we could clear up that it current affects only stuff that is in our
en-US.jar file, and the current stage is not affecting e.g. ChatZilla or
inspector.
Once we're able to compile with the flag --enable-ui-locale=ab-CD we'll
probably affect reporter though, as it already has been switched to
using that.
My current work in bugs 325473 and 328317 aims to get a single en-US.jar
for all localized files of the main suite instead of 5 files right now
(en-US.jar + US.jar + en-win.jar + en-mac.jar + en-unix.jar) and also
have language selection alone instead of combined with content pack
selection (as content packs are going away entirely).
Once that is done, our focus in that areas will be to move all
localizable suite-specific stuff into the suite/locales directory in CVS
and when that's done correctly, we should be able to check in locales
into l10n/ab-CD/suite/ directories in the L10n repository and use them
via the configure switch mentioned above.
All parts that currently don't have their locales in our en-US.jar (or
the other 4 files I mentioned above) will stay as-is and will see no
difference in how they work, as also chrome paths will stay completely
unchanged.
Note that calendar is currently working on getting their stuff organized
in the same way, and everything shared with Firefox or Thunderbird is
already there.
Robert Kaiser
Robert Kaiser
> Ok, so it just built in about 5 mins (normal SeaMonkey build 1-2 hours
> on my machine) and no seamonkey executable. Guess we're going to need
> some patches ;-)
That's actually what I expected, it may even try to turn on all the
startup stuff, profiles, etc.
> I'll start looking into lxr tomorrow and see if I can figure some of it
> out.
Thanks for looking into that!
Robert Kaiser
Robert Kaiser
> On 02/27/2006 09:15 PM Robert Kaiser wrote:
>
>> - Enigmail
>
> Nice to hear that. I would be glad if it would work without the
> linux-gtk2-compiler issues. but I could solve that by compiling myself...
Those will go away when we ship that code with our releases, as it will
be compiled with the same compiler as those releases and "just work"
there :)
>> - We should replace our old passwordmanager and wallet with the new
>> paswdmgr/satchel code, as our old implementations there are basically
>> unowned, known to be ugly code, and the new stuff has no problems
>> compared to ours - from what we know.
>
> I hope it will be "just a backend change", cos I like the password
> manager as is. But go on, I can find it bad afterwards ;-)
The UI (password manager window) should stay as it is, from what I know,
it's mainly backend code that will be heavily affected. The biggest
visible change will be how we handle multiple saved logins for one page,
I guess - we will stop displaying that popup dialog we're using now and
just fill in the last used username, giving a selection dropdown if you
press the "down" key on the username input field.
With the wallet -> satchel chenge, there might be more affected stuff,
but at the moment I can't tell a lot as we've not tried it yet.
> Nice work, Robert. Tell all your fellows what a great job they are doing.
Thanks, but the heavy work for all of that is still in front of us :)
We'll be happy to get any possible help, for sure.
Robert Kaiser
Philip Chee
> - We should replace our old passwordmanager and wallet with the new
> paswdmgr/satchel code, as our old implementations there are basically
> unowned, known to be ugly code, and the new stuff has no problems
> compared to ours - from what we know.
Does anybody know what is the satchel equivalent of "WALLET_PrefillOneElement"?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]It's 21:36:48. Do you know what your bugs are taping?
* TagZilla 0.059
Johannes Kastl
> Johannes Kastl schrieb:
> Those will go away when we ship that code with our releases, as it will
> be compiled with the same compiler as those releases and "just work"
> there :)
I hope so ;-)
>> I hope it will be "just a backend change", cos I like the password
>> manager as is. But go on, I can find it bad afterwards ;-)
>
> The UI (password manager window) should stay as it is, from what I know,
> it's mainly backend code that will be heavily affected. The biggest
> visible change will be how we handle multiple saved logins for one page,
> I guess - we will stop displaying that popup dialog we're using now and
Why? I like that popup.
> just fill in the last used username, giving a selection dropdown if you
> press the "down" key on the username input field.
I would not fill in any value, just open the dropdown menu instead of
the popup. Then it is only one click to add the right username.
> With the wallet -> satchel chenge, there might be more affected stuff,
> but at the moment I can't tell a lot as we've not tried it yet.
We'll see.
>> Nice work, Robert. Tell all your fellows what a great job they are doing.
>
> Thanks, but the heavy work for all of that is still in front of us :)
Im sure you'll do a fine job there.
> We'll be happy to get any possible help, for sure.
Ill try as much as I can.
OJ
--
Elisabeth's safe, just as I promised. And she's going to marry
Norrington, just as she promised, and you are going to die for her,
just as you promised. So we're all men of our word really, except
Elizabeth, who is, in fact, a woman. (Pirates of the Caribbean)
Manuel Reimer
> - People again requested that we should move to a different icon set for
> our default theme...
This sounds like an interesting thing to do.
Maybe we should talk about this via IRC soon. I could help with that as
soon as my vector graphic SeaMonkey logo is done (I'm currently porting
the icon to SVG to be able to cover my whole desktop with it)
Only one thing would be important for me: *Please* not the Firefox
icons. There are very much really nice themes for SeaMonkey. I'm sure
there is one that fits and we could ask the author to allow us to use
the graphics in SeaMonkey.
BTW: I hope you don't really plan to use the Firefox version numbers for
future SeaMonkey releases? Can't the SeaMonkey project use independent
version numbers?
CU
Manuel
Johannes Kastl
> Only one thing would be important for me: *Please* not the Firefox
> icons. There are very much really nice themes for SeaMonkey. I'm sure
In the german newsgroups some guys started to do some Icons and "GET
SEAMONKEY" pcitures:
http://unicorn-net.de/SM/Banner.html
http://unicorn-net.de/SM/Logo.html
http://unicorn-net.de/SM/Banner2.html
http://unicorn-net.de/SM/Banner2.html
> BTW: I hope you don't really plan to use the Firefox version numbers for
> future SeaMonkey releases? Can't the SeaMonkey project use independent
> version numbers?
ACK.
OJ
--
Multiple exclamation marks are a sure sign of diseased mind.
(Terry Pratchett)
Robert Kaiser
> Robert Kaiser wrote:
>> - People again requested that we should move to a different icon set
>> for our default theme...
>
> This sounds like an interesting thing to do.
>
> Maybe we should talk about this via IRC soon. I could help with that as
> soon as my vector graphic SeaMonkey logo is done (I'm currently porting
> the icon to SVG to be able to cover my whole desktop with it)
DO NOT DO THAT!!!
This interferes with our trademark stuff, and we already have an SVG
version for internal use that will probably be made public as soon as
our trademark policy is finished and online.
> Only one thing would be important for me: *Please* not the Firefox
> icons. There are very much really nice themes for SeaMonkey. I'm sure
> there is one that fits and we could ask the author to allow us to use
> the graphics in SeaMonkey.
Chris Thomas has done some work of doing colored SVG versions of the
Modern icons, which sound like a good idea for the default theme (which
will be a modified Classic based on a toolkit theme for global stuff).
I think we all would appreciate any help we can get in that effort, esp.
from you as our themes owner :)
> BTW: I hope you don't really plan to use the Firefox version numbers for
> future SeaMonkey releases? Can't the SeaMonkey project use independent
> version numbers?
Where do we use Firefox version numbers???
Robert Kaiser
Robert Kaiser
> On 03/01/2006 09:36 AM Manuel Reimer wrote:
>
>> Only one thing would be important for me: *Please* not the Firefox
>> icons. There are very much really nice themes for SeaMonkey. I'm sure
>
> In the german newsgroups some guys started to do some Icons and "GET
> SEAMONKEY" pcitures:
Those are component icons, but we're talking of theme icons here, which
are a different beast actually.
We need both of them though, as well as the "Get SeaMonkey" web page
buttons. In fact, I like those a lot, but his component icon proposals
are not yet the look I'd prefer to have...
Robert Kaiser
Johannes Kastl
> Those are component icons, but we're talking of theme icons here, which
> are a different beast actually.
Sorry, I must have mixed that up.
> We need both of them though, as well as the "Get SeaMonkey" web page
> buttons. In fact, I like those a lot, but his component icon proposals
> are not yet the look I'd prefer to have...
I prefer the unicorn-net ones.
OJ
--
You can do magic! Surely you can sourt out - well - anything!?
Scrimgeour [...] exchanged an incredulous look with Fudge, who really
did manage a smile this time as he said kindly, `The trouble is, the
other side can do magic too, Prime Minister.? (Harry Potter 6)
Chris Thomas
> Robert Kaiser wrote:
>> - People again requested that we should move to a different icon set
>> for our default theme...
>
> This sounds like an interesting thing to do.
>
> Maybe we should talk about this via IRC soon. I could help with that as
> soon as my vector graphic SeaMonkey logo is done (I'm currently porting
> the icon to SVG to be able to cover my whole desktop with it)
Don't bother. We already have one - we'll release it when we have the
trademark policy ("real soon now" ;)).
Chris
Manuel Reimer
>> (I'm currently
>> porting the icon to SVG to be able to cover my whole desktop with it)
>
> DO NOT DO THAT!!!
I already did it ;-)
But I won't publish it before the trademark policy is finished if this
would be a problem for you.
> Chris Thomas has done some work of doing colored SVG versions of the
> Modern icons, which sound like a good idea for the default theme (which
> will be a modified Classic based on a toolkit theme for global stuff).
This sounds great, but toolkit themes won't work from scratch in
SeaMonkey as we don't use the "new toolkit" so far.
> Where do we use Firefox version numbers???
http://kairo.mozdev.org/slides/fosdem2006/slide_06.html
<quote>
SeaMonkey trunk ("1.5")
</quote>
CU
Manuel
Robert Kaiser
> Robert Kaiser schrieb:
>>> (I'm currently porting the icon to SVG to be able to cover my whole
>>> desktop with it)
>>
>> DO NOT DO THAT!!!
>
> I already did it ;-)
>
> But I won't publish it before the trademark policy is finished if this
> would be a problem for you.
It is. We may not even allow it to be published at all, or we might
adopt it and remove all your rights on it, who knows. The logo is owned
by Mozilla Foundation, and we can't hand out any ownership of our
artwork to anyone else if we don't have to...
Sorry if that sounds rude, but trademark laws can be cruel as well...
>> Chris Thomas has done some work of doing colored SVG versions of the
>> Modern icons, which sound like a good idea for the default theme
>> (which will be a modified Classic based on a toolkit theme for global
>> stuff).
>
> This sounds great, but toolkit themes won't work from scratch in
> SeaMonkey as we don't use the "new toolkit" so far.
We're heavily working on that at the moment, though, as my posts might
have shown. Actually, I'm hearing of progress in that direction almost
daily now...
>> Where do we use Firefox version numbers???
>
> http://kairo.mozdev.org/slides/fosdem2006/slide_06.html
>
> <quote>
> SeaMonkey trunk ("1.5")
> </quote>
Firefox will be 3.0 when we release what's currently under the title of
"1.5" - and that number isn't even final. And I think we should be
allowed to use some version numbers that Firefox has already used for it
releases somewhere, else even 1.0, 1.0.1, etc. would be a problem.
And keep in mind that we won't jump from 1.0 to 1.5 as FF did, we'll
have at least 1.1 in between....
The reasons for having the trunk targeted at "1.5" are multiple: First,
we decided to use 1.1 for the Gecko 1.8.1-based release and trunk needs
to be targeted at something higher than that. Second, we don't know if
Gecko 1.9 will be pushed out further and we might need to insert even a
1.2 from some Gecko 1.8.x base (currently not planned, but you never
know) - and it should then still be clear that trunk is further
developed than anything off 1.8 branch...
And then, it will be a quite big step from any 1.8-based build to
current trunk, with all the toolkit transition stuff happening, so just
picking the next 1.x number might be misleading. We didn't dare to call
current trunk 2.0a though, as SeaMonkey 2 would imply that rather big
changes have already happened, and we currently haven't even started to
do those though. That left us with something reasonably in between those
possibilties, and "1.5" sounds like the logical choice - independent of
what Mozilla Corporation has used for their stuff or not.
Note that such x.5 steps are not unprecedented, e.g. Netscape jumped
directly to 4.5 from 4.0.x versions.
Our version politics are tied to how our application evolves, and we
don't care if Firefox has had a release with that number or not. We
don't feel we have to avoid version numbers they used, and we also don't
feel we have to follow their rapidly climbing numbers.
Minor changes in SeaMonkey rectify increasing the minor version number,
really major changes need us to step up to the next major number, and
significant steps in between call for something halfway in between. If
current trunk will be such a halfway step or a major one will be
determined by the progress we make. For now, the working title is the
halfway step, i.e. "1.5", as further increasing is much easier then
stepping back.
Robert Kaiser
Rich Gray
> Hi people,
>
> As some of you might know, a bunch of SeaMonkey people (CTho, biesi,
> Mnyromyr and me among others) met in Brussels last weekend in the
> Mozilla developer room at this year's FOSDEM conference.
>
> I presented the SeaMonkey project to the crowd, my slides are available
> at http://kairo.mozdev.org/slides/fosdem2006/ - for those who want to
> see the "special intro" I couldn't show at FOSDEM due to laptop
> problems, see http://kairo.mozdev.org/slides/fosdem2006/intro.html (and
> click on the page once you're ready).
>
> The pictures I made this weekend are up at
> http://dev.seamonkey.at/fosdem2006
Great work!
>
> - Paul Kim (Firefox marketing, mozilla.com website owner) strongly
> supports mozilla.org being more foxused on pojects instead of
> mozilla.com products, even wondered why SeaMonkey isn't on the
> mozilla.org front page. Currently nobody feels responsible for
> mozilla.org website content though, and we'll need someone who does.
> Paul would prefer "someone from the community" to take over that
> responsibility.
>
> - Gerv (one of the 3 direct MoFo employees) stated that (especially
> after the split from the Corporation) Mozilla Foundation feels its
> responsibility for the exisiting projects at mozilla.org, which include
> Camino, SeaMonkey and Bugzilla among others. They want to support those
> projects and surely will not drop them as long as there's community
> interest behind them. He applauded Camino and us for showing up in the
> public with our 1.0 releases.
This is all very encouraging, given some of the negative hysteria
I saw in some of the Mozilla newsgroups saying in effect that Mofo
would never let SeaMonkey onto the Mozilla.org pages in any sort of
competition with FF & TB. Never attribute to evilness what can be
explained by lack of volunteer time! :-) This is what I want to
see, one big happy Mozilla family, with ideas and code flowing
back and forth between the projects.
I think working SeaMonkey into as many of the Mozilla web pages
as is appropriate and possible should be a very high priority.
No point in going through all of this if nobody knows we're here!
Consider this exchange I just observed cross posted to three Mac
oriented groups when a user asked about Browsers for Mac OS
(sadly, primarily OS 9):
[quote]
>> Personally, if it is at all possible for you, I would suggest that
>> you use a Mac which supports OS X 10 or later, since you would
>> have many more options for browser support under OS X. (such as
>> Firefox 1.5, Safari, Camino, and several other Mac browsers).
>> Firefox 1.5 is the best choice for cross-platform support, if you
>> want your browser on your Mac to be the same as the browser on
>> your Wintel machine.
>>
> Also consider SeaMonkey, successor to the Mozilla Suite, successor
> to Netscape Navigator. It is basically Firefox & Thunderbird and
> more. A cross-platform browser, e-mail/news & more client. In
> addition to Mac & Wintel, the Mozilla programs are also available
> for Linux.
>
> http://www.mozilla.org/projects/seamonkey/
>
Thank you for posting that. As an avid fan of the Mozilla suite I
thought hope was lost after they announced it would die, I had not
heard of Sea Monkey.
http://www.mozilla.org/products/ does not mention it!
GW
[/quote]
Getting the word out seems almost as important a short term
goal as technical efforts. I've decided that one thing I
can do is write an article about SeaMonkey for the local
computer club newsletter. If I'm lucky the article will
be propagated to other user groups that are members of
APCUG (the Association of Personal Computer User Groups.)
An article is now on my list of Things To Do. (Please
do not inquire into the queue depth and priorities of
said list...)
Rich
--
SeaMonkey - Surfing the net has never been so suite!
Neil
> [quote]
> I had not heard of Sea Monkey.
> http://www.mozilla.org/products/ does not mention it!
> GW
> [/quote]
That would be because SeaMonkey is a project, not a product.
--
Warning: May contain traces of nuts.
Robert Kaiser
> Getting the word out seems almost as important a short term
> goal as technical efforts. I've decided that one thing I
> can do is write an article about SeaMonkey for the local
> computer club newsletter. If I'm lucky the article will
> be propagated to other user groups that are members of
> APCUG (the Association of Personal Computer User Groups.)
> An article is now on my list of Things To Do. (Please
> do not inquire into the queue depth and priorities of
> said list...)
Thanks for doing that!
Robert Kaiser
Adrian (Adrianer) Kalla
>> Johannes Kastl schrieb:> On 02/28/2006 03:33 AM Robert Kaiser wrote:
>
>>> I hope it will be "just a backend change", cos I like the password
>>> manager as is. But go on, I can find it bad afterwards ;-)
>> The UI (password manager window) should stay as it is, from what I know,
>> it's mainly backend code that will be heavily affected. The biggest
>> visible change will be how we handle multiple saved logins for one page,
>> I guess - we will stop displaying that popup dialog we're using now and
>
> Why? I like that popup.
I like the popup too, and some people uses SeaMonkey because of this (
for ex. my brother and father :) ).
If not popup, so could the drop-down menu be opened by default? So it
would be one-click too :)
--
Adrian (Adrianer) Kalla
Blog: http://www.adrianer.org
Telefon: ++4917620129456
JabberID: adrian...@jabber.wp.pl
Wengo: adrianer
Skype: adrianer8409
ICQ: 95297682
GG: 149970
Tlen: adrianer
Giacomo Magnini
> - Gerv (one of the 3 direct MoFo employees) stated that (especially
> after the split from the Corporation) Mozilla Foundation feels its
> responsibility for the exisiting projects at mozilla.org, which include
> Camino, SeaMonkey and Bugzilla among others. They want to support those
> projects and surely will not drop them as long as there's community
> interest behind them. He applauded Camino and us for showing up in the
> public with our 1.0 releases.
> - Gerv, who's also resposible for MoFo's licensing stuff, and the
> SeaMonkey Council people agreed on "heavily basing" our trademark policy
> on the ubuntu trademark policy, which is up at
> http://www.ubuntu.com/ubuntu/TrademarkPolicy - we hope to get our new
> policy up soon so that people know under which terms they can use e.g.
> our logo.
Sorry for being so late to reply here.
I do appreciate the Foundation being more happy about its projects than
before, but what about showing some real commitment?
Release build tinderboxen are still missing, brad and its stats are long
time gone, another tinderbox is not building correctly, we don't have
TalkBack enabled builds (while mozilla.org/com has access to the code,
since it is being ported to Universal Binary) and we are supposed to
embrace a strong brand policy, with all of its problems.
Fulfilling just two old promises would be a good sign: release build
machines and mozilla brand enforcing for other projects (aside from SM).
I'll believe in support when I'll see it.
Ciao, Giacomo.
Johannes Kastl
> If not popup, so could the drop-down menu be opened by default? So it
> would be one-click too :)
ACK.
OJ
--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. (Benjamin Franklin, 1759)
Christian Biesinger
> Release build tinderboxen are still missing, brad and its stats are long
> time gone,
You know that brad never was a mozilla.org/.com machine, right?
Rich Gray
> Rich Gray wrote:
>
>> [quote]
>> I had not heard of Sea Monkey.
>> http://www.mozilla.org/products/ does not mention it!
>> GW
>> [/quote]
>
> That would be because SeaMonkey is a project, not a product.
>
Sure, but Robert reported:
>
> - Paul Kim (Firefox marketing, mozilla.com website owner) strongly
> supports mozilla.org being more focused on projects instead of
> mozilla.com products, even wondered why SeaMonkey isn't on the
> mozilla.org front page. Currently nobody feels responsible for
> mozilla.org website content though, and we'll need someone who does.
> Paul would prefer "someone from the community" to take over that
> responsibility.
>
> - Gerv (one of the 3 direct MoFo employees) stated that (especially
> after the split from the Corporation) Mozilla Foundation feels its
> responsibility for the existing projects at mozilla.org, which include
> Camino, SeaMonkey and Bugzilla among others. They want to support those
> projects and surely will not drop them as long as there's community
> interest behind them. He applauded Camino and us for showing up in the
> public with our 1.0 releases.
>
Camino and Bugzilla are listed as projects on www.mozilla.org/products
and yet listed on the Mozilla.org homepage. Are those projects more
tightly bound to Mozilla.org than SeaMonkey? Guess I don't understand
the relationships in play. Besides, on http://www.mozilla.org, the
column heading is "Other Mozilla Software" which does not differentiate
between products and projects.
Seems to me that there should be a "SeaMonkey Suite" link on
www.mozilla.org. There should be an entry on
http://www.mozilla.org/products/. Maybe it is time for the
entry for Mozilla Suite to say something like "Note: The Mozilla
Suite is now in maintenance mode, with no new development being
undertaken. We recommend you use Firefox and Thunderbird for your
browser and e-mail/news clients. If you wish to continue to use
a suite, checkout SeaMonkey, a project continuing the development
of the Mozilla Suite codebase." (Ok, that got a little long, but
something like that could certainly go on
http://www.mozilla.org/products/mozilla1.x/ .) I do note an
infusion of SeaMonkey on the MozillaZine.org page. In digging
around trying to figure out a good OS X shortcut technique, I
found pages like http://kb.mozillazine.org/Profile_Manager and
http://www.mozilla.org/docs/command-line-args.html. Those pages
have [edit] buttons, so would someone get bothered if references
to Mozilla Suite became Mozilla Suite/SeaMonkey, etc.?? Bet even
I could blunder my way through making changes like that. :)
Guess I'm just really trying to figure out MoFo's sensibilities
on SeaMonkey references in and around the various Mozilla pages.
Robert's post seemed very promising. Neil's did not. I'm
confused.
Neil
> Robert's post seemed very promising. Neil's did not. I'm confused.
I'm sorry. I should have left it for someone else with more information
to comment.
Giacomo Magnini
> You know that brad never was a mozilla.org/.com machine, right?
Yes, I know. But it was very useful anyway. What about replicating its
function on a m.org/com machine? Way too difficult?
Ciao, Giacomo.
PS: Forgive me if this arrives twice.
Robert Kaiser
> Dnia 2/28/2006 12:47 PM, Johannes Kastl wrote:
>
>>> Johannes Kastl schrieb:> On 02/28/2006 03:33 AM Robert Kaiser wrote:
>>>> I hope it will be "just a backend change", cos I like the password
>>>> manager as is. But go on, I can find it bad afterwards ;-)
>>> The UI (password manager window) should stay as it is, from what I know,
>>> it's mainly backend code that will be heavily affected. The biggest
>>> visible change will be how we handle multiple saved logins for one page,
>>> I guess - we will stop displaying that popup dialog we're using now and
>> Why? I like that popup.
I hate that popup, I often enough want to look at pages where it shows
up and I have to click it away just to see the page content (and I may
not even want to login but only see the front page or whatever).
Or I log out of the page and it pops up uselessly because I don't want
to relogin.
> I like the popup too, and some people uses SeaMonkey because of this (
> for ex. my brother and father :) ).
>
> If not popup, so could the drop-down menu be opened by default? So it
> would be one-click too :)
It's already two-click: select the correct entry, then click OK.
If the last used entry is filled in by default, chances are high that
you save both clicks. If the filled-in entry is the wrong one, one click
is opening the dropdown, one is selecting the entry, and then it's
filled in - so two clicks, like currently.
Additionally, the currently needed clicks are likely very far away from
the submit button of the login form, so you have to move your mouse
pointer quite far. The username entry box (and the proposed dropdown) is
usually quite near to that button, so that you have to move the pointer
a much shorter distance, which is better from the usability side as well.
And then, why do you use a product with a popup blocker if you like
popups coming up? Most popups are just bad and distort the user
experience - at least that's what I learned from UI design articles and
from talks with real users (and from my own experience, btw).
Robert Kaiser
Robert Kaiser
> Neil wrote:
>> Rich Gray wrote:
>>
>>> [quote]
>>> I had not heard of Sea Monkey.
>>> http://www.mozilla.org/products/ does not mention it!
>>> GW
>>> [/quote]
>>
>> That would be because SeaMonkey is a project, not a product.
correct.
> Camino and Bugzilla are listed as projects on www.mozilla.org/products
> and yet listed on the Mozilla.org homepage. Are those projects more
> tightly bound to Mozilla.org than SeaMonkey? Guess I don't understand
> the relationships in play. Besides, on http://www.mozilla.org, the
> column heading is "Other Mozilla Software" which does not differentiate
> between products and projects.
Well, they got on the "products" page for historical reasons, as the
difference between what's nowadays MoCo products vs. mozilla.org
projects only came up when Firefox made more money roll in and MoFo
decided to use it for paying people to work on it even more. At this
time, Camino and Bugzilla were already there, and they just weren't
removed from there.
Nowadays, with those products that people are payed for moved over to
MoCo and mozilla.com, almost everyone agrees that mozilla.org needs to
be restructured in a way that it focuses on its projects (while pointing
those that look for MoCo products over to mozilla.com) - which also
means featuring SeaMonkey (among others) more then it previously did.
The "products" section might just go away, as those are not the main
concern of mozilla.org any more. The main page should feature the more
vibrant projects (I guess those basically would be Bugzilla, Camino and
SeaMonkey), and more prominently point people to the "projects" pages.
That's all more or less common sense, it seems. The bigger problem is,
like I posted in the original message along with the notes about my chat
with Paul Kim, who will do that? Who will be in charge of mozilla.org?
Someone from the community, who can be trusted by MoFo to not mess up
stuff, has to step forward and take over this resposibility.
Then what you (and me) are talking about would not just be hot air, but
would be near to reality.
Regardings MozillaZine Knowledge Base, it's just a matter of individual
contributors to update the wiki where they see room for improvement, so
feel free to do it where it's the right thing to do.
Robert Kaiser
Robert Kaiser
> Release build tinderboxen are still missing, brad and its stats are long
> time gone, another tinderbox is not building correctly, we don't have
> TalkBack enabled builds (while mozilla.org/com has access to the code,
> since it is being ported to Universal Binary) and we are supposed to
> embrace a strong brand policy, with all of its problems.
1) You realize that system/tinderbox admins are at MoCo (not MoFo), right?
2) We all don't know what happened to brad. Sure it was helpful, but it
was private. Sure a replacement would be nice, but it's the wrong thing
to demand other people to use their money to set up things that are just
"nice-to-have" but not necessary. Do you have a free machine on a
fitting connection by chance where you can set up a replacement? If so,
everyone would be happy about it
3) It's true that Chase said that he planned to set up branch
tinderboxen for us. Note that Chase was working like a dog to get
everything done that had been thrown at him, even donated his weekend
free time to help us kepping tinderboxen green for rebranding, never
came near to finishing all things he was supposed to so, and finally
gave up and quit his job at Mozilla. His successors have lots of stuff
to do as well and they're trying to do their best, really. SeaMonkey
branch tinderboxen aren't a pressing issue any more though as we now
have some on our own, and it should be a matter of days to weeks to have
them for all tier-1 platforms.
4) Trunk tinderboxen are still with MoFo/MoCo, and are currently being
upgraded to be able to deal with the recent changes in trunk code (build
requirements mainly). The Mac machines (barcelona and monkey) were taken
offline and reinstalled with a newer OS, even with a temporary
replacement - once they had installed the new OS, they realized it would
even be better to use the new server that was due to be in within days,
to replace them as virtual machines (with better perf and easier to
maintain), so they put aside the old boxes. And then the message came in
that delivery of that server is delayed it wil should be in... er...
today, actually. So they're on it, and we should have that up quite soon
again.
5) Talkback code is proprietary, and while some MoCo employees might
have some access to it, they surely have signed an NDA or something not
to make any code public. They also have a contract to use that non-cheap
product for free and build it into binaries. But that only can be done
on boxes that are under their control. Using that as a reason why they
have to do all work for all other projects is just unfair. Actually,
both them and us would be happy is we could get rid of those restraints
and have a OSS tool to replace Talkback. And actually, people from the
SeaMonkey project are working on developing such a tool, which will
hopefully go public soon and it targeted to being used across multiple
applications, from XULRunner to SeaMonkey.
6) The "strong brand policy" is something noone forces on us, but the
SeaMonkey Council does want it. The reason is quite simple: We want to
have a trademarked brand, and it's only possible to retain it by
enforcing it in some way. You might recognize that ubuntu is a quit open
project, trying to make it easily possible to reuse their stuff. This is
one reason why (on our request) Gerv proposed to base our trademark
policy on theirs, and we agree with that.
Robert Kaiser
Rich Gray
mess with wikis. :)
Giacomo Magnini
> 1) You realize that system/tinderbox admins are at MoCo (not MoFo), right?
Fine. It's good to know MoFo has no influence on MoCo. This will ease
some OSS extremists I've been dealing with lately about this new MoCo
entity (especially the Corporation part is hard to understand).
> 2) We all don't know what happened to brad...
You know my connection is ridiculous; otherwise a free machine was here
(Athlon XP 1,3Ghz, 512MB, 30GB HD)... Speaking of brad, well, it was the
only easy way to see leak stats for SM builds: especially since *lots*
of patches coming from one source have been and are still going into the
tree. The same source has been very good at increasing memory leaks in
the past which were recovered only a few months later. Don't want to go
personal here, and yes, I'm biased against the guy from other discussions.
> 3) It's true that Chase said that he planned to set up branch
> tinderboxen for us....
Sorry to learn that Chase resigned, and didn't know he was the sole
responsible for so many tinderboxen. Still, MoFo has assured something
it didn't provide, and that's a fact.
> 4) Trunk tinderboxen are still with MoFo/MoCo...
All great news, surely.
> 5) Talkback code is proprietary...
The problem I raised is still unanswered: MoFo/MoCo are the only ones
who can use TB -> build boxes from them are not available -> we don't
have release builds with TB enabled. I'm not arguing against TB, nor
against the pains you, the Council and other volunteers are going
through to ease the situation on the users: I'm just raising a flag for
a problem. I can understand you are worried about hurting feelings, but
I don't think we should just hide the facts.
It's even worse to learn (even if I already knew it) that the only
solution to such a problem is coming from SM developers, a very rare and
precious species. And please remember that such a problem was raised
long time ago, before even MoCo existed, when bugbuddy from gnome was
suggested and then refused. Instead, TB was still chosen, with all of
the problems relative to it, and which worsened since TB is not being
developed anymore.
One small note here: having no release build with TB doesn't help even
MoFo/MoCo with debugging core crash bugs: we lose all.
> 6) The "strong brand policy"...
I have no objections to that, maybe I'm just worried that SM Council
would be too much busy with the brand instead of the application.
Yet, the concern was about Mozilla brand enforcement upon SM, not the SM
brand. But from your reply I can understand the issue is troublesome to
talk about: fair enough.
Don't want to troll, just to give some visibility to critical nodes
(IMHO, obviously).
Ciao, Giacomo.
Peter Weilbacher
> 6) The "strong brand policy" is something noone forces on us, but the
> SeaMonkey Council does want it. The reason is quite simple: We want to
> have a trademarked brand, and it's only possible to retain it by
> enforcing it in some way. You might recognize that ubuntu is a quit open
> project, trying to make it easily possible to reuse their stuff. This is
> one reason why (on our request) Gerv proposed to base our trademark
> policy on theirs, and we agree with that.
Does that mean that soon I also have to rename my unofficial SeaMonkey
builds for OS/2 to PmW-Sm or something like that as I already do for
Firefox and Thunderbird? And replace artwork, too?
P.
Robert Kaiser
> Robert Kaiser wrote:
>
>> 6) The "strong brand policy" [...]
>
> Does that mean that soon I also have to rename my unofficial SeaMonkey
> builds for OS/2 to PmW-Sm or something like that as I already do for
> Firefox and Thunderbird? And replace artwork, too?
No, our brand policy will not be as strong as the one of Mozilla
products - as I said earlier, it will be heavily based on the ubuntu
policy...
Robert Kaiser
Boris Zbarsky
> Robert Kaiser wrote:
>
>> 1) You realize that system/tinderbox admins are at MoCo (not MoFo),
>> right?
>
> Fine. It's good to know MoFo has no influence on MoCo.
Whoa. Where did this come from?
In any case, Robert's main point about tinderboxen, as I understood it, was
simple: There are very few people at MoCo dealing with them, and they are very
overworked. If there is need for a tinderbox with leak stats to replace a
_contributed_ tinderbox, the simplest way is to find someone to contribute a
replacement tinderbox. The next simplest way is to file a bug in the relevant
Bugzilla product and component and wait until there is time to deal with it.
Now. Has a bug been filed? If not, why are people complaining here instead of
filing said bug?
-Boris
Robert Kaiser
> Robert Kaiser wrote:
>> 5) Talkback code is proprietary...
>
> It's even worse to learn (even if I already knew it) that the only
> solution to such a problem is coming from SM developers, a very rare and
> precious species.
Actually, it's good news that this has been _started_ in our group, it
tells we are a vibrant group. Even more, if we would have got branch
tinderboxen with talkback, development of this new tool wouldn't have
started (that story is similar to the git story, for example).
And the really good news is that now that they know something is being
developed, other developers within the Mozilla community want to
participate in that project and completely replace Talkback in
mozilla.org with that new tool. There's talk behind the scenes to move
in that direction.
> Instead, TB was still chosen, with all of the problems relative to it, and which worsened since TB is not being developed anymore.
Actuall, that's wrong. Firstly, it wasn't "still chosen", they just
continued to use it because it was already there. Secondly, it is still
being developed - the company "SupportSoft" is still selling it to new
customers under the new name of "SupportTrigger".
(BTW, gnome's bugbuddy is inadequate for the cross-platform job we want
and that's the reason why it's never been seriously discussed.)
> One small note here: having no release build with TB doesn't help even
> MoFo/MoCo with debugging core crash bugs: we lose all.
True, but release builds with crahs reporting aren't as important as
trunk builds with crahs reporting - as most top crashers from releases
are often even fixed on trunk, or at least present on trunk as well.
Additionally, there are release builds with Talkback - just not
SeaMonkey ones.
Robert Kaiser
Christian Reischl
> Manuel Reimer schrieb:
>> Robert Kaiser wrote:
>>> - People again requested that we should move to a different icon set
>>> for our default theme...
>>
>> This sounds like an interesting thing to do.
>>
>> Maybe we should talk about this via IRC soon. I could help with that
>> as soon as my vector graphic SeaMonkey logo is done (I'm currently
>> porting the icon to SVG to be able to cover my whole desktop with it)
>
> DO NOT DO THAT!!!
>
> This interferes with our trademark stuff, and we already have an SVG
> version for internal use that will probably be made public as soon as
> our trademark policy is finished and online.
>
>> Only one thing would be important for me: *Please* not the Firefox
>> icons. There are very much really nice themes for SeaMonkey. I'm sure
>> there is one that fits and we could ask the author to allow us to use
>> the graphics in SeaMonkey.
>
> Chris Thomas has done some work of doing colored SVG versions of the
> Modern icons, which sound like a good idea for the default theme (which
> will be a modified Classic based on a toolkit theme for global stuff).
>
>
there are already 2 themes with very good icon sets. the really modern
theme has colored modern icons. the orb colors classic theme uses
modified orbit icons. those two themes have a very native look on
various operating systems. this is an important point. both themes are
based on the classic theme. they can be heavily tweaked using the
userchrome.css file. there is a lot of discussion in the mozillazine forums.
http://forums.mozillazine.org/viewtopic.php?t=362605
http://thumper.kicks-ass.org/wordpress/really-modern
http://forums.mozillazine.org/viewtopic.php?t=363074
Chris Thomas
All the icons in Orb are too similar. Really Modern is nice, but as far
as I know, Thumper colorized the bitmaps from Modern and as a result
some of the edges don't look perfect. Otherwise, I do like Really
Modern. However, I think the replacement for classic should look more
native than Really Modern.
Giacomo Magnini
>> Fine. It's good to know MoFo has no influence on MoCo.
>
> Whoa. Where did this come from?
From Robert message, and only related to tboxen administration.
> Now. Has a bug been filed? If not, why are people complaining here
> instead of filing said bug?
As I said, I'm not complaining, I'm just piinting out what are the
criticalities I see IMHO. Since it seems I'm the only one seeing this
need, there's no point in pressing MoFo/MoCo/whatever to solve my issue.
I'm always curious at memory leaks, whilst somebody else is worried only
every few years (last time was for 1.4 IIRC, now for FF2).
Ciao, Giacomo.
Giacomo Magnini
> Actually, it's good news that this has been _started_ in our group, it
> tells we are a vibrant group. Even more, if we would have got branch
> tinderboxen with talkback, development of this new tool wouldn't have
> started (that story is similar to the git story, for example).
Different POVs I guess. For me, it was much better that SM devs were
using their spare time on fixing SM bugs or improving it instead of
fixing a *structural* hole in the Mozilla dev framework.
> And the really good news is that now that they know something is being
> developed, other developers within the Mozilla community want to
> participate in that project and completely replace Talkback in
> mozilla.org with that new tool. There's talk behind the scenes to move
> in that direction.
This will ensure that the end result will be much better and much more
useful: which is something good for all, and nothing I had problems with...
> Actuall, that's wrong. Firstly, it wasn't "still chosen", they just
> continued to use it because it was already there. Secondly, it is still
> being developed - the company "SupportSoft" is still selling it to new
> customers under the new name of "SupportTrigger".
Oh, so well developed that the Universal Binary compatability is being
developed by MoCo itself? I can still sell a product if there's someone
willing to buy it (MoCo perhaps?), and I can support it by helping with
its usage, but that doesn't mean it's still being actively supported (no
new versions).
> (BTW, gnome's bugbuddy is inadequate for the cross-platform job we want
> and that's the reason why it's never been seriously discussed.)
And that was just an example of how long this has been a *known* problem
that nobody wanted to address, until SM devs were forced to. I didn't
say that bb was *the* solution: please don't bend my words.
> True, but release builds with crahs reporting aren't as important as
> trunk builds with crahs reporting - as most top crashers from releases
> are often even fixed on trunk, or at least present on trunk as well.
How many people are using trunk builds, besides you, me and a few
others? How many people waited for the *final* release to be out before
switching their MAS installation to SM? Do you remember the discussions
in the support newsgroup, right? There is no chance that our nightly
testing will be ever as heavy nor as extended as the day-by-day use of a
few thousands of end users: hopefully we can agree on this.
> Additionally, there are release builds with Talkback - just not
> SeaMonkey ones.
And what about SM only crashes/problems (even if they are very few)?
The only hope is that someone with a nightly build can reproduce the
problem and have TB data for it: or you want to ask every enduser to
install a nightly to get the crash data? Hmm, not very practical...
Still, the two big questions I raised are without any answers
(where are the promised release build boxes and why the other projects
didn't go through all of the hussle of Mozilla branding enforcements
even if they had to [eg.: Calendar and Sunbird]), and so I'm still cold
to some statements coming from MoFo: that's all, nothing more, nothing less.
Ciao, Giacomo.
Robert Kaiser
> (where are the promised release build boxes
Nowhere, and they'll not arrive. There was never a real promise. Chase
said he'll try to get them set up, but as we know, he's gone. And
actually, we (the SeaMonkey Council) currently don't care a lot about
that any more, because we have our branch tinderboxen, and we have more
important stuff to fix.
> why the other projects
> didn't go through all of the hussle of Mozilla branding enforcements
> even if they had to [eg.: Calendar and Sunbird])
You'll have to discuss that with Gerv. I don't want to get into that
discussion, as I don't care much. I care about the future, not the past
- and that discussion is the past for me. We have a good new name and
logo, so I don't care any more why we needed to adopt it.
Robert Kaiser
Robert Kaiser
> Boris Zbarsky wrote:
>>> Fine. It's good to know MoFo has no influence on MoCo.
>>
>> Whoa. Where did this come from?
>
> From Robert message, and only related to tboxen administration.
And you added some interpretation to it, which is not fully correct. I
just stated that those are two different entities. In fact, MoCo is a
subsidiary of MoFo, but MoCo and MoFo decide lots of stuff differently.
I don't want to get into the dicsussion of who does what how there,
because if you don't agree with what they do, you need to discuss that
with them, and the SeaMonkey dev group is the wrong place to do that.
For us, the important point is that we need to deal with the situation
as it is and try to make it work out as good as possible for us. And
that's what we're trying to do.
Complaining that we feel to be too little cared about or calling other
people names isn't getting us anywhere but to a state where everyone's
just frustrated. We need to work on things we can achieve for ourselves
instead of complaining about what someone else could achieve for us.
Robert Kaiser