[RFC] KDev4 Ui

[Matt Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Nov 13, 2007, at 7:59 PM, Andreas Pakulat wrote:

> Hi,
>
> as a summary and some ideas I had while I couldn't sleep the last
> hours about the KDev4 UI.
>
> So we now have dockwidgets and ideal, I guess most/all of us agree  
> that
> one of the two needs to go. Which one depends on the possibility of
> implementing most/all of the following items.
>

No, actually, I think they both need to stay. But just those two. No  
more UI modes please.

> - drag'n'drop of the individual toolviews for organization
>
> - possibility to have multiple toolviews open on each border, i.e.
> ------------
> | Project  |
> |          |
> ------------
> | Teamwork |
> |          |
> ------------
>
> - allow to choose which toolview should get the corner of the  
> mainwindow
>   (side vs. bottom ones), optionally doing that on-the-fly with
>   drag'n'drop
>
> - focus switching and maximizing with both keyboard and mouse, the  
> first
>   should be obvious (what we already have in kdev3), the second is
>   something I quite often use in Eclipse, doubleclicking the title  
> of a
>   toolview or editor-tab to close everything else. I'm not sure how to
>   provide mouse-maximizing when we don't have tabs, but see below
>
> - remove that stupid combobox :) Well we all know its just temporary,
>   but so far it seems there are 2 types of people, those that want  
> tabs
>   and those that want scalability. I think we all agree that tabs  
> don't
>   scale for more than a handful of files, you'll either get annoying
>   arrow-buttons or like in eclipse you'll just get a "..." tab that
>   opens up a document-list.
>
>   I guess we need to have both again, I can't see a way to satisfy  
> both
>   needs and IMHO we don't really need to. We have the possibility to
>   switch between the two modes in KDev3, I see no reason to make it
>   different in KDev4, except maybe not using a KTabWidget and just
>   hiding its tabbar.
>
> - UI for edit-history, this goes somewhat together with the above, the
>   people that have 20+ files open need either quick-open or edit- 
> history
>   (or similar) to switch between files. Now kdev3 edit history has a
>   real bad drawback: You can't see where you're jumping to. If you  
> know
>   you've edited file foo.cpp before doing edits in the current file,
>   you'll start jumping backwards, but you need to know the code or  
> check
>   the titlebar to see when you found foo.cpp (if you edited multiple
>   locations in your current file).
>
>   My idea to solve this dilemma is attached, a small list of 11 items
>   that shows the current file and the last/next 5 entries in the
>   history. (history is a ringbuffer right?)
>
>   That should provide enough information to let you reasonably fast
>   switch back through edit history and we can even help resolving
>   multiple files with the same name problem by adding a url or project
>   in a second line. Of course the widget needs to be usable with mouse
>   and keyboard at the same time. I know adymo had a similar widget for
>   showing the list of open files hacked up already...
>
> Did I miss any general-ui-concerns?
>
> I'll be putting these things into the wiki, once the discussion has
> settled.
>

Better would be to put them in the wiki now and keep the wiki page up  
to date. :) But I know that sometimes that's just not possible.

> Andreas
- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFHOnTTA6Vv5rghv0cRAqvZAKCsV9AARZZqbktspdoyjCnRx1DTYACfbe6M
o1X7EVWQ7MIsTKq9V1lQv2o=
=yQjg
-----END PGP SIGNATURE-----