Closed catalinauser closed 3 years ago
felixhageloh
commented
3 years ago Hey have a look at this twitter thread https://twitter.com/Felx/status/1302530236907692035. Maybe it will help adjusting your widgets to the new interaction model!
Glad you enjoy the app! You can write widgets using JSX, btw - its the new standard (coffescript support is left to remain backwards compatible)
catalinauser
commented
3 years ago Thanks. It took me a little bit to realize that indents in the widget code had to be tabs and not spaces or the parser breaks. Oops!
Also, when interaction is enabled in the preferences, the widget layer sits above the desktop, obscuring files on the desktop even when the widget css includes "pointer-events: none".
Given this difference, can you help me understand why the option to use a modifier key to enable interaction was removed in the latest version? The tradeoff doesn't seem worthwhile to me. I think I must be missing something.
felixhageloh
commented
3 years ago Can you give some more details on your use case? Would you prefer that widgets stay behind desktop items, but are 'lifted' to the front temporarily when pressing a shortcut (i.e. the old behavior)? Do you have some widgets you would like to stay behind desktop items and not be clickable and others that you would like in front and always be clickable?
The change was motivated by the fact that many people seemed to expect widgets to just be always clickable. I had many issues opened that mentioned that people could not interact with widgets (even though the interaction shortcut existed). I personally also never really liked the shortcut - in my mind it was more of a hack.
catalinauser
commented
3 years ago To me, it always seemed the basic concept of an app like this (or GeekTool) was to present data in a way that was visually integrated with the background of the desktop. That means that files on the desktop would obscure the widget layer the same way they obscure the background image on the desktop. If there is something important enough that it should remain visible then locate the files elsewhere, but do not prevent or alter the normal use/operation of the Finder desktop.
Interaction with the widgets always felt like a bonus feature, only required for a subset of widgets. Many of the functions achievable through widget interaction are also assignable to global keystrokes using utilites like Qicksilver or Alfred, making them more readily and quickly accessible than by using mouse event interactions. An exception would be a scrollable list presented in a clipped widget with overflow on.
I suppose the ideal would be to have a property assignable to each widget that allows the author to set the widget to be either background or foreground relative to desktop objects, with perhaps a default that background widgets only offer interaction by means of a user-definable modifier key, and foregrounded widgets could employ pointer-events:none if they are intended to float statically above the desktop but not be interactive. This would accommodate both the ethic of non-interference with the Apple HID of the Finder and the wish to present both static and fully interactive widgets in a layer above the Desktop but behind the standard application layer.
I realize that accomplishing this may require a second instance of the chromium process, which could be expensive in terms of machine/processor resources. On the upside, chromium has recently made much-needed improvements in processor resource efficiency.
By the way, one feature of GeekTool that I found very useful was the ability to group widgets, making it simpler to select and display different subsets of all current widgets using Applescript, depending on the needs of the moment. Consider this a feature request for future versions. :-)
felixhageloh
commented
3 years ago thanks for the thorough reply.
I suppose the ideal would be to have a property assignable to each widget that allows the author to set the widget to be either background or foreground
I agree!
require a second instance of the chromium process, which could be expensive in terms of machine/processor resources
Luckily Übersicht uses a WebView, i.e. Safari, under the hood ;). Joking aside, the same concern applies tho.
felixhageloh
commented
3 years ago curious to hear wether the latest 1.6 releases addressed this issue for you!
catalinauser
commented
3 years ago Just installed. First thoughts:
• Thank you! This is a very nice feature update.
Specifying a :hover selector for each widget's base element makes it easy to quickly determine which ones are foreground and which ones background.
Having a unified interface which allows one to view a list of all widgets in the folder and select foreground/ background and hide/show for each would be smoother than having to select menu options for each one (particularly if one has multiple active widgets -- I have eleven at the moment). This could even be implemented in a widget which provides direct access to the preference settings and all other global options for the application. From there, it would only be a short hop to creating widget groups which could be toggled all at once either by the GUI or by AppleScript.
Is there a Release Notes page (a link accessible within the About dialog would be sensible) because I have not noticed one.
felixhageloh
commented
3 years ago Thanks for the feedback again! A better widget management UI has been on the wishlist for a while now. Also, good point about the release notes - I have an archive of all release notes but they are currently not readily accessible
Ubersicht 1.5 (63) macOS Catalina 10.15.6 MacBook Pro (16-inch, 2019)
Enabling Interaction in the Ubersicht preferences is causing the widgets to intercept UI interations intended for Desktop objects.
In the previous version of Ubersicht, a modifier key was required for widget interaction, without which the Finder handled the mouse clicks, as expected. The option to require a modifier key is no longer apparent in Ubersicht. This is a significant downgrade in user experience with the application.
I love this app (though I never liked coffeescript and prefer basic JS/CSS for widget coding) and I thank you for making it. Please contact me if I can provide any further useful information for tracking down and fixing this issue.