kowey / webprotege Goto Github PK

Can something like Selenium help us?

Why is this?

This is two separate problems, first that you can resize something until it's too small for you to access the resize control

Second that resizing goes crazy if you accidentally select something else in the process (you don't get the mouse up event)

Maybe increasing the z-index?

Mondrian is some kind of SVG editor written in CoffeeScript.

Speedith, is a well written library that represents Spider Diagrams (a fragment of Concept Diagrams). Can we use and extend its internal representation of a SD? Might save a day or two of work

https://github.com/urbas/speedith

See this video demo (I wrongly used the phrase drag and drop here).

Basically you drag to resize, but when you're dragging you can sometimes lose focus as your mouse button is held down. I don't know how to reproduce the problem reliably though, or what exactly is going on, but it's clear to me my model of this web UI stuff is pretty fuzzy.

Also I do generally hate that you have to click a button to signal to the plugin that you would like to start resizing. A more comfortable workflow might be something like holding down shift and drag, which is what I originally wanted to implement, but for some reason I had to retreat to the clunkier click then drag approach.

I recommend a big honking question mark in the centre of the dragsnap curve.

From observing Jim and Gem trying to actually use this tool, it's clear the whole dragsnap idiom is confusing as heck

The anonymous curve should really ride along as a passenger particularly since the property points to it.

I need to look into why I have this in the first place. It's something to do with initialisation not being very predictable. I needed the start button as a way to slow things down so that certain parts of initialisation happened in the right order, but what? And surely there is a programmatic way to do this, “only initialise when such and such condition has been fulfilled”

When you drag a shape over the sidebar, it's lost for good because future dragging is interpreted on the template objects

you can fix this by manipulating the z-index. Live objects should be higher and thereby get drag precedence

Scrolling? Some sort of page mechanism?

I really really hope this doesn't mean a whole big UI rethink

Probably the lasso selection mechanism is something that people would expect to have. It gets to be a real pain when you have curves within curve. You need some way to say that you want to move the whole lot together.

With subsumed concepts, you sometimes have the issue that the larger outer box obscures the smaller box within it.

Presumably something like transparency can be used to help with this problem, but it sounds like we need to do something clever with z-indices to manage this a bit better.

I don't think we need live feedback, but at least once you've finished the resize operation the arrow should snap to it

For the dragsnap mechanism, it would be nice when you're hovering over a candidate that is ruled out for some reason (for example, is already being used for subsumption elsewhere) to know that the candidate is being actively excluded, and not just eg. you're using the UI wrong or webprotege is not working.

Right now the only visual cue is the lack of a highlight. We should instead have some kind of reverse highlight, or something greyed out, etc.

Right now you have to press the Save button every time you want to save the diagram state. By rights, it should automatically save at the right points, perhaps in such a way that you're only really transmitting patches. But in the short/medium term, we can probably get away with saving everything.

See the trello card. Copy and pasting some key notes

The Properties of Students example in the tutorial (ch2, p 30) uses an example like

s -----[enrolledOn]---> Module1
Module2 <----[contributesTo^]--- Degree1
Module1 ⊑ Module2

Which I think might be easier (for someone like me) to understand with notation like

 s ----[enrolledOn]--->o Module1
 Module2 o----[contributesTo]---> Degree1
 Module1 ⊑ Module2

I'm not saying “change the notation on account of one easily-confused programmer” of course :-)

Gem, Aidan, Eric discussed the arrow inversion thing today on the whiteboard. Impression Eric had is that

• yes in principle this sort of thing could work,
• however, for practitioners, the arrow symbol creates an expectation about restrictions on the image, and that variants on arrows that work the other way are hard to learn/accept because they run counter to these expectations (so more a UI issue than a maths issue),
• interestingly, an alternative alternative notation like D >---p--- R seemed to be a lot less objectionable to Gem than the alternative notation (D o----p----> R which was suggested as replacement of D <---- p^ -----R), because it doesn't run afoul of those notational expectations [Eric also thinks this is a nicer notation in a way because there are fewer surprises like “oh, I didn't see the box”]

Gem will have a think about this problem of wanting to express things about the pre-image because it's a sort of pb that others have highlighted before, indicating that it may be a stumbling block