KDev4 Ui

On Wednesday 14 November 2007 21.53.18 Andreas Pakulat
wrote:
> On 14.11.07 21:39:51, Jens Dagerbo wrote:
> > What would a more predictable navigation history
look like? A popup that
> > describes what you would jump to with filenames
and line numbers (like in
> > your mockup.. (that's just the "useless"
KDev3 feature bound to a
> > shortcut) Personally, I never found it informative
enough.
>
> Maybe you're biased because you know exactly what
events add an entry to
> the history list.

Sadly, this is probably true. :(

> The problem is that unless you
>
> a) spend an hour or so playing with the history
> b) or know the code exactly
>
> you have no idea what exactly adds an entry to the
history. At least I
> didn't find a pattern that I can memorize. Thus I'm
_never_ sure what
> place I go back to when hitting the shortcut even once.
And I can
> imagine new users having the same problem.

I hope that if you try it now you will find it much more
predictable than it 
was pre-3.4.0. It wasn't until we finally ripped out KMDI
that it made sense 
to try and support tab-initiated file switching (which was
flat out 
impossible in KMDI, #kdevelop still echoes with my shouting
on that 
topic ;) )

I _think_ that the only navigation still not captured is
kate-initiated moving 
of the cursor - so we miss out on jumps caused by using
bookmarks via 
katepart (the kdevelop bookmarks plugin is supported).

