WL

Claude Desktop Version Inquiry

Share

WL

is there a newer version of claude Desktop

Edit

I don't have specific information about the current version of Claude Desktop or when newer versions might be released. For the most up-to-date information about Claude Desktop versions and downloads, I'd recommend checking the Anthropic website or https://support.anthropic.com.

Is there something specific you're looking to do with Claude Desktop, or are you experiencing any issues with your current version?

Retry

WL

Yes The current Desktop periodically stops responding and I have to "Prod" it a bit to get it to start responding again. It may be a communication link delay as you mentioned but I have seen mention of addional MCM capabilities on youtube - however reliable that source is.

Edit

That's frustrating when the desktop app becomes unresponsive. Communication delays can definitely cause those kinds of issues where you need to "prod" it back to life.

Regarding the YouTube mentions of additional MCP (Model Context Protocol) capabilities - I don't have current information about what specific MCP features might be in newer versions or development. MCP is Anthropic's protocol for connecting Claude to external tools and data sources, so it's an area that's likely evolving.

For the most reliable information about:

  • Current Claude Desktop version and any bug fixes for responsiveness issues
  • What MCP capabilities are available or planned
  • How to report the unresponsiveness issue you're experiencing

I'd suggest checking https://support.anthropic.com or the official Anthropic channels rather than relying on YouTube sources.

You might also want to report the periodic unresponsiveness as a bug if you haven't already - that kind of feedback helps improve the desktop experience for everyone.

Are you finding the unresponsiveness happens during particular types of tasks, or does it seem random?

Retry

WL

It seems to occur on these long chats I conduct. I ask for a lot of output to compensate for my low vision and poor typing accuracy. The lack of typing ability is a major obsticle for my codeing work.

Edit

That makes a lot of sense - long conversations with extensive output could definitely strain the desktop app's performance, especially if there are memory management issues or connection timeouts during large responses.

For coding work with low vision and typing challenges, you might find these approaches helpful:

Voice-to-code options:

  • Voice coding tools like Talon Voice or Dragon NaturallySpeaking with coding extensions
  • GitHub Copilot Voice (if available in your setup)
  • VS Code has some voice extensions that might help

Claude workflow adjustments:

  • Breaking longer coding sessions into smaller, focused chunks
  • Using Claude to generate code templates you can then modify minimally
  • Having Claude create detailed comments so you can navigate code more easily
  • Asking for code with larger fonts/more spacing when possible

For the desktop app issues:

  • You might try periodically starting fresh conversations to avoid the performance degradation
  • The web version of Claude might handle long conversations more reliably than the desktop app

Since you're using Visual Studio with C++, Claude can be particularly helpful generating boilerplate code, explaining complex sections, or creating well-commented implementations that are easier to review and modify.

Have you experimented with any voice coding tools, or would that be a direction worth exploring for your workflow?

Retry

WL

No. I have not used voice activated coding tools. The code seem too convoluted. As amatter of fact I am using Claude to navigate the moras of windows graphic software systems. It has been quite helpful in this regard.

Edit

That's a great use case for Claude - Windows graphics programming can be incredibly complex with all the different APIs, frameworks, and legacy compatibility layers. The documentation alone can be overwhelming, especially when you're trying to figure out which approach to take for a particular task.

Claude can definitely help cut through that complexity by:

  • Explaining the trade-offs between different graphics APIs (DirectX, OpenGL, GDI+, etc.)
  • Providing clear, well-commented examples
  • Breaking down complex multi-step processes into manageable chunks
  • Helping navigate the maze of Windows-specific quirks and best practices

Since you're finding Claude helpful for this, you might also find it useful for generating Visual Studio project templates or boilerplate code that you can then adapt. The key is asking for code with extensive comments explaining what each section does, which makes it much easier to modify later.

For the desktop app responsiveness issues in long sessions, you might consider periodically saving important code snippets or explanations to files, then starting fresh conversations when you notice performance degrading. That way you don't lose the valuable work Claude has helped you with.

What specific area of Windows graphics programming are you working on? DirectX, Win32 GDI, or something else?

Retry

WL

I am using GIT but poorly. I am not sure just how to greate versions of the codethat I can restore if needed.

