search

fesch / Structorizer.Desktop

Structorizer is a little tool which you can use to create Nassi-Schneiderman Diagrams (NSD).
https://structorizer.fisch.lu
GNU General Public License v3.0
65 stars 20 forks source link

Structorizer canvas should be scrollable with mouse wheel like Arranger is. #65

Closed elemhsb closed 8 years ago

elemhsb commented 8 years ago

Structorizers canvas isn't scrollable with mouse wheel. Arranger's canvas is vertically scrollable with mouse wheel but not horizontally. Some mice models support this.

codemanyak commented 8 years ago

The mouse wheel in Structorizer had been dedicated to a different purpose: It is used to collapse or expand a selected (large) element. It might be debatable if that was a wise decision and it is poorly documented. Anyway, an additional button or menu toggle to achieve the same effect would certainly be helpful. It may not seem very clever, however, to make the effect of the mouse wheel dependent on whether or not an element is selected. The horizontal scrollability of the Arranger canvas will be examined. But wouldn't this be a rather exotic functionality?

fesch commented 8 years ago

I do not stick to the collapse / expand feature. This has been asked / proposed by some other user.

codemanyak commented 8 years ago

Maybe a new diagram menu toggle will determine which effect the mouse wheel should have?

fesch commented 8 years ago

Why not ;-)

elemhsb commented 8 years ago

Mouse scrolling in both directions is a must, becourse there is no autoscrolling near canvas boundaries when dragging items on big structures.

codemanyak commented 8 years ago

I might say, decompose your algorithm if it gets too large for the canvas... (but I don't, of course :wink:). By the way, sensible workarounds are: decreasing the font size and collapsing large elements. But well, just a question: would activating autoscroll behaviour be an option? It is also supposed to get very tricky with element dragging, but would at least work with all conventional mouse models. (I'm still trying to work out how horizontal redirecting the mouse wheel effect is supposed to be achieved - both by user and programmer. Most approaches I have found so far are related to the browser.)

codemanyak commented 8 years ago

Okay, I learned, the redirecting might be triggered by pressing the shift key. This should be feasible.

elemhsb commented 8 years ago

It will be also very usefull in combination Arranger / Executor to test a lot of subroutines ... @fesch How to trigger the collapse / expand function at the moment ?

fesch commented 8 years ago

Each element has a method setCollapsed(boolean).

elemhsb commented 8 years ago

Ok, but with mouse wheel ?

fesch commented 8 years ago

Yes, the mouse wheel triggers this method.

elemhsb commented 8 years ago

@fesch My mouse wheel does nothing under linux

fesch commented 8 years ago

I know that there are some differences between Mac and Windows too regarding the Drag&drop with the mouse under Java, so I'm not really surprised that there are some differences with Linux too.

I'll have to install some Linux distribution to test this ...

codemanyak commented 8 years ago

Investigation results:

  1. As it turns out, the wheel rotation value is one of the decisive differences between Windows and Linux mouse wheel handling here: Under Windows you may get integer values in a practically unlimited range from MouseWheelEvent.getWheelRotation() -- depending on the scrolling speed, I observed at least -30 ... 30! --, whereas under Linux (I tested under OpenSuse with KDE) I can only get -1 or +1, not even 0 is observed in contrast to Windows. Unfortunately the detection thresholds for collapsing in method Diagram.mouseWheelMoved() were set to < -1 and > 1, respectively, which was certainly fine to avoid hypersensitiveness under Windows but explains why elemhsb didn't see any effect under Linux. (I will perform some more tests in order to find out if perhaps only some system-dependent unit or block scroll settings make the difference -- then we might be able to unify the behaviour).
  2. I tested autoscroll mode under Windows and Linux, which worked surprisingly stable with dragging of Elements under both systems - and even works if Diagram listens to Mouse Wheel events (which causes the missing mouse wheel reaction of the JScrollPane, by the way). Enabling autoscrolling in Diagram would satisfy most of the demands stated above, I guess. Hence, I will activate it for the next version.
  3. Under both platforms, the Swing components ignore completely any horizontal "wheel" activities on Notebook touchpads (no MouseWheelEvent is triggered at all!).
  4. Mouse wheel motions with pressed shift button trigger MouseWheelEvents on both platforms (modifier mask is 0x40 on the MouseWheelEvent, so horizontal scroll attempts may be identified), but the JScroolPane class -- and this is really stunning -- igores this modifier under Linux, whereas it actually scrolls horizontally under Windows.
  5. Some GUI enhancements to support collapsing/expanding by menu items and toolbar buttons are in progress. Whether the mouse wheel controls scrolling or collapsing may be switched at runtime, as I could prove. So a respective option might be added to the menu if we don't drop the mouse wheel control for this purpose entirely: Instead of mouse wheel triggering, the collapsing might be controlled by accelerator keys Shift+Num+ / Shift+Num- (in addition to the mentioned menu items and toolbar buttons).

Out of the findings listed above, a satisfying solution will be implementable pretty soon. Moreover, I will make a proposal for a modified drawing of collapsed Elements, opening a new issue.

codemanyak commented 8 years ago

The combination (i.e. product) of wheel rotation and scroll amount was sufficient to get over the collapsing threshold in Linux as well. The enhancement and bugfix package of today doesn't solve the horizontal mouse wheel scrolling insufficiency under Linux, though. Of course, I might write a workaround for the lacking Java.awt.Swing behaviour and have the Diagram class itself carried out all mouse wheel scrolling (instead of relying on JScrollPane). Some tests showed it might work, but due to lack of time I'm just not very inclined to refine this makeshift approach to release quality now. With functioning autoscroll mode and the existing possibility to scroll via the scrollbar, the situation doesn't seem entirely catastrophic anymore, does it? @elemhsb please test this out after Bob will have uploaded the prepared version 3.23-09.

fesch commented 8 years ago

3.23-09 is uploaded ...

elemhsb commented 8 years ago

Sorry for the latency. I tested now version 3.23-10 a very smooth version. :-) Works like expected.

codemanyak commented 8 years ago

@elemhsb Thank you for your response. I close the issue.