Yad notes

johnraff · 2016-01-07 06:36:47

Damo's rewritten a lot of scripts to use yad (now in the BL repo) instead of zenity, and to keep things tidy I thought I'd better switch too so we don't have to have both apps installed. In the process of rewriting a simple notification window I ran into a couple of things - now worked around - and thought I'd drop it here for future reference. Feel free to add your own findings/hints/etc. (Especially @Damo!)

While Damo and I were playing around with icons , images and yad we discovered a couple of things:
*) Full image paths always work, but --image= then displays the image at full size, not icon size.
*) Short icon names (like gtk-ok or firefox) also work if the image is in an icon theme or in /usr/share/pixmaps, but if it's in an icon theme --image resizes it, if it's in pixmaps it's displayed full size. ( --window-icon always resizes images icon-size.)

For these reasons we made an icon /usr/share/icons/hicolor/scalable/places/distributor-logo-bunsenlabs.svg and a symlink /usr/share/pixmaps/bunsenlabs-flame.svg pointing to it. Developers can use distributor-logo-bunsenlabs for icon-size or bunsenlabs-flame for full-size. (That's the idea anyway, see below.)

The initial code (from bl-lock):

zenity --info --title="Lock screen info:" --text="Lock screen has detected you are running a live session.\nThe username needed to unlock the screen is \"user\" and the password is \"live\".\nThis notice will only be displayed once per live session."

This was changed (borrowing from Damo's code) to:

yad --image="distributor-logo-bunsenlabs" --center --borders=20 --window-icon=distributor-logo-bunsenlabs --button=gtk-ok --on-top --title='Lock screen info:' --text="Lock screen has detected you are running a live session.\nThe username needed to unlock the screen is \"user\" and the password is \"live\".\nThis notice will only be displayed once per live session."

First issue: the --image could have been gtk-dialog-info for a match with with the zenity dialogue but I wanted to try our new BL icon distributor-logo-bunsenlabs.
Unfortunately:

Ubuntu!! If the image was renamed to eg distributor-bunsenlabs or pretty much anything else it worked OK. Among all the distributor-logo-something icons there's one called distributor-logo.svg, which is a copy of distributor-logo-ubuntu.svg (and .png), and that was taking precedence over ours! It took quite some time tweaking and googling, but eventually I found this post, and this page. Apparently it's not a bug it's built into GTK and yad just uses it. If an icon with parts-separated-by-dashes isn't found, instead of going down to inherited themes, and ultimately to hicolor as the freedesktop icon specification demands, it just chops off the last part of the name and tries what's left! wtf?

Finally resorted to adding a symlink named 'bunsenlabs.svg' pointing to the real icon, so devs can get a BL icon with --image="bunsenlabs".
Another workaround would be to add the icon to our Faenza-Bunsen icon theme, but if users switched icon theme it would be lost.
Another workaround would be to go back to --image="gtk-dialog-info" of course.
(btw the --window-icon suffered from none of this weirdness.)

Second issue: there's an old zenity bug where a long text would cause the bottom of the window to go way down, as if it was allowing enough height for the window when squeezed into its minimum width. (eg here) It looked as if yad was inheriting this bug. Actually I cheated with the last screenshot - it should have been like this:

This one took a long time. Eventually I found a post (sorry forgot to keep the link ) with a workaround: add

--fixed

to the options.
"--fixed
Make window fixed width and height."
Whatever that means. Anyway it seems to do the job.

I also tried compiling yad 0.33.0 from Sourceforge. After a single patch (had to add src/html.c to po/POTFILES.in but I don't know if it had been left out for a good reason...) it compiled, and also seemed to work free of that height bug. If anyone would like to play with it there's an amd64 version here. (Text wrapping seems to be different.)

---------------------------

btw @damo there seems to be a certain amout of evidence that the yad developer was thinking of icon-sized images for --image (like zenity's):
https://groups.google.com/d/msg/yad-com … hhxnAoAQAJ
"pictures sets by --image option have a size of GTK_ICON_SIZE_DIALOG by default it is a 48x48 px"
and
https://code.google.com/p/yad/issues/detail?id=8
"stock images specified in --image use GTK_ICON_SIZE_DIALOG and it's size depends on current gtk theme settings"

Last edited by johnraff (2016-01-07 07:06:12)

damo · 2016-01-07 10:50:52

Thanks for your explorations

Using `--image="distributor-logo-bunsenlabs"` I get the Debian logo, even though `distributor-logo.svg` is the ubuntu logo! (scrot is "current focus" btw)

yad --image="distributor-logo-bunsenlabs" --center --fixed  --borders=20 --window-icon=distributor-logo-bunsenlabs --button=gtk-ok --on-top --title='Lock screen info:' --text="Lock screen has detected you are running a live session. \
\nThe username needed to unlock the screen is \"user\" and the password is \"live\". \
\nThis notice will only be displayed once per live session."

Making a symlink, and using `--image="bunsenlabs"` as you describe, works properly:

ln -s /usr/share/icons/hicolor/scalable/places/distributor-logo-bunsenlabs.svg /usr/share/icons/hicolor/scalable/places/bunsenlabs.svg

hhh · 2016-01-07 15:11:24

^In this dialog example, why is there a background on the flame? Shouldn't that be transparent? And if so, could we have 2 logos corresponding to Bunsen light and Dark themes?

damo · 2016-01-07 15:18:35

hhh wrote:

^In this dialog example, why is there a background on the flame? Shouldn't that be transparent? And if so, could we have 2 logos corresponding to Bunsen light and Dark themes?

The reason is that only one logo is needed for any theme. I agree that it would look better if there was a transparent background, which is OK for Bunsen themes which we maintain. It would cause problems with other themes though. We decided that this was the simplest solution for now - maybe it can be improved for a future release

A single coloured logo, with alpha, could work though

hhh · 2016-01-07 15:45:06

OK, food for thought. Off to work, ciao for now!

johnraff · 2016-01-08 01:46:19

damo wrote:

Using `--image="distributor-logo-bunsenlabs"` I get the Debian logo, even though `distributor-logo.svg` is the ubuntu logo!

Weirder still! Is there no other distributor-logo.* higher up the chain somewhere? Is there even a distributor.* with the Debian swirl?? Why can't GTK just follow the freedesktop rules anyway?

hhh · 2016-01-08 01:50:31

johnraff wrote:

Why can't GTK just follow the freedesktop rules anyway?

#firstworldproblems

8o

hhh · 2016-01-08 02:04:04

https://twitter.com/hhhorb/status/685280387950612481

-edit-

https://twitter.com/corenominal/status/ … 1958634496

Just a week and a half ago.

8)

johnraff · 2016-01-11 06:38:07

damo wrote:

hhh wrote:
^In this dialog example, why is there a background on the flame? Shouldn't that be transparent? And if so, could we have 2 logos corresponding to Bunsen light and Dark themes?
The reason is that only one logo is needed for any theme. I agree that it would look better if there was a transparent background, which is OK for Bunsen themes which we maintain. It would cause problems with other themes though. We decided that this was the simplest solution for now - maybe it can be improved for a future release
A single coloured logo, with alpha, could work though

Agree the current default icon (in /usr/share/icons/hicolor) looks a bit spartan. It's a fallback, in case there's no "distributor-logo-bunsenlabs" in the current icon theme - which there isn't at the moment. We can add such icons to any themes we supply, but if the user switches to a theme with no BL icon (shock!) they'll get the fallback.

If one of our graphics geniuses had the time to make a set of pretty icons, we could anyway put them in the dark and light variants of bunsen-faenza-icon-theme.

johnraff · 2016-01-11 06:43:51

Two questions for @damo:

I notice you use both decorated and undecorated dialog windows. I'd like to maintain style consistency with your stuff in my code - what are your criteria for choosing one or the other?

In your scripts you use '--button=OK:0' but '--button=gtk-cancel:1' and the other gtk-things for other buttons. Why not also use '--button=gtk-ok:0' for consistency?

damo · 2016-01-11 11:23:04

^ The undecorated ones are for pop-up type boxes for info or input, which will be dismissed quickly. I think a decorated window to ask for an OK? looks very odd. Decorated windows are ones I've judged the user might want to keep around for a while, or move about the desktop.

The `gtk-ok` thing is an aesthetic choice. I personally prefer flat, minimal buttons generally, and with some themes the OK button icon is quite fugly and unecessary imo. I guess there are some inconsistencies in my choices, but they are what they are

I'm not precious about the buttons, so go with what works best. Decorated/undecorated depending on function is more important I think.

johnraff · 2016-01-12 03:06:25

^Thanks. Actually I agree about gtk-ok: that tickmark is really overdone. I was just thinking about consistency with the other buttons. The only possible advantage with the gtk-* things might be that they are automatically translated in other locales. I haven't tested that though (it does happen with the gtk.STOCK_CANCEL button in bl-exit), and will stick, like you, with a plain OK for now.

Could you give me an example or two of the kind of window that should be decorated?

tknomanzr · 2016-01-12 05:18:56

I can give you an example the other direction. Let's say you have a file dialog and want to pop up a confirm on file deletion, that would need to be an undecorated window, because it is a child window of another window.

Think of it like this, the dialog I posted in the other thread you started is actually closer to an application than a dialog (it is really just a graphical wrapper around a cli command) but we could consider it an application. Thus, it should look and behave like an application, with window decorations (minimize, close, ability to drag it around etc.) Simple confirmation windows, especially when a child window to an application should usually be undecorated. Also,, in the instance where you would absolutely require input (hard to name one off the top of my head), undecorating the window makes it much tougher to just cancel out of the dialog.

damo · 2016-01-12 12:06:19

Example dialogs:

ututo · 2016-01-12 21:12:44

I'll leave this here...

svg files: blue, dark, light, grey

Last edited by ututo (2016-01-12 23:20:14)

tknomanzr · 2016-01-12 22:26:42

Oh those are nice. You keep improving them

damo · 2016-01-12 22:38:24

^ He has the touch doesn't he?

Great work!

johnraff · 2016-01-15 06:21:28

@ututo those are really nice!

@damo thanks - I think I've got it now. Most of my dialogs will be undecorated.

Sector11 · 2016-01-15 14:02:43

ututo wrote:

I'll leave this here...

And of course I took them 'here'
Nice stuff, thank you.

johnraff · 2016-01-19 08:13:40

I was wondering about putting something like this in bunsen-common's bl-include.cfg
It would make it easier to keep some uniformity of style between different scripts' popups and possibly save developers some typing:

yad_common_args=('--window-icon=distributor-logo-bunsenlabs' '--center' '--borders=20')
yad_popup_args=('--undecorated' '--fixed' '--on-top')
yad_question(){
    yad --text="$1" --button=Yes:0 --button=No:1 "${yad_common_args[@]}" "${yad_popup_args[@]}"
    }
yad_info(){
    yad --text="$1" --button=OK "${yad_common_args[@]}" "${yad_popup_args[@]}"
    }
yad_error(){
    yad --text="$1" --button=OK "${yad_common_args[@]}" "${yad_popup_args[@]}" --image=dialog-error
    }

Devs could source bl-include.cfg (it often is anyway) and add something like

yad_common_args+=('--title=Dropbox Installation' '--image=dropbox')

at the top of a particular script before running the functions like

yad_info 'here's my message'

(The --image=... at the end of yad_error overrules what might have already been set in yad_common_args. It feels hacky but seems to work.)

Would something like that be any use?

#1 2016-01-07 06:36:47

Yad notes

#2 2016-01-07 10:50:52

Re: Yad notes

#3 2016-01-07 15:11:24

Re: Yad notes

#4 2016-01-07 15:18:35

Re: Yad notes

#5 2016-01-07 15:45:06

Re: Yad notes

#6 2016-01-08 01:46:19

Re: Yad notes

#7 2016-01-08 01:50:31

Re: Yad notes

#8 2016-01-08 02:04:04

Re: Yad notes

#9 2016-01-11 06:38:07

Re: Yad notes

#10 2016-01-11 06:43:51

Re: Yad notes

#11 2016-01-11 11:23:04

Re: Yad notes

#12 2016-01-12 03:06:25

Re: Yad notes

#13 2016-01-12 05:18:56

Re: Yad notes

#14 2016-01-12 12:06:19

Re: Yad notes

#15 2016-01-12 21:12:44

Re: Yad notes

#16 2016-01-12 22:26:42

Re: Yad notes

#17 2016-01-12 22:38:24

Re: Yad notes

#18 2016-01-15 06:21:28

Re: Yad notes

#19 2016-01-15 14:02:43

Re: Yad notes

#20 2016-01-19 08:13:40

Re: Yad notes

Board footer