I have committed on master this afternoon a first step, it is now possible to select the width of each panel column (in the panel wizard and in the page elements section of the administration).
It works with both Flamingo & Colibri. Guillaume 2014-04-24 14:00 GMT+02:00 Denis Gervalle <[email protected]>: > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
