Jean-Marc Lasgouttes wrote:
>>>>>> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
>>>>>> writes:
>
>>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>>>>> Icon "dialog-show-new-inset graphics" "graphics.xpm"
>>>> Why ?
>
> Angus> Because it's three lines of code and it's done in
> Angus> ToolbarDefaults.C (which, as you note, is where this code
> Angus> should be). Shall I do it?
>
> Jean-Marc> Thqt does not mqke sense, IMO. This means that everybody
> Jean-Marc> who needs to add an icon will have to hunt for the right
> Jean-Marc> icon. Please, if you lfun names are too long, it's your
> Jean-Marc> fault :)
>
> Now that I have access to a proper qwerty keyboard, I'd like to add
> that it may be a compelling reason why this lfun should be named
> "inset-insert". Did anybody feel the need to rename file-insert to
> file-dialog-show-and-insert-file? For the same reasons, I think that
> inset-insert is a perfectly reasonable name for the purpose of
> inserting interactively any inset whether it needs a dialog or not.
> And for internal communication (the case where you pass the inset
> contents as argument) we could use inset-parse or soemthing like that.
I have thought quite hard about this. Here's my take on it.
We have two sorts of insets.
1. Insets which can contain data that can be entered in the LyX screen.
2. Insets whose data can be input only from a dialog.
I think these two types of insets require two different creation mechanisms.
Type 1 insets should just be "inserted" and the user can get to work
filling them with fine words. Subsequently, the user can tweak their
properties by popping up the dialog.
Such insets should have an inset-insert lfun.
It makes no sense at all to have such an lfun for the Type 2 insets. Instead
we should pop up a dialog to fill the proposed inset with sensible values.
'Apply' then dispatches an lfun that actually creates the thing with valid
parameters.
Such insets should therefore have a dialog-show-new-inset lfun.
This is exactly what happens now. In the past some of the Type 2 insets used
this, correct, mechanism but others used the incorrect, second mechanism.
All are how consistent I believe.
That being said, it might indeed make sense to have a single
insert-inset "name"
lfun although at present the code for these different lfuns is very
different.
> That said, I agree that the magic code to get the icon name should go
> to ToolbarDefaults. Also, Angus, if you feel like it, the menu and
> toolbar backends should really be changed into some controller and use
> proper signals instead of this stupid pimpls.
Yes, I think that I could do this although I have come to the conclusion
that signals just obfuscated the Dialogs code. I suspect that this is also
true of the Menubar code and believe that we should use something like the
Timout code to proceed.
Anyway, this is all for the future. The current and real problem is that the
stuff that creates the psuedo action from "dialog-show-new-inset graphics"
is returneing it as "dialog-show-next-inset graphics" which is absolutely
wrong :-(
--
Angus
