Comments (9)
I'm considering display to work something like this:
1) right-click valued node
2) hover over "Send to" which has a sub-menu
3) choose sub-menu option, which is split into two parts: "new" and "existing"
plugin instances. Something like:
New PropertyGrid
New Eye
----------
PropertyGrid: existing name 1
PropertyGrid: existing name 2
Eye: existing name 1
maybe the "existing" nodes should themselves have sub-menus
4) Based on selection, will send the watch value to a TAB within the left hand
side of a SPLIT PANEL. Selecting an existing panel instance will simply update
said existing instance. Closing all plugin instance will make the right hand
split panel disappear.
Original comment by [email protected]
on 17 Jun 2012 at 2:28
- Added labels: ****
- Removed labels: ****
from fseye.
Currently pursuing the above display description.
Original comment by [email protected]
on 4 Jul 2012 at 7:31
- Changed state: Started
- Added labels: ****
- Removed labels: ****
from fseye.
Not sure if this is what you are getting at, but I would love to be able to
register plugins for custom data types that allow them to be visualized in
different ways. For example, suppose we have some datatype representing a
tabular data structure, I would like to be able to see some custom viewer for
it in fseye. I would also like to be able to invoke a menu option to insert a
visualization of that embedded in the FsEye window (as a separate area). I
envisage using the whole of one of my screens as an FsEye workspace that
contains my current bindings plus any visualized versions of them
Original comment by [email protected]
on 11 Jul 2012 at 1:00
- Added labels: ****
- Removed labels: ****
from fseye.
Added "todo.txt" to the project tracking work to be done on this issue since it
is big and the comments here are not really good for tracking issue sub-tasks.
http://code.google.com/p/fseye/source/browse/trunk/FsEye/todo.txt
Original comment by [email protected]
on 14 Jul 2012 at 11:12
- Added labels: ****
- Removed labels: ****
from fseye.
I spoke with Howard out-of-band and one of the good suggestions he made is to
allow plugins to only be available for certain types. I suggested that we could
add an AcceptedTypes property to the IPlugin interface which returned a list of
types supported by the plugin (with an empty list indicating all types
accepted). But since then I've rethought that and decided giving full control
to the plugin author via either of the two interface methods would be better /
more flexible:
(* Returns true or false depending on whether an instance of the given type is
watchable: if false, then FsEye will not allow creating a watch for a value of
the given type. *)
IPlugin.IsWatchable : Type -> bool
or
(* Returns true or false depending on whether the given instance and its type
(which we may need if the instance is null) is watchable: if false, then FsEye
will not allow creating a watch for a value of the given type. *)
IPlugin.IsWatchable : obj -> Type -> bool
Howard, if you are monitoring this thread, I'd be interested in whether you see
much value in the second option. I think it may be useful if e.g. you have some
mutable object which is a watchable type, but may not be watchable if the
object is in a given state (i.e. incompletely initialized).
Original comment by [email protected]
on 14 Jul 2012 at 11:23
- Added labels: ****
- Removed labels: ****
from fseye.
Hi Stephen
I definitely think that an interface that takes an instance of an object is the
way to go. It's the most flexible because it allows a plugin to become
available based on any characteristics of a value. The only downside is that
it could be slower if you have a large number of plugins, but I don't expect
that will be a bit deal.
As a concrete example of the value, I am working on a F# type provider for R,
which we plan to Open Source shortly. This allows you to call arbitrary
functionality in R, but the value coming back from the function is always of
the same .NET type. Through option (2), we could make different plugins
available depending on arbitrary characteristics such as the class of the
object in R.
Also, I feel that it is valuable to allow a plugin to return a tri-state value
- Enabled, Disabled, and Hidden. If it is Disabled, the plugin would be
present on the menu but disabled. If Hidden, the menu item would not be
present. For a plugin that works for a large proportion of values, being
Disabled is fine. But suppose I write a plugin that only works for a small
proportion of values, it would be better to hide if it the value is not
supported.
For example, I might have a plugin that sends a value to Excel, but I can only
support it one very specific types. It is better to not show it than to have a
disabled "Send to Excel". As another example, I might write a plugin that can
convert an F# Quotation into F# code and spit it out into my F# script file.
This would only be supported for quotations and so should be hidden for other
types.
As you can probably see from my examples, I envision this mechanism being used
for more than just "adding a watch". I would be like to be able to incorporate
arbitrary functionality that a user might want to invoke. So perhaps a more
general term (IsSupported?) would make more sense than IsWatchable.
I can imagine enhancements such as allowing the plugin to derive the text for
the menu item from the value, but I think that is unnecessary for now.
Original comment by [email protected]
on 16 Jul 2012 at 12:57
- Added labels: ****
- Removed labels: ****
from fseye.
Howard: heads-up, I've release FsEye 2.0.0-beta1! You can find the download at
https://code.google.com/p/fseye/downloads/list and reference the documentation
at https://code.google.com/p/fseye/wiki/FsEye2Beta.
I did go with the more flexible IsWatchable: (obj * Type) -> bool interface
member, thanks for the feedback.
Your F# type provider for R sounds interesting, I look forward to taking a look
at it!
Your other suggestions are great too, and my first reaction was "let's go for
it!". But upon further reflection I have some hesitations, but I certainly am
not closing the door on anything yet. I say try out the beta1 release and see
how well it works for your use-cases in practice.
To enumerate my thoughts:
1) Expanding the generality of plugins beyond just "adding a watch". I worry
about the increased complexity for both plugin authors and users. e.g. some
plugins expose GUI controls, some don't. But I believe the IWatchViewer
interface is certainly still flexible enough for your use cases (you can do
anything you want in the IWatchViewer.Watch implementation). Indeed, if you
have something like "Send to Excel", I think it could be nice to have a GUI
watch control displayed which could be used to display information, allow
configuration, show progress, etc..
2) I understand your motivation for wanting to allow plugin authors to return a
tri-state value to indicate the availability of the Send To command. But again
I worry about increased complexity for plugin authors and confusion for users.
In case, I believe the UX best practice is to only hide menu items when they
never make sense for static nodes (e.g. "Non-public" and "Rest" non-valued
nodes) - but for dynamic nodes, that may or may not have functionality
available based on their state, I think disabling the menu item is least
surprising to the user. However, I would consider empowering the user to make
this choice: i.e. add a setting (see issue 22) to either hide / or disable
plugin commands that are unavailable based on the context.
But again, let's see how this all works out in practice, and take it from there.
Thanks!
Original comment by [email protected]
on 20 Jul 2012 at 1:14
- Added labels: ****
- Removed labels: ****
from fseye.
Thanks - very exciting. I probably won't be able to try it out until next
week, but I will let you know as soon as I have feedback.
Original comment by [email protected]
on 20 Jul 2012 at 1:49
- Added labels: ****
- Removed labels: ****
from fseye.
Marking this issue "Fixed" for 2.0.0 beta1 release in favor of having new
plugin related features requests or bug reports logged as new issues against
the release.
Original comment by [email protected]
on 21 Jul 2012 at 3:07
- Changed state: Fixed
- Added labels: Milestone-Release2.0.0beta1
- Removed labels: ****
from fseye.
Related Issues (20)
- Ctrl+C on a highlighted node should invoke "Copy Value" action HOT 1
- Delete key press on highlighted root node should remove the node
- Create and publish NuGet package for plugin authors to develop against HOT 2
- IconResource and ImageResource types should be internal HOT 1
- IWatchViewer.Watch signature needs to be changed slightly HOT 2
- Improve plugin loading error message for ReflectionTypeLoadException HOT 2
- Include FsEye.dll dir in plugin search HOT 3
- Plugins fail to load if the plugin dir contains any non-dlls HOT 2
- FsEye Plugin Loading Error when loading plugins marked as from "unsafe" internet location (affects included plugins) HOT 3
- Add support for Mono HOT 2
- Consider using a ToolStrip instead of current Panel of action buttons
- Incorrect version of multiple top-level bindings of the same name from the same interactive submission is displayed HOT 3
- Occasional "SplitterDistance must be between Panel1MinSize and Width - Panel2MinSize" exception kills FSI HOT 5
- Add setting to filter out zero-arg, non-void/unit methods
- Keep track of Cleared watches and prevent them from being added back to the watch tree on subsequent FSI submissions
- Add DataGridView-based plugin HOT 3
- Property accessor on object 'System.Xml.XmlElement' threw 'Object does not match target type.' exception HOT 3
- mono bug needs work-around: sending watch to PropertyGrid causes exception if first use of a plugin HOT 1
- Flatten Send To sub menu items for better usablity HOT 1
- Migration to Github HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fseye.