Review Request 110327: KMessageWidget: Remove decoration icon

[Dominik Haumann]

> 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-devel&m=120204190217471&w=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 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130510/30e74b23/attachment.htm>