Open SelfRef opened 6 months ago
I have been thinking about this kind of thing lately, especially with the recent work on the desktop and introduction of regsvc
. I always sort of had it in mind that there 'isn't much' left to do before working on the setup/installer process to take care of everything, though considering that was all the way back in #81 I feel like it should just be expedited at this point. :thinking:
I'll have a think about how to do some sort of feature checklist so people know what's available and what isn't. Like some programs are there but not much of the functionality is (eg. Explorer is in a sort of 'read-only' state, there's no actions or anything yet).
I think at least getting a working version of setup would probably be best, mainly because some parts vary per-distro :dizzy_face: . Even just installing the packages isn't immediately obvious sometimes (Alpine does at least prompt you to generate a signing key, Void you have to index the packages before you can install them).
I'm just finishing up some testing for #293 . More or less there's a decent amount of distro coverage (minus Slackware for the moment because it seems like it needs more time invested in it). My idea for setup was to have it work akin to the actual Windows XP one - I did ponder last night about the AUR and how that'll work, probably if I add a switch to setup to tell it to skip to 'hey everything is installed' or something... :thinking:
For now a checklist would be good at least. My only struggle with it is 'features' - like the desktop exists, but it does not have desktop icons just yet, though it does now have the ability to set a wallpaper (via desk.cpl
). And the Plymouth boot screen under base/bootvid
exists as well, though I have not tested it on an encrypted disk, which I think needs it to be able to display a prompt... Stuff like that probably needs to be noted perhaps.
About the setup/installer, please take into account that different distros have their own policy about changing system/user settings. For Arch an installed package (except system ones) can:
So every action including enabling services, setting themes etc. should be done by the user. This is a different behavior than for example Ubuntu which packages often enable services upon install.
I again will bring the Chicago95 example because it's done almost as it should be - it has a GUI setup program that will install and setup all themes, but it will always do both, because that project is meant to be installed from source. I think that winxp-tc
targeting native packages should have something similar, but limited to configure everything by demand.
Also, the Chicago95 project has an extensive manual instruction to set up everything manually that setup app does - this is the only way to go while using a port package in that project. I consider it an essential part of every project, with auto-script/app being just an addition.
The best compromise that I often see in modern software is a wizard, like in this Fish prompt I use where you can install the package and just run the config wizard to set it up easily.
In terms of roadmap you can either use Projects feature and create a Kanban board (it integrates well with Issues) or a simple table with list of features, their statuses and notes so it will be clear if a feature is ready or not and what are current limitations (example).
The setup wizard would be a separate thing from the packages themselves - so you can still just manually install the packages if you want, it's an alternative "install and configure the stuff I want" sort of thing. Does that make sense? The AUR can remain as-is, I just didn't know whether it would be beneficial to have some way of launching the setup wizard in a 'just finish configuring stuff' step. :thinking:
Well, beneficial or not, the more such a setup will be flexible - the better, I think. Assuming there will be a full "do everything" wizard available, adding an option to run only a part of it won't be a big issue :smiley:
And in such a case even after installing the package natively, setup will be able to guide a user thought options, styles, etc.
Yeah I would like to consider as much as possible that might vary between distros and such. I definitely haven't got any plans to change how the packages currently work. It's good to have your input about the AUR and stuff, and I'll have a look into the GitHub projects thing when I get a chance. :grin:
Was pondering about instructions etc. yesterday on a walk and I was thinking about perhaps fleshing out some build/install information using the built-in Wiki feature on here. Might be a better, more flexible thing to update than a README. :thinking:
...using the built-in Wiki feature on here...
Definitely good idea. That's where such information should reside, and can be easily updated independently.
Cool fact: Wiki on GitHub is just a separate git repository internally and can be even used through git :smiley:
I've started dabbling with the wiki, such as this page here: https://github.com/rozniak/xfce-winxp-tc/wiki/Install-from-compiled-sources
I'll continue working on it, got to head out now tho :zipper_mouth_face:
Did some more work on it this evening - still dealing with a bit of jet lag so have not done the config stuff yet whilst my brain is a bit frazzled.
I'll tackle the rest tomorrow and the coming days, think main things are what you brought up - config guide (since manual is the only way atm :weary: ) and some information about what exists, the state stuff is in, however I think of to document it. I was thinking perhaps some kind of 'hacking' or 'contributing' guide for poking around individual components if that is useful at all.
@SelfRef Started looking at setup in #250 with some notes regarding AUR :grin:
Hi Rory,
From time to time I get a message asking how to use this project on Arch Linux. Considering there's much more components than just theme files for XFCE it would be much helpful to have a manual for currently available components. A great example I know is Chicago95's manual.
I've noticed that while Xfce standard themes are not often problematic, the
taskband
and other non-standard components are not obvious to enable. That's why I added a simple instruction to AUR package based on my own knowledge to help Arch users at least. I believe generic instructions should work for any distro in case of this project.The second thing worth adding would be a project state tracker list that shows what features this project already contains (ready to use) and what not (yet ready but in planned).
Here's my draft version from my observations, that you can use :
winver