Re: [Wikitech-l] Skin system rewrite

[Siebrand Mazeland]

Already has commit access and is committing[1]

[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/ashley

-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of K. Peachey
Sent: Thursday, February 11, 2010 6:36 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Skin system rewrite

jack, I would suggest if you don't already have SVN access then to
request it on wiki(1), Then if/when you get it create a (or ask
someone to do it for you) branch and start working on and then more
people can help and work on it at once.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[K. Peachey]

On Tue, Feb 9, 2010 at 6:58 AM, Jack Phoenix  wrote:
> Hi all,
...
> Jack Phoenix
jack, I would suggest if you don't already have SVN access then to
request it on wiki(1), Then if/when you get it create a (or ask
someone to do it for you) branch and start working on and then more
people can help and work on it at once.

(1). Commit access requests - MediaWiki --
http://www.mediawiki.org/wiki/Commit_access_requests

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler

[Gregory Maxwell]

On Wed, Feb 10, 2010 at 9:36 PM, Tim Starling  wrote:
> Gregory Maxwell wrote:
>> Looks like this change removed both the Oggthumb support as well as
>> the code that handles the cases where ffmpeg fails.
>
> The usual problem with deploying new solutions for equivalent tasks is
> that you substitute known issues with unknown ones.
>
> I've looked at oggThumb now, I downloaded the latest tarball. Here are
> some of the ways in which it sucks:

So a couple months back mdale suggested using oggThumb, with the old
installed ffmpeg was making spaghetti of some files (old ffmpeg not
completely implementing the Theora spec) and the new one that
(whomever) tried installing mage spaghetti in a different way (failing
to thumb because ffmpeg didn't take your seeking patch eons ago).

I'd never heard of it, went to look, and recoiled in horror. Then I
sent a patch.

> * Unlike the current version of FFmpeg, it does not implement
> bisection seeking. It scans the entire input file to find the relevant
> frames. For an 85MB test file, it was 30 times slower than FFmpeg.

Of the issues I raised, seeking was the only I didn't fix.
Unfortunately oggvideotools reimplements libogg in C++ so it could use
C++ memory management, my patience ran out before I got around to
implementing it.

If you search the archive you can see how strongly opposed I am to
tools that linear scan unnecessarily. But 30x slower on a file that
small sounds a bit odd.

> * The output filename cannot be specified on the command line, it is
> generated from the input filename. OggHandler uses a -n option for
> destination path which just gives an error for me. I don't know if
> it's a patch or an alpha version feature, but it's not documented
> either way.

It's in SVN.

After the author of the package applied my patches (on the same day I
sent them) Mdale asked if he should delay Wikimedia deployment until
the fixes I sent in went in, the author offered to simply do a new
release. No one took him up on the author.


> * It unconditionally writes a progress message to stdout on every
> frame in the input file.
>
> * It unconditionally pollutes stderr with verbose stream metadata
> information.
>
> * It ignores error return values from libtheora functions like
> th_decode_packetin(), meaning that essentially the *only* thing on
> stdout/stderr is useless noise.

I'm also not especially keen on its rather non-unixy style. Then
again, I think C++ is pretty much crap too, so you can see what my
opinion is worth.  What I can say is that speaking from personal
experience the author of this package is friendly, pleasant to work
with, and responsive.  Though 'submit patches' takes me out of the
'one line fix' I advertised,  — sorry, I'd assumed that Mdale had
already worked out the operational angles and my only concerns were
correct output and not allowing it to be an enormous DOS vector.


Cheers.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] confirm dfe03c58a0a....

[Tim Starling]

Marco Schuster wrote:
> Hi all,
> 
> I just got this email from bugzilla. Apparently Google Apps has screwed up
> something again so the message itself doesnt annoy me, but why are the
> users' passwords still sent in CLEARTEXT in these days??
> Can someone (tm) of the mailman admins or tech guys please fix this up?

https://bugs.launchpad.net/mailman/+filebug

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler

[Tim Starling]

Gregory Maxwell wrote:
> Looks like this change removed both the Oggthumb support as well as
> the code that handles the cases where ffmpeg fails.

The usual problem with deploying new solutions for equivalent tasks is
that you substitute known issues with unknown ones.

I've looked at oggThumb now, I downloaded the latest tarball. Here are
some of the ways in which it sucks:

* The output filename cannot be specified on the command line, it is
generated from the input filename. OggHandler uses a -n option for
destination path which just gives an error for me. I don't know if
it's a patch or an alpha version feature, but it's not documented
either way.

* Unlike the current version of FFmpeg, it does not implement
bisection seeking. It scans the entire input file to find the relevant
frames. For an 85MB test file, it was 30 times slower than FFmpeg.

* It unconditionally writes a progress message to stdout on every
frame in the input file.

* It unconditionally pollutes stderr with verbose stream metadata
information.

* It ignores error return values from libtheora functions like
th_decode_packetin(), meaning that essentially the *only* thing on
stdout/stderr is useless noise.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[Aryeh Gregor]

On Wed, Feb 10, 2010 at 8:03 PM, Trevor Parscal  wrote:
> Not all changes made in the HTML output of Vector were made arbitrarily
> or gratuitously as is being assumed here.

No one was assuming that.  I pointed out several differences that
*are* gratuitous, in that they do not provide any functional
difference that should logically be related to users' skin choice.
Either they're good and should be in all skins, or bad and should be
in no skins, or they're neutral and may as well be in all or none just
for consistency's sake.  None of them has any reason to be present in
one skin but not another.

> In i18n, you have to be careful about using the same message key in
> multiple places, because as the context changes in each of those places,
> the likelyhood of the message being ideal in all situations in all
> languages decreases. Similarly, relying on identical HTML structure and
> classification for dissimilar skins is a bad practice to keep scripts
> and hacks from having to be customized is a fatal mistake.

Why?  If the skins can be given identical (or nearly identical) HTML
structure, then give it to them, and the scripts will work.  Or some
percentage will break, fine -- but you don't have to deliberately
break all the rest too.

> Vector has a distinctly different approach to..
>
>    * Navigation structure - the namespaces, variants, views and actions
>      are all separate lists

The only substantive differences I can spot here at a glance on
localhost are that namespaces are their own list (is this actually
necessary for some reason? surely the gap can be added with CSS
somehow), and there's a "Variants" list which is empty (which is
invalid HTML, incidentally).  Plus a lot of stuff has different
classes and id's for, again, no apparent reason.

