User:Mafm

Personal Information

• Name: Manuel A. Fernandez Montecelo
• E-mail/GoogleTalk: manuel.montezelo
• IRC nickname (freenode network): mafm
• SourceForge username: mafm

GSoC (Google Summer of Code) 2008

• Project: OpenGL GUI Framework
• Example for interaction: http://brlcad.org/design/gui/ioe_proto_final.mov , recommended by Sean
• Another example in the form of a real program: wmii (Plan9 window manager) ( http://www.suckless.org/wiki/wmii ), recommended by Sean

Milestones

Milestones include (maybe some of them to be added or removed, to be discussed with the mentors and the community in general):

• Get logging working
• Get console working
• Being able to communicate with the back-end
• Displaying geometries
• Displaying various representations (wireframe, polygonal, etc)
• Rotating and positioning
• Input support (trackball, shift-grips)
• Clean cross-platform build system integration

ToDo

[2008-07-01 20:30:08]
<brlcad> should work on improving/finishing that build system integration some more too ;)
[2008-07-01 20:31:28]
<brlcad> saving users the need to hunt/download is only a small piece of the reason for including the deps, it should build them if it doesn't find a suitable system version
[2008-07-01 20:32:04]
<brlcad> also, your cmake files presently assume pkg-config, that shouldn't be assumed
[2008-07-01 20:32:13]
<brlcad> (nor required)

[2008-07-01 20:34:38]
<mafm> I'm no expert in building systems, but that could take weeks :S
[2008-07-01 20:35:39]
<mafm> "but" is alias to "but I think" and "because of that" at the same time :)

[2008-07-01 20:35:45]
<brlcad> I don't think anyone here would call themselves a cmake expert :)
[2008-07-01 20:37:03]
<brlcad> it is something that needs to happen earlier rather than later given this tool is intended to become pretty fundamental eventually
[2008-07-01 20:37:37]
<brlcad> minimally document the need somewhere (TODO), but poke on it when you can

[2008-07-01 20:37:56]
<mafm> but I could spend much time with it and miss the milestones with gsoc

[2008-07-01 20:39:14]
<brlcad> i understand, that doesn't change the pressing need for it ..
[2008-07-01 20:39:23]
<brlcad> the longer it's ignored, the harder it will be for whomever does try it
[2008-07-01 20:39:57]
<brlcad> it's part of coding complete
[2008-07-01 20:40:22]
<brlcad> if the build doesn't work cleanly, it's not really usable yet to most of our devs

[2008-07-01 20:40:45]
<mafm> I see

[2008-07-01 20:41:47]
<brlcad> e.g. I can't imagine bob readily being willing to futz with three different build systems plus pkg-config, cmake, and scons
[2008-07-01 20:42:29]
<brlcad> we're used to *zero* effort unless you want to change away from defaults
[2008-07-01 20:43:49]
<brlcad> it's not top-priority in front of the milestone tasks, but it's probably #2 or #3 to have a default-functioning build system regardless of system deps

[2008-07-01 20:44:22]
<mafm> that's fine, but I don't think that it's in the scope of the project to rework whatever building system the dependencies decide to use

[2008-07-01 20:44:38]
<brlcad> so at least document it is what I'm saying, maybe work on it if you take a break from coding

[2008-07-01 20:44:41]
<mafm> especially being an experimental project

[2008-07-01 20:45:38]
<brlcad> fyi, I don't see this as an experiement -- a prototype, sure .. but one with an exceptionally high probability of becoming the foundation for a new GUI
[2008-07-01 20:46:26]
<brlcad> you'd have to mess up in several big ways for it to be wasted effort :)

[2008-07-01 20:47:36]
<mafm> it seems to me that you're relaying on somebody with a weak knowledge of building for such a foundation :P

[2008-07-01 20:48:15]
<brlcad> not relying, just don't want you to blow it off entirely as not your problem
[2008-07-01 20:50:02]
<brlcad> wasn't saying drop what you're doing to work on it, just keep it in mind and poke on it when you can .. and document where things are at

Log

July

July 17:

• Some commits correspond to work of yesterday.

July 16:

• Changing private Observer/Listener pattern implementation in CameraManager by the one already existing in the project
• Setting limits to orbital camera mode, so it doesn't cause strange artifacts when verticalRotation is greater than PI/2 (or smaller than -PI/2).
• More work done but sourceforge's SVN has been unavailable due scheduled downtime -- some commits delayed for next day.

July 15:

• Commited first serious code for handling camera, instead of the old hacks. It's the orbital mode, which it's very similar to the trackball mode (rotates around central the point of the scene, changing zoom distance and horizontal/vertical rotation), but it happens that I understand this well so it goes first.
• Thinking about how the other modes would be implemented, by extending the actions of the current camera mode.

July 14:

