Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)

[Matt Rice]

i'll just pick a random post, and reply to this one...

--- Richard Frith-Macdonald <address@hidden>
wrote:

> On 2005-10-26 12:13:41 +0100 Dennis Leeuw
> <address@hidden> wrote:
> 
> > 
> 
> >> 1. window manager interaction ... I want clicking
> on windows to work 
> >> *reliably*, so that when I click on any GNUstep
> window
> >> a. The application activates (shows its menu and
> panels, and raises the 
> >> window clicked on).

similar to application activation is re-activation
currently when activating a hidden application windows
are stacked in the order they were created no the
order when they were hidden

possible with wm's supporting
_NET_CLIENT_LIST_STACKING, actually have a patch
somewhere for this i'll attempt to dig up...
then default to the current re-activate in the order
created

> >> b. The clicked winbdow starts accepting keyboard
> input
> >> c. any other GNUstep application deactivates
> (hides its menu and panels)
> >> 
> >> 2. popup/pulldown menu operation ... sometimes
> (often) popup menus seem to 
> >> fail to track the mouse, so you can't select
> their buttons.
> > 
> > 
> > These points seem to me are THE goals for a 1.0
> release. My question is 
> > about 
> > the next one. How much I would want to have
> Camaelon integrated I think it 
> > would be wise to move it to e.g. 1.1.
> > What do you think?
> 
> Well I *think* that Camaeleon integration should be
> a relatively 
> straightforward task, and while I have no personal
> need for it, the topic of 
> themes interests a lot of people, so I would *like*
> to see it real soon.
> 

documentation stuff,
it'd be nice if autogsdoc could be able to group
methods into alphabetically sorted groups
so set/ret methods could be near each other etc...
while yeah i understand this would require extra
markup

heres some stuff i noticed when running my app with
Camaelon which needs work on the -gui side of things

summary: 
a) switch button image affects themes
b) i'm lazy and don't think i should have to have 2
images with opposite colors for switch buttons in
columns and table column header..

my typical extra long explaination:
background: app with a table view, with lots of
columns of switch buttons each column has a specific
non-checkmark image as the switch button 'on state'
and the table column header image.

common_{SwitchOn,SwitchOff}.tiff are used in place of
drawing the image inside the button...

attempting to use a normal button with an image and
you get a button the entire size of the column not
centered in it,

i believe that NSButtonCell should be respecting
NS*ControlSize and switch buttons should be of
NSSmallControlSize button type and draw centered in
the cell frame, if the frame is larger than the set
control size.

then common_SwitchOff.tiff can just go away

because currently when theming my app the switch
button image has to be created with the switch button
background.. switch themes and it looks gross 

similar issue with NSTableColumnHeaderCell where our
table column header background color is dark, and the
control color is light

so i need 2 images, one for the table column header
image (light with no background), and one for the
switch button dark with a switch button background...

on macs/openstep the colors aren't so different and
switch button images don't contain the switch button
frame/bezel style, so you can use the same image for
both...

other random stuff,
i'd also like to see lots of graphs
not just class diagrams, but stuff like state diagrams
of events coming out of the backends and how they're
handled by various controls for example...


NSCell's working better outside of their various views

can't think of anything though...
matt




                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com