>    * Right-to-left compatibility - lists are actually generated
>      backwards in RTL modes (look at the personal tools in Monobook in
>      RTL - it's not in the correct order, and in Vector it is, even on
>      IE 5.5)

Then why shouldn't all other skins be changed to do this too?  This is
a bug in Monobook, and you've only fixed it in Vector rather than in
all affected skins.  Why?

>    * Search - it's not a portal anymore, it's part of the skin and it's
>      in the top right which has many incompatibilities with layout
>      assumptions made for other skins

Such as?  The HTML looks virtually identical in any case.

>    * Footer structure - Links to places and information like copyright
>      notices are separate lists and rendered differently

The differences in appearance here look like they could be replicated
in CSS without using different HTML for the two skins, offhand.

> These are not "gratuitous" changes in the UI, and the effects they have
> on the resulting HTML output aren't either.

I haven't yet seen any case where a difference in the HTML is actually
necessary to achieve some effect.  There might be one or two, I'm
happy to admit that, but there are sure a lot of differences that are
*not* necessary, and those should be fixed.

> What happened to column-one and column-content? Well, Vector doesn't
> layout the same way that Monobook does, and given that styles meant for
> those IDs were and would continue to be a problem.

What do you mean by this?  Anyone who tries applying styles that
affect the layout of one skin, to another skin, is obviously going to
see their styles break one way or another.  The problem will not be
helped by changing the id's -- it will break either way.  But changing
id's will break scripts unnecessarily, too.  And break styles that
would happen to work across skins.

If we want to change id's to more sensible names, then why don't we do
it in Monobook too?  The only reason not to is that it would break
scripts and styles -- but switching to Vector as default would do that
anyway.  (I don't think we should do this; I think Vector and all
other skins should just use the silly old names for backward
compatibility.)