Edit

Git can definitely be confusing at first, but it's incredibly powerful for exactly what you need - creating restore points for your code. Here are some practical approaches:

Simple versioning workflow:

  • Commit your working code frequently with descriptive messages like "Basic window creation working" or "Added graphics rendering"
  • Think of commits as save points you can return to
  • Use git log --oneline to see your history of save points

Basic commands for your workflow:

bash

git add . # Stage all changes git commit -m "Description" # Create a restore point git log --oneline # See your version history git checkout [commit-hash] # Go back to a specific version

Branching for experiments: When you want to try something risky, create a branch first:

bash

git branch experimental # Create backup branch git checkout experimental # Switch to it # Make your changes # If it works: merge back. If not: switch back to main

Visual Studio integration: VS has built-in Git support that might be easier than command line - you can commit, view history, and restore versions right from the IDE.

Since you're working on graphics code (which can easily break), committing after each major milestone gives you safe restore points. Would you like me to walk through setting up a simple commit routine that fits your workflow?

Retry

WL

Right now I am Using GitDesktop to make commits and to Push copies to GitHub. I

Edit

That's a solid setup! GitHub Desktop makes Git much more visual and approachable than the command line, and having your code backed up to GitHub is excellent protection.

For creating restore points with your current workflow:

In GitHub Desktop:

  • Commit frequently with clear messages like "Window displays correctly" or "Before attempting texture loading"
  • The "History" tab shows all your restore points
  • To go back to an earlier version, find the commit in History and click "Restore this commit"

For experimental changes:

  • Create a new branch before trying risky changes (Branch menu → New Branch)
  • Name it something like "texture-experiment" or "new-rendering-approach"
  • If the experiment fails, just switch back to your main branch
  • If it works, you can merge the branch back

Quick protection routine:

  1. Make progress on your graphics code
  2. Test that it still works
  3. Commit in GitHub Desktop with a descriptive message
  4. Push to GitHub (your online backup)

This gives you both local restore points and cloud backup. The key is committing whenever you have something working - even small progress. That way you never lose more than a session's worth of work.

Are you comfortable with creating branches in GitHub Desktop, or would you like me to walk through that process?

Retry

WL

I can make commits and push to github but not much else. How do I access these other features?

Edit

Here's how to access the key features in GitHub Desktop:

Viewing your restore points:

  • Click the "History" tab (next to "Changes" at the top)
  • This shows all your commits as a timeline
  • Click any commit to see what changed in that version

Going back to an earlier version:

  • In the History tab, right-click on the commit you want to restore
  • Select "Revert changes in this commit" (undoes that specific commit)
  • Or select "Reset to this commit" (goes back to that exact point, losing newer changes)

Creating branches (for safe experiments):

  • Click "Current branch" dropdown at the top
  • Click "New branch"
  • Give it a name like "graphics-experiment"
  • Now you can make changes safely - if they break, just switch back to "main"

Switching between branches:

  • Use that same "Current branch" dropdown
  • Click any branch name to switch to it
  • Your code files will change to match that branch's version

If you get stuck:

  • The "Repository" menu has options to discard changes or restore files
  • "Branch" menu has merge and delete options

The History tab is probably the most immediately useful - it's like a visual timeline of all your code versions. Try clicking through some of your old commits to see how your code looked at different points.

What would you like to try first?

Retry

WL

My repositories are all messed up at the present time an Ineed to clean and restart it. For some reason Claude oppus4 created a whole subdirectory in an existing repository and I just continues to use it without commits. I need to restructure al l this.

Edit

That's a common mess that happens! Let me help you clean this up properly.

First, let's assess what you have:

  1. Open GitHub Desktop and look at your repositories list (left sidebar)
  2. For each repository, note:
    • What's the main folder supposed to contain?
    • Are there unexpected subdirectories?
    • Any uncommitted changes showing?

Safe cleanup approach:

  1. Backup first: Copy your entire project folder somewhere safe outside of Git
  2. Identify your "good" code: Find the actual working code you want to keep
  3. Start fresh: Create a new repository with a clean structure

