google-code-export / labyrinth

Automatically exported from code.google.com/p/labyrinth
GNU General Public License v2.0
2 stars 0 forks source link

scrolling & zooming #43

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. drag a thought outside the window
2. try to see what it says 

What is the expected output? What do you see instead?

I should be able to see what the thought says, but I can't scroll the
contents of the window so the thought remains hidden to me.

Labyrinth should work a lot more like Inkscape does. It should have
scrollbars to begin with, and let the user scroll the whole map by
middle-button-dragging the mouse. Centering the window on the selected
thought might be useful as well.

Also, the ability to zoom in/out the map would be desirable in order to get
a more general idea, or focus on a specific thought. Scrolling up or down
the mousewheel should change the zoom level.

What version of the product are you using? On what operating system?

Labyrinth 0.3 on Ubuntu Feisty.

Original issue reported on code.google.com by frandavi...@gmail.com on 4 Dec 2006 at 5:36

GoogleCodeExporter commented 9 years ago
definitely a must-fix; let's have this use case: I have two computers, one at
1280x1024 and one at a 1280x800 resolution. If I draw a map maximized that 
takes the
full size of my 1280x1024 screen, I will not be able to access the lower 
contents on
my 1280x800 screen.

Original comment by nekoh...@gmail.com on 31 Dec 2006 at 4:13

GoogleCodeExporter commented 9 years ago
Zooming support has now been added (using the buttons and the scroll wheel). 
Translation support has been added (using ctrl-left click-drag on empty space).

I'm fairly happy with the zooming stuff however I am looking into better ways of
doing translations.  I like the idea of using the middle button.

Marking as Started until better support for translations works properly.

Original comment by DonScor...@gmail.com on 10 Mar 2007 at 10:49

GoogleCodeExporter commented 9 years ago
Wow. Seriously, wow. Don, you are a hero, this thing KICKS ASS. Just tried out 
SVN
167, I never expected it to work that good. It's very natural. Finally, I don't 
feel
"limited" to boundaries while mindmapping, this is awesome. This is like.. 
unlimited
ammo cheatcodes ;)

The only thing that kind of scares me is the "zoom view move" arrows on each 
side:
they have "smooth" scrolling. I guess that's intentional, but it sometimes 
feels a
bit sluggish and may lag behind the mouse actions; therefore you will have the 
thing
keep scrolling all by itself after you released the mouse button, weird.

Why not display a hint message in the statusbar "use the <b>mouse wheel</b> to
<b>zoom</b> in and out, and <b>click the wheel</b> to <b>move</a> around the 
work area" ?

Original comment by nekoh...@gmail.com on 9 Apr 2007 at 3:23

GoogleCodeExporter commented 9 years ago
The lagging is due to the performance (or lack thereof).  Basically it works on 
a
timeout while pressing on the arrows.  If draw signals are getting caught up, 
they
delay the receiving of the release event.

Original comment by DonScor...@gmail.com on 17 Apr 2007 at 6:47

GoogleCodeExporter commented 9 years ago
I have a few suggestions. 

1. Scrolling. Today people are used to using a mouse scroll for scrolling a 
page up
and down (compare web browsers experience and any other "scrolling" programs), 
_not_
for zooming. Arrows work fine for scrolling, but are not a standard way of 
doing it. 

What do you think about the idea of a main area with certain initial size which
increases (and scrollbars appear accordingly) when user moves a "thought" beyond
current area borders (Inkscape solution) ?

1.1. Scrolling left/right: <SHIFT + scroll>, scrolling up-down: simply scroll.

2. Zomming.  It should be <CTRL+scroll>, this is common for Firefox, GIMP, 
Inkscape etc.

If your scrolling/zooming strategy (current navigation) is not "fixed" yet, then
maybe the solutions implemented in other software currently available are worth
considering...

Original comment by kamila.chyla on 16 May 2007 at 6:08

GoogleCodeExporter commented 9 years ago
interesting points you have there. I see what you mean, I'm not sure about that
concept being better than the current behavior though. Here is my try at 
justifying
myself.

A webpage is a document, a very linear thing, it's mainly 100% of time 
scrolling up
and down. A mind map, on the other hand, goes in the X and Y in all kinds of 
funky
ways. And my *fastest* way of moving through a mindmap quickly is 
middle-clicking
or/and zooming out and rezooming in.