> I took the oportunity
> to name them more sensibly, and avoided future issues of people putting
> things in global CSS that obviously belonged in Monobook.css.

Can you point to where this is actually a problem?  I can point to
very clear evidence that using different classes/ids across different
skins is a problem.  On enwiki there's a gadget: "Compatibility
function to run scripts only tested on Monobook on the new Modern
skin. Required for using Twinkle or Friendly (along with many other
scripts) with the Modern skin."  Look at the source code:

http://en.wikipedia.org/wiki/MediaWiki:Gadget-modernskin-thunks.js

If that doesn't indicate that changing IDs creates real problems that
can be easily solved by just using the most similar ID in the original
skin, I don't know what does.

Not to mention the lengthy list of skin-related commits that have to
change four files at once because they're changing some HTML output.
If you maintain separate HTML where not strictly necessary, any chan

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler

[Gregory Maxwell]

On Wed, Feb 10, 2010 at 8:17 PM, Tim Starling  wrote:
> Obviously if there is some encoder that, with the default settings, is
> generating 10 second files with a single keyframe and 240 inter
> frames, and this encoder is significant for Wikimedia, then I will
> have to rethink this approach.

256-frame keyframe interval is the default for anything libtheora 1.1
based in two-pass mode... So, yes. I'm pretty sure thats relevant.

I wouldn't have even realized the existing processing chain was
failing on files that contained no keyframes past the midpoint were it
not for the fact that I'd bumped into failed thumbnailing on short
files. ::shrugs::

There isn't really a reasonable "fixed heuristic distance between
keyframes", the encoder can put them anywhere subject to the
limitation that they not be more than KEYINT away from the last one.
So even knowing the interval the locations can't be reliably
determined without scanning the file.

The alternative "one line fix" is switching to a thumbnailer that
actually thumbnails the requested location. All the better when the
thumbnailer correctly handles 4:2:2 and 4:4:4 colorspaces. Just
saying——

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler

[Tim Starling]

Gregory Maxwell wrote:
> I don't see how you can fix it in normalizeParams call unless you've
> scanned the stream and know where the keyframes are.  

Well, we do actually scan the stream. We interpret the granule
position of each page and record the last granule position in the
stream for the purposes of calculating stream length. It would be easy
enough to make a note of the last keyframe position as well.

But when I said a one-line fix, I was thinking along the lines of a
fixed heuristic distance between keyframes, either in time or frame
count, that roughly matches the characteristics of common encoders. If
the requested seek time is too close to the end, it would be moved
back, possibly right back to the start. This is already implemented,
but there's a bug in it for short streams which may be causing
trouble. Or the period may not be long enough.

Obviously if there is some encoder that, with the default settings, is
generating 10 second files with a single keyframe and 240 inter
frames, and this encoder is significant for Wikimedia, then I will
have to rethink this approach.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[Trevor Parscal]

On 2/10/10 3:50 PM, Platonides wrote:
> Aryeh Gregor wrote:
>
>> On Tue, Feb 9, 2010 at 8:35 PM, Trevor Parscal  
>> wrote:
>>  
>>> Merging Monobook and Modern is actually a good point for one of my other
>>> ideas, which is to have themes for skins. In other words, same HTML
>>> generation, different CSS. Then Monobook and Modern could naturally be
>>> merged, Vector could have a different colored version, etc.
>>>
>> I'd still be interested in seeing some differences between Vector and
>> Monobook HTML that are necessary at all.  There are a *lot* of small,
>> seemingly gratuitous differences that could be wiped out, like:
>>
>> * No  or
>> * Two empty  at the top, also
>> * Lots of extra comments like  
>> *  instead of, and it has class="noprint"
>>
>> and so on.
>>  
>
> Me too.
> And that's a good example of the things I'd like to have fixed before
> 1.16 so we can completely change the way some things were done on
> vector. Enough code had to be adapted (innecesarily) to vector on
> wikipedia now. Why force third users to vectorise if we are going to
> change it back?
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Not all changes made in the HTML output of Vector were made arbitrarily 
or gratuitously as is being assumed here.

