Agreed, +1 for B.
On Wed, Apr 23, 2014 at 6:10 PM, Marius Dumitru Florea < [email protected]> wrote: > On Wed, Apr 23, 2014 at 6:40 PM, [email protected] <[email protected]> > wrote: > > +1 for B, it seems the most natural one in the end. > > +1 as well. > > Thanks, > Marius > > > > > Thanks > > -Vincent > > > > On 23 Apr 2014 at 17:37:04, Guillaume Louis-Marie Delhumeau ( > [email protected](mailto:[email protected])) wrote: > > > >> Hi. > >> > >> Your arguments make sense. Actually, we had other options in mind: > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsiderationsabouttheBaritself > >> > >> It seems, regarding your answers, that the variation B is better than > the > >> current proposal. > >> > >> The variation B consists on developing only one panel which is the > >> "AppBar", or more certainly the "Favorite Applications Panel" + an > admin UI > >> to configure it instead of using the panel wizard. > >> > >> We still need to add an option about the size of the panels bars, but > we do > >> not need a panel per application anymore. > >> > >> If we all agree on this, I will start the implementation. > >> > >> Thanks for your help, > >> Guillaume > >> > >> > >> > >> 2014-04-16 18:14 GMT+02:00 Jeremie BOUSQUET : > >> > >> > 2014-04-16 17:02 GMT+02:00 Marius Dumitru Florea < > >> > [email protected]>: > >> > > >> > > On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET > >> > > wrote: > >> > > > Hi, > >> > > > > >> > > > Just some thoughts reading this ... > >> > > > > >> > > > > >> > > > 2014-04-16 14:48 GMT+02:00 [email protected] : > >> > > > > >> > > >> Hi Marius, > >> > > >> > >> > > >> On 16 Apr 2014 at 13:11:34, Marius Dumitru Florea ( > >> > > >> [email protected](mailto: > [email protected] > >> > )) > >> > > >> wrote: > >> > > >> > >> > > >> > On Tue, Apr 15, 2014 at 4:54 PM, [email protected] wrote: > >> > > >> > > Hi Marius, > >> > > >> > > > >> > > >> > > On 10 Apr 2014 at 21:07:13, Marius Dumitru Florea ( > >> > > >> [email protected](mailto: > [email protected] > >> > )) > >> > > >> wrote: > >> > > >> > > > >> > > >> > >> On Thu, Apr 10, 2014 at 6:08 PM, Guillaume "Louis-Marie" > >> > Delhumeau > >> > > >> > >> wrote: > >> > > >> > >> > >> > > >> > >> > But developers already needs to create a UI Extension, > why not > >> > a > >> > > >> panel? > >> > > >> > >> > >> > > >> > >> Because for the panel you'd have to write code.. Moreover, > we > >> > > >> > >> discussed about the fact that the non-typed parameters of > the UI > >> > > >> > >> Extension are not always a good idea and that for the > application > >> > > >> > >> panel a dedicated class would have been better (with typed > >> > > >> > >> properties). There is a big difference between having: > >> > > >> > >> > >> > > >> > >> icon: myIcon.png > >> > > >> > >> > >> > > >> > >> and > >> > > >> > >> > >> > > >> > >> content: > >> > > >> > >> #if ($panelWidth == "small") > >> > > >> > >> [[image:myIcon.png]] > >> > > >> > >> #else > >> > > >> > >> ## Display stuff as a list > >> > > >> > >> #end > >> > > >> > >> > >> > > >> > >> The first is semantic (data) and can be reused in other > places. > >> > The > >> > > >> > >> second would have to take the image from a property in > order to > >> > not > >> > > >> > >> duplicate the application icon, so more code.. The first is > clear > >> > > to > >> > > >> > >> the developer: he has to specify the application icon. The > second > >> > > is > >> > > >> > >> not, without reading documentation about what to write in > the > >> > panel > >> > > >> > >> content in order to have the application icon available for > the > >> > > >> > >> application bar. > >> > > >> > >> > >> > > >> > >> > Maybe we should provide a template for this kind of > panels so > >> > it > >> > > >> would be > >> > > >> > >> > very easy to create a new one, or a wizard that generates > it > >> > > easily? > >> > > >> > >> > >> > > >> > >> I find it awkward to ask the dev to create a panel in order > to > >> > > display > >> > > >> > >> an icon on the application bar. > >> > > >> > > > >> > > >> > > It would be awkward if that was the goal but it’s not :) > >> > > >> > > > >> > > >> > > >> > > >> > > There’s no notion of AppBar! > >> > > >> > > >> > > >> > Think as a user, you always ask me to do so :). > >> > > >> > >> > > >> hehe ;) > >> > > >> > >> > > >> > A user that sees the > >> > > >> > flamingo skin for the first time will notice a vertical bar on > the > >> > > >> > left side that has icons on it, most of which seem to > correspond to > >> > > >> > applications (features). He will never think those are panels! > The > >> > > >> > fact that the left thin vertical bar (to not call it AppBar) > is a > >> > > >> > panel bar is just an implementation detail for me. > >> > > >> > >> > > >> In this case you’re saying that implementing the AppBar as > several > >> > > panels > >> > > >> is bad idea (i.e. it’s not natural) and the AppBar should be a > single > >> > > Panel. > >> > > >> > >> > > >> For me either you agree about having each app provide a panel or > you > >> > > don’t > >> > > >> agree about having apps provide their panels. Agreeing about > having > >> > one > >> > > >> panel per app and then trying to autogenerate the panels seem too > >> > much a > >> > > >> tweak/hack to me and smell of a bad design. > >> > > >> > >> > > >> > > It just means that if an app wants to have a panel on the > side, it > >> > > >> needs to define it as they have always done (see blog app for > ex) :) > >> > > >> > > >> > > >> > We're talking about the left side, the thin vertical bar. The > app > >> > will > >> > > >> > want to put an icon on it, not a panel. A panel is just the > means by > >> > > >> > which the app is going to make the icon available for the user. > >> > > >> > >> > > >> The thin bar can be anywhere, on the left, on the right, for any > kind > >> > of > >> > > >> panel. The idea is to still call Panels the panel technology. > We’re > >> > just > >> > > >> adding panel sizes. > >> > > >> > >> > > >> Again if you don’t agree about having panels provided by apps > then we > >> > > need > >> > > >> to materialize the AppBar by having it as a specific Panel (and > thus > >> > > have a > >> > > >> custom UI to configure that AppBar). > >> > > >> > >> > > >> > > So if an App wants that its users to display a panel to link > to > >> > > them, > >> > > >> then they do the users a favour by creating such a panel for the > users > >> > > to > >> > > >> use. > >> > > >> > > >> > > >> > Again, the App doesn't want "to display a panel”. > >> > > >> > >> > > >> The app doesn’t want to display anything. It provides panels for > users > >> > > who > >> > > >> use to use them to be able to do so. They can provide a shortcut > panel > >> > > if > >> > > >> they wish. If you don’t agree with this (which is fine) then > shortcuts > >> > > >> should not be implemented as panels IMO and instead we should > have an > >> > > >> AppBar panel. > >> > > >> > >> > > >> > The App wants to > >> > > >> > allow the users to have a shortcut. In flamingo we display app > >> > > >> > shortcuts on the left side. > >> > > >> > >> > > >> Not quite. App shortcuts can be anywhere: on the left, on the > right, > >> > in > >> > > 2 > >> > > >> columns or in 1 column. It just happens that by default we’ll > position > >> > > them > >> > > >> on the left in one column. > >> > > >> > >> > > >> > So apps will want to have their shortcuts > >> > > >> > displayed on the left side. If what it takes to display a > shortcut > >> > on > >> > > >> > the left side is to create a panel then the App will provide a > >> > panel, > >> > > >> > but we should make app devs a favor by simplifying this as > mush as > >> > > >> > possible (eliminating the need of creating the panel and > >> > copy-pasting > >> > > >> > code is possible). > >> > > >> > >> > > >> Well you’re making a good point that Panels may not be the most > >> > natural > >> > > >> way to represent an app shortcut. I think I agree that it would > be > >> > more > >> > > >> natural to have an AppBar Panel (that can be configured with a > >> > specific > >> > > UI > >> > > >> to decide what apps it should display - Personally I’d prefer > calling > >> > it > >> > > >> Favorite Applications Panel and keep the existing Applications > Panel > >> > to > >> > > >> list all apps). > >> > > >> > >> > > > > >> > > > Both could be just variants of the same Panel adjusting to the > width of > >> > > the > >> > > > panel left/right area, what do you think ? > >> > > > Ie, with a "large" panel width, you would display what is in > >> > > "Applications > >> > > > Panel", with a "thin" panel width, you would display what would > be in > >> > > > "Favorite Applications Panel". > >> > > > I mean, the current "applications panel" could allow end-users to > >> > choose > >> > > > their "favorite apps", and group the rest in the "..." or "other > apps" > >> > > > shortcut (which it currently does except it doesn't use the > wording > >> > > > "favorite"). Basically both represent a list of links to > applications > >> > > > available in 1-click, along with a list of other applications > available > >> > > in > >> > > > 2-clicks, both available from any page (panel concept). > >> > > > Another example: if this "thin panel column" / "AppBar" is a set > of > >> > > > specific (distinct) Panels that you can order as you want with > panel > >> > > > wizard, it means you can put some other completely unrelated > Panels in > >> > > > between those applications panels (like a stats panel, a toc > panel, > >> > ...). > >> > > > >> > > > Nice and flexible, but does it mean anything in terms of UI ? > Would you > >> > > > ever want to do that ? I'm not sure ... > >> > > > >> > > Good point. Indeed I'm starting to think that having a Favorite > >> > > Applications Panel to handle the app icons is better than having a > >> > > panel for each icon. > >> > > > >> > > > > >> > > > > >> > > >> > >> > > >> > > Autogenerating panel would make this a special case and I’m > not > >> > sure > >> > > >> we need a special case here. > >> > > >> > > >> > > >> > While discussing with Guillaume in private, I end up realising > that > >> > > >> > what we are missing is the ability to 'configure' the panels. > Right > >> > > >> > now you can add a panel only once (and even if you add it > twice it's > >> > > >> > going to display the same thing). But what if I create a > generic > >> > > >> > panel, that has some parameters, and I would like to add this > panel > >> > > >> > twice, with different values for the parameters. I can't. But > if you > >> > > >> > think, you can do this with wiki macros. I can call the same > macro > >> > > >> > with different parameters in the document content. Moreover, > most of > >> > > >> > the current panels are not easily reusable, for instance if I > want > >> > to > >> > > >> > display the same thing inside the document content or in a > dashboard > >> > > >> > widget I have to either copy the panel content or write some > >> > Velocity > >> > > >> > code. For the future I think we should investigate implementing > >> > panels > >> > > >> > as wiki macros. With this, we can use directly the wiki macro > that > >> > > >> > Guillaume is going to use right now in a panel. > >> > > >> > >> > > >> So you mean removing PanelClass/Sheet/Template (i.e. remove the > notion > >> > > of > >> > > >> panels or have it only mean the left and right areas) and > instead when > >> > > >> someone wants to write a panel they need to write a wiki macro? > Thus > >> > in > >> > > the > >> > > >> left and rights areas, you’d configure the list of macros to use > with > >> > > their > >> > > >> parameters, similar to the {{gallery}} macro for images? > >> > > >> > >> > > >> This means we wouldn’t be able to list panels anymore, except by > >> > having > >> > > a > >> > > >> “Panel” category for all macros representing panels. > >> > > >> > >> > > >> Or do you mean having a {{panel}} macro that bridges PanelClass > >> > xobjects > >> > > >> and macros: > >> > > >> - keep PanelClass and pages having PanelClass xobjets as now > >> > > >> - {{panel reference=“Panels.Applications”/}} > >> > > >> - {{panel reference=“MySpace.MyPanelPage” > >> > > parameters=“param1=value1,…"/}} > >> > > >> - change the way we define the panels to display on the > left/right > >> > areas > >> > > >> by using this {{panel}} macro. For example by having a > >> > Left/RightPanels > >> > > >> page. > >> > > >> > >> > > >> ? > >> > > >> > >> > > > > >> > > > >> > > > Is it really a problem of panels architecture, or merely a > problem of > >> > > some > >> > > > lack of macros ? > >> > > > >> > > My "problem" was that we have two notions "panels" and "macros" and > I > >> > > thought that we can implement panels using macros. But we can't > >> > > because we cannot set rights on macro calls (a panel would be a > macro > >> > > call in a left/right side area). > >> > > > >> > > > If you want to put same content in 2 panels, or in a panel and a > >> > > dashboard > >> > > > gadget, to me it means that you miss a rendering macro because you > >> > should > >> > > > never duplicate your code. > >> > > > >> > > Yes, this is the solution. > >> > > > >> > > > I suppose in most cases with this principle, you would never > write any > >> > > > content in a Panel except a call to a macro with some parameters, > >> > > because I > >> > > > think you can almost always find a use-case where it'd be > interesting > >> > to > >> > > > put any panel content in a dashboard gadget or somewhere else. > >> > > > But I suppose also it was not like that because initially (maybe > still) > >> > > the > >> > > > idea was more to be able to include a Panel everywhere you want > (like > >> > for > >> > > > Statistics for example). But being able to include a content > through a > >> > > > rendering macro wherever you want (in a Panel, in a gadget, > inline in a > >> > > > page) seem more flexible. > >> > > > >> > > Yes, but you cannot set rights unless you bind the macro call to a > >> > > document. > >> > > > >> > > >> > Well you would set rights at the level of the container of the macro, > so at > >> > page level (a page that could contain a Panel, dashboard gadgets, or > just > >> > be a "plain" page), which anyway until now represent the finest level > you > >> > can set access rights on (until you add access rights to objects or > macro > >> > calls ;) ). A dashboard gadget is just something that wraps a macro > call > >> > with additional layout info (column/row), I imagine a panel could be > seen > >> > the same way. But you can also write any specific content in a > dashboard > >> > gadget (some groovy script, some velocity script, several macro > calls...) - > >> > and it's the same for a Panel. It's just an UI thing with a content > and > >> > some layout specificity / configurations. > >> > To go back to initial subject (sorry), I'd say that improving panels > >> > technology by adding the "size" parameter is very nice, the rest > falls back > >> > more into "improving existing panels" (not just technology). > >> > Another example (that is listed in the proposal btw), if you > implement this > >> > "AppBar" as a set of Panels containing App name + Large Icon, then if > one > >> > day you improve Panels technology so you can display a horizontal > panel bar > >> > and not just vertical, and you want to implement something very > similar to > >> > the nice "dock" of MacOS, you would have to rewrite all apps panels or > >> > create new ones (containing large icon without app name), and rewrite > your > >> > panel technology to be able to zoom a panel (and move the others > further) > >> > when hovered - and eventually add a specific typing of Panels so you > >> > activate this behaviour only for those who represent apps panels. > >> > While if you implement the "AppBar" as a unique Panel there is no > impact on > >> > panel technology by itself, to implement any variation of AppBar - > and the > >> > only inputs you need are "the info from app descriptors" whatever it > could > >> > be. > >> > > >> > > >> > > > >> > > Thanks, > >> > > Marius > >> > > > >> > > > > >> > > > > >> > > >> > >> > > >> Thanks > >> > > >> -Vincent > >> > > >> > >> > > >> > Thanks, > >> > > >> > Marius > >> > > >> > > >> > > >> > > > >> > > >> > > Thanks > >> > > >> > > -Vincent > >> > > >> > > > >> > > >> > >> The dev should just fill an > >> > > >> > >> application descriptor and then the App Bar manager (panel > wizard > >> > > or > >> > > >> > >> whatever) should create a panel on the fly (if that is > needed for > >> > > the > >> > > >> > >> underlying implementation) to display the icon/shortcut on > the > >> > > >> > >> application bar. > >> > > >> > >> > >> > > >> > >> Thanks, > >> > > >> > >> Marius > >> > > >> > >> > >> > > >> > >> > > >> > > >> > >> > > >> > > >> > >> > 2014-04-10 16:09 GMT+02:00 Marius Dumitru Florea < > >> > > >> > >> > [email protected]>: > >> > > >> > >> > > >> > > >> > >> >> To be clear, I'm not against reusing the left panels bar > for > >> > the > >> > > >> app > >> > > >> > >> >> bar. What I don't like is asking application developers > to > >> > > write a > >> > > >> > >> >> panel (boilerplate code) in order to have their > application > >> > > listed > >> > > >> > >> >> somewhere. > >> > > >> > >> >> > >> > > >> > >> >> Thanks, > >> > > >> > >> >> Marius > >> > > >> > >> >> > >> > > >> > >> >> On Thu, Apr 10, 2014 at 4:41 PM, Marius Dumitru Florea > >> > > >> > >> >> wrote: > >> > > >> > >> >> > I don't like it very much. Instead of writing code like > >> > this: > >> > > >> > >> >> > > >> > > >> > >> >> > #if ($panelWidth == "small") > >> > > >> > >> >> > ## Display stuff as icons > >> > > >> > >> >> > #else > >> > > >> > >> >> > ## Display stuff as a list > >> > > >> > >> >> > #end > >> > > >> > >> >> > > >> > > >> > >> >> > in a panel, I would prefer to describe my application > using > >> > an > >> > > >> XClass > >> > > >> > >> >> > (with properties for app name and icon). Then the > system > >> > > (XWiki, > >> > > >> Panel > >> > > >> > >> >> > Wizard, whatever) should use these data (app name and > icon) > >> > to > >> > > >> build > >> > > >> > >> >> > and UI that lets the user put shortcuts to his > favourite app > >> > > to > >> > > >> a bar. > >> > > >> > >> >> > If you want, the system should create this "panel". > Asking > >> > app > >> > > >> > >> >> > developers to write this boilerplate code to have > their app > >> > > >> listed is > >> > > >> > >> >> > not nice. > >> > > >> > >> >> > > >> > > >> > >> >> > Thanks, > >> > > >> > >> >> > Marius > >> > > >> > >> >> > > >> > > >> > >> >> > On Thu, Apr 10, 2014 at 4:17 PM, Guillaume > "Louis-Marie" > >> > > >> Delhumeau > >> > > >> > >> >> > wrote: > >> > > >> > >> >> >> Hi. > >> > > >> > >> >> >> > >> > > >> > >> >> >> After some discussions with Caty and Vincent, we > would like > >> > > to > >> > > >> propose > >> > > >> > >> >> you > >> > > >> > >> >> >> new ideas about the panels technology, that replaces > our > >> > > >> previous > >> > > >> > >> >> >> propositions about the Flamingo Applications Bar. > >> > > >> > >> >> >> > >> > > >> > >> >> >> The proposal is there, with more explanations and > >> > > screenshots: > >> > > >> > >> >> >> > >> > > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements > >> > > >> > >> >> >> > >> > > >> > >> >> >> Here is my +1. > >> > > >> > >> >> >> > >> > > >> > >> >> >> Louis-Marie > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
