How can i contribute to sphinex?
For now you could start by writing files in Markdown. A special index file would point to all the markdown files. We don’t need to be strict about formatting in this stage. Sphinx needs to be incorporated into the CMake build process. That will take me a few days, so I will leave it on hold for now.
Would you start with the installation part in the manual?
Could you sent me an example markdown i have no idea how to start one.
Would you start with the installation part in the manual?
I would so straight into program utilization. Although newcomer Linux users would benefit the most from install instructions.
Could you sent me an example markdown i have no idea how to start one.
Our Readme and Build instructions are written in Markdown:
I took a look at the but proberly still need to search up a tutorial
Does md support images?
There plenty tutorials online for it’s a very simple language. Markdown does support images. Here’s an example of that from Imaginary Teleprompter’s readme:
 The URI can be relative to the current folder.
So you have to figure out a smart path system for all pictures or just dump them in a single one?
In web design we usually set a folder aside for images. We could have an images folder inside of the documentation folder, like this:
When it comes to sub-pages, it could be done in two ways:
I’d go for the first approach for pictures that could be used more than once, and the second approach for images that wouldn’t be used outside of the sub-page’s context.
That aproach seems pretty good.
You looked into setting up shinex yet?
I haven’t gotten to it yet. This weekend I started a new prototype for testing the multi-screen feature in combination with the latest version of a framework that I plan on using for an alternate UI. It’s far from done, but I’ll pause and take on this when I get really stuck. Sometimes it’s hard for me to tell when I’m really stuck or just not trying hard enough.
Whats new in the alternated ui?
It’s a UI that separates the editor from the prompter, made using KDDockWidgets instead of Kirigami. It’s not meant to replace QPrompt’s Kirigami interface but to provide a more efficient workflow for in-studio use.
Here’s a screenshot of what it looked like when I paused working on it:
The Kirigami UI is a better option for users of mobile devices, such as phones and tablets. Here you can see QPrompt running on a PinePhone Pro:
https://x.com/JCuperino/status/1482379644716425222
that seems like a great way to allow adjustments whilst its runnig
It is. The tricky part is to restructure the code so docks can communicate with each other in that version, while the Kirigami version continues to work. It’s not too difficult to achieve, but I do question if it’s worth the effort, since Kirigami can’t run on the iPad. It would probably take me less time to recreate QPrompt in Flutter than to port all the KDE frameworks over… Having said that, porting the frameworks would be better for the KDE ecosystem.
I sometimes get the feeling the enduser doesnt even care much about the different framworks. They just want working Software.
That’s true. Most have no reason to care.
What I meant is that porting the frameworks would enable KDE developers to port their apps over to Apple’s mobile ecosystem. The benefit would go beyond QPrompt.
i guess the effort would go up by alot in doing so?
It’s hard to say, but for me yes. I don’t have experience developing for iOS or iPadOS.
I heard developing for ios requires you to have a mac.
That is correct. You can do some stuff in other systems, but you need a relatovely recent Mac to sign your packages for distribution.
