Re: Toolbar and info mode (and others)
Hello, Jan! On 2007-03-28, Jan Djärv said: > Richard Stallman skrev: >> A suggestion is that Info should use some sort of Quit icon >> instead of the delete, like for example >> http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. >> >> That sounds good, if there is no copyright issue for the icon. >> Can we use it without a delay? > > I think so. This is a stock GTK icon and we use a lot of other stock > GTK icons, see emacs/etc/images/README. > > Jan D. Any plan to update the icons taken from gnome-icon-themes? I think those icons are taken from gnome <= 2.14. Now 2.18 was out and >= 2.20 will be once emacs 22.1 is ready to release. They look outdated. See these screenshots: New icons: Old icons: It is more user friendly if Emacs 22.1 fit well in the major desktop environment namely Gnome. regards, -- Leo (GPG Key: 9283AA3F)
Re: Toolbar and info mode (and others)
Leo skrev: Hello, Jan! On 2007-03-28, Jan Djärv said: Richard Stallman skrev: A suggestion is that Info should use some sort of Quit icon instead of the delete, like for example http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. That sounds good, if there is no copyright issue for the icon. Can we use it without a delay? I think so. This is a stock GTK icon and we use a lot of other stock GTK icons, see emacs/etc/images/README. Jan D. Any plan to update the icons taken from gnome-icon-themes? I think those icons are taken from gnome <= 2.14. Now 2.18 was out and >= 2.20 will be once emacs 22.1 is ready to release. They look outdated. See these screenshots: ... It is more user friendly if Emacs 22.1 fit well in the major desktop environment namely Gnome. The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D.
Re: Toolbar and info mode (and others)
Richard Stallman <[EMAIL PROTECTED]> writes: > I am not trying to waste your time. > > It is not a waste. Issues like this are important, > and it is useful that you brought it up. > > Please note also that the specific point I raised is really not about > how many buttons you end up with. It's about how the toolbar behaves > when certain modes are displayed. > > I understand. > > We should try to make this better. Whether anything can be done > now before the Emacs 22 release, I am not sure -- it could be hard. > > It is possible that the solution of discarding the last few > global toolbar buttons to make room for the local ones > can be implemented now. Would someone like to try? I don't think this is easy at all. Let's leave it alone for now. BTW, setting tool-bar-button-margin to 0 gives room for more tool bar items. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416534: xae: error while compiling for xemacs
Package: xae Version: 1.0beta6-5 Severity: normal Hello, when I try configuring xemacs, I always get the following error: Compiling /usr/share/xemacs21/site-lisp/xae/xae.el... `semantic-format-tag-name' obsoletes overload `name-nonterminal' `semantic-format-tag-abbreviate' obsoletes overload `abbreviate-nonterminal' `semantic-format-tag-summarize' obsoletes overload `summarize-nonterminal' `semantic-format-tag-prototype' obsoletes overload `prototype-nonterminal' `semantic-format-tag-concise-prototype' obsoletes overload `concise-prototype-nonterminal' `semantic-format-tag-uml-abbreviate' obsoletes overload `uml-abbreviate-nonterminal' `semantic-format-tag-uml-prototype' obsoletes overload `uml-prototype-nonterminal' `semantic-format-tag-uml-concise-prototype' obsoletes overload `uml-concise-prototype-nonterminal' variable `semantic-imenu-bucketize-type-members' obsoletes, but isn't alias of `semantic-imenu-bucketize-type-parts' While compiling toplevel forms in file /usr/share/xemacs21/site-lisp/xae/xae.el: !! Wrong number of arguments ((# 2)) Error occurred processing xae.el: Wrong number of arguments: #, 2 This prevents xemacs from configuring, so could it possibly fail more silently or could xae conflict xemacs? Regards Jiri Palecek -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.3 Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2) (ignored: LC_ALL set to cs_CZ) Versions of packages xae depends on: ii eieio1:1.0pre3-6 Enhanced Implementation of Emacs I ii emacs21 [emacsen]21.4a+1-3 The GNU Emacs editor ii psgml1.3.2-4 An Emacs major mode for editing SG ii xemacs21 21.4.19-2 highly customizable text editor xae recommends no packages. -- no debconf information
Bug#415367: #415367 tex-guy - writes outside of the build directory
I'll try to do a qa upload to fix that... Thanks. -- Lior Kaplan [EMAIL PROTECTED] GPG fingerprint: C644 D0B3 92F4 8FE4 4662 B541 1558 9445 99E8 1DA0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
downcase'ing wrt locale in smtpmail.el
Hi, In smtpmail.el, protocol messages are getting downcased with respect to current locale. For instance, it downcases AUTH methods (LOGIN, PLAIN, etc.) and then compares them with the related downcased symbols '(login plain ...). And in Turkish, a downcased I is ı (dotless i), not i. Therefore, comparison fails because of logın != login or plaın != plain. IMHO, downcased must be applied using en_US locale. To reproduce the problem, start emacs with LC_CTYPE=tr_TR prefix and try to send a mail via smtpmail package. Regards.
Bug#407612: beep-media-player goes to background instead of stopping when it should close
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eddy Petrişor wrote: > Package: beep-media-player > Version: 0.9.7.1+cvs20050803-2 > Severity: critical > Justification: breaks unrelated software > > Hello, > > I just realised that beep-media-player doesn't close itself when it > should, instead it just backgrounds itself. I found out this when (after > a few starts and stops of the player) applications started crashing on > me (being killed by the kernel due to lack of resources). > > > This behaviour can be reliably reproduced on my system with this > sequence: > > 1) make sure there is no running instance of the player: > [EMAIL PROTECTED] ~ $ killall beep-media-player > beep-media-player: no process killed > 2) start the player: > [EMAIL PROTECTED] ~ $ beep-media-player > 3) start playing a song and close the player while is playing (through > the graphical interface) - this will result in music still being played > - BUG! > 4) CTRL+Z in the console > > [1]+ Stopped beep-media-player > [EMAIL PROTECTED] ~ $ ps ax | grep beep > 11214 pts/3TLl0:00 beep-media-player > 11235 pts/3S+ 0:00 grep beep > [EMAIL PROTECTED] ~ $ fg > beep-media-player > > > Because it causes unexpected behaviour (doesn't die when it should > terminate) and thus occupies memory making unrelated software not start > I think this is bug should be critical. > > Even if the bug is downgraded (is at least important), Etch should not > ship the software in such a broken state. > > -- System Information: > Debian Release: 4.0 > APT prefers testing > APT policy: (900, 'testing') > Architecture: amd64 (x86_64) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.18-3-amd64 > Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) > > Versions of packages beep-media-player depends on: > ii libasound21.0.13-1 ALSA library > ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit > ii libaudiofile0 0.2.6-6Open-source version of SGI's > audio > ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries > ii libcairo2 1.2.4-4The Cairo 2D vector graphics > libra > ii libesd-alsa0 [libesd0]0.2.36-3 Enlightened Sound Daemon (ALSA) > - > ii libfontconfig12.4.1-2generic font configuration > library > ii libfreetype6 2.2.1-5FreeType 2 font engine, shared > lib > ii libglade2-0 1:2.6.0-4 library to load .glade files at > ru > ii libglib2.0-0 2.12.4-2 The GLib library of C routines > ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user > interface > ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library > ii libid3-3.8.3c2a 3.8.3-6Library for manipulating ID3v1 > and > ii libogg0 1.1.3-2Ogg Bitstream Library > ii libpango1.0-0 1.14.8-4 Layout and rendering of > internatio > ii libpng12-01.2.15~beta5-1 PNG library - runtime > ii libsm61:1.0.1-3 X11 Session Management library > ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 > ii libvorbis0a 1.1.2.dfsg-1.2 The Vorbis General Audio > Compressi > ii libvorbisfile31.1.2.dfsg-1.2 The Vorbis General Audio > Compressi > ii libx11-6 2:1.0.3-4 X11 client-side library > ii libxcursor1 1.1.7-4X cursor management library > ii libxext6 1:1.0.1-2 X11 miscellaneous extension > librar > ii libxfixes31:4.0.1-5 X11 miscellaneous 'fixes' > extensio > ii libxi61:1.0.1-4 X11 Input extension library > ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library > ii libxml2 2.6.27.dfsg-1 GNOME XML library > ii libxrandr22:1.1.0.2-5X11 RandR extension library > ii libxrender1 1:0.9.1-3 X Rendering Extension client > libra > ii zlib1g1:1.2.3-13 compression library - runtime > > beep-media-player recommends no packages. > > -- no debconf information > > Here is thw whole session with a backtrace taken after I closed the main window and interrupted from gdb (I am not sure this is really that useful, but here goes): (gdb) run Starting program: /usr/bin/beep-media-player (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging
Re: Toolbar and info mode (and others)
Hello, Jan! > The plan is to make Emacs use stock items when built with Gtk+ at > least, so when icons changes due to a Gnome upgrade or a theme > change, Emacs changes accordingly. This is more or less > automatically done in Gtk+. But it is planned for after the > release. > > Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. regards, -- Leo (GPG Key: 9283AA3F) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Toolbar and info mode (and others)
Leo skrev: Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. You have a point, but changing things now will delay the release even further. Users have suffered with gnome 1.x icons for some time now. And I think the hope is that the next release will be done much faster than the time it has taken to do the upcoming release. Jan D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Toolbar and info mode (and others)
On 2007-03-29, Jan Djärv said: > Leo skrev: >> Hello, Jan! >> >>> The plan is to make Emacs use stock items when built with Gtk+ at >>> least, so when icons changes due to a Gnome upgrade or a theme >>> change, Emacs changes accordingly. This is more or less >>> automatically done in Gtk+. But it is planned for after the >>> release. >>> >>> Jan D. >> >> That would make users suffer for the next release cycle. But anyway, >> just a suggestion. > > You have a point, but changing things now will delay the release > even further. Users have suffered with gnome 1.x icons for some time > now. And I think the hope is that the next release will be done > much faster than the time it has taken to do the upcoming release. I am not quite sure about the delay. I can replace the icons with those from gnome 2.18 and submit to you, which probably only takes a few hours. My concern is a lot of users who want to learn Emacs will be driven off by the ugly GUI interface. regards, -- Leo (GPG Key: 9283AA3F)
