Hi Bartosz, On Wed, Nov 16, 2011 at 10:24 AM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote: > > Come on did You even read it?? This function is OBEX level (an it > works before in similar way - only one dir at a time) - we may don't > like specification, but seriously? Just read the patch, i exposed on > OBEX level stuff defined in the OBEX specification (as MAP needs > operation like "go one level up and than down" in one step) and as it > would be possible to just add some "if" for "../dir" in previous > version, but it is better to fix broken things than to propagate them > (it's obex level function not high level abstraction - deal with it). Yeah, lets create an API that we don't use, really? Your MAP API need it but that doesn't mean we agree on using it as it is, that table you use to explain how it works is already a sign that it is over-engineered and will be easily misinterpreted by applications. We will not break MAP by not exposing this complexity since we can still do it transparently, even doing cdup and another SetPath although inefficient would still work. > Each profile may use it multiple times for paths delivered through > dbus (but it provokes some questions, that i don't like). Generally > there is REALLY many gui that works like that (one level down or up at > a time) just look around (eg all file explorers) and it's all you > need, because its basically same context! Same context? What context, the folder listing is per folder, besides nowadays the file explores have abandon the tree view in favor of more simple one level like nautilus. But even with gui that uses tree view we can only jump one level or to the root so it is not that it would save that much of time. -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
