RE: Gnome: FormToc FormIndex
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 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 to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) - would it be possible to postprocess the .[ch] files so that we can get .[Ch] files as we do with fdesign generated files? (I would help to implement this if you like it!) In all computers that I've seen, gcc compiles files faster than g++. Do we need to have compilation times longer? :) Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) - what is this support.[ch] is it always generated by glade? yes. at least one function is used by me directly: lookup_widget. Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? This is much better implementation. Should I change it or you will make it? Well it's your baby :) - I will also have a look why some menu-items are never enabled and/or displayed wrong. Is it Gnome-specific or the same trouble is with XForms implementation? This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We don't believe in rheumatism and true love until after the first attack. -- Marie Ebner von Eschenbach
RE: Gnome: FormToc FormIndex
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 to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) I'll move the callbacks to FormXxx (actually, FormPrint is the only one that needs it). In all computers that I've seen, gcc compiles files faster than g++. Do we need to have compilation times longer? :) Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) I'm eager to hear it. Or is it FAQ-type question and I should look into developers-FAQ? - what is this support.[ch] is it always generated by glade? yes. at least one function is used by me directly: lookup_widget. Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? 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 this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. This is much better implementation. Should I change it or you will make it? Well it's your baby :) I'll patch it. This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) 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. Marko
RE: Gnome: FormToc FormIndex
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. Undo/Redo problem disappeared when I called update() after executing LyX action in "void Menubar::Pimpl::callback(int action)". However, I don't think that this is the right place to do so. Marko
RE: Gnome: FormToc FormIndex
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 this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. If it's always identical we could just modify it and leave it there as a class helper function. 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. 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 logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Hire the morally handicapped.
RE: Gnome: FormToc FormIndex
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 logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) I suppose that we need to call update after each action is executed regardless of the source of the action (menu, toolbar, pipe). Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? 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 know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? Marko
RE: Gnome: FormToc FormIndex
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 know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
RE: Gnome: FormToc FormIndex
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 (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! 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 LyXFunc::ToggleOff as the default for this kind of actions). Marko
RE: Gnome: FormToc FormIndex
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 LyXFunc::ToggleOff as the default for this kind of actions). I guess you got me here I'll try to have a look at this :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dammit Jim, I'm an actor, not a doctor.
RE: Gnome: FormToc & FormIndex
> > 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 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 to get rid of the #includes in the interface files and we should make a Makefile in the dialogs-directory which can produce the right files and postprocess them automatically (if I'm not mistaken glade has some sort of export option at least I've seen this in the archimedes project) > >> - would it be possible to postprocess the .[ch] files so that we can get >> .[Ch] files as we do with fdesign generated files? (I would help to >> implement this if you like it!) > > In all computers that I've seen, gcc compiles files faster than g++. Do we > need to have compilation times longer? :) > Well I let Allan or others explain why they would like .C files instead of .c files I'm not the expert here #:O) >> - what is this support.[ch] is it always generated by glade? > > yes. at least one function is used by me directly: lookup_widget. > Yes but is this generated for each .glade file you process or do you have to call glade with some special option to process it? And does glade use this then or you have to use the functions for your implementation? > > This is much better implementation. Should I change it or you will make > it? Well it's your baby :) > >> - I will also have a look why some menu-items are never enabled and/or >> displayed wrong. > > Is it Gnome-specific or the same trouble is with XForms implementation? This is Gnome-specific, I had a look and there is some problem with the update of the menus. While in the xforms part the menu is rebuild when I press on a menu-button this does not happen in gnome. I will have a better look but you should try too as you know better than me how gnome-menus work ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We don't believe in rheumatism and true love until after the first attack. -- Marie Ebner von Eschenbach
RE: Gnome: FormToc & FormIndex
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 to get rid of the #includes in > the interface files and we should make a Makefile in the dialogs-directory > which can produce the right files and postprocess them automatically > (if I'm not mistaken glade has some sort of export option at least I've > seen this in the archimedes project) I'll move the callbacks to FormXxx (actually, FormPrint is the only one that needs it). > > In all computers that I've seen, gcc compiles files faster than g++. Do we > > need to have compilation times longer? :) > > Well I let Allan or others explain why they would like .C files instead of > .c files I'm not the expert here #:O) I'm eager to hear it. Or is it FAQ-type question and I should look into developers-FAQ? > >> - what is this support.[ch] is it always generated by glade? > > > > yes. at least one function is used by me directly: lookup_widget. > > > > Yes but is this generated for each .glade file you process or do you have > to call glade with some special option to process it? And does glade use > this then or you have to use the functions for your implementation? 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 this file, but Glade assumes that you have one in the code it produces. And there is at least one function which is really required by my implementation: lookup_widget. > > This is much better implementation. Should I change it or you will make > > it? > > Well it's your baby :) I'll patch it. > This is Gnome-specific, I had a look and there is some problem with the > update of the menus. While in the xforms part the menu is rebuild when > I press on a menu-button this does not happen in gnome. I will have a better > look but you should try too as you know better than me how gnome-menus > work ;) 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. Marko
RE: Gnome: FormToc & FormIndex
> 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. Undo/Redo problem disappeared when I called update() after executing LyX action in "void Menubar::Pimpl::callback(int action)". However, I don't think that this is the right place to do so. Marko
RE: Gnome: FormToc & FormIndex
> > 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 this file, but Glade assumes that you have one in the code it > produces. And there is at least one function which is really required by > my implementation: lookup_widget. > If it's always identical we could just modify it and leave it there as a class helper function. > > 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. 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 logic to be changed, but I've no clue where to start looking at this, maybe we should just wait for Jean-Marcs return and hear what wise things he has to tell us :) Then now I get some gtk errors when I'm inside a tabular like this: Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. Could you have a look at them? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Hire the morally handicapped.
RE: Gnome: FormToc & FormIndex
> 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 logic to be changed, but I've no > clue where to start looking at this, maybe we should just wait for Jean-Marcs > return and hear what wise things he has to tell us :) I suppose that we need to call update after each action is executed regardless of the source of the action (menu, toolbar, pipe). > Then now I get some gtk errors when I'm inside a tabular like this: > > Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' > > Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): > assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. > > Gtk-WARNING **: invalid cast from `GtkMenuItem' to `GtkCheckMenuItem' > > Gtk-CRITICAL **: file gtkcheckmenuitem.c: line 144 (gtk_check_menu_item_set_active): > assertion `GTK_IS_CHECK_MENU_ITEM (check_menu_item)' failed. > > Could you have a look at them? 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 know the cause. Namely, when the menu is composed I use either regular or if the action is toggled on/off --- GtkCheckMenuItem. Do you know any means how can I know on beforehand whether the action is toggleable? Marko
RE: Gnome: FormToc & FormIndex
> > 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 know > the cause. Namely, when the menu is composed I use either regular or if > the action is toggled on/off --- GtkCheckMenuItem. Do you know any means > how can I know on beforehand whether the action is toggleable? That's the problem and IMO therefore the xforms implementation remakes the menu on the fly when it is opened. The problem is that we have only 4 states Disabled, Enabled, On and Off. To know this before we would need 6 of them Disabled, Enabled, On, Off, OnDisabled and OffDisabled! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3
RE: Gnome: FormToc & FormIndex
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 (LyXFunc::ToggleOn or LyXFunc::ToggleOff ) then you should know > > the cause. Namely, when the menu is composed I use either regular or if > > the action is toggled on/off --- GtkCheckMenuItem. Do you know any means > > how can I know on beforehand whether the action is toggleable? > > That's the problem and IMO therefore the xforms implementation remakes the > menu on the fly when it is opened. The problem is that we have only 4 states > Disabled, Enabled, On and Off. To know this before we would need 6 of them > Disabled, Enabled, On, Off, OnDisabled and OffDisabled! 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 LyXFunc::ToggleOff as the default for this kind of actions). Marko
RE: Gnome: FormToc & FormIndex
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 LyXFunc::ToggleOff as the default for > this kind of actions). I guess you got me here I'll try to have a look at this :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dammit Jim, I'm an actor, not a doctor.
RE: Gnome: FormToc FormIndex
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 the *callbacks.c files are just empty containers and IMO
they should be removed as they are not needed.
- would it be possible to postprocess the .[ch] files so that we can get
.[Ch] files as we do with fdesign generated files? (I would help to
implement this if you like it!)
- I don't see project files do you mean the .glade files? I did add the
directory and files the last time too!
- what is this support.[ch] is it always generated by glade?
- I had a look at Menubar_pimpl.C and have seen the composeUI function in
which you search for some commands to probably use some standard, GNOME
menu items for them, but why to you use the command-string and not directly
the action-int inside a switch like:
kb_action action;
string argument;
if (lyxaction.isPseudoAction
action = lyxaction.retrieveActionArg(ac, argument);
else
action = static_castkb_action(ac);
switch(action) {
case LFUN_FILE_OPEN:
gitem = Open(cback);
break;
case LFUN_QUIT:
gitem = Exit(cback);
break;
...
}
- I will also have a look why some menu-items are never enabled and/or
displayed wrong.
The patch fixes some small bugs in Gnome GUIRunTime_pimpl.C (we still have
to include FORMS_H_LOCATION to compile LyX).
Yes and we hopefully can remove that soon #:O)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Next Friday will not be your lucky day. As a matter of fact, you don't
have a lucky day this year.
RE: Gnome: FormToc FormIndex
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 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.
- would it be possible to postprocess the .[ch] files so that we can get
.[Ch] files as we do with fdesign generated files? (I would help to
implement this if you like it!)
In all computers that I've seen, gcc compiles files faster than g++. Do we
need to have compilation times longer? :)
- I don't see project files do you mean the .glade files? I did add the
directory and files the last time too!
yes, these are "project" files for each dialog.
- what is this support.[ch] is it always generated by glade?
yes. at least one function is used by me directly: lookup_widget.
- I had a look at Menubar_pimpl.C and have seen the composeUI function in
which you search for some commands to probably use some standard, GNOME
menu items for them, but why to you use the command-string and not directly
the action-int inside a switch like:
kb_action action;
string argument;
if (lyxaction.isPseudoAction
action = lyxaction.retrieveActionArg(ac, argument);
else
action = static_castkb_action(ac);
switch(action) {
case LFUN_FILE_OPEN:
gitem = Open(cback);
break;
case LFUN_QUIT:
gitem = Exit(cback);
break;
...
}
This is much better implementation. Should I change it or you will make
it?
- I will also have a look why some menu-items are never enabled and/or
displayed wrong.
Is it Gnome-specific or the same trouble is with XForms implementation?
Marko
RE: Gnome: FormToc & FormIndex
> 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 the *callbacks.c files are just empty containers and IMO
they should be removed as they are not needed.
- would it be possible to postprocess the .[ch] files so that we can get
.[Ch] files as we do with fdesign generated files? (I would help to
implement this if you like it!)
- I don't see project files do you mean the .glade files? I did add the
directory and files the last time too!
- what is this support.[ch] is it always generated by glade?
- I had a look at Menubar_pimpl.C and have seen the composeUI function in
which you search for some commands to probably use some standard, GNOME
menu items for them, but why to you use the command-string and not directly
the action-int inside a switch like:
kb_action action;
string argument;
if (lyxaction.isPseudoAction
action = lyxaction.retrieveActionArg(ac, argument);
else
action = static_cast(ac);
switch(action) {
case LFUN_FILE_OPEN:
gitem = Open(cback);
break;
case LFUN_QUIT:
gitem = Exit(cback);
break;
...
}
- I will also have a look why some menu-items are never enabled and/or
displayed wrong.
> The patch fixes some small bugs in Gnome GUIRunTime_pimpl.C (we still have
> to include FORMS_H_LOCATION to compile LyX).
Yes and we hopefully can remove that soon #:O)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Next Friday will not be your lucky day. As a matter of fact, you don't
have a lucky day this year.
RE: Gnome: FormToc & FormIndex
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 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.
> - would it be possible to postprocess the .[ch] files so that we can get
> .[Ch] files as we do with fdesign generated files? (I would help to
> implement this if you like it!)
In all computers that I've seen, gcc compiles files faster than g++. Do we
need to have compilation times longer? :)
> - I don't see project files do you mean the .glade files? I did add the
> directory and files the last time too!
yes, these are "project" files for each dialog.
> - what is this support.[ch] is it always generated by glade?
yes. at least one function is used by me directly: lookup_widget.
> - I had a look at Menubar_pimpl.C and have seen the composeUI function in
> which you search for some commands to probably use some standard, GNOME
> menu items for them, but why to you use the command-string and not directly
> the action-int inside a switch like:
>
> kb_action action;
> string argument;
> if (lyxaction.isPseudoAction
> action = lyxaction.retrieveActionArg(ac, argument);
> else
> action = static_cast(ac);
>
> switch(action) {
> case LFUN_FILE_OPEN:
> gitem = Open(cback);
> break;
> case LFUN_QUIT:
> gitem = Exit(cback);
> break;
> ...
> }
This is much better implementation. Should I change it or you will make
it?
> - I will also have a look why some menu-items are never enabled and/or
> displayed wrong.
Is it Gnome-specific or the same trouble is with XForms implementation?
Marko
