Re: [Openrocket-devel] Getting the next release out

[Kevin R. <kr...@su...>]

Hi Sampo,

Sorry, I've been distracted building rockets and designing a new club 
controller.


On 2/3/2013 3:06 AM, Sampo Niskanen wrote:
> Hi,
>
> It's again been too long since a release, and there's a bunch of stuff
> going on in the integration branch.  Let's try to figure out what we
> need to get the next release out.
>
>
> Decals - looking good.  I'm not sure what the state of the refactoring
> is that Kevin was doing.  We need to get at least the file format and
> UI in the desired state.
I've tried to remove DecalRegistry and DecalImage but to no avail. I was 
not happy with the resulting functionality.  I have an uncommitted 
change which makes DecalImages no longer Attachments which actually 
cleans the code up a bit.

Also, we need to pocket Doug's file watcher code since I've implemented 
something simpler.  We might want that in the future, but right now it's 
no longer used.
> Decals UI - look good, I can fine-tune it a bit more.

One thing I've noticed which is kind of weird, is when you press the 
"edit" (decal) button in the component details dialog, the details 
dialog remains open.  I think it maybe should be closed when you press 
that button.  Honestly, it doesn't really matter to me either way.

> Default visuals - looks nice, though the textures could do with a bit
> of touch up.  How much logic is in there already?  My idea was to have
> most of the built-in decals as mostly transparent decals that are
> applied on top of a solid color.  If there's sufficient logic to have
> a solid color plus texture I could make these textures.  (Can someone
> photograph/scan a sufficiently large piece of balsa for me?)
>
> Flight configurations - I'm working on the UI.  The data structure
> needs refactoring, but that can wait until after a release.

Can you refresh my memory about the refactoring?  Is it so components 
can have multiple independent configurable items?

What are you going to do with the UI?

> Lower stage simulation - we now have a model for the lower stage
> simulation that should be implemented.  Volunteers?

Most of the easy work is already done in the tumble recovery branch.  
The only changes needed are to compute the Cd correctly. There was some 
discussion about changing the conditions when it moves to tumbling as 
well - I think it was adding some bound on pitch.

> Example menu vs. dialog - opinions on this one?  I personally use
> ctrl+shift+O quite a lot during testing, though I guess it should be
> possible to bind that without having a menu item for opening the
> dialog.  Or I just learn to use the menu instead.

I prefer the cascading menu because it allows me to select an example 
with two clicks.  We could map the c-s-O to the cascading menu and see 
if that makes you happier as well.

> Simulation plot dialog - I think we must have an option of selecting
> the region where to zoom to.  More   often than not, the interesting
> content takes up 100% of the Y sca le but only 10% of the X scale.
> Laptops are very common these days so the alt-mouse wheel for X-zoom
> only is a poor substitute.  I also find the free panning a bit
> irritating, can we at least limit panning to within the X-range,
> possibly both X and Y?

The right click drag also zooms.  Basically the direction you move the 
mouse determines how it zooms.

You can zoom x-axis only, by using alt-key with the "zoom in" button.

Do you want some kind of mechanism to select the zoom area?  click & 
drag a bounding box maybe?

I think we can clamp the pan pretty easily.

Let me know what keys/buttons you want to do what.

> I think the lower stage plots should include the portion of the
> primary FlightDataBranch prior to separation, otherwise they seem very
> detached (this is "nice to have", not "must have").  Also since we're
> not coloring the lower stages in different colors I'd revert the
> legend to the original (i.e. just "Altitude", "Vertical velocity"
> etc), currently it's just too cluttered.

I guess most of the time you don't use "show data points".  When you use 
show data points, then the different stages use different symbols and 
the multiple legend entries make sense.  Should I look into using 
different line types - solid, dashed, dotted, etc?

I'll try to add the main data in.  shouldn't be that hard.

Kevin

> Testing - we need to poke around and try to get rid of obv





> ious bugs.
>
> Something else - what else has been modified?
>
>
> Unfortunately we need another hardening time.  After this let's take a
> strict feature-branch policy, so that we can pull ready features in
> independently.
>
>