Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Searchboxes #303

Merged
merged 7 commits into from
Oct 19, 2015
Merged

Searchboxes #303

merged 7 commits into from
Oct 19, 2015

Conversation

in3otd
Copy link
Contributor

@in3otd in3otd commented Jul 8, 2015

The refactor done some time ago on the Project View brought also a nice (instant) search box, at the bottom of the Components tab. But when doing a search, the string shown in the combo box at the top of the Components tab, normally used to select the components family shown, did not change so it was something confusing, since the components icons shown were actually the results of the search.
So I changed the code to show "Search results" in the combo box when searching, to made things more clear.

Then I recalled that also the Library Tool has a search function, for the library components of course, and thought it will be nicer if it had the same kind of instant search function. The current search is not so user friendly, as one needs to click a first button to open the Search Dialog, then press search after entering the string in the Search Dialog, then click a second button to perform the search. And repeat all this again if you would like to do another search. So I changed also the Library tool to have the same kind of search, with a similar appearance to the Component Search in Qucs.

Please check if everything still works fine on your side also.

qucs_lib

(Will be nice to add the same kind of search to the Libraries Tab in the main Qucs GUI, one day, maybe...)

@guitorri guitorri added this to the 0.0.19 milestone Jul 18, 2015
@guitorri
Copy link
Member

The "Search results" is nice. However, your patch also changed the previous behavior. If you did a search and then selected one component, it would set the family related to that component when the search is cleared. The idea was to take the user to the 'box of components' where he/she is picking the item from. I think it helps people to learn where to find stuff. Shall we keep the previous behavior?

The search on Qucs-lib is welcome. Can we extend it to search also in the user_lib which can be either in the QucsHomeDir and/or inside a project directory.

We also need a search function for the 'Edit Component Properties", for the list of parameters. I have a half-working version on a experimental branch for bsim6 (which has some 700 parameters). I will dig it out.

Other than that, it is working great on my side.

@in3otd
Copy link
Contributor Author

in3otd commented Jul 18, 2015

ah, so the previous behavior was intended 😕 ... I purposely changed it to return to the last used component family, since I found it distracting. But I understand it can be helpful for new users to learn where the components are. Should not be too difficult to restore the previous behavior, let me take a look. This also reminds us (me) we should try to document the intended GUI behavior somewhere.

I didn't notice that the user_libis not searched, will fix that.

For BSIM6, you can really have an 'Edit Component Properties' dialog with so many parameters listed?? I understand you need a search there...

@guitorri
Copy link
Member

Yes, UI documentation is lacking... this should guide the development, not the other way around.

@in3otd
Copy link
Contributor Author

in3otd commented Jul 26, 2015

I have restored the previous search behavior and included the User Libraries in the search.

Re-reading your comment "user_lib which can be either in the QucsHomeDir and/or inside a project directory" I'm not sure I understood/agree: AFAIU the User Libraries can not be in a project directory, right??

...just saw there is more work to do: the user_lib location is not defined correctly in qucs-lib/main.cpp as it uses QDir::homePath() instead of QucsSettings.QucsHomeDir as parent of /user_lib/, will correct that later...

in3otd added 6 commits July 26, 2015 22:46
When using the Component Search in the Components Tab the component
category shown in the top combo box was not changed, but still showed
the last used category. Now when searching, the category text shown is
changed to "Search results" and restored to the last used category
when exiting the search.
The ToolTip for the "verilog-a user devices" icons was not using
the translated string.
The Library Tool was using a somewhat cumbersome search, forcing
the user to open a separate dialog for searching.
A search box is now included in the main Library Tool window and
provides an 'instant search' feature, like the main Qucs window
does for the standard component search.
The old Search Dialog widget files are removed.
Previously the user libraries were shown in the selection list but
not actually used when searching for a component. Now the list of
searched libraries includes also the user libraries.
@guitorri
Copy link
Member

You are right, user_lib should be inside QucsHomeDir.

@in3otd
Copy link
Contributor Author

in3otd commented Jul 27, 2015

corrected the user_lib/ location definition in qucs-lib/main.cpp
Might be nicer squashing some commits, let me know.

Not strictly related to this PR: looking around the code I have somewhat the feeling that the various paths handling is not always done properly: e.g. do the definitions here work correctly also for user installing in a non-default directory from precompiled packages? I saw that in the Qucs main GUI these are defined differently in a way which should work in all cases, but most of the tools use the former definition.

@guitorri
Copy link
Member

I am confused. On Windows the compiler is complaining about

C:\projects\qucs\qucs\qucs-lib\main.cpp:93:36: error: 'homeDirPath' is not a member of 'QDir'
   QucsSettings.QucsHomeDir.setPath(QDir::homeDirPath() + "/.qucs");
                                    ^

