Regaining IDE Efficiency: Property Inspector

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode

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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
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 <
[hidden email]> 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
if you insert cr's you get more lines. But a single line will not wrap. Not sure tooltips in any version did.

Bob S


> On Aug 9, 2018, at 01:29 , Curry Kenworthy via use-livecode <[hidden email]> wrote:
>
> - 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.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
Oh never mind. PI (Property Inspector)

Bob S


> On Aug 9, 2018, at 07:51 , Bob Sneidar via use-livecode <[hidden email]> wrote:
>
> if you insert cr's you get more lines. But a single line will not wrap. Not sure tooltips in any version did.
>
> Bob S
>
>
>> On Aug 9, 2018, at 01:29 , Curry Kenworthy via use-livecode <[hidden email]> wrote:
>>
>> - 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.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
I'm using rc1, and the PI issues persist so far as I can see. As I mentioned, the element portion of the PI is actually a tree widget, so some of the issues are really with the tree widget, not the PI itself.

Bob S


> On Aug 9, 2018, at 06:23 , Paul Dupuis via use-livecode <[hidden email]> wrote:
>
> 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)?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
Inspectors are popular in drawing and layout programs, where object
properties are relatively limited.

Many (most?) development environments use a property sheet* instead, to
handle the deep, rich variety of detailed properties developers need to
control.

Property sheets can help address everything in this list by:

- making better use of space, with more options visible at once

- being more complete, allowing all object properties to be available
   rather than just a selected subset

- providing more efficient navigation; accordion controls have a much
   larger target area than toolbar icons; good ones let you switch
   between grouped categories and one full list sorted by prop name.

- simplifying resizing so the entire resizing complexity goes away

Bonus:

- they're simpler and more cost-effective to develop


Once we extend "the properties" property to handle widgets uniformly
with LC-engine-native controls, I'll gladly extend my 4W Prop Sheet to
handle them, and even donate it to the project if they like so they
won't have to lift a finger beyond providing the uniform access to prop
arrays.



*If you haven't used an IDE with a property sheet, here's VB's as an
example:
http://www.afralisp.net/visual-basic-for-applications/tutorials/images/vb-properties.png

--
  Richard Gaskin
  Fourth World Systems


Curry Kenworthy wrote:

> 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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
I’ve done a bit of work in the tree widget, so I can take care of submitting a PR against a bug/enhancement request there.

Thanks,
Brian
On Aug 9, 2018, 9:56 AM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> I'm using rc1, and the PI issues persist so far as I can see. As I mentioned, the element portion of the PI is actually a tree widget, so some of the issues are really with the tree widget, not the PI itself.
>
> Bob S
>
>
> > On Aug 9, 2018, at 06:23 , Paul Dupuis via use-livecode <[hidden email]> wrote:
> >
> > 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)?
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
- 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.

Yes... select the gear icon on the right. You can change the size and switch to text labels if you prefer.

Thanks,
Brian
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode

Here's the QA enhancement request for Property Inspector defects:

https://quality.livecode.com/show_bug.cgi?id=21479

<https://quality.livecode.com/show_bug.cgi?id=21479>

Sorry I didn't see some of the replies here until already submitted, but
feel free to add comments there, and sign on if you want this stuff done!

Paul/Bob: Yes, I tested all these with 901rc1.

Richard: You and I both love efficiency! I do think sheets are powerful.
Then again LC already had a mostly very efficient IDE full of well-honed
features in a well-designed format that were inexplicably lost when
updating/porting/remaking. Efficiency already achieved and probably
fairly easy to regain.

Brian: Ah, the gear can make the tab icons bigger! Thanks!!

BTW, at some point I'll do the same for other IDE areas and file
separate Regain Lost Efficiency requests for those areas, but if anyone
has spare time, feel free to beat me to it!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
This one escaped me at first as well, but if you click on the sprocket  
widget in the upper-right of the PI you have the option for  
"Header/Footer Size" to grow and shrink the tabs. I'm not sure what  
"Footer" is referring to.

--Andrew Bell

>
> 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.
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
Curry Kenworthy wrote:

 > Here's the QA enhancement request for Property Inspector defects:
 >
 > https://quality.livecode.com/show_bug.cgi?id=21479

