This project is read-only.

source/downloads in bad state

Aug 9, 2010 at 8:40 PM
Edited Aug 9, 2010 at 8:40 PM

Hi,

It looks like something got screwed up on July 8th: there's a check-in with the comment "Checked in by server upgrade", but nothing exists (other than 2 xml files) in the repository any more.

...Unless you're just using codeplex as a host for your downloads, in which case I'll just download the release from last year.

 

--m

Aug 9, 2010 at 11:35 PM

That's exactly how it is.

The source code repository is at https://devel.nuclex.org/framework/svn/. I've split the library into two solutions, foundation (https://devel.nuclex.org/framework/svn/Foundation.Build/trunk/) and framework (https://devel.nuclex.org/framework/svn/Framework.Build/trunk/) - you'll need both if you want to compile it yourself.

Automated builds of everything can be found here: https://devel.nuclex.org/teamcity/guestLogin.html?guest=1.

Features of the development trunk over R984 are support for .NET 4.0 Beta1, some architectural changes, a few bugfixes for the GUI and updated versions of many third-party libraries used in the framework. There are no major features or groundbreaking additions you'll be missing out on by using the latest stable release.

 

Aug 9, 2010 at 11:42 PM

Ok, thanks for the heads-up.  Did you announce this on your blog, and I just missed it or something?

 

Incidentally, any plans on porting this to the Windows Phone 7?

Aug 10, 2010 at 12:24 AM

I used my own subversion repository from the start, so I didn't specifically announce anything about it on my website. But you're right, I should probably put a link somewhere here on the CodePlex, for the cutting-edge users :)

About Windows Phone 7, it depends on how far-reaching the changes will be. Without XmlDocument, I will at least have to rewrite the skin loader for my GUI library and probably some other area as well. I admit that I haven't tried building the code for WP7 yet. If I support it, WP7 won't be a very well tested platform because I don't plan on developing any games for WP7 myself (unless WP7 takes off like the iPhone, at least :P).

I will post something here on CodePlex when I made a decision.

Sep 20, 2010 at 1:18 PM

I commited a single revision to the CodePlex repository with a comment explaining where to find the sources for anyone clicking on the "Source Code" tab. I hope that helps :)

I'm also just finishing up my Windows Phone 7 port. All assemblies compile cleanly and the current Subversion trunk has the projects in it. Still need to do some more testing and I'm not sure what changes will be required in Nuclex.UserInterface (my GUI) to support touch input. If it simulates a mouse - all fine. If not, I'll have to extend the DefaultInputCapturer for this.

Sep 20, 2010 at 3:01 PM

Awesome, thanks.

I don't know if touches can simulate a mouse (my guess is no), but assuming I get some free time I'll let you know. :)

Sep 21, 2010 at 9:59 PM

I'm attempting to connect to your SVN to download the latest .NET 4.0 and XNA 4.0 source buts its prompting for authentication which I haven't seen any information on.

Wouldn't be too much of an issue as the builds are available, its just that any modifications to the Interface elements have to be made via source as the Screen property is flagged as internal and so isn't available. Was looking at making some alterations to the ListControl to allow the internal list to be a key, value pair for when you want a display value but an internal key for doing things with events.

Sep 21, 2010 at 10:34 PM

Subversion read access *should* be unauthenticated. If I browse to https://devel.nuclex.org/framework/svn in IE (or any other browser), I can navigate the repository and download source files.

A checkout on a virtual machine which never had Subversion on it before (and so couldn't have cached any credentials) worked without asking me for authentication. I also tried putting some typos in the URL or using http instead of https, but that didn't cause the server to ask for authentication either. If nothing helps, drop me a PM and I'll send you the sources.

-

What are you needing the Screen property for (I'm assuming you mean Control.Screen)? If I overlooked something, I could make it protected or even instead (hiding it wasn't a design choice, more of an attempt to avoid clutter in the public interface).

The ListControl is indeed extremely simplistic. Maybe I could provide a ListControl<ItemType> with a protected ItemToString() method (one would have to be careful to cache that string to avoid feeding the garbage collector, though). For your case, you could manage a list of keys in parallel to the list of strings in the ListControl, but I'm not at all opposed to adding more flexibility. I could still offer a class ListControl : ListControl<string> {} for simplicity and backwards compatibility :)

Sep 21, 2010 at 10:44 PM
Edited Sep 21, 2010 at 10:51 PM

Hah, ignore me, was using the wrong command in TortoiseSVN and was trying to import your SVN instead of check it out. Downloading fine now.

It was complaining about the lack of access to Screen because I attempted to create my own control outside of the assembly, as I couldn't compile the old source with additonal controls as it wasn't XNA 4.0 compatible. You check Screen inside the updateSlider method. Now that I have access to the source I could add my own controls, however adding things to your library would require me to update it each time with my code, or to submit my code for inclusion (do you accept that if its any good?).

I was thinking more of just having a ListControl<type> where by the internal store would be a dictionary which was keyed to be <type, string>.

Adding items would then need the string and the key and whilst the renderer would display the string value any events raised would pass the key value pair so that you could get at the key for that string. I have one list that feeds another list and my items are currently stored by GUID rather than by name.