KDev4 Ui

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.

- 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.
  
Andreas

-- 
Communicate!  It can't make things any worse.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 14.11.07 02:59:07, Andreas Pakulat wrote:
> - 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?)

Apart from forgetting to attach it, its also quite large, so
I've put it
here:

http://www.apaku.de/vardata/kdev_edit_history_mockup.png


Andreas

-- 
Don't tell any big lies today.  Small ones can be just as
effective.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 14 November 2007 02:59:07 Andreas Pakulat
wrote:
> - 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...

That looks nice, although, maybe it can be integrated with
the already 
available document-list view? We could make the
document-list somehow 
highlight the files you have last worked with, similar as I
think it's done 
in kate. Then when you press the modifier-keys for your
history browsing 
action, the list could show additional information, like
"+1", "+2", "-1" to 
show you how many times you need to push "back" or
"forward" to get there and 
some different color-highlighting to show you where you are
jumping. The tabs 
could show the same information and highlighting.

All in all, I agree with what you've written. 

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

-----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)

iD8DBQFHOnTTA6Vv5rghv0cRAqvZAKCsV9AARZZqbktspdoyjCnRx1DTYACf
be6M
o1X7EVWQ7MIsTKq9V1lQv2o=
=yQjg
-----END PGP SIGNATURE-----

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 14.11.07 03:33:36, David Nolden wrote:
> On Wednesday 14 November 2007 02:59:07 Andreas Pakulat
wrote:
> > - 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...
> 
> That looks nice, although, maybe it can be integrated
with the already 
> available document-list view? We could make the
document-list somehow 
> highlight the files you have last worked with, similar
as I think it's done 
> in kate.

Well, I find that highlighting in kate (2.5 at least) mostly
unusable.
And the document view really shows all documents, without
any edit
positions (note the line numbers). When switching through
history I
think one usually don't cares about the "end" or
"beginning", you just
want to go back a little, or forth and see where you end up.
If you want
to jump directly to a file, a quick-open method is much
faster than
running through edit history.

Andreas

-- 
Today is National Existential Ennui Awareness Day.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 13.11.07 22:08:51, Matt Rogers wrote:
> 
> 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.

That means double the work, for IMHO no gain. I mean if we
can provide
drag'n'drop and multiple toolviews on the same border
visible at the
same time, then we already have dockwidgets. But its
dockwidgets that
auto-collapse, where the buttons take less space and scale
better (the
tab texts in qt dockwidgets are just cut and the ellipsis
added). 


Whats your reasoning to keep the dockwidget mode? Oh and
just in case I
wasn't clear: I'm not saying throwing dockwidgets out the
window right
now, I'm saying to throw them away once we have a proper
replacement
(i.e. at least dnd working)

Andreas

-- 
It was all so different before everything changed.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 14 November 2007 10:56:31 Andreas Pakulat
wrote:
> Well, I find that highlighting in kate (2.5 at least)
mostly unusable.
> And the document view really shows all documents,
without any edit
> positions (note the line numbers). When switching
through history I
> think one usually don't cares about the "end"
or "beginning", you just
> want to go back a little, or forth and see where you
end up. If you want
> to jump directly to a file, a quick-open method is much
faster than
> running through edit history.

Hmm yes you're right.

But I think we should at some point do some
"hotness" highlighting, in the 
tabs, as well as in the document-view. We should implement
some algorithm 
that takes into account how much the user has edited a
document during the 
last time, and how much he has watched a document, calculate
according 
highlighting-colors, and add a one-click way to close
documents from within 
the document-view.Then you could easily close all the
dangling documents you 
have just taken a short peek into, without doing too much
thinking, and you 
wouldn't lose the overview all that fast(Would help our
scalability thing ;)

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wed, 14 Nov 2007 10:52:08 pm David Nolden wrote:
> On Wednesday 14 November 2007 10:56:31 Andreas Pakulat
wrote:
> > Well, I find that highlighting in kate (2.5 at
least) mostly unusable.
> > And the document view really shows all documents,
without any edit
> > positions (note the line numbers). When switching
through history I
> > think one usually don't cares about the
"end" or "beginning", you just
> > want to go back a little, or forth and see where
you end up. If you want
> > to jump directly to a file, a quick-open method is
much faster than
> > running through edit history.
>
> Hmm yes you're right.
>
> But I think we should at some point do some
"hotness" highlighting, in the
> tabs, as well as in the document-view. We should
implement some algorithm
> that takes into account how much the user has edited a
document during the
> last time, and how much he has watched a document,
calculate according
> highlighting-colors, and add a one-click way to close
documents from within
> the document-view.Then you could easily close all the
dangling documents
> you have just taken a short peek into, without doing
too much thinking, and
> you wouldn't lose the overview all that fast(Would help
our scalability
> thing ;)

What I would like to see is something akin to the apt
"packages installed as 
dependencies but no longer needed" feature - ie, files
that you opened during 
a debug session but didn't modify are likely just there for
code navigation, 
so close those with a particular shortcut.

But I still think I'll keep on using "close all
others" ;)

Cheers,
Hamish

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wed, 14 Nov 2007 08:59:54 pm Andreas Pakulat wrote:
> On 13.11.07 22:08:51, Matt Rogers wrote:
> > 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.
>
> That means double the work, for IMHO no gain. I mean if
we can provide
> drag'n'drop and multiple toolviews on the same border
visible at the
> same time, then we already have dockwidgets. But its
dockwidgets that
> auto-collapse, where the buttons take less space and
scale better (the
> tab texts in qt dockwidgets are just cut and the
ellipsis added).

You probably already know this, but the first commit I added
support for 
on-the-fly switching, so it's no stress having two (other
than it's more work 
to maintain).

Cheers,
Hamish

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

> 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.

Agreed.  By the time ideal is done it will basically be
dockwidgets++ anyway.

> - 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 like the way Visual Studio 2005 handles the situation of
too many open documents to display:
http://www.imagedump.com/index.cgi?pick=get&tp=5203
97
IMO, this is much friendlier than the arrow buttons.  It's
much easier to find what you are looking for.  This would be
pretty easy by subclassing QTabBar (except on the Mac, where
they do goofy things like centering tabs ;).

>   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?)

When/how would this list be shown/hidden?

Kris Wong

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel