March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

Jens Lautenbacher

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > <nic(a)niss.ac.uk> writes: > > > Sure many Linux distros come with gtk/Qt, but Sun, IBM, etc. boxes[1] > > do not, > > This will probably be change soon because of Mozilla 5/Netscape 6. > All it needs one killer app. (Although currently Mozilla takes "killer > app" too literal sometimes). mozilla wants to replace gtk again as ar as I know with pure xlib. They do their own widgets now for very good reasons, still based at the moment on gtk, but this makes no sense in the long run. One thing I toyed with if it wouldn't be a nice thing to simply use gecko as XEmacs display engine... I don't know if it _is_ possible to handle really large buffers in gecko (I assume not, as I suppose they have the DOM for a buffer always in memory) but the same holds for emacs and shouldn't be a real problem nowadays. jtl

2 participants
1 comments

[bug] Ben: `menu' keysym behaviour. 24 years, 8 months

Karl M. Hegbloom

"menu runs `popup-mode-menu'" It pops up a menu, always at the mouse pointer, but the arrow keys don't work for selecting menu items, and ESC doesn't pop the menu down again.

2 participants
1 comments

A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

William M. Perry

Well, my proposal was accepted by the BeOpen folks on SourceXchange, so I'm going to start working on the various documents outlining how I'll be replacing the lwlib/motif/athena/etc widgets with gtk or qt. 99.9% sure it is going to have to be gtk after talking with stallman and the discussion we had on the mailing list a few weeks ago. Ah well... But while I was sketching out some things, and looking at the current EmacsFrame widget I wondered why we should even bother having the toolbars and menubars managed differently than the various 'gutters' that andy has implemented. If I'm going to be completely rewriting large chunks of that code, why not take the next step and just use the gutter than andy has worked so hard on? Things like scrollbars would still need to be done in the core I think (because they go with windows not frames). The basic idea would be to simplify the XEmacs window to just be an X Window with gutters on all 4 sides. When you turn on the toolbar, something just gets added to the top gutter. When you turn on the menubar, ditto. This would entail making 'toolbar' and 'menubar' widgets accesible like 'button' and 'progress-gauge', but I don't think that would be very hard. As a side-benefit this would allow you to have multiple menubars, and multiple toolbars visible at once. Just imagine... a XEmacs completely surrounded my toolbars. *shudder* Thoughts, comments, etc? -Bill P.

4 participants
3 comments

Re: XEmacs 21.2.32 FAILURE Linux 2.2.13 24 years, 8 months

SL Baur

> Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: What > happens if you insert this code from faces.c before WINDOW_FACE_CACHEL > is accessed: >> struct window *w = XWINDOW (domain); >> /* #### It's possible for this function to get called when the >> face cachels have not been initialized. I don't know why. */ >> if (!Dynarr_length (w->face_cachels)) >> reset_face_cachels (w); That cures the crash. I don't like it as a ``solution'' though. Ugh. This XEmacs is really ugly. How do I make the menu underlines go away?

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 8 months

SL Baur

William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: ... > But, using Qt would bring in horrendous licensing issues. Please. Not this again. I thought the Qt licensing issue was dead with Qt-2.0. > Trying to get RMS and Sun to allow linking with Qt - I'd rather > stick a railroad spike thru my chest than try to argue that one. I don't care what Stallman thinks. What does Sun have to do with anything? They gave us the XEmacs code and it's GPL'ed. If there are solid, technical reasons why Gtk is a better toolkit for XEmacs/InfoDock than Qt that's O.K. I would prefer not to see Qt dismissed solely for stupid, political in-fighting reasons. > Having X/Xt resources work is in my opinion useless. It isn't useless now! I would be very happy to see it made useless though. > XEmacs runs on other platforms that do not have X resources (win32, > macintosh, and tty spring to mind). We should encourage people to > use custom instead of X resources. Custom needs to understand fonts, especially Mule fonts, sensibly. We also need to be able to change everything from Lisp, which we still don't allow yet.

1 participants
0 comments

Re: XEmacs 21.2.32 FAILURE Linux 2.2.13 24 years, 8 months

