Add Ability to Change the User Status Freely #90
kske
mpk
Labels
No Label
client
server
user made
L
M
S
XL
bug
bugfix
discussion
documentation
feature
maintenance
postponed
refactoring
wontfix
No Milestone
No Assignees
3 Participants
No due date set.
Dependencies
No dependencies set.
Reference: zdm/envoy#90
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "f/change-user-status"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Additionally added display of own user status and added logout option to StatusTrayIcon (on top of the usual keyboard shortcuts and system commands of course).
It would be good, if someone whose StatusTrayIcon is supported, would test whether my TrayIcon related changes are doing what they are supposed to be.
This is a rather essential feature. Can't believe it has taken us so long to implement.
Apart from a little bug and some code cleanup stuff, it looks quite good.
Also, I think it would be much easier to change my status if the combo box wasn't part of the settings, but rather directly available from the chat scene. However, I am not sure how too make this look good as combo boxes are rather bulky and don't fit nicely into the scene.
Maybe take a look at Skype for inspiration.
@ -0,0 +5,4 @@import envoy.event.Event;/*** Conveys the action that the currently logged in {@link User} has changed hisThis construction is complicated even for my standards.
What about "Signifies a manual status change of the client user".
@ -129,3 +131,1 @@// Add the option to logout using "Control"+"Shift"+"L" if not in login sceneif (sceneInfo != SceneInfo.LOGIN_SCENE)accelerators.put(new KeyCodeCombination(KeyCode.L, KeyCombination.CONTROL_DOWN, KeyCombination.SHIFT_DOWN), ShutdownHelper::logout);if (sceneInfo != SceneInfo.LOGIN_SCENE) {SceneContext, that could be completely generic as to what scenes it displays, except for being littered with code specific toLoginScenewhich nobody would expect here?(yes, these are both rhetorical questions)
to 1. While I know what you mean, I'd still say that this goes beyond the scope of this branch.
to 2. While I know what you mean, I'd still say that this goes beyond the scope of this branch.
It seems as if one of the next branches should cleanup that in SceneContext. I could do it in that branch, but than this branch will have two completely separate tasks on it (and it would be eve larger than it already is).
No, I think you are right. The cleanup should be performed inside a separate branch.
See #91
@ -60,0 +62,4 @@// Adding the logout menu itemfinal var logoutMenuItem = new MenuItem("Logout");logoutMenuItem.addActionListener(evt -> { hide(); UserUtil.logout(); });popup.add(exitMenuItem);This appears to be an error.
Ctrl C, Ctrl V.
@ -93,3 +108,1 @@message.hasAttachment() ? "New " + message.getAttachment().getType().toString().toLowerCase() + " message received" : "New message received",message.getText(),MessageType.INFO);if (displayMessages) trayIconI think the point of the "busy" status is that the user does not want to be disturbed, so maybe put a check in place that prevents the notification in this status.
Also, could we keep the previous formatting of this section? The new one looks very confusing to me.
@ -66,0 +70,4 @@try {UserUtil.changeStatus(Enum.valueOf(UserStatus.class, text.get(0).toUpperCase()));} catch (final IllegalArgumentException e) {final var alert = new Alert(AlertType.ERROR);We implement a standardized way of handling system command failures. Wou don't be able to display an alert if Envoy is running on the command line.
While I agree with you, there is a reason why I accepted your solution of automatically displaying an alert in case of a system command only with gritted teeth.
For now, this has to suffice. In the future I can well imagine that we can pass a consumer accepting an error to the calling method to handle errors in a command.
But, I'd say this is a branch of its own again and far beyond the scope of this branch.
I would suggest to introduce a new exception and catch that at a convenient place. No need for consumers.
I however do agree, that this is beyond the scope of this branch.
@ -66,0 +74,4 @@alert.setContentText("Please provide an existing status");alert.showAndWait();}}).setDescription("Changes your status to the given status.").setNumberOfArguments(1).setDefaults("OFFLINE").build("status");Any reason why the default is "offline"? This should be documented.
to 1. Well, normally when executing this command I'd argue that you want to change it, (from "ONLINE" in the standard case) and "OFFLINE" seemed like the most reasonable value. If you want another value, I can change that, i.e. BUSY?
to 2. Where should I document it? Our wiki is a laughable joke and the only location where it could be partially useful for the consumer would be inside the description of this system command. Should I add it there?
Okay, I can remove the default value. Even though that completely defies the purpose of default values.
I've already thought about doing that (inspired by Skype)
but that'll require some major changes to the underlying system command system (=>another branch)
To my understanding, default values are only used if there is a default that actually makes sense. In case of status changes, I don't see, why a specific status would be the most frequently used one.
Have a look at the declaration again. Already fixed.
@ -38,3 +35,1 @@clip.setArcHeight(32);clip.setArcWidth(32);contactProfilePic.setClip(clip);final var contactProfilePic = new ProfilePicImageView(chat instanceof GroupChat ? groupIcon : userIcon, 32);As we are using a dedicated component for this, why not handle the selection of the correct profile picture inside
ProfilePicImageView?Well, if I do that right inside this branch, then I'll add a (transient) Image to Chat (that will be for now always null) whose value I'm going to null check inside the mentioned constructor. Should I really do that here?
I don't see why the solution would be that complicated, but you might also resolve this in a separate branch.
@ -34,3 +29,1 @@} else {getChildren().add(new Label(contact.getContacts().size() + " members"));}getChildren().add(contact instanceof User ? new UserStatusLabel((User) contact) : new GroupSizeLabel((Group) contact));I did not locate the source of the problem, but the group size label changes its color occasionally when a member of the group changes his status to "busy".
If this is intended, how would we go about multiple group members with different statuses?
Wait what? How's that possible? That shouldn't be possible at all.
I'd love to hear how that problem is caused because I have no clue what could cause it.
Are you sure you managed to change the color of the group size label?
I've tried reproducing using the instructions you just gave, but could not reproduce it.
I will provide some screenshots in a few hours.
How to reproduce:
Preparation:
Step-by-step reproduction:
There might be a more general reproduction, however this is what I tried at the moment.
The issue is that you rejected my idea to use a separate component (ContactControl) there. That would have prevented that.
Because we had a case here of not reinitializing the value correctly.
@ -192,0 +194,4 @@settingsButton.setAlignment(Pos.BOTTOM_RIGHT);HBox.setHgrow(spaceBetweenUserAndSettingsButton, Priority.ALWAYS);generateOwnStatusControl();System.out.println(ownContactControl.getChildren());This seems to be a leftover from development.
@ -699,6 +719,13 @@ public final class ChatScene implements EventListener, Restorable {attachmentView.setVisible(visible);}private void generateOwnStatusControl() {You could annotate this as an event handler directly.
@ -63,1 +62,3 @@statusComboBox.setOnAction(e -> {});statusComboBox.setOnAction(e -> {final var status = statusComboBox.getValue();if (status == null) return;How is this possible?
Artifact from when I called it using the selectionModel before stumbling upon this method.
Yes, agreed, their Javadoc doesn't mention anything about it,so I'll remove it.
Yeah, this looks really nice now 👍
Looks good overall despite some minor complains I have besides that good job!
@ -50,3 +35,1 @@AlertHelper.confirmAction(alert, () -> {EnvoyLog.getLogger(ShutdownHelper.class).log(Level.INFO, "A logout was requested");public static void exit(boolean force) {Why exactly do you want the option of force closing the application if you hardcoded it to false when you are calling the method?
Because otherwise we encounter a problem in
StatusTrayIconas I've noticed:The previous method only checked whether
settings.isHideOnClose()andStatusTryIcon.isSupported()aretrue. If a StatusTrayIcon is shown, both are automatically true. Hence, nothing would happen when you click on Exit in the TrayIcon (except that the stage would be minimized, which is not what is wanted here). That's the reason why this extra method was needed.OK than it is clear
@ -702,0 +720,4 @@private void generateOwnStatusControl() {final var ownUserControl = new ContactControl(localDB.getUser());ownUserControl.setAlignment(Pos.CENTER_LEFT);if (ownContactControl.getChildren().get(0) instanceof ContactControl) ownContactControl.getChildren().set(0, ownUserControl);I do not see the point of doing this as you can just check if it is null if I understand that correctly. If not please correct and explane the exact purpose to me.
As you can see a few lines above, this method is annotated with an Event: It gets called every time the user changes his own status.
Hence I always have to replace it then.
And for the first part: I cannot do that because initially this component is no part of the HBox (you remember, the thing with importing the by now outdated jar into the SceneBuilder...). To avoid that, it gets dynamically added.
But thinking about it, it may be possible, however I do not know if it'll work as bug-free as this implementation: As soon as you initialize this variable somewhere else, you might encounter a bug that duplicates it.
What if, instead of regenerating the whole control, we would just change the displayed information in the event handler?
It could be possible if we make some changes to the underlying
ContactControl.The question however is: Should it be done?
Oh, and also: there is a difference between ownUserControl and ownContactControl.
Better?
Yes better
@ -123,3 +120,3 @@String token;if (user.getAuthToken() != null && user.getAuthTokenExpiration().isAfter(Instant.now())) {if (user.getAuthToken() != null && user.getAuthTokenExpiration().isAfter(Instant.now()))Are you sure all of the code in the body of this if statement gets executed if you remove the curly brackets?
Was my formatter, so I'd guess so. Otherwise blame Eclipse.
Same for below.
And yes, it's only one statement, so why shouldn't it?
Because of the comment but I guess it does not count
@ -145,2 +141,3 @@for (final var msg : pendingMessages) {final var msgCommon = msg.toCommon();if (msg.getCreationDate().isAfter(credentials.getLastSync())) {if (msg.getCreationDate().isAfter(credentials.getLastSync()))same as above
Still only one statement.
@ -199,3 +195,3 @@// Sending group message status changesif (gmsg.getStatus() == SENT && gmsg.getLastStatusChangeDate().isAfter(gmsg.getCreationDate())|| gmsg.getStatus() == RECEIVED && gmsg.getLastStatusChangeDate().isAfter(gmsg.getReceivedDate())) {|| gmsg.getStatus() == RECEIVED && gmsg.getLastStatusChangeDate().isAfter(gmsg.getReceivedDate()))same as above
Still only one statement
Oh and I noticed that the settigs button is not sticking to the right end of the new OwnContactControl so please make sure you add a region in the middle and setting the hgrow of this component to
Priority.ALWAYSto ensue proper allignment.Oh and I noticed that the settigs button is not sticking to the right end of the new OwnContactControl so please make sure you add a region in the middle and setting the hgrow of this component to
Priority.ALWAYSto ensue proper allignment.(Sorry messes up the converation a little bit with the top comment beeing a comment that can't be deleted instead of beeing another request changes.)
@ -192,0 +192,4 @@// Set the design of the box in the upper-left cornersettingsButton.setAlignment(Pos.BOTTOM_RIGHT);HBox.setHgrow(spaceBetweenUserAndSettingsButton, Priority.ALWAYS);@DieGurke The region you requested is already here, but for some strange reason it doesn't work as expected.
Any idea why?
Feel free to take on that challenge, because I've tried it for about twenty minutes and could not get it to work.
I could't fix it neither. Preferably you open an issue for that.