Re: ssl?
10 years, 12 months
Stephen J. Turnbull
Jerry James writes:
> I was also told, however, that Fedora considers openssl a "system
> library", which means that GPL applications can link against it.
In the cases of Motif and Qt RMS disagreed vehemently, including
bringing his lawyers into it. He won those without going to court[1],
so AFAIK there's no legal precedent one way of the other.
> I don't know if Fedora is odd in this matter, but the RedHat
> lawyers have always been conservative [1] in other matters.
So I've heard (from Tiemann and Henckel-Wallace, no less).
> [1] Excessively so, in the opinion of some Fedora users. They just
> barely OKed the use of elliptic curve cryptography a few weeks ago,
> for example.
I don't blame the lawyers. I would not mess with the US government on
the munitions nonsense, and I don't even live there.
Have a nice Thanksgiving weekend! :-)
Footnotes:
[1] X/Open's Motif was rare on OSS distros, and Lesstif and OpenMotif
were developed pretty quickly, so nobody really cared. Similarly,
although many developers preferred Qt/KDE to GTK+/GNOME, GTK+ was good
enough that nobody was willing to pay legal expenses.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: ssl?
10 years, 12 months
Uwe Brauer
>> "Stephen" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
> Of course, GPL is incompatible with most licenses, including itself,
I cannot resist:
You mean software, which is released under GPL, cannot be released under
GPL.:-D
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
smtpmail and delete-process fails
10 years, 12 months
Raymond Toy
A long time I asked about smtpmail, starttls and gmail
(http://lists.xemacs.org/pipermail/xemacs-beta/2011-March/020997.html).
I couldn't get to work and gave up.
So, I finally tried again, and it still failed to work for me, with
starttls-use-gnutls set to T. When I changed that to nil, it started
working for me, suddenly. Hurray! Of course, it's now on a different
system from before, but I don't care.
I wouldn't be writing this if there wasn't, of course, an issue.
What's happening is that the messag is sent, but the delete-process
near the very end of smtpmail-via-smtp generates an error about not
being able to delete the process. When I C-x e smtpmail-via-smtp,
everything works. Is there something special about delete-process in
byte-compiled code?
It's a bit annoying, but I can live without a byte-compiled smtpmail.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
xemacs-gtk does not compile Kubuntu 10.04 postgresql
10 years, 12 months
Uwe Brauer
Hi
this is very odd, I have two laptops which both run Ubuntu 10.04, but
don't have the same deb installed. I was compiling successfully in one
laptop but now it failed on the other with the following error message.
,----
|
| In file included from inline.c:86:
| ./../modules/postgresql/postgresql.h:32:10: fatal error: 'postgresql/libpq-fe.h'
| file not found
| #include LIBPQ_FE_H_FILE /* main PostgreSQL header file */
| ^
| In file included from inline.c:42:
| ./config.h:568:25: note: instantiated from:
| #define LIBPQ_FE_H_FILE "postgresql/libpq-fe.h"
| ^
| 1 diagnostic generated.
| make[1]: *** [inline.o] Error 1
| make[1]: Leaving directory `/home/oub/ALLES/Add-Import/xemacs-gtk/xemacs-xemacs-gtk-d8d9b29bfaba/src'
| make: *** [src] Error 2
`----
So libpq-dev is missing
what puzzles me that .configure did not find out about some missing
postgresql library, nor did
sudo apt-get build-dep xemacs21
thanks
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
quail, hebrew, gtk coding question
10 years, 12 months
Uwe Brauer
Hello
In my opinion Jeff's work on xemacs-gtk is a big leap towards BIDI
support.
So far I have written hebrew via KDE keyboard layout, but of course this
is not a solution, since all the Control commands are then lost.
So I thought of providing a hebrew input method, in fact several
different layouts, standard layout, layout with niqud (vowels), phonetic
layout.
The question is: in which coding should I save the file:
- iso-8859-8
- UTF-8
- iso-2022-7bit.
The first option would rule out niqud. I am not sure between two and
three. GNU emacs uses iso-2022-7bit, which is not compatible with "our"
iso-2022-7bit, at least when I open their hebrew.el (quail file). I
don't see hebrew letters. When I use GNU emacs save the file with UTF8
and open it with xemacs (21.5.33 Mule) I see the hebrew letters
correctly displayed.
Which makes me vote for UFT8.
Any comments??
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
xemacs-gtk: cannot compile the latest checkin
11 years
Uwe Brauer
Hi
I just tried to compile the latest checkin, but got the following error:
,----
|
| In file included from ui-gtk.c:1322:
| ui-byhand.c: In function 'Lisp_Object Fgtk_label_get(Lisp_Object)':
| ui-byhand.c:184: error: invalid conversion from 'const gchar*' to 'gchar*'
| ui-gtk.c: At global scope:
| ui-gtk.c:1128: warning: 'void __internal_callback_destroy(void*)'
| defined but not used
| ui-gtk.c:1138: warning: 'void __internal_callback_marshal(GObject*,
| void*, guint, GValue*)' defined but not used
| ui-byhand.c:241: warning: 'void __remove_gcpro_by_id(void*, GObject*)'
| defined but not used
| ui-byhand.c:247: warning: 'void __generic_toolbar_callback(GtkWidget*,
| void*)' defined but not used
| ui-gtk.c:2169: warning: 'Lisp_Object get_enumeration(const GValue*)'
| defined but not used
| make[1]: *** [ui-gtk.o] Error 1
| make[1]: Leaving directory
|`/home/oub/ALLES/Add-Import/xemacs-gtk/xemacs-xemacs-gtk-0ae936df056e/src'
| make: *** [src] Error 2
`----
so the latest changes in ui-gtk seem to be the culprit.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
GNU emacs mule-cmds.el: describe-input-method
11 years
Uwe Brauer
Hi
I just found out that describe-input-method in GNU emacs is much more
informative that ours. Here is a result
,----
| Input method: hebrew-phonetic-xkb (mode line indicator:פ)
|
| Hebrew phonetic (XKB) input method.
|
| Based on the XKB (SUN) hebrew-phonetic keyboard layout, layout that
| attempts to match Hebrew letters to English phonetic equivalents.
| 1! 2＠ 3# 4$ 5% 6^ 7& 8* 9( 0) -_ =+ ;~
| /Q 'W קE רR אT טY וU ןI םO פP [{ ]}
| שA דS גD כF עG יH חJ לK ךL ף: ," |
| זZ סX בC הV נB מN צM ת< ץ> .?
|
|
|
| KEYBOARD LAYOUT
| ---------------
| This input method works by translating individual input characters.
| Assuming that your actual keyboard has the `standard' layout,
| translation results in the following "virtual" keyboard layout:
|
| +----------------------------------------------------------------+
| | 1 ! | 2 ＠ | 3 # | 4 $ | 5 % | 6 ^ | 7 & | 8 * | 9 ) | 0 ( | - _ | = + | ` ~ |
| +----------------------------------------------------------------+
| | ק ק | ו ו | א א | ר ר | ת ט | ע ע | ו ו | י י | ס ס | פ ף | ] } | [ { |
| +------------------------------------------------------------+
| | א א | ש ש | ד ד | פ ף | ג ג | ה ה | י י | כ ך | ל ל | ; : | ' " | \ | |
| +-----------------------------------------------------------+
| | ז ז | ח ח | צ ץ | ו ו | ב ב | נ ן | מ ם | , > | . < | / ? |
| +-------------------------------------------------+
| +-----------------------------+
| | space bar |
| +-----------------------------+
|
| If your keyboard has a different layout, rearranged from
| `standard', the "virtual" keyboard you get with this input method
| will be rearranged in the same way.
|
| You can set the variable `quail-keyboard-layout-type' to specify
| the physical layout of your keyboard; the tables shown in
| documentation of input methods including this one are based on the
| physical keyboard layout as specified with that variable.
| [customize keyboard layout]
|
| KEY SEQUENCE
| ------------
| You can also input more characters by the following key sequences:
| key character(s) [type a key (sequence) and select one from the list]
| --- ------------
| E א א
|
| [back]
`----
that is pretty cool, I just had a look in there mule-cmds.el file, which
is now very different from ours. I can't figure out where do the
generate the nifty graphical keyboard display.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: [CONFIRMED]
11 years
Uwe Brauer
>> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
> On Wed, Nov 20, 2013 at 5:07 AM, Uwe Brauer <oub(a)mat.ucm.es> wrote:
>> >> "Jeff" == Jeff Sparkes <jsparkes(a)gmail.com> writes:
>>
> In theory, (setq default-frame-plist '(height 20)) should work. In
> practice, I had to edit frame-gtk.c and replace three instances of 40 with
> 20 to get a 20 line high frame. I just checked in a change setting the
> default height to 24, which should help you.
Right the setq does not work. I already tried out the changes in frame-gtk.c
BTW sorry for the naive question, I deleted frame-gtk.o and run make
again which besides compiling the frame-gtk did also all the lisp
stuff. Is this necessary to do this way?
> Go into src/faces.c and look for "Monospace 10". The 10 is the point size.
> I don't actually know where the Hebrew characters are coming from. Trying
> putting unifont first with a larger font size. Make sure it's installed;
> ubuntu doesn't select it by default.
> The default font might be Deja Vu Sans Mono. GTK makes it rather hard to
> find out.
Ok I did the following changes
/* Note that fontconfig can search for several font families in one
call. We should use this facility. */
"Monospace-14",
^^^^^^^^^^^^^^^
/* do we need to worry about non-Latin characters for monospace?
No, at least in Debian's implementation of Xft.
We should recommend that "gothic" and "mincho" aliases be created? */
"Sazanami Mincho-12",
/* Japanese #### add encoding info? */
/* Arphic for Chinese? */
/* Korean */
#elif defined (HAVE_GTK)
"Monospace 14",
^^^^^^^^^^^^^^^^^
"Sazanami Mincho 10",
"WenQuanYi Micro Hei Mono 10",
"unifont 14", /* ttf-unifont package on Ubuntu */
^^^^^^^^^^^^^^
#else
And it looks much better, save the hebrew font which is better but not much
> Hmm, I just tried "Droid Sans Mono" and Hebrew looked better.
Where did you insert that? Could you also check in please?
Thanks
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: error when compiling xemacs-gtk
11 years
Stephen J. Turnbull
Jeff Sparkes writes:
> On Wed, Nov 20, 2013 at 1:24 PM, Stephen J. Turnbull wrote:
>> Unfortunately, now I get no toolbar (but space is reserved for it),
> I've wasted countless hours trying to get that toolbar to
> appear. I just can't figure it out.
>> and the menubar is quite busted (no visible labels and the active
>> regions on the menubar for each submenu are about a dozen pixels wide).
> Yes, there's code do display emacs keys in the menu labels. It
> currently works for GTK 2 only, I should have it fixed soon.
I suspect you misunderstand me. The menubar itself is invisible: the
menu names are not displayed, and the clickable region corresponding
to each invisible label is about 12 pixels wide.
>> The tabs are somewhat broken, which is probably related to the
>> many thousands (literally) of repetitions of the warning: [omitted]
> Yesterday I checked in a partial fix that fixes the tab appearance,
> but not that warning. I haven't worked how the instantiator gets
> the notebook tabs to work.
I'll bet a drink of your choice at such time as we're in the same
place that these are all manifestations of a failure to do something
needed to activate a subwidget. (Perhaps not for the menubar, I
suspect the menubar has something to do with the fact that XEmacs
normally uses the internally defined Lucid widget rather than one from
a toolkit. Even so, I bet the manifestation would be different if the
GTK menubar was actually working.)
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta