Re: status displayer

On 21.06.07 16:32:21, David Nolden wrote:
> On Thursday 21 June 2007 15:53:56 Andreas Pakulat
wrote:
> > On 21.06.07 09:24:47, Kris Wong wrote:
> > > > I personally never even look at the
statusbar, simply because its
> > > > "too far away", I nearly have
to move my head to see its content.
> > >
> > > I look at it all the time.  I have the
"Show type evaluation in status
> > > bar" option turned on though.
> >
> > Well, everytime I need it to work it doesn't (and
thus CC doesn't work
> > either). Thats my impression. Also  I don't really
see the use-case, but
> > maybe thats because I have variables that explain
what type they have...
> 
> Then you should have reported your problems when that
stuff was in 
> development. For me CC works quite ok now, in about 95%
of all cases in 
> kdevelop-4 source.

Well, I more less accepted that CC fails sometimes so I saw
no point in
reporting each and every case where CC failed. Also the
above doesn't
mean its only working 1% of the time, it only means that
often when I
want CC I end up looking into the apidox because it failed.


> > > It's also handy for the progress bar that
> > > is displayed when opening the project.  It
gives me some indication that
> > > KDevelop is actually doing something while I
wait for my project to
> > > open.
> >
> > Well, for me the progress bar doesn't work
properly. There seem to be 2
> > progress bars "doing something" also.
And kdevelop is usable before the
> > progress bar is finished. Also I suspected this to
be the c++ parser,
> > but I don't see why it would run every time I open
a project (where no
> > files are open!). Thats just completely useless,
the "wait" mouse-cursor
> > is indicator enough that kdevelop does something
(for me that is).
> 
> Yes sometimes that progress-bar thing happens. See
comment above. However I 
> don't see what that has to do with kdevelop-4's
status-displayer.

Well, if there's nothing usable to display, then we don't
need the
statusbar in kdev4. And I personally don't see any usable
(for me)
information in it.

> Personally I think something like a status-bar would be
useful, at least 
> something is needed to show for example the
parsing-progress.

Why? Seriously. The parsing is a background thing that -
unless I'm
mistaken - happens on file-open. I don't see the need to see
a
progressbar for this. I do agree we need a way to
communicate some
things to the user, but a transparent balloon is IMHO much
better here
because it takes away space only for a certain amount of
time.

Oh, and I just forgot: The progressbar for the parsing is
eventually
already existing, unless I'm mitaken ParseJob is a KJob
subclass and
thus kuiserver will display it. Maybe we can have a
progresviewer for
kdevelop-jobs as a plugin, then you'd see the progress of
various things
all in 1 place, that can be disabled if you want it (or
moved to another
screen/desktop).

> It would also be great if there was some kind of
filterable log available, for 
> debugging and also later for problem-reporting. A
normal user could 
> copy-and-paste messages from the log and ask for help.

We have the outputview for exactly that purpose. 

Andreas

-- 
Beware the one behind you.

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

On Thursday 21 June 2007 16:56:34 Andreas Pakulat wrote:
> > Personally I think something like a status-bar
would be useful, at least
> > something is needed to show for example the
parsing-progress.
>
> Why? Seriously. The parsing is a background thing that
- unless I'm
> mistaken - happens on file-open. I don't see the need
to see a
> progressbar for this. I do agree we need a way to
communicate some
> things to the user, but a transparent balloon is IMHO
much better here
> because it takes away space only for a certain amount
of time.

The problem is that the parsing influences what the user can
do: 

- Code-completion will only work correctly after a file and
all it's includes 
are parsed, which may take some time when there is many
includes.

- Refactoring will only work after all files of the whole
project are parsed

So the user should know about these progresses. Probably the
status-bar isn't 
the right place to show these progresses. Maybe a bubble
that you could show 
and hide on demand would be best for parsing a whole
project, while for the 
first a progress shown per-file directly within kdevelop
would be best.

> Oh, and I just forgot: The progressbar for the parsing
is eventually
> already existing, unless I'm mitaken ParseJob is a KJob
subclass and
> thus kuiserver will display it. Maybe we can have a
progresviewer for
> kdevelop-jobs as a plugin, then you'd see the progress
of various things
> all in 1 place, that can be disabled if you want it (or
moved to another
> screen/desktop).

But it really isn't very user-friendly having to open
another application just 
to see whether your project is parsed, that belongs into
kdevelop.

There's also other statuses to be displayed: For example
when you callaborate 
on a file, you would maybe like to know about the
connection-state, whether 
the file is locked, etc. We need some way to display such
information. When 
there's no status-bar then we need another place suited to
display such 
stuff.

One thing comes into my mind that's really useful about the
status-bar: 
The line-number, I wouldn't want to miss that

>
> > It would also be great if there was some kind of
filterable log
> > available, for debugging and also later for
problem-reporting. A normal
> > user could copy-and-paste messages from the log
and ask for help.
>
> We have the outputview for exactly that purpose.
>

That's great.

greetings, David


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