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
