Better keyboard support so you wouldn’t have to use the mouse so dang much.
The issue is focus rings. Each property is a container control, and if you bring the controls to close to the edge of the container, their focus rings draw wrong.
No objection. I think there was desire not to require scrolling, which is futile of course.
Its advantageous in this case. It allowed us to place the property name on the left, making the inspector more consistent. Since the design was going to be non-standard in some way (either by placing a lone checkbox to the right of a label or using a custom control) it was decided to use something custom that people normally see in this configuration anyway. And just because iOS introduced the control, doesnt mean a switch control hasnt become fairly common on other platforms. Apple uses one in certain places in macOS, such as Time Machine preferences. Its not uncommon on websites. I think this feeling that it started on iOS, it should stay there isnt really grounded in reality these days. I wouldnt object to some style changes, as it looks a bit dated, but I rather this than some awkward checkbox sitting alone in the space.
Funny. While I read your post, I was thinking that the best replacement for switches would be a checkbox or radio button. It is more compact and just as obvious and explicit. I guess that no UI design can please everyone!
In the end, I just want it to work well.
Or you could have done a no caption checkbox with a label on the left and that way it’s consistent with the rest of properties. A listbox would have been simpler and easier to implement since you could have reused the Real Studio properties list.
Honestly, if you look at scads of other IDE’s (which I have in the last month) many are using a simple checkbox. I think Xojo overthought it. But what’s done is done and undoing it is not a priority nor the more important thing.
The layout for each property should be dynamic. So when you resize the panel, if there’s not room for the name, it should drop the switch, textfield etc down and move the name over and above it rather than just clipping the label…
Scrolling is OK! It’s why mice have wheels.
Same for Method inspectors…
[quote=465856:@Bob Keeney]
Or you could have done a no caption checkbox with a label on the left and that way it’s consistent with the rest of properties. A listbox would have been simpler and easier to implement since you could have reused the Real Studio properties list.[/quote]
I know, thats why I said either by placing a lone checkbox to the right of a label. We pretty much had to go with a non-standard design, so we went with one that is more traditionally caption-then-control.
Back to the REAL.Studio vs. Xojo comparison, I will always prefer the RS version:
The main reason I asked the opinion question was that I am building a custom Property Inspector control (for my own use for now, but perhaps when API2 settles I might offer it out, its all AP1 code now)
I like features of both. (these are MY opinions of course) 
Old version
-
pro - items are all on one pane
-
con - font is too small
-
con - items are too close together
-
con - uses fake dropdowns
New Version
-
pro - looks nicer (my opinion)
-
pro - switches instead of checkboxs (my opinon, the one I’m making supports both)
-
pro - uses popup menus instead of fake dropdowns
-
con - too much space between items
-
con - font data on 2nd page
I agree that I would like a more practical rather than pretty inspector that takes less space than the current one. And checkboxes are fine!!! In fact the more standard controls used the better (BTW IMO Xojo inc should NEVER create a new control JUST for the IDE… if they are going to create one then it should be cerated for general use- That is eating ones own dog food!)
Looking at other IDE’s with Listboxes for inspectors one would initially say they don’t look good and are too busy … but they could easily look better…
I think a listbox based inspector would be best with the following suggestions…
Make the row Height a bit bigger than the default … Just enough so it does not look too dense but does not table up too much space… i do that all the time to make listboxes a bit easier to read/scan and it does make the UI more attractive. That would take up a lot less space than the current one but still not look too dense… The row height could easily be made a user preference then… I like some white space for readability but others might prefer more compact
Of course it should be hierarchical with sections headings being at the lowest level. In some cases (maybe position locks) groups setting could be a second level.
Each section header should be colored too stand out with different or alternating (for when collapsed)
One should be able to collapse all sections or or expand an single section optionally with it’s subsections but keyboard or menu.
And of course it should be scrollable… and IMO the only things on the “gear” panel should be things like attributes, if even that… Certainly not fonts!
A listbox based inspector can look good, though it would not be as pretty and the current one… but it would be more practical. While looks do matter in they end they are not the MOST important thing… IMO anything that makes working in the IDE more efficient/easier is more important than being the MOST beautiful.
- karen
Its a listbox - make it so you can increase the font size and the row size increases accordingly ?
make it so there is “row padding” - ie/ if the font would fill the cell then add some padding to the row height to make it so they are not crunched together ?
cant do much here since you cannot embed native control in the listbox
Hear, Hear!
I believe that every element of the IDE and Feedback should have an example provided if they were created in Xojo.
Norm… you observations are moot, since those applied to the OLD property inspector (and I don’t think Xojo allowed the user to change any of those)…
I believe that Norman was responding to what you’re doing and providing tips on how to get your wanted results in the property inspector you’re building.
my control is not based on a listbox, nor as it seems the new Xojo PI is, based on a collection of container controls. It uses native controls where possible (except for my colorwell and switch, but both of those ARE available as developer controls as a side benefit of this control). I have constants to control all the various spacing so they can be tweaked as required…(and I still have a bit to do)
but here is what MY Property Inspector looks like now (subject to change at my whim)
This is a non-retina shot
The current Xojo inspector is also a container with embedded containers which use native controls where possible
No magic to that
Doing things dynamically like while dragging to resize can be slow for something like https://forum.xojo.com/conversation/post/465861
I did try that and it made things quite slow and laggy - hence why it doesnt do that now
A listbox avoids certain of those issues but has other inherent issues
Its all trade offs
Norm… you misunderstood… Mine does not have embedded container controls, just embedded control sets
and uses a canvas as the scrollable “parent”… the only container control is the base
sure - lots of ways to achieve the same end goal and it really doesnt matter whether its containers embedded in containers or control sets
it still has similar issues if you want control labels right aligned and its resizeable horizontally and want controls to restack themselves as the entire thing is made larger / smaller
the same issues exist either way - just different internal implementations
Wow. The RS inspector looks way better!
I really like the Visual Studio design - a simple list with EVERY property shown.
[quote=465992:@Tim Jones]Back to the REAL.Studio vs. Xojo comparison, I will always prefer the RS version:
[/quote]
I never understood why put some properties under the machine icon tab that is 70% empty.
And then there is the variable inspector in the debugger: now that it’s at the bottom, I can only see 1/3 of the variable I could see with RS when it was in a column on the right. Monitors are wider than they are tall, so I see less source and fewer variables compared to when the variables were displayed in a column to the right of the source code. If you have to do it this way, AT LEAST stop scrolling back to the top with each step, forcing me scroll back down to see variable names further down the alphabet! But this is another conversation…