Hello to all, I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality. Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.

It needs flash 10.

On Thu, May 7, 2009 at 3:18 PM, apri a.vd.wiel <a.vd.wiel(a)apri.nl> wrote: I have flash player installed, and I didn't understand what to do. I saw a few boxes to the left and right, but nothing in them made sense. I pressed add a link, but I didn't see any way to control the target of the link or what the link text says. -Chad _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

This means we will probably not see this enabled on WMF sites. Flash is a proprietary format. Forcing users to install this is in conflict with Wikimedia's mission to spread open file formats and software. See also http://en.wikipedia.org/wiki/Adobe_Flash#Disrespecting_freedom_of_the_web

Ok. options: a. we wait for Adobe to make this format opensource ;-)

I don't think making it work with free flash players is an option. Just like MP3, free software is able to play it, but the format itself is not free and will thus not be used by the WMF.

from the Adobe site http://www.adobe.com/devnet/swf/: SWF File Format Specification (Version 10) The SWF file format is available as an open specification to create products and technology that implement the specification.

This looks like MW can use flash 10 and its swf format. I asked Adobe about this question. I let you know what there answere is.

wrote:

wrote:

*If* it actually works, then there's still at least one more problem: It should be possible to modify this plugin using Free tools. Adobe's own Flash authoring tool is not Free.

On Fri, May 8, 2009 at 11:43 AM, Amir Elisha Aharoni <amir.aharoni(a)gmail.com > On Fri, May 8, 2009 at 20:26, Brian <Brian.Mingus(a)colorado.edu> > There is nothing bad about the flash format. If it works in a free player > > I'm not aware of any other objections. > > *If* it actually works, then there's still at least one more problem: > It should be possible to modify this plugin using Free tools. Adobe's > own Flash authoring tool is not Free. This may not seem relevant to > users, but people need to have a reasonable way to use a program > without being deprived of Freedoms #1 and #3 of Free Software. (See > [[Free_software#Definition]] in Wikipedia.) Are you really addressing a deficit in Gnash, or some hypothetical situation?

Ok, but is there one that supports the features found in Gnash? Isn't flash a language specification, and doesn't Gnash have an emacs mode? On Fri, May 8, 2009 at 12:21 PM, Amir Elisha Aharoni &lt;amir.aharoni(a)gmail.com > On Fri, May 8, 2009 at 21:11, Brian &lt;Brian.Mingus(a)colorado.edu&gt; >> On Fri, May 8, 2009 at 11:43 AM, Amir Elisha Aharoni < > amir.aharoni(a)gmail.com >>>> >>> On Fri, May 8, 2009 at 20:26, Brian &lt;Brian.Mingus(a)colorado.edu&gt; >>>>>> There is nothing bad about the flash format. If it works in a free > player >>>> I'm not aware of any other objections. >>> >>> *If* it actually works, then there's still at least one more >>> problem: >>> It should be possible to modify this plugin using Free tools. >>> Adobe's >>> own Flash authoring tool is not Free. This may not seem relevant to >>> users, but people need to have a reasonable way to use a program >>> without being deprived of Freedoms #1 and #3 of Free Software. (See >>> [[Free_software#Definition]] in Wikipedia.) >> Are you really addressing a deficit in Gnash, or some hypothetical >> situation? > > Gnash is a *player*, a Free replacement for Adobe Flash *Player*. It > works pretty well as a player, but it is not supposed to be an > authoring tool. > > There are certain Free Flash authoring tools, but to the best of my > knowledge there is no complete replacement for Adobe Flash, the > authoring tool. > > -- > אמיר אלישע אהרוני > > heb: http://haharoni.wordpress.com | eng: http:// > aharoni.wordpress.com > cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com > > "We're living in pieces, > I want to live in peace." - T. Moore > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I'd just like to get this thread back on track with a couple notes. 1) Wikimedia will not be interested in an editing widget based entirely on Flash. 2) If someone wants to make their own, hey have fun! That's cool. Try to keep list discussion about it on-topic and productive. 3) General issues with Flash and Wikimedia's software freedom demands have previously been discussed. We're not against using it in limited ways with graceful degradation as a fallback alternative to other web standard technologies, so long as no patent-encumbered formats are involved. If folks are interested in further general discussion about how free Flash or Flash authoring are or aren't, please feel free to take it off-list. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