SL Baur

Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > Can you break on the line that sets cachel (glyphs.c:1963 in my build) and > see what the domain actually is (i.e. is it a window?). I see glyphs.c:1963 as: cachel = WINDOW_FACE_CACHEL (XWINDOW (domain), DEFAULT_INDEX); (gdb) pobj domain $3 = (struct window *) 0x8646dc0 $4 = {header = {lheader = {type = 37, mark = 0, c_readonly = 0, lisp_readonly = 0}, next = 0x85d5cb0, uid = 9803, free = 0}, frame = 140336304, mini_p = 137314884, next = 141041056, prev = 137314884, hchild = 137314884, vchild = 137314884, parent = 137314884, pixel_left = 0, pixel_top = 0, pixel_height = 9, pixel_width = 10, buffer = 137905888, start = {140617900, 140617924, 140617948}, pointm = {140617972, 140617996, 140618020}, sb_point = 140618044, hscroll = 0, modeline_hscroll = 0, top_yoffset = 0, left_xoffset = 0, use_time = 1, last_modified = {1, 1, 1}, last_point = {140618068, 140618092, 140618116}, last_start = {140618140, 140618164, 140618188}, last_facechange = {1, 1, 1}, face_cachels = 0x8649130, glyph_cachels = 0x86490f0, subwindow_instance_cache = 140799976, line_start_cache = 0x86490b0, line_cache_last_updated = 1, line_cache_validation_override = 0, max_line_len = 0, last_point_x = {0, 0, 0}, last_point_y = {0, 0, 0}, window_end_pos = {0, 0, 0}, redisplay_end_trigger = 137314884, gutter_extent_modiff = {0, 0, 0, 0}, last_redisplay_pos = 0, dedicated = 137314884, display_table = 139989152, modeline_shadow_thickness = 5, has_modeline_p = 137314908, vertical_divider_shadow_thickness = 5, vertical_divider_line_width = 7, vertical_divider_spacing = 5, vertical_divider_always_visible_p = 137314908, scrollbar_width = 31, scrollbar_height = 31, horizontal_scrollbar_visible_p = 137314908, vertical_scrollbar_visible_p = 137314908, scrollbar_on_left_p = 137314884, scrollbar_on_top_p = 137314884, scrollbar_pointer = 140267368, toolbar = { 140337228, 137314884, 137314884, 137314884}, toolbar_size = {75, 1, 1, 1}, toolbar_border_width = {1, 1, 1, 1}, toolbar_visible_p = {137314908, 137314908, 137314908, 137314908}, toolbar_buttons_captioned_p = 137314908, default_toolbar = 140337228, default_toolbar_width = 81, default_toolbar_height = 75, default_toolbar_visible_p = 137314908, default_toolbar_border_width = 1, gutter = {137314884, 137314884, 137314884, 137314884}, real_gutter = {137314884, 137314884, 137314884, 137314884}, gutter_size = {137432060, 1, 1, 1}, real_gutter_size = {137314884, 1, 1, 1}, gutter_border_width = {5, 1, 1, 1}, gutter_visible_p = {139859616, 137314908, 137314908, 137314908}, default_gutter = 137314884, default_gutter_width = 81, default_gutter_height = 137432060, default_gutter_visible_p = 139859616, default_gutter_border_width = 5, left_margin_width = 1, right_margin_width = 1, minimum_line_ascent = 1, minimum_line_descent = 1, use_left_overflow = 137314884, use_right_overflow = 137314884, menubar_visible_p = 137314908, text_cursor_visible_p = 137314908, config_mark = 0, dead = 0, force_start = 0, redo_modeline = 0, start_at_line_beg = 1, windows_changed = 1, shadow_thickness_changed = 1, need_vertical_divider_p = 0, need_vertical_divider_valid_p = 0} > What happens if you insert this code from faces.c before > WINDOW_FACE_CACHEL is accessed: > struct window *w = XWINDOW (domain); > /* #### It's possible for this function to get called when the > face cachels have not been initialized. I don't know why. */ > if (!Dynarr_length (w->face_cachels)) > reset_face_cachels (w); > Thank I will try that next. Further data: $ xrdb -q | grep -i xemacs XEmacs*fontSet: -*-helvetica-bold-r-*--12-*-*-*-*-*-*-*,-*-fixed-medium-r-normal--14-* XEmacs.bold.attributeFont: -*-lucidatypewriter-bold-*-*-*-14-*-*-*-*-*-iso8859-* XEmacs.bolditalic.attributeFont: -*-lucidatypewriter-bold-i-*-*-14-*-*-*-*-*-iso8859-* XEmacs.default.attributeFont: -*-lucidatypewriter-medium-*-*-*-14-*-*-*-*-*-iso8859-* XEmacs.italic.attributeFont: -*-lucidatypewriter-medium-i-*-*-14-*-*-*-*-*-iso8859-* XEmacs.modeline.attributeBackgroundPixmap: nothing

1 participants
0 comments

A different VM crash on 21.2.32 24 years, 8 months

Raymond Toy

