Comment 1 Andre Klapper 2009-10-13 18:46:22 UTC

I'd LOVE to have this, it is possible already in the Addressbook.
Now everybody vote for this report please. ;-)

Comment 2 Andre Klapper 2009-11-02 17:22:56 UTC

*** Bug 5967 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> I'd LOVE to have this, it is possible already in the Addressbook.
> Now everybody vote for this report please. ;-)
> 

It is already implemented in hildon, as HildonLiveSearch. It is currently in
the way to be adopted.

(In reply to comment #3)
> (In reply to comment #1)
> > I'd LOVE to have this, it is possible already in the Addressbook.
> > Now everybody vote for this report please. ;-)
> 
> It is already implemented in hildon, as HildonLiveSearch. It is currently in
> the way to be adopted.

Is this going to be available to third party application developers as well?

I can find an example for it in the repos already:

http://maemo.gitorious.org/hildon/hildon/blobs/master/examples/hildon-live-search-example.c

In my case, I have already implemented a live search in my application (using
key-press-event on the TreeView to show a initially hidden HildonEntry, and
using a TreeModelFilter with visible_func set) - should I think about replacing
it with a HildonLiveSearch in the future, or is HildonLiveSearch just a
convenience class/widget to be used for adding live search behaviour to
non-searchable treeviews?

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > I'd LOVE to have this, it is possible already in the Addressbook.
> > > Now everybody vote for this report please. ;-)
> > 
> > It is already implemented in hildon, as HildonLiveSearch. It is currently in
> > the way to be adopted.
> 
> Is this going to be available to third party application developers as well?
> 
> I can find an example for it in the repos already:
> 
> http://maemo.gitorious.org/hildon/hildon/blobs/master/examples/hildon-live-search-example.c
> 
> In my case, I have already implemented a live search in my application (using
> key-press-event on the TreeView to show a initially hidden HildonEntry, and
> using a TreeModelFilter with visible_func set) - should I think about replacing
> it with a HildonLiveSearch in the future, or is HildonLiveSearch just a
> convenience class/widget to be used for adding live search behaviour to
> non-searchable treeviews?
> 

You can check both that example and also any touch selector example, to see it
in action.

It is of course public API, you can use it with any treeview.

*** Bug 6392 has been marked as a duplicate of this bug. ***

Comment 7 Quim Gil 2009-12-07 08:30:03 UTC

This is being treated by the Fremantle program more as a bug than as an
enhancement request.

(In reply to comment #7)
> This is being treated by the Fremantle program more as a bug than as an
> enhancement request.
> 

Then it's a design bug. I consider it almost offending to claim it's a bug when
it was never a requirement until a few months ago. At least, that's clear from
the UI design docs published in Forum Nokia [1].

[1]
http://www.forum.nokia.com/info/sw.nokia.com/id/019c2b31-3777-49a0-9257-970d79580756/Hildon_2_2_Widget_UI_Specification.html

Comment 9 Quim Gil 2009-12-07 12:01:33 UTC

I'm only making a reference to int-142952. Whatever happens there will bring
the resolution here.

*** Bug 5431 has been marked as a duplicate of this bug. ***

Comment 11 Tim Samoff 2009-12-07 17:35:19 UTC

I'd say that no offense should be taken from an enhancement becoming a bug at
some point -- that's just escalation, right?

In any case, the real bug lies in the fact that there is such cathotic
user-experiences between apps that should all act the same.

Comment 12 Tim Samoff 2009-12-07 17:37:38 UTC

s/cathotic/catholic (i.e., wide-ranging)

Comment 13 Andre Klapper 2009-12-16 17:14:49 UTC

*** Bug 7039 has been marked as a duplicate of this bug. ***

The severity should remain at "Normal", as this should be considered "a must"
throughout the UI, but ESPECIALLY(!) in the Application Manager. Also because
the list in the Application Manager is reset after a selected app has been
installed, so if you have installed an app starting with, say, the letter 'u',
and you're scrolling through a full app list covering bout extras,
extras-devel, and genereal dists, then you have to scroll all the way through
the list once more to get to the place where you left off. Tiring in the long
run... really, Nokia Maemo Development team - fix this!

(In reply to comment #14)
> The severity should remain at "Normal", as this should be considered "a must"
> throughout the UI, but ESPECIALLY(!) in the Application Manager. Also because
> the list in the Application Manager is reset after a selected app has been
> installed, so if you have installed an app starting with, say, the letter 'u',
> and you're scrolling through a full app list covering bout extras,
> extras-devel, and genereal dists, then you have to scroll all the way through
> the list once more to get to the place where you left off. Tiring in the long
> run... really, Nokia Maemo Development team - fix this!

Dude, read the comments before posting. As I said already, I fixed this in
hildon quite some time ago. No need for extra whining.

And the package was accepted internally yesterday and the internal bug verified
and closed. Closing this now.

In general you could make people less anxious if you can give them some clue
about when they might see the fix on their device. Most people have no idea of
Nokia's internal processes.

(In reply to comment #16)
> In general you could make people less anxious if you can give them some clue
> about when they might see the fix on their device. Most people have no idea of
> Nokia's internal processes.

I'm sure Nokia can do better about informing schedules, but that's about
general Nokia policies; I can't speak on behalf of them and this is not the
place to do it anyway. Talk to Quim or André.

I'm just trying to suggest how you might avoid people behaving in a way that
annoys you, despite what Nokia won't let you do. I mean well.

You said
"It is already implemented in hildon, as HildonLiveSearch. It is currently in
the way to be adopted."

It might help to say something like 
"
This is fixed by commit 1245 in hildon:
gitweblink

With the new xyz() function / it works automatically.

You'll see this improvement on your devices when Nokia releases an update for
the whole N900 system. (Maybe) However, this requires each application to be
modified to use this new feature, so it might not appear in all of them at the
same time.
"

Users need to be treated gently, like other wild animals.

Comment 19 Andre Klapper 2009-12-18 13:44:04 UTC

So....

This has been fixed in package
libhildon 2.2.8-2+0m5
which is part of the internal build version
2009.51-8
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

This is *not* fixed. Just because some version works behind a Nokia firewall
does not mean it is resolved. The problem is resolved when the public can
download a copy.

Re-opened.

Comment 21 Andre Klapper 2009-12-18 15:48:47 UTC

Please understand how our processes work. Closing. Thanks.

(In reply to comment #20)
> This is *not* fixed. Just because some version works behind a Nokia firewall
> does not mean it is resolved. The problem is resolved when the public can
> download a copy.

You can download a copy right now if you want:

  http://maemo.gitorious.org/hildon

No Nokia firewall preventing you from getting this and building your own
package. If you want Nokia to provide you official packages, now that's a
different story and you'll have to be patient and wait.

Comment 23 Andre Klapper 2010-01-12 22:33:24 UTC

(In reply to comment #19)
> This has been fixed in package
> libhildon 2.2.8-2+0m5
> which is part of the internal build version
> 2009.51-8

Looks like it's also fixed in 2.2009.50-0 ("PR1.1") if I got the cryptic
internal information right.

Comment 24 Andre Klapper 2010-01-14 12:28:20 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

(In reply to comment #24)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
> Please leave a comment if the problem is not fixed for you in this update
> version.
> 

I think you are wrong...

PR1.1 includes libhildon 2.2.3-1. The HildonLiveSearch widget was first
introduced in hildon 2.2.4 and was not accepted internally until hildon 2.2.8.

In fact, there are other bug fixes announced announced with PR1.1 that were
_not_ fixed by libhildon 2.2.3-1. To put it nicely, the list in
http://wiki.maemo.org/Maemo_5/PR1.1 is wrong for libhildon, and I wonder
whether is wrong for other components as well.

Comment 27 Quim Gil 2010-01-14 12:59:10 UTC

(In reply to comment #26)
> In fact, there are other bug fixes announced announced with PR1.1 that were
> _not_ fixed by libhildon 2.2.3-1. To put it nicely, the list in
> http://wiki.maemo.org/Maemo_5/PR1.1 is wrong for libhildon, and I wonder
> whether is wrong for other components as well.

The good news is that it's a wiki page open to corrections.  :)

Comment 28 Andre Klapper 2010-01-14 13:02:39 UTC

(In reply to comment #26)
> PR1.1 includes libhildon 2.2.3-1. The HildonLiveSearch widget was first
> introduced in hildon 2.2.4 and was not accepted internally until hildon 2.2.8.

Thanks for clarifying. As written before, the internal comments are not always
clear and Nokia is quite successful in confusing me sometimes.

> In fact, there are other bug fixes announced announced with PR1.1 that were
> _not_ fixed by libhildon 2.2.3-1. To put it nicely, the list in
> http://wiki.maemo.org/Maemo_5/PR1.1 is wrong for libhildon

If you have time for listing specific issues, feel free to drop me an email.
Afterwards I can correct and maybe rant at some folks if I find out that it
wasn't my fault that some stuff is wrong. :-)

(In reply to comment #28)

> 
> > In fact, there are other bug fixes announced announced with PR1.1 that were
> > _not_ fixed by libhildon 2.2.3-1. To put it nicely, the list in
> > http://wiki.maemo.org/Maemo_5/PR1.1 is wrong for libhildon
> 
> If you have time for listing specific issues, feel free to drop me an email.
> Afterwards I can correct and maybe rant at some folks if I find out that it
> wasn't my fault that some stuff is wrong. :-)

OK, I take that back. It seems that these are actually documentation issues
that were solved in the SDK documentation, not in the hildon one. So, for
hildon, that would be it. Still, I guess it's worth reviewing the list for
other components (I guess users will notice and complain anyway).

I just wanted to make this clear to avoid having more bashing on this issue
than what we already had from some extremely enthusiastic users :)

Comment 30 Andre Klapper 2010-03-15 20:53:38 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

Confirm fixed in PR1.2