Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
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
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
Closed because the main issue is fixed.
Original comment by sinfr...@gmail.com
on 21 Mar 2008 at 12:28
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
Original issue reported on code.google.com by
frandavi...@gmail.com
on 4 Dec 2006 at 5:36