Re: Some words to frontends!
On Fri, 11 Aug 2000, Juergen Vigna wrote: ¹ Check JMarcs toolbar/menu stuff as per his request. Workout a support class for Ok/Apply/Cancel button management (similar to Baruch's RadioButtonGroup but with a separation of policy from gui toolkit), and another for Restore/Save/Apply/Cancel (preferences dialog) -- just a state machine that controls which buttons are active. Something as we had in the old devel branch? I'm looking at the new document/ paper/stuff dialog and have seen there some enum and apply functions which de/activate this buttons. Similar only much easier to use. Once I've fixed the clashes with the stuff you changed in src/frontends... (fairly minor I hope -- its updating now) you'll see how wonderful it is. Hmmm... finished now to make all your patching changes work with the new scheme. Allan. (ARRae)
Re: Some words to frontends!
On Fri, 11 Aug 2000, Juergen Vigna wrote: > > > > ¹ Check JMarcs toolbar/menu stuff as per his request. Workout a support > > class for Ok/Apply/Cancel button management (similar to Baruch's > > RadioButtonGroup but with a separation of policy from gui toolkit), and > > another for Restore/Save/Apply/Cancel (preferences dialog) -- just a state > > machine that controls which buttons are active. > > Something as we had in the old devel branch? I'm looking at the new document/ > paper/stuff dialog and have seen there some enum and apply functions which > de/activate this buttons. Similar only much easier to use. Once I've fixed the clashes with the stuff you changed in src/frontends... (fairly minor I hope -- its updating now) you'll see how wonderful it is. Hmmm... finished now to make all your patching changes work with the new scheme. Allan. (ARRae)
Re: Some words to frontends!
¹ Check JMarcs toolbar/menu stuff as per his request. Workout a support class for Ok/Apply/Cancel button management (similar to Baruch's RadioButtonGroup but with a separation of policy from gui toolkit), and another for Restore/Save/Apply/Cancel (preferences dialog) -- just a state machine that controls which buttons are active. Something as we had in the old devel branch? I'm looking at the new document/ paper/stuff dialog and have seen there some enum and apply functions which de/activate this buttons. 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The hardest thing in the world to understand is the income tax. -- Albert Einstein
Re: Some words to frontends!
> > ¹ Check JMarcs toolbar/menu stuff as per his request. Workout a support > class for Ok/Apply/Cancel button management (similar to Baruch's > RadioButtonGroup but with a separation of policy from gui toolkit), and > another for Restore/Save/Apply/Cancel (preferences dialog) -- just a state > machine that controls which buttons are active. Something as we had in the old devel branch? I'm looking at the new document/ paper/stuff dialog and have seen there some enum and apply functions which de/activate this buttons. 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The hardest thing in the world to understand is the income tax. -- Albert Einstein
Re: Some words to frontends!
Allan Rae [EMAIL PROTECTED] writes: | It'd be nice to have the glade source or whatever is the equivalent of the | xforms .fd files and the kdevelop .kdevdlg files in cvs for people to work | with. | | On a related note, I'm pretty sure I can get autogeneration of the | form_xxx.[Ch] files working easily but I'll do that once I'm finished | cleaning up Angus's patch and committed that. That would then allow us to | remove all the form_xxx.[Ch] files from cvs and the user then builds them | with whatever xforms they have on their system -- assuming they have | anon cvs access otherwise they'll get whatever is generated in the `make | dist` Don't do that... there might be some incompabilities with fdesign from 0.88 and 0.89...and until we move to 0.89 as the required version .fd files sould be processed by fdesign 0.88. Lgb
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: Then you could help us with hints for what you need f.ex. in LyXView so that you really can use the GNOME-menus or/and toolbars when you make that one work. I've took a first look into toolbar implementation and I am wondering why this implementation is so different from Menu? It seems to me that menus and toolbars are quite similar: (a) they both provide link between user's mouse (keyboard) and LyX command, (b) they both have to be updated regularly. The main difference between tool- and menubar which I see is the fact that Menus are hierarchical. However, we can decode the menu levels for use in the toolbars as follows: main-toolbars collection of the toolbars in "normal mode" |-- general-toolbar --- present toolbar | |-- layout --- selection box in the toolbar (Standard et al) | |-- fontsize --- new selection box (for example) |-- math-toolbar |... Thus, it is possible to use very similar interfaces for menu- and toolbars. Wouldn't that make writing-/configuring LyX easier? Or I don't see some important difference between toolbar and all these menus? :) Marko PS: I'll start to work on the dialogs meanwhile...
Re: Some words to frontends!
Allan Rae <[EMAIL PROTECTED]> writes: | It'd be nice to have the glade source or whatever is the equivalent of the | xforms .fd files and the kdevelop .kdevdlg files in cvs for people to work | with. | | On a related note, I'm pretty sure I can get autogeneration of the | form_xxx.[Ch] files working easily but I'll do that once I'm finished | cleaning up Angus's patch and committed that. That would then allow us to | remove all the form_xxx.[Ch] files from cvs and the user then builds them | with whatever xforms they have on their system -- assuming they have | anon cvs access otherwise they'll get whatever is generated in the `make | dist` Don't do that... there might be some incompabilities with fdesign from 0.88 and 0.89...and until we move to 0.89 as the required version .fd files sould be processed by fdesign 0.88. Lgb
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: >Then you could help us with hints for what you need f.ex. in LyXView so >that you really can use the GNOME-menus or/and toolbars when you make that >one work. I've took a first look into toolbar implementation and I am wondering why this implementation is so different from Menu? It seems to me that menus and toolbars are quite similar: (a) they both provide link between user's mouse (keyboard) and LyX command, (b) they both have to be updated regularly. The main difference between tool- and menubar which I see is the fact that Menus are hierarchical. However, we can decode the menu levels for use in the toolbars as follows: main-toolbars < collection of the toolbars in "normal mode" |-- general-toolbar <--- present toolbar | |-- layout <--- selection box in the toolbar (Standard et al) | |-- fontsize <--- new selection box (for example) |-- math-toolbar |... Thus, it is possible to use very similar interfaces for menu- and toolbars. Wouldn't that make writing-/configuring LyX easier? Or I don't see some important difference between toolbar and all these menus? :) Marko PS: I'll start to work on the dialogs meanwhile...
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: I know that working on this stuff is much more interesting then working on some dialogs. BTW.: you should find a clean way for makeing complex dialogs as you probably use some dialog-builder. Have a look at the work we did in the KDE and XFORMS branch. While in the XFORMS branch we use fdesign and then sed to make the necessary changes to the exported files so that they can be used asis without the need of manual work. In KDE (as I did that branch initially I decided that the KDevelop is a really nice tool to do this stuff I have used that) the files are already exported in nice C++ so that the modifications we do in the XFORMS branch are not necessary, but we can directly used the exported files). There is the glade tool for GTK+/Gnome, it can produce a .glade XML file and source code for C/C++ and some more (Perl and such). I use it in a python program I work on and it's really great but then I simply use libglade that loads the .glade file in runtime to build the dialogs. It should be considered if we want the source generated of the dialogs or the XML file to be loaded in runtime, the good thing about the XML file is that the (knowledgeable) user can play with it and customize the whole dialog to his liking (well at least in the sense of reorganizing it), the bad thing is the housekeeping that will make something else besides the executable a requirement to run the Gnome frontend. 3. For us developers: We should move to make LyXView GUII so that toolbars, menu's and stuff like that can be integrated by other frontends. But we already know this, just a reminder to go for it ;) I believe I sort of implied that in the latest thread, besides the dialog nothing is GUII, someone needs to put up a design and framework to make all of LyX GUII so we will really be independent. (Not me, I'm up to my ears with InsetGraphics :-) -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Some words to frontends!
There is the glade tool for GTK+/Gnome, it can produce a .glade XML file and source code for C/C++ and some more (Perl and such). I use it in a python program I work on and it's really great but then I simply use libglade that loads the .glade file in runtime to build the dialogs. Well I really think that it's enough to have the C++ files (I had a look at archimedes mail program and they use .glade files and libglade but it really didn't convince me!) 3. For us developers: We should move to make LyXView GUII so that toolbars, menu's and stuff like that can be integrated by other frontends. But we already know this, just a reminder to go for it ;) I believe I sort of implied that in the latest thread, besides the dialog nothing is GUII, someone needs to put up a design and framework to make all of LyX GUII so we will really be independent. (Not me, I'm up to my ears with InsetGraphics :-) BTW.: I tried to load some .eps file and it worked like a flaw, congratulations! but did you try Apply on an already displayed file (rotate 45) I get a segmentation fault. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Q: How did you get into artificial intelligence? A: Seemed logical -- I didn't have any real intelligence.
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: 1. For Marko (and mybe other people who want to support another frontend): The Menu_pimpl you did is nice but as you surely have seen there are some bases which do not work and so the whole menu-stuff is really not good working. IMO you should for now concentrate on the dialogs (as they can be fully implemented and it's really enough work for now) I think you are right. However, can you be a little bit more specific about "some bases which do not work". May be I can fix it before moving on with other parts? Marko
Re: Some words to frontends!
1. For Marko (and mybe other people who want to support another frontend): The Menu_pimpl you did is nice but as you surely have seen there are some bases which do not work and so the whole menu-stuff is really not good working. IMO you should for now concentrate on the dialogs (as they can be fully implemented and it's really enough work for now) I think you are right. However, can you be a little bit more specific about "some bases which do not work". May be I can fix it before moving on with other parts? I meant LyX-BaseClass files as the LyXView for example which is not yet GUII. So we all have to work on it to make it really GUII so you can add all the stuff cleanly. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We can predict everything, except the future.
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: BTW.: I tried to load some .eps file and it worked like a flaw, congratulations! but did you try Apply on an already displayed file (rotate 45) I get a segmentation fault. This is a work in progress, all translations are not done in the inline and I admit that I did not test the overall functionality for some time now, I'll see why this happens. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: There is the glade tool for GTK+/Gnome, it can produce a .glade XML file and source code for C/C++ and some more (Perl and such). I use it in a python program I work on and it's really great but then I simply use libglade that loads the .glade file in runtime to build the dialogs. Well I really think that it's enough to have the C++ files (I had a look at archimedes mail program and they use .glade files and libglade but it really didn't convince me!) It'd be nice to have the glade source or whatever is the equivalent of the xforms .fd files and the kdevelop .kdevdlg files in cvs for people to work with. On a related note, I'm pretty sure I can get autogeneration of the form_xxx.[Ch] files working easily but I'll do that once I'm finished cleaning up Angus's patch and committed that. That would then allow us to remove all the form_xxx.[Ch] files from cvs and the user then builds them with whatever xforms they have on their system -- assuming they have anon cvs access otherwise they'll get whatever is generated in the `make dist` Allan. (ARRae)
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: >I know that working on this stuff is much more interesting then working >on some dialogs. BTW.: you should find a clean way for makeing complex >dialogs as you probably use some dialog-builder. Have a look at the work >we did in the KDE and XFORMS branch. While in the XFORMS branch we use >fdesign and then sed to make the necessary changes to the exported files >so that they can be used asis without the need of manual work. In KDE >(as I did that branch initially I decided that the KDevelop is a really > nice tool to do this stuff I have used that) the files are already >exported in nice C++ so that the modifications we do in the XFORMS branch >are not necessary, but we can directly used the exported files). There is the glade tool for GTK+/Gnome, it can produce a .glade XML file and source code for C/C++ and some more (Perl and such). I use it in a python program I work on and it's really great but then I simply use libglade that loads the .glade file in runtime to build the dialogs. It should be considered if we want the source generated of the dialogs or the XML file to be loaded in runtime, the good thing about the XML file is that the (knowledgeable) user can play with it and customize the whole dialog to his liking (well at least in the sense of reorganizing it), the bad thing is the housekeeping that will make something else besides the executable a requirement to run the Gnome frontend. > 3. For us developers: > >We should move to make LyXView GUII so that toolbars, menu's and stuff >like that can be integrated by other frontends. But we already know this, >just a reminder to go for it ;) I believe I sort of implied that in the latest thread, besides the dialog nothing is GUII, someone needs to put up a design and framework to make all of LyX GUII so we will really be independent. (Not me, I'm up to my ears with InsetGraphics :-) -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Some words to frontends!
> > There is the glade tool for GTK+/Gnome, it can produce a .glade XML file > and source code for C/C++ and some more (Perl and such). I use it in a > python program I work on and it's really great but then I simply use > libglade that loads the .glade file in runtime to build the dialogs. Well I really think that it's enough to have the C++ files (I had a look at archimedes mail program and they use .glade files and libglade but it really didn't convince me!) > >> 3. For us developers: >> >>We should move to make LyXView GUII so that toolbars, menu's and stuff >>like that can be integrated by other frontends. But we already know this, >>just a reminder to go for it ;) > > I believe I sort of implied that in the latest thread, besides the dialog > nothing is GUII, someone needs to put up a design and framework to make > all of LyX GUII so we will really be independent. (Not me, I'm up to my > ears with InsetGraphics :-) BTW.: I tried to load some .eps file and it worked like a flaw, congratulations! but did you try Apply on an already displayed file (rotate 45) I get a segmentation fault. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Q: How did you get into artificial intelligence? A: Seemed logical -- I didn't have any real intelligence.
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: > 1. For Marko (and mybe other people who want to support another frontend): > >The Menu_pimpl you did is nice but as you surely have seen there are >some bases which do not work and so the whole menu-stuff is really not >good working. IMO you should for now concentrate on the dialogs (as they >can be fully implemented and it's really enough work for now) I think you are right. However, can you be a little bit more specific about "some bases which do not work". May be I can fix it before moving on with other parts? Marko
Re: Some words to frontends!
>> 1. For Marko (and mybe other people who want to support another frontend): >> >>The Menu_pimpl you did is nice but as you surely have seen there are >>some bases which do not work and so the whole menu-stuff is really not >>good working. IMO you should for now concentrate on the dialogs (as they >>can be fully implemented and it's really enough work for now) > > I think you are right. However, can you be a little bit more specific > about "some bases which do not work". May be I can fix it before moving on > with other parts? I meant LyX-BaseClass files as the LyXView for example which is not yet GUII. So we all have to work on it to make it really GUII so you can add all the stuff cleanly. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We can predict everything, except the future.
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: > BTW.: I tried to load some .eps file and it worked like a flaw, congratulations! > but did you try Apply on an already displayed file (rotate 45) I get a > segmentation fault. This is a work in progress, all translations are not done in the inline and I admit that I did not test the overall functionality for some time now, I'll see why this happens. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Some words to frontends!
On Wed, 9 Aug 2000, Juergen Vigna wrote: > > > > There is the glade tool for GTK+/Gnome, it can produce a .glade XML file > > and source code for C/C++ and some more (Perl and such). I use it in a > > python program I work on and it's really great but then I simply use > > libglade that loads the .glade file in runtime to build the dialogs. > > Well I really think that it's enough to have the C++ files (I had a look > at archimedes mail program and they use .glade files and libglade but it > really didn't convince me!) It'd be nice to have the glade source or whatever is the equivalent of the xforms .fd files and the kdevelop .kdevdlg files in cvs for people to work with. On a related note, I'm pretty sure I can get autogeneration of the form_xxx.[Ch] files working easily but I'll do that once I'm finished cleaning up Angus's patch and committed that. That would then allow us to remove all the form_xxx.[Ch] files from cvs and the user then builds them with whatever xforms they have on their system -- assuming they have anon cvs access otherwise they'll get whatever is generated in the `make dist` Allan. (ARRae)
