May 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > > > Well, is the only reason for motion events while over the > > > toolbar for tooltips? Those are handled natively by the GTK > > > toolbar. > > > > Can you embed images in such tooltips? > > Ick! I should hope not. :) Why not? Have you ever played starcraft? I believe it has images in tooltips.

1 participants
0 comments

Re: XEmacs/GTK does menus... 24 years

William M. Perry

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > > I'm 100% sure -- I've been seeing it for a while. Because of > > > that, popups with many submenus are extremely slow as they need to > > > evaluate all the :active statements. Things get even worse when > > > filters come into play. > > > > Cool, then I did a good thing. :) > > Definitely. Now, if you could do the same with popup menus, it'd be > totally cool. As well as hip and rad. Nag, nag. Uhhhh... already done. :) The code that constructs the widgets is all shared code. There is a 'convert_menu' function that returns a GtkMenuItem that is suitable for inclusion into a GtkMenuBar. popup_menu just calls this function, rips out the submenu, instantiates the first-level widgets, and bob is your uncle. :) > > > You can always take a look at what Windows people have done. > > > Although I'd rather you wouldn't :), because the mswindows toolbar > > > doesn't behave properly, for instance it doesn't generate motion > > > events when mouse moves over the toolbar. > > > > Well, is the only reason for motion events while over the toolbar > > for tooltips? Those are handled natively by the GTK toolbar. > > Can you embed images in such tooltips? Ick! I should hope not. :) > Do they do the right thing with Mule-coded text (hi Stephen)? Doesn't look like it. I need to try and do a build this afternoon with mule anyway. That should be interesting. :) > Can you press button3 to popup a context-sensitive menu (you can do this > with correctly dispatched events)? Hrm. Probably could. > None of these things are crucial, but are one argument against default > system-specified tooltips. I'll have to see how far I get. I think good integration with the native widgets is a good reason to make the implementation a little harder. Dealing with mule should be my burden, I shouldn't burden the user with crappy toolbars. :) -Bill P.

1 participants
0 comments

bitkeeper integration? 24 years

Neal D. Becker

Now that bitkeeper (www.bitkeeper.com) has *finally* a public release, has anyone looked at integrating support into vc?

2 participants
1 comments

Re: XEmacs/GTK does menus... 24 years

Hrvoje Niksic

wmperry(a)aventail.com (William M. Perry) writes: > > I'm 100% sure -- I've been seeing it for a while. Because of > > that, popups with many submenus are extremely slow as they need to > > evaluate all the :active statements. Things get even worse when > > filters come into play. > > Cool, then I did a good thing. :) Definitely. Now, if you could do the same with popup menus, it'd be totally cool. As well as hip and rad. Nag, nag. > > You can always take a look at what Windows people have done. > > Although I'd rather you wouldn't :), because the mswindows toolbar > > doesn't behave properly, for instance it doesn't generate motion > > events when mouse moves over the toolbar. > > Well, is the only reason for motion events while over the toolbar > for tooltips? Those are handled natively by the GTK toolbar. Can you embed images in such tooltips? Do they do the right thing with Mule-coded text (hi Stephen)? Can you press button3 to popup a context-sensitive menu (you can do this with correctly dispatched events)? None of these things are crucial, but are one argument against default system-specified tooltips.

2 participants
1 comments

Re: bitkeeper integration? 24 years

Adrian Aichner

>>>>> "nbecker" == nbecker <nbecker(a)fred.net> writes: nbecker> Now that bitkeeper (www.bitkeeper.com) has *finally* a nbecker> public release, has anyone looked at integrating support nbecker> into vc? Even ClearCase support for XEmacs vc package is still pending. Jan Vroonhof is still waiting for a reimplementation of GNU Emacs vc.el to be integrated with XEmacs. See a discussion earlier in this group under the subject: Re: [PATCH] backout to make kill-comilation work in native NT [Re: Fixing nt_create_process for MKS Toolkit shell] I am guilty of that subject for the thread :) Regards, Adrian

1 participants
0 comments

Re: XEmacs/GTK does menus... 24 years

Michael Harnois

On 11 May 2000 00:56:12 -0500, wmperry(a)aventail.com (William M. Perry) said: > I just checked in a whole slew of changes today that get menus > working. I had to rewrite all my beautiful lisp code in C > because it was just too darn slow and caching didn't even help. Awesome! What is your thinking in regards to MULE? Is it on your horizon somewhere? -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org "Waiter, there's no fly in my soup!" - Kermit the Frog

1 participants
0 comments

Re: XEmacs/GTK does menus... 24 years

William M. Perry

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Only the menu about to be popped down is generated (I think the > > lwlib menus currently generate the entire menubar when you click in > > the menubar, not 100% sure). > > I'm 100% sure -- I've been seeing it for a while. Because of that, > popups with many submenus are extremely slow as they need to evaluate all > the :active statements. Things get even worse when filters come into > play. Cool, then I did a good thing. :) The code in (gui|menubar)-x.c could use some commenting. I'm going to start writing up a GTK-Internals document that talks about the redisplay, X specific crap I needed, how menus work, etc, while it is still fresh in my mind. > > On to toolbars tomorrow - although this will probably be nasty given > > that toolbar.c wants to know about pixel positions of the mouse and > > things like that. I want to let Gtk handle all that nastiness. Should > > be interesting. :) > > You can always take a look at what Windows people have done. Although > I'd rather you wouldn't :), because the mswindows toolbar doesn't behave > properly, for instance it doesn't generate motion events when mouse moves > over the toolbar. Well, is the only reason for motion events while over the toolbar for tooltips? Those are handled natively by the GTK toolbar. -Bill P.

1 participants
0 comments

Re: Don't be fancy in stderr_out [Was Re: [FAILURE] CVS @ 10/05/2000 12:12] 24 years

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > +#ifdef HAVE_VSNPRINTF > + retval = vsnprintf ((char *) kludge, 8191, fmt, args); > +#else > retval = vsprintf ((char *) kludge, fmt, args); > - TO_EXTERNAL_FORMAT (DATA, (kludge, strlen ((char *) kludge)), > +#endif ... > + kludge[8191] = 0; Sorry for nitpicking, but could you please use `sizeof (kludge) - 1' instead of 8191? For instance, I'd be happier if the last line were: kludge[sizeof (kludge) - 1] = '\0'; You never know when someone will change the size of KLUDGE and miss an instance of hardcoded 8191 or 8192.

1 participants
0 comments

Re: lots of doc updates, some glyph changes 24 years

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > i'm going to fix specifiers so you can do the equivalent of > "restart-specifier-instance". this way, you just replace the code > that gets the display table with one that gets *all* display tables > in the specifier that apply, and you just have a few more to iterate > over. much simpler and faster than calling > specifier-matching-instance or whatever each time. You're right. I actually tried to implement it slow method, and I had a prototype that even worked, but was so abysmally slow that each redisplay took several seconds. That's when I concluded the specifier-matching-instance per character was not the right approach.

1 participants
0 comments

Re: [21.2.32] Build failure with minimal configuration 24 years

Jan Vroonhof

Yoshiki Hayashi <yoshiki(a)xemacs.org> writes: > ungcpro_popup_callbacks is defined in gui-x.c. Should > gui-x.o be linked unconditionally? If X is linked in, I think so. Jan

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 May 2000