- User Since
- Wed, Aug 21, 3:01 PM (3 w, 3 d)
...But is this true? the feature doesn't exist yet. We have no idea whether or not it would impose overhead on Spectacle when not in use. Maybe we should implement it before designing a feature to turn it off if it has bad performance. Who knows, maybe the performance turns out to be just fine! :) I honestly have no idea how the feature could possibly cause bad performance when it's not in use. "I want to turn it off because it has bad performance" smacks of a fixable design error that should be fixed, not worked around.
Fri, Sep 13
Anything requiring so technical an explanation of the options is certainly not something that should be in the UI.
That's unfair :D it's not a finished feature, it's wip , it was a technical analysis of scenarios, which should be taken into account and possible solutions (with the option to add some solutions from you or another). That doesn't make the setting complicated or anything for the user. I could explain every single revision I've done in such great detail ;)
Fri, Sep 6
unless all icons were removed from the desktop theme (all icons would come from the icon theme)
Thu, Sep 5
Okay I changed it in Spectacle, so in the ComboBox, Spectacle shortcut settings, global settings it displays the correct string.
Updated capture/action names (and captureMode names in enum)
One important change with that version is that Fullscreen is called "Entire Desktop" instead.
- Improve code in various places
- Change model to QListModel
- Keep reference to QAction (so the texts can be updated if a shortcut changes)
- Add captureMode as a property of QAction (setData)
I'm not sure about the structure of the tableModel. Thinking about it we don't really have a table structure of items but a list. Also it seems you are mixing columns an roles. Your model advertises itself with 3 columns but only has data 2 and each column in a row refers to the same item.
Changed if condition according to David's comment
Wed, Sep 4
- Removed formatting/style issues mentioned by ngraham
- Shortcut changes no dynamically if user changes them in spectacle's or the global settings. It does't work for the fullscreen shortcut though, this needs to be fixed
Would be great if someone could check again all options make sense in the different branches and I have not deleted any useful information accidentally.
Updated style for the other if branch
Alright, in terms of strings if I were to make one suggestion it'd be this:
Change the SHIFT tips to language like "(Hold SHIFT to Blah)" (e.g.: "Hold SHIFT to Magnify").
Fixed small bugs, updates now if you change global shortcuts
- Result is now on the left side, action on the right side
- Mouse Actions are above Keyboard actions
- Word fine-tune replaced by more clear explaination
I don't know if it's the right metric
- Did things David suggested in the comments
Tue, Sep 3
< Also, "pixel-by-pixel" (there might be a better way to say it, maybe find it later) is better than "fine tune" because it's more accurate.
If we would write it in qml I would still disagree since my initial feeling how this would look like would be somehting like:
This is how it could look like. I really like it and perhaps we could add some styling to make it look better (but I'm not a designer, so perhaps someone else has a mockup for that then :P)
I just had another idea: We have multiple controls for the same action. What about switching the order of Layout around:
I'll try to explain what I have thought about the different things you mentioned (and hope it makes sense):
Mon, Sep 2
The style should be now as normal with the right margin and selection color.
Especially getting the right margin was more difficult than expected, I figured a way out to get it, although I'm not 100% sure if that's the simplest way.
- Added style for ComboBox from theme
- Added logic for resizing the ComboBox View
- Works directly with the Color from the colorscheme and changes the transparency, rather than constructing a new color
- Style is connected to a paletteChange of QGuiApplication, so that the style would be updated if the colorscheme changes (makes no difference at the moment as the Object is created new every time at the moment anyway)
Sat, Aug 31
- Refactored code
- Added licensing
- Used QPalette instead of stylesheets
Tue, Aug 27
Figured out with @davidre how to do get the highlighting text color (on in general the text brush) and the padding most likely:
Mon, Aug 26
@felixernst my bad, sorry! I was only focused on the ComboBox itself and therefore overread that you were actually talking about the dropdown.
If the combobox's pop-up is a bit long sometime, that's not really a problem.
I actually haven't thought about that at all! I just assumed that the popup has to have the same width as the QComboBox itself. Thanks for the suggestion :)
@ngraham That's how it currently is. The shortcuts are only displayed in the popup, but the space there is limited. I agree with you that it should stay there and shall not be displayed in the ComboBox itself.
Unless you were talking about tooltips? Or did I misunderstand you completely?
@ngraham Good point, I didn't know that. What would you suggest then? It seems to me like the only way to go then is to set a width limit for the shortcuts? If a shortcut to long we could display an error message there? Something like "too long" just?
Personally I think it would make sense to have the same shortcut for copy and non-copy with an additional modifier.
Also I am a fan of Meta + Print for taking a screenshot of the active window as it maps to the windows key on my laptop which is a great metaphor.
I agree if the shortcut is displayed it should be displayed always
I'm not sure if you mean the same than me. I was favouring an approach, where only default shortcuts are displayed. So even if custom shortcuts were short enough, I wouldn't display them as from a user perspective it seems more reasonable to me when all my custom shortcuts are not displayed then when only a few of them are displayed and some other not (because they are too long).
I agree though, perfect would be to display all shortcuts always, but that's probably impossible -> Print+Volume Up+Volume Down ... I don't see a way to display such a long shortcut without making the shortcut incredibly wide, which would perhaps look very strange.
Sun, Aug 25
Personally, I find it a very useful feature too. Especially the argument of @felixernst that there is not really a point anymore in displaying the shortcut, if the user has changed them, is quite strong. In general, we can assume that users, who change the default shortcut, are then aware of their own shortcut they set (most likely these users are also power users). Still one could argue that it might be helpful for one shortcuts as well. So there would be the possibility to display only shortcuts up to a specific width. I would rather not this though, as such an approach is not straight forward to the user and might lead to confusion and bug reports.
Removed unrelated changes
Sat, Aug 24
Code refactoring: Bottom text has own class, improving readability, better separation of position and layout -> improved performance for changing the position (screen)
Fri, Aug 23
An idea to avoid calling layoutBottomHelpText would be to store the current screen rect as a member and only relayout if the center of the selection is outside the screen.
Yeah thought about that as well. But I suppose the screen rect is not really an attribute of that class from an OOP view. I think the actual problem is more that positioning logic has been mixed up with the logic for layouting.
I think it's not a problem. The default is that spectacle only remembers the old selection until it is closed. Also I would be seeing the relatively big bottom help text on one screen. And I don't really find the old rectangle I can simply start drawing a new one by clicking and dragging.
Convinced. Especially if spectacle doesn't remember the old selection on closing, my argument has no point anymore.
mid help text should be displayed on right screen now: mSelection`s top left corner defaults now to the active screen`s top left corner
bottom help text should update: update() (-> paintEvent()) calls now layoutBottomHelpText
No it's always on the left screen. The reason is probably we call drawMidHelpText if `mSelection.size().isEmpty() .
Thu, Aug 22
Removed unecessary local variable
Implemented new behaviour of handlers when they touch a screen edge
Rectangle can no be resized on edges, if the rectangle is big enough (>= 100x100)
Okay going to implement the feature that only some of the handles move inside (and we can see then if it's worth it) and going to implement the feature that resizing work on the rectangle`s edges works as well if the rectangle is not too small.
This is how it would look like
or like this
Temporary fix for multiple screen issue: Other parts (like the tooltip) don't handle multiple screens either. Will fix all these issue in a seperate patch
Wed, Aug 21
Removed unused property: Instead of a fixed size for the mouse area, it's a multiple of the handle`s size instead as it varies (touch or mouse mode)
@ngraham You have a 2-1 device, right? Could you please test if the the handles` radius increases as soon as you use touch and goes back to normal as soon as you use your mouse again? (change should happen on single click/touch)
Added "touch-mode": Adjusts the size of the handles if touch is used
There is actually one "problem" I noticed. If you resize the rectangle from big to small (where the handles become free-floating), the cursor is at the end still there, where the handler should be in the normal mode. So the handler moved away from the cursor and you have to move the cursor back to the drag handler, if you want to resize the rectangle again. I'm actually not quite sure if that's a problem, but it's definitely different to how it behaved before the patch. One possible solution would be to move the cursor automatically to the drag handler it grabbed before. But it might look strange if the cursor suddenly jumps somewhere else?
Some opinions on this would be great!
@ngraham Is there a possibility to detect a touch device? If not what radius would you prefer? I also included an option to make the area, where resizing events are noticed bigger than the actual handles. At the moment the area is twice as big see "increaseDragAreaFactor". What value would you prefer for that?
Removed unnecessary changes
Removed unessecary changes