Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index

On Wed, Apr 24, 2013 at 8:44 AM, Mirek M. <> wrote:

Hi Keith,

On Mon, Apr 22, 2013 at 9:24 AM, Keith Curtis <> wrote:

Notice that the advantages listed above don't require a ribbon-like UI
can be accomplished using toolbars while retaining all of the
advantages of
LibreOffice's current UI. Focusing on toolbars also allows a smoother
change and less development effort. The proposed EasyHacks are a first

You could quickly prototype any kind of toolbar or ribbon in Python.

Do you have a better toolbar design? I'd update my wiki page with anything
radically better. For this task, I suggest you not worry about what is
doable and instead what you want.

Alright, sure. (I just don't want you to get your hopes up that this will
ever be implemented in LibreOffice. As I was told by several LibO devs, the
chances for LibO changing toolkits is basically zero to none.)

Everything is a question of resources and efficiency. Anyone who says that
there is no chance of LibreOffice changing toolkits are simply saying they
can't imagine the resources for it would show up. But there is no need to
change LibreOffice's widgets to build a prototype. It depends on what
people mean by "implemented." I wouldn't worry about my hopes, I'm happy to
get a blank Python toolbar. My biggest concern right now is whether the
first tool panel will be able to dock only on the side or also on top.

If you need a quality mockup to work from, spiceofdesign made an excellent
one on deviantart:
It's somewhat similar to my own vision for the UI, though I propose
several changes:
* Have the static toolbar on the same line as the contextual toolbar, as
pictured on
This toolbar should only contain Undo, Redo, Save, and Tools items. It
should not contain New, Open, Templates, Print, or Share, as those aren't
relevant during editing. (In case this proves controversial, MS Office and
iWork also hide these in order to keep a focused workflow.)
* The mockups on how the Tools menu 
could evolve.
* Each toolbar should have a Hidden Items Menu (HIM) [1] containing the
hidden commands of that toolbar (i.e. those set as "hidden" in
"Customize..."). The dialog relevant to that toolbar should be among these
commands, if it exists.
* Dragging commands from the toolbar to the HIM should hide them. Doing
the opposite should show them on the toolbar.
* Pages should be selectable. [2] Selecting a page would trigger a toolbar
with page-related commands. [3]


Hmmm, looks different and interesting. It could also be done in Python,
except possibly for the buttons on the title bar. However, you could
temporarily put them into another toolbar below.

If someone creates a new UI, and a way to save and restore the old menus
and toolbars, then people could try it out and work through the issues, and
just switch back to the old interface when needed.

The more thorough and tested the UX proposal, the more likely it will get
implemented. Furthermore, once you've got a prototype you like, you won't
really care when that happens.

I'll put this text on the wiki page as another design.


Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.