Jeff Sparkes <jsparkes(a)gmail.com&gt; writes: Here's screenshot showing right to left languages. And Runic! http://i.imgur.com/38Dsx.png _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Great news! Just out of curiosity, any chance that we can use the Pango code under regular Xt as well? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Nope. $ pkg-config --libs pango -pthread -L/usr/lib/i386-linux-gnu -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 Yes, and 3.0 as well. There actually aren't many changes from 2 to 3 that affect XEmacs. Now that the display is using pango, it can be used without hitting C-l all the time. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Michael Sperber writes: My point is that a fair number of things will probably need to be converted to speak glib-ly, and I would not want to do that surgery on the existing redisplay-x code, which is already a bloody mess. I doubt it's just a matter of plugging in pango-*() everywhere we used to use Xft*(). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I was mainly thinking of the long-term: Pango seems to work on all major platforms we support - Xt, Gtk, and Win32. Maybe it should do the font rendering for all of them? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On Fri, Apr 15, 2011 at 08:15:33AM -0400, Jeff Sparkes wrote: one reason I can think of is that gtk is a fast moving target. Too many usefull apps (like Dillo) were never ported from 1.x to later versions. Also I have seen subtle changes within 2.x stable branch making more complex apps unstable unless these were run in combination with exactly the same gtk version they were compiled against. Richard --- Name and OpenPGP keys available from pgp key servers _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I mean font name compatibility. Xft can use XLFD font names, gtk/pango can not. Xft and pango can use fontconfig font names. Gtk/Gdk, which I'm no longer using to draw text, only uses a simplfied version of fontconfig naming, whereas pango uses Gtk font names plus font names dependent on the backend being used. Right now, that's Xft so fontconfig names can be used. For pango on Win32 or OSX, the font names could be different. At least I can tell the three main ones apart. XLFD - "-*-luximono-bold-r-*-*-*-120-*-*-m-*-*-*" fontconfig - "Monospace-12:weight=bold:slant=italic Gtk - "Monospace Bold Italic 12" I'm trying to pango to consistently work with both Gtk and fontconfig font names. Using fontconfig brings in the fc-* functions. As you know, there's a lot of code that assumes XLFD naming. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Okay. I like definitive answers! It will be good to share font-names with Xft. Uhh, never seen it described that way. It's very informally described, even worse than the original Xft docs. I'm not sure if order is important. The Emacs manual has the best description and it's merely "fontname [properties] [size]" with a list of valid weight and slant properties. I know that font names can have spaces in them. I've never seen one with a dash, but don't know if they're legal. I've been using the dash to differentiate fontconfig from Gtk. See http://www.gnu.org/software/emacs/manual/html_node/emacs/Fonts.html I answer email at best once a day. so I understand.. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Giacomo Boffi writes: Set, yes, but they don't take effect until you actually use X. I'm suggesting that the user be given the option to run Lisp to modify those resources before popping up any frames. Certainly there are use cases for using xrdb to bind resources, such as non-local displays. I'm not saying eliminate it entirely, just that the current situation where X resources have different semantics from settings in init.el is suboptimal, and where some things (eg, Xft fonts for the tabs) don't really work at all in Customize is horrible. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mike, Michael Sperber <sperber(a)deinprogramm.de&gt; writes: I believe we've been through that many times on this list. http://ldn.linuxfoundation.org/node/34972 Best regards Marcus _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On 2011-04-17, Marcus Harnisch <marcus.harnisch(a)gmx.net&gt; wrote: And how does the GTK program running on the server pick up the different, display-appropriate, GTK preferences you have set on the laptop? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: Sure, but they don't write code for XEmacs. What matters is, first, what those of us who do write code for XEmacs want, and second, what we're willing to do for others. You are more than welcome to express *your* opinions. You are well-known here (at least to one reviewer, and that's more than enough :-), and we value your past contributions and expect more in the future. We would like to keep you happy. But I really don't think it much matters what some ill-defined and silent "majority" prefers, and my votes and code contributions won't be informed by guesses about it. It's not a question of where it's rendered; it's a question of where it's displayed. XEmacs should be able to display on multiple displays, automatically adapting to each display's special characteristics. That's why we have specifiers (aside from torturing poor David Kastrup, who has -- in his own way -- actually been a pretty good sport about it). But specifiers don't populate themselves, mostly. They need to be initialized from some kind of configuration; where available, that should include X resources. N.B. We can't get away with relying on built-in Xt initializations anyway; we already do our own parsing of most resources. Satisfying Julian, even in the GTK context, should be possible with X resources. Au contraire. I do, and I imagine Julian does too, regularly have frames displayed on both machines at the same time for various reasons. It doesn't mean that there aren't other ways of accomplishing the same goals, but we'd rather not be forced to make a choice between upgrading XEmacs and maintaining personal workflows that don't need breaking. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: Well, now that you're talking about writing the code yourself, that's a different matter entirely. :-) All I'm saying, and I believe Julian is saying the same thing, is that the Xt-based port works best for me now. For my own needs, I expect I will continue to use an Xt build and work mostly on that and Xft improvements, and maybe the Mac port, until GTK is clearly at least as good for me. At present, it clearly is not. The best I can say about the Mac GUI is that it rarely gets in my way. I doubt I could say that about GTK, and in any case XEmacs doesn't implement all that good stuff yet, and it doesn't come for free. Somebody has to jump through the hoops writing the code, and *only then* can you avoid jumping through hoops at run time, no? I'm just saying that I'm not going to be writing that code any time soon, and that I don't want the code that I still use to be removed in favor of some notion of making the code more maintainable or whatever. BTW, I do work with XEmacs displaying windows on workstations with very different displays *simultaneously* about once a week, maybe every other week. As I say, I could do it some other way, but I'm used to this way of working, and it would be unnecessary effort to do it differently. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

On Mon, Apr 18, 2011 at 04:32:11PM +0900, Stephen J. Turnbull wrote: one thinkg thats making me slightly nervous about gtk is that it is nowadays mostly run by gnome. Some prominent gnome developpers have repeatedly expressed their unwillingness to do anything to make their applications network transparent and I would be less than surprised if network transparency were ditched from gtk in some future release. Richard --- Name and OpenPGP keys available from pgp key servers _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Jeff Sparkes writes: Congratulations! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta