Quickopen dialog

Hi! I'm thinking about creating a new quickopen dialog for
Kdevelop-4.

Since we do header-parsing by default now, we can list
files, or items 
contained in files, that were included into the
translation-unit represented 
by the current open document. This is especially useful when
looking up 
documentation, or when working without a project at all.
- We can show additional information embedded into the
quickopen list, using 
the technology from the completion list(for this reason the
quickopen widget 
should be a little bigger now).

Still, since it might be confusing sometimes getting all
that out-of-project 
content, I think it's useful being able to disable those
items from the GUI.

Also I think it would be useful if we would create only a
single 
implementation of the quickopen-widget, that can choose
different models 
based on a model/view approach. That way it's easy to switch
between 
Files/Classes/Functions, or maybe even list them all within
one list, so such 
options is are shown in the mockup.

We can still provide the quickopen-function,
quickopen-class, and 
quickopen-file shortcuts, by preselecting the correct item
for each case.

Eventually we could also hide those options between an
"advanced" button that 
would make them show up, however I think this isn't needed
as long as it's 
only those few options.

I'm posting this to the list for discussion because Andreas
has some concerns 
about having gui-items in the quickopen dialog.

So discuss please. 

Greetings, David

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

On 01.10.07 02:14:58, David Nolden wrote:
> Hi! I'm thinking about creating a new quickopen dialog
for Kdevelop-4.
> 
> Since we do header-parsing by default now, we can list
files, or items 
> contained in files, that were included into the
translation-unit represented 
> by the current open document. This is especially useful
when looking up 
> documentation, or when working without a project at
all.
> - We can show additional information embedded into the
quickopen list, using 
> the technology from the completion list(for this reason
the quickopen widget 
> should be a little bigger now).
> 
> Still, since it might be confusing sometimes getting
all that out-of-project 
> content, I think it's useful being able to disable
those items from the GUI.
> 
> Also I think it would be useful if we would create only
a single 
> implementation of the quickopen-widget, that can choose
different models 
> based on a model/view approach. That way it's easy to
switch between 
> Files/Classes/Functions, or maybe even list them all
within one list, so such 
> options is are shown in the mockup.
> 
> We can still provide the quickopen-function,
quickopen-class, and 
> quickopen-file shortcuts, by preselecting the correct
item for each case.
> 
> Eventually we could also hide those options between an
"advanced" button that 
> would make them show up, however I think this isn't
needed as long as it's 
> only those few options.
> 
> I'm posting this to the list for discussion because
Andreas has some concerns 
> about having gui-items in the quickopen dialog.

 As I
agree with the conceptual stuff, I'll just comment on the
mockup:

a) I'd group the options above the list because they
influence the list
and at least to me it makes more sense to have options
changing the list
before the list instead of after (think of reading from top
to bottom,
at least in many languages on earth).

b) Translation Unit, does fit well? Wouldn't file fit better
here and be
better known to the "general audience"? IMHO its a
term too close to the
theoretic part of programming languages.

Hmm, c) put a screenshot of completion widget into the empty
area where
the list is ;)

> So discuss please. 

Done.

Andreas

-- 
Slow day.  Practice crawling.

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

On Monday 01 Oct 2007 2:40:03 pm Andreas Pakulat wrote:
> b) Translation Unit, does fit well? Wouldn't file fit
better here and be
> better known to the "general audience"? IMHO
its a term too close to the
> theoretic part of programming languages.

You are right! As "general audience" i do not know
what that "Translation 
Unit" means!  Does it
just mean any string int he code that is meant to be 
translated for localization?
-- 
Cheers!
kitts

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

On 01.10.07 21:46:50, kitts wrote:
> On Monday 01 Oct 2007 2:40:03 pm Andreas Pakulat
wrote:
> > b) Translation Unit, does fit well? Wouldn't file
fit better here and be
> > better known to the "general audience"?
IMHO its a term too close to the
> > theoretic part of programming languages.
> 
> You are right! As "general audience" i do not
know what that "Translation 
> Unit" means!  Does it
just mean any string int he code that is meant to be 
> translated for localization?

Just to educate you: Translation unit usually means a file
in C++ and
also other languages. Its just an arbitrary amount of code
that is to be
translated from the source language into the binary for (or
interpreted
in the case of script languages). Its OTOH also used in the
background
of translating texts (real-world as well as program-texts),
at least
thats what wikipedia told me 

Andreas

-- 
You will experience a strong urge to do good; but it will
pass.

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

On Monday 01 October 2007 19.09.44 Andreas Pakulat wrote:
> On 01.10.07 21:46:50, kitts wrote:
> > On Monday 01 Oct 2007 2:40:03 pm Andreas Pakulat
wrote:
> > > b) Translation Unit, does fit well? Wouldn't
file fit better here and
> > > be better known to the "general
audience"? IMHO its a term too close to
> > > the theoretic part of programming languages.
> >
> > You are right! As "general audience" i
do not know what that "Translation
> > Unit" means!  Does it
just mean any string int he code that is meant
> > to be translated for localization?
>
> Just to educate you: Translation unit usually means a
file in C++ and
> also other languages. Its just an arbitrary amount of
code that is to be
> translated from the source language into the binary for
(or interpreted
> in the case of script languages). Its OTOH also used in
the background
> of translating texts (real-world as well as
program-texts), at least
> thats what wikipedia told me 

Unless I'm completely mistaken, a "translation
unit" in C/C++ refers to all 
the "visible code" from one file context, that is
it consists of the file 
being compiled _and all files included from that file_. 

I assume the "translation unit" setting in the
suggested dialog would include 
information from all the header files as well, in which case
I think the name 
is quite fitting. It isn't quite language-agnostic though.

// jens




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

On Tuesday 02 Oct 2007 12:53:26 am Jens Dagerbo wrote:
> > > You are right! As "general
audience" i do not know what that
> > > "Translation Unit" means!  Does it
just mean any string int he code
> > > that is meant to be translated for
localization?
> >
> > Just to educate you: Translation unit usually
means a file in C++ and
> > also other languages. Its just an arbitrary amount
of code that is to be
> > translated from the source language into the
binary for (or interpreted
> > in the case of script languages). Its OTOH also
used in the background
> > of translating texts (real-world as well as
program-texts), at least
> > thats what wikipedia told me 
>
> Unless I'm completely mistaken, a "translation
unit" in C/C++ refers to all
> the "visible code" from one file context,
that is it consists of the file
> being compiled _and all files included from that
file_.
>
> I assume the "translation unit" setting in
the suggested dialog would
> include information from all the header files as well,
in which case I
> think the name is quite fitting. It isn't quite
language-agnostic though.

Thank you both for the information. Everyday i learn
something new!  But i 
would be worried about using terms like that in the GUI. I
would rather that 
it clearly states something like "Current file and all
included headers"
-- 
Cheers!
kitts

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