Re: GNUstep Window Manager (was RE: Idea)

[Nicola Pero]

> Further, when I compare the results of GSBench (on a 400MHz PII with  
> an ultra fast graphics card) to those of NXBench (25MHz m68k) I get  
> just scared...;-)

Are you sure this comparison is fair as it is ?  We have an additional
layer, X, and X is very slow itself.

Moreover, are you sure it is meaningful ?  Personally, the evidence is
that for my normal work the gui is quick enough.  If you show us an
interesting program which is unusable because the gui is too slow, we
could change our priorities.  But I won't work on the speed of the backend
just because you are telling me the figures say it's slow.  If it is,
fine, I don't care, for me it's quick enough.

> > A complete gui demo/suite with loadable bundles, a complete front
> > end to ping/finger/traceroute, a calculator, a utility to set the
> > keyboard modifiers of gnustep, a complete board table game, a
> > utility to slow down my system.
> 
> Those are all simple apps in terms of UI (only basic widgets are used).

I have to understand that by 'basic widgets' you mean:

- images (tiff, png, jpeg, gif)

- text in arbitrary combinations of fonts and colors

- hboxes and vboxes and complex tables with total automatized control of
  sizing and positioning 

- boxes with no border, simple border, bezel border, groove border, 
  title up, down or no title etc 

- complete browser widget with tons of options

- buttons (images, text, text + images, alternate images and alternate 
           texts, all kind of borders, all kind of possible behaviours; 
           mixed states, key equivalents; autosizing; etc)

- clipview, cells, controls

- color objects accessible by name, by RGB, by any other space

- fonts, font manager to convert and modify fonts on the fly; 
  configurable system fonts etc;

- matrices of buttons, including radio buttons, different kind of mouse
  tracking and policies, autosizing etc;

- menus (detachable submenus, key equivalents, menu popup on right click 
         on a window, automatic updates of menu entries etc);

- cut, copy and paste of text (including pasting to/from external X apps);

- save panel (title, prompt, file type, treat file packages as
  directories, possibility of adding a custom view, keyboard navigation
  etc)

- open panel (same as the save panel + selection of multiple files, etc)

- popup-menu buttons, pullsdown-menu buttons (...)

- scrollviews (...)

- sliders (...)

- table views (interacting with the scrollview; with or without corner view 
  and/or header view, including selection of columns or rows, resizing of
  columns, editing of cells in the table, with or without grid, grid
  color, putting any image or text in arbitrary fonts etc inside the table
  using cells etc)

- textfields (including validation, notifications, keyboard navigation 
  between text fields etc)

- forms (including automatic synch of the sizing of the multiple entries
  keyboard navigation etc)

- standard info panel (...)

- view objects, creation of view subclasses simply by implementing
  drawRect: etc

- autoresizing, flipping, arbitrary coordinate transformations, etc

- windows with or without titles, borders, close buttons, resize; 
  support for that in most X window managers etc;

- nearly everything can autosize and can be encoded/decoded into binary
  files at run-time.

I probably forgot many other - but except the big text view, everything
which you find in an advanced widget set is *here working now*.  In that
respect, I have to understand that for you *everything* in an advanced
widget set is just a `basic widget'.

When I say it's enough for my UI needs is because I can't think of a
widget which is missing, except the rich text editor.

If you want to build composite or more complex objects, it's extremely
easy.  The design and the API are made to make that incredibily easy.

But these composite objects are not and will not be part of the library.  
We won't add a spreadsheet-application-widget to the library just because
everything else for you is a `basic widget'.

> But as it seems, unlike for you, for me it is not enough to have simple UI  
> frontends for tools like finger or ping in order to say 'it's  
> perfectly usable'.

But it's enough to have all the widgets you need to write any UI app you
like to say that it's `usable'.

> Performance (and stability) is probably the most important issue  
> besides a working text system. And again, I do not talk about the  
> drawing speed for basic widgets here! Thus I really would like to  
> look into libart to solve that problem, perhaps I can find some more  
> spare time somewhere...

Could you please tell me why are you talking about `stability' here ?  
Did you get a gui crash ?  If so, why don't you send us a bug report.  As
far as I know, it's a *very* long time I don't see a gui crash reported -
nor I can generate one - so I was assuming things were stable enough.