View source for Calligra/Usability and UX/Common/Web Browser-like UX for Main Window/IRC logs

Random IRC log (jstaniek, boud, cyrille, sebsauer):
<pre>
[15:58] <boud> jstaniek: if you want to argue that our apps should work more like a website than a desktop application, maybe we should 
get rid of the File menu completely and make the application look like a website, with a home button top-left _inside_ the window that 
leads to a home screen where users can select actions.
[15:58] <boud> but that would look a lot like eclipse, I guess
[15:59] <boud> and maybe we should have a permanent search field that looks in all documents of the right type top-right, same to most websites
[15:59] <jstaniek> for the second thing: I am 99% sure
[16:00] <boud> or if a webbrowser is what you meant, not a website, when writing ""Q0: Shouldn't we agree that the main UX these days 
is web browser?"
[16:00] <boud> put in a combobox with all recently opened documents with a search box next to it
[16:00] <boud> forward/backward buttons and a home button...
[16:00] <jstaniek> for the first: I did not expect anything calligra-wide, 1. it's up to maintainers, 2. new UX can be optional, 
3. simple apps like Flow or Braindump would play with the ideas easier than other apps.
[16:01] <jstaniek> boud: very interesting too
[16:01] <boud> is going to be tricky with split views, though tabs might be a good idea
[16:01] <jstaniek> boud: if the home displays recent docs and fav templates....
[16:01] <CyrilleB> well braindump does not have any open functionality... and new ui should not be optional, otherwise we lose consistence
[16:01] <boud> jstaniek: exactly
[16:01] <jstaniek> +1 for tabs
[16:02] <CyrilleB> for tabs... lets use window manager functionality
[16:02] <boemann> CyrilleB: +1
[16:02] <boud> The file menu can be what users expect from it
[16:02] <jstaniek> boud: speaking of browsers, opera is especially good at improved UX, eg. I bookmarked their previews-in-tabs at last akademy
[16:03] <jstaniek> y, the file menu or "Words" menu to be strict is the home 'page' also for the 'moder menu' proposal
[16:03] <boud> I always feel that opera is extremely cluttered and chaotic, but I haven't looked at it for a year now
[16:04] <boud> jstaniek: if you want to go for a browser L&F, the file menu should be a classic, old fashioned file menu and 
not open the "home page"
[16:04] <CyrilleB> I though the trend for web browser was no menu ?
[16:05] <boud> Right. But my firefox still has one -- and that's what I was looking at.
[16:06] <jstaniek> boud: yes, the modern menu would be the page
[16:06] <jstaniek> i.e. moved 
[16:06] <CyrilleB> but FF4 does not
[16:06] <boud> you can cut a lot of stuff from there though -- no reason to put settings or even the print dialog in the "home page"
 -- especially since the concept of a home page in a web app means it's divorced from the active document
[16:06] <boud> CyrilleB: this is firefox 4.0
[16:07] <CyrilleB> hum, weird

[17:56] <jstaniek> continuing the topic of UX, macosx introduces idea of dropping the save action completely
[17:57] <jstaniek> this plays ok with the browser paradigm
[17:57] <jstaniek> i.e. autosave
[17:57] <jstaniek> with nearly-indefinite 'revert'
[17:57] <jstaniek> action.
[17:58] <jstaniek> Of course kexi has no global save action by design (of the databases)
[17:58] <-- irina has left this server (Ping timeout: 246 seconds).
[17:58] <jstaniek> I seem to be convinced that the save action in document-oriented apps comes from old times
 when the storage was on floppies (look at the icon..)