In i18n, you have to be careful about using the same message key in 
multiple places, because as the context changes in each of those places, 
the likelyhood of the message being ideal in all situations in all 
languages decreases. Similarly, relying on identical HTML structure and 
classification for dissimilar skins is a bad practice to keep scripts 
and hacks from having to be customized is a fatal mistake. Vector has a 
distinctly different approach to..

* Navigation structure - the namespaces, variants, views and actions
  are all separate lists
* Right-to-left compatibility - lists are actually generated
  backwards in RTL modes (look at the personal tools in Monobook in
  RTL - it's not in the correct order, and in Vector it is, even on
  IE 5.5)
* Search - it's not a portal anymore, it's part of the skin and it's
  in the top right which has many incompatibilities with layout
  assumptions made for other skins
* Footer structure - Links to places and information like copyright
  notices are separate lists and rendered differently

These are not "gratuitous" changes in the UI, and the effects they have 
on the resulting HTML output aren't either.

What happened to column-one and column-content? Well, Vector doesn't 
layout the same way that Monobook does, and given that styles meant for 
those IDs were and would continue to be a problem. I took the oportunity 
to name them more sensibly, and avoided future issues of people putting 
things in global CSS that obviously belonged in Monobook.css. Look at 
the revisions to shared.css and you will see allot of things that were 
moved to skin-specific CSS files that should have never been in the 
global one.

As to the point of the two empty divs, they are absolutely used, and 
they are specifically noprint for good reason. The tags area actually:




As for the tag:  - this 
is used for the ajax watch and unwatch functionality and is also present 
on Monobook once you use it. The difference is simply that Vector 
provides it ahead of time. I didn't do that

Also, Why would you want to print the contents of the head? The 
printable version of Vector has been carefully crafted. If there's a 
noprint class somewhere, it's on purpose.

Finally, those comments are useful for debugging purposes. If they are 
offensive, they can be removed - obviously they have no other functional 
properties.

Furthermore, if you take a quick look at the revision history of Vector, 
you can see that we've done all we can to make things compatible with 
Monobook where it makes sense. 
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/Vector.php?view=log

So, I hope that answers some of these questions. I'm glad to answer more.

- Trevor
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[Platonides]

Aryeh Gregor wrote:
> On Tue, Feb 9, 2010 at 8:35 PM, Trevor Parscal  wrote:
>> Merging Monobook and Modern is actually a good point for one of my other
>> ideas, which is to have themes for skins. In other words, same HTML
>> generation, different CSS. Then Monobook and Modern could naturally be
>> merged, Vector could have a different colored version, etc.
> 
> I'd still be interested in seeing some differences between Vector and
> Monobook HTML that are necessary at all.  There are a *lot* of small,
> seemingly gratuitous differences that could be wiped out, like:
> 
> * No  or 
> * Two empty  at the top, also 
> * Lots of extra comments like  
> *  instead of , and it has class="noprint"
> 
> and so on.  


Me too.
And that's a good example of the things I'd like to have fixed before
1.16 so we can completely change the way some things were done on
vector. Enough code had to be adapted (innecesarily) to vector on
wikipedia now. Why force third users to vectorise if we are going to
change it back?



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] confirm dfe03c58a0a....

[Peter Kaminski]

Conrad Irwin writes,

> The point of the password is so you can prove to the web interface 
> that you own the email address; so the fact that it is in your email 
> box doesn't matter much. (If your email gets hacked this is the last 
> thing you're likely to be worried about after all.) As it says on sign 
> up "do not use a valuable password".

The problem with a cleartext password in email isn't that your email 
might get hacked.  It's that each device with access to the network path 
from list server to mail server and mail server to email client has 
access to the password.  Search the net for "password sniffer" for more 
information.

> In which case so could the password reset emails. It gains you nothing.

Password reset tokens or URLs are generally designed to be used one 
time, and then they expire.  The user generally uses it within a few 
minutes of initiating the password reset, preventing any later use of it.

On the other hand, sending a user's password through the mail exposes it 
to being logged for later use.  For a security-conscious user, it 
effectively spoils its use forever.

I agree that you shouldn't use a valuable password with Mailman, and 
that the Mailman project is the right place to ask for a change in 
Mailman's behavior.

Pete


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] confirm dfe03c58a0a....

[Conrad Irwin]