Built from full tarball on Solaris 2.7 with gcc 2.7.2.2. In a VM summary buffer, I clicked on a line to display the message, but I might have hit a buffer tab. I wasn't paying much attention. XEmacs crashed. Here's the C backtrace. The lisp backtrace is still in kernel memory somewhere. Ray #0 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa429c in fatal_error_signal (sig=6) at emacs.c:293 #2 <signal handler called> #3 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #4 0xfebb92a4 in abort () from /usr/lib/libc.so.1 #5 0xa704c in assert_failed (file=0x244468 "eval.c", line=2075, expr=0x244510 "found_error_tag || NILP (Vcurrent_error_state)") at emacs.c:2754 #6 0xaaf64 in check_error_state_sanity () at eval.c:2075 #7 0xab52c in call_with_suspended_errors (fun=0x1437f0 <image_instantiate>, retval=2616740, class=3041284, errb=Cannot access memory at address 0x2a. ) at eval.c:1314 #8 0x1c577c in specifier_instance_from_inst_list (specifier=3602688, matchspec=2616740, domain=18600960, inst_list=4395012, errb=Cannot access memory at address 0x2a. ) at specifier.c:2457 #9 0x1c5be4 in specifier_instance (specifier=3602688, matchspec=2616740, domain=18600960, errb= Cannot access memory at address 0x2a. ) at specifier.c:2572 #10 0x146164 in update_glyph_cachel_data (w=0x11bd400, glyph=3602752, cachel=0xd28280) at glyphs.c:3619 #11 0x146458 in mark_glyph_cachels_as_not_updated (w=0x11bd400) at glyphs.c:4005 #12 0x19a600 in redisplay_window (window=18600960, skip_selected=5367293) at redisplay.c:5950 #13 0x19b0a8 in redisplay_windows (window=18600960, skip_selected=1) at redisplay.c:6253 #14 0x19a318 in redisplay_window (window=18298880, skip_selected=1) at redisplay.c:5883 #15 0x19b43c in redisplay_frame (f=0x875000, preemption_check=18298880) at redisplay.c:6253 #16 0x19b6c8 in redisplay_device (d=0x628700, automatic=8867840) at redisplay.c:6487 #17 0x19bbe0 in redisplay_without_hooks () at redisplay.c:6576 #18 0x19be64 in redisplay () at redisplay.c:6633 #19 0xfd3d8 in Fnext_event (event=18008880, prompt=3041284) at event-stream.c:2180 #20 0x87ed0 in Fcommand_loop_1 () at cmdloop.c:566 #21 0x87c74 in command_loop_1 (dummy=3041284) at cmdloop.c:490 #22 0xaa254 in condition_case_1 (handlers=2805760, bfun=0x87c28 <command_loop_1>, barg=3041284, hfun=0x880c0 <cmd_error>, harg=3041284) at eval.c:1644 #23 0x881d0 in command_loop_2 (dummy=3041284) at cmdloop.c:252 #24 0xa9de8 in internal_catch (tag=3123444, func=0x88184 <command_loop_2>, arg=3041284, threw=0x0) at eval.c:1310 #25 0x875a8 in initial_command_loop (load_me=557444) at cmdloop.c:301 #26 0xa5ebc in xemacs_21_2_b32_sparc_sun_solaris2_7 (argc=1, argv=0xffbeedb4, envp=0xffbeedbc, restart=0) at emacs.c:1873 #27 0xa66d8 in main (argc=1, argv=0xffbeedb4, envp=0xffbeedbc) at emacs.c:2292

1 participants
0 comments

Build Failure for Xemacs-21.2.32 24 years, 8 months

Brent B. Powers

xemacs.mak, as per Ben's changes, has !include "config.inc" But there is no config.inc in the tarball.

2 participants
1 comments

still crashing in VM 24 years, 8 months

John A. Turner

updated and rebuilt this AM, still crashing in the same way that was reported in this thread: http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00128.html but now even my C stack is almost useless (no lisp backtrace, as usual): Program received signal SIGSEGV, Segmentation fault. XtIsManaged () at Destroy.c:152 152 Destroy.c: No such file or directory. (gdb) where #0 XtIsManaged () at Destroy.c:152 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. XtIsManaged () at Destroy.c:152 152 in Destroy.c (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. kill () at engine.c:648 648 engine.c: No such file or directory. (gdb) cont Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. install details same as those reported here: http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00021.html -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 825-8319

2 participants
3 comments

Re: 21.2.32 (31 too) - most of custom faces got lost 24 years, 8 months

Dmitry Yaitskov

Sorry for a followup to my own post, or rather sorry for posting w/out investigating the problem first. It turned out that in custom-set-faces, most of my faces were specified with (background light) whereas my current background is "dark". I still do not know why it worked before, but looks like it was another bug that got fixed. I wrote: > Hi, > > Subj. I had re-defined most of faces in my XEmacs to use a dark > background. All worked well till b31. Now in beta 32 the problem is > still there - most of my customized faces look like (also redefined) > default face. This is true for at least font lock and gnus. OTOH, > modeline faces are fine (I changed them too). My XEmacs is cygwin. -- Cheers, -Dima.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta March 2000