At 12:36 PM 8/19/99 -0700, Erik Arneson wrote: The gutter is controlled with gui-element face. The tab widget in the gutter uses the default face. Maybe this is wrong. Its easy to make it customizable. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

On Thu, Aug 19, 1999 at 02:55:47PM -0700, Erik Arneson wrote: well, you're lucky to have a second window with a gutter, i don't have that! as i already explained somewhere here, i am allowed to only one window with a gutter, all new frames that i'd create will have these black gutters with only edges. ah, also, what is supposed to happen when you have more files in a gutter group than displayable ? me thinks the groups gets divided into two groups that switch to and fro eachother when i click on the gutter, which has the effect that wherever i click on it, it just switches to the other half of the group, not to the files pointer by the gutter. would it not be nice if we had them like in windows, (argh!) where clicking on the rightmost would scroll the gutter to the right, allowing you to select new gutters that didn't fit ? or have an arrow at the right an left to scroll it to see the whole group ? even one up and down to switch gutter group ? i think gtk has a widget for that, but of course i haven't seen any XEmacs for gtk :( (and maybe it's better that way?) -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding...

On Fri, Aug 20, 1999 at 11:39:06AM +0100, Andy Piper wrote: not using multiple frames ? yes i understood the concept of groups, but what i say is that when the amount of 'java' files i'm visiting exceeds the amount of visible tabs, i get several 'semi-groups' of 'java' files, like ... one with 4 files, and a second with 2 files, and when i am seeing the one with 2 files, and i click on one of the tweo gutters, i get the gutter pane with the 4 other gutters, but no current buffer change. when i click again i switch back to the 2 files gutter, still no change of current file. the only way to change file using the gutter, is to have all gutters of one group fit in the gutter pane. am i clear? sorry if my english is french. ah, i understand better how you're using it, now :) well, where does the widget come from then, if it is not a standard in motif/whatever i'm currently using ? i mean there could just be re-use of widget code, no? -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding...

ok, i forgot to mention that i set my default face background to black, and when xemacs starts, it paints everything to grey default, then it initializes the gutter tabs by calling TabsInit(Widget req, Widget new, ArgList, Cardinal *nargs) in xlwtabs.c , by looking a bit at what happens in there i see a primising variable in the new widget passed as argument, called newTw->core.background_pixel wchich is set to 52857 (me thinks the default grey) then it gets painted, it all changes color to my preferred black, and the buffer window and minibuffer and surrounding of gutter tab becomes black. the gutter at this point is not updated or repainted, so it does not become unvalid and will never change its background to black. when i create another frame , you create another gutter tab widget. and this time in the function TabsInit(Widget req, Widget new, ArgList, Cardinal *nargs) in xlwtabs.c, the variable newTw->core.background_pixel is set to 0 (which i assume is my black), and then from there on, the tabs widget will assume his background is black, and since the font in the gutter default to black (my default font is white however, so it does not care about it), i see NOTHING! and it will never change. by setting the variable newTw->core.background_pixel when TabsInit initializes the new tabs widget in the debugger to the value it got in the first frame (52857), then the widget will always be painted with the excpected value: what i want. so my diagnostic is that whoever created the tab widget sets its foreground to black and its background to the default face background, when the foreground should be that of the other widgets (like menus) and so should be the background. or do we want the background of the tab widget to be that of the default face and then it should be updated when face background is changed, and it should care about the fae foreground and use it as well. i'd prefer the menu colors. -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding...

I'm stalled on this. There is a bug in the tab widget which means you can't set the tab colors dynamically at present. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

At 12:01 PM 8/24/99 +0200, Stef Epardaud wrote: I was talking about the second frame being totally black. The inital frame is a different problem which I will fix, but if I fix it I will then encounter the totally black problem - so I'm waiting... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd