Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Added menu item icon to show whether updates are available #519

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

paul-court
Copy link
Contributor

@paul-court paul-court commented Feb 20, 2022

Issue

Fixes #489

Adds an icon to the "Help -> Check for Update..." menu and displays in one of the following states:-

All OK and up-to-date:-
image

Update is available:-
image

Exception thrown in the existing version checking code:-
image

Progress

@AlmasB
Copy link
Collaborator

AlmasB commented Feb 20, 2022

Looks great!

It seems there are 3 cases: OK, update available, exception. I think we can simplify this for the user:

case exception: (the user doesn't need to know there is an error, so just fall through to case OK)
case OK: we should show OK icon and say "All up-to-date!" - also disable this button since no need to click.

case update available: we should show download icon and say "Update available..."

Is there any way we can do this in FXML? Perhaps add both of these buttons and then make them visible / invisible as needed from code.

@paul-court
Copy link
Contributor Author

I'm not sure about doing it all from the FXML, I might need some help with that.

It looks like the existing logic handles this with the SceneBuilderApp::canPerformControlAction() method. By getting the switch to return false for CHECK_UPDATES , the menu item becomes disabled:-
image

If I were to change this one to being two menu items that are shown/hidden, it would make it the odd one out.

I can easily add the same if check for the version to this switch statement, but I'll have a stab at refactoring a little bit (rule of thirds and all that).

@AlmasB
Copy link
Collaborator

AlmasB commented Feb 21, 2022

You could go with "All OK" in FXML with the appropriate icon. Then, in code, check for updates and overwrite if an update is available.

Let me know if you need help with the FXML part of it.

@jperedadnr
Copy link
Collaborator

jperedadnr commented Feb 25, 2022

Doing a quick test on Mac:
image

Seems like iconView.setFitHeight, iconView.setFitWidth don't have any effect, and imageView uses the size of the icon (which works fine if the menubar is not system menu).

@paul-court
Copy link
Contributor Author

Oh, thanks @jperedadnr. I'll have a play round.

@jperedadnr
Copy link
Collaborator

Seems that GlassSystemMenu::getPixels doesn't check other than the url of the image to get the pixels down to native.
So you'll need to provide a smaller size for the icons?

@AlmasB
Copy link
Collaborator

AlmasB commented Feb 25, 2022

My original proposal was to use something like new red Circle(), which is visible when there is an update, otherwise not. Both for the update item and the "Help" menu title. I wonder if that would simplify this issue.

@jperedadnr
Copy link
Collaborator

@AlmasB
Copy link
Collaborator

AlmasB commented Feb 25, 2022

In which case, for this PR, we could ditch the visual indicator and do:

  • If update available, the menu item text is "Update available..."
  • Else, the menu item text is "Up to date" and greyed out (disabled).

Later, once we have a notification service of some sort like a non-modal pop-up in the top-right corner or something, we can make use of that to notify the update is available.

@paul-court
Copy link
Contributor Author

Thanks for all the feedback.

@AlmasB I agree with the simpler UX for the user, so I removed the exception state, and the default if anything goes wrong is to show the OK message, as you suggested.

However, when simulating a delay in the thread that goes off and grabs the version number from the web, I felt some kind of user feedback that something was happening in the background would be better. So I added an initial state of "Checking for update...". This is what it looks likes with a forced 10s delay (sorry about the washed out gif colours):-

slow_net_sim

Since there is now no image for the default state, I've not added anything else to the FXML. If you still want to experiment with that, then I'll have to take you up on your offer for some FXML assistance because I couldn't figure that bit out.

@jperedadnr I found an article from Dirk Lemmermann and updated the images and code accordingly. However the same oversized icon was rendered, so this is deffo a bug in the Mac code as it correctly identified a high-res system and loaded [email protected] but then still rendered it at double the size. So I have just removed the high-res versions for now.

This is how it looks on Mac:-

help_menu_mac

And on Linux:-

help_menu_linux

And on Linux when there's an update available:-

help_menu_linux_update

@paul-court
Copy link
Contributor Author

FYI: I think I fixed the icon rendering issue in openjfx:- openjdk/jfx#743. So hopefully we can put some high res icons back in play at some point in the future (if/when that PR gets merged).

@@ -235,6 +234,10 @@ public boolean canPerformControlAction(ApplicationControlAction a, DocumentWindo
result = true;
break;

case CHECK_UPDATES:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to make this change at all? If the update is not available, the item is disabled, so not clickable. I think the existing behaviour is fine here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. The checks are performed every time you open the menu. Even with disabling the menu item in the FXML file, if we leave this hard coded to a true response, it will re-enable the item when you open the menu.

AlmasB
AlmasB previously approved these changes Feb 27, 2022
Copy link
Collaborator

@AlmasB AlmasB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks.

@jperedadnr did you want to have another look at this? If not, we are good to go.

@AlmasB AlmasB changed the title fix: Adds status icon to the Check for Updates menu item. Fixes #489 feat: Added menu item icon to show whether updates are available Feb 27, 2022
@@ -191,7 +191,9 @@ menu.title.no.window = No Window
# Help menu items
menu.title.scene.builder.help = Scene Builder Help
menu.title.show.welcome = Show Welcome Page
menu.title.check.updates = Check for Update...
menu.title.check.updates.available = Update available
menu.title.check.updates.ok = All up-to-date!
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This text out of context can mean many things. We need a better wording like "Updates: Scene Builder is up-to-date", which is longer, but I see that the menu is already wider than expected:

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about "No updates available"?

Also, menu doesn't have that extra space on Linux 🤷
image


Platform.runLater(() -> {
checkUpdatesMenuItem.setGraphic(iconView);
checkUpdatesMenuItem.disableProperty().setValue(false);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to disable this menu option?

In case the user really wanted to be sure, clicking on it should at least bring a dialog saying that the current version XXX is already up-to-date, which is what we already do now?

image

try {
isUpdateAvailable = isCurrentVersionLowerThan(latestVersion);
} catch (NumberFormatException e) {
e.printStackTrace();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this to Logger.logSevere ? We shouldn't print stacktraces to console as they get lost unless you run from command line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just following what the rest of the code in the block was doing. e.printStackTrace() seems to be used quite a lot.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand, but we have logs for a reason, and that's how new PRs should be tackling exceptions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a search of how Logging is being done elsewhere. Seems we have two patterns:-

Logger.getLogger(AppSettings.class.getName()).log(Level.SEVERE, "An exception was thrown:", ex);

or

Logger.getLogger(PreferencesRecordDocument.class.getName()).log(Level.SEVERE, null, ex);

With the second one seeming to be a bit more common. Any recommentation on which to use?

I'm assuming from the output that it will be clear its an exception, making the "An exception was thrown:" text redundant?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The String message should normally include some useful information. So in the above case it might say: "Cannot parse version string" or something similar.

@jperedadnr
Copy link
Collaborator

@AlmasB I've added some comments.
@Gargoyle Looks good, it's also great that you created the OpenJFX PR.

@Oliver-Loeffler
Copy link
Collaborator

@Gargoyle Would you mind to have a look at the conflicts? May be we can get this one eventually merged. It technically looks fine to me.

@Oliver-Loeffler Oliver-Loeffler added the enhancement New feature or request label Aug 26, 2024
@Oliver-Loeffler Oliver-Loeffler added this to the 23 milestone Aug 26, 2024
@Oliver-Loeffler Oliver-Loeffler modified the milestones: 23, 24 Sep 27, 2024
@paul-court
Copy link
Contributor Author

I had a quick look this evening and got myself into a rebase nightmare. 🙄

I've hardly looked at SceneBuilder (or even done much JavaFX) in the last two years, so what will probably be best is that I'll see if I can find some time in the next week or so to get back into it a bit, and just re-implement this on a fresh branch cut from the latest main/master.

My fix for MacOS icon rendering did make it into JavaFX 20, so if SceneBuilder is targeting that or later as a min requirement, I can redo the high res versions of the icons too?

Will need to pair up with someone though, as I don't even have my old Mac to check even basic stuff anymore.

@Oliver-Loeffler
Copy link
Collaborator

Oliver-Loeffler commented Sep 27, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update dialog should be extracted into a non-intrusive notification
4 participants