[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Change the look of dialogs created with `x-popup-dialog'

From: Andrey Smirnov
Subject: Re: [PATCH] Change the look of dialogs created with `x-popup-dialog'
Date: Tue, 13 Dec 2011 21:29:58 -0800

On Mon, Dec 12, 2011 at 11:07 PM, Jan Djärv <address@hidden> wrote:
> Hello.
> The change looks good in principle, the current dialog when closing
> Emacs with unsaved changes contains way too many buttons.  How does
> that look on your new implementation?

I, attached before/after screenshot to my initial e-mail, did you see
it? Or do you want to see the results of different code sample?

> Should the radiobuttons be grouped into two columns when the exceed
> some number, say 4 or 6 for example?

I don't know, since the upper limit on the amount of buttons is 9, and
9 radio-buttons in the same row looks fine to my taste, in my opinion
they shouldn't be, but then again that's the matter of personal taste.

> The code has issues however:
> You have removed the title, that is no good.  Several window
> managers show the title in icon bars and other places, so keep the
> title even if you add an icon.

Well, the title is pretty much useless, since it doesn't provide any
information, and I did set the "skip-taskbar-hint" to TRUE, so it
shouldn't appear in the task bar. What icon bars are we talking about?
I used GEdit as some sort of reference implementation of how dialogs of
GNOME editors should look like, and it's dialogs don't have the title.
I don't mind returning it back, it would be  a trivial change after
all, it's just I'm not sure that I see the point.

> The use of default bold indicates screaming to me.

I thought that function was reserved for all caps :)

> It should not be default. A configure option is OK. Ditto font
> size larger. Not sure if this is a good default.

Well, again I tried to emulate GEdit, whose dialogs I find to be
easier on the eyes. And don't you think it would be too minor detail
to be worth a dedicated configure option. Shouldn't we just some sort
of a consensus and just use that settings?

> The use of markup opens up the possibility of having markup in the
> text for the dialog. Also, some characters will not display right,
> as they will be interpretered as masrkup. You need to escape the
> text with g_markup_escape in glib.

Didn't think of that one. Thanks, will fix that.

> Radio buttons should not have any callbacks. When OK is pressed you
> should check what radiobutton is selected and then call the
> callback. Just selecting a radio button should not execute any code
> if there are OK and Cancel buttons present. Also the select
> callback pops down the dialog. This is not something a radiobutton
> should do.

Well, I guess there is more than one way to skin a cat, I'll rewrite
that portion of the code.

> +          g_signal_connect (G_OBJECT (ok), "clicked", deactivate_cb, 0);
> +          g_signal_connect (G_OBJECT (cancel), "clicked", select_cb, 0);
> +          g_signal_connect (G_OBJECT (cancel), "clicked", deactivate_cb, 0);
> Why select_cb on the cancel button?

Because I need to set `menu_item_selection' to 0 otherwise if user
fiddles with radiobuttons and then presses cancel button for the code
in xmenu.c it would be indistinguishable from OK button being pressed.

> -  popup_activated_flag = 0;
> Do not remove this line. It is needed. Why are you removing it?

It is removed because otherwise one wouldn't be able to change
selected radio button more than once, since the first call to
`select_cb' would close the whole dialog.

At least for Gtk this code is redundant anyway, since the same
functionality could, and IMHO should, be achieved by chaining
`select_cb' and `deactivate_cb' for particular signal. Not sure if all
the other toolkits allow you to do such a thing.

Andrey Smirnov

reply via email to

[Prev in Thread] Current Thread [Next in Thread]