Also, one type of navigation that is captured, but shouldn't
be, is stepping 
in the debugger - it unfortunately used editDocument() to
move the cursor. :(

> So maybe the problem we have to solve is actually just
making the
> addition to the history more easily to follow? One idea
would be having
> a highlight set on the back-button which then fades
out, everytime the
> history is changed...

Actually, that sounds both instructive and kinda cool.  And also
like 
something you would tire of quite quickly. :( As long as the
non-noob can 
turn it off it wouldn't be too bad, but I hate having
features that work best 
turned off. :(


// jens



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

On Wednesday 14 November 2007 22.08.17 Esben Mose Hansen
wrote:
> On Wednesday 14 November 2007 20:03:40 Jens Dagerbo
wrote:
> > Multiline tabbars are widely regarded as Bad
UI(tm). The reason is that
> > the active tabbar needs to be at the bottom to
indicated which document
> > is actually open, which in turns leads to the
requirement to _reorder_
> > the tabbars every time you switch document.
>
> Because, just highlighting the active tab is forbidden?


I dunno. I agree that highlighting might be better than
reordering, but I 
never saw it done like that. 

One reason could be that the typical tabwidget indicates
that one tab is 
active by making it look like it "belongs" to the
document (through less 
contrast between the active tab and document than the other
tabs have). Using 
tab highlighting instead would need to remove this visual
cue and instead 
effectively creates what looks like buttons, with one button
highlighted.

It's unpopular for a reason, and either way, using a
tabwidget this way to 
effectively _force_ the user to deal with the
too-many-files-open problem 
is.. the wrong solution. 

IMHO, of course. ;)

// jens



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

On Wednesday, 14. November 2007, Jens Dagerbo wrote:
> One reason could be that the typical tabwidget
indicates that one tab is
> active by making it look like it "belongs" to
the document (through less
> contrast between the active tab and document than the
other tabs have).
> Using tab highlighting instead would need to remove
this visual cue and
> instead effectively creates what looks like buttons,
with one button
> highlighted.

btw, try the Kate plugin that comes in the KDE 4 version.
it does multiline tabs with buttons, and seems to work not
all too bad.

-- jakob!

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

On 14.11.07 22:42:06, Jens Dagerbo wrote:
> On Wednesday 14 November 2007 21.53.18 Andreas Pakulat
wrote:
> > On 14.11.07 21:39:51, Jens Dagerbo wrote:
> > > What would a more predictable navigation
history look like? A popup that
> > > describes what you would jump to with
filenames and line numbers (like in
> > > your mockup.. (that's just the
"useless" KDev3 feature bound to a
> > > shortcut) Personally, I never found it
informative enough.
> >
> > Maybe you're biased because you know exactly what
events add an entry to
> > the history list.
> 
> Sadly, this is probably true. :(
> 
> > The problem is that unless you
> >
> > a) spend an hour or so playing with the history
> > b) or know the code exactly
> >
> > you have no idea what exactly adds an entry to the
history. At least I
> > didn't find a pattern that I can memorize. Thus
I'm _never_ sure what
> > place I go back to when hitting the shortcut even
once. And I can
> > imagine new users having the same problem.
> 
> I hope that if you try it now you will find it much
more predictable than it 
> was pre-3.4.0.

I never tried that until after 3.4.0 was released, IIRC ;)
 
> I _think_ that the only navigation still not captured
is kate-initiated moving 
> of the cursor - so we miss out on jumps caused by using
bookmarks via 
> katepart (the kdevelop bookmarks plugin is supported).

So basically any navigation, except bookmarks and normal
cursor
movements are tracked? Lets see if I can keep that in mind


> > So maybe the problem we have to solve is actually
just making the
> > addition to the history more easily to follow? One
idea would be having
> > a highlight set on the back-button which then
fades out, everytime the
> > history is changed...
> 
> Actually, that sounds both instructive and kinda cool.
 And
also like 
> something you would tire of quite quickly. :( As long
as the non-noob can 
> turn it off it wouldn't be too bad, but I hate having
features that work best 
> turned off. :(

I meant a rather subtle glowing effect on the button, not
something like
turning it completely red. Just something that you'd notice
without
really catching attention. Though I have to admit I still
like my
widget, even if it just produces file:line and a preview of
what the
line looks like...

Andreas

-- 
Break into jail and claim police brutality.

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

On Wednesday November 14 2007 22:56:41 Jens Dagerbo wrote:
> On Wednesday 14 November 2007 22.08.17 Esben Mose
Hansen wrote:
> > On Wednesday 14 November 2007 20:03:40 Jens
Dagerbo wrote:
> > > Multiline tabbars are widely regarded as Bad
UI(tm). The reason is that
> > > the active tabbar needs to be at the bottom
to indicated which document
> > > is actually open, which in turns leads to the
requirement to _reorder_
> > > the tabbars every time you switch document.
> >
> > Because, just highlighting the active tab is
forbidden?
>
> I dunno. I agree that highlighting might be better than
reordering, but I
> never saw it done like that.
>
> One reason could be that the typical tabwidget
indicates that one tab is
> active by making it look like it "belongs" to
the document (through less
> contrast between the active tab and document than the
other tabs have).
> Using tab highlighting instead would need to remove
this visual cue and
> instead effectively creates what looks like buttons,
with one button
> highlighted.

Here is a firefox/iceweasel plugin that does that:

http://tmp.garyr.net/

You have to change the tab option to see it in action

edit->preferences->Tabs->When tabs don't
fit->Multi Row

I think that works well. It does rather look like buttoms,
though rounded 
rects are used to give it a slight tabby look.


>
> It's unpopular for a reason, and either way, using a
tabwidget this way to

The unpopularity might just be fashion. Currently, too many
applications gets 
tabs, whether it makes any sense or not. Tabs are just the
new hotness.

> effectively _force_ the user to deal with the
too-many-files-open problem
> is.. the wrong solution.

I don't understand that. Can you elaborate a bit? Where is
the forcing? It's 
just a better way of overflowing the tab wigdet, is all.

(And imho, a vertical open-file-list would still be better)



-- 
regards, Esben

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

On 11/15/07, Esben Mose Hansen <kdemosehansen.dk> wrote:
> On Wednesday November 14 2007 22:56:41 Jens Dagerbo
wrote:
> > effectively _force_ the user to deal with the
too-many-files-open problem
> > is.. the wrong solution.
>
> I don't understand that. Can you elaborate a bit? Where
is the forcing? It's
> just a better way of overflowing the tab wigdet, is
all.

Try opening 50 files in a multiline tab UI - you will feel
"forced" to
close some to have some screen space left to actually view
your
documents.


> (And imho, a vertical open-file-list would still be
better)

Well.. then we are in full agreement! 

Kill the tabwidget, it is the WRONG choice! Well.. IMHO.

// jens

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

On Thursday November 15 2007 11:29:52 Jens Dagerbo wrote:

> Try opening 50 files in a multiline tab UI - you will
feel "forced" to
> close some to have some screen space left to actually
view your
> documents.

Actually, I did say I would limit the number of lines to say
5 (I can see the 
firefox extension uses 3). After that, it would have to
scroll in some way.

>
> > (And imho, a vertical open-file-list would still
be better)
>
> Well.. then we are in full agreement! 
>
> Kill the tabwidget, it is the WRONG choice! Well..
IMHO.

That was my first point. It should be a plugin, like in
Kate, for those who 
for some reason edits very small projects or projects where
you only look in 
a few files at the time.


-- 
regards, Esben

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

On Wednesday 21 November 2007 16:06:35 Jörg Rüppel wrote:
> So +1 for stack based document history switching (NOT
edit history
> switching) from an otherwise happy KDevelop user.

+1 also from an otherwise happy KDevelop user 
It's really such an obvious thing that almost all
editors/IDEs/browsers have 
this days. 

Paulo

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