Re: KDE

On 11.06.07 09:30:09, dukju ahn wrote:
> 2007/6/11, Andreas Pakulat <apakugmx.de>:
> > On 11.06.07 04:06:57, dukju ahn wrote:
> > > 2007/6/11, Andreas Pakulat <apakugmx.de>:
> > > > On 11.06.07 07:42:46, Dukju Ahn wrote:
> > > > > SVN commit 673863 by dukjuahn:
> > > > >
> > > > > Implement show next error in
makebuilder.
> > > > > Add IOutputView::currentId(). This
is needed by outputview users
> > > > > to know which page, and thus which
model, is active currently.
> > > >
> > > > This will not work properly when there
is more than 1 outputview. Or
> > > > lets say it will be confusing, because
next/prev will jump in the output
> > > > tab that was last activated, not
necessarily the one that the user
> > > > currently looks on. We need to find
another way to do this, IMHO.
> > >
> > > Is the last activated tab is different from
currently looked tab? I thought
> > > its same.
> >
> > Yes, because you may have 2 outputviews open at
the same time. But they
> > don't have the same tab shown at the same time.
Now with the current
> > code you show next/prev error for the tab that was
last activated in
> > either of the 2 views. However that may not be
what the user wants,
> > maybe he opened the 2nd view to monitor the build
of another project and
> > to see that he needed to activate the tab showing
the build. Now to use
> > the next/prev thing he needs to change to a
different tab and then back
> > to the one with the errors in the first
outputview.
> 
> I got it. Then we should discuss which view among the
bunch of other views
> will have focus, and how does the user specifies which
view should be active.
> Or, More radically, we can introduce the concept of
"active tab".
> Only after the default view(or tab) is set, we can use
shortcut key to
> show next/prev.

Yeap, that is my idea as well, am not sure though wether its
the best
thing to do, it surely is the easiest thing.

> To enable these, one option is introducing context menu
in each view,
> such as "set as default".

I don't like "default" as name and I don't think a
context menu is good
(too much work to change). 

What about a button on the left corner of the tabs that just
make the
outputview where its clicked "active". Then we can
go on with visible
tab receives next/prev signals. This is rather easy to
implement, all
that is needed is the button and then all outputwidget's
will connect to
the next/prev signals, but they will only do something if
the button is
pressed. Well, a signal is also needed, such that all
outputwidgets get
notified when another widget is activated.

Also I guess we should do something with the background of
the
outputwidget class (or something else) to make it more
visible which
outputview is active.

> > > but no big deal here Anyway, I have another
idea to enable this. See
> > > my different post.
> >
> > That wouldn't help at all. We need to think about
an easy way to say: I
> > want next/prev output-shortcut go through this
outputview-tab.
> 
> I can't understand "next/prev output-shortcut go
through this outputview-tab."

Thats what the user wants, if he presses "next/prev
shortcut key" he
wants this to cycle through the outputview tab that he
"wants", not the
last one he clicked on.

Andreas

-- 
Long life is in store for you.

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

> > I got it. Then we should discuss which view among
the bunch of other views
> > will have focus, and how does the user specifies
which view should be active.
> > Or, More radically, we can introduce the concept
of "active tab".
> > Only after the default view(or tab) is set, we can
use shortcut key to
> > show next/prev.
>
> Yeap, that is my idea as well, am not sure though
wether its the best
> thing to do, it surely is the easiest thing.
>
> > To enable these, one option is introducing context
menu in each view,
> > such as "set as default".
>
> I don't like "default" as name and I don't
think a context menu is good
> (too much work to change).
>
> What about a button on the left corner of the tabs that
just make the
> outputview where its clicked "active".

Button is good. What I'm worried is if it is small, it is
hard to be clicked.
Besides the button, we can set active when user double
clicked
certain tab or tab-title. Both of the thing( button,
dblclick ) should be
implemented.

> Then we can go on with visible
> tab receives next/prev signals. This is rather easy to
implement, all
> that is needed is the button and then all
outputwidget's will connect to
> the next/prev signals, but they will only do something
if the button is
> pressed. Well, a signal is also needed, such that all
outputwidgets get
> notified when another widget is activated.
> Also I guess we should do something with the background
of the
> outputwidget class (or something else) to make it more
visible which
> outputview is active.

Yes.

> > > > but no big deal here Anyway, I have
another idea to enable this. See
> > > > my different post.
> > >
> > > That wouldn't help at all. We need to think
about an easy way to say: I
> > > want next/prev output-shortcut go through
this outputview-tab.
> >
> > I can't understand "next/prev output-shortcut
go through this outputview-tab."
>
> Thats what the user wants, if he presses
"next/prev shortcut key" he
> wants this to cycle through the outputview tab that he
"wants", not the
> last one he clicked on.

Isn't this choosing an active tab?  Then another shortcut
key is needed,
because next/prev error only acts on already installed
active tab.

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