On 02/10/2010 09:15 PM, Thomas Dalton wrote:
> On 10 February 2010 21:00, Conrad Irwin  wrote:
>> The point of the password is so you can prove to the web interface that
>> you own the email address; so the fact that it is in your email box
>> doesn't matter much. (If your email gets hacked this is the last thing
>> you're likely to be worried about after all.) As it says on sign up "do
>> not use a valuable password".
> 
> It doesn't require your email to be hacked, though. There is no
> security in the email system, they can be intercepted at any point.

In which case so could the password reset emails. It gains you nothing.

Conrad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] confirm dfe03c58a0a....

[Thomas Dalton]

On 10 February 2010 21:00, Conrad Irwin  wrote:
> The point of the password is so you can prove to the web interface that
> you own the email address; so the fact that it is in your email box
> doesn't matter much. (If your email gets hacked this is the last thing
> you're likely to be worried about after all.) As it says on sign up "do
> not use a valuable password".

It doesn't require your email to be hacked, though. There is no
security in the email system, they can be intercepted at any point.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] confirm dfe03c58a0a....

[Conrad Irwin]

On 02/10/2010 08:49 PM, Marco Schuster wrote:
> Hi all,
> 
> I just got this email from bugzilla. Apparently Google Apps has screwed up
> something again so the message itself doesnt annoy me, but why are the
> users' passwords still sent in CLEARTEXT in these days??
> Can someone (tm) of the mailman admins or tech guys please fix this up?
> 
> Thanks,
> Marco

The point of the password is so you can prove to the web interface that
you own the email address; so the fact that it is in your email box
doesn't matter much. (If your email gets hacked this is the last thing
you're likely to be worried about after all.) As it says on sign up "do
not use a valuable password".

As far as I'm aware there's no flag to modify this behaviour, so any
local fixes would have to be hacks to mail-man. As I'm sure you can't be
the only one who wants this fixed, I recommend you try and contact the
mail-man folk directly.

Conrad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] confirm dfe03c58a0a....

[Marco Schuster]

Hi all,

I just got this email from bugzilla. Apparently Google Apps has screwed up
something again so the message itself doesnt annoy me, but why are the
users' passwords still sent in CLEARTEXT in these days??
Can someone (tm) of the mailman admins or tech guys please fix this up?

Thanks,
Marco

On Wed, Feb 10, 2010 at 2:47 PM, wrote:

> Your membership in the mailing list Wikitech-l has been disabled due
> to excessive bounces The last bounce received from you was dated
> 10-Feb-2010.  You will not get any more messages from this list until
> you re-enable your membership.  You will receive 3 more reminders like
> this before your membership in the list is deleted.
>
> To re-enable your membership, you can simply respond to this message
> (leaving the Subject: line intact), or visit the confirmation page at
>
>
> https://lists.wikimedia.org/mailman/confirm/wikitech-l/dfe03c58a0a1fe2.
>
>
> You can also visit your membership page at
>
>
> https://lists.wikimedia.org/mailman/options/wikitech-l/marco%40harddisk.is-a-geek.org
>
>
> On your membership page, you can change various delivery options such
> as your email address and whether you get digests or not.  As a
> reminder, your membership password is
>
> 

>
> If you have any questions or problems, you can contact the list owner
> at
>
>wikitech-l-ow...@lists.wikimedia.org
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[Trevor Parscal]

