-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update to QgsMessageBar and duplicateLayers()
- Move project macros message into project open method (as app property, partially showed behind later messages) - Support for multi-line messages that also wrap at with canvas window width - Update text stylesheets to handle all text styling - Show count of remaining queued messages - Add popup menu to Close button with action to optionally close all messages at once - Add slot to clear all widgets, called on project close - Update QgisApp::duplicateLayers() to use QgsMessageBar instead of popup dialogs
- ltr-3_40
- ltr-3_34
- ltr-3_28
- ltr-3_22
- ltr-3_16
- ltr-3_10
- ltr-3_4
- ltr-2_18
- ltr-2_14
- ltr-2_8
- final-3_40_2
- final-3_40_1
- final-3_40_0
- final-3_38_3
- final-3_38_2
- final-3_38_1
- final-3_38_0
- final-3_36_3
- final-3_36_2
- final-3_36_1
- final-3_36_0
- final-3_34_14
- final-3_34_13
- final-3_34_12
- final-3_34_11
- final-3_34_10
- final-3_34_9
- final-3_34_8
- final-3_34_7
- final-3_34_6
- final-3_34_5
- final-3_34_4
- final-3_34_3
- final-3_34_2
- final-3_34_1
- final-3_34_0
- final-3_32_3
- final-3_32_2
- final-3_32_1
- final-3_32_0
- final-3_30_3
- final-3_30_2
- final-3_30_1
- final-3_30_0
- final-3_28_15
- final-3_28_14
- final-3_28_13
- final-3_28_12
- final-3_28_11
- final-3_28_10
- final-3_28_9
- final-3_28_8
- final-3_28_7
- final-3_28_6
- final-3_28_5
- final-3_28_4
- final-3_28_3
- final-3_28_2
- final-3_28_1
- final-3_28_0
- final-3_26_3
- final-3_26_2
- final-3_26_1
- final-3_26_0
- final-3_24_3
- final-3_24_2
- final-3_24_1
- final-3_24_0
- final-3_22_16
- final-3_22_15
- final-3_22_14
- final-3_22_13
- final-3_22_12
- final-3_22_11
- final-3_22_10
- final-3_22_9
- final-3_22_8
- final-3_22_7
- final-3_22_6
- final-3_22_5
- final-3_22_4
- final-3_22_3
- final-3_22_2
- final-3_22_1
- final-3_22_0
- final-3_20_3
- final-3_20_2
- final-3_20_1
- final-3_20_0
- final-3_18_3
- final-3_18_2
- final-3_18_1
- final-3_18_0
- final-3_16_16
- final-3_16_15
- final-3_16_14
- final-3_16_13
- final-3_16_12
- final-3_16_11
- final-3_16_10
- final-3_16_9
- final-3_16_8
- final-3_16_7
- final-3_16_6
- final-3_16_5
- final-3_16_4
- final-3_16_3
- final-3_16_2
- final-3_16_1
- final-3_16_0
- final-3_14_16
- final-3_14_15
- final-3_14_1
- final-3_14_0
- final-3_12_3
- final-3_12_2
- final-3_12_1
- final-3_12_0
- final-3_10_14
- final-3_10_13
- final-3_10_12
- final-3_10_11
- final-3_10_10
- final-3_10_9
- final-3_10_8
- final-3_10_7
- final-3_10_6
- final-3_10_5
- final-3_10_4
- final-3_10_3
- final-3_10_2
- final-3_10_1
- final-3_10_0
- final-3_8_3
- final-3_8_2
- final-3_8_1
- final-3_8_0
- final-3_6_3
- final-3_6_2
- final-3_6_1
- final-3_6_0
- final-3_4_15
- final-3_4_14
- final-3_4_13
- final-3_4_12
- final-3_4_11
- final-3_4_10
- final-3_4_9
- final-3_4_8
- final-3_4_7
- final-3_4_6
- final-3_4_5
- final-3_4_4
- final-3_4_3
- final-3_4_2
- final-3_4_1
- final-3_4_0
- final-3_2_3
- final-3_2_2
- final-3_2_1
- final-3_2_0
- final-3_0_3
- final-3_0_2
- final-3_0_1
- final-3_0_0
- final-2_18_28
- final-2_18_27
- final-2_18_26
- final-2_18_25
- final-2_18_24
- final-2_18_23
- final-2_18_22
- final-2_18_21
- final-2_18_20
- final-2_18_19
- final-2_18_18
- final-2_18_17
- final-2_18_16
- final-2_18_15
- final-2_18_14
- final-2_18_13
- final-2_18_12
- final-2_18_11
- final-2_18_10
- final-2_18_9
- final-2_18_8
- final-2_18_7
- final-2_18_6
- final-2_18_5
- final-2_18_4
- final-2_18_3
- final-2_18_2
- final-2_18_1
- final-2_18_0
- final-2_16_3
- final-2_16_2
- final-2_16_1
- final-2_16_0
- final-2_14_22
- final-2_14_21
- final-2_14_20
- final-2_14_19
- final-2_14_18
- final-2_14_17
- final-2_14_16
- final-2_14_15
- final-2_14_14
- final-2_14_13
- final-2_14_12
- final-2_14_11
- final-2_14_10
- final-2_14_9
- final-2_14_8
- final-2_14_7
- final-2_14_6
- final-2_14_5
- final-2_14_4
- final-2_14_3
- final-2_14_2
- final-2_14_1
- final-2_14_0
- final-2_12_3
- final-2_12_2
- final-2_12_1
- final-2_12_0
- final-2_10_1
- final-2_10_0
- final-2_8_9
- final-2_8_8
- final-2_8_7
- final-2_8_6
- final-2_8_5
- final-2_8_4
- final-2_8_3
- final-2_8_2
- final-2_8_1
- final-2_8_0
- final-2_6_1
- final-2_6_0
- final-2_4_0
- final-2_2_0
- final-2_0_1
- final-2_0_0
- archive/master_2
- Before-merge-new_vector_api
Showing
3 changed files
with
111 additions
and
34 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4910276
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Larry,
next time you need a review please open a pull request.
I'm writing my opinions inline.
Those changes looks good to me, though I guess that the message bar could be used not only for messages related to projects, so clear the bar when the project is closed couldn't be the right thing to do.
IMO we should add a parameter to define messages context: whether related to the project or to the application instance or maybe something else (to be defined).
Before your change the problem wasn't there (the project macro message was accessible from the project close method), but I agree that your change goes to the right direction.
I really like those changes! I'm building everything, I'll tell you.
I would also add two buttons to switch to the prev/next message in the list.
I would keep the
QLabel { color: ... }
part so labels within any pushed widget (even custom ones) have that text color: the message level changes the background color and this could make dark/bright texts rather invisible on a dark/bright background.If the developer want to override the color of a particular label he can still specify the new one using
QLabel#objectName
as CSS selector.I don't like to add a message to the bar for each layer that fails, ok it's not a messagebox, but anyway the user has to close them.
BTW this is not related to the review of the code, it's just my opinion ;)
4910276
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understanding your reasoning here, but if the core commit is non-disruptive, moves the code forward in a beneficial manner, fixes an issue and is heavily tested, I don't see the difference (since we have github's commenting system) other than having to wait for all discussion to end before I could continue with using the commit in another dev branch (which I am currently doing).
If I am unsure about the implementation, think the code may disrupt or break something else I do not fully understand, or the changes would affect or is part of code someone else is currently working on, I think a pull request or sharing a dev branch off of my forked repo would then be in order.
What would a message be that would need to persist between project openings? Wouldn't all pre-project opening messages (like ones that might occur during app launch) be handled on the first empty project, or in the log? Also, couldn't any app-level messages just be generated again (if needed) on project open? Not sure I'm following the use case here for not clearing the bar on project close.
Yes. That sounds good. Kind of like how syslog messages are keyed off of the 'facility' context, except the message bar is more of a temporal notification system, than a log. Not sure the best way to show that context in the bar. Maybe a label just before the message icon that reads: App, Project, or whatever? Or maybe an icon?
I tried a version of prev/next, but found the implementation of CurrentItem property (which is separate from mList) problematic for keeping track of current message number (e.g. for 'message 3 of 5' type counter ). Was going to try again after this commit.
Makes sense. I'll make and test the change.
I could look at batching the message lines into grouped messages, e.g. grouping lists with a max line count of 5, since the message lines should never really need to wrap. Thanks.
4910276
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I agree.
I've no use cases right now, it was just an idea. But I guess that defining a context for messages would be a good thing.
Anyway it's something can be added in the future.
BTW after implementing the duplicateLayer also for the other providers it'll fail very few times.