williams_ui_layout.pdf (application/pdf Object)

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.
- posted by techgurufloyd @ 2/19/2005 10:38:00 AM 0 comments

 
udk: UNO Development Kit Project

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.
- posted by techgurufloyd @ 2/05/2005 02:45:00 PM 0 comments

 
Why "Silver Onion"?

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)
- posted by techgurufloyd @ 2/03/2005 05:22:00 PM 0 comments