On 2/10/10 6:55 AM, Roan Kattouw wrote:
> 2010/2/10 Aryeh Gregor:
>
>> I'm also concerned by the fact that at least some (I haven't looked
>> closely) of the Usability Initiative stuff seems to work only in
>> Vector.  For instance, apparently EditWarning doesn't work at all in
>> non-Vector skins, although it's surely just as applicable.  Skins
>> should *only* be used to provide different visual appearance -- they
>> should not be creating functional differences.  Users should be able
>> to choose which skin they prefer based on aesthetics alone, without
>> having to sacrifice features to use their preferred skin.
>>
>>  
> EditWarning only working in Vector is a weird quirk that is indeed
> unnecessary. The other Vector-only modules, however, do stuff that's
> rather Vector-specific and need skin support (like collapsing tabs,
> enhancing Vector's search box, etc.).
>
> Roan Kattouw (Catrope)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
EditWarning works in any skin. It's only turned on on Vector because 
there was this concern that the "Read" tab would cause people to leave 
the edit page without thinking about their edits. I never agreed with 
this notion, but we added it in to appease those who did.

- Trevor

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[David Gerard]

On 10 February 2010 14:45, Aryeh Gregor  wrote:

> That means 6% aren't, i.e., ~700,000 users.  That's actually much
> higher than I expected.  It would be particularly silly to throw out
> Chick, Simple, and MySkin, since those differ from Monobook only in
> CSS.
> I don't think we should get rid of any skins here if feasible.


Main thing is to let people know on the larger wikis that a change to
the skin engine is coming, and if they want ObscureSkin or
PrimordialSkin they are heartily welcome to hack on the CSS. (I'd
guess good web designers would be much easier to find than good PHP
developers.) As long as people are warned and asked to help, it should
avoid ruffled feathers on the part of the users.

(Hmm, wonder how easy it'd be to put a Nostalgia skin on Monobook ...)


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[Roan Kattouw]

2010/2/10 Aryeh Gregor :
> I'm also concerned by the fact that at least some (I haven't looked
> closely) of the Usability Initiative stuff seems to work only in
> Vector.  For instance, apparently EditWarning doesn't work at all in
> non-Vector skins, although it's surely just as applicable.  Skins
> should *only* be used to provide different visual appearance -- they
> should not be creating functional differences.  Users should be able
> to choose which skin they prefer based on aesthetics alone, without
> having to sacrifice features to use their preferred skin.
>
EditWarning only working in Vector is a weird quirk that is indeed
unnecessary. The other Vector-only modules, however, do stuff that's
rather Vector-specific and need skin support (like collapsing tabs,
enhancing Vector's search box, etc.).

Roan Kattouw (Catrope)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skin system rewrite

[Aryeh Gregor]

On Tue, Feb 9, 2010 at 7:30 PM, Trevor Parscal  wrote:
> Why only Monobook and Vector? 94%[1] of users on English Wikipedia are
> currently using one of them.

That means 6% aren't, i.e., ~700,000 users.  That's actually much
higher than I expected.  It would be particularly silly to throw out
Chick, Simple, and MySkin, since those differ from Monobook only in
CSS.

I don't think we should get rid of any skins here if feasible.

> In short, It's better to give users their choice of 3 decent skins than
> 10 crappy ones, and if we can make migration to the new system less
> painful, it's more likely to actually happen.

The skins would only be more "decent" from a developer's perspective,
not a user's perspective.  I'm reluctant to agree that we should get
rid of skins that people actually use in significant numbers (even
0.1% of 10,000,000+ is significant) when it will yield no substantial
user-visible improvements.  If the new system only includes
Vector/Monobook/Modern at first, fine, but keep the old skins too --
at least we'll have only two skin systems instead of four.  When
someone feels motivated, they can port the old skins to the new system
in some format.  (It's okay IMO if they're not exactly the same, as
long as they look similar enough.)

On Tue, Feb 9, 2010 at 8:35 PM, Trevor Parscal  wrote:
> Merging Monobook and Modern is actually a good point for one of my other
> ideas, which is to have themes for skins. In other words, same HTML
> generation, different CSS. Then Monobook and Modern could naturally be
> merged, Vector could have a different colored version, etc.

I'd still be interested in seeing some differences between Vector and
Monobook HTML that are necessary at all.  There are a *lot* of small,
seemingly gratuitous differences that could be wiped out, like:

* No  or 
* Two empty  at the top, also 
* Lots of extra comments like  
*  instead of , and it has class="noprint"

and so on.  These all make things harder to do and will force code
duplication.  Every id or element that exists in one skin but not
another means it's that much harder to write portable scripts and
styles.  If we want more comments, or extra empty divs for JS to hook
into (why not create those with JS like we do with jsMsg in
wikibits.js?), then add them to *all* skins.  And if Vector doesn't
need globalWrapper or column-content, it can have them anyway but just
not style them -- that doesn't hurt anything.

(These concerns all apply to Modern as well, which I also complained
about when it was introduced.)

I'm also concerned by the fact that at least some (I haven't looked
closely) of the Usability Initiative stuff seems to work only in
Vector.  For instance, apparently EditWarning doesn't work at all in
non-Vector skins, although it's surely just as applicable.  Skins
should *only* be used to provide different visual appearance -- they
should not be creating functional differences.  Users should be able
to choose which skin they prefer based on aesthetics alone, without
having to sacrifice features to use their preferred skin.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler

[Gregory Maxwell]

On Wed, Feb 10, 2010 at 8:38 AM, Tim Starling  wrote:
> That sounds like it needs a one-line fix in
> OggHandler::normaliseParams(), not 50 lines of code and a new decoder.
> Do you have a test file or a bug report or something?

Just switching the thumbnailer should be sufficient, I agree the pile
of code and the retries were fairly lame (and I think I complained
about it on IRC). I'm not sure why any support for thumbnailing ogv's
with ffmpeg was retained.

I don't see how you can fix it in normalizeParams call unless you've
scanned the stream and know where the keyframes are.  Ffmpeg could be
fixed, of course, but the ogg demuxer basically needs a rewrite... I
think the patch you did to ffmpeg a while back was a lot better than
the code they ultimately included.

Here is a file that won't thumbnail under the current code:
http://myrandomnode.dyndns.org:8080/~gmaxwell/theora/only_one_keyframe.ogv


ffmpeg -y -ss 5 -i only_one_keyframe.ogv -f mjpeg -an -vframes 1 foo.jpeg
throws a pile of errors then foo.jpeg is a zero byte file.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [62223] trunk/extensions/OggHandler

[Tim Starling]

Gregory Maxwell wrote:
> On Wed, Feb 10, 2010 at 12:51 AM,   wrote:
>> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62223
>>
>> Revision: 62223
>> Author:   tstarling
>> Date: 2010-02-10 05:51:56 + (Wed, 10 Feb 2010)
>>
>> Log Message:
>> ---
>> * In preparation for deployment, revert the bulk of Michael's unreviewed 
>> work. Time for review has run out. The code has many obvious problems with 
>> it. Comparing against r38714 will give you an idea of which changes I am 
>> accepting. Fixes bug 22388.
>> * Removed magic word hook, doesn't do anything useful.
>> * OggPlayer.js still needs some work.
> 
> Looks like this change removed both the Oggthumb support as well as
> the code that handles the cases where ffmpeg fails.
> 
> Ffmpeg will fail to generate a thumb if there is no keyframe in the
> file after the point in time that you requested a thumb. This was
> causing a failure to generate thumbs for many files because they are
> short and only have a single keyframe at the beginning.

That sounds like it needs a one-line fix in
OggHandler::normaliseParams(), not 50 lines of code and a new decoder.
Do you have a test file or a bug report or something?

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Release the content on Wikimedia Technical Blog under a free content license

[David Gerard]

On 10 February 2010 09:59, K. Peachey  wrote:
> On Wed, Feb 10, 2010 at 7:25 PM, Daniel Kinzler  wrote:

>> I'm afraid you will have to ask every author individually. At least in 
>> theory.

> Shouldn't the blog be under the WMF's blanket policy, which if I
> remember correctly is a CC-Attribute Share-alike by default?


Asking every author individually first still smells like the right
thing to do. With a policy going forward that techblog posts are
CC-by-sa or freer.


- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Release the content on Wikimedia Technical Blog under a free content license

[K. Peachey]

On Wed, Feb 10, 2010 at 7:25 PM, Daniel Kinzler  wrote:
> I'm afraid you will have to ask every author individually. At least in theory.

Shouldn't the blog be under the WMF's blanket policy, which if I
remember correctly is a CC-Attribute Share-alike by default?

-Peachey

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Release the content on Wikimedia Technical Blog under a free content license

[Daniel Kinzler]

Liangent schrieb:
> http://techblog.wikimedia.org/ : Is it ok to do it just like our main
> wikis and WMF official blog?

I'm afraid you will have to ask every author individually. At least in theory.

Fwiw, I'm fine with CC-BY, CC-BY-SA, and/or GFDL.

-- daniel

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l