bugGNU TeXmacs - Bugs: bug #43373, No "open file" dialog...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43373: No "open file" dialog box after new window

Submitter:  Punto Di Rosso <puntodirosso>
Submitted:  Tue 07 Oct 2014 02:02:33 PM UTC
   
 
Category:  Qt port Priority:  5 - Normal
Item Group:  Error Status:  Fixed
Privacy:  Public Assigned to:  mgubi
Originator Name:  Open/Closed:  Closed
Release:  None Release:  1.99.21
Fixed Release:  None Fixed Release: 
Keywords: 

Jump to the original submission

Sat 28 Oct 2023 03:24:33 PM UTC, comment #16: 

This fix introduced a problem for embedded widgets:
when opening a search & replace window,
both the search and replace fields receive focus.

I reverted the implementation of embedded widgets to
the old one in revision 14211.

Joris van der Hoeven <vdhoeven>
Group administrator
Fri 27 Oct 2023 04:48:27 PM UTC, comment #15: 

Thanks for your work on this, Philippe.
I applied your patch in revision 14205.
It seems to work under MacOS.
Please reopen in case of problems.

Joris van der Hoeven <vdhoeven>
Group administrator
Mon 23 Jan 2023 08:36:18 PM UTC, comment #14: 

The attached patch fixes the issue (as described in #11).

Tested to work on linux & windows builds with Qt 5.15. Could a MacOS user tell if the issue is present on Mac and if so, if the patch solves it?



(file #54256)

Philippe Joyez <pjoyez>
Group Member
Sun 15 Jan 2023 02:11:47 PM UTC, comment #13: 

What I proposed in the previous comment correctly gives focus to the second window only when using the keyboard shortcut Ctrl-N, but not when using the File->New menu (or File->Open, File->Recent ...).

In the case we use menu to open the second window, the debug-qt output shows that, after I have explicitly activated the 2nd window, the first window temporarily gets the focus back (I guess its because of the refresh when closing the menu), but focus is not returned to the second window. So we are back to square one : none of the windows has focus.

Philippe Joyez <pjoyez>
Group Member
Sat 14 Jan 2023 10:23:09 AM UTC, comment #12: 

Adding something like

QApplication::setActiveWindow(concrete(win)->qwid);

at line 195 in tm_window.cpp fixes the bug.

there are already a couple of #ifdef QTTEXMACS in this file so I guess it should not be a major problem to further #ifdef QTTEXMACS this (and the appropriate include).

Philippe Joyez <pjoyez>
Group Member
Mon 09 Jan 2023 06:47:42 PM UTC, comment #11: 

This bug is back! It's occuring with Qt 5.15 in Linux and Windows (I can't test MacOS).

How to reproduce : Start Texmacs in the default configuration (with documents in separate windows - you can clear your .TeXmacs folder). Once started, press Ctrl-N or select "New" in the file menu. A new widow comes up. It seems to have focus, but if you start typing text, it is not taken into account. As well, if you select some menu items (such as  File->Open) in the newly created window, nothing happens (object of the original bug report). If you run TeXmacs with --debug-qt you realize that (despite the appearance) TeXmacs has no "foused" window once the new window is created, which explains the behavior.

It's most likely a Qt-related problem because with the AppImages (Qt 5.6 and Qt 5.12) the newly created window is properly activated: it receives text typing and all menu items operate normally. I guess the previous comment was with an earlier Qt version, but I cannot retrace what Qt version I used at that time (maybe I ran a Qt5 AppImage, already).

In order to solve this we would need to make sure that a newly created window really gets proper focus, working around what seems a Qt bug or shortcoming.




Philippe Joyez <pjoyez>
Group Member
Fri 04 Feb 2022 11:55:02 AM UTC, comment #10: 

Good news : the problem does not occur in Qt5 builds! (it is still present in Qt4 builds)

Philippe Joyez <pjoyez>
Group Member
Sat 12 Jun 2021 12:44:56 PM UTC, comment #9: 

A form of this bug is still present in V. 1.99.21 with the latest official xUbuntu_18.04 deb package, starting with a fresh ~/.TeXmacs folder. It does not seem to depend on the language settings unlike a previous comment of mine was suggesting. It is not occurring on windows.

The bug is triggered through very basic actions that new users are quite likely to perform and from which they would certainly conclude texmacs is just unusable. OTH, when you know the workaround the bug is just a minor annoyance (I've been coping with it for years).

Steps to reproduce:
Launch texmacs. It opens a window with a new blank document or the welcome if you've just cleared the  ~/.TeXmacs folder; let's call it doc1.

In the File menu, click “load” to bring up the file chooser dialog. Navigate to an existing tm document, and open it. The chosen document (doc2) comes up (in the same or a new window depending on the preferences). Note that if you open the doc2 through File>recent instead of File>load, the bug won't occur.

Now in the window showing doc2, once more go to the File menu and select “load” or “new”. Nothing happens. The corresponding menu shortcuts do not work either.

Workaround: if you click in the text of doc2 (before or after the bug occurs), File>load or File>new subsequently properly work.

The original report was about using the menu View>New window. The bug may indeed occur following such action, but there seems to be some context involved which I have not fully figured out.

When running texmacs with -d, nothing is reported on the console when you trigger the bug. However when you click in the doc2's window, you'll see

TeXmacs] debug-keyboard, Got focus at 63618

after which the shortcuts are noticed :

TeXmacs] debug-keyboard, Pressed C-o at 74203