[17:59] <_anna_> jstaniek: sounds a bit like google docs editor
[17:59] <jstaniek> yes
[18:00] <jstaniek> _anna_: I'd love to see our opinions on that idea. Online editors have autosave for other reason (to avoid loosing 
the work when user navigates out of the page), but autosave is useful regardless of using browsers.
[18:01] <sebsauer> jstaniek: guess a problem would be that saving a document can take some time... and auto-saving may block the whole UI. 
So, it can not happen so often but then ppl may lose things on crash... idealy saving would happen in background
[18:01] <ahiemstra> oo does autosaving... and it blocks the ui
[18:01] <ahiemstra> which is horrible imo
[18:01] <sebsauer> or maybe even only save incremental... but that's way to hard to implement
[18:02] <ahiemstra> also, another thing with autosaving is that I may not want to save to the same document
[18:03] <ahiemstra> so unless you autosave to a backup file (which some calligra applications already do) you would get conflicts there
[18:04] <sebsauer> re save to another file; good point
[18:04] <sebsauer> jstaniek: how was that solved in macosx?
[18:05] <sebsauer> or maybe someone has to explicit SaveAs and just not edit the file if he really likes to save to another document?
[18:06] <ahiemstra> errr
[18:06] <ahiemstra> that's just horrible
[18:06] <ahiemstra> "hey, you edited the document so you I just overwrote your existing document which you did not actuall 
want to write to, i'm sure you don't mind right?"
[18:08] <_anna_> it's a bit hard to learn new ways of doing things I guess
[18:08] <verbalshadow> sebsauer: not sure how MAC OSX solved it but inkscape does filename-Date-Time-group.ext and you can set the number of backups to keep
[18:10] <ahiemstra> the only way that would work properly is if you have proper versioning in all your files
[18:11] <ahiemstra> and unless we are going to force people to use git or svn with their documents that's unlikely to happen :)
[18:12] <_anna_> but my personal opinion is to use templates when a certain base structure is needed, not other documents (that can be made to templates when needed)
[18:13] <_anna_> but as said, people have their ways and the are stuck to them
[18:13] <ahiemstra> _anna_: you are talking about the startup related discussion right?
[18:14] <_anna_> no, I'm talking about using existing files as a base for new ones
[18:15] <ahiemstra> oh right
[18:15] <_anna_> though a bit slowly as I'm using my phone at the bus for irc ;-P
[18:16] <ahiemstra> well, the specific use case i'm thinking of is where i have some text document, 
start reading it and making some corrections here and there and then realizing that I should save 
it to a new version of the document
[18:20] <jstaniek> of course the autosave is together with ful lsave history, not just a single backup
[18:20] <jstaniek> mac also moved to that 
[18:20] <jstaniek> sebsauer: ^
[18:21] <jstaniek> also I do not imaging it's the workflow that powerusers would like to switch in, say, kdevelop
[18:21] <jstaniek> _anna_: for documents, the idea of autosave is widely known (gmail, gdocs, wordpress, and most of the competing services)
[18:22] <jstaniek> so I am confident about level of familiarity
[18:23] <dmitryK> ahiemstra: you mean it won't work in all the compillers?
[18:24] <jstaniek> ahiemstra: no need to use VCS, we have discussion with Pau about this already; VCS are good for unstructured 
objects like plain text files; there's nothing to optimize too in autosave on desktops
[18:25] <ahiemstra> jstaniek: then how are you going to save history?
[18:25] <jstaniek> (btw, if there's something to optimize, images and sounds: can be saved once and refernced). All that is detail. 
[18:25] <jstaniek> to separate files
[18:26] <jstaniek> mac does so (with integration at the filesystem level)
[18:26] <jstaniek> i.e. file-level versioning
[18:26] <jstaniek> Nothing special at all. 
[18:27] <sebsauer> jstaniek: then there is the problem that auto-saving can take lot of time with larger documents
[18:27] <ahiemstra> yes
[18:29] <sebsauer> maybe optimization would be possible there to not re-save e.g. images every time but still...
[18:30] <jstaniek> sebsauer: you know, hard to believe it's a problem. Browsers consume more CPU (even V8) and googledocs are useful.
[18:30] <jstaniek> I opt for reusing multicore of course.
[18:30] <jstaniek> We can do that; browsers: not that easy.
[18:31] <sebsauer> jstaniek: googledocs uses a db in the background. So, they just call UPDATE and voila. ODF is a bit more complicated there :-/
[18:32] <jstaniek> the saving process has 2 main CPU-intensive steps: 1. encoding the data structs to the ODF, 2. using the filter chain.
[18:32] <sebsauer> I mean incremental updates are not so easy in ODF
[18:33] <sebsauer> yes, so it can take way longer to save a document especially if you have images and what not
[18:33] <jstaniek> google docs use ODF-like doc definitions, since DOC is similar (i.e. not optimized for gdocs).
[18:33] <sebsauer> google docs actually uses an own xatom-like format. ODF is just for import/export
[18:33] <ahiemstra> yeah, I was just going to say that...
[18:33] <sebsauer> so, it's not saved as ODF-files
[18:33] <jstaniek> Images, videos - all can be handled via resources, and we have them already. What I already like is that the 
concept does not interfere with ODF requirements.
[18:34] <jstaniek> We need ODF for contacting with the outside world. Which is - different computer systems or calligra-unaware 3rdparty apps.
[18:35] <sebsauer> ah, you mean to not actually save to ODF but have something that allows incremental writes (e.g. SQLite). 
Yes, would be an idea. But then you still need to write the ODF-file sometime cause that's what the user opened, no?
[18:36] <jstaniek> custom ODF-oriented apps use flat ODF XML for custom needs, and this breaks compatibility with apps requiring 
structured ODF, but nobody complains as long as ther's veryeasy import/export path.
[18:36] <jstaniek> hmm no db, please :)
[18:36] <sebsauer> :)
[18:36] <jstaniek> can be surprising that _I_ do not promote databases, but really, serializing to tables degrades efficiency
[18:37] <sebsauer> but then you have the pribblem that saving can be rather expensive
[18:37] <sebsauer> problem
[18:37] <sebsauer> in terms of time needed
[18:37] <sebsauer> what means the UI freezes
[18:38] <jstaniek> I am assuming that we spend more time in CPU for playing with filter chains (eg saving ->ODF->DOC) 
than with saving directly to ODF
[18:38] <jstaniek> I opt for a separate thread
[18:38] <jstaniek> we're prepared for that
[18:38] <jstaniek> since we have separation between data structs and the view
[18:39] <sebsauer> what sounds like lot of work for me to get it right. But yes, if that would really work then it could be done this way. 
As long as we don't end with hard to debug code what can happen very easy using threads
[18:39] <jstaniek> delayed copying can happen to avoid blocking the structures that GUI uses, but this can be per-paragraph or so
[18:40] <jstaniek> sebsauer: I planed to continue the abstraction works by introducing value-based API for libodf 
[18:41] <jstaniek> that would play with multithread
[18:41] <jstaniek> and not just in gui case but also in massive processing (that's why I though about Qt-only libs)
[18:42] <jstaniek> I have quite a bit of that done for Predicate, which has similar structures, e.g. full syntax tree for expression is value based now.
[18:43] <sebsauer> that (threads) sounds like a lotttt of work for me
[18:43] <jstaniek> libodf is built on top of a number of maps, it's quite typical system 
[18:43] <jstaniek> introducing threads == 1. blocking or 2. delayed cloning
[18:43] <jstaniek> nothing more
[18:44] <jstaniek> the aim is to create a snapshot of the structures without global locks
[18:44] <sebsauer> I see. Still you need to synchronize if new content is added. Also I am not sure if it's really fast if you do a deep
copy of the whole QTextDocument
[18:44] <jstaniek> since saving (in a thread) means iterating over the structures, and accessing to global maps, the locks can be nicely atomic
[18:45] <jstaniek> a full copy is needed if you delete all the document while background saving has already started
[18:46] <jstaniek> in typical case saving happens while your system is idle, that's why I quite confident
[18:46] <sebsauer> actually we once had the idea to improve loading by using threads. But that was canceled then cause threads can bring
pain and there where easier ways to optimize
[18:47] <jstaniek> I beleive that was not about using background threads . That was about parallel computing. This is another story. 
ODF processing is not easily parallelable...
[18:47] <jstaniek> (eg. because of cross-dependencies)
[18:48] <sebsauer> if you think you can do it then please do it. Personal I think it would be lot of work to get right. 
But then maybe just deep copy a QTextDocument and/or setting locks at proper places would already do it. I've not really an idea there 
how well our code and QTextDocument are prepared for that
[18:49] <sebsauer> but I know that I usually try to stay away from threads if not really needed ;)
[18:50] <jstaniek> yeah using threads without a good plan is like starting house renovation... you know :)
[18:50] <sebsauer> or helping others move from one house to another... yes, I know :)
[18:50] <jstaniek> good think is that the background savng would also be good for the classic behaviour
[18:50] <jstaniek> s/thing
[18:51] <jstaniek> i.e. for ctrl+S
</pre>