Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32564 --- This review has been submitted with commit c8264896312e244e028be291dc390363d3aad843 by Aurélien Gâteau to branch master. - Commit Hook On May 15, 2013, 9:45 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 15, 2013, 9:45 a.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.h 80a9980e0af63185e032ca759800bb9fb32b1557 kdeui/widgets/kmessagewidget.cpp 724da0fa60a7b236d61685257e011fc49a30c1ff Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 15, 2013, 1:54 p.m.) Status -- This change has been marked as submitted. Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.h 80a9980e0af63185e032ca759800bb9fb32b1557 kdeui/widgets/kmessagewidget.cpp 724da0fa60a7b236d61685257e011fc49a30c1ff Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 2:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Dominik Haumann wrote: Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 Dominik Haumann wrote: Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Not really: We just had once someone on kwrite-devel (iirc) complaining about the colors. But if you ask me, the colors are fine for the use cases right now. Aurélien Gâteau wrote: I don't like watermarks, they look too noisy. Having thought about this patch more, I would like to keep the ability to set the icon. What about removing all icons by default but adding an icon property? This would fix the confusion for KMessageWidget::Error and still saves space while giving the ability to set icons more adapted to the widget message when there is a need for it. Kai Uwe Broulik wrote: I think we also need a neutral message type that uses the window/button background color (as a gradient, of course) as widget background for displaying things that aren't really an information but rather progress such as the Kate document is still loading message. And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. Thomas Lübking wrote: as a gradient, of course http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKStyle.html#a679a9290cff89d0f2e330cd448216d2d Reg. the icon not prominent enough that's easily solved by, as Kai suggested, using a sensible icon in the first place (eg. one that does not look like a close button, to start with) and then let it occupy the entire left or right half of the widget, resp. cap that at (dpi adjusted) 128px. Then *partially* overlay it with a translucent bg colored rect and put the text in there. The imporant aspect of all those actions should be to make it look like not-a-button. If you can't imagine what i've in mind, i'll sketch a mock this evening. Eli MacKenzie wrote: This example may be relevant, even though its using the warning mode: http://wstaw.org/m/2013/03/27/plasma-desktopTm3877.png Perhaps the confusion is due to autoraise being enabled if there is only the close button? Regards, Eli Dominik Haumann wrote: And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. This makes a lot of sense to me. Aurélien, what's your opinion on this? Personally, I was never much troubled by the icon itself, but I think it could be useful to hide it, and customize it. Yes, that's what I meant with:
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 14, 2013, 4:31 p.m.) Review request for Dolphin, Kate and kdelibs. Changes --- Add back the icon, but hide it by default and introduce an icon property to let users define it. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs (updated) - kdeui/widgets/kmessagewidget.h 80a9980e0af63185e032ca759800bb9fb32b1557 kdeui/widgets/kmessagewidget.cpp 724da0fa60a7b236d61685257e011fc49a30c1ff Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32512 --- Ship it! Given the posted screenshot, setting a unique icon is certainly a plus, since the colored background already serves as incident indicator (like a very heavily blurred watermark ;-) but this way actually even diminishes the related icon (the yellow triangle is rather lost on the yellow background and a disk or folder would work much better and provide additional information) kdeui/widgets/kmessagewidget.cpp http://git.reviewboard.kde.org/r/110327/#comment24180 Swap in case this is called on a shown dialog? I'm at hand not sure how smart Qt is on activating the layout + if the icon needs to be loaded and there was one and there's a longer delay, you'd briefly see the old one (- flicker) - at best shadowed by the compositor. - Thomas Lübking On May 14, 2013, 2:31 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 14, 2013, 2:31 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.h 80a9980e0af63185e032ca759800bb9fb32b1557 kdeui/widgets/kmessagewidget.cpp 724da0fa60a7b236d61685257e011fc49a30c1ff Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 12:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Dominik Haumann wrote: Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 Dominik Haumann wrote: Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Not really: We just had once someone on kwrite-devel (iirc) complaining about the colors. But if you ask me, the colors are fine for the use cases right now. Aurélien Gâteau wrote: I don't like watermarks, they look too noisy. Having thought about this patch more, I would like to keep the ability to set the icon. What about removing all icons by default but adding an icon property? This would fix the confusion for KMessageWidget::Error and still saves space while giving the ability to set icons more adapted to the widget message when there is a need for it. I think we also need a neutral message type that uses the window/button background color (as a gradient, of course) as widget background for displaying things that aren't really an information but rather progress such as the Kate document is still loading message. And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 8:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 8:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 12:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Dominik Haumann wrote: Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 Dominik Haumann wrote: Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Not really: We just had once someone on kwrite-devel (iirc) complaining about the colors. But if you ask me, the colors are fine for the use cases right now. Aurélien Gâteau wrote: I don't like watermarks, they look too noisy. Having thought about this patch more, I would like to keep the ability to set the icon. What about removing all icons by default but adding an icon property? This would fix the confusion for KMessageWidget::Error and still saves space while giving the ability to set icons more adapted to the widget message when there is a need for it. Kai Uwe Broulik wrote: I think we also need a neutral message type that uses the window/button background color (as a gradient, of course) as widget background for displaying things that aren't really an information but rather progress such as the Kate document is still loading message. And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. as a gradient, of course http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKStyle.html#a679a9290cff89d0f2e330cd448216d2d Reg. the icon not prominent enough that's easily solved by, as Kai suggested, using a sensible icon in the first place (eg. one that does not look like a close button, to start with) and then let it occupy the entire left or right half of the widget, resp. cap that at (dpi adjusted) 128px. Then *partially* overlay it with a translucent bg colored rect and put the text in there. The imporant aspect of all those actions should be to make it look like not-a-button. If you can't imagine what i've in mind, i'll sketch a mock this evening. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 8:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 8:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 8:50 a.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Dominik Haumann wrote: Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 Dominik Haumann wrote: Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Not really: We just had once someone on kwrite-devel (iirc) complaining about the colors. But if you ask me, the colors are fine for the use cases right now. Aurélien Gâteau wrote: I don't like watermarks, they look too noisy. Having thought about this patch more, I would like to keep the ability to set the icon. What about removing all icons by default but adding an icon property? This would fix the confusion for KMessageWidget::Error and still saves space while giving the ability to set icons more adapted to the widget message when there is a need for it. Kai Uwe Broulik wrote: I think we also need a neutral message type that uses the window/button background color (as a gradient, of course) as widget background for displaying things that aren't really an information but rather progress such as the Kate document is still loading message. And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. Thomas Lübking wrote: as a gradient, of course http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKStyle.html#a679a9290cff89d0f2e330cd448216d2d Reg. the icon not prominent enough that's easily solved by, as Kai suggested, using a sensible icon in the first place (eg. one that does not look like a close button, to start with) and then let it occupy the entire left or right half of the widget, resp. cap that at (dpi adjusted) 128px. Then *partially* overlay it with a translucent bg colored rect and put the text in there. The imporant aspect of all those actions should be to make it look like not-a-button. If you can't imagine what i've in mind, i'll sketch a mock this evening. This example may be relevant, even though its using the warning mode: http://wstaw.org/m/2013/03/27/plasma-desktopTm3877.png Perhaps the confusion is due to autoraise being enabled if there is only the close button? Regards, Eli - Eli --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 4:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 4:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description ---
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 12:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Dominik Haumann wrote: Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 Dominik Haumann wrote: Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Not really: We just had once someone on kwrite-devel (iirc) complaining about the colors. But if you ask me, the colors are fine for the use cases right now. Aurélien Gâteau wrote: I don't like watermarks, they look too noisy. Having thought about this patch more, I would like to keep the ability to set the icon. What about removing all icons by default but adding an icon property? This would fix the confusion for KMessageWidget::Error and still saves space while giving the ability to set icons more adapted to the widget message when there is a need for it. Kai Uwe Broulik wrote: I think we also need a neutral message type that uses the window/button background color (as a gradient, of course) as widget background for displaying things that aren't really an information but rather progress such as the Kate document is still loading message. And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. Thomas Lübking wrote: as a gradient, of course http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKStyle.html#a679a9290cff89d0f2e330cd448216d2d Reg. the icon not prominent enough that's easily solved by, as Kai suggested, using a sensible icon in the first place (eg. one that does not look like a close button, to start with) and then let it occupy the entire left or right half of the widget, resp. cap that at (dpi adjusted) 128px. Then *partially* overlay it with a translucent bg colored rect and put the text in there. The imporant aspect of all those actions should be to make it look like not-a-button. If you can't imagine what i've in mind, i'll sketch a mock this evening. Eli MacKenzie wrote: This example may be relevant, even though its using the warning mode: http://wstaw.org/m/2013/03/27/plasma-desktopTm3877.png Perhaps the confusion is due to autoraise being enabled if there is only the close button? Regards, Eli And for Kate I could think of many cases where, instead of using the generic warning icon or no icon at all, using a more specific one could improve first-sight-recognizability such as 'object-locked' for when the file has been opened read-only, or 'character-set' when there's encoding issues. This makes a lot of sense to me. Aurélien, what's your opinion on this? Personally, I was never much troubled by the icon itself, but I think it could be useful to hide it, and customize it. - Dominik --- This is an
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. - Dominik Haumann On May 6, 2013, 8:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 8:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 2:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 10:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 10:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 12:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? What about making the icon a watermark? - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 8:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 8:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 12:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 - Dominik --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 8:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 8:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 7, 2013, 12:50 p.m., Dominik Haumann wrote: The patch itself is fine and most likely does not introduce regressions in terms of misbehavior. Still, is never showing an icon the way to go? Another way to work around this by default would be an additional function called KMessageWidget::setShowIcon(bool). In fact, I've recently been thinking that being able to set custom icons also may be a good idea, along with setting a custom color for the message widget. Maybe one could ex extend MessageType, i.e.: setMessageType(Custom). Along with setIcon() and setPalette() or similar. Then, the developer would have more control over the colors showing up in the Kate views. A disadvantage of this is, however, that this leads to inconsistent ui's. It this is needed, this patch works against this, though. Aurélien Gâteau wrote: It could be nice to be able to use a custom icon which would be adapted to the context of the message. But I think the widget still works without it for now, and getting rid of it has its advantages (fixing confusion, saving space). An alternative to this fix would be to replace the icon with something less button-like. The only icon I think would work here is the dialog-warning one, which is already used with KMessageWidget::Warning type. Any other idea? Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Thomas Lübking wrote: What about making the icon a watermark? Dominik Haumann wrote: Using icons as watermark was already discussed years ago. I didn't read the entire thread, but on the following link you can find a url to an image showing a watermark icon in the background. The thread is very long, and it the end nothing came out of it apparently: http://lists.kde.org/?l=kde-core-develm=120204190217471w=2 Exposing access to the palette would indeed be dangerous for consistency. Can you explain in which situation you would want control over the colors? Not really: We just had once someone on kwrite-devel (iirc) complaining about the colors. But if you ask me, the colors are fine for the use cases right now. - Dominik --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32194 --- On May 6, 2013, 8:59 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 8:59 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32146 --- I think your patch will fix the bug 304775. ;) Bug 304775 - Multiple red 'X' icons/buttons are shown in the KMessageWidget below the location bar when errors occur - Emmanuel Pescosta On May 6, 2013, 3:53 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 3:53 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32149 --- Looks very reasonable from my point of view, thanks! And yes, https://bugs.kde.org/show_bug.cgi?id=304775 can be closed when this is pushed. Thanks for the hint, Emmanuel! kdeui/widgets/kmessagewidget.cpp http://git.reviewboard.kde.org/r/110327/#comment23939 I guess you can remove the variable 'icon' from this function now, right? - Frank Reininghaus On May 6, 2013, 3:53 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 3:53 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32154 --- Semi-OT (sorry) - what makes this thing appear on top of things (below the toolbar) - and why? In a NW gravity world, this means the UI is shifted downwards under the users fingers (no matter where you are, the poaint where your mouse was will be ~128px lower as soon as this appears - untriggered) a) Is moving it to the bottom in the cards? b) Is it in the cards for 4.11? - Thomas Lübking On May 6, 2013, 3:53 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 3:53 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 6, 2013, 9:32 p.m., Thomas Lübking wrote: Semi-OT (sorry) - what makes this thing appear on top of things (below the toolbar) - and why? In a NW gravity world, this means the UI is shifted downwards under the users fingers (no matter where you are, the poaint where your mouse was will be ~128px lower as soon as this appears - untriggered) a) Is moving it to the bottom in the cards? b) Is it in the cards for 4.11? KMessageWidget is used like a regular widget: it appears wherever the application developer decides to place it. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32154 --- On May 6, 2013, 5:53 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 5:53 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
On May 6, 2013, 8:45 p.m., Frank Reininghaus wrote: kdeui/widgets/kmessagewidget.cpp, line 253 http://git.reviewboard.kde.org/r/110327/diff/1/?file=142371#file142371line253 I guess you can remove the variable 'icon' from this function now, right? Indeed. Removing it. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/#review32149 --- On May 6, 2013, 5:53 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 5:53 p.m.) Review request for Dolphin, Kate and kdelibs. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
Re: Review Request 110327: KMessageWidget: Remove decoration icon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110327/ --- (Updated May 6, 2013, 10:59 p.m.) Review request for Dolphin, Kate and kdelibs. Changes --- Remove useless KIcon. Description --- This avoids confusion between the decoration icon and the close button, especially when type is KMessageWidget::Error. This happens for example with Dolphin when an error happens while trying to connect to an non available host. This change also has the nice side-effect of leaving more space for the widget text. Diffs (updated) - kdeui/widgets/kmessagewidget.cpp a52316726233a22929ce8ad3aff60b9ccc5f9b85 Diff: http://git.reviewboard.kde.org/r/110327/diff/ Testing --- Tested with kmessagewidgetdemo, Dolphin and Kate. Thanks, Aurélien Gâteau
