16 Apr
2014
16 Apr
'14
5:02 p.m.
On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET
<jeremie.bousquet(a)gmail.com> wrote:
Hi,
Just some thoughts reading this ...
2014-04-16 14:48 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
Hi Marius,
On 16 Apr 2014 at 13:11:34, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
wrote:
hehe ;)
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, ...). 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@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
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 :). 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).
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <
>> > mariusdumitru.florea(a)xwiki.com>gt;:
>> >
>> >> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs