Wed 06 Sep 2017 04:01:40 AM UTC, comment #19:
Indeed, that does fix it. I'm closing the report as this seems to be an upstream issue with KDE. It would be nice if there were a way to change the AutoCheckAccelerators on a per application basis ratherg for everything. It would be even nicer if Octave could make a call during initialization to turn this option on for itself.
|
Wed 06 Sep 2017 02:24:58 AM UTC, comment #18:
I guess this issue is also caused by the "&"-injection of KDE: the test for an already existing tab is done by reading the tab text, which was already changed by KDE. Could someone who is using KDE please confirm this by adding
into the file
|
Fri 01 Sep 2017 12:07:20 AM UTC, comment #17:
I can reproduce the original reporter's problem using either a double-click in the Workspace Window, the right-click menu in the Workspace Window, or openvar twice in the Command Window. The Variable Editor Window was docked for all of these tests.
This is with 23987:4d5018136313.
|
Wed 30 Aug 2017 09:42:19 PM UTC, comment #16:
[OT]
@Mike:
A quick search, see here:
http://octave.1599824.n4.nabble.com/MXE-Ctrl-C-Ctrl-V-Ctrl-X-in-GUI-editor-amp-terminal-built-with-Qt5-tt4682986.html
AFAIK I never got an answer so I probably forgot, it also was in our Spring school holiday period and my family and me were away several weeks.
I just tried with the most recent Qt5 cross-build I have, from April 23.
On Win10, Ctrl-V to the terminal pane didn't work.
Bug #50843 might be related (is also about Win10 / Qt5).
I'll investigate further and will enter a bug report if I can reproduce it with a more recent build. But that will take some time.
|
Wed 30 Aug 2017 09:00:48 PM UTC, comment #15:
I thought this has been reported before, must be maybe a year or longer ago.
I'll try to uncover it.
|
Wed 30 Aug 2017 07:24:31 PM UTC, comment #14:
I was actually responding to Philip, who claims he has a known issue with Octave built using Qt 5 on Windows, but I see no open bug reports about it.
|
Wed 30 Aug 2017 07:00:24 PM UTC, comment #13:
Yes, I'll report any issues I encounter.
|
Wed 30 Aug 2017 03:26:08 PM UTC, comment #12:
Side note - can you please file bugs that need to be fixed to get Octave working with Qt 5? I don't see any bugs in the tracker related to Qt 5 that would prevent us from switching to Qt 5 by default today.
I would hope that we can deliver the 4.4 Windows binary built against Qt 5. Qt 4 is obsolete and no longer supported.
|
Wed 30 Aug 2017 03:21:11 PM UTC, comment #11:
OK, my builds are all with Qt4. One reason for that is that copy/paste from/to terminal doesn't work on Windows with Qt5 (my main productivity OS).
On my brand new Mageia 6 system I use Qt5 but I ran in some compilation problems (probably some dependency issue). Once cleared out of the way I can try to see if Qt5 is indeed related.
|
Tue 29 Aug 2017 11:26:12 PM UTC, comment #10:
No problem, thanks for caring about this.
I'm indeed using Qt 5.7.1, this is some of the ./configure output:
|
Tue 29 Aug 2017 09:45:50 PM UTC, comment #9:
Alexander, thanks for all the trouble.
I have no idea why it works fine for me but not for you.
Or maybe... I use Qt4 for my builds; do you use Qt5 ?
|
Tue 29 Aug 2017 05:19:10 PM UTC, comment #8:
I ran
make clean
hg update -C
./bootstrap
./configure
make all
make install
and the problem persists.
|
Tue 29 Aug 2017 04:26:52 PM UTC, comment #7:
@Alexander: you also submitted bug #51853 that Torsten nor I can reproduce. That makes me suspect you got some issues in your source and/or build tree.
Can you please do
make clean
-or-
make maintainer-clean
hg update -C
./bootstrap
,wipe your build tree, completely rebuild again and check if the problems persist?
|
Tue 29 Aug 2017 04:20:51 PM UTC, comment #6:
I can't reproduce the OP's issue at all, neither on Linux nor on Windows. First docked and then undocked makes no difference either.
hg id df49ac93f50c "run.m recode BIST tests ..."
@Alexander:
what patch level is your Octave build? (hg summary)
|
Sun 27 Aug 2017 09:13:33 AM UTC, comment #5:
This is strange, even in your scenario described in comment #3, there is only one tab per variable on my system.
|
Fri 25 Aug 2017 09:51:50 PM UTC, comment #4:
It seems like this is limited to two tabs per variable. One tab is opened when inspecting a variable while the editor is docked and one while it isn't. Opening the variable again in the editor doesn't create any more than these two tabs per variable.
|
Fri 25 Aug 2017 09:33:32 PM UTC, comment #3:
It might be that this only happens when one first opens a variable while the editor is docked, then undocking it, and finally opening the same variable again.
|
Fri 25 Aug 2017 08:39:29 PM UTC, comment #2:
Right click > "Open in variable editor"
|
Fri 25 Aug 2017 08:37:06 PM UTC, comment #1:
I can not confirm this behavior on my system. How do you open the variables for editing?
|
Fri 25 Aug 2017 08:09:52 PM UTC, original submission:
When the variable editor window isn't docked to the main window, opening a varable more than once open a new tab each time.
|