Hi, On Thu, May 07, 2015 at 10:46:51AM +0200, Jan Holesovsky wrote: > Frm -> Frame (to handle things like SwFrm, SwCellFrm, SwRowFrm, > SwColumnFrm, ..., SwFrmFmt, FrmMap, SwFlyFrm, etc.)
IMHO lets leave Frm -> Frame out of the change in this round. In the end, we should have the SwFrm/sw::Frame situation sorted out in a consistent way, ideally with most of the Writer stuff actually namespaced in sw. As such I'd propose to do this round with all the nonconflicting stuff (Fmt, Cntnt, Txt, Fld, Ftn, Updt, Fml, Hnt) and leave Frm as is. Lets also see how painful those others are on their own. Later (next major release), we could then do a followup with the goal to: - put as much in a sw namespace as possible - solve the sw::Frame, SwFrm (and whatever other Frames we have flying around) conflict along the way I'd like to avoid a situation, where we need a cheatsheet to map sw::Frame to different things in three different releases, so lets do all the easy stuff first, and then solve the Frms/Frames/whatever in one batch later. > I deliberately leave out eg. Cnt (usually Count, but could be Content by > mistake), or PaM (as PointAndMark would be too long - but I think it > would deserve some better name too). So, PaM would need a _very good_ replacement. Its a sufficiently synthetic concept and all candidates for replacement e.g. "Cursor", "Selection" are already widely used, overloaded with meaning and thus might cause more conflict and confusion. If we dont find a good name for PaM, better leave it as is and rather document it better. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
