The new md files need to be added to the dev-docs sources so they should up in an IDE.
You also can update the protocoltypes.h and the mainpage .

@laz-001 we have landed the dev doc starting parts so be sure you rebase upon our current master, Just make sure you rebase Don't Merge update that will cause landing issues later on.

I am going to say we don't need the tutorial and much of what is in the reference should perhaps be doxygen comments within protocolTypes or other files .. ill let @nbolton comment there as my main issues were related to dev document deployment.

@sithlord48 , i noticed the "about" section points to "deskflow.org", which points back to the repo. Maybe replace it with "https://deskflow.github.io/deskflow/"

@nbolton , you can review now.

I would not since the about should be user facing but we do need to link something to the dev docs

You have removed my links from the main page to the other pages i.e building / contributing also you have made no links to the new pages how are the users expected to find the pages ?

The diagram is fine just put links to the other markdown files.

@whot, could you take a look.
@nbolton , can we speed this up a bit? I'd like to finish this before going on with your other 2 main issues:

• Clipboard support in XDG Desktop Portal (Wayland) #8031
• Persist Input Capture XDG Desktop Portal dialog (Wayland) #8032

You need to add a link to the protocol_reference.md in the main page

No need for repetitions, I'm awaiting the main review so i can go on.

👋 I am part of that main review, While we wait for the others to lets get my simple nits out of the way.

that's a lot of documentation to grok in one go

It's an iterative process. Personally, I see many things when the docs are public facing.

fixed those.

To speed things up: if you see more things, please feel free to directly commit.

@laz-001 I don't mean to jerk you around with EDataTransfer and EDataReceived. I got confused because we recently removed drag and drop file transfers, and I misremembered the purpose of these. I should have dug a bit deeper!

So close, just a couple of things I missed last review.

@nbolton , @sithlord48 , please HALT any reviews/comments, something went wrong.

Yeah, I was a bit confused by latest push. I'll hang fire until you say so.

Yeah, I was a bit confused by latest push. I'll hang fire until you say so.

should be ok now.

@laz-001 I don't mean to jerk you around

The thing is:

• github PR review is a flawed, inefficient process
  • this gets even worse if the material is textual (articles, docs etc.)

That's why: #8666 (comment)

@nbolton , all good from my side. This one needs to go in now, otherwise we end up refining for weeks. Each detail eats a day, further details are surely somewhere in there.

I'm at the point that I need the closure - this is more about 'closing this step' than about the bounty. Doc edit goes on for me once docs are live - that's how I do it usually.

As said, you can commit freely to this branch, I don't even care if I loose authorship (I purge/drop my github accounts anyways regularly).

@nbolton , all good from my side. This one needs to go in now, otherwise we end up refining for weeks. Each detail eats a day, further details are surely somewhere in there.

That is fine rather have it take abit longer to land then need a bunch of corrections after. Also makes issues easier to track since its all in one place.

You can commit freely to this branch, I don't even care if I loose authorship (I purge/drop my github accounts anyways regularly).

You just lmk and i will take this over for you so you do not have to deal with the nit picks .

No, no, I did NOT meant to give this PR even more live.

What i meant to say was: instead of introducing one more day/cycle/iteration, just commit your stuff and merge (instead of waiting for me). E.g. if @nbolton finds something 'final' tomorrow, just commit and merge.

🎉🎈 @laz-001 has been awarded $200 by Deskflow! 🎈🎊