Re: [xwiki-devs] [Proposal] Improve our Panels technology

+1 for B, it seems the most natural one in the end.

Thanks -Vincent On 23 Apr 2014 at 17:37:04, Guillaume Louis-Marie Delhumeau (

> Hi. > > Your arguments make sense. Actually, we had other options in mind: >

> > It seems, regarding your answers, that the variation B is better than

> current proposal. > > The variation B consists on developing only one panel which is the > "AppBar", or more certainly the "Favorite Applications Panel" + an

> to configure it instead of using the panel wizard. > > We still need to add an option about the size of the panels bars, but

> 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 < > > mariusdumitru.florea(a)xwiki.com&gt;gt;: > > > > > 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 vincent(a)massol.net : > > > > > > > >> Hi Marius, > > > >> > > > >> On 16 Apr 2014 at 13:11:34, Marius Dumitru Florea ( > > > >> mariusdumitru.florea(a)xwiki.com(mailto:

> > )) > > > >> wrote: > > > >> > > > >> > On Tue, Apr 15, 2014 at 4:54 PM, vincent(a)massol.net wrote: > > > >> > > Hi Marius, > > > >> > > > > > >> > > On 10 Apr 2014 at 21:07:13, Marius Dumitru Florea ( > > > >> mariusdumitru.florea(a)xwiki.com(mailto:

> > )) > > > >> wrote: > > > >> > > > > > >> > >> On Thu, Apr 10, 2014 at 6:08 PM, Guillaume "Louis-Marie" > > Delhumeau > > > >> > >> wrote: > > > >> > >> > > > >> > >> > But developers already needs to create a UI Extension,

> > a > > > >> panel? > > > >> > >> > > > >> > >> Because for the panel you'd have to write code.. Moreover,

> > > >> > >> discussed about the fact that the non-typed parameters of

> > > >> > >> Extension are not always a good idea and that for the

> > > >> > >> 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

> > The > > > >> > >> second would have to take the image from a property in

> > > to > > > >> > >> the developer: he has to specify the application icon. The

> > > is > > > >> > >> not, without reading documentation about what to write in

> > > >> > >> application bar. > > > >> > >> > > > >> > >> > Maybe we should provide a template for this kind of

> > > >> > left side that has icons on it, most of which seem to

> > > >> > fact that the left thin vertical bar (to not call it AppBar)

> > > >> > panel bar is just an implementation detail for me. > > > >> > > > >> In this case you’re saying that implementing the AppBar as

> > > panels > > > >> is bad idea (i.e. it’s not natural) and the AppBar should be a

> > > don’t > > > >> agree about having apps provide their panels. Agreeing about

> > 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

> > > >> needs to define it as they have always done (see blog app for

> > > >> > > > > >> > We're talking about the left side, the thin vertical bar. The

> > will > > > >> > want to put an icon on it, not a panel. A panel is just the

> > of > > > >> panel. The idea is to still call Panels the panel technology.

> > just > > > >> adding panel sizes. > > > >> > > > >> Again if you don’t agree about having panels provided by apps

> > > need > > > >> to materialize the AppBar by having it as a specific Panel (and

> > > if > > > >> they wish. If you don’t agree with this (which is fine) then

> > > >> should not be implemented as panels IMO and instead we should

> > > >> > shortcuts on the left side. > > > >> > > > >> Not quite. App shortcuts can be anywhere: on the left, on the

> > in > > > 2 > > > >> columns or in 1 column. It just happens that by default we’ll

> > > 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

> > panel, > > > >> > but we should make app devs a favor by simplifying this 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

> > 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

> > it > > > >> Favorite Applications Panel and keep the existing Applications

> > to > > > >> list all apps). > > > >> > > > > > > > > Both could be just variants of the same Panel adjusting to the

> > > 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

> > choose > > > > their "favorite apps", and group the rest in the "..." or "other

> > > > shortcut (which it currently does except it doesn't use the

> > > > "favorite"). Basically both represent a list of links to

> > > > available in 1-click, along with a list of other applications

> > > in > > > > 2-clicks, both available from any page (panel concept). > > > > Another example: if this "thin panel column" / "AppBar" is a set

> > > > specific (distinct) Panels that you can order as you want with

> > > > wizard, it means you can put some other completely unrelated

> > > > between those applications panels (like a stats panel, a toc

> > ...). > > > > > > > Nice and flexible, but does it mean anything in terms of UI ?

> > > > 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

> > > >> > what we are missing is the ability to 'configure' the panels.

> > > >> > now you can add a panel only once (and even if you add it

> > > >> > going to display the same thing). But what if I create a

> > > >> > panel, that has some parameters, and I would like to add this

> > > >> > twice, with different values for the parameters. I can't. But

> > > >> > think, you can do this with wiki macros. I can call the same

> > > >> > with different parameters in the document content. Moreover,

> > > >> > the current panels are not easily reusable, for instance if I

> > to > > > >> > display the same thing inside the document content or in a

> > panels > > > >> > as wiki macros. With this, we can use directly the wiki macro

> > > >> > Guillaume is going to use right now in a panel. > > > >> > > > >> So you mean removing PanelClass/Sheet/Template (i.e. remove the

> > > of > > > >> panels or have it only mean the left and right areas) and

> > > >> someone wants to write a panel they need to write a wiki macro?

> > 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

> > 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

> > > 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

> > should > > > > never duplicate your code. > > > > > > Yes, this is the solution. > > > > > > > I suppose in most cases with this principle, you would never

> > > because I > > > > think you can almost always find a use-case where it'd be

> > to > > > > put any panel content in a dashboard gadget or somewhere else. > > > > But I suppose also it was not like that because initially (maybe

> > > the > > > > idea was more to be able to include a Panel everywhere you want

> > for > > > > Statistics for example). But being able to include a content

> > > > rendering macro wherever you want (in a Panel, in a gadget,

> > page level (a page that could contain a Panel, dashboard gadgets, or

> > can set access rights on (until you add access rights to objects or

> > calls ;) ). A dashboard gadget is just something that wraps a macro

> > with additional layout info (column/row), I imagine a panel could be

> > the same way. But you can also write any specific content in a

> > gadget (some groovy script, some velocity script, several macro

> > and it's the same for a Panel. It's just an UI thing with a content

> > 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

> > more into "improving existing panels" (not just technology). > > Another example (that is listed in the proposal btw), if you

> > day you improve Panels technology so you can display a horizontal

> > and not just vertical, and you want to implement something very

> > panel technology to be able to zoom a panel (and move the others

> > 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

> > panel technology by itself, to implement any variation of AppBar -

> > only inputs you need are "the info from app descriptors" whatever it

> > be. > > > > > > > > > > Thanks, > > > Marius > > > > > > > > > > > > > > >> > > > >> Thanks > > > >> -Vincent > > > >> > > > >> > Thanks, > > > >> > Marius > > > >> > > > > >> > > > > > >> > > Thanks > > > >> > > -Vincent > > > >> > > > > > >> > >> The dev should just fill an > > > >> > >> application descriptor and then the App Bar manager (panel

> > > or > > > >> > >> whatever) should create a panel on the fly (if that is

> > > the > > > >> > >> underlying implementation) to display the icon/shortcut on

> > the > > > >> app > > > >> > >> >> bar. What I don't like is asking application developers

> > > write a > > > >> > >> >> panel (boilerplate code) in order to have their

> > 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

> > an > > > >> XClass > > > >> > >> >> > (with properties for app name and icon). Then the

> > > (XWiki, > > > >> Panel > > > >> > >> >> > Wizard, whatever) should use these data (app name and

> > to > > > >> build > > > >> > >> >> > and UI that lets the user put shortcuts to his

> > > to > > > >> a bar. > > > >> > >> >> > If you want, the system should create this "panel".

> > app > > > >> > >> >> > developers to write this boilerplate code to have

> > > >> listed is > > > >> > >> >> > not nice. > > > >> > >> >> > > > > >> > >> >> > Thanks, > > > >> > >> >> > Marius > > > >> > >> >> > > > > >> > >> >> > On Thu, Apr 10, 2014 at 4:17 PM, Guillaume

> > > >> Delhumeau > > > >> > >> >> > wrote: > > > >> > >> >> >> Hi. > > > >> > >> >> >> > > > >> > >> >> >> After some discussions with Caty and Vincent, we

> > > to > > > >> propose > > > >> > >> >> you > > > >> > >> >> >> new ideas about the panels technology, that replaces

> > > >> previous > > > >> > >> >> >> propositions about the Flamingo Applications Bar. > > > >> > >> >> >> > > > >> > >> >> >> The proposal is there, with more explanations and > > > screenshots: > > > >> > >> >> >> > > > >>

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs