Mailing List Research

Here we go, my very exhaustive (well it exhausted me at least) research into the gsl-dev mailing list:

gsl-dev 778 - How we might get some major help: play our cards right.

gsl-dev 703 - Excellent Glossary. Very useful distinctions between certain terms.

VCL pointers and processes/procedures to follow
gsl-dev 398 - Great possible parliamentary procedure I might choose to use parts of.
gsl-dev 855 - some things to keep in mind throughout creating this new layer
gsl-dev 861 - pointers on replacing vcl
gsl-dev 698 - Note about keeping VCL operational till everything is working. I'm kind of htinking, go through and try to remove a part of VCL see if we covered everything, if they're still dependencies or something doesn't look right we uncomment the section and find where we missed over and over and over.... nasty but worth it.
Current VCL info "vclNativeWidgetProposal"
Current VCL info "nativemenus"
Current VCL info "VCLClassHierarchyWindows"
Current VCL info "VCLClassHierarchyControls"
gsl-dev 1493 - This is a major argument as to why we are eliminating VCL.
gsl-dev 396 - This emphasizes the need of the Chrome toolkit vs the canvas toolkit, which BTW is what this is!

UNO / API info
I think I want a toolkit abstraction layer that will allow us to use any of these. It would be a standard API that OOo refers to and then this component would translate it to whatever API we want... Could be messy. I dunno yet. Said much more elegantly here:
gsl-dev 580
gsl-dev 688 - some previous work? has somone already created the UNO component? Am I up in the night?
gsl-dev 699 - Not sure this is how I'm thinking of making the abstraction layer. That'd be a little more complex.. but maybe not. Requires more investigation.
gsl-dev 700 - I still think we can use the UNO component... Good way to look at it though.
gsl-dev 180 - Optional UNO?
gsl-dev 178 - Some opposition to UNO with some suggestions as why... Good points on modularity (Widgets must be separate from rendering layer.) Note that I'm not going to be basing this on the rendering layer. Also has a lot of good links
gsl-dev 410 - A note on how we might be able to quickly develop the features we need in any toolkit, and let the upstream happen without us waiting for it.
gsl-dev 468 - warning on being slow (check gsl-dev 472 and gsl-dev 474 as well)

