On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET
<[email protected]> wrote:
> Hi,
>
> Just some thoughts reading this ...
>
>
> 2014-04-16 14:48 GMT+02:00 [email protected] <[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.
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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
