KDev4 Ui

On Wednesday 14 November 2007 15:54:12 Andreas Pakulat
wrote:
> Working filesets cut down only if you don't need the
other 15 files, but
> what if you do?

The question is, whether you need ALL 40 files at the same
time!

And I think, you never do. If you have them open at the same
time, they are 
automatically so unaccessible that it's only slightly better
than not having 
them open at all(see quickopen  ). So you
could have one "look" and 
one "work" set. Since kdevelop-4 will allow
multiple main-windows, don't we 
already have implicitly something similar to working-sets?
You could open an 
additional main-window in which you do all the lookup,
understanding, 
searching, etc. and have another main-window where you do
the real work. But 
with real working-sets, you could do everything within one
main window, and 
once you feel that you need to see both sets at the same
time, you could open 
an additional main-window with the other set. It would just
make the thing 
more manageable.

But to come back to the core problematic:
Once you have 40 files open, you are most probably at a
point where you worked 
at one point, and to understand it jumped to 39 other points
using 
code-navigation or whatever, so you will have 39
"nearly useless" files. I 
personally usually just close ALL tabs in such a
situation(just for 
frustration), and re-open what I was working on using
quickopen. We need a 
nice way to close those files.

One option would be marking all files that have been opened
during 
code-navigation and not edited, so they can all be closed
automatically at 
the same time, and maybe grouped together in the
document-view under a single 
category "Navigated". But highlighting might help
too. 

greetings, David

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

On 14.11.07 16:21:05, Amilcar do Carmo Lucas wrote:
> On Wednesday 14 November 2007 15:42:30 Vladimir Prus
wrote:
> > some sorting
> > of files by number of times it was looked at would
be good.
> Kate has this ! 

No it doesn't. It only has some obscure highlighting which
is not
self-explanatory unless you actively try to figure out the
scheme of the
highlighting.

Andreas

-- 
You get along very well with everyone except animals and
people.

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

On 14.11.07 10:12:48, Kris Wong wrote:
> > Also as I said that dropdown-thing only allows to
switch
> > between files,
> > while my proposal was about edit-history, which
includes
> > multiple places
> > in the same file.
> 
> O, I like your edit histroy idea, I'm just saying I
think the tab
> widget solution is the best bet as the base
functionality for
> switching between open files.  Anything we can add on
top of that to
> make it more scalable is a plus.

No, the document list is the proper base functionality to
switch between
files, IMHO. The tabs are a plus, because they only work for
a handful
of files. So having a tabwidget there is solely for those
people that
want to have tabs, we have better ways for the switching
between files.

About the drop-down I'm not sure thats needed, I mean
opening that one
with the mouse is the same amount of "work" as
opening the document
list in ideal mode - including automatic closing when
selecting a file
and switching focus back to the editor.

Andreas

-- 
Is that really YOU that is reading this?

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

On 14.11.07 18:03:27, David Nolden wrote:
> On Wednesday 14 November 2007 15:54:12 Andreas Pakulat
wrote:
> > Working filesets cut down only if you don't need
the other 15 files, but
> > what if you do?
> 
> The question is, whether you need ALL 40 files at the
same time!
> 
> And I think, you never do. If you have them open at the
same time, they are 
> automatically so unaccessible that it's only slightly
better than not having 
> them open at all(see quickopen  ).

As you know I completely disagree with this. Navigation
among 20 files
is no problem using quickopen. Of course using tabs and the
next-tab/prev-tab switching doesn't work because files are
too far away.

> So you could have one "look" and one
"work" set. Since kdevelop-4 will
> allow multiple main-windows, don't we already have
implicitly
> something similar to working-sets? You could open an
additional
> main-window in which you do all the lookup,
understanding, searching,
> etc.

Well, multiple mainwindows might not work too well on
single-head
desktops.

About the "close-files-I've-only-read" feature,
that truely sounds like
a good idea. But has not much to do with the navigation
among multiple
files, maybe you usually work in only 1 file, but I find
myself
currently working on at least 4 files "at once",
with another 3 open for
reference and additionally about 6 tabs on a konqueror
window for
API reference. Those last 6 would ideally also be among the
"open files"
list, inside KDevelop.

Andreas

-- 
Good day for a change of scene.  Repaper the bedroom wall.

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

On 14.11.07 16:00:52, Jens Dagerbo wrote:
> Why isn't the current Document List (or whatever it's
called) enough?

Well, if it automatically re-arranges itself according to my
navigation,
it might work well enough. That means when I go from foo to
bar, it
should be 1 keyboard-shortcut to go back to bar and the
document list
should show that. Same thing for mouse-movement, 1 move + 1
click at
most to go back 1 edit position.

> It actually scales and can additionally house many more
actions than a
> dropdown list. (VCS actions, file actions, etc)

Sorry, I think you lost me here, what do VCS actions do in a
document
list. And what exact VCS actions do you mean?

I agree with everything else you said.

Andreas

-- 
You are the only person to ever get this message.

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

On Wednesday 14 November 2007 18:43:57 Andreas Pakulat
wrote:
> > And I think, you never do. If you have them open
at the same time, they
> > are automatically so unaccessible that it's only
slightly better than not
> > having them open at all(see quickopen  ).
>
> As you know I completely disagree with this. Navigation
among 20 files
> is no problem using quickopen. Of course using tabs and
the
> next-tab/prev-tab switching doesn't work because files
are too far away.

Well.. what if there was a quickopen-file shortcut that
shows you all the 
files in a most-recently-used order? The files would be
about exactly as 
accessible as they are when they are open(when you use
quickopen to access 
them).

> Well, multiple mainwindows might not work too well on
single-head
> desktops.

That's true.