I guess it should be QDir::homePath(), but why is this building on Linux/OSX ?!

@guitorri
Copy link
Member

Forgot the AppVeyor log reference:
https://ci.appveyor.com/project/qucs/qucs/build/1.0.229#L845

@in3otd
Copy link
Contributor Author

in3otd commented Sep 17, 2015

uhm, just noticed that cmake fails also on Linux... I (almost) always use the autotools and didn't notice that compiling with cmake failed.
Apparently with cmake the macro QT3_SUPPORT is not defined when compiling main.cpp, so the deprecated function is not found. How comes that it was possible to compile until now, given that we still have lot of Qt3 deprecated functions, I have no idea.
Could you/someone please take a look at this, I'm not familiar with the cmake stuff, thanks!

@in3otd
Copy link
Contributor Author

in3otd commented Sep 17, 2015

BTW, of course the right fix is to use QDir::homePath() (will do) but I was wondering why cmake is not defining QT3_SUPPORT

@in3otd
Copy link
Contributor Author

in3otd commented Sep 17, 2015

I have changed QDir::homeDirPath() to QDir::homePath(), now here it compiles also using cmake. Still, I would like to understand why QT3_SUPPORT is not defined when using cmake...

Corrected location of User Libs: now 'user_lib/' is assumed to be
located in QucsSettings.QucsHomeDir instead of homePath() + '.qucs/',
so that it will be correctly found even if the user changed the
default Qucs home (user) directory.
@guitorri
Copy link
Member

About 50% of the time, qucslib crashes on launch on OS X.
Not sure if this is new... I don't use qucslib that much.

[in3otd-searchboxes]~/git/qucs/qucs $ ./qucs-lib/qucslib 
QWidget::setMinimumSize: (/SymbolWidget) The largest allowed size is (16777215,16777215)
QWidget::setMinimumSize: (/SymbolWidget) The largest allowed size is (16777215,16777215)
Assertion failed: (winRgnBounds.size.height <= 1000000), function CGSNewWindowWithOpaqueShape, file Services/Windows/CGSWindow.c, line 594.
Abort trap: 6

And the crash report:

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
Assertion failed: (winRgnBounds.size.height <= 1000000), function CGSNewWindowWithOpaqueShape, file Services/Windows/CGSWindow.c, line 594.


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff954b2866 __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff8bc9035c pthread_kill + 92
2   libsystem_c.dylib               0x00007fff890d8b1a abort + 125
3   libsystem_c.dylib               0x00007fff890a29bf __assert_rtn + 321
4   com.apple.CoreGraphics          0x00007fff90cbe000 CGSNewWindowWithOpaqueShape + 1229
5   com.apple.AppKit                0x00007fff8fa2ab36 _NSCreateWindowWithOpaqueShape2 + 540
6   com.apple.AppKit                0x00007fff8fa29a21 -[NSWindow _commonAwake] + 3720
7   com.apple.AppKit                0x00007fff8fa286f7 -[NSWindow _makeKeyRegardlessOfVisibility] + 85
8   com.apple.AppKit                0x00007fff8fa28670 -[NSWindow makeKeyAndOrderFront:] + 29
9   QtGui                           0x000000010ffd70f3 QWidgetPrivate::show_sys() + 1139
10  QtGui                           0x0000000110099738 QWidgetPrivate::show_helper() + 408
11  QtGui                           0x0000000110099a6f QWidget::setVisible(bool) + 511
12  qucslib                         0x000000010ff5eb7b QWidget::show() + 27 (qwidget.h:497)
13  qucslib                         0x000000010ff5e43a main + 1770 (main.cpp:125)
14  libdyld.dylib                   0x00007fff88a1b5fd start + 1

Do we have to set the size? 😕
I will poke it a bit tomorrow.
When it works... it works as advertised! 😄

@in3otd
Copy link
Contributor Author

in3otd commented Sep 18, 2015

? I guess the crash comes from (this line) [https://github.com/in3otd/qucs/blob/master/qucs/qucs-lib/symbolwidget.cpp#L452] but I have no idea why. I have never seen qucslib crashing here. Do you have any user library installed? Can you place components from the Library Tool to the schematic?

@guitorri
Copy link
Member

You are right. The y1, y2, ..., variables are not initialized and for some reason these are picking up garbage. Sometimes very large numbers are picked up, hence failing on the mentioned assert...
I will send you a PR.

@guitorri
Copy link
Member

I will merge this and send another PR with the fix for the mentioned crash on OSX.
Thank you!.

guitorri added a commit that referenced this pull request Oct 19, 2015
@guitorri guitorri merged commit 6c8badc into Qucs:master Oct 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants