14 Oct
2016
14 Oct
'16
12:49 p.m.
+1 for your proposal until we have a better solution. I would avoid comment tab if ever
possible, since it increase the inconveniences already explained. I agree with almost all
other comments, but until we have time for something better, this proposal would be a
first improvement. We should just ensure it does not cause any regression.
--
Denis Gervalle
SOFTEC sa - CEO
On Fri, Oct 14, 2016 at 12:19 PM, Denis Gervalle <denis.gervalle(a)softec.lu> wrote:
+1 for your proposal until we have a better solution. I would avoid comment tab if ever
possible, since it increase the inconveniences already explained. I agree with almost all
other comments, but until we have time for something better, this proposal would be a
first improvement. We should just ensure it does not cause any regression.
--
Denis Gervalle
SOFTEC sa - CEO
On Thu, Oct 13, 2016 at 11:28 AM, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
2016-10-13 11:07 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
Some notes about the comments:
- @GD: In CkEditor when drag&dropping it doesn't open a file explorer
(that's for the simple upload), instead you just drag the image from
Desktop and it inserts it.
I think I was not clear. I know CKEditor does not a file explorer. But you
have to open that kind of application by yourself (in mac it's called
"Finder", on my laptop it's called "Nautilus") if the file you
plan to drag
is not on your desktop (which is the case 99% of the time). That is exactly
what I dislike.
- @Vincent: the inline editing approach (with keeping
the attachments tab
in the same location) doesn't work for cases when we hide the docextra: we
will have the same problem, and we might plan to remove that area for other
skins.
- @Thomas: yes this approach to have attachments tab in edit is problematic
because of the save and other js events, plus to me is still oldish.
So I don't want us to include the attachment tab in edit mode (although it
sounded as a nice option). Instead I would like at least to have an
improved drag&drop for CkEditor (improvement) and in the 'future' to
support drag&drop in wiki mode (new feature).
Thanks,
Caty
Thanks,
On Thu, Oct 13, 2016 at 10:47 AM, Thomas Mortagne <
thomas.mortagne(a)xwiki.com
Don’t leave
the view page when editing (ie. inline editing) and just
replace the view area by an edit area. And find how to display the page
syntax and include/display references in the UI.
valicac(a)gmail.com
would
permitted,
it,
to
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
wrote:
> Something is not clear to me. What is exactly going to happen in edit
> mode when you select an attachment ?
>
> If the plan is to let the attachment tab behave exactly as it does in
> view mode (which is to actually upload the attachment and save the
> document) I'm really not a big fan of this. If we support attachments
> in edit view it should not send anything until we click save.
>
>
> On Thu, Oct 13, 2016 at 9:41 AM, Vincent Massol <vincent(a)massol.net>
wrote:
> >
> >> On 12 Oct 2016, at 18:47, Guillaume Delhumeau <
> guillaume.delhumeau(a)xwiki.com> wrote:
> >>
> >> Just some remarks before I go:
> >> * As a developer, I always use the Wiki editor, and even for me it's a
> pain
> >> to go to view mode to upload a file (for example, an image in the
> release
> >> notes).
> >> * I never use drag&drop in whatever application I have. I have never
> liked
> >> it because it requires to open a file explorer specially for that and
> it's
> >> always a pain because I use applications in full size mode. I'm sure
I'm
>> not the only one so I'm not fond of
having it as the only way to
upload
attachments.
For the sake of the discussion, also note that there’s another option.
The nice part is that it 1) it saves a reload of the UI (good for perf)
and 2) it
feels more snappy and no context switching for the user (better
usability).
If you remember this was a proposal done a very long time ago by
Jean-Vincent
Drean (tried to find the thread again but didn’t succeed).
>
> Thanks
> -Vincent
>
>> Thanks,
>>
>> 2016-10-12 18:00 GMT+02:00 Ecaterina Moraru (Valica) < :
>
>> There are some problems with docextra, because it contains comments,
which
>>> are mostly needed in view mode, not in edit. So in edit mode, we need
>>> just some tabs from docextra. But I'm not sure that adding docextra
now
>>> will fix the underlying problem of
the issue.
>>>
>>> The issue was trying to fix the attachments uploading limitation of
the
>>
editor. The problem is that the editors (including CKEditor) are
>> advertising that they add images and not other file types. If users
want
to
>> add a PDF they might be confused.
>>
>> Ideally the users would just need to drag&drop a file and we would
insert a
>>> displayer depending on the dragged type (viewer for PDFs, gallery for
>>> multiple images, image macro for single image, etc.)
>>> Also even if in CKEditor the drag&drop option for images is >>
nobody knows about it. And currently CKEditor has the limitation to
allow
>>> dragging just images and not other types (dragging an image inserts >>> dragging a text file does nothing).
>>>
>>> Other thing to consider is that for Groupware flavor, where we
promote
>>> applications, we hide the docextra,
since this is not so relevant for
>>> application entries. Hidding docextra creates
>>> http://jira.xwiki.org/browse/XWIKI-13799 and
>>> http://jira.xwiki.org/browse/XWIKI-12993 .
>>>
>>> So, a conclusion: I'm not sure adding #docextra in the edit mode is
the
>>
best solution, especially since we try to make the interface more
simple
>> and we usually hide docextra also from
view.
>> An idea would be to better mark in the Edit mode that Drag&Drop is
>> permitted (at least for the CKEditor - the wiki mode will still have
the
>> same issue). Have a drag&drop
behavior also for other file types, not
just
>> images (for text files we could create a
link for the attached file,
etc.).
>> Plus have a link to manually go to the
attachments viewer as a backup
(by
>> fixing the 2 additional issues
mentioned). The problem will still
remain on
>>> wiki mode, but let's say those users are more advanced and know how
use
>>> viewers (although consistency between the edit modes would be ideal).
>>>
>>> Thanks,
>>> Caty
>>>
>>>
>>> On Wed, Oct 12, 2016 at 5:26 PM, Guillaume Delhumeau <
>>> guillaume.delhumeau(a)xwiki.com> wrote:
>>>
>>>> Hi.
>>>>
>>>> Currently a user have 2 ways to attach a file to a wiki page:
>>>> - in the attachment tab in VIEW mode only ;
>>>> - if it's an image, using a WYSIWYG editor.
>>>>
>>>> However, if it's not an image, you cannot add it while you're
writing
the
>>>> content. It's a bit as if you were not able to attach a file while
you
>>> were
>>>> writing an email... not user friendly!
>>>>
>>>> So we have this issue: http://jira.xwiki.org/browse/XWIKI-5400
>>>>
>>>> To fix it, I see 2 options:
>>>> - add the handling of attachments in edit mode.
>>>> - add *all* docextra tabs like we have in view mode (it's not
because
you
>>>> are editing a page that you don't need to see the history of the
page,
>>
nor
>>> the comments).
>>>
>>> But this might be not relevant for the class and the object editor.
>>>
>>> My proposal:
>>> * Display docextra tabs by default.
>>> * In class and object editors, set $docExtras = [].
>>> * Set $docExtras = [] in all sheets where we consider it's not
relevant
> to
>> have the tabs.
>>
>> WDYT?
>>
>> Thanks,
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2894
days inactive
2894
days old
0 comments
1 participants
participants (1)
-
Denis Gervalle