• Still working in camera implementation, but unfortunately not much since I got sidetracked by job interviews.
• In the meanwhile, after talking with developers, scraped the idea of having a window for camera control, since: 1) it doesn't seem to fit into the "ideal operating environment" to have a small window present just for this, and 2) the basic camera modes should mimic what BRL-CAD uses already know, so no much point in making a visible interface for controlling it. There might be place for something in the top-panel showing camera mode and so on, maybe.

July 11:

• Started to work in proper Camera controls implementation.

July 10:

• Adding methods for basic camera manipulation. I'm waiting for confirmation from other devels, but I think that the proper thing to do is to create one or several camera modes with better and more complete functionality, encapsulated in a proper way.
• Adding GeometryConversion class, and modifying the "create geometry" command so we can create at least sample tetrahedrons.
• Screenshot after a few days:

July 9:

• Trying to get manually-made geometries displayed in the window, with no successful results in the whole day. As I figured out later, it's not enough to create them as vertices list inside ManualObject, but it has to be created with indices so it can be made a Mesh, and then instantiate an Entity and add it to the SceneManager. And nowhere where they clearly tell you this. Pheeeeew.

July 8:

• Using another approach for building 'src/other': creating the rules in a way that if some of the external libraries fails to build, the whole process stops (suggestion of Dawn Thomas). Hopefully I got it right this time...
• Trying to create geometries, which in fact I think I do, but I can't visualize them...

July 3:

• Continued working on automatic compilation of external dependencies (Ogre remained with some problems). Finally got all of them working smoothly in my system; but this will only happen for certain systems -- probably only GNU/Linux and at most FreeBSD; and some manual intervention for MacOSX.
• Writing instructions about building, so hopefully with both of these issues "resolved" we will get more people willing test it.

July 2:

• Working on automatic compilation of external dependencies (src/other, like Ogre or RBGui). This includes:
  • To create a Makefile in there with rules to automatically compile/install those libraries
  • Creating CMake files in Mocha (so SCons is not needed)
  • Modifying CMake files for RBGui so no ".svn" files are installed in the system
  • Creating pkg-config files from CMake files in Mocha and RBGui so no static external files are needed (and as a consequence now it uses CMake variables for choosing the destination of the installed files, in example).
• This work should mean a step forward in the desired direction, but it's not very well tested and most certainly it won't work right away for non-modern-Unix systems.

July 1:

• Moving basic window creation, operations and settings to base class, so we abstract and protect a bit more the code from the GUI libraries that we're using underneath. Other general enhancements: making public-accesable attributes read-only (const) in the Observer events, decoupling a bit more functionality of the Console from the widgets implementing it, etc.
• Adding a couple of commands (quit, set log level); enhancing the command display (help), and the flexibility to show information about commands themselves.
• Improvements to Logger class: checks when setting new level so it's a correct one, made it a ObserverSubject so other classes can attach and receive interesting events (e.g. the Console, to show also the log messages in there).
• Substituted private Listener implementations for the more general Observer pattern, so we'll [hopefully] have less hassles when adding/modifying code in the future. The update() operation in the Observer is event-based, and the events are subclassed and identified by RTTI -- so we only need to create new types of events and program the reaction to them by the observers, no need to touch the rest of the code.

June

June 30:

• Working to create the Command Interpreter (to use in conjunction with console-like windows), still a work in progress.

June 27:

• Mostly revisiting the code created so far (and commiting minor enhancements and fixes here and there), testing the features and preparing a bit the next steps (loading geometry and so on).

June 26:

• Creating buttons in the top toolbar to quit the application and toggle visibility of console and command overlay.
• Enhancing usability and consistency of Command and Console, such as focusing the prompt and closing command overlay automatically with each command entered.
• Disabling keyboard and mouse grabbing in X11, so it doesn't disturb the user too much in the case of program hangs and the like (OIS defaults are really annoying).
• Fix of many small glitches, doxygen documentation, cleanups and renamings for consistency.
• Starting to look into Ogre geometries.
• Screenshot of the Day:

June 25:

• Usability enhancements to CommandOverlay and Console, such as sharing history and commands of CommandOverlay being reflected in the Console panel. Screenshot:
• Spent half the afternoon investigating and fixing a problem with Ogre Singleton intantiations. It turns out that their implementation allows you to create objects from classes which are Singletons, and that kinds of cause weird problems.

June 24:

• Working on the implementation and redesign of many things in the GUI front (see screenshot for visual reference: ):
  • New Window Manager class, to act as high level decision-maker about layout; and things like taking into account created windows (and deciding which ones to show in taskbar), so I think that "assimilates" the Taskbar class too, and thus I removed it as separate class.
  • New panel in the top, which will be used for context operations, setting fullscreen modes and things like that.
  • Created new Command Overlay, separated from Console (but probably would collaborate and share a common history, etc)
