Qucs / qucs

Qucs Project official mirror
http://qucs.sourceforge.net/
GNU General Public License v2.0
1.15k stars 213 forks source link

File name in tab is not updated when using 'Save As...' #228

Closed in3otd closed 9 years ago

in3otd commented 9 years ago

This just changed recently... Open a schematic, save it with a different name using "Save as...": the file name shown in the tab is not updated...

Edit: similarly, when you simulate a schematic, the corresponding Data Display tab opened at the end of the simulation shows an extension .sch (but is correctly saved as .dpl)... Edit: this latter issue moved to #229

yodalee commented 9 years ago

You can create a hotfix, the previous problem is caused by this. The this should be w. https://github.com/Qucs/qucs/blob/master/qucs/qucs/qucs.cpp#L1533

in3otd commented 9 years ago

...ok, this fixes the first problem, but not the second (the Data Display window shown as .sch instead of .dpl.

~~Moreover I get "random" crashes, when closing a tab. Did not yet find a repeatable sequence to reproduce the bug, but after opening/simulating/closing a few tab Qucs crashes. Here is a gdb backtrace of a crash happened when closing a tab, don't know how valid it is~~

~~0 0x00000003 in ?? () #1 0x08071331 in QWidget::setHidden (this=0x91ecb30, hidden=true) at /usr/lib/qt/include/QtGui/qwidget.h:495 #2 0x0807b9ea in QucsApp::slotHideEdit (this=0x91dce20) at qucs.cpp:2630 #3 0x080839cd in QucsApp::closeFile (this=0x91dce20, index=1) at qucs.cpp:1623 #4 0x08083ea4 in QucsApp::slotFileClose (this=0x91dce20, index=1) at qucs.cpp:1613 #5 0x0810a99e in QucsApp::qt_static_metacall (_o=0x91dce20,``_c=QMetaObject::InvokeMetaMethod, _id=12, _a=0xbf958938) at qucs.moc.cpp:269 #6 0xb74eedd5 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #7 0xb6eac665 in QTabWidget::tabCloseRequested(int) () from /usr/lib/libQtGui.so.4 #8 0xb6eac8d9 in ?? () from /usr/lib/libQtGui.so.4 #9 0xb74eedd5 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #10 0xb6ea0325 in QTabBar::tabCloseRequested(int) () from /usr/lib/libQtGui.so.4 #11 0xb6ea03c9 in ?? () from /usr/lib/libQtGui.so.4 #12 0xb74eedd5 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) ()``from /usr/lib/libQtCore.so.4 #13 0xb70d7f6d in QAbstractButton::clicked(bool) () from /usr/lib/libQtGui.so.4 #14 0xb6df0881 in ?? () from /usr/lib/libQtGui.so.4 #15 0xb6df1c17 in ?? () from /usr/lib/libQtGui.so.4 #16 0xb6df1d1e in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #17 0xb6a372ca in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4 #18 0xb6df2d22 in QAbstractButton::event(QEvent*) () from /usr/lib/libQtGui.so.4 ....~~ Edit: this latter issue moved to #230

yodalee commented 9 years ago

This is funny, it crash at slotHideEdit, which hide the text input when you open a component property.

yodalee commented 9 years ago

OK, I think I found it. The crash is happened when you focus on the textedit of component property, and try to close file. Directly call slotHideEdit() will cause crash though the reason is not clear. Add one line of editText->clearFocus(); can solve this problem. But there is more, in some place of qucs.cpp it still call editText->setHidden(true);, they will still crash. So we need to change all direct call to call slotHideEdit()

in3otd commented 9 years ago

There is another issue... file names with dots are not shown in the project content: create a Project, create a file named MyFile_v0.1.sch and you will see that it is not shown in the project content. Edit: this issue moved to #231

@yodalee, did you actually use Qucs after the modifications you did ?? I found all the problems above in less than 1 hour of using it...

yodalee commented 9 years ago

Well, I didn't use Qucs frequently. Actually I suggest you open up new issue for every problem you found, and we can track them easily. The third issue is cause by the projectView.cpp:111, it use completeSuffix() rather than Suffix(), so you will see new file in Other category but Schematic

in3otd commented 9 years ago

ok, I will open separate issues for all these problems.

I understand it can be difficult to find the time to thoroughly check the code changes - we are all all quite time constrained - but may I suggest you to ask (here and/or on qucs-devel) others to check your branch before merging if you think that more testing is needed, at least later you can say we were warned if somebody complains :grin:

ra3xdh commented 9 years ago

@yodalee , Maybe you should take a pause in development of Qucs? If you cannot test your own changes you should not make a global changes in Qucs. We have no our own QA team for you. The bugs in your last changes are very dangerous and can put Qucs into chaos. Take into account that many people use latest Qucs version from master branch on Github to make work with it. Carefully check what you merge in master! It's not a experimental polygon in a full sense. You can come back, when you will have more time for Qucs.

yodalee commented 9 years ago

Actually I test the changes I made (like projectView), but that is a corner case I didn't find out. In real project there is many way to prevent this, like create a develop branch. The develop merge into release after a period of time. After testing and bugfix, the release can merge back to master. But the qucs doesn't use this kind complex branch model.

in3otd commented 9 years ago

In the end, it is always the same problem: there are not enough people working on the Qucs development. Even if we adopt the develop and release branches approach, there will not be enough people to test both. Sure, once develop has been sufficiently checked, there should not be many uncovered issues remaining in master, but this will not guarantee there will be none, the time spent verifying the code in develop will mean less time to verify master.

An unwritten rule that I thought was adopted for Qucs is that one does not merge its own pull requests, but patiently waits that someone else finds the time to independently check the pull request and merge it after reviewing it. But again, this does not work if there are not enough developers who can find the time to merge the pull requests, so I am not stigmatizing those doing it, but, as said, I will suggest to write a short message before doing this to directly ask for an independent review of the changes and if nobody can find the time to help, well, merge and see what happens...

in3otd commented 9 years ago

"Save as..." file name update fixed in PR #235 (commit 0d373ce838d94e022e72bf56c481b038cf7c20f8)