Re: [OS-JIRA] Created: (WOL-407) Entity Modeler -> please default new attributes with locking=false and allows_null=true

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Fri Apr 27 2007 - 19:43:15 EDT

  • Next message: Mike Schrag: "Re: [OS-JIRA] Created: (WOL-407) Entity Modeler -> please default new attributes with locking=false and allows_null=true"

    On 28/04/2007, at 2:40 AM, Mike Schrag wrote:

    >> e.g., Clicking on the "Add new attribute" button five times in a
    >> row would take longer than 5 seconds to populate. Beach-ball city
    >> after a while... and clicking each of the attributes locking to
    >> untick the ones I wanted unticked, took too long also. Too much
    >> mouse clicking.
    > OK in the next commit:
    >
    > * loading is a /lot/ faster if you had a lot of errors or warnings
    > (I'll move these enhancements over into wod and html editors also)
    > -- apparently when you create error/warning markers on a resource,
    > if you don't do that in a workspace job, it will fire a single
    > notification event for every one, each of which causes the problems
    > view to reload entirely .. these batch into a single event now.
    >
    > * adding/removing anything that has a table view is about 2x faster
    > for reasonably large data sets (i was lazy and just refreshing the
    > entire table view when structure changed rather than computing the
    > differences and removing/adding individual rows)

    Nice. Thanks very much Mike.

    > * something else i forgot now
    >
    > The BIG BIG BIG one, though, appears to be the preferences panels.
    > It appears that constructing those things is really expensive.
    > This is actually the killer for clicking new attribute 5x in a row
    > (although that is 2x faster now, that's still not cool). For
    > comparison, close your Preferences view completely with Entity
    > Modeler open and you'll see a MUCH faster repeat rate on those
    > operations.

    Interesting. Yes without the Properties view open it is snappier...

    > I'm not exactly sure what I'll do about this one at the moment, but
    > I might end up dropping the preference view and doing a custom view
    > instead that i can cache (those dynamically build each time they
    > display). I want to look into exactly what part is taking time on
    > it now, because it's kind of a handy API, but given that things
    > like the tab structure don't actually change often, it might not be
    > a big deal to manually construct them up front.

    Perhaps if it could morph into one of those fast views (e.g., when
    editing java, Navigate > Quick Outline) then together with being able
    to tab/return between fields in the table this would be just a CMD+I
    away (i.e., Navigate > Quick Inspector)

    Perhaps the Advanced and User Info tabs could also be separate fast
    views for similar quick access. CMD+Shift+I for Quick Advanced
    Inspector, CMD+U for Quick User Info Inspector.

    Then our fingers need not necessarily reach for the mouse ;-)

    with regards,

    --
    

    Lachlan Deck



    This archive was generated by hypermail 2.0.0 : Fri Apr 27 2007 - 19:43:24 EDT