not all are empty (diaprint_callbacks.c). Well, the rest are empty, that's
true. In general, more complex dialogs will require some callbacks. I
think that if we will remove these (empty) files then we will have to
postprocess Glade-generated _interface files which include _callbacks.
I
On Fri, 18 Aug 2000, Juergen Vigna wrote:
I guess the callbacks should go into the FormXxx files and so we can
remove this additional files and yes we have to postprocess the .[ch]
files I've seen that already, so if you move the callbacks you use into
the FormXxx implementation I see then
I think that the problem is in the way LyX calls "update" function. For
example, when I press "Undo" in the menu, the "Redo" command is still
disabled. I have to move and click mouse in LyX working area to get it
enabled. I would predict, that the toolbar should have the similar
behavior.
I'll move the callbacks to FormXxx (actually, FormPrint is the only one
that needs it).
Good than we can remove the unneeded files!
Generally, glade produces this file for every project. However, as far as
I have seen it is almost identical each time. You can desire not to
produce
If it's always identical we could just modify it and leave it there as a
class helper function.
true
Well I tracked this down till LyXView::showState which updates the right
things and the toolbar than is updated. If showState is not called there
is no update at all! IMO there has some
Well, I can't reproduce it (or I don't undestand how I can get into this
"tabular" thing :) ). However, if you know any LyX action which changes
its state after you enter tabular from "plain action" to action which can
be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should
On Fri, 18 Aug 2000, Juergen Vigna wrote:
Well, I can't reproduce it (or I don't undestand how I can get into this
"tabular" thing :) ). However, if you know any LyX action which changes
its state after you enter tabular from "plain action" to action which can
be toggled
On 18-Aug-2000 Marko Vendelin wrote:
Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and
LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the
responsibility of the programmer that implements some new action to define
its state this way (we can use
>
> not all are empty (diaprint_callbacks.c). Well, the rest are empty, that's
> true. In general, more complex dialogs will require some callbacks. I
> think that if we will remove these (empty) files then we will have to
> postprocess Glade-generated _interface files which include _callbacks.
On Fri, 18 Aug 2000, Juergen Vigna wrote:
> I guess the callbacks should go into the FormXxx files and so we can
> remove this additional files and yes we have to postprocess the .[ch]
> files I've seen that already, so if you move the callbacks you use into
> the FormXxx implementation I see
> I think that the problem is in the way LyX calls "update" function. For
> example, when I press "Undo" in the menu, the "Redo" command is still
> disabled. I have to move and click mouse in LyX working area to get it
> enabled. I would predict, that the toolbar should have the similar
>
>
> I'll move the callbacks to FormXxx (actually, FormPrint is the only one
> that needs it).
>
Good than we can remove the unneeded files!
>
> Generally, glade produces this file for every project. However, as far as
> I have seen it is almost identical each time. You can desire not to
>
> If it's always identical we could just modify it and leave it there as a
> class helper function.
true
> Well I tracked this down till LyXView::showState which updates the right
> things and the toolbar than is updated. If showState is not called there
> is no update at all! IMO there has
>
> Well, I can't reproduce it (or I don't undestand how I can get into this
> "tabular" thing :) ). However, if you know any LyX action which changes
> its state after you enter tabular from "plain action" to action which can
> be toggled (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you
On Fri, 18 Aug 2000, Juergen Vigna wrote:
> >
> > Well, I can't reproduce it (or I don't undestand how I can get into this
> > "tabular" thing :) ). However, if you know any LyX action which changes
> > its state after you enter tabular from "plain action" to action which can
> > be toggled
On 18-Aug-2000 Marko Vendelin wrote:
>
> Hmm. Can't we have LyXFunc::Disabled | LyXFunc::ToggleOn and
> LyXFunc::Disabled | LyXFunc::ToggleOff ? This means that it is the
> responsibility of the programmer that implements some new action to define
> its state this way (we can use
Hi!
Hi Marco!
this patch ports two more dialogs to Gnome frontend. I've also included
all glade project files that were used for all ported dialogs. It would be
nice to have these files in CVS too.
I had a look at the patch and the files and have some more comments ;)
- I've seen that
On Thu, 17 Aug 2000, Juergen Vigna wrote:
I had a look at the patch and the files and have some more comments ;)
- I've seen that the *callbacks.c files are just empty containers and IMO
they should be removed as they are not needed.
not all are empty (diaprint_callbacks.c). Well, the
> Hi!
>
Hi Marco!
> this patch ports two more dialogs to Gnome frontend. I've also included
> all glade project files that were used for all ported dialogs. It would be
> nice to have these files in CVS too.
>
I had a look at the patch and the files and have some more comments ;)
- I've
On Thu, 17 Aug 2000, Juergen Vigna wrote:
> I had a look at the patch and the files and have some more comments ;)
>
> - I've seen that the *callbacks.c files are just empty containers and IMO
> they should be removed as they are not needed.
not all are empty (diaprint_callbacks.c). Well,
20 matches
Mail list logo
