On 01/26/2010 03:14 PM, Guillaume Lerouge wrote: > The fact that currently panels are not the same in edit& view mode and the > fact that users can configure view panels as they see fit but not edit > panels is a usability problem too. Panels can be useful but it doesn't mean > they're used to the best effect right now. Additionally, some panels are > plain obnoxious (especially the translation& tags ones).
Yes, this too is a good reason for discarding the edit panels. Several users have asked about changing the edit panels in the past. > Although I like the way Sergiu's suggestions are going, I agree with Vincent > that this is major work that we can't possibly try making fit in XE 2.2 now > without postponing the release& introducing a lot of instability. We have > already introduced risk with Vincent's refactoring. I'm aware that some > community members are looking forward to the WCAG / accessibility > improvements we brought in XE 2.2 and I think it would be safer to provide a > version that introduces them without re-hauling the whole XWiki Edit > interface. > > Last but not least, these proposals have been discussed very little on the > list so far and could benefit from additional refinements. Waiting for XE > 2.3 would give us more time to make it work just right. I agree. >> PS: It's really cool to look for new ideas. I just hope you haven't started >> coding it too much. It would have been better to propose it earlier so that >> we could have discussed it, not causing extra work for Marta and you. >> PPS: In your mail you haven't explained why you wanted to have panelless >> edits. Could you explain? >> > > My personal take on this is that panelless edit would open the way to make > inline edition a reality in XWiki. In practice this would mean that the > content area (contentview.vm) could be replaced with the edit area while > everything else would remain the same on the page (header, footer, panels). > We could also load the edit part dynamically via AJAX, improving the speed > and thus the perceived performance for the user. > > Last but not least, this would also bring us closer to unifying the edit& > inline mode, which I believe would make XWiki more appealing for application > developers. I've been developing applications lastly by adding metadata > right above and under the content area in contentview.vm and being able to > use the native XE content area& edit mode without mixing edit& inline is > great and makes for a smoother user experience. I see Sergiu's proposal as a > first and significant step in that direction and I think it's maybe actually > not ambitious enough rather than the other way round ;-) Exactly. > > PS: Sergiu, I know all this would be much nicer if we were using Git and you > could implement it in your own branch and share it whith whomever developer > pleased you. Maybe this could be the right time to explore once again how > XWiki development could take place using Git? Well, a first step would be to have something like this: - keep the SVN repo as the main repo - add a git central repo that devs and users can push to - this git repo is configured as a SVN clone - the master branch automatically pushes to the SVN trunk any new commit - we can do the same for the equivalent of SVN branches - git automatically fetches updates from the SVN repo - configure rights so that developers can push changes to any branch - configure rights so that any user can have his own branch where only he and the developers can commit This means that devs can work both with the SVN and the git repo, as they wish, giving us the freedom to test git instead of suddenly switching to it. This also makes it easier for users to contribute and feel more involved. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
