Gtk patch version 2, part 1

Gtk patch version 2, part 1

[Jan D.]

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

Hello.

Here is the diff for modified files for the GTK port.  New files are posted
separately.  I hope this diff makes it without corruption this time.

I have corrected everything that was commented on in the first version,
except Richards suggestion to modify the way events to toolkits gets
dropped or not, I have not explored this in detail yet for Xt.

Scrollbar problems is fixed, although some borderline cases look strange
(but they also look strange with Motif).

Geometry problem remains, I haven't nailed that down yet.  Specifically
-g -0-0 does not end up at -0-0, the menu bar is not taken into account.
+X+Y works OK as well as -X+Y.  Only -Y is off.

Detachable menus works, but dissapears unexpectedly.  This is due to the
bas update of widgets in the menu tree.  When the "original" menu
is removed, the detachable menu is also removed.  So if one detach "File"
for example, that goes well.  But then a click on the menubar recreates
widgets (destroying old) so the detached menu vanishes.

This is also why detachable popups does not work.  Or rather they do work,
but the popup menu is removed at once it is popped down, so the
detachable menu is also removed.  In principle, you will never see it,
it goes too fast.  I must keep menus that has detachable "children" around
longer.

Still to do:
  Geometry problems.
  Detachable menu problem.
  NEWS and ChangeLog entries.
  Documentation about widgets used and their names so one can customize them.
  Bugs I don't know about yet.
  Help for menus (can possibly checkin without this).
  GTK toolbar (after checkin I think).


Please comment,

	Jan D.


