Editing User:Mafm

From BRL-CAD

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 29: Line 29:
  
 
<pre>
 
<pre>
[2008-07-25 17:01:58]
+
[2008-07-25 17:01:58] <brlcad> okay, so requirements
<brlcad> okay, so requirements
+
[2008-07-25 17:03:35] <brlcad> hooking in to the back-end in *some* fashion is definitely one to do so you can display real stuff
<brlcad> hooking in to the back-end in *some* fashion is definitely one to do so
+
[2008-07-25 17:03:59] <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
you can display real stuff
+
[2008-07-25 17:05:38] <mafm> so I could introduce a class simulating network layer?
<brlcad> libged has enough for that to be doable now, but your app isn't
+
[2008-07-25 17:06:00] <brlcad> *delete* *delete* *delete*  .. heh, yes
supposed to talk to libged directly, it's a bad coupling
+
[2008-07-25 17:07:08] <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
<mafm> so I could introduce a class simulating network layer?
+
[2008-07-25 17:08:00] <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
<brlcad> *delete* *delete* *delete*  .. heh, yes
+
[2008-07-25 17:10:21] <mafm> yes, I mean that the app could call this layer, and this layer bind directly to libged
<brlcad> doesn't even have to simulate it, on the app side it could be a network
+
[2008-07-25 17:10:44] <mafm> and when the network libs are complete, to use them instead
layer using libpkg, but then you'll need to stuf in a server layer that
+
[2008-07-25 17:10:54] <mafm> but the rest of the front-end wouldn't be affected
minimally hooks into libged too
+
[2008-07-25 17:11:44] <brlcad> okay, so that sounds like the start of a plan
<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
+
-- the other bit I'd like to get a better feel for before gsoc ends is rbgui customization
rbgui customization
+
[2008-07-25 17:12:33] <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> i.e. how easy it is to 1) customize the appearance (theme it or
+
[2008-07-25 17:14:01] <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
otherwise change how it looks) and 2) add a new control widget (e.g. say you
+
[2008-07-25 17:14:16] <brlcad> somewhere in there is how layout can be controlled too
want a rotating progress indicator)
+
[2008-07-25 17:16:00] <mafm> rotating progress indicator?
<brlcad> if that's a huge deal, then rbgui probably isn't a good framework to go
+
[2008-07-25 17:16:12] <mafm> the camera coordinates at the moment?
with since the design requirements require a lot of custom interactions and
+
[2008-07-25 17:16:34] <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
appearance
+
[2008-07-25 17:17:10] <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> somewhere in there is how layout can be controlled too
+
[2008-07-25 17:19:31] <brlcad> that's because it shouldn't be a smallish floating "window" .. it should be a control that can go onto a given context
<mafm> rotating progress indicator?
+
[2008-07-25 17:20:32] <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
<mafm> the camera coordinates at the moment?
+
[2008-07-25 17:21:20] <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)
<brlcad> finally, the last item making sure input controls are "done" .. not
+
[2008-07-25 17:21:31] <mafm> contexts are minimum half of the window size?
just 90% -- I can redo the entire build system really easily if needed, I can
+
[2008-07-25 17:21:40] <brlcad> i have a fairly straight-forward sense for how hard that is roughly with cegui, for example
redo the libged binding easily, can work on logging/console, etc .. but there's
+
[2008-07-25 17:21:48] <brlcad> little to no idea how hard that will be for rbgui
a higher 'expense' to follow how input control works so that part should be near
+
[2008-07-25 17:22:10] <brlcad> hm? minimum half? (no)
"done" for the two styles
+
[2008-07-25 17:22:55] <mafm> in example in IOE, when dragging parts of the greeting card
<mafm> I have been working in something like that (as a window with components,
+
[2008-07-25 17:23:21] <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)
not a new widget), but I scraped it because in IOE it doesn't seem to be place
+
[2008-07-25 17:23:25] <mafm> IIRC :D
for smallish, floating windows
+
[2008-07-25 17:28:04] <brlcad> yeah, that was a separate (temporary) context/panel
<brlcad> that's because it shouldn't be a smallish floating "window" .. it
+
[2008-07-25 17:28:21] <brlcad> how much space those take up is content-specific and application-specific
should be a control that can go onto a given context
+
[2008-07-25 17:28:36] <brlcad> but yeah, could hold primitives in our case
<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
+
[2008-07-25 17:44:17] <brlcad> the last bit I'd add would be to actually do a binary release
<brlcad> for at least one platform
+
[2008-07-25 17:44:23] <brlcad> for at least one platform
<brlcad> for developers
+
[2008-07-25 17:44:26] <brlcad> for developers
<brlcad> (to check it out)
+
[2008-07-25 17:44:33] <brlcad> (to check it out)
[2008-07-25 17:44:33]
 
 
</pre>
 
</pre>
  
Line 166: Line 139:
  
 
= 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:
 
* Working in the custom window and camera control, commiting code even if it doesn't work very well.
 
  
 
July 30:
 
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).
 
* 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).
  

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)