Skip to content
Snippets Groups Projects

dialer-button: Simplify the style

Closed Adrien Plazas requested to merge adrien.plazas/libhandy:dialer-button-style into master

Drops the removal of relief, drops the circular style and makes the secondary text smaller to better match the mockups for Calls.

Merge request reports

Pipeline #102 passed

Pipeline passed for 954496a6 on adrien.plazas:dialer-button-style

Approval is optional

Closed by Guido GuntherGuido Gunther 6 years ago (Jun 27, 2018 2:17pm UTC)

Merge details

  • The changes were not merged into master.

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • While I was on the fence regarding the icon this is IMHO not a visual improvement. If calls needs something different please use style classes / css in calls.

  • closed

  • While I was on the fence regarding the icon this is IMHO not a visual improvement. If calls needs something different please use style classes / css in calls. There are other keypad consumers besides calls.

  • Once thing we could do is remove all styling and add more proper style classes so users can adjust it properly.

  • I agree we should drop all styling and allow users to define theirs, but we should also define a sane default and I find the current one very unsane (and I say that while being the one who caused that insanity). What we could do is to allow some tweaks like having a circular property toggling the circular style class to the buttons and a relief property bind to the buttons' relief property. I would still prefer both to be off by default, and the size of the secondary text to be smaller as I did in this MR.

    Using custom CSS classes in Calls is a no-go, it would break custom themes and I don't want any of us to deal with users changing the GTK+ theme.

    I feel you closed that MR a bit too hastily, if you don't mind I would like to ask the point of view of a few other persons, for example @bob.ham, @dorota.czaplejewicz and @tobias.bernard.

    Edited by Adrien Plazas
  • I closed the MR since we don't want to do it this way - not out of disrespect or somesuch. I'm certainly open for using style classes to style things (or better ways if you know of any). There's nothing wrong with custom css in calls since it's currently the only way in GTK+ (I know off) to achieve this. From what I've heard from @tobias.bernard at FOSDEM custom themes are almost impossible to support atm anyway.

  • The current HdyDialer definitely needs to cleaned up a bit, to look more like the mockups. If we're going to be using it in multiple places it probably makes sense to just do it in libhandy, no? I don't expect the requirements to be very different in different places in this regard.

    This is the mockup btw:

    image

    @adrien.plazas can you take a screenshot of what the dialer looks like with this MR vs. before?

  • Which looks not nice as s.th. on the lockscreen or on a T9 keyboard. It's a generic keypad so let's please leave it like that and make things styleble.

  • Is there a dial pad on the lockscreen?

    Or do you mean the PIN unlock input (mockup below)? Does that use the same widget?

    image

    Either way, I think these two things are pretty different, and I'm not sure how much (if any) styling they should share.

  • @tobias.bernard sure there is (I wouldn't have put it into a library for a single use case). See #7 (closed). (and just to be sure: the design is (IMHO) nice for a calls application but we want HdyDialer to be a generic keypad.

  • I prefer the existing appearance of HdyDialer. I agree with Guido here that the real issue here is to make HdyDialer stylable.

    Using custom CSS classes in Calls is a no-go, it would break custom themes and I don't want any of us to deal with users changing the GTK+ theme.

    As I understand CSS classes, there can be many classes applied to an element. If using custom CSS classes breaks custom themes, is this a limitation in GTK+? Would fixing GTK+ be the right solution?

Please register or sign in to reply
Loading