Jürgen Spitzmüller wrote:
> > - possibility to use graphics dialog for changin group definition as it
> > is now without any additional clicking around (i'm not sure we agree
> > here) - possibility to define new group inside the graphics dialog (also
> > not sure about your position)
>
> I thin
Jean-Marc Lasgouttes wrote:
> Pavel Sanda writes:
> > Manveru schreef:
> >> I hadn't read this in manual, but from your explanations it seem to be
> >> very user not-friendly feature. It is not natural to users entering
> >> new name in that field every time they want new group. Without reading
>
Pavel Sanda wrote:
> - possibility to use context menu for assign (i think we agree here)
Yes
> - possibility to use graphics dialog for changin group definition as it
> is now without any additional clicking around (i'm not sure we agree
> here) - possibility to define new group inside the gra
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
Wrong, it's perfectly fine that the dialog do 'read' access to the
buffer. The other way around is strictly forbidden. And it's good
practice to avoid direct 'write' access to the buffer from the dialog;
we should use an LFUN instead.
> > imho Document->Settings way is very unpractical. my usual worflow is not to
> > define set of groups and then assign them images, but to have set of images
> > and start to create new groups via dialog without even closing it.
>
> My problem with the current approach is that graphic groups are
Abdelrazak Younes writes:
> Wrong, it's perfectly fine that the dialog do 'read' access to the
> buffer. The other way around is strictly forbidden. And it's good
> practice to avoid direct 'write' access to the buffer from the dialog;
> we should use an LFUN instead.
So could the buffer() be con
Pavel Sanda wrote:
> imho Document->Settings way is very unpractical. my usual worflow is not to
> define set of groups and then assign them images, but to have set of images
> and start to create new groups via dialog without even closing it.
My problem with the current approach is that graphic g
> Pavel Sanda writes:
> > i also accept your critics, but this was to be addressed when i was trying
> > to
> > get the attention for design details of this feature. when i didn't get the
> > feedback i did it the way i like to use it;
>
> Pissed off already?
friday!
ok, on wrong list :)
pavel
> Pavel Sanda wrote:
> > i also accept your critics, but this was to be addressed when i was trying
> > to get the attention for design details of this feature. when i didn't get
> > the feedback i did it the way i like to use it; now i don't have time nor
> > interest to rewrite it for a different
Pavel Sanda wrote:
Pavel Sanda writes:
this belongs to those 'another proposals'. you need to fetch the list of
groups. in case user clicks on some group you need to fetch all parameters for
this group. all this without direct access to buffer, so new lfun machinery
would be needed around.
The
> Pavel Sanda writes:
> > i had the feeling that we try to avoid direct touching of kernel from gui,
> > thats why everything in dialogs is passed through lfuns.
>
> My view is that we avoid to do _actions_ dorectly (so that everything
> can be reproduced through lfuns), but we can query as much
Pavel Sanda wrote:
> i also accept your critics, but this was to be addressed when i was trying
> to get the attention for design details of this feature. when i didn't get
> the feedback i did it the way i like to use it; now i don't have time nor
> interest to rewrite it for a different philosoph
Pavel Sanda writes:
> i also accept your critics, but this was to be addressed when i was trying to
> get the attention for design details of this feature. when i didn't get the
> feedback i did it the way i like to use it;
Pissed off already?
JMarc
> Pavel Sanda wrote:
> > the point 2 is the only one i was a bit worried about. context menu
> > selection is done on purpose, since it seemed to be most effective
> > way how to work with groups for me.
>
> User actions should never ever be restricted to context menu exclusively.
yes, thats why
Pavel Sanda writes:
> i had the feeling that we try to avoid direct touching of kernel from gui,
> thats why everything in dialogs is passed through lfuns.
My view is that we avoid to do _actions_ dorectly (so that everything
can be reproduced through lfuns), but we can query as much as we want.
Pavel Sanda wrote:
> the point 2 is the only one i was a bit worried about. context menu
> selection is done on purpose, since it seemed to be most effective
> way how to work with groups for me.
User actions should never ever be restricted to context menu exclusively.
Frankly, the graphic group
> 1. The gui works in another way than many lyx options. Take the
> 'local layout' option from the document options (In document
> class tab) as an example on how I would expect it to work.
> (A list of layouts-> add layout button-> new window to specify
> the new layout-> new layout added)
>
> Pavel Sanda writes:
> > this belongs to those 'another proposals'. you need to fetch the list of
> > groups. in case user clicks on some group you need to fetch all parameters
> > for
> > this group. all this without direct access to buffer, so new lfun machinery
> > would be needed around.
>
> -Opprinnelig melding-
> Fra: Pavel Sanda [mailto:sa...@lyx.org]
> Sendt: 9. januar 2009 09:51
> Til: lyx-users@lists.lyx.org
> Emne: Re: What is groupId in GraphicsUi
>
> Manveru schreef:
> > I hadn't read this in manual, but from your explanations it
Pavel Sanda writes:
> this belongs to those 'another proposals'. you need to fetch the list of
> groups. in case user clicks on some group you need to fetch all parameters for
> this group. all this without direct access to buffer, so new lfun machinery
> would be needed around.
The dialog class
> Pavel Sanda writes:
> > the group name is just part of the image settings, so filling up the name
> > is similar as filling the 'new' latex parameters for the image. i have
> > removed the confusing "Initialize" word and enriched the tooltips.
> > another proposals i have seen up to now are not
Pavel Sanda writes:
> Manveru schreef:
>> I hadn't read this in manual, but from your explanations it seem to be
>> very user not-friendly feature. It is not natural to users entering
>> new name in that field every time they want new group. Without reading
>> the manual, people like I who mostly
Manveru schreef:
> I hadn't read this in manual, but from your explanations it seem to be
> very user not-friendly feature. It is not natural to users entering
> new name in that field every time they want new group. Without reading
> the manual, people like I who mostly not read manuals at all can
2009/1/9 Pavel Sanda :
>> Manveru schreef:
>>> This question is probably to devel list, but I am not subscribed
>>> there. Probably I can get good answer here to my question.
>>>
>>> In 1.6 there in new option in Graphics Ui: "Initialize Group Name". I
>>> would like to translate it to Polish, but
> Manveru schreef:
>> This question is probably to devel list, but I am not subscribed
>> there. Probably I can get good answer here to my question.
>>
>> In 1.6 there in new option in Graphics Ui: "Initialize Group Name". I
>> would like to translate it to Polish, but this is not possible without
Manveru schreef:
This question is probably to devel list, but I am not subscribed
there. Probably I can get good answer here to my question.
In 1.6 there in new option in Graphics Ui: "Initialize Group Name". I
would like to translate it to Polish, but this is not possible without
having context
This question is probably to devel list, but I am not subscribed
there. Probably I can get good answer here to my question.
In 1.6 there in new option in Graphics Ui: "Initialize Group Name". I
would like to translate it to Polish, but this is not possible without
having context on mind.
Thanks i
27 matches
Mail list logo
