24 Apr
2014
24 Apr
'14
2 p.m.
Agreed, +1 for B.
On Wed, Apr 23, 2014 at 6:10 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, Apr 23, 2014 at 6:40 PM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
+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 (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
> Hi.
>
> Your arguments make sense. Actually, we had other options in mind:
>
http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsi…
>
> 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 <
> > mariusdumitru.florea(a)xwiki.com>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:
mariusdumitru.florea(a)xwiki.com
> > ))
> > > >> 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:
mariusdumitru.florea(a)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 :).
> > > >>
> > > >> 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 <
> > > >> > >> > 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