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