Thanks for submitting that, Curry.

I have a dream in which an increasing amount of IDE stuff gets done by
the community, leaving more C++ programmers available for the stuff that
needs C++ programmers.

That said, I have to admit I'm pressed for time this month myself, so
I'm a poor example.

But since this is all scripting work, is there anyone with the
intersection of time, skills, and interest available to take some of
this on?

Obviously the team will get to it soon, but the more we work on IDE
stuff the faster both that and engine work gets done. Mo' better LiveCode!

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode


> On 10 Aug 2018, at 1:53 am, Curry Kenworthy via use-livecode <[hidden email]> wrote:
>
> Here's the QA enhancement request for Property Inspector defects:
>
> https://quality.livecode.com/show_bug.cgi?id=21479 <https://quality.livecode.com/show_bug.cgi?id=21479>

Hi Curry

We really need a single report per issue. After all you wouldn’t like to see a release note for bug 21479 being “Fixes various property inspector issues Curry noticed”. One report per issue, with recipe on how to reproduce means we can focus on implementing the actual fixes rather than having to task someone with creating reproducible recipes and individual reports.

As Richard mentioned it would be great if we had more Brian Milbys (or is that Milbies ;-) around that like to jump in and get involved. The reality is with limited resources the team ends up having to prioritise engine issues over IDE usability niggles so the help is appreciated.

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
On 08/09/2018 08:14 AM, Richard Gaskin via use-livecode wrote:

> Many (most?) development environments use a property sheet* instead, to
> handle the deep, rich variety of detailed properties developers need to
> control.

Much like revNavigator, no? <g>
I'm a big fan of property sheets.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode

Monte:

 > We really need a single report per issue.

Howdy Monte! Whatever you need is absolutely fine with me, feel free to
parse and slice/dice this into any number of pieces with my blessing.

However I myself will NOT be filing dozens or hundreds of report;
impossible. I wasn't kidding or exaggerating the slightest bit about not
having time for that; wish I did, but think of it ... I've been waiting
for a whole YEAR just for the chance to get this first list done, and
now it's done! Mark wanted some specifics and here they are.

Also this is very much a gift to LiveCode, perhaps far more to your own
benefit, not just a selfish request of my own.

 > with recipe on how to reproduce

Each is described clearly, with all the info actually needed.

 > it would be great if we had more Brian Milbys ...
 > around that like to jump in and get involved.

Yes it would! I heartily agree with you, amazing and greatly appreciated
when people contribute, and I wish it were possible for me to donate
more time to LC. (Beyond the 10 hours this list has taken to test and
compile, and many dozens devoted to producing reports on LC 7 issues
during that transition.)

But right now it's just not physically (or temporally) possible for me.
I have less free time and a bigger todo list than it might be possible
for you to imagine. I'm sorry about that.

But perhaps that would make more sense if I pointed out that YOU also
are not donating time working on MY code either! :) However, if you're
short of people, I certainly would be available for some part-time paid
work on the IDE, and highly likely to improve on some of what you have
there. I know my stuff.

 > IDE usability niggles

Ha! I think the visible face of LiveCode that every user sees, along
with the level of efficiency provided for doing useful tasks with it,
might just rise to a slightly different phrase than "niggles." That got
a real-life audible chuckle out of me just now! Wow. Still chuckling.
That'll keep me smiling for a bit.

Anyway, thank you sincerely for your comments and attention. I would
love to see these issues improved, and there's no possible doubt that
fixing the IDE would certainly be at the very minimum 100% as much to
your benefit (and likely far, far more to yours) as it would be to my
own. Not to mention all the others here. LC is a very special product,
and we have a very special love for it. What a difference it makes in
our lives! There's nothing that comes anywhere close to it. So I'd love
to see the UI 100% back on its feet again. The love is real. I have to
wrap up this reporting now and get back to my normal tasks which are
piling up as we speak. Keep up the great work!!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode

Richard:

 > Many (most?) development environments use a property sheet

Wieder:

 > I'm a big fan of property sheets.

Hint: A property sheet doesn't necessarily need to look like one.

