WelcomePageView - the 'Save As...' problem

El dc 07 de 06 del 2006 a les 02:12 +0200, en/na Matej Urbas
va
escriure:
> Hi
> 
> After some weeks of working with Monodevelop, I've
decided to
> participate in its development.

That's good news 

> 
> I have found a bug (or at least something I personally
consider a bug)
> and have tried to fix it - just for practice.
> 
> I have finished fixing it and I want to propose the
solution to be
> committed to SVN. In fact this is more a proposal to
extend the
> functionality of Monodevelop's architecture then
merely a bugfix. (The
> report of this endeavour is located below.)

IViewContent already has a property for checking if the view
is savable
or not: IsViewOnly. However, this property is not always
checked, as you
found out, so your fix is partially correct. If you change
the patch so
it uses IsViewOnly and provide ChangeLog entries, I'll
commit.

> 
> Aside from this problem, I have looked into the TODO
section, and I must
> say that momentarily I'm especially interested in the
C# 2.0 parser.

As Miguel said, basic support is already working. I updated
the TODO
section.

> Also, I'm willing to improve the way code completion
works - there are
> still some issues about code completion in monodevelop
that I think
> should be fixed. 

There are many things that can be improved in this area.
Other replies
have already explained some ideas.

> I would also like to contribute to ASP.NET development
> support in monodevelop and Web Service integration.
> 
> Please, do point me to people who can give me some
assignments.

If you need any help, just ping me.

> 
> If it needs mentioning: I'm not a participant in
google's summer of code
> but I want to commit myself to monodevelop for a longer
period - if God
> will allow me to.
> ----------------------------------------
> Here goes the REPORT of the aforementioned problem:
> 
> PROBLEM: If you try to 'Save As...' the Welcome page,
it will throw an
> exception.
> DESIRED EFFECT: a) Not to enable 'Save As...' in the
Welcome page at all
> or b) fail silently.
> GENERALIZATION OF THE PROBLEM: Not to enable saving for
documents which
> don't make sense to be saved.
> 
> REPORT OF THE SOLUTION:
> - I have added an IsSavable property to IViewContent
> - I have added a SavableChanged event to IViewContent
> - I have added an update handler for the SaveAs command
in
> ViewCommandHandlers
> - I have changed the behaviour of methods 'Save' and
'SaveAs' in
> MonoDevelop.Ide.Gui.Document to make proper use the
newly added
> IsSavable property
> - I have changed some (but possibly not all) classes in
some AddIns to
> accommodate to changes made in IViewContent
> - Made some changes in the WelcomePageView to fix the
exception that
> happens at 'Save As...' (also, there is a minor fix
in the code that is
> not related to the problem)
> 
> Diffs are attached
> 
> See ya
> 
> P.S.: I find it a wonderful coincidence that my first
attempt to
> contribute involved the WelcomePage.
> ---
> Matej Urbas
> 
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Lluis Sanchez wrote:
> IViewContent already has a property for checking if the
view is savable
> or not: IsViewOnly. However, this property is not
always checked, as you
> found out, so your fix is partially correct. If you
change the patch so
> it uses IsViewOnly and provide ChangeLog entries, I'll
commit.
>   
Indeed, I didn't notice that property - will be more
careful in the future.

The patches are hopefully attached to this post.
> As Miguel said, basic support is already working. I
updated the TODO
> section.
>   
Very well. The only thing that needs to be done is to modify
code 
completion so that it will use the C# 2.0 parsed type data.
Am I correct?
> If you need any help, just ping me.
>   
Aye.
---
Matej
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Matej Urbas escribió:
> ...
>> As Miguel said, basic support is already working. I
updated the TODO
>> section.
>>   
> Very well. The only thing that needs to be done is to
modify code 
> completion so that it will use the C# 2.0 parsed type
data. Am I correct?
I think we should extend the AbstractClass and
AbstractMethod classes 
(and IClass and IMethod) to allow generic parameter
definition, because 
as of today there's no way to keep account of them (and
that means that 
no information about generic parameters can be shown on
completion 
window and class view, something that I think that should be
extended 
prior to modifying the C# binding).


	
	
		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

El dc 07 de 06 del 2006 a les 16:26 +0200, en/na Alejandro
Serrano va
escriure:
> Matej Urbas escribió:
> > ...
> >> As Miguel said, basic support is already
working. I updated the TODO
> >> section.
> >>   
> > Very well. The only thing that needs to be done is
to modify code 
> > completion so that it will use the C# 2.0 parsed
type data. Am I correct?
> I think we should extend the AbstractClass and
AbstractMethod classes 
> (and IClass and IMethod) to allow generic parameter
definition, because 
> as of today there's no way to keep account of them 

That's correct. This is the first thing to do. Once this is
done, you'll
need to change the parser database (so it is able to store
and search
for generic types) and the c# resolver.

