Latest revision |
Your text |
Line 25: |
Line 25: |
| | | |
| = ToDo = | | = ToDo = |
− |
| |
− | == To finish GSoC ==
| |
− |
| |
− | <pre>
| |
− | [2008-07-25 17:01:58]
| |
− | <brlcad> okay, so requirements
| |
− | <brlcad> hooking in to the back-end in *some* fashion is definitely one to do so
| |
− | you can display real stuff
| |
− | <brlcad> libged has enough for that to be doable now, but your app isn't
| |
− | supposed to talk to libged directly, it's a bad coupling
| |
− | <mafm> so I could introduce a class simulating network layer?
| |
− | <brlcad> *delete* *delete* *delete* .. heh, yes
| |
− | <brlcad> doesn't even have to simulate it, on the app side it could be a network
| |
− | layer using libpkg, but then you'll need to stuf in a server layer that
| |
− | minimally hooks into libged too
| |
− | <brlcad> you could do it without the network communication, but the danger there
| |
− | will be that it really needs to avoid polluting any data types across into the
| |
− | front end
| |
− | <mafm> yes, I mean that the app could call this layer, and this layer bind
| |
− | directly to libged
| |
− | <mafm> and when the network libs are complete, to use them instead
| |
− | <mafm> but the rest of the front-end wouldn't be affected
| |
− | <brlcad> okay, so that sounds like the start of a plan
| |
− |
| |
− |
| |
− | <brlcad> the other bit I'd like to get a better feel for before gsoc ends is
| |
− | rbgui customization
| |
− | <brlcad> i.e. how easy it is to 1) customize the appearance (theme it or
| |
− | otherwise change how it looks) and 2) add a new control widget (e.g. say you
| |
− | want a rotating progress indicator)
| |
− | <brlcad> if that's a huge deal, then rbgui probably isn't a good framework to go
| |
− | with since the design requirements require a lot of custom interactions and
| |
− | appearance
| |
− | <brlcad> somewhere in there is how layout can be controlled too
| |
− | <mafm> rotating progress indicator?
| |
− | <mafm> the camera coordinates at the moment?
| |
− | <brlcad> finally, the last item making sure input controls are "done" .. not
| |
− | just 90% -- I can redo the entire build system really easily if needed, I can
| |
− | redo the libged binding easily, can work on logging/console, etc .. but there's
| |
− | a higher 'expense' to follow how input control works so that part should be near
| |
− | "done" for the two styles
| |
− | <mafm> I have been working in something like that (as a window with components,
| |
− | not a new widget), but I scraped it because in IOE it doesn't seem to be place
| |
− | for smallish, floating windows
| |
− | <brlcad> that's because it shouldn't be a smallish floating "window" .. it
| |
− | should be a control that can go onto a given context
| |
− | <brlcad> just as an example, say you wanted to draw a simple spinner progress
| |
− | indicator, like http://www.tmssoftware.com/Images/acp.png down on one of the
| |
− | buttons or on the top status bar or elsewhere
| |
− | <brlcad> i'm not saying do that particular control, but need to be able to
| |
− | evaluate how hard it is to write new controls (so maybe try that one)
| |
− | <mafm> contexts are minimum half of the window size?
| |
− | <brlcad> i have a fairly straight-forward sense for how hard that is roughly
| |
− | with cegui, for example
| |
− | <brlcad> little to no idea how hard that will be for rbgui
| |
− | <brlcad> hm? minimum half? (no)
| |
− | <mafm> in example in IOE, when dragging parts of the greeting card
| |
− | <mafm> one context was the sheet for the card, another half was the things to
| |
− | put in there (would be like primitives in our case)
| |
− | <mafm> IIRC :D
| |
− | <brlcad> yeah, that was a separate (temporary) context/panel
| |
− | <brlcad> how much space those take up is content-specific and
| |
− | application-specific
| |
− | <brlcad> but yeah, could hold primitives in our case
| |
− |
| |
− |
| |
− | <brlcad> the last bit I'd add would be to actually do a binary release
| |
− | <brlcad> for at least one platform
| |
− | <brlcad> for developers
| |
− | <brlcad> (to check it out)
| |
− | [2008-07-25 17:44:33]
| |
− | </pre>
| |
− |
| |
− | == About building system ==
| |
| | | |
| <pre>[2008-07-01 20:30:08] | | <pre>[2008-07-01 20:30:08] |
Line 166: |
Line 92: |
| | | |
| = Log = | | = Log = |
− |
| |
− | == August ==
| |
− |
| |
− | August 24:
| |
− | * Submitting final evaluation survey, and sending e-mail to the developer mailing list with the summary about the work done and future.
| |
− | * Screenshot: http://brlcad.org/~mafm/g3d-screenshots/brlcad_rbgui_20080824-1.png
| |
− |
| |
− | August 20:
| |
− | * (In trunk) Bug fixing: not using argv[0] when argc<1, it tends to be crashy ;) (it happened to me when trying to use the library). I did some minor normalization in other commands, initializing the result and so on, hopefully I didn't introduce new bugs due to poor understanding of the way it works.
| |
− | * (In trunk) Remove '#if GED_USE_RUN_RT', Sean did the same yesterday in libged but not here, so now it won't compile.
| |
− | * Fixing the commands in g3d using libged -- finally they are using the library correctly and libged is not crashing improperly.
| |
− |
| |
− | August 19:
| |
− | * Fixing libged commands, now they at least give some result and mostly work.
| |
− | * Using program-wide data structures for libged, instead of on-demand ones for testing until now.
| |
− |
| |
− | August 18:
| |
− | * Official "Pencils down" date.
| |
− | * I was trying to get my commands using libged working, but no luck so far and no tangible code worth to commit.
| |
− |
| |
− | August 17:
| |
− | * Adding a couple of new commands using libged, but still not properly working (I don't know if it's my fault or libged's)
| |
− |
| |
− | August 15:
| |
− | * Moving Command base class to a separate file
| |
− | * Preparing CMake files for using BRL-CAD library
| |
− | * Adding a new command to start to use libged (more to come, but I'm having some issues)
| |
− |
| |
− | August 11/12:
| |
− | * Preparing binary package so more people can test it. Unfortunately they're only for GNU/Linux amd64, since my personal laptop got screwed and I cannot install new systems in the computer at work. The packages are in: http://brlcad.org/~mafm/g3d-packages/ , some other libs are necessary in order to get it running: libfreeimage, libCg etc; easily available from your favourite distro or the Intertubes.
| |
− |
| |
− | August 8:
| |
− | * Working in the camera control window, fixing some of the remaining problems
| |
− | * Revisiting part of the code, removing some comments not applicable anymore and doing a bit of cleanup.
| |
− | * Starting to prepare a binary package.
| |
− |
| |
− | August 7:
| |
− | * Perfecting the taskbar, now it works much more closely to the Ideal Operation Environment (IOE, see my wiki page for the video) that we take as ideal interaction model
| |
− | * Enhancing custom widget with a label and the numerical progress (useful at least when testing)
| |
− | * Several other minor changes related with this.
| |
− |
| |
− | August 6:
| |
− | * After a few days of weekend and relax visiting friends and family, came back to work.
| |
− | * Adding methods to CameraMode to retrieve the relative rotations, so (in example) they can be shown in windows
| |
− | * Continued working with the custom widget. It's not easy since it seems that some of the brush methods don't work (in example to draw lines), so I changed the strategy to use a kind of slider instead of a "pie" to represent the rotation.
| |
− |
| |
− | August 1:
| |
− | * Creating icons for camera control buttons
| |
− | * Enhancing camera modes by adding bindings for actions in the camera control window, and binding actions in camera control window with camera modes -- some previous code needed some modifications to get this working fine.
| |
| | | |
| == July == | | == July == |
| | | |
− | July 31: | + | July 24: |
− | * Working in the custom window and camera control, commiting code even if it doesn't work very well.
| |
− | | |
− | July 30:
| |
− | * Saving the state of camera rotations before dragging, so they continue to rotate from the current position instead of starting from scratch (for both Blender and MGED modes).
| |
− | * Working in creating a new window to control the camera, including the creation of a custom Widget (as requested by Sean, to test how easy it is to achieve that with RBGui), but results not ready to commit yet because there are lots of glitches (images not showing in buttons when they should, etc).
| |
− | | |
− | July 29:
| |
− | * Fixing day :)
| |
− | ** Fixing the problems with zooming in orthographic mode with minimum hassle, using some of the capabilities of OGRE (instead of previous trials modifying view matrices and so on). It works as expected with all current camera/input modes.
| |
− | ** Fixing the problems with panning when controlled by keyboard (currently for Blender Camera mode only).
| |
− | ** Fixing the problems with panning when controlled by mouse (currently for MGED/Shift-grips Camera mode only). In the end it was very simple, but only once we got the relative dimensions of the camera and we're working in orthogonal projection mode.
| |
− | | |
− | July 28:
| |
− | * Adding support for different projections: orthogonal(orthographic)/perspective. Putting the control of Perspective/Orthogonal projection types in the CameraManager, so it's independent of the Camera/Input Modes (MGED, Blender, etc).
| |
− | * When in orthogonal projection mode there's no concept of zooming, every object is projected with real size on the screen; so I started to look into how to emulate this by using view matrices and things like that.
| |
− | | |
− | July 25:
| |
− | * Screenshot: http://brlcad.org/~mafm/g3d-screenshots/brlcad_rbgui_20080725-1.png
| |
− | * Working on perfecting MGED (Shift-grips) mode
| |
− | * Talking with Sean for quite a long time about mid-term evaluation, some new goals (making binary release, working in making some widget control) and stressing some things (more polishing), etc -- main things reflected in ToDo section
| |
| | | |
| July 23: | | July 23: |