Hi, all...
After spending the morning refactoring some of my 3.x code to deal with
wizard modal contexts vs. jobs, wrapped progress monitors, and specialized
status handling, I got inspired to brainstorm on what I wish those services
looked like in e4. [1]
One thing that struck me when writing client code examples is that the 3.x
client code can be simple when you work within the (narrow?) expected usage
pattern, but once you move away from that, your code explodes in
complexity. So I've tried to add multiple examples of client code to make
this point.
I also think there are cases where usability suffers (poor progress
feedback, for example) because we can't use the code the way we want to,
and there's no way to hook in and fix the problem without copying code or
abandoning the standard service altogether. I'm not sure how we can
quantify the usability gains on these pages. ie, the code is no simpler
than in 3.x, but it's no worse, and it supports cases that couldn't be done
before. I've used a lot of words to describe these issues, maybe someone
has a better presentation?
I also started writing some samples of what things might look like in an e4
world, but I don't claim to really know and am hoping that my ideas will
spark further evolution.
susan
[1]
http://wiki.eclipse.org/E4/EAS/Progress_Service
http://wiki.eclipse.org/E4/EAS/Status_Handling
http://wiki.eclipse.org/E4/EAS/Status_Reporting
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev