launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

On 16.02.2010 06:36, Karl Fogel wrote:
> For all of you following bug #255868 (which is about linking to the new
> "+patches" view from the web UI), some questions:
> 
>   * Do you like the two screenshots I just posted at
>     https://bugs.edge.launchpad.net/malone/+bug/255868 ?
> 
> Then these next two questions are for Abel or Tom Berger or some other
> more experienced Launchpad developer:
> 
>   * In the latter of the two screenshots, you see how a popup comes up
>     showing the details of the patch (this works the same way as in the
>     +patches view itself).  However, for some reason, in the new branch
>     [1] there's a bug whereby you can't move the mouse pointer into the
>     popup because it pops down too quickly.  I remember we had the same
>     problem when developing the +patches view, and we solved it, but
>     looking over the code (see r8961 in db-devel) I can't figure out
>     how.  What am I missing?

IIRC there must not be a gap between the area of the link that lets the
popup appear on the mouseover event and the area of the popup itself. In
this the case, the popup disappears when you move the mouse towards the
popup area, as soon as the pointer leaves the area of the link.

We might consider to hide the popup window 0.5 or 1 second after the
mouse pointer left the link area, and to prevent the hiding if the
pointer is over the popup area at that time.

I suspect that we either have something like this already for other
popups or that other popup windows would benefit from such a delayed
hiding as well. In the latter case, we should implement this in a
separate branch, I think.

> 
>   * I told the portlet to sort the bugtasks by latest_patch_uploaded,
>     and that definitely had an effect -- but it's strangely a little
>     off.  As you can see in the screenshots, two recent patches are
>     reversed according to their upload times, even though sorting *did*
>     cause them two go to the top of the list when they hadn't been at
>     the top before.  How can a sort be "almost" working?

This is odd. Can you check the values of Bug.latest_patch_uploaded of
these bugs and of Message.datecreated of the related attachments?

Or... Did you add something like "?orderby=importance" to the request
URL? From your branch:

+    def latestPatchTasks(self, quantity=5):
+        """Return <quantity> bug tasks that have patch attachments.
+
+        Order the results by patch attachment age, starting from
youngest."""
+        orderby = self.request.get("orderby", "latest_patch_uploaded")
+        return self.context.searchTasks(
+            None, user=self.user, order_by=orderby,
+            status=UNRESOLVED_PLUS_FIXRELEASED_BUGTASK_STATUSES,
+            omit_duplicates=True, has_patch=True)[:quantity]
+

So, the _default_ sort order is latest_patch_uploaded, but you can
override it.

But you use the data returned by this method for the main page of an
IProduct, which shows several other listings, so, a general query
parameter "orderby" is ambiguous: Why does it affect only the patches
listing, but not the "latest bugs" listing or the latest questions?

I think you can simply use
searchTasks(orderby="latest_patch_uploaded",...) -- sort options for the
main page of a project are not really necessary.

Abel