> (and that means that 
> no information about generic parameters can be shown on
completion 
> window and class view, something that I think that
should be extended 
> prior to modifying the C# binding).
> 
> 
> 	
> 	
> 		
> ______________________________________________ 
> LLama Gratis a cualquier PC del Mundo. 
> Llamadas a fijos y mviles desde 1 cntimo por minuto. 
> http://es.voice.yahoo.com

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Lluis Sanchez wrote:
>> I think we should extend the AbstractClass and
AbstractMethod classes 
>> (and IClass and IMethod) to allow generic parameter
definition, because 
>> as of today there's no way to keep account of them

>>     
>
> That's correct. This is the first thing to do. Once
this is done, you'll
> need to change the parser database (so it is able to
store and search
> for generic types) and the c# resolver.
>   
 From what I see, a lot of restructuring will be needed. A
big 
undertaking, for sure. So, if you all agree that this is
where I should 
start working, I'll take a deep dive into it - questions
will ensue.

I will try to make a detailed plan of what I will have to
change, and 
surely, I will want to discuss these things with you.

In any case, I will take a very good look into reflection to
make sure 
that we follow the path of .NET 2.0 more closely - to better
adapt to 
potential CLI changes.

I'm taking notes of all your hints and wishes concerning my
tasks, so 
don't stop giving me input - nothing will be forgotten
(unless my disk 
drive gives up or I die - well, there are endless
possibilities - I 
should better say: nothing should be forgotten, nay? ;) ).

---
Matej
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

You've probably got plenty of ideas to be running with for
now, but if
you do get time, please also take a look at what eclipse
currently
does - some of it is even better than vs2003 (IMHO).
For example, eclipse has completion of parameters, so you
type a
method name and an opening bracket and it will fill in the
pararameters with ones of suitable types. Focus is first
passed to the
first parameter, where you can either accept the first
choice, choose
an alternative parameter from a list, or type something else
in; when
you press return, you move to the next parameter and again
can select
from a list. In many cases, it is possible to type the first
characters of the method name, press ctrl-space to complete
it, type
'(' and hit return a few times to enter a long line of
code. My
description probably hasn't done this justice, but it does
really make
you more productive.

Since you are working on code completion, perhaps it might
also be
worth considering looking at a more advanced search
interface too,
using the same data as used by code completion. In eclipse,
there is a
code search feature (different to plain text search) where
you enter a
full class, method or field name and can search for items
such as all
references to a method call, all implementors of an
interface, all
write accesses or read accesses of a  variable. Since all
this data is
already in memory or at least cached in an easily navigable
form, this
type of search can be much faster than a plain text search,
as well as
producing more relevant results.

Anyway, I guess there are probably more urgent features at
the moment,
such as showing the types and names of the parameters in a
tooltip.

Good luck!

Mark
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

The patch looks great, although it's missing the ChangeLog
entries for
each of the changed assemblies.

Thanks!
Lluis.

El dc 07 de 06 del 2006 a les 15:44 +0200, en/na Matej Urbas
va
escriure:
> Lluis Sanchez wrote:
> > IViewContent already has a property for checking
if the view is savable
> > or not: IsViewOnly. However, this property is not
always checked, as you
> > found out, so your fix is partially correct. If
you change the patch so
> > it uses IsViewOnly and provide ChangeLog entries,
I'll commit.
> >   
> Indeed, I didn't notice that property - will be more
careful in the future.
> 
> The patches are hopefully attached to this post.
> > As Miguel said, basic support is already working.
I updated the TODO
> > section.
> >   
> Very well. The only thing that needs to be done is to
modify code 
> completion so that it will use the C# 2.0 parsed type
data. Am I correct?
> > If you need any help, just ping me.
> >   
> Aye.
> ---
> Matej

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Lluis Sanchez wrote:
> The patch looks great, although it's missing the
ChangeLog entries for
> each of the changed assemblies.
>   
Here are the corrected patches.
> Thanks!
> Lluis.
Hopefully, I will soon provide more of those ;)
---
Matej
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Matej Urbas escribió:
> From what I see, a lot of restructuring will be needed.
A big 
> undertaking, for sure. So, if you all agree that this
is where I 
> should start working, I'll take a deep dive into it -
questions will 
> ensue.
>
> I will try to make a detailed plan of what I will have
to change, and 
> surely, I will want to discuss these things with you.
>
> In any case, I will take a very good look into
reflection to make sure 
> that we follow the path of .NET 2.0 more closely - to
better adapt to 
> potential CLI changes.
I think the best way to take is to mimic how Reflection
works: just 
adding a "IsGeneric" property to IClass, and
"TypeParameters" to both 
IClass and IMethod. This code should be enough (Reflection
makes 
distinction between open and closed generic types and so
on...), because 
ReturnType, the only place where open/closed generic types
could be used 
indeed takes a string.
Also, in that way we could prevent changing every add-in:
just add 
public bool IsGeneric { get { return false; }} would be
enough for 
updating them.
What do you think?
>
> I'm taking notes of all your hints and wishes
concerning my tasks, so 
> don't stop giving me input - nothing will be forgotten
(unless my disk 
> drive gives up or I die - well, there are endless
possibilities - I 
> should better say: nothing should be forgotten, nay? ;)
).
>
I hope you don't die. At least before ending the transition



	
	
		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y móviles desde 1 céntimo por minuto. 
http://es.voice.yahoo.com
_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

The patch is now in SVN.
Thanks!
Lluis.


El dj 08 de 06 del 2006 a les 02:03 +0200, en/na Matej Urbas
va
escriure:
> Lluis Sanchez wrote:
> > The patch looks great, although it's missing the
ChangeLog entries for
> > each of the changed assemblies.
> >   
> Here are the corrected patches.
> > Thanks!
> > Lluis.
> Hopefully, I will soon provide more of those ;)
> ---
> Matej
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-listlists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st