On Fri, Aug 24, 2007 at 09:43:18AM -0400, Richard Heck wrote:
> Andre Poenitz wrote:
> >>If people really want me to change all of these, I'll do so. But this
> >>was modeled on the existing Layout_ptr.
> >>
> >I guess I'll just rename Layout_ptr into LayoutPtr to avoid this in the
> >furture.
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
(iii) remember layout base class _and_ module in BufferParams.
Maybe the solution is to have a global TextClassModule along the
global TextClassList instead of having local copies of TextClass?
Or integrate the module acces
Andre Poenitz wrote:
If people really want me to change all of these, I'll do so. But this
was modeled on the existing Layout_ptr.
I guess I'll just rename Layout_ptr into LayoutPtr to avoid this in the
furture.
I'll change TextClass_ptr to TextClassPtr later. I don't want to do it
now
On Thu, Aug 23, 2007 at 10:50:41AM -0500, Bo Peng wrote:
> > Sure...though I can't promise competence with minizip, etc.
>
> No. You do not have to worry about minizip. No one understands that
> part of the code. Use zipFiles and unzipToDir as two black boxes.
>
> > There's no feature yet. I'm tr
On Thu, Aug 23, 2007 at 11:40:08AM -0400, Richard Heck wrote:
> Bo Peng wrote:
> >In my institution, because few people are willing to review others'
> >grant, there is a submit one, review one policy. If we adopt this rule
> >here, you should go ahead and review my Embedding patch. :-)
> >
> Sur
Andre Poenitz wrote:
> I too.
>
> Andre'
You tooed too much already!
A/
On Wed, Aug 22, 2007 at 11:03:24PM -0500, Bo Peng wrote:
> In my institution, because few people are willing to review others'
> grant, there is a submit one, review one policy. If we adopt this rule
> here, you should go ahead and review my Embedding patch. :-)
>
> First, could you disclose a lit
Abdelrazak Younes wrote:
Previously, it just held an index into TextClassList, and extending
that would lead to solution (i). I suppose you could have some kind
of next TextClass-thingy that kept a list of modules that are in use.
But that presumes that the contents of the modules don't change
Abdelrazak Younes wrote:
Richard Heck wrote:
(iii) remember layout base class _and_ module in BufferParams. Maybe
the solution is to have a global TextClassModule along the global
TextClassList instead of having local copies of TextClass? Or
integrate the module access to the TextClassList its
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
The pointer in question is a boost::shared_ptr. This is needed
because CutAndPaste saves a copy of the layout with each cut or
copied selection. We cannot assume the selection vanishes when the
document is closed, so there are t
Bo Peng wrote:
There's no feature yet. I'm trying to follow the "divide your patch into
logical bits" rule. This one just reworks the infrastructure to prepare
for modules, which will come next.
I was asking for a big picture.
Oh, yes, then: There'll be a UI, and two LFUNs: clear-modules
Abdelrazak Younes wrote:
Richard Heck wrote:
The pointer in question is a boost::shared_ptr. This is needed
because CutAndPaste saves a copy of the layout with each cut or
copied selection. We cannot assume the selection vanishes when the
document is closed, so there are two options: (i) keep
> Sure...though I can't promise competence with minizip, etc.
No. You do not have to worry about minizip. No one understands that
part of the code. Use zipFiles and unzipToDir as two black boxes.
> There's no feature yet. I'm trying to follow the "divide your patch into
> logical bits" rule. This
Bo Peng wrote:
In my institution, because few people are willing to review others'
grant, there is a submit one, review one policy. If we adopt this rule
here, you should go ahead and review my Embedding patch. :-)
Sure...though I can't promise competence with minizip, etc.
First, could you
Richard Heck wrote:
The pointer in question is a boost::shared_ptr. This is needed because
CutAndPaste saves a copy of the layout with each cut or copied
selection. We cannot assume the selection vanishes when the document is
closed, so there are two options: (i) keep a list of all the layouts
Richard Heck wrote:
Andre Poenitz wrote:
On Wed, Aug 22, 2007 at 07:44:17PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
Looks good in general.
Good.
I find the naming TextClass_sptr exceptionally ugle (CamelBump and
under_score mixed), but I know there are unfortunate precenden
On Wed, Aug 22, 2007 at 07:03:50PM -0400, Richard Heck wrote:
> This is one of a series of patches that will merge the layout modules
> development in personal/branches/rgheck back into the tree.
...
> Index: src/BufferParams.h
> =
In my institution, because few people are willing to review others'
grant, there is a submit one, review one policy. If we adopt this rule
here, you should go ahead and review my Embedding patch. :-)
First, could you disclose a little bit how to use this feature? Is
there a GUI to add modules?
Andre Poenitz wrote:
On Wed, Aug 22, 2007 at 07:44:17PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
Looks good in general.
Good.
I find the naming TextClass_sptr exceptionally ugle (CamelBump and
under_score mixed), but I know there are unfortunate precendents
(Layout_ptr). I
On Wed, Aug 22, 2007 at 07:44:17PM -0400, Richard Heck wrote:
> Andre Poenitz wrote:
> >The file TextClass_sptr.h seems to be missing from the patch?
> >
> Yes, sorry. Here it is.
Looks good in general.
I find the naming TextClass_sptr exceptionally ugle (CamelBump and
under_score mixed), but I
Andre Poenitz wrote:
The file TextClass_sptr.h seems to be missing from the patch?
Yes, sorry. Here it is.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
On Wed, Aug 22, 2007 at 07:03:50PM -0400, Richard Heck wrote:
> This is one of a series of patches that will merge the layout modules
> development in personal/branches/rgheck back into the tree.
>
> Design goal: Allow the use of layout "modules", which are to LaTeX
> packages as layout files ar
This is one of a series of patches that will merge the layout modules
development in personal/branches/rgheck back into the tree.
Design goal: Allow the use of layout "modules", which are to LaTeX
packages as layout files are to LaTeX document classes. Thus, one could
have a module that define
23 matches
Mail list logo
