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 | ||
− | + | -- 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 |
− | + | [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 = | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== July == | == July == | ||
− | |||
− | |||
− | |||
July 30: | July 30: | ||
− | |||
* 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). | ||