[resolved] BUG Search Panel Change
After updating to 6.3 this afternoon I have noticed a new Bug. When searching on a word or phrase in Bible, and then changing the search type from Bible to Basic and running the same word search, the entire set of results is offset, so that there is a wide bar of empty space on the right, with much clipped and unviewable on the left, scrolling is not an option This remains the same regardless of collection searched. It does not seem to be a problem when going from Basic to Bible. - OSX 10.9.5, Logos 6.3.0.0038
Comments
-
I don't see this on Windows - interesting to see if another Mac user can check this.
0 -
Graham Criddle said:
I don't see this on Windows - interesting to see if another Mac user can check this.
Neither do I on a Mac - when I tried it the program crashed. :–(
though what I didn't notice was that logos was updating and indexing (Lexham Bible Dictionary) at the time.
now it has stopped I am able to the swap in search just fine.
tootle pip
Mike
How to get logs and post them.(now tagging post-apocalyptic fiction as current affairs) Latest Logos, MacOS, iOS and iPadOS
0 -
I don't see this on Mac either...
Could you provide more details? Which view are you in when doing the Bible search & which view in the Basic search?
0 -
Reuben, I am quite familiar with the technical use of the term "view" as a method of aggregating and presenting data from various tables into a single place that appears to the user as if it were a table. However if you are using it in any other sense, I am simply not sure what you are asking for. The screen shots show which resources and choices I had made. I am not familiar with any other options that are not displayed in those screen shots.
Here is the exact process I have been using. I open a search pane (which manner of opening seems irrelevant, I have tried several with the same result). The search pane defaults to Bible since that is where I make many of my searches, however, even if I open first to basic search, once I run a search any Bible switch and then change to Basic, ANY search I run in that same pane will come back with the same offset error. This is consistent and consistently repeatable.
At this point the only way to run functional basic searches is to have a separate search pane for basic searches and one for Bible searches.
Interestingly enough, I have a laptop I also use. I have the same identical issue on the laptop. However, I did just discover that if I click on the + in the upper left it will reset the search pane results when the window resizes.
The other interesting thing is that on the laptop's smaller screen, there is also a scroll bar that is offset as well as text clipping that helps demonstrate the both vertical and horizontal offset.
0 -
Any change to the window that causes the pane to resize seems to take care of the offset problem. For example, with the screen shot above, once I closed the Copy Bible Verse pane, the search and Bible panes resized and the offset was corrected, at least until the next time I trigger it.
These are using different layouts. The first screen shot was taken on my iMac with multi monitors, the last one was on a laptop with no external monitors connected.
Please let me know if there is any other data I can provide.
0 -
Tim said:
Please let me know if there is any other data I can provide.
Do you have Program Scaling (in Program Settings) set to something above 100%? Or text size in the slider from the panel menu? It looks like the text size in the search panel is larger than the UI.
I can reproduce this with >100% program scaling, and I'll make a case for development to fix.
0 -
At the moment I have the Logos preferences set at 100% and have for a few days. I dropped it down from 140% on Friday or Monday trying to prevent a whole different issue in notes with the default font size always being 16, but that is a different issue that I haven't had time to bring up, and is a lesser priority because is has a much smaller impact on my study. I tried tinkering with the pane zoom and have been generally running at 1 notch greater than mid, however the problem is consistent regardless of where my zoom is set, even if I drop it down to mid or lower. The effects are less, but the offset still occurs.
With Mac settings, I have both the iMac and MBP set at Apple's default.
The reason I keep saying offset rather than size or zoom is because of what is most apparent in the screen shot from my laptop with the scroll bar and text clipping. The display is offset from the pane, both vertically (higher) and horizontally (to the left).
Also, switching to another tab on the same pane will cause the results to reset into a normal position once I switch back.
0 -
Tim said:
I tried tinkering with the pane zoom and have been generally running at 1 notch greater than mid, however the problem is consistent regardless of where my zoom is set, even if I drop it down to mid or lower.
If you have Program Scaling set at 100%, try setting the Zoom in the Panel menu to the 3rd notch. In my testing, that should work properly.
And I understand your distinction for the word "offset", but the offset behavior is a bug we've seen in a few areas of the app, and it's related to Program Scaling or resource zoom.
0 -
You are correct that at that particular scaling, the problem does not occur. However, while you may be still blessed with good visual acuity at a smaller scale, at that setting I cannot read anything without giving myself a headache. Hopefully a fix will be available soon. I will just deal with it using my workarounds for now. Thanks.
0 -
Tim said:
You are correct that at that particular scaling, the problem does not occur. However, while you may be still blessed with good visual acuity at a smaller scale, at that setting I cannot read anything without giving myself a headache. Hopefully a fix will be available soon. I will just deal with it using my workarounds for now. Thanks.
I understand, and you'll be pleased to hear a fix for this should be in 6.3 SR-1, which should be available next week.
Program Scaling at 100% and the text slider on 3rd notch is the "default", which is why it worked correctly.
0 -
Dylan Rondeau said:
I understand, and you'll be pleased to hear a fix for this should be in 6.3 SR-1, which should be available next week.
6.3 SR-1 is now available, including a fix for this issue.
0 -
Thank you! I can confirm that this resolved not only this problem but another note text related scaling issue.
0
