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.
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?
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 :-).
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.
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.
@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.
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.
I proposed an idea here http://bugs.kde.org/show_bug.cgi?id=165391#c6, i think that it could solve even this issue
*** This bug has been confirmed by popular vote. ***
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
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.
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.
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 :-).
*** Bug 168892 has been marked as a duplicate of this bug. ***
(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.
*** Bug 171549 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.
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.
#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.
In KDE 4.2 you resize plasmoids in one direstion. So does it meen this raport can be closed?
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).
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.
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.
"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?
> 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!
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.
"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"
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.
> 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.
Created attachment 34862 [details] 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.
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).
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...
Created attachment 34867 [details] 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.
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.
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).
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?
hvm, you are right. What do the handle things depend on? The desktop containment?
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
"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.
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.)
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?
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.
> 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.
@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.
#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.
@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.
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.)
> 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.
> 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.
@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.
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.
#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.
@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.
@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.
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.)
> 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.
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.
> 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.
> 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"?
Reading the comments, I came up with a following concept: http://forum.kde.org/viewtopic.php?f=83&t=62206
@Tuomas: basically your idea is the same of mine on comment 36 .
@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.
(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.
(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?
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).
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 ;)
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?
Resize plamoid like window is possible with grid desktop.
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? :)
@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.
(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?
(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?
(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. :)
Hello! This feature request was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this feature request is already implemented in Plasma 5, or is no longer applicable. Accordingly, we hope you understand why we must close this feature request. If the requested feature is still desired but not implemented in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham