On Wed, Apr 16, 2014 at 3:48 PM, [email protected] <[email protected]> wrote:
> 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).
>
>> > 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.
We wouldn't need a "Panel" category. Any macro can be displayed in a
panel (i.e. on the left/right side). Not all will look good of course.
>
> 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.
After more thinking I realised that we cannot remove
PanelClass/Sheet/Template because we need to be able to set rights on
panel documents, i.e. we need to use a separate document for each
panel, not just wiki macros called in a left/right side area
(document). I think I diverged too much from the topic :)
>
> ?
>
> 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