[-- Attachment #2: emacs-cvs-gtk-diff.gz --]
[-- Type: application/gzip, Size: 69857 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Gtk patch version 2, part 1

[Miles Bader]

"Jan D." <jan.h.d@swipnet.se> writes:
> Here is the diff for modified files for the GTK port.  New files are posted
> separately.  I hope this diff makes it without corruption this time.

Ah, this time, the patch applied perfectly, and everything
configured/compiled without problem.  It also seems to work. "-'

> Scrollbar problems is fixed, although some borderline cases look strange
> (but they also look strange with Motif).

Scrollbars seem to still be incorrect in one case: when the buffer is
zero-length.  In this case, the scroll-bar thumb should cover the whole
bar, but emacs-gtk displays a `tiny' thumb, as used when the document
is very large.

I also notice that scrollbars flicker _a lot_, to the extent that it's
pretty annoying.  This happens even if you just move the cursor around
within the screen (so that no redraw should be necessary), but only when
it moves to a new line, e.g., if you just repeat `C-n C-p C-n C-p ...'
it will flicker for each command.

Also, menu display seems noticably slower than with `lucid toolkit'
menus, but that may be just GTK being slow (or some sort of intentional
delay).

Otherwise, it's looking good!

I still don't want to use it for everyday use, because the menu bar is
too big and ugly, but that's partially Gnome/GTK's fault -- it only
seems to have _one_ font you can specify, which gets used for everything
(and I want to keep the large font for my `panel' text)!

Hopefully a future version of emacs-gtk will allow overriding some of
the horrid GTK defaults...  I'd like, at least:  (1) menu font, and
(2) some way to reduce the gratuitous whitespace used around menu-bar
labels (there are at least two whitespace areas -- the whitespace which
is `part of' the menu-label-button, and additional whitespace around
that; I'd like to reduce the second to zero).

Thanks,

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Gtk patch version 2, part 1

[Eric Gillespie]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I also notice that scrollbars flicker _a lot_, to the extent that it's
> pretty annoying.

Yes, i notice that too.

> Also, menu display seems noticably slower than with `lucid toolkit'
> menus, but that may be just GTK being slow (or some sort of intentional
> delay).

It certainly isn't GTK.

> Otherwise, it's looking good!

Quite!

> I still don't want to use it for everyday use, because the menu bar is
> too big and ugly, but that's partially Gnome/GTK's fault -- it only
> seems to have _one_ font you can specify, which gets used for everything
> (and I want to keep the large font for my `panel' text)!

No, you can specify styles for individual widgets just like with
true Xt applications.  Application developers are supposed to
assign their widget's name with gtk_widget_set_name().  As long
as Emacs sets its menubar widgets to be named something like
"emacs-menubar" something like this should do what you want:

style "emacs-menubar-font" { font = "blah" }
widget emacs-menubar style "emacs-menubar-font"

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

Re: Gtk patch version 2, part 1

[Eric Gillespie]

Eric Gillespie <epg@pretzelnet.org> writes:

> No, you can specify styles for individual widgets just like with
> true Xt applications.  Application developers are supposed to
> assign their widget's name with gtk_widget_set_name().  As long
> as Emacs sets its menubar widgets to be named something like
> "emacs-menubar" something like this should do what you want:
> 
> style "emacs-menubar-font" { font = "blah" }
> widget emacs-menubar style "emacs-menubar-font"

And it looks like Jan knew all about this and did it right.  See
below.  Cool :).

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

> Still to do:

[...]

>   Documentation about widgets used and their names so one can customize them.

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

Re: Gtk patch version 2, part 1

[Miles Bader]

Eric Gillespie <epg@pretzelnet.org> writes:
> > style "emacs-menubar-font" { font = "blah" }
> > widget emacs-menubar style "emacs-menubar-font"
> 
> And it looks like Jan knew all about this and did it right.  See
> below.  Cool :).

Where would I put the above magic?

Thanks,

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: Gtk patch version 2, part 1

[Eric Gillespie]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Where would I put the above magic?

~/.gtkrc-2.0
$sysconfdir/gtk-2.0/gtkrc

If you're curious, GTK 1.x apps work similarly but with these paths:

~/.gtkrc
$sysconfdir/gtk/gtkrc

The syntax of the files has not actually changed between
versions.  I think the only reason versioned file names are now
used is because engines (themes that actually provide new
drawing code rather than simply changing colors, sizes, fonts,
etc.) are loaded from the rc files, and the ABI does change
between major versions.

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

Re: Gtk patch version 2, part 1

[Miles Bader]

Eric Gillespie <epg@pretzelnet.org> writes:
> > Where would I put the above magic?
> 
> ~/.gtkrc-2.0
> $sysconfdir/gtk-2.0/gtkrc

Oddly enough, I have _none_ of those files, and yet surely the info is
stored somewhere, because I'm using a non-standard theme, which works
fine!  I set the theme via the `control panel' stuff, so I'm not sure
how it's done.

I'm using the standard gnome/gtk installation in debian unstable (which
is gnome 2.x).

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Gtk patch version 2, part 1

[Miles Bader]

Ok, I tried putting the following:

   style "emacs-menubar-font" { font = "URW Gothic L 10" }
   widget "emacs-menubar" style "emacs-menubar-font"

in ~/.gtkrc-2.0, and it doesn't seem to have any effect.

I know it's _reading_ that file, because it initially complained about
the syntax when I started emacs, so I changed `widget emacs-menubar' (as
you had it in your email) to `widget "emacs-menubar"'.

No obvious effect though.  I noticed that some old .gtkrc files used
`widget_class "*"' so I tried doing that now too (replacing `widget
"emacs-menubar"'), but that didn't do anything either, so maybe where
it's getting the general gtk theme from is overriding this file...

`URW Gothic L' is the font I usually generally for gtk/gnome, so I
assume it should be OK here too; I just changed the size to 10 here, and
the syntax seems consistent with other examples.

Thanks,

-Miles
-- 
Fast, small, soon; pick any 2.

Re: Gtk patch version 2, part 1

[Eric Gillespie]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Ok, I tried putting the following:
> 
>    style "emacs-menubar-font" { font = "URW Gothic L 10" }
>    widget "emacs-menubar" style "emacs-menubar-font"
> 
> in ~/.gtkrc-2.0, and it doesn't seem to have any effect.

Sorry, but as i said in my message you got that from, that is
only an example.  I do not know what name (if any) Jan has used
for the menubar.

> No obvious effect though.  I noticed that some old .gtkrc files used
> `widget_class "*"' so I tried doing that now too (replacing `widget
> "emacs-menubar"'), but that didn't do anything either, so maybe where
> it's getting the general gtk theme from is overriding this file...

No, the 'widget' directive is definitely what you want.  See
<http://developer.gnome.org/doc/API/gtk/gtk-resource-files.html>
for more information.

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

Re: Gtk patch version 2, part 1

[Jan D.]

tisdagen den 17 december 2002 kl 11.42 skrev Eric Gillespie:

> Miles Bader <miles@lsi.nec.co.jp> writes:
>
>> Ok, I tried putting the following:
>>
>>    style "emacs-menubar-font" { font = "URW Gothic L 10" }
>>    widget "emacs-menubar" style "emacs-menubar-font"
>>
>> in ~/.gtkrc-2.0, and it doesn't seem to have any effect.
>
> Sorry, but as i said in my message you got that from, that is
> only an example.  I do not know what name (if any) Jan has used
> for the menubar.

It is actually called "menubar" (I use the same names as Xt).  But
due to my ignorance, I missed to give a name to the top level widget,
(I thought it picked up argv[0] by default, but that does not seem
to be the case), so you have to say:

   widget "*.menubar.*" style "your_style"

However, menubar sounds quite generic, so it might affect other applications
also.  I recommend reading the link Eric posted in another mail.  The
format of GTK resource files are quite different from the standard
.Xdefaults syntax.  I am not very good at it.

	Jan D.

Re: Gtk patch version 2, part 1

[Richard Stallman]

I think the discussion of where to find this customization info is
important.  It would be very useful for Emacs to come with a complete
list of the places that this customization information may be located,
so users can be sure they can find it and correct it.

Re: Gtk patch version 2, part 1

[Eric Gillespie]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Oddly enough, I have _none_ of those files, and yet surely the info is
> stored somewhere, because I'm using a non-standard theme, which works
> fine!  I set the theme via the `control panel' stuff, so I'm not sure
> how it's done.

That is as expected.  The GNOME 1.x control center had a hack
where it managed ~/.gtkrc but included ~/.gtkrc.mine and had a
comment in .gtkrc explaining that this file is generated, go
edit that one.

The problem is that your theme is one of the settings that should
be per display, not per host.  That is, when running gedit on
host1 displaying on host2, the theme should not come from the
.gtkrc on host1 but from what was configured on host2's display.
The mechanism KDE and GTK use for this is called XSettings
(http://www.freedesktop.org/standards/xsettings.html).  So the
theme is stored in GNOME's gconf settings, and when it starts it
sets the theme XSetting and all GTK apps pick that up.

We're drifting frightfully off-topic at this point...

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

Re: Gtk patch version 2, part 1

[Jan D.]

> 
> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > Where would I put the above magic?
> 
> ~/.gtkrc-2.0
> $sysconfdir/gtk-2.0/gtkrc
> 
> If you're curious, GTK 1.x apps work similarly but with these paths:
> 
> ~/.gtkrc
> $sysconfdir/gtk/gtkrc
> 
> The syntax of the files has not actually changed between
> versions.  I think the only reason versioned file names are now
> used is because engines (themes that actually provide new
> drawing code rather than simply changing colors, sizes, fonts,
> etc.) are loaded from the rc files, and the ABI does change
> between major versions.

There is at least one change.  2.0 allows for Pango font names like
  font_name = "helvetica bold 14"

	Jan D.

Re: Gtk patch version 2, part 1

[Miles Bader]

BTW, unless you forsee massive future changes, why not check this stuff
into CVS?

It appears to work well enough to be useful, and as far as I can tell
doesn't interfere with non-gtk platforms (I kept your previous patch
applied even when I switched back to using the normal lucid widgets).

It seems like the only real pre-checkin change needed is ChangeLog
entries (and that's pretty easy if you use Stefan's whizzy `C-x 4'-
from-diff-mode feature).

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: Gtk patch version 2, part 1

[Jan D.]

> 
> BTW, unless you forsee massive future changes, why not check this stuff
> into CVS?

No, I hopefully will only do incremental changes from here on.  The basic
structure should be OK.
I didn't want to check in so much before someone in the appropriate
position looked it over and gave the OK.

If nobody have objections I can check it in pretty much anytime.

> It seems like the only real pre-checkin change needed is ChangeLog
> entries (and that's pretty easy if you use Stefan's whizzy `C-x 4'-
> from-diff-mode feature).

Hmm, I didn't know about that.  I'll be sure to try it.

Thanks,

	Jan D.

Re: Gtk patch version 2, part 1

[Jan D.]

> 
> > Scrollbar problems is fixed, although some borderline cases look strange
> > (but they also look strange with Motif).
> 
> Scrollbars seem to still be incorrect in one case: when the buffer is
> zero-length.  In this case, the scroll-bar thumb should cover the whole
> bar, but emacs-gtk displays a `tiny' thumb, as used when the document
> is very large.

I should have caught that.  It is an easy fix.  Thanks.

> I also notice that scrollbars flicker _a lot_, to the extent that it's
> pretty annoying.  This happens even if you just move the cursor around
> within the screen (so that no redraw should be necessary), but only when
> it moves to a new line, e.g., if you just repeat `C-n C-p C-n C-p ...'
> it will flicker for each command.

I will take a look.  It does not look terribly bad on my machine,
I will try on a slower one so the effect really shows.

> Also, menu display seems noticably slower than with `lucid toolkit'
> menus, but that may be just GTK being slow (or some sort of intentional
> delay).

This is probably due to the non-optimal rebuilding of Emacs menus that
this code currently does.  I wanted something working, so when Emacs
tells the UI code to rebuild menus, I basically throw away the old menus
and create new ones.  It has always been my plan to make this better,
I will move it up in priority.  I must do this for detachable menus
also.

> I still don't want to use it for everyday use, because the menu bar is
> too big and ugly, but that's partially Gnome/GTK's fault -- it only
> seems to have _one_ font you can specify, which gets used for everything
> (and I want to keep the large font for my `panel' text)!
> 
> Hopefully a future version of emacs-gtk will allow overriding some of
> the horrid GTK defaults...  I'd like, at least:  (1) menu font, and
> (2) some way to reduce the gratuitous whitespace used around menu-bar
> labels (there are at least two whitespace areas -- the whitespace which
> is `part of' the menu-label-button, and additional whitespace around
> that; I'd like to reduce the second to zero).

There are ways for 1 at least.  I don't know about 2, the code in Emacs
just uses the menubar widget as is.  I'll check if there is something
one can customize.  For 1) you can create a file  ~/.gtkrc-2.0
and put into it something like:

style "menubar"
{
  font = "-adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1"
}

widget_class "*GtkMenu*" style "menubar"

One can also use 'font_set = ...' or us Pango font names with
	font_name = "helvetica bold 14"

Unfortunately I haven't set names on all widgets yet, so the above
setting will affect all your GTK menus.  Later on, you can say somthing
like

  widget "Emacs.*.menubar.*" style "menubar"

	Jan D.

Re: Gtk patch version 2, part 1

[Miles Bader]

"Jan D." <jan.h.d@swipnet.se> writes:
> > Hopefully a future version of emacs-gtk will allow overriding some of
> > the horrid GTK defaults...  I'd like, at least:  (1) menu font
> 
> For 1) you can create a file ~/.gtkrc-2.0 and put into it something like:
> 
> style "menubar"
> {
>   font = "-adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1"
> }
> widget_class "*GtkMenu*" style "menubar"

I tried this, and it doesn't seem to work -- there's no error message,
but no change in the menubar font either.  Here's the exact .gtkrc-2.0
file I tried (as I mentioned in a previous message, I know it's
_reading_ the file, because syntax errors _do_ result in error messages):

   style "menubar" { font = "-adobe-helvetica-medium-r-normal--10-*-*-*-*-*-iso8859-1" }
   widget_class "*GtkMenu*" style "menubar"

[minus the indentation, actually; I also tried variants like
`font = "Helvetica 10"', but none of them worked either]

Any ideas?

Thanks,

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Gtk patch version 2, part 1

[Jan D.]

onsdagen den 18 december 2002 kl 02.08 skrev Miles Bader:

> "Jan D." <jan.h.d@swipnet.se> writes:
>>> Hopefully a future version of emacs-gtk will allow overriding some of
>>> the horrid GTK defaults...  I'd like, at least:  (1) menu font
>>
>> For 1) you can create a file ~/.gtkrc-2.0 and put into it something like:
>>
>> style "menubar"
>> {
>>   font = "-adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1"
>> }
>> widget_class "*GtkMenu*" style "menubar"
>
> I tried this, and it doesn't seem to work -- there's no error message,
> but no change in the menubar font either.  Here's the exact .gtkrc-2.0
> file I tried (as I mentioned in a previous message, I know it's
> _reading_ the file, because syntax errors _do_ result in error messages):
>
>    style "menubar" { font = "-adobe-helvetica-medium-r-
> normal--10-*-*-*-*-*-iso8859-1" }
>    widget_class "*GtkMenu*" style "menubar"
>
> [minus the indentation, actually; I also tried variants like
> `font = "Helvetica 10"', but none of them worked either]
>
> Any ideas?

Well, I am currently out of ideas, because what you have is exactly what
I have (but size 14 instead of 10), and it works here.  Are you running
Gnome 2?  I am not.  I told you I wasn't good at these files :-)

I will read up on this and see what I can find.

	Jan D.

Re: Gtk patch version 2, part 1

[Simon Josefsson]

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

> Please comment,

This looks very good, possibly except some flicker in the scrollbar.
I'm using it for my main emacs now.  I also vote for installing this
in CVS.

Is any elisp GTK support planned?  Using GTK widgets from elisp would
be cool.

Re: Gtk patch version 2, part 1

[Jan D.]

> 
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
> > Please comment,
> 
> This looks very good, possibly except some flicker in the scrollbar.

I'm looking at that right now, as others have seen it also.

> I'm using it for my main emacs now.  I also vote for installing this
> in CVS.
> 
> Is any elisp GTK support planned?  Using GTK widgets from elisp would
> be cool.

Nothing planned.  XEmacs have it, but I have not looked at how that is
done.  I did read some discussion about it in usenet around the time
it was done, it then sounded quite complicated :-)

	Jan D.

Re: Gtk patch version 2, part 1

[Nick Roberts]

 > > Is any elisp GTK support planned?  Using GTK widgets from elisp would
 > > be cool.
 > 
 > Nothing planned.  XEmacs have it, but I have not looked at how that is
 > done.  I did read some discussion about it in usenet around the time
 > it was done, it then sounded quite complicated :-)

I'm sure it has been discussed many times before but can someone please
explain to me in simple terms (perhaps by way of a brief history lesson) why
guile-gtk has has a Scheme interpreter. Does this not result in duplication
of effort ? Or does it serve a different purpose ?

Nick

Re: Gtk patch version 2, part 1

[Richard Stallman]

    I'm sure it has been discussed many times before but can someone please
    explain to me in simple terms (perhaps by way of a brief history lesson) why
    guile-gtk has has a Scheme interpreter.

Guile is a Scheme interpreter; that is its purpose, to be a Scheme
interpreter.

Have I misunderstood the question?  Have you perhaps misstated it?

Re: Gtk patch version 2, part 1

[Richard Stallman]

    Still to do:
      Geometry problems.
      Detachable menu problem.
      NEWS and ChangeLog entries.
      Documentation about widgets used and their names so one can customize them.
      Bugs I don't know about yet.
      Help for menus (can possibly checkin without this).
      GTK toolbar (after checkin I think).

Do you think we should install the code in its current form?

Re: Gtk patch version 2, part 1

[Jan D.]

> 
>     Still to do:
>       Geometry problems.
>       Detachable menu problem.
>       NEWS and ChangeLog entries.
>       Documentation about widgets used and their names so one can customize them.
>       Bugs I don't know about yet.
>       Help for menus (can possibly checkin without this).
>       GTK toolbar (after checkin I think).
> 
> Do you think we should install the code in its current form?

I'd like to see if I can fix the scrollbar flicker
and customization items before checkin (should not take more than a
couple of days) so that some of the issues brought up here are resloved.

I'd recommend a checkin after that (say Friday local time).  Is that OK?

Geometry problems, menubar slowness, detachable menu problem and help
for menus not working are bugs, but not very serious ones so fixes for
that can wait a couple of weeks.

	Jan D.

Re: Gtk patch version 2, part 1

[Eli Zaretskii]

On Tue, 17 Dec 2002, Jan D. wrote:

> Geometry problems, menubar slowness, detachable menu problem and help
> for menus not working are bugs, but not very serious ones so fixes for
> that can wait a couple of weeks.

How about a command named, say, `gtk-emacs-known-bugs', which will 
display the list of known bugs and problems?

Re: Gtk patch version 2, part 1

[Alex Schroeder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Tue, 17 Dec 2002, Jan D. wrote:
>
>> Geometry problems, menubar slowness, detachable menu problem and help
>> for menus not working are bugs, but not very serious ones so fixes for
>> that can wait a couple of weeks.
>
> How about a command named, say, `gtk-emacs-known-bugs', which will 
> display the list of known bugs and problems?

Why not just add them to the PROBLEMS file?

Alex.

Re: Gtk patch version 2, part 1

[Richard Stallman]

    Why not just add them to the PROBLEMS file?

That file is for a telling people how to work around system-specific
problems.  It is not supposed to be used for listing unfinished parts
of the code.

Re: Gtk patch version 2, part 1

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     Why not just add them to the PROBLEMS file?
>
> That file is for a telling people how to work around system-specific
> problems.  It is not supposed to be used for listing unfinished parts
> of the code.

Sounds like a job for etc/TODO, then.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)