It could be useful to consider the value that the past and current PI
appearance has for users. The effect it has. It's a very user-friendly
look, isn't it? So easy to locate things visually too.

We could ask ourselves if that factors into any buying decisions. It
probably did for me. At the time I wasn't really looking for just "yet
another dev tool." There were plenty of those but I didn't go that route.

But behind the scenes ... much can happen. And probably should happen.
Without necessarily changing the look that people know and love. :)

I'm capable of doing that, and others are too. Good food for thought.
Back to work....

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode


> On 10 Aug 2018, at 9:07 am, Curry Kenworthy via use-livecode <[hidden email]> wrote:
>
> Whatever you need is absolutely fine with me, feel free to parse and slice/dice this into any number of pieces with my blessing.

OK for anyone else following along the best way to discuss issues with us is to follow the bug reporting guidelines. Here they are FYI https://quality.livecode.com/page.cgi?id=bug-writing.html <https://quality.livecode.com/page.cgi?id=bug-writing.html>

Cheers

Monte
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
In reply to this post by Skip Kimpel via use-livecode
On 08/09/2018 04:21 PM, Curry Kenworthy via use-livecode wrote:

> Hint: A property sheet doesn't necessarily need to look like one.

True, but it also shouldn't get in my way.
And you've done a great job in listing most of the annoyances of the PI.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
I'm not a fan of sheets.  I find myself doing constant scrolling because
the property I'm looking for never seems to be on the screen, or if I'm
changing multiple properties and messing with settings to see what the
combination does, I'm constantly going up down up down, overshooting the
property, having to scroll-scroll-scroll to get to the right spot.  You
can't take advantage of the 2D space (think about the position tab in the
PI as the most obvious example) to organize related properties.  You also
can't use graphics or group boxes, shadows, colors, or backgrounds to make
it clearer how properties are associated with each other.

Shortcuts to switch tabs in the PI would make navigating better, IMHO.
Ctrl-right arrow or ctrl-left arrow, ctrl-1..n would make flipping between
pages faster, but the layout and the proximity of the tabs to the
properties now still makes navigating between multiple pages of properties
for an object and fiddling with them much faster than a sheet does.

On Thu, Aug 9, 2018 at 7:44 PM Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 08/09/2018 04:21 PM, Curry Kenworthy via use-livecode wrote:
>
> > Hint: A property sheet doesn't necessarily need to look like one.
>
> True, but it also shouldn't get in my way.
> And you've done a great job in listing most of the annoyances of the PI.
>
> --
>   Mark Wieder
>   [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Regaining IDE Efficiency: Property Inspector

Skip Kimpel via use-livecode
Mike Kerner wrote:

 > I'm not a fan of sheets.  I find myself doing constant scrolling

You're not using v9's PI? ;)


 > because the property I'm looking for never seems to be on the screen,
 > or if I'm changing multiple properties and messing with settings to
 > see what the combination does, I'm constantly going up down up down,
 > overshooting the property, having to scroll-scroll-scroll to get to
 > the right spot.

True, prop sheets with views grouped by type and a Favorites view are best.


 > You can't take advantage of the 2D space (think about the position tab
 > in the PI as the most obvious example) to organize related properties.

That's one.

 > You also can't use graphics or group boxes, shadows, colors, or
 > backgrounds to make it clearer how properties are associated with each
 > other.

Why not?  Most sheets I've seen use the color/pat as the background for
the value, pretty much as we see them in LC's PI.


 > Shortcuts to switch tabs in the PI would make navigating better, IMHO.
 > Ctrl-right arrow or ctrl-left arrow, ctrl-1..n would make flipping
 > between pages faster, but the layout and the proximity of the tabs to
 > the properties now still makes navigating between multiple pages of
 > properties for an object and fiddling with them much faster than a
 > sheet does.

Do we even have a keyboard shortcut to move focus to the Inspector?

Back when I used to use Adobe products they used Cmd-, to shift focus to
their inspector.

Even if we do, though, since any palette has a global-ish scope how
would the developer using it know when a shortcut is handled by the
Inspector and when it's handled by their own app's menubars or other
shortcut-driven features?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12