Okay. I'll work on clutter. That one might not be easy, although reducing name size might help a little bit.
Timeout should be easier. Cheers, Susan > On Mar 9, 2016, at 5:50 PM, Queenie Ma <[email protected]> wrote: > > In reference to the 4th item in the list: > > > By default, the oplets tend to be a bit cluttered. Is there any way to > remedy that? Also, I really like how you can drag the oplets, but it can be > frustrating with the popup that appears when you hover over an oplet. I > think would be more user-friendly if it disappeared faster on hover out. > > On Wed, Mar 9, 2016 at 2:33 PM, Dan Debrunner <[email protected]> wrote: > >>> On Wednesday, March 9, 2016 11:39 AM, "[email protected]" < >> [email protected]> wrote: >> >>>> I'd like for the console to be more usable and relevant to quarks >>> application developers. I'm also hoping by asking for feedback and ideas >>> for improvements someone may decide they would like to make a >> contribution to >>> the console. >> >>> 1. Display oplet aliases (application assigned names) instead of the >>> 'OP_X' in the topology graph >>> 2. Alternately, remove the 'OP_X' and just assign the index value in the >>> graph '0', '1', etc >> >> Somewhat related to this is there should be a view that represents how a >> developer coded their application, which is through the topology api, where >> (for the most part) oplets do not exist. I'm not sure what exactly this >> would look like, but it's a move away from having oplets as the first class >> objects, to having streams and windows as the first class objects. Maybe >> such a graph would look similar but the focus would not be on oplets, e.g. >> oplet names like OP_1 have no meaning to the application developer. >> >> We may in the future have the physical representation (oplets) be heavily >> transformed from the logical view (topology), so in that case having a >> logical view is much more useful, e.g. imagine an extreme case where the >> graph has been optimized down to a single oplet. >> >> See: https://github.com/quarks-edge/quarks/wiki/Quarks-Etiao-Runtime >> >> >>> 3. If a topology has counter metrics on all oplets (i.e, >> DevelopmentProvider is >>> used) either a) remove all oplets from the graph or b) make the counter >> ops look >>> less significant or 'grey' them out from the graph. >> >> I think there are a number of oplets where the visualization could be >> simplified, e.g. FanIn, Union Isolate etc. could be not shown in the >> graph, as they are low-level building blocks somewhat unrelated to the >> application graph. >> >> >> Dan. >>
