Re: [Framework-Team] Plone 4 - holidays are over :)
On Mon, Jan 4, 2010 at 6:36 PM, Eric Steele ems...@psu.edu wrote: 2) We *really* need to move away from this whole limi's theme thing where Alex is the point-of-failure for anything template/design related. Agreed. Denys has been picking up this, but anyone should feel free to help out. My main concern at the moment is the state of TinyMCE, I'll see if we can get some traction on this over the weekend with Rob and Sisi. I have been useless over the past week since I'm home sick, but And on points 2 and 4...what does the UI team do these days, do we still have one? I've been silently trying to bootstrap a new one (mostly for Plone 5), and I have rallied them to get Plone 4 beta in shape. Currently my list is Rob, Denys, Sisi — other suggestions welcome. Spare time and follow-through more important than skills (which can be learned ;). -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4 - holidays are over :)
Regarding the AJAX dialog problems, I just haven't gotten to those because of holiday busyness. I've watched them as they've come in, and they all look like they should be easily fixable. I'll make every effort to get to them soon! I've mainly been checking with Eric on which dialogs would benefit from AJAX. This is all convenience work, so if there's any dialog that is resistant to full fixup, we can easily omit it from the AJAX handling. All of these are set up in a single js file that's part of CMFPlone. Steve On Mon, Jan 4, 2010 at 11:42 AM, Hanno Schlichting ha...@hannosch.euwrote: Heya. Some of us have been busy over the holiday season and worked a bit more on Plone 4. The next question now is: ... JS dialogs #9805, #9806, #9921, #9693, #9957, #9964, #9977 All of these essentially mean that an operation done in a pop-up doesn't redirect and reload a new page. So any kind of feedback (positive, reconfirmation and failures) is lost. The other problem is that the original page (shown in the background of the dialog) might show information that is changing as a result of the dialog action. For example publishing an object in a dialog, needs to refresh the page, as its workflow state needs to be reflected, the item might now show up in the navigation tree, a calendar or any other type of portlet. It's a bit sad to see these problems, as we have already encountered all of them, when first applying AJAX/KSS in the early Plone 3 stages. We ended up reverting to a non-AJAX UI for most things, as almost all of our UI actions can have arbitrary effects. I'm afraid that we need to re-evaluate all actions that use the new dialogs and discuss them. We haven't had a PLIP review of the individual dialogs. I think we have missed to pass on the hard earned knowledge learned from the early Plone 3.0 days, but luckily it's not too late. ...__ _ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4 - holidays are over :)
On Jan 6, 2010, at 2:02 PM, Steve McMahon wrote: Regarding the AJAX dialog problems, I just haven't gotten to those because of holiday busyness. I've watched them as they've come in, and they all look like they should be easily fixable. I'll make every effort to get to them soon! I've mainly been checking with Eric on which dialogs would benefit from AJAX. This is all convenience work, so if there's any dialog that is resistant to full fixup, we can easily omit it from the AJAX handling. All of these are set up in a single js file that's part of CMFPlone. Steve Thanks for the update, Steve. Let me know if there's anything I can do to help. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 4 - holidays are over :)
Heya. Some of us have been busy over the holiday season and worked a bit more on Plone 4. The next question now is: What is missing for a beta release? I'll allow myself to give my opinion on that. Eric feel free to disagree, it's your call :) In general I think Plone 4 is in good overall shape. But there's some blockers and critical issues noted in the bug tracker, which we need to address. I cleaned up Trac, so the 4.0 milestone only has tickets which are new to Plone 4.0 and should *all* be resolved before a release candidate. But here's the list of things that we need to tackle, before we can label a release beta in my opinion: Unified folders #9912, #9791 This comes down to: What to do with the Large Plone Folder during upgrades. To actually unify folders, we need to migrate all existing large folders to the new unified type. From what I understand that type should have an option in its schema, that allows to turn on/off the orderability. When migrating large folders, orderability should be turned off. Currently the large folders are left as is and we don't have such an option in the schema. TinyMCE vs. Kupu #9945, #9783, #9877, #9949, #9956, #9976, #9637, #9958 Overall we always have many issues with our visual editor. Kupu is far from being problem-free, so we cannot expect TinyMCE to suddenly be all perfect. So I wouldn't call all of the listed tickets critical. But one really critical problems is, that TinyMCE doesn't work well enough in Safari/Chrome to give it to normal users. The proposed solution is to install both Kupu and TinyMCE by default and force Kupu for all Safari/Chrome users. Kupu has such a browser detection logic, as it also didn't work with Safari for a long time. It did a fallback on a plain textarea, but we can do better today having two editors with different browser coverage. Sunburst (or themes in general) There's quite a number of open tickets in the Templates/CSS component. For some parts of the UI, there's currently no styling information. While we can fix some of those during the beta cycle, I think we should fix everything that requires changes to main_template or needs new viewlet managers and the like before a beta release. Noteworthy are #9278, #9995 and #8805 (don't ship with NuPlone anymore). JS dialogs #9805, #9806, #9921, #9693, #9957, #9964, #9977 All of these essentially mean that an operation done in a pop-up doesn't redirect and reload a new page. So any kind of feedback (positive, reconfirmation and failures) is lost. The other problem is that the original page (shown in the background of the dialog) might show information that is changing as a result of the dialog action. For example publishing an object in a dialog, needs to refresh the page, as its workflow state needs to be reflected, the item might now show up in the navigation tree, a calendar or any other type of portlet. It's a bit sad to see these problems, as we have already encountered all of them, when first applying AJAX/KSS in the early Plone 3 stages. We ended up reverting to a non-AJAX UI for most things, as almost all of our UI actions can have arbitrary effects. I'm afraid that we need to re-evaluate all actions that use the new dialogs and discuss them. We haven't had a PLIP review of the individual dialogs. I think we have missed to pass on the hard earned knowledge learned from the early Plone 3.0 days, but luckily it's not too late. User / Group handling #9789, #9966, #5548, #9743, #9898, #9777, #9710, #9732, #9955, #9960, #9742, #9748 There's a ton of problems with the various new user and groups templates and related password handling functionality. If we want to claim that we improved anything in this regard (as our PLIP's claim) we need to fix this stuff. Not all of this needs to be fixed before a beta, but we need to get some good progress on these or they'll never be done. Otherwise we have some issues related to the installers. I just refactored a large part of the zope2instance recipe, which might have broken things in the installers. I didn't test the new changes on Windows yet, so the current recipe trunk quite definitely some issues. I'll fix these during this week. Finally there is one open PLIP (https://dev.plone.org/plone/ticket/9314) about the Developer Pack for the installers. I have no idea what the status on this one is. Personally I disagree with some of the choices mentioned in the PLIP (like shipping the unmaintained Clouseau, using eggtractor where buildout covers the same use-case today, turning on debug-mode in zope.conf, which should only be done via bin/instance fg vs. bin/instance console). It would be good to get an idea what the current status of this is and how it is implemented. Looking at this there's still a ton to do. I'll leave it to Eric to figure out whom to encourage to get these things done ;-) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org
Re: [Framework-Team] Plone 4 - holidays are over :)
On Jan 4, 2010, at 2:42 PM, Hanno Schlichting wrote: Heya. Some of us have been busy over the holiday season and worked a bit more on Plone 4. The next question now is: What is missing for a beta release? I'll allow myself to give my opinion on that. Eric feel free to disagree, it's your call :) In general I think Plone 4 is in good overall shape. But there's some blockers and critical issues noted in the bug tracker, which we need to address. I cleaned up Trac, so the 4.0 milestone only has tickets which are new to Plone 4.0 and should *all* be resolved before a release candidate. But here's the list of things that we need to tackle, before we can label a release beta in my opinion: ...big snip... Looking at this there's still a ton to do. I'll leave it to Eric to figure out whom to encourage to get these things done ;-) Hanno Thanks Hanno. I've been slogging through the changelogs trying to get caught up on what's been done over the last two weeks. Between whatever plague it was that I contracted in late December and the holidays, I've been mostly useless lately. We're definitely close. I'd love to see a beta out by the 18th. I'll start rounding up people to get the worst of it cleaned up. There's a lot above to address, so I'll just make a few points: 1) I've got people (including myself) on most of the user/groups stuff. Some of that needs to be aired out here, which I'll do tomorrow. 2) We *really* need to move away from this whole limi's theme thing where Alex is the point-of-failure for anything template/design related. These are the most visible and obvious bugs and though they're not necessarily the most critical, they're the ones that leave the biggest impression of our doneness. Denys has been picking up some the slack, but I'd like to find 1-3 more people willing to have at it. 3) /me clears his throat in witsch's general direction ;) 4) I'll talk with Steve about the JS issues. He's got quite a lot of tickets assigned at the moment, so I'm guessing he could use some help. Just a cursory look at the problem leads me to think there's a generally easy way of fixing it across the board, but also a nicer, one-less-page-load way that would be much more involved. And on points 2 and 4...what does the UI team do these days, do we still have one? Oh, and you said... Personally I disagree with some of the choices mentioned in the PLIP (like shipping the unmaintained Clouseau, using eggtractor where buildout covers the same use-case today, turning on debug-mode in zope.conf, which should only be done via bin/instance fg vs. bin/instance console) A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
