User:KeithCu

From The Document Foundation Wiki
Jump to: navigation, search

LibreOffice is exciting, but many complain that the user interface looks from another decade. At the same time, there are designers who are a part of the community who want to create futuristic user interfaces, but today are forced to work in GIMP and Inkscape. LibreOffice has a Python-based object model for toolbars which seemingly could be used for graphical experiments, but it is apparently not good enough as there hasn't been any progress beyond bitmaps in 2 years.

By hosting a PyGtk (or WxPython, etc.) window inside a LibreOffice toolbar, it should be possible in a few months to create a new UI for Writer like this: Libreoffice ui mock up dark 1 by pauloup-d37dx4a.png


This is just one possibility. There are long-running debates about whether ribbons are good thing. Note that the Microsoft design has evolved in the 6 years since they were first introduced. Calligra's sidebar is clunky. The key point is that the Python toolbar becomes a canvas for experiments in new and prettier UIs, touch, etc. One could build this in C++, but there is no spec. Furthermore, it might take a week for an intern to create the new "Insert - Breaks" button in VCL, etc. which is just one of the new widgets. There is also a chicken and egg problem in that it is very hard to create a spec on something radical without testing it out on users first.

Toolbars are mostly glue code, so perfect for Python. By doing it in Python, you don't need to make a full spec first. You can put something reasonable out there, and start iterating with instant turnaround time. The LibreOffice build system is getting faster, but you still need to recompile and restart. That is especially bad for graphical work, for people with limited knowledge of the codebase, short attention spans, and those who want to evolve towards the solution.

Implementation notes

Working from a headless build is not a good idea here because it makes sense to start by re-using some of the the existing UI code: search dialog box, menus, bitmaps, etc. This isn't about starting over, this is about advancing the state of the art. This work would also need interaction with the graphics designers, working through the holes that are found when bitmaps are turned into code. An intern should be able to create a new Writer UI in one summer. Later, it could be extended to the other applications and touch. You don't need to wait for Google to fund new UIs, however.

Eventually some of these experiments may be partially thrown away, and partially ported to C++ for slightly faster performance and better integration. But it will still save time in the end because it is easier to write the C++ after you've got the Python "spec" that people don't hate, but instead like!

Unlike Office 2007, Calligra, and Gnome 3.x, where code was taken away from happy users, this is an experimental mode where you could even switch back and forth in one click.

Some of the screenshots you see on the web like the one above, are dark, so it should also be customizable with a few color schemes, etc.

Rather than making a bunch of new button icons, the existing ones could be batch-converted to monochrome, and made able to draw in the color schemes.

Some might not want the different buttons and colors, etc. It can be customizable. Unlike Calligra, LibreOffice has the ability to throw enough resources at this complicated problem that you hopefully won't end up shipping something that people don't like! I am not sure I could live with a sidebar for Writer, but I'd like to try.

One big question is whether to use PyGtk or WxPython or PyGObject. WxPython's stable branch doesn't support Python 3, although there is the Phoenix project. It seems not to matter too much what is used for experiments, but PyGtk seems to have little activity, and less features. PyGObject has more activity, but it doesn't run on the Mac. If the experiment lives beyond the first few months, it will be worth thinking about. Furthermore, maybe using WxWidgets enables LibreOffice to (slowly) migrate away from its internal cross-platform widget toolkit. Obviously that is a lot of work, but it is nice to write code that doesn't limit future choices.

Another issue is how to build and deliver this large and complicated experiment so that users can easily try it out.

Another topic how this relates to the new Android UIs that people are thinking about. Having played with QuickOffice on my tablet, which has about 5% of LibreOffice features, a full UI is not necessary to be relevant. Their first 5% could be built from scratch from a headless version, but not this.

Coding advice from Michael Meeks

Using the Python / StarBasic task-panel example that would probably be a good place to start from - though clearly we want a pure Python solution here; so I think we want to adapt the odk/ toolpanel example in several ways here:

1. Adapt the toolpanel Python to hide all the elements using XLayoutManager - except for ourselves:

+ XLayoutManager impl is in framework/source/layoutmanager and framework/inc/services if you need to read it.
Get the XLayoutManager from the xFrame from the 'LayoutManager' property on it; git grep getLayoutManagerFromFrame if in doubt.
2 hours

2. Adapt the task-panel code, such that we can disable this 'Tasks' surround for our replacement UI panel. Code is in sfx2/source/dialog/taskpane.cxx I think, see also svtools/source/toolpanel/*.cxx, set that property from the Python to disable.

4 hours perhaps? (if we think this is the right approach)

3. UI / rendering:

+ rid ourselves of this getOrCreatePanelRootWindow junk in the Python. Instead implement the XToolPanel interface ourselves in Python.
+ We will need to create a toolkit/source/awt/ window using VCLXToolkit::createWindow( ... ), prolly passing the '"control"' type there (?)
+ We will want to connect to that control's size change events, and particularly use the 'addPaintListener'
method to hook paint events, cf. vclxwindow.hxx for the C++ impl.
+ paint a background color, a diagonal line across the extent, and a single image: we'll need to use the XGraphics API:
http://api.libreoffice.org/docs/common/ref/com/sun/star/awt/XGraphics.html
8 hours

4. finally - I suspect we will need to hook keybindings using a Python equivalent of: framework/qa/complex/XUserInputInterception/EventTest.java

2 hours

At the end of that we should have all the basics in-place to get a prototyping harness to allow the UI to be (optionally) improved via Python plugins - giving the plugin the ability to render the view it sees fit (including embedding other controls in it).

Another UI proposal from Mirek

If you need a quality mockup to work from, spiceofdesign made an excellent one on deviantart: http://spiceofdesign.deviantart.com/art/Writer-Concept-351501580?q=gallery%3Aspiceofdesign&qo=2 . 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 https://wiki.documentfoundation.org/File:Writer-appmenu1.png. 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 Design/Whiteboards/Toolbars#Mockups detail 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]

[1] tdf#62079 [2] tdf#60416 [3] tdf#61080

Another UI proposal from Michael Meeks

I'm was more interested in an attractive, new tab-based top-bar with various sizes of icon + text button in them and some grouping. That would fit a custom widget rendering better IMHO.