Silver Onion

PDF outline of API DB

2005-03-21T01:46:00.000-07:00

Well I made a diagram in OOo Writer of the DB I'm making for to store
all the API calls.

If this works, there will be a PDF attached to this post. If not, I'll
continue to search for a way to do so.

API database diagram

2005-03-17T18:30:00.000-07:00

OK, I finally found a place that I don't care about bandwidth. Download as much as you want. Here's my database diagram. Comments welcome.

diagram.pdf (application/pdf Object)

diagram.odt

API database

2005-03-16T16:50:00.000-07:00

I'm currently working on building a database where we can store all the API calls.
Quote from an e-mail to the discuss@OOo list (discuss thread ) describing what I'm doing:
==========================================
OK, I ended up staying up till 3 in the morning thinking about the
problem. This e-mail kind of queued me into where I need to go and I
think I finally understood relational databases, and how this relates
to my problem.

OLAP is for analysis of data, not inputing it, though I'd really love
to be able to do something like "inverse-OLAP" putting in the data, in
a way that makes sense, or in the same way we view it. Maybe if I'm
ever lacking in a project to complete I'll work on doing something
like that. Until then, i'll make do.

So I have developed a design for a relational database that meets my
needs. I found that with a relational database (after I figured out
what I was doing) I could add some of the extra info into the database
that would have seemed slightly out of place in my cube design, though
it is very easy to see how a cube still applies to alot of the data.
In the end, my design is a 12-14 table database (there are still a few
questions on how I want to deal with a category of information). It's
still got 4 dimensions, but I added several tables to further
categorize and deliminate some info on all my info. Once I've finished
putting it in digital form, I'll post a link to my desing, and a link
to the final interface as I will want help populating it.

My main table consists of a lists of IDs from 5 other tables
essentially creating the "Array" that was mentioned.

The purpose of this database? to create a central storage place easily
accessible to more than just me for all of the toolkit API calls for a
specific feature(widget) on a platform. So my 4 'dimensions', and
subsequently the 4 main tables linked into my main reference
'array'-like table are:
Platforms
Toolkit
Features
API

Also, I designed the beginning layout for forms for data-input (forms)
and data-output (reports). I definately want to be able to have people
help me fill in my database so I'm looking at creating a form in PHP
or something like that with a MySQL backend. Either that, or I simply
host the database and offer a Base file that interfaces with it so
that people can view/modify the data. Or I do both. I'm not sure how
to deal with user accounts though. I'm afraid to allow anonymous
access because I can't afford the time to de-spam this. But I want to
give anybody who wants to help, access. Suggestions?

For Silver Onion I will select a feature, get a list of all the API
calls for that feature, dividing into specific platforms where
necessary, and create a new UNO API layer that will translate an API
that I will define into the APIs of whatever toolkit happens to be the
preferred toolkit on that platform, with a user option to override and
manually select a toolkit. That's the purpose of this database. I have
a blog devoted to this project at silveronion.blogspot.com Note
however that I write the blog for me and I periodically cross post
what I post there into a mailing list if I need input on a decision or
on how to do something. (Also note, that I'd love to get other people
to help me. I'm working on creating some well defined parameters that
I can then present with a call for help in programming it, because
well, I'm not the best programmer.)

Thanks for helping me to think of this in every so slightly a
different light that makes it possible to complete!

Thanks,
Jacob

Mailing List Research

2005-03-11T18:47:00.000-07:00

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

gsl-dev mailing list research

2005-03-07T19:54:00.000-07:00

I've eliminated what used to be in this entry in favor of my updated next entry.
Cheers,
Jacob

wxwidgets has "XML-based resource system"... I wonder...

2005-03-07T19:35:00.000-07:00

XML-based resource system overview

I've briefly looked at wxwidgets as I've heard some people rave about how great it is. I'm not sure what has been said so that it hasn't been implemented. I'll have to look into that.

It looks to me like I might be able to create a small UNO component that creates a OOo specific API that is then translated to whatever 'backend' I give it. It might be wxWidgets, a 'home-grown' solution (which I'm hesitant to do based on how stagnated VCL has become, which is a home-grown solution), or some other solution. I'm going to make a diagram of how the basic architecture might work, I've done it on paper, now to just get around to putting it in a digital form...

More later.

williams_ui_layout.pdf (application/pdf Object)

2005-02-19T10:38:00.000-07:00

williams_ui_layout.pdf (application/pdf Object)

Oh way cool.

This outlines some of the stuff other people have worked out. It's a very good outline. Though I'm going to change the order a little bit I think.

I just heard something about OOo supporting XForms, and from what I understand XForms is a standard similar to XUL only made by the W3C. I was thinking about using XUL but there are some distinct benefits to XForms, like you don't have to use javascript.
This definately needs more investigation into XForms.

So what I think I'll do is this:

1) Finish reading Dev Guide to familiarize myself with UNO
2) Determine the file format for the UI files (Research XForms)

Once the file format is chosen:

3) Check for existing code that already supports importing the filetype
4) Create or adapt any required interface to parse the UI files.

I need to keep in mind as I'm doing this that this needs to be layout oriented, as the presentation mentioned, and can't be in binary format.

5) Create cross platform UNO control that will take the parsed data and pipe it to the rendering plugin for that platform
6) Will need to create some rendering plugins as I go.