So it seems the problem is that the window just does not fully have focus prior to clicking into it (and that's why I had proposed comment #5).

Philippe Joyez <pjoyez>
Group Member
Sun 01 Nov 2020 05:11:36 PM UTC, comment #8: 

I just tried on two virtual machines with Ubuntu and Manjaro Linux (the second one being based on Arch Linux) and I could not reproduce the problem (English language settings).  So I assume that the issue has been solved by now (revision 13052, upcoming release 1.99.14).

Please re-open if you still experience this bug.

Joris van der Hoeven <vdhoeven>
Group administrator
Sun 25 Jun 2017 11:01:25 AM UTC, comment #7: 

I just tested in linux, and the problem was still there. But clearing my preferences solved it...

Looking further it seems that the occurrence of the problem depends on the language setting! The default on my system (French) works fine but if I set ("language" "english") the bug occurs. Actually anything other than "english" seems fine. Weird.

Philippe Joyez <pjoyez>
Group Member
Fri 23 Jun 2017 05:13:04 PM UTC, comment #6: 

I just tried on my Mac for version 10674 and noticed no problem.
Does the problem still occur on your systems?

Joris van der Hoeven <vdhoeven>
Group administrator
Thu 16 Mar 2017 09:34:44 PM UTC, comment #5: 

marked bug #44452 as duplicate.

This issue seems fixed by the simple change
 ("Open new window" (open-window))
to
 ("Open new window" (window-focus (open-window)))
in view-menu.scm (and file-menu.scm)

I will test it further before risking a commit.


Philippe Joyez <pjoyez>
Group Member
Wed 01 Mar 2017 09:07:03 PM UTC, comment #4: 

This bug still exist, but there is a much simpler fix than th eone suggested in #2:  just click in the new window prior to using the menu. Probably there should be a way to do this programatcally (and automatically).

Philippe Joyez <pjoyez>
Group Member
Mon 10 Nov 2014 06:58:38 PM UTC, comment #3: 

Thanks for the trick!

Punto Di Rosso <puntodirosso>
Thu 06 Nov 2014 05:09:17 PM UTC, comment #2: 

Using the lastest source compiled in Debian, I confirm the problem: In the newly open window the menu File/load does not open the file dialog (works fine from the first window's menu). No error message is shown.

You can sort of "repair" that broken menu item by bringing up a file dialog by another way, for instance using:
- the menu Insert/link/include in the new window,
- the File/load menu from the first window,

Subsequently the File/load menu also opens the dialog in the new window.


Philippe Joyez <pjoyez>
Group Member
Fri 24 Oct 2014 09:41:56 AM UTC, comment #1: 

If I do the same things and try to search the help with F1 on the new windows nothing happens either.

Punto Di Rosso <puntodirosso>
Tue 07 Oct 2014 02:02:33 PM UTC, original submission:  

System is Arch linux with gnome (gnome-session version is 3.12.1).

I have noticed the following behavior.

After starting Texmacs, TeXmacs opens with an empty document titled "No name [1]". I select open a new window (e.g. from the icon bar). A new windows appears with an empty document titled "No name [2]". I select "File -> Load" or use the "load" button in the icon bar but nothing seems to happen, i.e. no "open file" dialog box appears.


Punto Di Rosso <puntodirosso>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #54256:  fix43373.patch added by pjoyez (1KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pjoyez
  • -email is unavailable- added by vdhoeven (Posted a comment)
  • -email is unavailable- added by pjoyez (Posted a comment)
  • -email is unavailable- added by puntodirosso (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-10-27 vdhoeven CategoryNone Qt port
        StatusReady For Test Fixed
        Assigned tovdhoeven mgubi
        Open/ClosedOpen Closed
    2023-01-23 pjoyez Attached File- Added fix43373.patch, #54256
        StatusIn Progress Ready For Test
        Carbon-Copy- Added mgubi
    2023-01-14 pjoyez StatusConfirmed In Progress
    2021-06-12 pjoyez StatusWorks For Me Confirmed
        Open/ClosedClosed Open
        Release1.99.2 1.99.21
    2020-11-01 vdhoeven StatusIn Progress Works For Me
        Open/ClosedOpen Closed
    2017-06-23 vdhoeven Item GroupNone Error
        Assigned toNone vdhoeven
    2017-03-16 pjoyez StatusConfirmed In Progress
    2014-11-06 pjoyez StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code