El 5/8/09 11:48 PM, Brian escribió: If you're creating a huge giant UI in Flash, it'll take a lot of extra work to duplicate an entire second version in cross-platform high-functioning web standards, and maintain both versions. If you've only programmed a Flash version, then when Flash isn't available, you've got nothing. That's not very nice for something we'd want to ship. :) Hence, we're most interested in Flash for small pieces which degrade gracefully, not an entire page editing widget. But as I said, third parties are more than welcome to use whatever they like for their own development. If the result is interesting, we'd be happy to learn lessons on UI and workflow from it, but we'd never use it directly. -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, May 8, 2009 at 2:39 PM, Brion Vibber &lt;brion(a)wikimedia.org&gt; wrote: Even if it's designed to work perfectly in gnash? _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hello to all, I am developing Apri wiki editor and at this moment have a what I call a working prototype which I want to share with you. Still a lot of work to do but I like the results so far ;-). Functionality is very basic but shows enough to give you an impression. UI is not what the end result will look like but I'm still looking for the right design in combination with functionality. Please see http://ria.apri.nl/mediawiki-1.14.0/index.php/Main_Page Read the page. Click the edit button and see what happens.

Handling of the wikitext uses a markup definition file. Application handles all elements configured in this file. Elements not recognised are presented as the original wikitext. So all elements can be used but then of cours not presented as wysiwyg. This means you can edit simple but also complex wikitext. Switching to other wiki-platforms can be done relative easy by simply changing the tags in de defintion file.

Yes, I did see this. Template is not configured yet. I did configure swm ask wich has the same end tag ' }}'. A bug wich I will correct in the engine. Comment configuration is easy but howto present in wysiwg? Hidden property? Do you have an idea? My plan is to make a testapplication which calls the editcomponent for different wikitext files and compares the result with goodresult- files. One push on the button will give the answer if changes is the engine are ok. Andre Op 11 mei 2009, om 14:30 heeft Mark Clements (HappyDog) het volgende geschreven: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I see there is no formating (bold and italic) in the message. But for this case my conclusion is: MW formatting is (also) not correct. The markup spec says: Note that improper nesting of bold and italics is currently permitted. Which means that the formatting can't be correct in all cases. The markup spec must be more strict.

'''how about ''this edit'''s more complicated bold/italic markup?''' Do you think MW gives the right result?

Basically, this is the reason why there is no really good WYSIWYG editor for MediaWiki. I don't want to discurage you, I just want to point out where the problems are. Some examples: the closing }} of a template may actually be contained in the definition of another template, same with thables. I have seen |} being replaced by something like {{TableEnd}}. Lots of fun there.

The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. Cases that break could be detected by comparing tidied HTML output from both parser versions.

On Mon, May 11, 2009 at 8:50 PM, Daniel Schwen&lt;lists(a)schwen.de&gt; wrote: Sounds cool, but it'd require a formalization of MW markup first (something that should have been done long ago). What about correcting stuff from "old" behavior to new parser via bots/update scripts, even for old revisions? Marco

2009/5/11 Daniel Schwen &lt;lists(a)schwen.de&gt;de>: Actually, this makes sense, and I've heard a very similar suggestion from another developer (I believe it was Tim, not sure) at the Berlin meet-up.

I thought it was generally agreed upon that the path to fix the parser goes something like this: * Define a new wiki language that is compatible with bison/flex * Write a converter between the old language and the new (when possible) * Implement per-revision parsers * Implement the new parser * Begin the migration On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal &lt;tparscal(a)wikimedia.org&gt;wrote;wrote:

I thought it was generally agreed upon that the path to fix the parser goes something like this: * Define a new wiki language that is compatible with bison/flex * Write a converter between the old language and the new (when possible) * Implement per-revision parsers * Implement the new parser * Begin the migration On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal &lt;tparscal(a)wikimedia.org&gt;wrote;wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l