So - it's the time of year when we want ideas for google summer of code
students to hack on. *But* - these need to be small, reasonably well
contained, and must have a (hacker) mentor who is enthusiastic about
helping the person get the code done.
Having said all that - I'm sure there are some cool ideas from you guys
for small, incremental changes - eg. adding notes by clicking in the
toolbar, or well - something that is reasonably achievable in six weeks
of work, then it'd be great if you could let me know.
Re: [Libreoffice-ux-advise] Google Summer of Code ...
it's probably extremely late now, but here are some extremely rough
ideas (in no real order):
* Make vertical toolbars more usable: vertical toolbars can be great
if you can just throw the cursor to the side of the window and only
need the right vertical positioning (cf. Fitts Law). Thus, it's
important that the sensitive area of buttons in vertical toolbars
extends to the very first/last column of pixels (depending on whether
the toolbar is located on the left or the right) when the window is
maximised. Also, choosing something from a split button in a
horizontal toolbar is not really working well. This might also help
with implementing something like .
* Refine Find: Find today is still a normal toolbar that can be
undocked, moved, locked closed etc. The task would be to find a
_permanent_ place for the Find toolbar and make sure it works nicely
with Toolbars that are docked to the bottom (like the Drawing
toolbar). It might also be a good idea to add a timeout after which to
close the Find bar and/or an explicit close button.
* Info bars: many modern programmes have info bars to modelessly alert
users of certain things. It would be great to have these in LibO,
because they allow alerting users without violently breaking their
flow. See  for mock-ups.
Markus's new Names dialogue uses a similar concept – though there it
is implemented as a FixedText only. It would be good to have the info
bar concept available both to the main window as well as to individual
* An about:config thing for LibreOffice: my somewhat kludgey idea
would be to use Base as a RAD platform and a Base file as an
intermediary format for our configuration files. Macros would be
responsible for syncing the Base file with the actual configuration.
Additional work would be to add UI entry point to our settings and to
make it look nice (i. e. hide all the Base chrome and make it look
like a regular programme window).
Pro: dogfood Base
Cons: doesn't work without Java (?); Base will also be unavailable on
mobile platforms, so it like wouldn't work there.
* Remove the page Memory from the options and replace it: the options
page Memory can be used to configure pretty obscure settings. Instead
of using this page for setting things up, LibreOffice should determine
all of these things on its own.
* Animations: make it easier to use animations in all apps, not just