Active Developers Needed


(Pedram Pourang) #22

I know this is old but in that time, I didn’t get email notifications. Anyhow, it’s good to know that, with PCMan’s recent work, libfm can’t be a blocker anymore :slight_smile:


(Henrik Christiansen) #23

I really agree with you on this. I work professionally with IT and in my work we have release plans for all our software.

It is the best to ensure that people are committed properly to the task.

I am not a developer but will assist in QA/Test in any way I can.

Keep up the excellent work!


(Alf Gaida) #24

@hxcdk - the problem is that we can’t plan all things right now. We should, but we can’t. Right now it is as in Murphy’s Law - behind evey big problem hide some smaller problems. Behind every small problem there might hide a big problem. So we hopefully solved the really big things right now and (libfm, partly menu-cached) and can go on the smaller things. But these big blockers needed a solution first to make plannings possible in the first place.

The fine thing is that with every removed blocker LXQt gets more mature - and that it make sense to polish it more and more. Maybe more clear: It just make no sense to polish a component when we know that it will be rewritten from the very ground.


(Henrik Christiansen) #25

@agaida Thanks for the reply. It is nice to know that things are progressing.

I will look forward to follow the project!


#26

I can’t say I’ve ever involved myself directly in coding software projects, yet I’ll contribute where possible (I’m still at the fumbling-through-QT-and-C+±documentation stage). Can’t say I’m the most experienced for the task, yet I’m willing to learn if I can get some pointers in the right directions. Right now, I’m interested in taking on libinput configuration, but finding documentation on how to implement this in QT is difficult. Considering KDE is working on a kirigami/qtquick configurator and GNOME is using Gnome Settings Daemon for libinput, I’m assuming this isn’t a simple task in LXQT, XFCE, or MATE.


(Pedram Pourang) #27

Very good news!

You could contribute by making PRs. Then, at least one LXQt developer – but usually more – will discuss probable problems with you, make suggestions, etc.

A libinput Qt config tool is a great idea.


(Alf Gaida) #28

Right - i guess we can leave alone synaptic (as in “We just don’t care anymore”) and concentrate fully on libinput.


(Chris Wyatt) #29

I’m interested in this project. I wouldn’t mind helping out, but I only have Python experience, and I have no experience of working on any large open-source projects like this.


(Mark Rabideau) #30

As a thought… is there a place for me to go to see when there are new modules/ components/ piece parts that need testing? I’d like to test when things are ready for review, and not have to just build and test random parts. :slight_smile:


(Pedram Pourang) #31

You’re very welcome to join the LXQt development in any way (coding, testing, bug reports,…).

You’ll need a standard installation of the latest git LXQt (you couldn’t use what Ubuntu provides, for example).


(Pedram Pourang) #32

To test PR’s you need to apply patches and have more than latest git.

To test the recently merged commits, you could see the “commits” tab of each source page (https://github.com/lxqt/pcmanfm-qt/commits/master for pcmanfm-qt, for example), which shows what is done recently. You’ll have to skip translation commits though.

However, upgrading to and using the latest git LXQt once in a while is enough. For testing, you need to get comfortable with package building.


(Mark Rabideau) #33

Based on my skill level, I guess I’ll just take the LXQt DE for a ‘test drive’ every month or so then.


(Chris Wyatt) #34

I’ll have a go at building it when I find the time. Will be a start. I’ve also been wanting to try out Arch Linux for a while, so I can kill two birds with one stone.


(Pedram Pourang) #35

Yes, a rolling system is needed for that: Debian sid, Arch, Manjaro (Arch + ease),… but not Ubuntu, Fedora,…