Xojo focus issue in IDE causes problems

General
1

I’ve run into what I think is a bit a nitpick, but albeit annoy problem.

Try this (Windows), I have not tried this on the Mac yet.

  1. Open a Xojo project. Make sure that the Inspector is open on the right hand side.
  2. Ctrl-F to open the search and replace.
  3. Search for member function in your project.
  4. Double click on one that you’ve found.

At this point, focus will change from the Find dialog to the inspector, and the member
function will be highlighted (selected and blue) IN THE INSPECTOR.

This is NOT apparent at first glance, and this key to the issue (i.e. Nitpick)

  1. Scroll your mouse or move it, with the notion that your cursor SHOULD be in the code window.
    (You could also start tying here as well, which will change the name of the member function).

You’ll notice that the drop-list of functions will change to another member function or something you typed.

If you’re not paying attention, this will completely mess up your function declaration, and this has
happened to me more than four or five times. Enough for me to warrant asking others if they
can reproduce this – I think this is a pretty glaring UI issue.

The solution is to simply NOT go to the inspector, but go to the code window, or to the Navigator
and highlight the one you found – By going to the inspector (which I understand why), its causing
you to change/modify the name of the function unintentionally.

A nitpick, but I’ve done this enough to get annoyed.

Gary

2

The focus control within the IDE has been messed up since the day XOJO was deployed. And yes it it very annoying.

3

yes

4

I’ve ranted about this several times. Not beating the dead horse again.

5

Yes, because of this issue I have ended with many duplicate methods and code that will not compile because of extra characters that were added while IDE focus was having a fit.

6

Remember that I’ve been using Xojo since roughly December of 2012 during the alpha. Xojo has trained me not to use the keyboard shortcuts. I almost rely exclusively on the contextual menu. The IDE doesn’t have to guess then what the object in question is.

7

I’ve been using it since 2012 as well. But the reason I ran into this now is that I’ve since moved 100% to Xojo for our larger project and hadn’t done as much core development until the last couple months.

It burned me about 10 times last week.

The UI has some design issues that I simply didn’t catch early on until after I really started heavily using it.

The move to decouple the navigator on one side, and the inspector on the other is the issue.

Hopefully, the team will take a look at this. Its really a nightmare.

8

Theoretically this bug is solved in the new release (see #30555).
But those who are Alpha tester can check it, although probably they are not allow to comment it here.

9

I’m not sure I understand the point of having the inspector to the right of the navigator (on the other side of the IDE).
This is really a UI no-no. You’re interacting with an object in the Navigator. Good UI would have you remain within
that are of interest and not take your eyes off that area.

I propose moving the inspector to be UNDER the Navigator. Having them be on one side of the other is really the issue.

If you select something int the navigator, the eyes have to move to the other side of the screen?

That really is the issue for me, and I believe it would resolve the focus issue.

My two cents.

10

[quote=62859:@Gary MacDougall]I’m not sure I understand the point of having the inspector to the right of the navigator (on the other side of the IDE).
[/quote]
Ever used Xcode ? Or the OLD UI which also had the “inspector” on the right.
Or Pages or Numbers or so many other tools that are not just developer tools where you wither have an inspector on the right or as a floating palette.
Its a very common idiom - not saying its right just that when you do a survey of things this is not unusual.

There could be an argument to put the inspector right next to the navigator and make it something you can hide / show as that way your focus is on the left - click something in the navigator show the inspector & its right beside it. (Now don’t misread this for Norm likes this - its just an idea)
But then do you put the library there as well ?

Or, as some have suggested stack the library & inspector - next to the navigator or on the right ?

I’m sure there are things that can be done to improve the overall experience to make it work better

11

The inspector on the right isn’t so bad, only that it takes so much space and that my ageing brain never can remember the order of the properties.

Over the weekend I had to test something for Retina on my 1600x1000something monitor and the IDE was totally useless. That was painful but working on RealStudio. Need a larger monitor…

12

An rMBP running its monitor & two external thunderbolt monitors :stuck_out_tongue:
I don’t think it can run 3 externals

13

[quote=62861:@Norman Palardy]Ever used Xcode ? Or the OLD UI which also had the “inspector” on the right.
Or Pages or Numbers or so many other tools that are not just developer tools where you wither have an inspector on the right or as a floating palette.
Its a very common idiom - not saying its right just that when you do a survey of things this is not unusual.

There could be an argument to put the inspector right next to the navigator and make it something you can hide / show as that way your focus is on the left - click something in the navigator show the inspector & its right beside it. (Now don’t misread this for Norm likes this - its just an idea)
But then do you put the library there as well ?

Or, as some have suggested stack the library & inspector - next to the navigator or on the right ?

I’m sure there are things that can be done to improve the overall experience to make it work better[/quote]

There’s two issues here, one of which is subjective, the other is a bug.

  1. I think there’s a focus bug.

If you do a “Find”, double click on your result in the search. The focus never goes to the code window. Focus moves to the Navigator, then highlights the method name, but also highlights the “found word” – Focus is on the Navigator.

Since you’re finding “code”, you should have the focus and cursor be placed in the code. That’s not really an argument, thats really the way things USED to work in the past. One could argue that you’re finding things in the Navigator, if that were the case, then I would make the Find functionality actually select WHERE you want to search (i.e. Navigator, code… etc.)

  1. There’s a clear UI subjective issue going on.

I have used Xcode and I have used the old product (Version 5 up to 2012). I agree that things can get cluttered.
But here’s the thing you should be looking at. Visual Studio. The way that the “Properties” (which is analogous to the inspector) can be positioned, and the way that the “Solution Explorer” can be situated, you can “stack” things how you like.

The problem right now – for me personally – and yes, this is subjective. The inspector is far to the right and away from where
I’m working to be able to see the properties of the object I’m inspecting.

I think the UI in this area could be improved. Either allow for the user to position the inspector within an embedded tab/stocked metaphor like Visual Studio. Or allow it to be positioned like 2012, which was above the code.

14

I didn’t disagree or even comment on this

Use the floating palette variation & drag it where you want ?

The inspector (properties palette) could never be positioned above the code
The signature for a code item was there - but that wasn’t the “inspector” or properties palette

There IS a feature request for making the signature be above the code item again
<https://xojo.com/issue/25238>

15

There also appears to be a bug report filed for the focus issue.

The floating palette can resolve part of this, but its a bit clumsy – and yes, I was referring to the code signature above
the code window – not the whole inspector. That was incorrect to state that.