Re: Some words to frontends!

2000-08-13 Thread Allan Rae

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!

2000-08-11 Thread Juergen Vigna

> 
> ¹ 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!

2000-08-10 Thread Allan Rae

On 10 Aug 2000, Lars Gullik Bjønnes wrote:

> Allan Rae <[EMAIL PROTECTED]> writes:
> | 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.

I've found some other things¹ to stop me doing this anyway.  I'll hold off
till 0.90 is released with the auto-generation plan and then if 0.90 and
0.88 are compatible we can then just make sure that only 0.88 is used for
editting the fd files.

Allan. (ARRae)

¹ 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.




Re: Some words to frontends!

2000-08-10 Thread Marko Vendelin


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!

2000-08-10 Thread Lars Gullik Bjønnes

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!

2000-08-09 Thread Allan Rae

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!

2000-08-09 Thread Baruch Even

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&D site)

" Learn to laugh ... it's the path to true love! " 
   - The Angel in the movie Michael





Re: Some words to frontends!

2000-08-09 Thread Juergen Vigna

>> 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!

2000-08-09 Thread Marko Vendelin



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!

2000-08-09 Thread Juergen Vigna

> 
> 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!

2000-08-09 Thread Baruch Even

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&D site)

" Learn to laugh ... it's the path to true love! " 
   - The Angel in the movie Michael





Some words to frontends!

2000-08-09 Thread Juergen Vigna

Hi All!

I soon will commit the work Marko did for the GNOME-Frontend, now I have
some thoughts to all this frontend stuff I've seen by looking at the work
Marko did for the Menu_pimpl-stuff.

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)

   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 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).

2. General (mainly for the upcoming 1.1.6):

   IMO we should deactivate the not actively supported frontends for the
   general release (say KDE) as we would only get a lot of feedback with
   'why is this not working there?' For the supported ones (say GNOME and
   XFORMS) we know the answers and also can directly go for bugfixes and
   so we can support them.

   We should also remember to do the necessary symlinks in the GNOME frontend
   before releasing 1.1.6 so that ALL the stuff is supported and all the
   dialogs will shown if compiled with this frontend (this is mainly for
   Lars as he will do this ;)

   We will have also to disable the code of how the GNOME-menu code is made
   actually!

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 ;)

Now probably I will get a lot of flames (but it's not friday so ... :), but
IMO we should talk about this things before they happen.

 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

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

A straw vote only shows which way the hot air blows.
-- O'Henry