• Working "toggle Fullscreen" functionality
• Making Application and GuiWindowManager classes a Singleton, so they can be accessed from elsewhere without having to pass pointers around all the time (it's needed for the "toggle fullscreen" functionality, in example).

June 23:

• Watching again the video about "ideal interaction", for inspiration and to create a list of ideas to implement. I would like to have a chat about this though, to see the differences that we need to apply to our program.
• Starting to implement a taskbar, to mimic the interaction shown with the video. Screenshot:

June 20:

• Finished commiting OGRE (lots of hours spent seeking mime-types to meet SVN hooks' requirements), and also commiting Mocha and RBGui and brief, rudimentary building instructions.

June 19:

• Starting to commit 3rd party libraries needed for all this to work: OGRE and OIS. Only OIS could be commited, at last.

June 18:

• Sidetracked by work and bureaucracy, couldn't do almost anything.

June 17:

• Preparing and uploading RBGui files (theme, shaders, images, fonts), OGRE config files are to be generated on the fly (they contain paths depending on installation options).
• Getting the current code to compile with CMake in a clean fashion (without hardcoded system, in example). I think that it's a good base and a very important step.

June 16:

• Take wmii (Plan9 window manager) ( http://www.suckless.org/wiki/wmii ) as a guide when designing the console (recommended by Sean)
• Trying to get the project to build with CMake

June 14:

• Creating Logging functionality.
• Starting to look into putting data files in place, creating a proper build system and all that.

June 13:

• Looking into ideas to implement the User Interface.

June 12:

• More work in the Console, getting lines to wrap instead of being cut; and fixing RBGui (with several hours of reasearch involved) so autorepeat does use an initial delay and you can actually write individual characters (instead of 'aaaaaaaa' when you press the key for only 200ms). See the screenshot of the day:
• A bit of work reorganizing code, making Doxygen documentation, removing leaks (even if the objects only are to be removed when the application closes anyway) and the like.
• I wrote to RBGui guys to know if they're interested in patches to support at least my platform (Debian GNU/Linux, amd64 -- but at least Linux and POSIX systems by extension) instead of having to maintain private patches.
• I need ideas and directions about what things to implement (e.g. how to implement console window, if I should use logging from libbu or making my own method, for a start).

June 11:

• Today I continued working in the Console, now at least the history functionality and the way to create and position windows it is basically stable (can be changed easily, but I mean that it's not a hack-ish/example-ish application). Screenshot:
• OIS (the input library) is giving problems with auto-repeat, a problem that already had several years ago: it disables auto-repeat from X, so the rest of the applications in that DISPLAY that capability, and if the application crashes before OIS restores it, you have to reset it by hand. This looks unacceptable to me, but I haven't devised any solution yet.

June 10:

• Mostly working in the Console window & functionality, still quite a lot of work to be finished.

June 9:

• Still working in the example application, but now it looks much better -- documented, code style, reorganizing things, making cursor visible (wasn't there in the POSIX version at least)... Screenshot:

June 8:

• Getting RBGui sample application to work, reading "administrative" information of rt^3 module and in general preparing for submitting the code.
• Commiting first patches, it's basically the example application coming with RBGui.

June 6:

• Patching and recompiling other branches needed of some of the components, RBGui doesn't work with the most recent stable versions of OGRE right away.
• Investigating a bit about other GUIs, updates on the considered GUIs, etc; with no interesting results: things are basically the same as when making the application.

June 5:

• Compiling OGRE and OIS (input system, needed for most applications using OGRE), since latest stable versions are not available in Debian. No big hassles.
• Compiling Mocha, a library needed by RBGui with misc utilities (3D math and the like) -- found a source RPM with minor patches for GNU/Linux systems, again no big problems.
• Compiling RBGui... this one is not so easy. Some CMake config files have to be modified, at least for my 64 bit system; and it's not in sync with OGRE (it seems to use some special function) so it doesn't compile successfully, yet.
• Thought: I'm starting to be a bit worried about RBGui... by the time of the application they had very recent releases adding support for [at least] GNU/Linux systems, apart from Windows. Now, even if there seems to be people porting it to MacOS X too, the developers seem are mostly silent and inactive. In general, it seems that this complicates the ease of installation for BRL-CAD users, and thus RBGui seems less convenient now than a while ago...

June 4:

• Misc. preparations: compiling up-to-date BRL-CAD, re-enabling subscriptions to mailing lists, and checking the tools to use (OGRE, RBGui). Not a very productive day, but not so bad to be the 1st day after weeks of overworking and travelling... and at least it's a start!

June 3:

• Back to Lisbon, at last. Hopefully tomorrow I'll start coding!

May

May 26:

• SoC program starts :)
• Due to some personal problems and exam dates (as already noted when submitting the application) I couldn't start coding or submitting patches to get commit access, note sure if I'll be able to start before June 5th or so.