[Bug 253709] Re: Plasmoid resizing is undiscoverable
Bug Watch Updater
253709 at bugs.launchpad.net
Mon Sep 16 07:43:32 UTC 2013
Launchpad has imported 77 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=164355.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2008-06-18T02:51:43+00:00 Groszdanireg wrote:
Version: (using Devel)
Installed from: Compiled sources
OS: Linux
In some cases it would be more convenient to be able to resize plasmoids
like windows, so to resize it in one direction by dragging its edge or
in two directions by dragging its corner. The curernt resizing by
dragging the resize button on the handle is especially inconvenient e.
g. when I want to make a plasmoid fit in a space: I first have to move
the plasmoid exactly to the center of the space. In addition to resizing
by dragging the edge, an Alt/Meta+Click combination for resizing would
be convenient, just as Alt/Meta/Right click to resize windows as the
nearest edge was dragged.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/0
------------------------------------------------------------------------
On 2008-07-19T14:20:43+00:00 Sel Goona wrote:
I agree that. Especially tough is it if you try to get two folderview-
plasmoids to an exact size . that can be really frustrating. :-(
I think the best approach would be when a single click on the resize-
button will change the icon and give so a signal, that now all sides can
be change by hand. Then if all changes be done, simply click a second
time on it and the icon changes to it`s normal state again.
This way, you could simply maintained the existing drag`n`drop-resize-
Variant.
Would it work?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/1
------------------------------------------------------------------------
On 2008-07-19T14:35:08+00:00 Maciej Pilichowski wrote:
It is not "the best" but different, here is the link to report about sticky UI:
http://bugs.kde.org/show_bug.cgi?id=165432
I like both ideas :-).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/2
------------------------------------------------------------------------
On 2008-07-19T20:35:50+00:00 aseigo wrote:
i agree that moving-from-the-center is not great (there are technical
reasons for this atm, so it's not exactly a random thing), but plasmoids
are not windows and i do not want to have to support some complex resize
system that would also increase the visual impact.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/3
------------------------------------------------------------------------
On 2008-07-20T00:35:32+00:00 Groszdanireg wrote:
Well, they are not windows but they still sometimes need to be sized and
placed properly. A resize handle in the bottom-right corner that leaves
the top-left corner in place would be OK.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/4
------------------------------------------------------------------------
On 2008-07-20T01:22:06+00:00 Sel Goona wrote:
@Grósz Dániel: That would it be! But this one resize-handler is actually
already there, everything what`s missing by now is that the top-left
corner leaves in place while the plasmoid will be adjusted.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/5
------------------------------------------------------------------------
On 2008-07-20T09:41:02+00:00 Maciej Pilichowski wrote:
ad.#4) not mentioning consistency. User does not expect explanations why UI is different and requires more work but needs easy, efficient UI.
I don't see any benefit in having two UIs at the same time. And I doubt there is any.
Aaron, it is funny in some way, that there are several reports already
(closed), which all together would solve such issues right away.
Currently I mentioning the one with frame around, not only sticker-
handle. Frame around with a little bold corners -- two issues solved +
uniform UI.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/6
------------------------------------------------------------------------
On 2008-07-24T16:30:42+00:00 Dario Panico wrote:
I proposed an idea here http://bugs.kde.org/show_bug.cgi?id=165391#c6, i
think that it could solve even this issue
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/7
------------------------------------------------------------------------
On 2008-07-24T19:54:11+00:00 Sel Goona wrote:
*** This bug has been confirmed by popular vote. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/8
------------------------------------------------------------------------
On 2008-08-02T17:32:39+00:00 Witold-sowa wrote:
I think that the simplest and most effective way is to allow plasmoids be resized like windows when plasma is unlocked.
If you want to resize plasmoid just unlock plasma, drag one o its edges or corners, drop it and lock plasma again.
When plasma is unlocked, mouse cursor should change over edges and corners of plasmoids like over window ones
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/11
------------------------------------------------------------------------
On 2008-08-03T19:19:45+00:00 Gilboa Davara wrote:
Trying to resize folder-view, especially on nVidia-based hardware is an exercise in futility. (Even with InitialPixmapPlacement and GlyphCache)
... Please switch to Windows-like resizing.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/12
------------------------------------------------------------------------
On 2008-08-11T16:31:48+00:00 Rct+bugs wrote:
I like the "sticky UI" idea a lot. That is, clicking the resize button
should open a border around the plasmoid that contains handles for
resizing and rotating. This border should look much like the border used
for editing the panel.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/13
------------------------------------------------------------------------
On 2008-08-11T16:40:51+00:00 Maciej Pilichowski wrote:
Ryan, sticky meant something different -- instead of press&hold, move,
release, you click, move, click (such UI is helpful for RSI people, and
other disabilities probably).
However I like your idea too! Especially one does not conflict with
another :-).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/14
------------------------------------------------------------------------
On 2008-08-13T10:53:45+00:00 FiNeX wrote:
*** Bug 168892 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/15
------------------------------------------------------------------------
On 2008-09-23T14:07:48+00:00 Kamil wrote:
(In reply to comment #9)
> I think that the simplest and most effective way is to allow plasmoids be
> resized like windows when plasma is unlocked.
> If you want to resize plasmoid just unlock plasma, drag one o its edges or
> corners, drop it and lock plasma again.
> When plasma is unlocked, mouse cursor should change over edges and corners of
> plasmoids like over window ones
>
I'm agree with you, but some plasmoids haven't any frame so there should
be still the old way to resize. When a plasmoid has the frame such as
'Folder View' or 'Dictionary' it's size would be changed by moving it's
edges or by using the old way. When plasmoid hasn't the frame such as
'Analog Clock' there would be only the old way available.
(In reply to comment #11)
> I like the "sticky UI" idea a lot. That is, clicking the resize button
> should open a border around the plasmoid that contains handles for
> resizing and rotating. This border should look much like the border used
> for editing the panel.
Keep it simple. When plasma is unlocked, it's something like 'edit mode'
so resizing should be available without entering any 'resize mode'.
'Edit mode' is enough. The way introduced in comment #9 is better.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/16
------------------------------------------------------------------------
On 2008-09-23T20:00:30+00:00 aseigo wrote:
*** Bug 171549 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/17
------------------------------------------------------------------------
On 2008-09-28T18:48:24+00:00 Dherring-0 wrote:
Just to add my two cents: There is a well-established paradigm in
window placement that has worked well for Apple, Microsoft, and Unix
desktops for many years. Don't be so quick to throw it away for
plasmoids. The rezoom and rotate buttons are cute -- they may even be
natural for certain operations -- but when arranging (mostly)
rectangular boxes on the screen, we have years of experience placing the
two corners of the window.
Same goes with the placement of the plasmoid handle(? what used to be
called window decorations); when is this on the top, right, left, or
bottom? The principle of least surprise says window decorations always
appear on the top (99% of window managers agree). Since plasmoids can
be rotated (no natural top), maybe this should always appear on all
sides? I occasionally struggle when the bar appears on the left of a
large plasmoid when I wanted to access it on the right. Takes a few
clicks to get the left one to hide and the right one to appear.
FWIW, when I first saw the rotate button, I thought it was a "reset
zoom" button, not something you clicked and dragged.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/18
------------------------------------------------------------------------
On 2008-09-28T19:01:33+00:00 Rct+bugs wrote:
It seems to me that one problem is simply that the handle needs to
appear at all. Since the handle doesn't appear until you hover the
plasmoid itself, there is no way to move your mouse directly to it, even
if you know exactly where it will appear. I think the most
straightforward solution to this is to make all applet handles visible
at all times when in edit mode.
For resizing, it might even make sense to expand the applet handle into
a full-fledged 4-sided border, or at least a bit in each corner and in
the middle of each side with a resize handle. Also, for power users,
Alt+right click and drag should work for plasmoids like it does for
windows. Or maybe just right click and drag, without alt. I'm just
throwing these out there; I'll let the usability experts sort things
out.
When not in edit mode, handles should either work like they do currently
(show on hover), or else not appear at all.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/19
------------------------------------------------------------------------
On 2008-09-29T01:13:52+00:00 Dherring-0 wrote:
I like Ryan's idea. When widgets are unlocked, the handle should always
be visible. That matches the behavior of the KDE3 and Microsoft
taskbar.
Also, a request for more buttons on the handle (possibly customizable a la normal window decorations)
- maximize -- fill the visible screen; alternate clicks would just fill horizontally or vertically
- shade -- only show the handle
- minimize -- shrink to a stamp/icon a la OSX and possibly move near the cashew
- reset -- return to the original zoom and rotation
- background/transparency -- change the background hue and transparency
Some of these may do better in a context menu available from the
plasmoid's handle.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/20
------------------------------------------------------------------------
On 2008-10-17T12:22:01+00:00 Myth00s wrote:
This is a major usability issue. Suppose you want to align the sides of
a new plasmoid with the sides of an existing one. In the current
situation it is at least a very difficult fail and retry process and I
doubt it will leave anyone satisfied in the end. Imagine if you succeed
to align the sides and you decide you want the widget to become a bit
"taller". It is impossible to do it without messing up the former
alignment. This is about an action that happens a lot and people will
notice it in no time. I hope it gets fixed soon.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/21
------------------------------------------------------------------------
On 2008-10-23T03:26:48+00:00 Mjmccans wrote:
I agree that a "normal window" resizing mode should be introduced and I
like the idea of a "resize mode" as proposed by Sel Goona, while still
retaining the current resize method in some way so that there is not
always a two step process required to change the size. However, I see
how this could lead to a confusing interface that would have, in
essence, two resize buttons. A possible solution may be to leave the
current button as is, but also have corners that fade in when the
plasmoid has focus that could be used to alter the size.
However, I do not like the idea of the handles always being visible
while in edit mode. I think this would add a great visual distraction to
the edit screen and could get in the way of visualizing a layout (I
would have to leave the edit mode to be sure that it looks as I expect).
Basically, any solution that allows me to resize plasmoids as regular
windows would be greatly appreciated.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/22
------------------------------------------------------------------------
On 2008-10-23T16:47:18+00:00 Kamil wrote:
Why do you want to add some corners for resizing? Every plasmoid which
hasn't got fixed proportions already has a frame, which may be the
resizing handler. In plasmoids with fixed proportions such as the analog
clock, there's no need to add new way of resizing, so there's no need to
add a frame.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/23
------------------------------------------------------------------------
On 2008-10-23T16:54:17+00:00 Groszdanireg wrote:
#21: There is need for the window-like resizing for fixed proportion
plasmods. Imagine e. g. that you want to place a clock in a way that it
exactly fits between two plasmoids. With the current method, you have to
first move it exacly to the midpoint between the two plasmoids (almost
impossible without a ruler or much of trying). With window-like
resizing, especially with snap-zones, it would be easy.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/24
------------------------------------------------------------------------
On 2009-01-30T12:44:37+00:00 Kojot350 wrote:
In KDE 4.2 you resize plasmoids in one direstion. So does it meen this
raport can be closed?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/25
------------------------------------------------------------------------
On 2009-01-30T12:59:37+00:00 Groszdanireg wrote:
Yes, I would say that, at least for me, the new behavior solves the main
problem (that it was difficult to move and size a plasmoid to an exact
place and size).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/26
------------------------------------------------------------------------
On 2009-03-13T22:12:37+00:00 Voicu Hodrea wrote:
I think that the plasmoids should be resized like windows, from the
bottom right corner and leave the top left one in place. Everything else
on the desktop (with most window managers) flows from top left to bottom
right. Because of the difference in plasmoid resize you have to arrange
the desktop from bottom left to top right. Maybe swap the close button
with the resize button or put another resize button near the close one.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/27
------------------------------------------------------------------------
On 2009-06-26T22:41:20+00:00 Kde-2011-08 wrote:
I have watched about ten new-to-kde4 users try to configure their
plasmoids, each and every one of them got frustrated at the non-
intuitive behaviour. I dare call it non intuitive because:
1) It differs from establish paradigms.
2) Those with experience moving/resizing windows expect the controls on
the top, not the side. The auto-hiding is not a problem (for me it is,
but not for people that I ask), but the side-placement is a problem
because often the controls appear on the opposite side from what the
user expected.
3) Those with experience moving/resizing windows expect that grabbing a
corner or side will affect only that side, not the opposite side as
well.
4) Those with experience moving/resizing windows expect to align one
side of the window with a move operation, and the opposing side with a
resize operation. With plasmoids, the user must carefully measure and
find the center of their desired location, a difficult task.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/28
------------------------------------------------------------------------
On 2009-06-27T00:45:43+00:00 aseigo wrote:
"appear on the opposite side from what the user expected"
they appear on whatever side the mouse is when the handle appears
"the user must carefully measure and find the center of their desired
location"
plasma hasn't done center-based resize in a while now. it resizes with
the opposite side of the object anchored and the resize happening by
moving the top corner by the handle (where the mouse is).
time to update your testing?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/29
------------------------------------------------------------------------
On 2009-06-27T01:03:00+00:00 Kde-2011-08 wrote:
> they appear on whatever side the mouse is when
> the handle appears
Which means that they appear inconsistently from side to side!
> plasma hasn't done center-based resize in a while now.
Very, very cool. I can think of at least two people that this will make
very happy.
> time to update your testing?
It's not testing, it's actual installs. I like to sit around at first
and see how they do. You will notice that I file a lot of bugs, most of
them start off with a frustrated user!
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/30
------------------------------------------------------------------------
On 2009-06-27T01:04:04+00:00 Groszdanireg wrote:
By the way a resize corner in the bottom left corner would still be more
customary even if we don't want full resizeable borders. As normal
windows can be grabbed by their top people tipically move the top (the
caption) to the right place and then resize it by a bottom corner, so it
is unusual to have to move a widget so that its bottom is at the right
place and resize by a top corner.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/31
------------------------------------------------------------------------
On 2009-06-27T01:24:45+00:00 aseigo wrote:
"Which means that they appear inconsistently from side to side!"
it means they appear nearest the mouse. we used to do "always on the
same side" display and that turned out to be (unexpectedly) awkward for
people. even with consistent-side-display, when widgets were pushed up
against the edge of the screen, the handle had to be shown on the other
side anyways, making for inconsistency. so we experimented with "nearest
the mouse" which at least was consistent in all cases and tested well.
"a resize corner in the bottom left corner would still be more
customary"
* interferes with widget contents and widget interaction (unless it was
kept outside the widget)
* still doesn't work for widgets at or near the bottom of the screen
* would actually have the same basic behaviour as the current system
does (opposite corner anchored) with the only diff being that it sizes
"downwards" instead of "upwards"
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/32
------------------------------------------------------------------------
On 2009-06-27T01:30:07+00:00 Groszdanireg wrote:
OK, true. Btw what I was thinking of was a resize corner which appears
only on mouseover, outside of the plasmoid. It would be still possible
to move the resize button to the bottom of the handle and make it resize
the bottom corner.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/33
------------------------------------------------------------------------
On 2009-06-27T12:15:26+00:00 Kde-2011-08 wrote:
> so we experimented with "nearest the mouse" which at least
> was consistent in all cases and tested well.
Now that I am aware of the behaviour it seems natural to me. Would you
like me to run a small survey next week of users manipulating the
plasmoids in KDE 4.3 beta? I can probably get about five people to play
with it and tell me what behaves differently from what they expect.
> would actually have the same basic behaviour as the current
> system does (opposite corner anchored) with the only diff being
> that it sizes "downwards" instead of "upwards"
I think that was quite the point that Grosz was making. He states that
most people align the upper portion of the window / plasmoid, and then
resize from there. I don't know if that is accurate, but I can find out
next week on a few people if you like.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/34
------------------------------------------------------------------------
On 2009-06-27T14:01:06+00:00 FiNeX wrote:
Created attachment 34862
Resize plasmoid use cases.
Well, I can imagine four use cases related to plasmoid resizing.
Two cases are easy to accomplish (the actual implementation), the other
two are a bit less easy.
I've done an image which explains the cases.
Case "C" shows one of the two "difficult" task (the fourth case is
equal, it changes only the direction: right instead of left)
The main difference is that the first two cases are solved with only one
human action, the third (and the fourth) needs two user actions (one
move and one resize). Probably users could not well understand why it is
more harder to do the same thing on the opposite direction (down).
P.S: There are even four additional use cases: when the user want a
smaller plasmoid, but the cases are almost equals.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/35
------------------------------------------------------------------------
On 2009-06-27T18:21:38+00:00 Maciej Pilichowski wrote:
ad.#27
Using KDE4.3 beta2 handles are shown in vertical only, meaning I have to
move to opposite side of the widgets just to get it resized, when you
are moving mouse from below.
ad.#33
Finex, thanks for the testcases -- but unfortunately it only shows we
are going in the circles. You cannot get intuitive (>20 years old)
resizing UI if you are limited to resize handles (i.e. the direction of
the resizing is determined by resize handle placement).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/36
------------------------------------------------------------------------
On 2009-06-27T19:00:25+00:00 FiNeX wrote:
Indeed Maciej, I've simply drawn that png for having a visual
rappresentation of the problem :-)
One possible solution could be to allow the current "resize" icon to
resize not only to the current direction... it is a bit hard to explain
with words. I'll try to draw an image...
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/37
------------------------------------------------------------------------
On 2009-06-27T19:03:26+00:00 FiNeX wrote:
Created attachment 34867
Improved resize plasmoid example
This .png shows how plasmoids could be easily resized to the wanted
position. I've shown the vertical movement, the horyzontal is the same.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/38
------------------------------------------------------------------------
On 2009-06-27T19:23:03+00:00 Maciej Pilichowski wrote:
Do I see flip-resize? If yes -- it still creates unsolvable cases.
Example -- you have plasmoid 100x100 pixels 10 pixels above the bottom
edge of the screen. You would like to have 100x110 pixels plasmoid at
the bottom of the screen.
Of course it is all caused by reinventing the wheel and pretending
plasmoids cannot be resized the way windows are (not you). Because let's
face it -- windows behaviour was not conceived as some kind of who-
needs-it theory, its purpose was exactly this -- easy resizing.
So we can come up with behaviour A, B, C...Z and we still won't beat
simple geometrical resizing.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/39
------------------------------------------------------------------------
On 2009-06-27T19:29:29+00:00 Groszdanireg wrote:
FiNeX: your mockup is still unusual: if you resize the bottom edge, the
top of the plasmoid goes to where the bottom was before. It would be
better if in this case, when the handle reaches the bottom of the
plasmoid, the top jumped back to the original top edge - but the layout
of the handle (where the resize button is normally at the top) would be
strange.
I second Maciej, the best is the traditional window resizing method
(with edges appearing if you move the mouse over or near the plasmoid).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/40
------------------------------------------------------------------------
On 2009-06-27T21:17:42+00:00 Voicu Hodrea wrote:
Uhm, am I missing something? Instead of trying to find the perfect
behavior that will please everyone (which IMO will never happen) why not
make it customizable? There wouldn't be many things to customize and
they wouldn't have many options. Defaults will probably (still) be an
issue but not as critical. Anyway isn't customizability the selling
point of KDE?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/41
------------------------------------------------------------------------
On 2009-06-27T21:21:39+00:00 Groszdanireg wrote:
hvm, you are right. What do the handle things depend on? The desktop
containment?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/42
------------------------------------------------------------------------
On 2009-06-28T07:56:53+00:00 Maciej Pilichowski wrote:
ad.#39
Hvm, Normally I am all for options, configuring, etc. but here...?
Adding customization adds complexity. Adding customization (in this
case) means there will be at least two modes, one broken, and one
perfectly natural. Is there any user who would like to go trough all the
hoops just to make resize in N steps instead of 1 (see Finex example)?
Seriously, I doubt it.
ad.#38
Daniel, about edges. It struck me that the priorities of plasmoid actions are (currently) mixed up. According to plasmoid look, the most common action is move, and then equally common actions are resize and rotate.
move -----> (rotate+resize)
It is hard to believe -- in reality move is the most common action, but not far from resize, and then, rather rare action is rotate.
move -> resize --------> rotate
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/43
------------------------------------------------------------------------
On 2009-06-28T09:53:35+00:00 Voicu Hodrea wrote:
"Adding customization (in this case) means there will be at least two
modes, one broken, and one perfectly natural."
It's broken from your point of view. And I didn't say anything about 2
'modes'. What I had in mind was a few options, each of them customizing
one aspect of the plasmoids' moving and resizing. Like "resize from
center y/n" "moving handle placed at mouse/left/right/up/down" etc. I
don't think it would increase complexity that much and the user wouldn't
go crazy if there was a new pane in the desktop config or something.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/44
------------------------------------------------------------------------
On 2009-06-28T14:09:21+00:00 Groszdanireg wrote:
By the way, what is exactly the problem with full resizeable borders?
Most plasmoids already have some sort of frame; where would it hurt if
they were resizeable? (With edges appearing on mouseover.)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/45
------------------------------------------------------------------------
On 2009-06-28T21:13:27+00:00 Kde-2011-08 wrote:
Grosz is correct: there already is an established method of resizing
rectangular screen objects. Let me ask this: what is bad about the
current window-resizing behaviour? What problem is the new behaviour
trying to solve?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/46
------------------------------------------------------------------------
On 2009-07-03T17:40:53+00:00 Kde-2011-08 wrote:
I installed Kubuntu 9.04 with KDE 4.2 for a new user today. After
showing him how I move plasmoids and resize them, he attempted to
configure his desktop the way he sees fit. He added the World Clock
plasmoid, dragged it up to the top of the screen, then tried to enlarge
it. After about a minute of confusion then frustration, he gave up. He
did not realize that he must perform the size maneuver before the
placement maneuver. He tried grabbing at grab handles that weren't
there, dragging the size to it's smallest size, then continuing, holding
shift, ctrl, alt, and the Tux key, right clicking, middle clicking, and
probably some other techniques that I don't remember. And this is not
some idiot, he is a retired electrical engineer.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/47
------------------------------------------------------------------------
On 2009-07-03T18:27:22+00:00 Vedran Furač wrote:
> And this is not some idiot, he is a retired electrical engineer.
This is the problem. Plasma is just not meant to be used by non-idiots.
It is designed for idiots and children.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/48
------------------------------------------------------------------------
On 2009-07-03T18:51:07+00:00 aseigo wrote:
@Dotan: and after being shown how to use it, how did he manage?
btw, i find that the people who have the hardest times with new things
are people who are the most familiar with older things. basic learning
principle.
@Vedran: one more non-constructive comment like that and i will have
this report purged.
keep it constructive.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/49
------------------------------------------------------------------------
On 2009-07-03T19:01:47+00:00 Groszdanireg wrote:
#47: "people who have the hardest times with new things are
people who are the most familiar with older things"
True. And we cannot ignore the fact that the vast majority of potential
KDE 4 users are familiar with the most basic UI principles of
Windows/KDE 3/GNOME/Mac OS X most of which are the same on all these
platforms (with OS X being somewhat different but window moving works
this same way even there).
"one more non-constructive comment like that and i will have this
report purged"
That wouldn't help in the original problem.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/50
------------------------------------------------------------------------
On 2009-07-03T20:14:59+00:00 aseigo wrote:
@Grósz: widgets are not windows (i keep repeating that, people keep
insisting on viewing them as such ..); it's much more of a web content
type model than a windowing model. windowing is ok, but it has a lot of
shortcomings. the idea is to not make these into windows and fall back
into that rat-hole. once we start mimicking windows people will expect
more and more windowing behaviour, and that just won't work out nicely.
"That wouldn't help in the original problem."
no, it won't. which is a good reason to keep the discussion here civil.
i'm under no obligation to put up with people here or elsewhere; i do
work with people quite willingly due to a sense of participation and
teamwork. when that is removed, i remove the causes.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/51
------------------------------------------------------------------------
On 2009-07-03T20:26:34+00:00 Groszdanireg wrote:
I understand that widgets are not windows. But (as Dotan has a practical
example, and yourself said it too) users don't.
(Btw my personal opinion about web content is that the biggest
inconveniences of web content stem from that web pages cannot use
traditional user interfaces and more complex pages, where the web page
is not just a "document" but the "user interface of a program" have to
mimic traditional UIs but they are always inferior.)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/52
------------------------------------------------------------------------
On 2009-07-03T20:42:57+00:00 Vedran Furač wrote:
> widgets are not windows (i keep repeating that, people keep insisting
> on viewing them as such ..)
No. But you CAN resize then, you CAN move them... they have window-like properties.
It's just much harder to use that properties, less intuitive and requires more time to do the same action.
This discussion is useless, you have your vision and you won't change
your mind.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/53
------------------------------------------------------------------------
On 2009-07-03T21:23:24+00:00 Kde-2011-08 wrote:
> and after being shown how to use it, how
> did he manage?
In our culture we arrange items from right to left then from up to down,
like we read. Europeans arrange items from left to right, but still from
up to down, like they read. Plasma seems to assume that the user will
arrange items from down to up, as items can be placed along the bottom
of the screen and then resized comfortably, yet cannot be arranged along
the top of the screen and then sized comfortably. So far as I know, no
human culture arranges from down to up.
> btw, i find that the people who have the hardest times
> with new things are people who are the most familiar with
> older things. basic learning principle.
I agree. Note that this user went from IE to Firefox without a blink,
and from MS Office to Open Office without a complaint. He is very good
at figuring things out, which is why we get along. I asked him
afterward, and he _did_ notice that the resize was only moving the upper
and right hand side, but he refused to beleive in his instict telling
him that there is absolutely no way to resize on the bottom as well. He
considered just moving the plasmoid and then resizing the top, however,
he considered that as a last-resort workaround and wanted to figure out
the right way to do it.
> widgets are not windows
They are rectangular containers of information. The problem of how to
intuitively resize rectangular containers was solved decades ago.
> once we start mimicking windows people will expect more and
> more windowing behaviour, and that just won't work out nicely.
So the solution is to make resizing unintuitive? How about having
distinct, huge grabhandles at all four corners when the user clicks the
resize button. Don't let them resize from the edges, like windows, but
only from the corners. It will be visually different from windows, yet
intuitive.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/54
------------------------------------------------------------------------
On 2009-07-03T21:33:00+00:00 R-mike-v wrote:
@Aaron : Would it be possible to add an external border to the plasmoid
so that it could be resized? That could be given rotate handles and the
close and settings could be blended into the corner. I think that if
the design is different enough then people will not expect window-like
features.
Maybe if you itemized your fears about which window features would be
wanted then it might be possible to work around those problems so that
people do not expect them. It might just be a case of getting the
graphic design right.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/55
------------------------------------------------------------------------
On 2009-07-03T21:47:13+00:00 Angel Blue01 wrote:
I don't have much to add to this discussion, but I thought I'd add my
thoughts.
First its a relief that plasmoids can even be resized. I booted into
Windows the other day and carelessly tried to resize a widget,
forgetting that in Vista/7 they are fixed sizes. :-)
(In reply to comment #52)
> In our culture we arrange items from right to left then from up to down, like
> we read. Europeans arrange items from left to right, but still from up to down,
> like they read. Plasma seems to assume that the user will arrange items from
> down to up, as items can be placed along the bottom of the screen and then
> resized comfortably, yet cannot be arranged along the top of the screen and
> then sized comfortably. So far as I know, no human culture arranges from down
> to up.
>
That's another issue I have with Plasma, I'd prefer if it arranged items left to right then top to bottom, like the English language. Actually, I'd prefer that this be the default, with the option to change it, (depending on the language?) so if I want it to be like Windows (top to bottom then left to right) I can :P
But that should go in another issue I'd think.
>
> They are rectangular containers of information. The problem of how to
> intuitively resize rectangular containers was solved decades ago.
That's why I don't understand why the resistance to resizing them like
windows, all rectangular containers that can be moved around should be
moved and resized in similar if not identical ways.
>
> So the solution is to make resizing unintuitive? How about having distinct,
> huge grabhandles at all four corners when the user clicks the resize button.
> Don't let them resize from the edges, like windows, but only from the corners.
> It will be visually different from windows, yet intuitive.
I think this is the next best thing to having them be resized like
windows. So I guess this would get my vote for best solution to the
issue.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/56
------------------------------------------------------------------------
On 2009-07-03T22:08:21+00:00 Groszdanireg wrote:
#54: In the resize issue left-to-right then up-to-down and up-to-down
then left-to-right are not different cases since plasmoids can be
resized simultaneously in both directions. Currently even left-to-right
and right-to-left are not different since the handle appears on the side
which is closer to the mouse. What makes a difference is up-to-down and
down-to-up because with the current method only either the top or the
bottom edge can be moved - currently the top which corresponds to a
down-to-up arrangement.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/57
------------------------------------------------------------------------
On 2009-07-03T22:18:37+00:00 Maciej Pilichowski wrote:
@Aaron,
> btw, i find that the people who have the hardest times with new things are
> people who are the most familiar with older things. basic learning principle.
When new things are contradiction of previously acquired knowledge --
yes, it is well known effect. And _knowing_ that every good designer
does not turn upside down his/her product (at least it will annoy user,
at worst it could be dangerous). Unless he/she does not care.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/58
------------------------------------------------------------------------
On 2009-07-03T23:04:11+00:00 aseigo wrote:
@Maciej: "And _knowing_ that every good designer does not turn
upside down his/her product"
only if that product is actually like the product it's mimicking. if a
product mimicks something falsely it raises incorrect expectations and
assumptions.
square pegs and round holes.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/59
------------------------------------------------------------------------
On 2009-07-03T23:13:02+00:00 Groszdanireg wrote:
>From the viewpoint of the user they seem to be like windows enough that
they expect window-like behavior. Reisize behavior which they are used
to in every application in which something can be resized. (I cannot
think of any well-known instance where something can be resized but not
by an edge and possibly a corner.)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/60
------------------------------------------------------------------------
On 2009-07-04T02:08:09+00:00 Kde-2011-08 wrote:
> square pegs and round holes.
No, Aaron, both the windows and the widgets are square. Maybe if the
widgets were made round the current behaviour would be acceptable.
The problem is two-fold:
1) The current behaviour is non-intuitive.
2) The current behaviour does not let the user configure his desktop in a top-down fashion: put the widget at the top, size it how you wish. The current behaviour forces the user to resize the plasmoid before he can put it at the top of the desktop. The problem is, due to reading from top-down users are inclined to organize their desktops in a similar fashion.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/61
------------------------------------------------------------------------
On 2009-07-04T05:37:36+00:00 Tyrerj-4 wrote:
Widgets may not be windows, but they are rectangular objects which
people want to re-size and move. We are all used to re-sizing and
moving objects by using drag targets. This is not just windows but
objects in applications. Taking a screen shot of a Region of the screen
use drag targets in KDE-4.3.
The three important things in GUI design are 1. Consistency, 2.
Consistency, 3. Consistency. :-D This is an old joke but it is true.
I know how the current method is supposed to work. I do not like this
little margin tag things. I find the current method of resizing and
moving to be difficult to use -- understanding how it works does not
help with that. Part of this is that there is no snapping to the edge
of the frame. This user wants to precisely arrange his desktop and the
current method is not well suited to doing that.
IMHO, this is a usability issue and it needs to be addressed. We need a
different method of re-sizing and moving widgets. IIRC, in KDE-3.x,
people were asking for dragable Panels, so this isn't exactly a new idea
or request.
I am not saying that we have to use drag targets. KDE-3.5 uses slider
/spin-box combination widgets to size things. So, I would be happy with
a dialog box with a set of these to re-size and move stuff.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/62
------------------------------------------------------------------------
On 2009-07-04T08:14:30+00:00 Maciej Pilichowski wrote:
> I am not saying that we have to use drag targets.
Actually we have to. And plasmoid UI _will_ change (*) it is just a
matter whether it will be done at who-cares-now moment, or when such
change makes a difference.
(*) simply because current UI is an obstacle for a given task and it
doesn't scale up with new technologies. Look at the Surface -- sliders?
handle toolboxes? No! You want to rotate an object, you rotate the
object. You want to move the object you move the object. _Natural_.
We won't get new breed of human, we won't stop development of hardware.
It is better to admit a mistake and change it now, than pity oneself in
3 years "who would know" -- a lot of KDE users know, competition knows.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/63
------------------------------------------------------------------------
On 2009-07-04T13:54:02+00:00 Kde-2011-08 wrote:
> You want to move the object
> you move the object.
Go watch users try to move their panels! I have asked at least five or
six users to try it on KDE 4.2, and even though there is a button RIGHT
THERE that says "Screen Edge" they try fruitlessly to drag the panel
away. Of the users that I asked, only two were able to move the panel to
a different screen edge, and one of them was after I gave him a hint to
read all other options available to him. The ones that failed had failed
even after I told them to read what options were available to them.
Apparently the KDE 4 way is "in order to move object A, pull on object
B". Users just cannot understand that, even if there is a big button
marked "pull on me". And why should they even want to, when every other
application on the planet uses the idea "in order to move an object,
just pull on it"?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/64
------------------------------------------------------------------------
On 2009-07-05T22:53:06+00:00 Tuomas-1 wrote:
Reading the comments, I came up with a following concept:
http://forum.kde.org/viewtopic.php?f=83&t=62206
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/65
------------------------------------------------------------------------
On 2009-07-06T00:21:58+00:00 FiNeX wrote:
@Tuomas: basically your idea is the same of mine on comment 36 .
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/66
------------------------------------------------------------------------
On 2009-07-06T12:08:32+00:00 Kde-2011-08 wrote:
@Tuomas: I personally like to see the contents of the plasmoid change
shape as I resize. It lets me decide what the optimal size is.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/67
------------------------------------------------------------------------
On 2009-07-06T13:46:21+00:00 Tyrerj-4 wrote:
(In reply to comment #65)
> @Tuomas: I personally like to see the contents of the plasmoid change shape as
> I resize. It lets me decide what the optimal size is.
Yes, I agree. Whether using the mouse or a spinbox, it is necessary do
see what you are doing. So, I would have to vote against rubberbanding.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/68
------------------------------------------------------------------------
On 2009-07-07T04:13:04+00:00 Dherring-0 wrote:
(In reply to comment #66)
> (In reply to comment #65)
> > @Tuomas: I personally like to see the contents of the plasmoid change shape as
> > I resize. It lets me decide what the optimal size is.
>
> Yes, I agree. Whether using the mouse or a spinbox, it is necessary do see
> what you are doing. So, I would have to vote against rubberbanding.
Could the window contents be repainted during a rubberband operation?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/69
------------------------------------------------------------------------
On 2009-07-07T07:17:44+00:00 Maciej Pilichowski wrote:
Technically, yes. But there are other drawbacks -- rubberband (if I
understood correctly) works as "do it from scratch". It is frustrating
and tiresome because it does not allow correct only the "errors", you
have to correct everything.
However, if we are up to find something new it has to be not worse than
classic resizing. Otherwise I don't see a point. And it also be good to
point out a living user (not imaginary) who is confused with classic
resizing applied to plasmoids (it is the person who is surprised that
you cannot shade the panes in Dolphin).
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/70
------------------------------------------------------------------------
On 2009-10-13T15:01:24+00:00 Bug-4 wrote:
In my opinion it would be the best, if the resizing and placement can be
done like a window: if the mouse is over a plasmoid a big frame appears
and you can resize them intuitve. Some buttons like a "x" for "close"
(delete the plasmoid), a "spanner" for "preferences" and a "resize"-icon
can be there like the normal window-buttons.
The advantage are better handling, intuitiv (we alle know about the
handling of window's) and at last a better handling on small displays
like the Nokia N900 ;)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/72
------------------------------------------------------------------------
On 2009-11-01T11:33:28+00:00 Maciek Gajewski wrote:
In 4.3 plasmoids are not resized with fixed center, but with fixed
corner instead. This somehow improves the situation, so I'm removing my
votes from the issue. But still - while on earth can't plasmoids use
more intuitive, window like behaviour?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/73
------------------------------------------------------------------------
On 2011-05-20T17:19:56+00:00 Alessandro Nakamuta wrote:
Resize plamoid like window is possible with grid desktop.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/74
------------------------------------------------------------------------
On 2012-03-13T19:10:45+00:00 Navid-zamani wrote:
The Compiz window resizing paradigm is even better. It doesn’t require fiddling with tiny 1px borders or limited 4×4px buttons for resizing.
All you do, is hold the Meta key, and press the right mouse button anywhere in the window. Depending on where, you drag a different edge/corner. Example: if you click in the lower right area of the window, you can resize the right and bottom edges.
KDE can do this, albeit in a fashion that feels more primitive, as well.
In Compiz this works really well, and makes all borders, title bars or
buttons obsolete and kludgily inconvenient.
You can also drag windows by using the left instead of the right button.
And close windows by middle-clicking instead.
I *really* recommend trying it. It’s oh-so nice and together with a
sticky grid makes window management a breeze.
I recommend doing this for Plasma as well. It could even be added in parallel, allowing the primitive way and this way of doing it, without any compromises. :)
Who’s with me? :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/75
------------------------------------------------------------------------
On 2012-03-13T19:24:19+00:00 Maciej Pilichowski wrote:
@Navid Zamani,
> I recommend doing this for Plasma as well.
Please don't hijack reports, what you describe is another issue. One
report = one issue.
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/76
------------------------------------------------------------------------
On 2012-03-13T19:55:15+00:00 Navid-zamani wrote:
(In reply to comment #73)
> @Navid Zamani,
> > I recommend doing this for Plasma as well.
> Please don't hijack reports, what you describe is another issue. One report = one issue.
Wait, what?
• The title of the bug says “resize plasmoids like windows”.
• I suggested the best way to resize windows, arguing that if that’s best for windows, it’s the best way to implement “resizing plasmoids like windows” in practice.
• You say I highjacked the thread^Wbug??
The only explanation that I have, is that you haven’t read or understood
my comment at all. I’m sorry if I didn’t make myself clear enough, but
please make a bit of a bigger effort with reading things too, OK?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/77
------------------------------------------------------------------------
On 2012-03-13T20:13:12+00:00 Bugs-n wrote:
(In reply to comment #74)
> (In reply to comment #73)
> > @Navid Zamani,
> > > I recommend doing this for Plasma as well.
> > Please don't hijack reports, what you describe is another issue. One report = one issue.
<snip>
> The only explanation that I have, is that you haven’t read or understood my
> comment at all.
That answer wasn't directed at your whole comment, just at the part where you went off-topic, namely the suggestion for non-plasmoids. If you were serious about that, open a new report.
Otherwise, may I suggest you take your own advice and try to understand what you're responding to?
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/78
------------------------------------------------------------------------
On 2012-03-13T20:39:46+00:00 Navid-zamani wrote:
(In reply to comment #75)
> That answer wasn't directed at your whole comment, just at the part where
> you went off-topic, namely the suggestion for non-plasmoids.
Aah, yeah, that makes sense. You didn’t say that it was just about that
part though, so it was left open what you meant.
But now we’re clear, so all is well. :)
Reply at: https://bugs.launchpad.net/ubuntu/+source/kdebase-
workspace/+bug/253709/comments/79
** Changed in: kde-baseapps
Status: Confirmed => Unknown
** Bug watch added: KDE Bug Tracking System #165432
https://bugs.kde.org/show_bug.cgi?id=165432
** Bug watch added: KDE Bug Tracking System #165391
https://bugs.kde.org/show_bug.cgi?id=165391
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kdebase-workspace in Ubuntu.
https://bugs.launchpad.net/bugs/253709
Title:
Plasmoid resizing is undiscoverable
To manage notifications about this bug go to:
https://bugs.launchpad.net/kde-baseapps/+bug/253709/+subscriptions
More information about the kubuntu-bugs
mailing list