> About the "close-files-I've-only-read"
feature, that truely sounds like
> a good idea. But has not much to do with the navigation
among multiple
> files, maybe you usually work in only 1 file, but I
find myself
> currently working on at least 4 files "at
once", with another 3 open for
> reference and additionally about 6 tabs on a konqueror
window for
> API reference. Those last 6 would ideally also be among
the "open files"
> list, inside KDevelop.

Of course I also usually work on multiple files at a time,
let's say it's 3 in 
the average. But around those files, there's usually about 7
other files that 
I'm not working with, that I just opened some time to look
something up. 
Those additional files currently make it a lot harder
getting an overview of 
the exact files I'm working on.

greetings, David

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

On Wednesday 14 November 2007 16:00:52 Jens Dagerbo wrote:
> Why isn't the current Document List (or whatever it's
called) enough?
> It actually scales and can additionally house many more
actions than a
> dropdown list. (VCS actions, file actions, etc)

ever since using my first IDE I have wondered about this,
too. Vertical lists 
of files seems much more scaleable. For that matter, I
prefer tabs to be 
vertical stacking in most cases because

a) Screens seems to get wider and wider, but text still
reads better at 
75chars/line
b) Scanning a list is sooo much easier than looking across
c) typically, the vertical stack fits 40 tabs easily. 

I feel that the horizontal tabwidget is only useful when you
have very few 
tabs. E.g.a tab for debug, another for profiling, a third
for hacking. A 
horizontal tab for each webpage/file is a not a good idea if
you open many 
tabs... which I suspect many people do.

Switching files while editing is one of the most common
task, especially in OO 
programming, and even more so in C++. While many here have
stated that "3-4 
files max is reasonable, I frequently commit 10+ files ---
simply because the 
OO solution involved a call to an pure virtual function,
which was 
implemented in a number of subclasses. Or think of the times
when you decide 
that *that* member has a horrible name, or a poor
interface... and go and 
change it? 

As a final note:  *If* you want to use the horizontal tab
bar, I'd suggest 
simply starting a second bar below the first one when the
first bar runs 
full. Limit it to 5 bars, and you can at least scale
tolerably.

Happy thoughts! 

-- 
regards, Esben

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

On Wednesday 14 November 2007 16:00:52 Jens Dagerbo wrote:
> "File sets" doesn't solve this. They are just
the
> remember-to-close-before-you-open idea on crutches. At
least for this
> problem. File sets could perhaps be nice for other use
cases. I can't
> quite see them.

Nope.. it has nothing to do with "remember to
close". The idea is that while 
the whole searching-process, you could use an own file-set
where you open 
your 40 files that you close alltogether once you're ready,
or you switch the 
file-set to another "working" set so you can come
back to your 40 files when 
you think it's needed. Of course this needs special user
actions, so it would 
not help those who are not aware of it. I think those can
mainly be helped by 
highlighting/marking in the document-view.

greetings, David

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

On Wednesday 14 November 2007 18.50.50 Andreas Pakulat
wrote:
> On 14.11.07 16:00:52, Jens Dagerbo wrote:
> > Why isn't the current Document List (or whatever
it's called) enough?
>
> Well, if it automatically re-arranges itself according
to my navigation,
> it might work well enough. That means when I go from
foo to bar, it
> should be 1 keyboard-shortcut to go back to bar and the
document list
> should show that. Same thing for mouse-movement, 1 move
+ 1 click at
> most to go back 1 edit position.

I'm not convinced code navigation history (places visited
via language support 
features) and file navigation history (files visited via
file switching or 
opening) mixes well.

MSVC6 had what I refer to as file navigation history - the
files you had 
visited were sorted in a "stack-like" order and
accessible through a 
file-switching keyboard shortcut. No support for navigation
point or edit 
point history (and no visible indication of what the visit
order looked 
like).

KDevelop3 mainly had code navigation history (by 3.4.1 I
think we tracked all 
ways to switch files too, but a file switch was handled as a
code navigation 
point), accessible through toolbar (dropdown-)buttons and
keyboard shortcuts.

Eclipse/JDT (dunno about CDT) has both. But it keeps them
seperately. You can 
either chose to go back/forward between code navigation
points or use a 
keyboard shortcut to revisit files in a stack-like fashion
(There was a nice 
patch to KDevelop3 that did this, but, instructively, it was
implemented with 
a parallel history)

> > It actually scales and can additionally house many
more actions than a
> > dropdown list. (VCS actions, file actions, etc)
>
> Sorry, I think you lost me here, what do VCS actions do
in a document
> list. And what exact VCS actions do you mean?

Well.. the document list is a list of files, and simple VCS
actions 
(checkin/checkout/diff/annotate, etc..)  are file-centric
actions. Being able 
to click on a file and diff it with the VCS copy seems a
reasonable feature 
to have, right? (Unless I'm totally lost, KDev3 hooked VCS
actions into 
the "FileContext" and VCS actions were thus
available in, among other places, 
the FileList (the "document list" of KDev3)

// jens



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

On Wednesday 14 November 2007 04:59:07 Andreas Pakulat
wrote:
> Hi,
> 
> as a summary and some ideas I had while I couldn't
sleep the last
> hours about the KDev4 UI.

Sorry for jumping late, and possibly incoherently, but it
might be
very good to remove hard distinction between toolview and
editor.
For example, in KDevelop 3.5 debuggers memory viewer is on
the left.
I've heard some people request, in earnest, that the memory
view be
able to show some images they store in memory, and for that,
putting
memory view in the central area would be much better --
sqeering 800x600
image into sidebar won't work. Likewise, for disassembler
view -- especially
with interleaved source, it won't fit in tool window.

Will something be possible to solve those issues?

- Volodya

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