On Tue, Jul 01, 2025 at 01:56:25PM +0200, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 01.07.2025 um 00:19 +0200 schrieb Scott Kostyshak:
> > The above code triggers a warning:
> >
> > src/frontends/qt/TocWidget.cpp:188:11: warning: 'return' will never
> > be executed [-Wunreachable-code-return]
>
Am Dienstag, dem 01.07.2025 um 00:19 +0200 schrieb Scott Kostyshak:
> The above code triggers a warning:
>
> src/frontends/qt/TocWidget.cpp:188:11: warning: 'return' will never
> be executed [-Wunreachable-code-return]
> 188 | return true;
> |
On Mon, Apr 28, 2025 at 09:47:24AM +, Juergen Spitzmueller wrote:
> commit 9f6c452a5b4e444ab24903ff7d7ba17c1ef74985
> Author: Juergen Spitzmueller
> Date: Mon Apr 28 11:46:56 2025 +0200
>
> Add \cpageref to context menus
> ---
...
> + case LFUN_R
Am Freitag, 15. Dezember 2017 um 17:46:57, schrieb Jean-Marc Lasgouttes
> Le 15/12/2017 à 17:38, Kornel Benko a écrit :
> >> The code in InsetCollapsible::contextMenu tells it all: it depends
> >> whether there is a button, whether it is open, etc.
> >
> > It describes the algorithm, yes. But, a
Le 15/12/2017 à 17:38, Kornel Benko a écrit :
The code in InsetCollapsible::contextMenu tells it all: it depends
whether there is a button, whether it is open, etc.
It describes the algorithm, yes. But, as a translator, one needs the possible
combinations.
I was a bit fast: the code show tha
Am Freitag, 15. Dezember 2017 um 16:46:14, schrieb Jean-Marc Lasgouttes
> Le 15/12/2017 à 15:36, Kornel Benko a écrit :
> > Do we have somewhere a list of possible combinations?
> >
> > Something like
> > context-edit + context-tabular
> >
> > or
> > context-phantom + context-collapsibl
Le 15/12/2017 à 15:36, Kornel Benko a écrit :
Do we have somewhere a list of possible combinations?
Something like
context-edit + context-tabular
or
context-phantom + context-collapsible + context-edit
The code in InsetCollapsible::contextMenu tells it all: it depends
whethe
Do we have somewhere a list of possible combinations?
Something like
context-edit + context-tabular
or
context-phantom + context-collapsible + context-edit
It would help in omitting conflicting shortcuts.
Kornel
signature.asc
Description: This is a digitally signed mes
Jürgen Spitzmüller lyx.org> writes:
> > I see no ticket about this.
> > Shouldn't exist one, following earlier threads on the subject ?
>
> Yes, it should, and it should point to target 2.0.
Done (ticket #7275)
--
Jean-Pierre
Jürgen Spitzmüller wrote:
> there should probably be some limit to make the context menus not grow
> perversely.
+1
pavel
" share the same shortcut.
This comes from the context-menu-inheritance feature (see #6642). In current
state, this feature is problematic. We should probably strip the shortcuts
from all inherited context menus, or try to generate some unique shortcuts (as
we do for the languages setting
On Fri, Dec 10, 2010 at 12:16 AM, Pavel Sanda wrote:
> Liviu Andronic wrote:
>> As for the tabular items themselves, personally I would prefer that it
>> stays as it is.
>
> you mean this 2 column version?
>
No, no. I was talking only about the tabular-specific items: the menu
present in beta1, fr
Liviu Andronic wrote:
> As for the tabular items themselves, personally I would prefer that it
> stays as it is.
you mean this 2 column version?
p
On Thu, Dec 9, 2010 at 11:54 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> That's a pretty good idea. Another would be to use more submenus on the
>> tabular menu.
>
> i feel that once you need tree-like structure in context menu the whole point
> to have something quickly in hand via context me
Richard Heck wrote:
> That's a pretty good idea. Another would be to use more submenus on the
> tabular menu.
i feel that once you need tree-like structure in context menu the whole point
to have something quickly in hand via context menu is lost and we can safely
return back to settings dialog o
On 12/09/2010 05:23 PM, Liviu Andronic wrote:
On Thu, Dec 9, 2010 at 9:32 PM, Pavel Sanda wrote:
hi,
dont have a netbook to test but i bet that our current tabular context menu
have no chance
to get inside the monitor after last changes...
I can confirm. I have a 12 inch netbook, and beta1 c
On Thu, Dec 9, 2010 at 9:32 PM, Pavel Sanda wrote:
> hi,
> dont have a netbook to test but i bet that our current tabular context menu
> have no chance
> to get inside the monitor after last changes...
>
I can confirm. I have a 12 inch netbook, and beta1 c-menu was fine but
beta2 tabular c-menu c
Vincent van Ravesteijn wrote:
> Go for it.
i once did, but i have some vague memory that it was a bit controversial
so in the end we decided to stick to what we had
i do think that the menu's are too daunting for most
perhaps i'll try to dig up these old threads over the xmas holiday to
see wh
Vincent van Ravesteijn wrote:
> Go for it.
yay i see the flames :)
>
> Op 9 dec 2010 22:07 schreef "Edwin Leuven" :
>
> Jean-Marc Lasgouttes wrote:
> > I think these menus are getting to large to be ac...
> and would benefit from a bit of reorganisation
>
> and then some fresh icons on top of
Go for it.
Op 9 dec 2010 22:07 schreef "Edwin Leuven" :
Jean-Marc Lasgouttes wrote:
> I think these menus are getting to large to be ac...
and would benefit from a bit of reorganisation
and then some fresh icons on top of it ...
ed.
Jean-Marc Lasgouttes wrote:
> I think these menus are getting to large to be actually useful.
and would benefit from a bit of reorganisation
and then some fresh icons on top of it ...
ed.
Le 09/12/2010 21:32, Pavel Sanda a écrit :
hi,
dont have a netbook to test but i bet that our current tabular context menu
have no chance
to get inside the monitor after last changes...
I think these menus are getting to large to be actually useful.
JMarc
hi,
dont have a netbook to test but i bet that our current tabular context menu
have no chance
to get inside the monitor after last changes...
pavel
Helge Hafting wrote:
> Same arrowfills and bracefills, but now the context menu works also.
> I have incremented the format and added lyx2lyx conversion too, but ran
> into some trouble during testing:
You forgot to adapt the version number in lyx2lyx/LyX.py.
Also, accelerators for the new menu en
Same arrowfills and bracefills, but now the context menu works also.
I have incremented the format and added lyx2lyx conversion too, but ran
into some trouble during testing:
First test:
Ran from the build directory. Loading old documents did not work, because
format 329 is unknown. strange, fo
Abdelrazak Younes wrote:
BufferView::mouseSetCursor() is used with button1 and button3 so we need
an additional boolean parameter for this. For button1, we definitly
don't want to set the cursor inside a non editable inset. For button3 on
the other hand we could push back the cursor slice temp
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdel, I think the problem is that, when right-clicking on an inset
button, I think the cursor should be set to include the isnet as a
slice, even when the inset is closed or is not highly editable.
Won't this
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Abdel, I think the problem is that, when right-clicking on an inset
>> button, I think the cursor should be set to include the isnet as a
>> slice, even when the inset is closed or is not highly editable.
>
> Won't this lead to crash or assertion in
Jean-Marc Lasgouttes wrote:
Pavel Sanda <[EMAIL PROTECTED]> writes:
The 'show label' entry of conglomerate-style insets (charstyles) is
not working.
aha. well just the few others i remember now:
all insets: dissolve is disabled when clicking on the top label,
checkboxes are not vi
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> The 'show label' entry of conglomerate-style insets (charstyles) is
>> not working.
>
> aha. well just the few others i remember now:
> all insets: dissolve is disabled when clicking on the top label,
> checkboxes are not visible (eg note ins
> >> The following patch fixes the context menus for conglomerate-like
> >> insets.
> >
> > can you be more specific what exactly are you trying to fix?
> > currently i know about more bugs about the context menu of
> > insets toggling.
>
> The
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> The following patch fixes the context menus for conglomerate-like
>> insets.
>
> can you be more specific what exactly are you trying to fix?
> currently i know about more bugs about the context menu of
> insets toggli
> The following patch fixes the context menus for conglomerate-like
> insets.
can you be more specific what exactly are you trying to fix?
currently i know about more bugs about the context menu of
insets toggling.
> I am not sure what the current
> one exactly is.
i tried to
The following patch fixes the context menus for conglomerate-like
insets. The problem was in the way next-inset-toggle and inset-toggle
work.
Here is the situation as it used to be. I am not sure what the current
one exactly is.
* next-inset-toggle finds a suitable inset, either next to cursor
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> For one LFUN_INSET_TOGGLE did not have an associated name, I fixed
> this in r23884. Problem is that C-i is binded to
> LFUN_NEXT_INSET_TOGGLE not LFUN_INSET_TOGGLE... maybe we should merge
> the two LFUN?
There is some logic in these two function a
On Fri, Mar 21, 2008 at 07:45:17PM +0100, Abdelrazak Younes wrote:
> For one LFUN_INSET_TOGGLE did not have an associated name, I fixed this in
> r23884. Problem is that C-i is binded to LFUN_NEXT_INSET_TOGGLE not
> LFUN_INSET_TOGGLE... maybe we should merge the two LFUN?
Well, there would be a
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
Pavel Sanda wrote:
That's the reason why I'd like us to standardize on "right-click"
== "context-menu".
either one left click to (un)collapsing or ok context menu, but
then lets go back
to old visual style of ert inset, where w
rgheck wrote:
Abdelrazak Younes wrote:
Pavel Sanda wrote:
That's the reason why I'd like us to standardize on "right-click" ==
"context-menu".
either one left click to (un)collapsing or ok context menu, but
then lets go back
to old visual style of ert inset, where was possible to click on
t
On Fri, Mar 21, 2008 at 07:20:48PM +0100, Pavel Sanda wrote:
> > > if i'm going to touch keyboard i can use shortcut.
> > > what about middle button?
> >
> > "Paste".
>
> do you get all messages from the list Andre? :)
My computer most likely gets them. Whatever happens afterwards is
non-determi
On Fri, Mar 21, 2008 at 06:11:35PM +0100, Dominik Böhm wrote:
> On Fri, Mar 21, 2008 at 6:05 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > > if i'm going to touch keyboard i can use shortcut.
> > > what about middle button?
> >
> > no, thats for pasting :(
>
> What about double left click?
Pos
Abdelrazak Younes wrote:
Pavel Sanda wrote:
That's the reason why I'd like us to standardize on "right-click" ==
"context-menu".
either one left click to (un)collapsing or ok context menu, but
then lets go back
to old visual style of ert inset, where was possible to click on
the left label
> > if i'm going to touch keyboard i can use shortcut.
> > what about middle button?
>
> "Paste".
do you get all messages from the list Andre? :)
pavel
Abdelrazak Younes wrote:
Andre Poenitz wrote:
I wonder whether I have the same sources like you. Right now I have
quite a few problems to use LyX and it does note even remotely look
like nearing a release. E.g.
- The only way to change ERT from "expanded" to "inline" is to place the
cursor in f
On Fri, Mar 21, 2008 at 06:02:12PM +0100, Pavel Sanda wrote:
> >>> I don't have strong opinion on old style versus new visual style for ERT.
> >>> The new style looks better on screen of course.
> >> in fact i dont have strong opinion about either context menu or visual
> >> styles.
> >> but what
Andre Poenitz wrote:
Which reminds me: Storing Par(Const)Iterators is _not_ safe. They
are meant to iterate over a non-changing document, nothing else.
In this case, it is safe because we update the list for each paragaph or
inset creation or deletion thanks to the updateLabels()/addToToc()
m
On Fri, Mar 21, 2008 at 6:11 PM, Dominik Böhm <[EMAIL PROTECTED]> wrote:
>
> What about double left click?
Sorry, I answered too quickly and saw already that a double click is
not an option.
Why do ERT insets not have such fancy handles on the top left, like
floats for example? It would be very
On Fri, Mar 21, 2008 at 6:05 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > if i'm going to touch keyboard i can use shortcut.
> > what about middle button?
>
> no, thats for pasting :(
What about double left click?
> if i'm going to touch keyboard i can use shortcut.
> what about middle button?
no, thats for pasting :(
pavel
>>> I don't have strong opinion on old style versus new visual style for ERT.
>>> The new style looks better on screen of course.
>> in fact i dont have strong opinion about either context menu or visual
>> styles.
>> but what is wrong wrong and wrong is to loose the possibility of one-click
>> (
Pavel Sanda wrote:
That's the reason why I'd like us to standardize on "right-click" ==
"context-menu".
either one left click to (un)collapsing or ok context menu, but then lets
go back
to old visual style of ert inset, where was possible to click on the left
label
to collapse job.
I don't h
> That's the reason why I'd like us to standardize on "right-click" ==
> "context-menu".
>
>> either one left click to (un)collapsing or ok context menu, but then lets
>> go back
>> to old visual style of ert inset, where was possible to click on the left
>> label
>> to collapse job.
>
> I don't
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> No. We had a discussion last week and the conclusion was that
> right-clicking should pop-up a context menu.
Agreed. We could use something like Ctrl-leftclick to change appearance.
JMarc
Pavel Sanda wrote:
Andre Poenitz wrote:
I wonder whether I have the same sources like you. Right now I have
quite a few problems to use LyX and it does note even remotely look
like nearing a release. E.g.
- The only way to change ERT from "expanded" to "inline" is to place the
cursor in front of
> Andre Poenitz wrote:
>> I wonder whether I have the same sources like you. Right now I have
>> quite a few problems to use LyX and it does note even remotely look
>> like nearing a release. E.g.
>> - The only way to change ERT from "expanded" to "inline" is to place the
>> cursor in front of the
Andre Poenitz wrote:
I wonder whether I have the same sources like you. Right now I have
quite a few problems to use LyX and it does note even remotely look
like nearing a release. E.g.
- The only way to change ERT from "expanded" to "inline" is to place the
cursor in front of the inset and pres
On Tue, Mar 18, 2008 at 09:07:08PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
>
> > Which reminds me: Storing Par(Const)Iterators is _not_ safe. They
> > are meant to iterate over a non-changing document, nothing else.
> >
> > At the very least, StableDocIterators have to be used.
Andre Poenitz wrote:
> Which reminds me: Storing Par(Const)Iterators is _not_ safe. They
> are meant to iterate over a non-changing document, nothing else.
>
> At the very least, StableDocIterators have to be used.
StableDocIterators aren't really safer... The only *sort* of 'safe' (i.e.
editio
On Tue, Mar 18, 2008 at 07:33:47PM +0100, Andre Poenitz wrote:
>
> I wonder whether I have the same sources like you. Right now I have
> quite a few problems to use LyX and it does note even remotely look
> like nearing a release. E.g.
>
> - The only way to change ERT from "expanded" to "inline"
- I get an immediate crash when trying to open the Navigate menu
after loading the Embedded Objects document.
#0 0x00045d69 in
__gnu_norm
::vector
<
__gnu_debug
::_Safe_iterator<__gnu_norm::_List_iterator,
__gnu_debug_def::list >
>,
std
::allocator
<
__gnu_debug
::_Safe_iterator
I wonder whether I have the same sources like you. Right now I have
quite a few problems to use LyX and it does note even remotely look
like nearing a release. E.g.
- The only way to change ERT from "expanded" to "inline" is to place the
cursor in front of the inset and press Ctrl-I.
- I get an
Abdelrazak Younes wrote:
Pavel Sanda wrote:
One question to everybody: how do I now that I am starting a new
selection? My problem is as follow:
1) select some text
2) move the mouse somewhere else outside the selected area.
3) left-click to start a new selection
I have to detect that the p
Pavel Sanda wrote:
Pavel Sanda wrote:
So the selection should remain intact only if one right click on a
selection.
yes
I am having a look at mouse business right now. I must say that this is a
mess and that we do basically everything different from other apps. The
main problem is that we do
> Pavel Sanda wrote:
>>> So the selection should remain intact only if one right click on a
>>> selection.
>> yes
>
> I am having a look at mouse business right now. I must say that this is a
> mess and that we do basically everything different from other apps. The
> main problem is that we do m
Pavel Sanda wrote:
So the selection should remain intact only if one right click on a
selection.
yes
I am having a look at mouse business right now. I must say that this is
a mess and that we do basically everything different from other apps.
The main problem is that we do most things at mo
> So the selection should remain intact only if one right click on a
> selection.
yes
pavel
Abdelrazak Younes wrote:
> Tabular would be fantastic at least. Graphics would be useful for
> selection and
external editing. Cf.
http://bugzilla.lyx.org/show_bug.cgi?id=3975
Jürgen
Abdelrazak Younes wrote:
> > change of type (vref, prettyref.../citep, citet,...),
>
> Do we have LFUNs for these?
>
> > for space
> > inset, change of type (thinspace, normalspace, negthinspace ...).
>
> and for these?
not that I'm aware of.
Jürgen
at remains to do is to create
entries in "stdmenus.inc".
do we plan make context menus also for tabulars and graphics?
Tabular would be fantastic at least. Graphics would be useful for
selection and
Abdel.
should pass an optional argument to
Menus::menu() coming from Inset::contextMenu()...
Also, I think all context menus of insets that do have a dialog should have an
entry "Customize settings ..." that opens the dialog.
Agreed, should be easy at least for InsetCommand based insets.
Abdel.
ink all context menus of insets that do have a dialog should have an
entry "Customize settings ..." that opens the dialog.
Jürgen
Pavel Sanda wrote:
As some of you already noticed, adding a context menu to a given inset is
now easier than ever. You just need to implement contextMenu() and add the
corresponding entry in "stdmenus.inc". For InsetCommand derived Insets, the
support code is already there so all that remains t
> As some of you already noticed, adding a context menu to a given inset is
> now easier than ever. You just need to implement contextMenu() and add the
> corresponding entry in "stdmenus.inc". For InsetCommand derived Insets, the
> support code is already there so all that remains to do is to c
off-topic but related: note that right clicking clears a selection
ed.
at remains to do is to create
> entries in "stdmenus.inc".
do we plan make context menus also for tabulars and graphics?
(this is question, not proposition)
pavel
Hello,
As some of you already noticed, adding a context menu to a given inset
is now easier than ever. You just need to implement contextMenu() and
add the corresponding entry in "stdmenus.inc". For InsetCommand derived
Insets, the support code is already there so all that remains to do is
to
75 matches
Mail list logo
