* Michael A. Koziarski <[EMAIL PROTECTED]> [010329 10:14]:
> I've rewritten the credits dialog. In order to get the program to
> compile I also had to hack configure.in.
Did you update from cvs?
configure.in was patched already to link libglade for gnome.
> I haven't formatted the info yet (to
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| I mentioned it, but I don't know what the best file to check for might
| be.
| Configure currently checks for lyx.C, which went away. Only the shadow
| knows.
| Garst
src/main.C
--
Lgb
On Wednesday 28 March 2001 21:42, Garst R. Reese wrote:
> The problem is that configure checks for lyx.C and lyx.C is no longer
> pertinent.
> I changed configure to look for lyxfind.C and it configured. Running
> make now.
Many thanks, Garst, for tracking this down. I've just commited the fix.
A
Looks good! I'll have a play.
Angus
On Wednesday 28 March 2001 18:32, Baruch Even wrote:
> >
> Attached is a patch I prepared to refactor the ButtonControllerBase
> hierarchy. The idea is to gather the similar in gnomeBC, xformsBC and
> kdeBC into one thing, currently there is code duplication
Well apart from the obvious, "you could put some of this in a base class and
forget about it", how about:
void FormCredits::build()
{
dialog_.reset(dialog());
ok()->clicked.connect(SigC::slot(this, &FormCredits::OKClicked));
std::stringstream ss;
- controller(
Hi,
I am using LyX on a daily basis writing linguistic reports and stuff. I
use the "cgloss4e" and "gb4e" LaTeX-packages and it works well. However,
I am not very pleased with the way I have to squeeze LaTeX-code into my
documents. I have written a special layout for my needs, but I think
that th
On Wed, 28 Mar 2001, Kayvan A. Sylvan wrote:
> On Thu, Mar 29, 2001 at 05:18:31PM +1000, Allan Rae wrote:
> >
> > You should be able to :
> > rm -f po/POTFILES*
> > make
> >
> > to get around this unless of course there's a Makefile.am somewhere that
> > still lists these files.
>
> The
Kalle Dalheimer and I have been having a discussion about possible ways
forward with the GUI-I stuff. Thought you might be interested (and of course,
I'll be able to find this on the archive in future!)
Feel free to comment...
A
Angus> Incidentally, how do you find the new scheme?
Angus> Any
On Thu, 29 Mar 2001, Angus Leeming wrote:
> Well apart from the obvious, "you could put some of this in a base class and
> forget about it", how about:
The refactoring (put some of this in a base class and forget about it), is
something that is needed, but I first want to get us down a few dial
It seems to me that having 5 implementations in one file separated by
#ifndef's is not a good idea. I'd rather see 5 different implementation
files. Not only will the code be cleaner, but I also like the idea of having
the xform code in the xform dir, the qt code in the qt dir, etc.
Although n
> Kalle> What could be done would be something like this:
>
> #ifdef XFORMS
> typedef FL_OBJECT* WidgetPtr;
> #elif defined QT
> typedef QWidget* WidgetPtr;
> #endif
This should get encapsulated in a real class, say "Widget", with different
implementaions for Qt, xforms, etc.
> K
On Thursday 29 March 2001 14:28, Edwin Leuven wrote:
> It seems to me that having 5 implementations in one file separated by
> #ifndef's is not a good idea. I'd rather see 5 different implementation
> files. Not only will the code be cleaner, but I also like the idea of
> having the xform code in
On Wednesday 28 March 2001 18:32, Baruch Even wrote:
> Attached is a patch I prepared to refactor the ButtonControllerBase
> hierarchy. The idea is to gather the similar in gnomeBC, xformsBC and
> kdeBC into one thing, currently there is code duplication in them.
>
> However when compiling with e
Wow a trip down memory lane...
On Thu, 29 Mar 2001, Andre Poenitz wrote:
> > Kalle> What could be done would be something like this:
> >
> > #ifdef XFORMS
> > typedef FL_OBJECT* WidgetPtr;
> > #elif defined QT
> > typedef QWidget* WidgetPtr;
> > #endif
>
> This should get encapsul
> Suggested/rejected GUII implementation number two. Both of the above
> cases just end up being yet another restrictive cross-platform toolkit.
> We don't need that. If you want one of those then just create a port to
> the cross-platform toolkit of your choice and use that.
Oh, I did not sugge
On Wed, 28 Mar 2001 [EMAIL PROTECTED] wrote:
> figureForm.C figureForm.h figure_form.C figure_form.h
> Removed Files:
> form1.C form1.h lyx.C lyx.h
> Log Message:
> Stripped out FD_form_figure code into figureXXX.[Ch] files.
yikes, I hope you didn't spend long on this ... I thought
On Thu, 29 Mar 2001, Andre Poenitz wrote:
> > Suggested/rejected GUII implementation number two. Both of the above
> > cases just end up being yet another restrictive cross-platform toolkit.
> > We don't need that. If you want one of those then just create a port to
> > the cross-platform toolki
On Thu, 29 Mar 2001, Allan Rae wrote:
> Still tripping down memory lane...
>
> Suggested/rejected GUII implementation number two. Both of the above
> cases just end up being yet another restrictive cross-platform toolkit.
> We don't need that. If you want one of those then just create a port to
Attached is a patch that implements a controller-view split of the External
Material popup.
However, I don't use the inset and don't have any of the supported programs
installed, so my ability to test my patch is limited.
Would someone out there take up the batton?
Many thanks,
Angus
exter
I guess that this is directed mainly at Lars,
frontends/xforms/FormToc.C is full of #if... #else... #endif statements. So,
the questions are:
* what needs to be done to the new code to bring it up to standard?
* The new code seems to work to me. Can I strip out the old code?
Angus
FormToc.
* Angus Leeming <[EMAIL PROTECTED]> [010329 16:15]:
> On Wednesday 28 March 2001 18:32, Baruch Even wrote:
> > Attached is a patch I prepared to refactor the ButtonControllerBase
> > hierarchy. The idea is to gather the similar in gnomeBC, xformsBC and
> > kdeBC into one thing, currently there is
Please note that something freaky is going on with the Browse button, but I'm
dealing with this in another popup and will apply the fix here once I've
found it.
Angus
On Thursday 29 March 2001 15:43, Angus Leeming wrote:
> > Attached is a patch that implements a controller-view split of the
Angus Leeming <[EMAIL PROTECTED]> writes:
| I guess that this is directed mainly at Lars,
|
| frontends/xforms/FormToc.C is full of #if... #else... #endif statements. So,
| the questions are:
|
| * what needs to be done to the new code to bring it up to standard?
|
| * The new code seems to
Baruch, I've discovered a small but crucial bug in your ButtonController
stuff:
void GuiBC::refresh()
{
...
// Enable/Disable read-only handled widgets.
if (!read_only_.empty()) {
- bool const enable = bp().isReadOnly();
+ bool const enable =
Ok! False alarm. The bug was in the ButtonController, not in this patch.
Please, please please test it to destruction.
Angus
On Thursday 29 March 2001 16:33, Angus Leeming wrote:
> Please note that something freaky is going on with the Browse button, but
I'm
> dealing with this in another po
On Thursday 29 March 2001 16:04, Baruch Even wrote:
> I'm not sure regarding the cancel button, the reason I took my approach
> is that I want to use stock buttons and not just to rename the button
> (stock buttons also have a special icon for them).
>
> Maybe instead of having the names passed f
* Angus Leeming <[EMAIL PROTECTED]> [010329 18:29]:
> Baruch, I've discovered a small but crucial bug in your ButtonController
> stuff:
>
> void GuiBC::refresh()
> {
> ...
>
> // Enable/Disable read-only handled widgets.
> if (!read_only_.empty()) {
> - bool const
On Thu, Mar 29, 2001 at 08:54:15PM +1000, Allan Rae wrote:
> To avoid this problem affecting your builds you can change your script
> from:
> make rpmdist
>
> to
> rm -f po/POTFILES*
> make rpmdist
This is what I already do.
> This can't fail because POTFILES can safely be reb
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| I have verified that POTFILES.in is not necessary in the CVS. Someone
| can go ahead and remove it.
I am not convinced.
--
Lgb
On Thu, Mar 29, 2001 at 06:50:16PM +0200, Lars Gullik Bjønnes wrote:
> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
>
> | I have verified that POTFILES.in is not necessary in the CVS. Someone
> | can go ahead and remove it.
>
> I am not convinced.
Look at po/Makefile.in:
${srcdir}/POTFILES.i
* Angus Leeming <[EMAIL PROTECTED]> [010329 16:15]:
> On Wednesday 28 March 2001 18:32, Baruch Even wrote:
> > Attached is a patch I prepared to refactor the ButtonControllerBase
> > hierarchy. The idea is to gather the similar in gnomeBC, xformsBC and
> > kdeBC into one thing, currently there is
On Thursday 29 March 2001 19:21, Baruch Even wrote:
> * Angus Leeming <[EMAIL PROTECTED]> [010329 16:15]:
> > On Wednesday 28 March 2001 18:32, Baruch Even wrote:
> > > Attached is a patch I prepared to refactor the ButtonControllerBase
> > > hierarchy. The idea is to gather the similar in gnomeBC
On Thu, Mar 29, 2001 at 03:43:36PM +0100, Angus Leeming wrote:
> Attached is a patch that implements a controller-view split of the External
> Material popup.
>
> However, I don't use the inset and don't have any of the supported programs
> installed, so my ability to test my patch is limited.
On 29 Mar 2001, Lars Gullik Bjønnes wrote:
> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
>
> | I have verified that POTFILES.in is not necessary in the CVS. Someone
> | can go ahead and remove it.
>
> I am not convinced.
make maintainer-clean
./autogen.sh
rm -f po/POTFILES*
./configure
make
Attached is a patch to fix a couple of memory leaks, I'll also attach
the report of LeakTracer, it includes various Mathed leaks and two
non-mathed leaks.
In the fix I provide there is a "fix" for the leak in the idex, this is
not really a fix as it is a way to hide the problem from LeakTracer.
On 30-Mar-2001 Baruch Even wrote:
> Attached is a patch to fix a couple of memory leaks, I'll also attach
> the report of LeakTracer, it includes various Mathed leaks and two
> non-mathed leaks.
>
> In the fix I provide there is a "fix" for the leak in the idex, this is
> not really a fix as it
On 30-Mar-2001 Juergen Vigna wrote:
> I don't like patches which change intentation! (especially if the whole
^indentation
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED
37 matches
Mail list logo