Features
gsl-dev 428 - Good list of requirements
gsl-dev 701 - Scriptability? hmm. Hadn't thought of that.
gsl-dev 1493 - We need a GUI Builder, and layout manager (NO FIXED POSITIONING!, though it might be nice to have that capability, except it might be abused, and over used... Why would we need fixed positioning?...)
WE REQUIRE DOCUMENTATION, DOCUMENTATION, DOCUMENTATION!
We need to be able to run this over the network, detecting what visual toolkit they are using... Not statically designed for a specific toolkit (ie don't make separate QT/Linux OOo and GTK/Linux OOo and X11only/Linux OOo. They all need to be included as dynamic objects.
I also think we need to be able to choose alternate toolkits on more than just linux. e.g. GTK on windows, X11 on Mac.
MAJOR: Need to make sure that the file parser doesn't croak when we use UNICODE (important for internationalization)
Work with any fontworks stuff... Needs more research
gsl-dev 410 - Vector graphic support???
gsl-dev 459 - Need to make sure the spell checking menu is taken care of with the toolkit (dynamic components). See the next line.
Human readable resource files (like say XML) with dynamic components, like the spell checker or recent file list. I don't think the spell checker will be all that configurable, just a special spell check menu with options like (word choices) a space and other explicit options, which could allow us to add other external spell, grammer checkers...
gsl-dev 508 - RTL text in the GUI??? I don't know a thing about how to go about this. Hardly a clue where to start. Ugh. More research needed.
Alpha icons
Speed
porting-dev 6835 - native L&F on mac
gsl-dev 443 - another good list of features
gsl-dev 492 - We need the API to be very flexible to allow outlandish featuers to be implemented without too much trouble. Perhaps an extensible API that can be extended with other UNO components (am I making any sense? would this actually work?)
Specification matrix developed for the "toolkit2" project that seems to have died.
dynamic layout manager!!!

Possible Toolkits
gsl-dev 404 - This is a very good explanation of WHY the chrome and the canvas are separated into two segments.
gsl-dev 406 - An alternate philosophy stating that the Chrome should be a sub part of the canvas... Hmmm...
gsl-dev 407 - Almost "mission statement" like for this project. To support everyone... Futher explanation is in gsl-dev 409
gsl-dev 411 - More mission statement like. multiple front ends on a single backend. That's the idea.
gsl-dev 397 - An opinion on why we should use GTK+, QT, or Swing, or emulating toolkits.
gsl-dev 326 - Opinion on using bitmap pushing, esp on X11. Maybe, maybe not. But I don't think so for OS X. with a counter to that in gsl-dev 327
gsl-dev 431 - Good description of the alternative types of toolkits we can use with some benefits and deficits to each. - I don't think we should do exactly one of these. see next line.
gsl-dev 434 - The quote in here mentions a combination of emulate and wrap. But I think it's more of a combination wrapping the "common denominator" and implementing platform specific for the rest, and where a platform *does not have* something, then we emulate. That's the ideal.
gsl-dev 440 - So my approach is basically the 'abi-word' approach. Good I have an example, maybe I'll download their code and see what I can learn from them.
gsl-dev 463 - We definately need ways for different toolkits to coexist (QT should be used on KDE, GTK on Gnome (I think, I might be wrong), MFC/Win32 on windows, Aqua/Quartz on Mac, whatever is used on solaris, plus allowing people to use QT or GTK on windows or mac or solaris where available.
gsl-dev 435 - Why native controls are my preferred method over emulation if at all possible (though I think there will be some emulation.)
porting-dev 6718 - A strong opinion on why not to use Native widgets
gsl-dev 217 - An opinion that we should emulate using native where possible pointing some of the arguments both ways especially pointing out the usefulness of emulation
gsl-dev 495 - examples of where emulation falls through but native is great.
porting-dev 6835 - Why a native L&F on mac is discussed here.
porting-dev 6729 - Legal issues with Mac themes on other platfoms, we would have to restrict any mac themes to the mac platform.
gsl-dev 350 - Some toolkits. I've commented on those toolkits below
GTK+ - Might work. Not native rendering though. Also, Mac port is pretty sad right now.
Swing - Java (see below) - Some arguments against it here: gsl-dev 410
Qt - Licensing problems but important for KDE
SWT - Java (see below) - Major garbage collection problems (see gsl-dev 373) - C++ implementation on sourceforge mentioned in gsl-dev 433
wxWindows - Established with [most of?] required features and lots of help (gsl-dev 6648) - Accessibility (a11y, I believe) not supported (see gsl-dev 367)??? basing our new API on wxWindows with a flexible rendering backend might be good as noted in gsl-dev 863
Fitz/AEkit - Where is this? GPL license problems - Very popular???
FLTK - Would work except for the lack of mac development
Java2D - Java (see below)
Mozilla (xpfe/XUL) - cross platform and works... with an argument against it in gsl-dev 410 ; gsl-dev 471 - They built on GTK?
WinAmp - Designed for WinAmp (not exactly general use though possible), might be able to use, themeable. Does it even support solaris or OS X? I don't think so.
CroPL - License problems, but works well on Mac, We might be able to work something out for OOo...
GnuStep - Cultural Clash. Not quickly developed.
enlightenment - gsl-dev
Custom Built - Lots of work suggested in gsl-dev 427
Anti-grain Geometry
FOX
others?

Some things that were suggested for layers, but I don't think should be for widgets
gsl-dev 432 - a bunch of canvas specific requirements
gsl-dev thread on the canvas
XRender
GGI
SDL
Fresco
Chaco plotting environment
Anti-Grain Geometry
Fitz
YAAF
Quesa
OpenRM
Agile2D - Java
Canvas Draw (CD)
VOGL
SRGP
GKS
Mesa
OpenGL
GD
GDK
Cairo (used to be Xr/Xc I believe)


Though Java is the first programming language I learned, I'm not too keen on using it because it's not as mature as C++ is, as well as a bunch of other reasons (proprietary language, etc.).
gsl-dev 479 - It's not a good idea to become dependent on Java.
gsl-dev 707 - Java definatly isn't mature. They've just redone a bunch of stuff in the latest version of Swing and AWT

Evaluation of Qt/GTK/Java2D Regarding Applicability as the New Graphics Core
"Low Level" API info especially in regard to X and Windows
proposal for the highly discussed "Toolkit 2"
Toolkit 2 presentation. - VERY USEFUL. Has a list of requirements/expectations. History, and vision.
Rendering Layer Initiative
Rendering Layer - Canvas API
Rendering Layer - Canvas Requirements Matrix
Rendering Layer - Meeting Minutes 2002/11/28

A bunch of specs on the UI
- posted by techgurufloyd @ 3/11/2005 06:47:00 PM