[PATCH] Properly initialize device_data_t when downloading

[Tomaz Canabrava]

On Sun, Jun 16, 2013 at 1:37 AM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

>
>
> On Sat, Jun 15, 2013 at 6:07 PM, Tomaz Canabrava <tcanabrava at kde.org>
> wrote:
> >
> > Also, you said that the Cylinder / Weigth editions are worse than in GTK
> > version, can you describe briefely why ? - remind you that I never dived
> or
> > used the program before - I'm helping to the Qt Transition becaus I
> think is
> > fun to hack, but never really using the software means that I sometimes
> can
> > make a change that I think is for the best, and actually make things
> worse, I
> > can deal with that, It's easy to revert something and do in another way.
>
> So when I download a dive from a dive computer, the cylinders come
> pre-populated with the gasmix information and with the beginning and ending
> pressures (because subsurface gets all that from the dive computer).
>
> In the gtk version, I can *see* those pressures (they'll be grayed out
> when editing the cylinder information, though, because they are taken from
> the sample data):
>
> [image: Inline image 1]
> Hmm,. I also notice that the size is actually *wrong*. The size should be
> 80.0, and it is for my old dives where I picked "AL80". But for the dives I
> did today, when I used AL80, it filled the sizes incorrectly for some
> reason. Very odd.
>
> Anyway, in the Qt version, I can't see the pressures at all, and the units
> in the table hide the incorrect size:
>
> [image: Inline image 2]
>
> and quite frankly, I think the gtk version just looks better too.
>

This screenshoot show's me three bugs:
1 - '+' button out of place, it should be at far right
2 - start press and end press empty
3 - 'Type' field small to hold the combobox , and fixed size ( it wasen't
me that fixed, it used to be manually ajusted. )

will fix them tomorrow - woke up now with some shots being fired in my
street. lovely.


>
> But the real problem is when editing the cylinder type, which ends up
> being totally unreadable, because that type field doesn't have space for
> the different possible types, so I can't actually even see myself typing
> "AL80" at all.
>

This was introduced after I did the code - the behavior before was better,
but not much better - it was possible to manually adjust. the smaller size
should be the size of the biggest type, so you can see everything when
editing. will fix it tomorrow.


>
> AND to make matters worse: when I've typed AL80, and press enter, nothing
> happens. It doesn't actually fill in the size and workpressure fields at
> all - not until I switch focus to something else. Only at that point does
> it say "oh, AL80 means that the size is 80cuft, and has a working pressure
> of 3000psi" (if you're in metric, it will obviously look different - it's
> around 11 liters and 208 bar or something like that)
>

That's my 'oops.' ;)


>
> It's very odd. And it's definitely inferior both in looks and in behavior
> to the old gtk branch.
>

It will have the correct behavior on enter.


>
> The weight thing has similar issues, but because you don't have the "type
> -> size/workingpressure" thing, you don't see quite as much of a problem.
> But say you have something like this:
>
> [image: Inline image 1]
>
> and you want to edit that weight from 12 to 10, when I double-click that
> entry to edit it, it looks very odd, and very wrong. I can't screenshot it,
> because when it switches to the screenshot app, it "fixes" itself and
> becomes 0.0lbs because there is some focus-out callback..
>

0.0 ? that's model 'EditRole' bug, I may not be passing the correct values
to the edit role.


>
> I think the gtk approach actually worked better. Also, because of the
> (temporary, as Dirk tells us) lack of multi-dive editing, right now in the
> Qt branch you have to see this problem for every dive you do. Which is
> annoying if you're downloading all the dives of one day in one go (ok, so I
> only did two dives today, but even two was annoying and it could have been
> four or five).
>

I'll hold the Planner for for a few moments and fix all that as soon as I
wake up.


>
> But that multi-dive editing is a separate issue, it just brings the UI
> problems to the fore even more just because the lack forces you to see the
> issues multiple times.
>
> > Tomaz ( recovering from the police brutality )
> > -- side note, search for são paulo police brutality, quite fun pictures
> and
> > you can spot me in one or two.
>
> Not making much news here in the US. Not even news.google.com, which is
> usually better than the totally US-centric normal stuff.. In fact, after I
> decided that Sao Paulo was maybe too specific for US news, and searched for
> "Brazil" instead, all that shows me is soccer news. Only one bbc article on
> police brutality so far.
>
>
http://www.policymic.com/articles/48717/13-shocking-photos-of-brazilian-military-police-brutalizing-protesters-in-s-o-paulo


>                      Linus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130616/ed5ecb75/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 7684 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130616/ed5ecb75/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10779 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130616/ed5ecb75/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 15147 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130616/ed5ecb75/attachment-0005.png>