> 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.
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 > >