IRC 2007/06/15

15:02 < jfhv> we were speaking with Bermi about the XHTML parser
15:02 < jfhv> I copy/paste:
15:02 < jfhv> 14:51 < bermi_> I really need to get some time free to help more on WYM
15:02 < jfhv> 14:52 < jfhv> I see. So you're too busy right now to help?
15:02 < jfhv> 14:53 < bermi_> yes, but in two weeks I'll have some time to contribute
15:02 < jfhv> 14:54 < jfhv> OK. That changes a little bit my plans, but it's OK.
15:02 < jfhv> 14:54 < bermi_> which are your plans?
15:02 < jfhv> 14:55 < jfhv> I was going to ask you if you wanted to integrate the XHTML parser into the trunk.
15:02 < jfhv> 14:57 < bermi_> I'd love to have the new parser on the trunk. It's implemented on the new_parser branch, but naming conventions have changed, so it will take a little bit
15:03 < jfhv> 14:59 < jfhv> I guess you mean some code has to be updated in jquery.wymeditor.js?
15:03 < bermi_> Thats right some code needs to be updated
15:03 < jfhv> OK. So just the variable names?
15:04 < bermi_> an a lot of code needs to be removed from the Browser Drivers
15:04 < jfhv> Explain please?
15:05 < bermi_> I'll have a look right now to refresh my mind and explain it better
15:05 < jfhv> OK, thanks.
15:06 < jfhv> Has everybody seen the Coding Guidelines?
15:06 < jfhv>
15:06 < vmx> if you'd like to change anything just do it, they shouldn't be considered as final
15:07 < jfhv> I'm OK with them :)
15:07 < bermi_> I have read them
15:08 < jfhv> OK. Can we start rewrite the code, or do we have to wait for the XHTML parser integration?
15:09 < jfhv> I mean e.g. using literals.
15:10 < bermi_> IMO It should not make any difference
15:11 < jfhv> OK. I can start this task.
15:11 < bermi_> ok, so integrating the new parser eliminates de need for browser specific WymClass.prototype.xhtml method. That is the main difference
15:12 < vmx> bermi: is it currently working and it needs a rewrite, or does it need a rewrite to get it working?
15:12 < bermi_> It is currently working on the new_parser branch
15:13 < vmx> so the rewrite could take place in trunk?
15:13 < bermi_> I wouldn't change the xhtml_parser code because of the literals thing, until we have it working on the trunk
15:13 < bermi_> yes it could go in the trunk
15:15 < jfhv> If I understand correctly, it's 1) rewrite, using literals 2) integrate XHTML parser in the trunk ?
15:15 < bermi_> I would do it the other way arround
15:16 < jfhv> Ah, sorry.
15:16 < bermi_> I would make sure I works in the trunk and then rewrite It without breaking it
15:16 < vmx> i'll second that
15:17 < dreszka> sounds good
15:17 < jfhv> OK. Someone interested to do the job?
15:17 < bermi_> I also added a method named getBrowserSpecificWymInstance
15:18 < bermi_> but I'm not sure if its worth adding it to the trunk due the monolithic JS that the build generates
15:18 < vmx> moving it to trunk should be done by bermi, the rewrite could be done by anybody (if i understood it right)
15:21 < jfhv> I agree. Bermi: what's your opinion?
15:21 < bermi_> I'm moving it into the trunk right now. It should work without problems
15:21 < jfhv> cool
15:21 < bermi_> there is another feature that I already implemented and would like to know if it fits in the trunk (configureEditorUsingRawCss)
15:23 < jfhv> IIRC I'm OK with that feature, but I don't remember if we said we'll integrate it as a plugin.
15:23 < vmx> bermi: what does it do?
15:24 < bermi_> you can configure your WYM instance by providing the url to a CSS file or in plain CSS Text
15:25 < jfhv> ... to populate classesItems and so on
15:26 < vmx> sounds good
15:26 < bermi_> jf, could you send the URL to the new_parser branch so they can see how it works
15:27 < jfhv> OK
15:27 < jfhv> on the Trac:
15:28 < jfhv>
15:28 < bermi_> thanks
15:29 < jfhv> you're welcome :)
15:29 < bermi_> sWymStylesheet: 'wym_stylesheet.css', tells which CSS file to use
15:30 < bermi_> and WYM styles are enclosed into /* WYMeditor */ /* /WYMeditor */
15:31 < bermi_> So you can use the same CSS For wym and for the production site
15:32 < jfhv> great feature for web designers
15:32 < vmx> and integration into cms'
15:33 < jfhv> Ah, something I remember now: FF opens a new window when clicking on the tools buttons
15:34 < jfhv> Do you have the same problem in your FF?
15:35 < bermi_> I'm aware of that
15:35 < jfhv> Do you know what's happening?
15:35 < bermi_> no idea, that only happens on the new_parser branch. Isn't it?
15:35 < jfhv> yes
15:37 < vmx> target was used
15:37 < vmx> in the <a>
15:37 < vmx> without that it shouldn't open a new window
15:38 < dreszka> sorry, but i'm looking at the example:
15:38 < dreszka>
15:38 < dreszka> and i don't see the CSS declarations enclosed into /* WYMeditor */ /* /WYMeditor */
15:38 < bermi_>
15:38 < dreszka> ok
15:39 < jfhv>
15:39 < jfhv> uses sWymCss (wymCss)
15:40 < jfhv> OK. Volker: where is the offending code?
15:41 < vmx> i've just take a look at the final dom tree
15:41 < vmx> the toolbar consits of <a>, right?
15:42 < vmx> e.g. <a name="Bold" href="#" target="">Strong</a>
15:42 < vmx> without the "target" attribute is shhould work
15:43 < vmx> sorry i was wrong
15:43 < jfhv> jquery.wymeditor.js uses toolsItemHtml, which contains <a href="#" name=.... - no target
15:43 < jfhv> (sToolsItemHtml)
15:44 < vmx> i can take a look, let's go on with the meeting
15:44 < dreszka> bermi: I looked at wym_stylesheet.css and that's excellent ! Looks simple, effective and really flexible regarding the control possible on the visual feedback inside WYMeditor
15:45 < dreszka> exactly what was needed
15:45 < jfhv> OK. So is it a plugin or a core feature?
15:46 < dreszka> I'm impressed, but as it's not strictly needed for wymeditor to work, i'd make it a plugin
15:46 < bermi_> the CSS parser is ONLY loaded if that sort of configuration is used
15:46 < jfhv> important point
15:47 < bermi_> so having it on the core doesn't add more than 7 lines of code
15:47 < dreszka> ok
15:47 < dreszka> so why not
15:47 < dreszka> seems simpler to put it to the core then
15:47 < jfhv> Volker?
15:47 < bermi_> sorry 23 lines :D
15:47 < dreszka> and make it a standard feature
15:48 < vmx> jfhv?
15:48 < bermi_> it just builds up the configuration array that wym normally expect
15:48 < jfhv> Your opinion on that question?
15:49 < dreszka> both approaches are ok to me, but it's a feature so practical and time-saving that I think most users will want to use it
15:50 < dreszka> so we could make it standard
15:50 < bermi_> I'd love to have it on the core. I implemented it mainly to dynamically build editors based on the theme selected on the CMS
15:50 < vmx> i think it should be a core feature
15:50 < jfhv> BTW, perhaps we could use the same technique (using AJAX and eval) to dynamically load plugins, so the developer doesn't need to manually load the script plugin.
15:51 < bermi_> that would be great
15:51 < jfhv> I mean adding adding an option named e.g. plugins
15:52 < jfhv> plugins: {'hovertools','tidy'} ...
15:53 < bermi_> there is one issue
15:53 < bermi_> the scope of the functions included with this method remains in the loader
15:53 < bermi_> in the loading function
15:54 < bermi_> so you need to expand it to window.ClassName to avoid loading several times the same plugin content if you have more than one WYM instance
15:55 < jfhv> I see. Until jQuery.globalEval works in safari?
15:55 < bermi_> I tried jQuery gobal eval but it didn't work in XXX browser (short memory sorry)
15:55 < bermi_> thats right ;) thanks
15:55 < jfhv> Line 1045 :)
15:55 < jfhv>
15:56 < jfhv> OK. That can wait.
15:56 < bermi_> thanks, its good to comment my future memory leaks
15:56 < jfhv> LOL
15:57 < jfhv> OK. So it's OK for me for adding the CSS parser in the trunk.
15:58 < jfhv> What about getBrowserSpecificWymInstance?
15:58 < jfhv> Line 1014 :)
15:59 < bermi_> that will make WYM lighter
15:59 < bermi_> it uses the same technique to load ONLY current browser code
16:01 < jfhv> So I guess we can integrate it in the trunk, too.
16:03 < jfhv> I think we can also use this technique for l10n
16:04 < vmx> i can't find the "target" bug. let's hope it won't occur in trunk
16:04 < bermi_> I haven't used i18n yet on WYM. Does it load the language automatically?
16:05 < jfhv> No. You need to load the specific JS file.
16:05 < jfhv> manually
16:05 < jfhv> Will there be a problem with the scope?
16:08 < bermi_> no, that seems simple
16:08 < jfhv> Is jQuery.globalEval documented somewhere?
16:10 < jfhv> OK, it's in
16:11 < jfhv> line 827 'not reliable for safari'
16:12 < bermi_> thats why I did my own version
16:12 < bermi_> I need to check it out in WebKit and the new Safari beta
16:12 < bermi_> support for current safari is a REAL nightmare
16:13 < jfhv> Yes. I also tested in Safari+Windows
16:13 < bermi_> how was it?
16:14 < jfhv> Made some test in my branch, test/021
16:14 < jfhv> The generated HTML is .... strange.
16:15 < jfhv> I suppose its the same as in Safari+Mac
16:16 < jfhv> FYI:
16:18 < jfhv> OK. So Bermi, do you have some time to integrate the new features in the trunk?
16:19 < bermi_> not until wednesday night
16:19 < bermi_> and from now to 17:00
16:21 < bermi_> I'm implementing it but finding problems when using inheritance
16:24 < jfhv> OK, I'm not urging you, BTW.
16:25 < jfhv> We can also work on documenting the code, using Natural Docs.
16:25 < bermi_> is there any file uploading plugin for WYM?
16:26 < jfhv> Not for the moment.
16:26 < jfhv> There was a Drupal developer interested to integrate IMCE.
16:27 < jfhv> Why?
16:28 < bermi_> because I need to code one for my CMS
16:28 < dreszka> I'm not a huge fan of imce, I find it doesn't integrate so well with WYMeditor
16:29 < jfhv> Well, it's also a long-awaited feature
16:29 < bermi_> just for having a look at it, the file management I'm coding is too tied to the Akelos framework
16:29 < dreszka> it could be interesting to have a plugin for WYMeditor, so we can have full control over it, and make it really well integrated
16:30 < vmx> i think the integration is ok. but the long term goal should be to write our own. the best would be a jquery plugin
16:31 < jfhv> I'd like the Community to work on that kind of features.
16:31 < dreszka> ok
16:32 < vmx> (nice)
16:32 < jfhv> IMHO, we need to focus on core features.
16:32 < dreszka> yes, i like this too :)
16:33 < bermi_> I will to code a jquery plugin for handling files and will try the interface simple to integrate with other server side solutions via json
16:33 < bermi_> need it for my CMS and I need it integrated in WYM
16:34 < jfhv> OK.
16:34 < vmx> bermi: the existing jquery plugin looks really nice (as i said before ;)
16:35 < bermi_> I will use one I coded that does uploading via an iframe (like gmail)
16:36 < bermi_> so files start traveling to the server before you fill in the rest of the form fields..
16:37 < bermi_> BTW looks really cool
16:37 < vmx> jfhv: i've just read the forum. i don't like the idea of moving the mailings lists to google groups. i had troubles (as you've sen on my multiposts on the jquery 1.1.3a thread).
16:37 < bermi_> thanks
16:38 < vmx> imho peple who dislike mailing lists could use the forum
16:39 < bermi_> vmx: I agree
16:40 < jfhv> I don't plan to transfer the m-l to Google.
16:40 < jfhv> But we'll see how it scales, too.
16:41 < jfhv> Another point: WYMeditor versions.
16:41 < jfhv> Do you think it's a good idea to rename 0.3.1 (so Bermi's new features) to 1.0?
16:42 < dreszka> oh yes :)
16:42 < vmx> i don't think it's a good idea
16:42 < jfhv> ... for marketing reasons.
16:43 < vmx> for me a 1.0 is a version which is really wym. => things like sapi needs to work
16:43 < dreszka> it could be 2.0
16:43 < vmx> sure, but i don't think wymeditor is ready for prime time
16:43 < jfhv> Well, we use it since 0.1 stable, you know.
16:44 < jfhv> We get good feedbacks from our customers.
16:44 < vmx> in addition it won't be in the spirit of other open source projects (although this is not a real reason)
16:44 < dreszka> currently, the main obstacle to adoption,is that people think 0.3 is not usable -> they think 'alpha software'
16:44 < vmx> my opinion: 1.0 can be out if it does what that name says: wym.
16:46 < jfhv> I understand What You Mean, but IMHO 0.2.2 was already WYM for the end-user.
16:46 < dreszka> if it can be used in production, i think it should be labelled 1.0
16:46 < dreszka> then we can have 1.5, 2.0 ... :)
16:46 < vmx> and i think you won't get that much hype from a "1.0" if knowone knows it. i think it'll be much better to wait for additional "hype" and then release a 1.0
16:47 < dreszka> but it would solve the problem of "wrong image" given by "0.XXX"
16:47 < jfhv> Actually for me it's only a marketing issue.
16:47 < dreszka> for me too
16:47 < vmx> 0.x doesn't give a wrong image. there needs much to be done
16:49 < vmx> it say it a bit provoking: it's proprietary 1.0 but an opne source 0.x
16:49 < jfhv> Idea: we can already switch to 0.4 with Bermi's new features.
16:49 < jfhv> 0.5 with SAPI
16:49 < jfhv> 0.6 Safari
16:50 < vmx> making bigger steps is ok for me
16:51 < jfhv> OK, that solves the problem a little bit.
16:51 < jfhv> But we lack good marketing.
16:52 < vmx> version is really an ideational discussion (at least for me)
16:52 < vmx> i think it is better marketing if you release a 1.0 when the hype is bigger
16:52 < bermi_> regarding MK, I saw a great Icon for wym at
16:52 < vmx> but i'm no expert in that matter
16:53 < bermi_> this guy has designed icons for several OS projects
16:53 < bermi_> they have on that looks really cool for wym
16:53 < bermi_>
16:54 < jfhv> yep, nice
16:54 < jfhv> Improving the web site is important, too.
16:55 < jfhv> We wanted to switch to Drupal, BTW.
16:56 < vmx> at the moment you use your own cms?
16:56 < jfhv> yep - rather corporate oriented
16:58 < jfhv> OK. We'll see.
16:58 < vmx> does anything need to eb discussed?
16:59 < dreszka> i have a question for bermi, but it's out of context, so i'll wait a little
16:59 < dreszka> (related to sintags)
16:59 < bermi_> I'll wait
16:59 < dreszka> thanks
17:00 < bermi_> #akelos
17:00 < dreszka> ah ok
17:00 < vmx> i've also an really of topic question. may we end the meeting?
17:00 < dreszka> thanks
17:00 < jfhv> So we wait for Bermi's code in the trunk, or can we start documenting the code?
17:01 < bermi_> yes we can end now, I had trouble with the new toggle effect and the Xhtml parser :(
17:01 < vmx> jfhv: you can start on parts that won't change
17:02 < bermi_> you can document everything but xhtml functions
17:02 < vmx> bermi: with internet explorer?
17:02 < bermi_> FF Mac
17:03 < vmx> bermi: you still have problems?
17:04 < bermi_> yes, but I'll go deeper next wednesday night
17:04 < bermi_> I don't have time now
17:05 < vmx> it might be caused by the expandos used be jquery
17:06 < bermi_> I get the error at jquery line 440
17:06 < vmx> if there#s a problem and you've using native javascript, try to use the jquery euqivalent
17:06 < bermi_> I dig deeper
17:07 < bermi_> see you all, bye!
17:07 < vmx> cu
17:07 < jfhv> OK. Thanks for the meeting. Bye!