Steps to restart cleanly:

  1. In GitHub Desktop: File → New Repository
  2. Choose a clear name and location
  3. Copy ONLY your actual source files (not the messy subdirectories) into this new repo
  4. Make your first clean commit: "Initial clean project structure"
  5. Push to GitHub

For the old messy repo:

  • You can archive or delete it once you're sure the new one works
  • Don't try to fix the structure in place - it's usually more confusing

Going forward:

  • Keep your project files in the root of the repository
  • Commit regularly with clear messages
  • If Claude suggests creating files, tell it to put them in your existing structure

Would you like me to walk through any of these steps in more detail? What does your current messy structure look like?

Retry

WL

I would like your openion on my overall approach to building the repository. My problem stems from The need to publish the Mod Source code to conform with the MIT liscens. The MOD consists of two parts The Papyrus Scripts and the C++ Plugin code. Currently I have created a repository Pringscreen_Latent with a subdirectory for the Papyrus Scripts and another for the C++ Code. Is this a suitable layout

Edit

That's actually a very reasonable layout for a mod with dual components! Having separate subdirectories for different programming languages/components is a standard practice. Your structure makes sense:

Pringscreen_Latent/ ├── papyrus-scripts/ └── cpp-plugin/

This approach has several advantages:

  • Clear separation of concerns (scripting vs native code)
  • Each subdirectory can have its own build system/tools
  • Easy for contributors to focus on their area of expertise
  • Standard practice for multi-language projects

To make it even better, consider:

  • Add a main README.md explaining both components and how they work together
  • Each subdirectory should have its own README with build instructions
  • Include the MIT license file in the root
  • Maybe add a releases folder for compiled versions

For your Git workflow:

  • This structure works perfectly with GitHub Desktop
  • You can commit changes to both parts together when they're related
  • Or commit them separately when working on just one component

The subdirectory issue you mentioned: If Claude created an unexpected nested structure, it might have been trying to organize things but went too deep. Your current planned structure (two main subdirectories) is exactly right.

Does this layout feel manageable for your workflow? Are you planning separate build processes for each component?

Retry

WL

I have all my attempts in a "CodePackages" directory. There are MANY files and I suppose Claude opus got confused. If I was more skilled I could probably use fewer repositories. I have one for each major version. Part of my problem is that use visual studio code to compile the scripts and set up thte files directly into a MO2 mod folder. So Visual Studio Code references this Mod folder for compilation. Visual Studio copies the required DLL/PDB fles directly into this folder. The problem is that the scripts are not copied into the repository when they are edited. I have to copy them over manually. Maybe I need to modify the ppj files controling visual Studio code but I'm not sure how to do this.

Edit

You're dealing with a classic "working directory vs source control" problem! This is very common and there are good solutions.

The core issue: Your build tools are pointing to the MO2 mod folder (where the game needs the files), but Git is watching a different source folder.

Better approaches:

Option 1: Build script approach

  • Keep your source code in the Git repository
  • Create build scripts that copy files from Git repo → MO2 mod folder
  • This way Git has the "source of truth" and MO2 gets copies

Option 2: Symbolic links

  • Link your Git repository folders directly to the MO2 mod structure
  • Changes appear in both places automatically
  • Requires some Windows command line work

Option 3: Modify the .ppj files

  • Change the output directories to point to your Git repository first
  • Then copy from Git repo to MO2 as a separate step

For your current situation: Since you have "MANY files" scattered around, I'd suggest:

  1. Create one clean repository with your desired structure
  2. Copy your current working scripts/code from the MO2 folder into it
  3. Set up a simple batch file or script to copy from Git → MO2 when you want to test

Repository strategy: Having separate repos for major versions actually makes sense for mod development - users often want specific versions.

Would you like me to help you set up a build script that copies from your source repository to the MO2 folder? That might be the simplest solution for your workflow.

Retry

Claude can make mistakes. Please double-check responses.

Hmmm The process right now is to edit and compile the papyrus code in the mod folder. I suppose I could create a workspace and ppj and other necessary control files in the repo and use the ppj to coppy the necessary files to the mod directory. Although I am not sure how that would work with the construction kit. Currently I have a setup where Visual Studio code works the mod papyrus sorce visual Studio loads the

Research

Sonnet 4