I think I'll start with creating the following plugins, in approximatly tandem:

Mac OSX - AQUA/Quartz [Cocoa not Carbon]
Windows - MFC, I think... Need more research on what exactly this requires
Unix/Linux/Solaris - I think these use GTK or QT or other engines. Which one should I use initially, as I'm not going to develop for all of them. Just one per platform initially.

Why do I want to develop plugins for every platform as I go?
Because their event models are very different so I need to make sure that OOo can handle any event model whether it be Object Oriented as in OS X or procedural as in the rest. It can't be tied to

Also we need to include all of the basic components of OOo (e.g. Menus, Toolbars--Floating, Docking, outside doc window inside doc window--, Buttons, Dialogs, Preferences window in native manner, etc) See a little later for some ideas I'm toying with about all the widgets...

*All of the above should be developed so that it can be tested separate of the rest of OOo, a modular component if you will. So it only needs the interface components of OOo like for UNO, and XForms/XUL. The actual functionality of the buttons (like which button does what) should initially not come into play, as we only want to get the layout working _well_ first.

7) Create the GUI builder app, possibly integrating it with OOo to make it so people can customize things like the preferences dialog box.

8) Then we can work on recreating the OOo interface in the new UI files and assigning the functionality for all the components.

So we need to be able to recreate the interface within OOo without reloading OOo (like recreating the preferences dialog box).

One thiing I've been toying with is an OOo preference database editor that lists all the preferences and their values, kind of like either the regedit is for the windows registry, only this interface would need to be more intuitive sorting the preferences, searching them etc.

A new 'table', if you will, could be put in the preferences database that contains all of the text for every dialog box... except that then all the info wouldn't be located in the UI files, which is a possible problem. Maybe a way could be made where we can put the stuff in the files themselves and then later create some kind of function or something that would allow us to query a preference in the database. So for now I'll stick with text in the files themselves with the idea that the feature can be added later.

Another table we may need to add is something that would associate the button with the functionality. Perhaps a list of all the required functions (a list of all the possible menu items/buttons/check boxes) that associates that particular item, (identified by something like an ID number maybe, or possibly a namespace type thing (I'm not familiar with the intricacies of namespaces, but from what I've read it might be useful in a case like this...), with what it is supposed to do (e.g. the function that clicking the search button on the toolbar or the search menu item is supposed to bring up the search dialog box)
Then you have the UI files that contain the following:
Where in relationship to another component somewhere, does this component go (layout controls)
What text does this have on it (if any)
What icon is associated with this particular function or area (if any)
Any image associations of some kind
What type of object this is (menu, button, title,...)
The function that control is associated with (if any)
Any popup/tooltip information.
Associated shortcut keys
Tab order if needed
Anything else?

Anyway, something else to consider, as mentioned above, is how the widgets will work on different systems.
For example, on OS X we want the menu bar for every document to be the system menu bar (very important Apple User Interface) but in the other platforms we want the menu attached to the window of the document. To this end we should make everything 'detachable' so that in the file we can say that the menu is detached and then associate a special layout type that would put the menu in the apple system menu bar. Following this same train of thought, I think that it would be good if all the toolbars didn't have to be docked to the document window, but can be docked on the side of the screen space. I don't thinnk these detachable toolbars should be exclusive to only the mac though, as people may find it very useful to have all their toolbars along the edge of the screen with 2 or more documents sitting side by side sharing the same toolbars (or perhaps, simply making the toolbars positioned the same across windows, so that as you switch from one document to the other the toolbars don't jump all across tarnation.
Another thing we need to note is the different style for Mac OS X Preferences dialog box versus the pertty much unstandardized interface elsewhere. We want to support this interface where the preferences window isn't a window in itself but a modal type slide down thing on the active window. If you've installed any software on a Mac then think of the 'agree/disagree' modal dialog that pops up.

In case it wasn't noticed, one of my major focuses in doing this is to ensure that the UI can be rendered across all platforms including Mac, because if OOo looked like other Mac apps on the Mac, I could easily convince some schools to switch to OOo as it works on every platform they have (Mac/Win). That's about 500 machines per high school, 20-25 high schools in the district.

Comments welcome.

udk: UNO Development Kit Project

2005-02-05T14:45:00.000-07:00

udk: UNO Development Kit Project

Right now, I'm trying to figure out UNO. I think I get that it is an interface for everthing to communicate but it looks like it requires the network and I'm not so sure I want a UI to be dependent on the network... I need to learn more. I've sent a letter to the dev@OOo list. I hope I get an clear answer. I don't particularly fancy reading a 1000 page document for no purpose.

I'll have to wait for a response and do some other stuff while I wait.

~Jacob

EDIT: I got a response, and basically UNO 'networks' between OOo components, but doesn't use the traditional connotation network=ethernet. This is good :D, except for having to read the massive guide.

Why "Silver Onion"?

2005-02-03T17:22:00.000-07:00

This is kind of the test post to make sure everything's set up the way I want it.

Why did I choose the name "Silver Onion" for the development of the OpenOffice.org new chrome layer?

silver is kind of like chrome
onions have layers
the new chrome layer will probably consist of multiple layers of OS support, UNO controls, and config files, so the multi-layered onion fits the role.

so Silver Onion it is (If you want to abbreviate I think I'll use SILON = SILver ONion)