Regaining IDE Efficiency: Property Inspector
Tom Glod
tom at makeshyft.com
Thu Aug 9 09:41:36 EDT 2018
great breakdown of the issues...... i have been ramping up tp sit down and
make all those notes..... its hard to do when you go work to do. So thanks
Curry for going through that.
Once these are fixed, I think the IDE will be quite good.
On Thu, Aug 9, 2018 at 9:23 AM, Paul Dupuis via use-livecode <
use-livecode at lists.runrev.com> wrote:
> I second Curry's list of LC 9.0.0 IDE issue - especially when the PI
> resizes itself switching between tabs to cut off display of fields below
> the current window size.
>
> My understanding from something I (think I) saw on this list was that
> 9.0.1 is focused on IDE improvements. I have not yet downloaded 9.0.1rc
> (my bad) but can any others who have downloaded comment if the IDE, and
> PI in particular, is, in fact, improved? If so by how much (guestimate)?
>
>
> On 8/9/2018 4:29 AM, Curry Kenworthy via use-livecode wrote:
> >
> > Howdy Folks,
> >
> > As more client projects have caught up with 9, now I'm currently
> > spending the majority of my time in LiveCode 9 IDE. That's both good
> > and bad. The bad is that the 8/9 IDE's UI is much less efficient and
> > much less polished than 6 was. And I'm starting to feel the cumulative
> > impact of the less efficient and more tedious UI during my work! I
> > like an efficient environment. That way I can get more work done in
> > less time for my clients and addon users, and also train people how to
> > accomplish tasks very easily in LC.
> >
> > Some time ago I mentioned that the big IDE update was more of a
> > downgrade, when it comes to UI and UX; way too many good things lost
> > in the remake, very obvious to a hands-on user. But specifics were
> > desired, and I didn't have any opportunity to focus on that until now
> > when I'm dealing with these things daily while I work. So I'm starting
> > to compile a big list of the current IDE defects. I will be filing QA
> > report(s) on these soon. Obviously a big win-win for LC.
> >
> > Posting here first, in case any of these are already filed (please let
> > me know, I'll sign on) or anything to add.
> >
> > I'm starting with the Property Inspector.
> >
> > PI Fields:
> >
> > - PI fields don't scroll with mouse scrollwheel. None of them do.
> > (Sometimes the group containing them can do so, but that's not very
> > well-designed or consistent either; more on that below.) Just paste or
> > type more text than the field's current height, and then try the
> > scrollwheel - nothing.
> >
> > - PI Tooltip field is short, only one line high, can't resize unless
> > you resize window or visit another tab and back. Window can't resize
> > taller unless you visit another tab; tedious.
> >
> > - Some PI fields are resized to their content height, but that causes
> > side effects. If a field contains too much text, the window may be
> > resized extremely short and when changing to other PI tabs, controls
> > won't be shown until you resize the window again, but that doesn't
> > always fix it permanently, more fiddling require as you change tabs. I
> > suggest a better-planned approach to resize, not just fully maximizing
> > the height of all fields, but either way it needs to work smoothly;
> > that's the main thing. The PI is pretty important.
> >
> > - Using tab key to cycle through fields, 9 PI usually places cursor at
> > the start of the text, whereas 6 PI selected the entire text.
> > Selecting the entire text was more efficient in most cases.
> >
> > PI controls:
> >
> > - Sometimes there is plenty of room horizontally for two columns, but
> > the large empty horizontal space is not utilized, requiring a tall PI
> > window.
> >
> > - When we have little arrows and also a slider for the same value
> > (such as Blend Level) it serves no purpose for slider click to
> > increment by 1. Little arrows already do that. Those slider clicks
> > should increment by 5 or 10.
> >
> > - When we have a slider with no field or arrows (such as Effects tab
> > Drop shadow Color Opacity) we need more control and more info. There's
> > no way to even tell what the current Opacity value is! Could be shown
> > via field, tooltip, arrows ... something. Again here, the click
> > increment by 1 doesn't seem very useful.
> >
> > - Since effectFilter setting is no longer supported, should it show up
> > in the UI? I would love to have it supported, that would be good for
> > optimization, but otherwise there's no need to see it.
> >
> > Custom Properties:
> >
> > - Can't resize the Value field. And it doesn't accept the Tab key.
> > (which was also imperfect in 6 but at least accepted.) No wrap
> > control. Currently pretty useless for editing longer text.
> >
> > - Faulty window resize. To test, resize to make the PI window very
> > tall, then shorter again. The element list always gets taller with the
> > window, but never contracts again, even when there's only 1 element,
> > so it becomes ridiculously big and the Key and Value fields are no
> > longer in view without scrolling.
> >
> > - Value field bug or critical flaw: it is or was easy to lose changes
> > when editing the Value of a prop if you click in the wrong place. Now
> > it seems better testing this time in 901rc1; this may have been fixed
> > already?
> >
> > - Inefficient when adding new element, requires extra click from user
> > to select the newly added element, another extra click to select the
> > name. Clicks matter! It could be already opened for editing after
> > creation, with the entire Key field text selected. Or just use the ask
> > dialog as before.
> >
> > - Easy to confuse the "Add Array Key" "+" buttons with adding a new
> > element, and that's fine to learn, but even after you learn it, it's
> > still easy to click by accident. Then there's trouble; if you didn't
> > want an array, the problem is that you've permanently lost the
> > original Value for that key. That may be a big important text that is
> > nontrivial to lose with a single click! Prop values are important.
> > Possible fix by putting the original value into the value for the
> > newly created subelement when changing a single element into an array.
> >
> > PI window and tabs:
> >
> > - The PI tabs (Basic, Contents, Custom...) are one thing that is
> > almost more efficient now than in 6. Good! But still needs
> > improvement. I say "almost" efficient because the little tab buttons
> > are way too small - about 11x10 px on my screen. That's takes more
> > effort and concentration to click, and these are your highest-traffic
> > PI controls. Even 16x16 would be an improvement. Unless there's
> > already a setting for this that I missed.
> >
> > - The little target icon in the tab bar to "Select object to inspect"
> > usually does not actually select the object! But sometimes it does;
> > inconsistent. Unless there's a trick I need to learn. And no, I never
> > touch the lock. I hate the need to type a select command in the
> > message box (for a control or group that's hard to select by mouse)
> > when this PI select button is glitchy.
> >
> > Good start?
> >
> > Best wishes,
> >
> > Curry Kenworthy
> >
> > Custom Software Development
> > LiveCode Training and Consulting
> > http://livecodeconsulting.com/
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
More information about the use-livecode
mailing list