| Age | Commit message (Collapse) | Author |
|---|
|
The actual compilation process now happens with xbuild. The root makefile
just issues an "xbuild Main.sln" call. If you type 'make' in a subdirectory
you will issue an 'xbuild foo.csproj' for that dir and every subdir. This is
slightly slower than building Main.sln directly if many subdirs are being built.
'make dist' is now implemented with a call to 'git archive' which means our tarball
really does contain everything we need to build monodevelop (yay!).
Makefile integration is now disabled (it's unnecessary).
We now put test assemblies in build/test too to avoid polluting build/bin and build/Addins
|
|
Also revert KeyboardShortcut back into a struct to save space (soptimization ftw)
and fixed Mac keybinding menu strings to upper-case the character keys.
|
|
|
|
|
|
The new RecommendedSize property is a non-strict version of
the AcceptedSize property.
Images not matching the RecommendedSize are allowed to be set,
but are given a warning overlay in the UI to signal to the user
that the chosen image does not fit the recommended size.
|
|
|
|
Fixes bug #4137.
|
|
|
|
|
|
Still not perfect - would be good to have more validation messages -
but at least we avoid a lot of error dialogs now.
|
|
|
|
Fixes bug #3431.
|
|
|
|
|
|
|
|
…caused by Gdk.Rectangle.Bottom breakage in GTK#.
|
|
The PList editor displays this value in the 'Property' column, so let's
call it 'newProperty' instead of 'newNode'.
|
|
We can get the 'key' parameter from the tree we pass in, so don't
require it.
|
|
what to add'
If we have no idea what to add (i.e. the key is not part of the schema), then we should
just add a regular PString/whatever and let the user change it as required. If the key
is part of the schema, but we have used all the allowed values, just do nothing.
|
|
a key
Add the ability to figure out what values are valid in a particular situation so
the plist editor only displays things which can be created.
|
|
There are several places which need to iterate over a pobject if it
is either a PArray or PDictionary. We typically need both the Identifier
and the PObject itself, so we enumerate as a KeyValuePair. If the object
is a dictionary, we can simply use the Key and Value of the dictionary itself
If the object is a PArray, we can get the Identifier by getting the 'Value'
property for any PValueObjects.
|
|
|
|
When editing a pboolean value we simply add the 'Yes' and 'No' options
to the cell renderer combo. This way we properly support all pbooleans
whether or not they are in the PListSchema.
|
|
All PObjects in the tree *must* exist in the results dictionary.
|
|
This allows us to add the correct key (where it exists) without adding
duplicates.
|
|
|
|
Do not null deref when custom keys are added which have no
related schema item. In this scenario we should just use an
empty IEnumerable as there are no known keys.
|
|
If I have a top level key 'Foo' which is a dictionary, when adding a new
value to the dictionary the key renderer should only offer me keys which
are valid to be placed inside 'Foo'.
|
|
We did not handle this right for the combobox in the KeyRenderer for
when the keys were being actively edited.
|
|
If a PObject can have subvalues and does not specify a required one,
automatically create one anyway. This helps as 99% of the time the
user will want to immediately add a child to a PArray and begin
editing it. Similarly for PDictionary.
|
|
We should ensure we sort by either identifier *or* by description, depending
on what mode is active. This ensures everything is always alphabetical.
|
|
If we have a PNumber with value '1' and change it to '2', we need
to update the value in the 'Identifier' column of the tree store.
|
|
We should do our best to store the 'Identifier' for every entry in the
tree model so that the rest of our code can correctly match against it.
For cases like PNumber, PString, PBoolean, the identifier is the same as
the value so store that in the model.
|
|
We can now tell *exactly* what created a value so we can properly detect
when its Type should be rendered. We can also properly detect the identifier
and description for many more keys and tell when something should be editable
or not.
|
|
Rendering text for the 'identifier' column for children of a
PArray is confusing. There's no point in rendering 'Item1', 'Item2'
etc. Just leave it blank.
|
|
This way we can sort alphabetically by description or by identifier
in the most optimal way.
|
|
|
|
All possible values of this type are known (either 'Yes' or 'No'), so
insert these into the Values array of any PBoolean type.
|
|
|
|
known value
If we have a Key/Value object for the current item, we know exactly what type it
needs to be so we should not allow the user to edit it.
|
|
|
|
|
|
The same code is executed by both paths now. This removes a bunch of duplication
and will make it easier to add fancy features later on.
|
|
|
|
Refactor 'AddToTree' so we can handle both PDictionary and PArray objects
in the same method. Removes duplication of some tricky code.
|
|
|
|
|
|
|
|
We now support PList keys with arbitrary depth. I.e. you can have a key
which contains 5 values, each of which contain 5 values, etc. This allows
us to give proper 'code completion' when editing known keys in the plist
editor. Also add features like 'required' so we know when a value must
be created for the key to be valid
|
|
|