«What do you think about the idea of a main area with certain initial size 
which
increases (and scrollbars appear accordingly) when user moves a "thought" beyond
current area borders (Inkscape solution) ?»
I would hate that. It would imply «create a thought AND move it», it would 
also add
lag (I have yet to see such a kind of solution that does not either lag to 
death or
degenerate into some uncontrollable accelerated movement. Just think of drag and
dropping stuff into OpenOffice for an example; as soon as you are off the mark,
whoops, you just went down 20 pages).

Further on this idea, I believe the inkscape solution can work because it can 
be a
"pixel-dimensions-thingy-based-editor" as well (I mean, you can create a 
document
that is "the size of a US Letter paper"). One thing I really like in the current
labyrinth is the lack of scrollbars that give me a really warm and fuzzy 
feeling of
freedom. I don't feel like I need to "push" some canvas borders before 
continuing my
map. I feel like I have unlimited space. Fixed canvas sizes suck. I am 
constantly
bumping into these in the GIMP and Inkscape. It's a bit hard to 
describe/explain :)

For the record, I never use ctrl+mousewheel to zoom in GIMP. It annoys me 
greatly. If
simply mousewheelup/down were available for zoom, I would use that. Currently, 
what I
do is mousewheelup/down on the "zoom combobox" in the status bar of the image. 
So no,
the fact that it's the default in GIMP doesn't *necessarily* make it a better 
way to
do it.
Using some keyboard shortcuts exclusively is not in any way intuitive, I 
believe.

I think your comment is very interesting, I just had to reply to give 
counterweight
arguments :)

Original comment by nekoh...@gmail.com on 16 May 2007 at 9:03

GoogleCodeExporter commented 9 years ago
1. Scrolling: current implementation is not HIG-compliant. I don't think 
Labyrinth is
much different than other graphical programs; user experience should be the 
same.

Please, have a look at GNOME HIG guidelines about mouse navigation:
http://developer.gnome.org/projects/gup/hig/2.0/input.html#input-mouse

" If present on the mouse, the scrollwheel should scroll the window or control 
under
the pointer, if it supports scrolling. (...)

Ctrl-scrollwheel-up should zoom into the window or control under the mouse 
pointer,
and Ctrl-scrollwheel-down should zoom out. (...)"

By the way: isn't HIG-compliance one of the goals of Labyrinth project?

2. Canvas size: in Inkscape even if you define fixed-sized page, you are still 
free
to paste objects on the whole "expandable" area, and the scrollbars are updated
accordingly. This is standard behavior and it's the Labyrinth's behavior that in
GNOME world would be regarded as counter-intuitive, I'm afraid.

Original comment by kamila.chyla on 19 May 2007 at 10:49

GoogleCodeExporter commented 9 years ago
ok, pretty much agreed then. I didn't think the HIG covered that input part 
(even the
shift+scroll thing is present in the cvs version
http://developer.gnome.org/projects/gup/hig/draft_hig_new/input.html#input-mouse
)

As I kind of hinted, I was not entirely against your proposal, just presenting
alternate arguments ;)

Original comment by nekoh...@gmail.com on 20 May 2007 at 12:53

GoogleCodeExporter commented 9 years ago
Okay.  Some replies.  Yes, HIG compliance is one of labyrinth's goals.  Another
(sometimes conflicting) goal is to experiment with different ideas.

At this stage of development, I think it makes sense to put more effort into the
second goal.  For this reason, I'm going to suggest leaving it as-is *for now*. 
 Once
0.4 has been released (Real Soon Now), I'll try and gauge reaction and maybe try
asking some HIG people for advice.  If people like the current style and the
usability people aren't too unhappy, then leave it.  If not, it's easy to 
change it
to scrollbars.

How does this sound?

Original comment by DonScor...@gmail.com on 21 May 2007 at 6:00

GoogleCodeExporter commented 9 years ago
Closed because the main issue is fixed.

Original comment by sinfr...@gmail.com on 21 Mar 2008 at 12:28

GoogleCodeExporter commented 9 years ago
After reading the comment above I installed Labyrinth again, but as it turns 
out the
issue was still present. In fact, I think it was the same version I was using 
when I
filed the request!

Will the fix be in an upcoming version? If so, when should we expect it?

Original comment by frandavi...@gmail.com on 21 Mar 2008 at 12:51