Improving the gtk2 port

Improving the gtk2 port

[Pierre Chanial]

Hey,

first of all, congrats to the devs for the rejuvenating port of emacs to 
gtk2.
emacs is now a pleasure to use. The user experience is so much improved 
that I think the sentence "The next release will have many new features, 
but no one specific essential feature" in the Development & "Coming 
Soon" section is misleading.

We, at mozilla.org, are looking forwards really tight integrations with 
the OSes especially for Mozilla Firebird. For each port, we have a look 
and feel file 
(http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/nsLookAndFeel.cpp 
) and additional skin files. There's still a lot of work to make mozilla 
integrate gracefully in the Gnome desktop. Since we're doing the same 
job, let me share the most visible problems I've noticed. Don't get me 
wrong, I know that most of them can be tweaked via the pref file, but 
they should be resolved out of the box.

- vertical scrollbar should be on the right (for LTR, at least).
- background and foreground colors for the default font should be white 
and black.
- background and foreground colors of text selection should obey the 
system default (in moz, we have the background color right but not the 
foreground, we'll fix that).
- the text cursor should be like a |, not an filled rectangle. Its 
default color should be black and not pink.
- on the content area, even outside of the text, the mouse cursor should 
not be an arrow but a |--| rotated 90° and by no way pink but black.
- tooltips haven't the system background and foreground colors and 
should appear below the mouse pointer.

Given that I don't know the emacs codebase, I've tried to establish the 
above list to maximize the "user experience/work required" ratio but of 
course, there are other issues like antialiasing, default system fonts, 
writing a gtk2 pref panel similar to other gtk2/KDE apps, use of the gtk 
file integration of the info files with yelp, etc.

There's still another serious bug in emacs: the X selection isn't done 
right: I can't paste from emacs to another gkt2 app without using the 
mouse. Apparently, the PRIMARY and CLIPBOARD X selections are messed up.
See the guidelines followed by mozilla, Xemacs and GTK2 apps in
http://freedesktop.org/Standards/clipboards-spec/clipboards.txt for more 
info.

Thanks for the attention,
Pierre Chanial

Re: Improving the gtk2 port

[Miles Bader]

On Mon, Jan 19, 2004 at 04:52:25PM -0500, Pierre Chanial wrote:
> - the text cursor should be like a |, not an filled rectangle. Its 
> default color should be black and not pink.

No, the default cursor should _not_ be a |, that's not visible enough for
serious text editing.  Remember, emacs depends a lot more on the cursor
position than typical mousey editors.

[Speaking of Mozilla, actually, I often find its edit boxes a miserable
experience because of exactly that issue: the thin little bar-cursor is hard
to find after a keyboard operation that didn't have exactly the result I
expected.]

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: Improving the gtk2 port

[David Kastrup]

Pierre Chanial <p_ch@verizon.net> writes:

> We, at mozilla.org, are looking forwards really tight integrations
> with the OSes especially for Mozilla Firebird. For each port, we have
> a look and feel file
> (http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/nsLookAndFeel.cpp
> ) and additional skin files. There's still a lot of work to make
> mozilla integrate gracefully in the Gnome desktop. Since we're doing
> the same job, let me share the most visible problems I've
> noticed. Don't get me wrong, I know that most of them can be tweaked
> via the pref file, but they should be resolved out of the box.

Let me state one thing: Emacs is by far the most common application I
use.  I rather prefer that it works well than that it mimics other
applications.

> - vertical scrollbar should be on the right (for LTR, at least).

No.  Emacs' main task is editing of plain text files, such as program
texts.  Program texts (as opposed to justified text) are oriented on
the left border.  Ergonomics demand that the scroll bar be at the
side where I am editing most of the time.  That is the left.  With a
browser, you might get away with scroll bar to the right since you
are not actually doing anything with the content of the pane, but
this is an editor.

> - background and foreground colors for the default font should be
> white and black.

They are here, unless overridden.

>  - the text cursor should be like a |, not an filled rectangle.

Forget it.  We are talking an editor here.  The whole screen area is a
potential target for the cursor, not some tiny input line.  One of
the most important tasks when leafing through a text is finding your
cursor again.  The | line is simply too small for finding reliably
when it is static (the mouse text cursor _is_ of the | variety, but
since it moves synchronously with you hand, you can easily find it
with a bit of manual help).

> Its default color should be black and not pink.

It is here.

> - on the content area, even outside of the text, the mouse cursor
> should not be an arrow but a |--| rotated 90° and by no way pink but
> black.

Why?  Aiming is easier when it is an arrow.  And packages like
preview-latex <URL:http://preview-latex.sourceforge.net> offer
targets which you have to click on.

> - tooltips haven't the system background and foreground colors and
> should appear below the mouse pointer.

What is the advantage in tooltips having the same colors?  Does Gtk2
not have a separately customizable tooltip color?

While integration is a nice thought, Emacs is very idiosyncratic in a
lot of ways, and quite a few of them have particular reasons.  And
not too few reasons are related to the fact that Emacs is, after all,
an editor.

So one should weigh differences on their merits before trying to
plough them under.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Improving the gtk2 port

[Jan D.]

> - vertical scrollbar should be on the right (for LTR, at least).
> - background and foreground colors for the default font should be 
> white and black.

They are.  But if you are running Emacs on some GNU/Linux distribution
like RedHat, they may have (well, RedHat and Mandrake i know have) 
installed
some system wide Emacs customizations that change this.

> - background and foreground colors of text selection should obey the 
> system default (in moz, we have the background color right but not the 
> foreground, we'll fix that).
> - the text cursor should be like a |, not an filled rectangle. Its 
> default color should be black and not pink.

I totally agree with Miles Bader, this is no good, even in Mozilla.

> - on the content area, even outside of the text, the mouse cursor 
> should not be an arrow but a |--| rotated 90° and by no way pink but 
> black.
> - tooltips haven't the system background and foreground colors and 
> should appear below the mouse pointer.

All of these points really is the difference of using Emacs default,
which predates GTK.  Scrollbar to the left, different tooltip colours,
text selection colours, e.t.c. are all done the Emacs way.

> Given that I don't know the emacs codebase, I've tried to establish 
> the above list to maximize the "user experience/work required" ratio 
> but of course, there are other issues like antialiasing, default 
> system fonts, writing a gtk2 pref panel similar to other gtk2/KDE 
> apps, use of the gtk file integration of the info files with yelp, 
> etc.

Antialiasing is being worked upon as I recall.  I do not think a gtk2 
pref
panel is feasible for Emacs.  Emacs is much more complex than the 
average
GTK application in this regard.  Maybe the current preference "panel"
(i.e. customize), could be given a more specific GTK look when Emacs
is compiled for GTK.  I don't know what yelp is.

>
> There's still another serious bug in emacs: the X selection isn't done 
> right: I can't paste from emacs to another gkt2 app without using the 
> mouse. Apparently, the PRIMARY and CLIPBOARD X selections are messed 
> up.
> See the guidelines followed by mozilla, Xemacs and GTK2 apps in
> http://freedesktop.org/Standards/clipboards-spec/clipboards.txt for 
> more info.

I'll look in to it.


Most of the points you bring up is Emacs using its own look and feel
that is consistent regardles of what port of Emacs you may be
running (i.e. GTK, Motif/Lesstif, Lucid, etc), versus using GTK 
defaults.
Technically I don't see any problem with using GTK defaults when 
compiled
with GTK (the colours, scrollbar on the left, the cursors), but it also
impacts on the consistens of Emacs and the feasability of using the
same Emacs configuration across different Emacs ports.  This is for
someone else to decide.  I presonally like Emacs to use the same 
colours,
cursors and so on, on different Emacs ports.

	Jan D.

Re: Improving the gtk2 port

[Pierre Chanial]

Kim F. Storm wrote:
> Pierre Chanial <p_ch@verizon.net> writes:
>>- on the content area, even outside of the text, the mouse cursor
>>  should not be an arrow but a |--| rotated 90° 
> This was changed recently (to show the arrow in non-text areas).
> 
> Besides my personal preference for this behaviour, a major reason
> for this change was that many other applications behave like that
> -- including Mozilla 1.2.1 (the one I'm using).

but mozilla behaves like that only in non editable content. Text areas 
and compose windows don't show an arrow outside of the text.
Which applications are you referring to? LyX, openoffice (not a good 
example of integration), gedit and also gtk2 single and multi lines text 
areas behave like moz.

> When (and why) did Mozilla change that ?
That's too old :) I'd point you to try out 1.6 or Mozilla Firebird, lot 
of performance stuff has been achieved.
I'd guess the reason is that in non editable content, mouse pointer 
changes notify the user he/she can or can not select the text.

But even if I found distracting the change of the mouse cursor in emacs, 
that's still a fairly minor issue, maybe because I rarely use the mouse.

Re: Improving the gtk2 port

[Kim F. Storm]

Pierre Chanial <p_ch@verizon.net> writes:

> - on the content area, even outside of the text, the mouse cursor
>   should not be an arrow but a |--| rotated 90° 

This was changed recently (to show the arrow in non-text areas).

Besides my personal preference for this behaviour, a major reason
for this change was that many other applications behave like that
-- including Mozilla 1.2.1 (the one I'm using).

When (and why) did Mozilla change that ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Improving the gtk2 port

[Danilo Segan]

Hi Jan,

"Jan D." <jan.h.d@swipnet.se> writes:

>  I don't know what yelp is.

Yelp is a Gnome Help system browser, it supports rendering DocBook via
XSLT, and has earlier (in Gnome 2.4) supported rendering info pages as
well. I think the latest one (in CVS, to come with Gnome 2.6 in March)
is not capable of rendering info files anymore, because lead
developer (Shaun McCance I think) didn't have time to adjust the
backend with new big changes in the program. 

So, it's currently not needed to worry about Yelp-integration, at
least until Yelp gets info browsing support back.

Ok, I just wanted to chip in with some info, hope this helps clarify
some things a bit, and helps make proper decisions :)

Cheers,
Danilo

Re: Improving the gtk2 port

[Kim F. Storm]

Pierre Chanial <p_ch@verizon.net> writes:

> Kim F. Storm wrote:
> > Pierre Chanial <p_ch@verizon.net> writes:
> >>- on the content area, even outside of the text, the mouse cursor
> >>  should not be an arrow but a |--| rotated 90° 
> > This was changed recently (to show the arrow in non-text areas).
> > Besides my personal preference for this behaviour, a major reason
> > for this change was that many other applications behave like that
> > -- including Mozilla 1.2.1 (the one I'm using).
> 
> but mozilla behaves like that only in non editable content. Text areas
> and compose windows don't show an arrow outside of the text.
> Which applications are you referring to? LyX, openoffice (not a good
> example of integration), gedit and also gtk2 single and multi lines
> text areas behave like moz.

So for emacs to be consistent with e.g. moz, the cursor outside
text-areas should change to an arrow in read-only buffers, but not in
editable buffers.

> 
> I'd guess the reason is that in non editable content, mouse pointer
> changes notify the user he/she can or can not select the text.

Exactly!  The change in pointer shape clearly indicate whether there
is any selectable text below the pointer.  That is equally important
in editable and non-editable buffers.

> 
> But even if I found distracting the change of the mouse cursor in
> emacs, that's still a fairly minor issue, maybe because I rarely use
> the mouse.

You can get the behaviour you want with

        (setq void-text-area-pointer nil)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Improving the gtk2 port

[Jan D.]

> Yelp is a Gnome Help system browser, it supports rendering DocBook via
> XSLT, and has earlier (in Gnome 2.4) supported rendering info pages as
> well. I think the latest one (in CVS, to come with Gnome 2.6 in March)
> is not capable of rendering info files anymore, because lead
> developer (Shaun McCance I think) didn't have time to adjust the
> backend with new big changes in the program.
>
> So, it's currently not needed to worry about Yelp-integration, at
> least until Yelp gets info browsing support back.

Thanks for the info.  I'm not sure what is meant by "integration" 
though.
Is the suggestion that Emacs use yelp to display info manuals?  Why
would any Emacs user want that, especially since one has used Emacs
own info reader for several years and on platforms where yelp is not
available?  Anyway, you say this is nothing to worry about, so lets not.

	Jan D.

Re: Improving the gtk2 port

[Danilo Segan]

"Jan D." <jan.h.d@swipnet.se> writes:

>> Yelp is a Gnome Help system browser, it supports rendering DocBook via
>> XSLT, and has earlier (in Gnome 2.4) supported rendering info pages as
>> well. I think the latest one (in CVS, to come with Gnome 2.6 in March)
>> is not capable of rendering info files anymore, because lead
>> developer (Shaun McCance I think) didn't have time to adjust the
>> backend with new big changes in the program.
>>
>> So, it's currently not needed to worry about Yelp-integration, at
>> least until Yelp gets info browsing support back.
>
> Thanks for the info.  I'm not sure what is meant by "integration"
> though.
> Is the suggestion that Emacs use yelp to display info manuals?  

That's how I got the idea of Pierre Chanial. Though, I may have
misunderstood it. (info support in Yelp is still to be desired,
because that would also provide another way to access other manuals,
not just those of Emacs, but that's not relevant to emacs-devel.)

> Why would any Emacs user want that, especially since one has used Emacs
> own info reader for several years and on platforms where yelp is not
> available?  Anyway, you say this is nothing to worry about, so lets not.

Yeah, I agree with that.

There are many more problems which will probably "plague" Emacs
forever (if one considers it a bad thing because it's not "like every
other Gnome app"), because Emacs is a completely distinct system: no
gettext support for UI translation, UI is tightly bound with
documentation (which explains lack of translation support for the UI
-- it cannot be separated from documentation), no Pango support etc.

So, while I think some things are very useful (Gtk+2 port, DND,
copy-paste, even support for accessibility framework of GNOME would be
nice to have, etc.), others are not (like using external info reader,
as you explain above).

Cheers,
Danilo

Re: Improving the gtk2 port

[Richard Stallman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

    wrong, I know that most of them can be tweaked via the pref file, but 
    they should be resolved out of the box.

A disagreement between Emacs conventions and GNOME conventions is not,
ipso facto, a problem in Emacs.  We might want to change some of these
things in Emacs, but not necessarily.  In some cases it might be better
to change GNOME.

Emacs has its own customization mechanisms, and in many cases we have
chosen the defaults we think are best.  We might decide to change some
of them but there is no reason to change them all.

    - vertical scrollbar should be on the right (for LTR, at least).

Scroll bars on the left are better, so we won't change that default.

    - background and foreground colors for the default font should be white 
    and black.
    - background and foreground colors of text selection should obey the 
    system default (in moz, we have the background color right but not the 
    foreground, we'll fix that).

We've made careful choices of default colors in Emacs, but we can
consider whether there is an equally good choice that accords with
those conventions.

    - the text cursor should be like a |, not an filled rectangle. Its 
    default color should be black and not pink.

The box cursor will remain the default.

    - on the content area, even outside of the text, the mouse cursor should 
    not be an arrow but a |--| rotated 90° and by no way pink but black.

I have no particular opinion about this.

    - tooltips haven't the system background and foreground colors and 
    should appear below the mouse pointer.

I would not mind if we changed the defaults for the tooltips.