hello also having problems with Connman has to manually setup the wired connection used dhcp for the wireless connection and was able to connect to a wireless network but upon restart, had to manually reconnect with same wireless network and after a short time (say 20 mins) the connection dropped and could not reconnect without reconfiguring Connman (but not really sure how, sometimes it work) i also turned the wireless off and on, but no clear procedure note: using an intel wireless device; so maybe the kernel is doing something; had the same type of problem with a RTL wireless device is there any info to follow? especially how to autoconnect to the wireless network i was on
Which distro? With systemd and connman the connman.service has to be enabled.
@tsujan - if you remember John Rambo’s blue light - Q: What does it do? A: It turns blue …
With lxqt-connman-applet one can turn connman on and off - nothing less, nothing more in general. That’s one of the reasons why i didn’t release it yet. Ok, there are other reasons, but generally this applet could be useful - with a few small additions:
- if we consider cmst as our gold standard, the applet should be able to call cmst to do the dirty work
- the applet can run and provide the on/off functionality (and run cmst if needed) - so cmst is not needed to run all the time
With lxqt-connman-applet one can turn connman on and off
I didn’t know about it.
…so cmst is not needed to run all the time
When cmst exists as a light and efficient Qt app with a systray icon, isn’t lxqt-connman-applet what we usually call “reinvention of the wheel”? I mean why might we need another app to call cmst?
Right now i don’t know the ultimate answer - in my eyes lxqt-connman-applet could be a welcome addition to connman for some people - please keep in mind that we want a modular system. The applet could be a welcome addition for some people who don’t like cmst for some reasons. And i’m a bit in a conflict: Supported cmst for years now and use it myself - imho the best outcome would be if the applet would be in cmst and dropped by us - @pmattern wrote some things about the tray integration of cmst some years ago in our bugtracker - i think in the tracking bugs.
Imho we have here a problem with some concurrent implementations - the best ways to get this solved would be
- we do it our way
- we simply drop our implementation
- we get involved into cmst development and try to bring some our thoughts into
And after all these years i don’t know what would be the right thing. For me the perfect outcome would be: We just drop our implementation and have a applet in cmst upstream - or maybe use the DE agnostic way and use the systray (or what it’s called now or in future implementations). To be honest i would like the second option, maybe with a better separation between cmst and the applet part. I hope that this writeup is not to confusing
What problem does CMST have? Some people may not like it (why?!) but that’s not a problem in CMST. I’ve used it everywhere without problem – not just in LXQT.
If there is a problem other than needing a manual delay, please tell me!
if we don’t care, please close it without further comments
Sorry, took a bit of time to get through our history - What i do know is that Andrew is short on time - we are too. So it’s time to make some decisions about which things we want to provide and which not - and maybe it’s the better way to drop our things and work with our alternative upstreams more close.
Ok, this one is a bit in the future, i’m not really happy about we handled our bugs, pull requests or some other things in the past, but this have to wait until our new release is out. Only a short hint: We should cleanup our basement and our morgue and really burn all the dead corpses in a timely manner. Some of them are old and even don’t smell strong anymore
Thanks for the links! CMST is mentioned in both.
CMST has only one minor issue: Its tray icon needs a manual delay setting. That can be easily fixed (sooner or later, I’ll make a PR).
LXQt Panel’s Status Notifier Plugin works seamlessly; so, IMHO, we don’t need a connman plugin of our own. Frankly, I don’t think we could make something better than CMST. There are 2 simple reasons for that: (1) lack of manpower; (2) How could it be better than CMST?
ok - let’s release first and after the release start a LXQt cleanup - second thing i forget: try cmst with iwd - works fine, but signal strenth is missed
Ok, closed the first bug to clean up after your comment - we should do this far often.
Second thing: I had far to much spare time, so i created https://wiki.lxqt.org - not ripe for a official mention, but i copied all our github stuff into - the result is: Gosh, we don’t want this to be online another time. So i really want to get rid of our so called github “wiki” stuff, it is really useless and don’t let us shine in the brightest light possible - and i think in a half year or so wiki.js will be really ready to use without to much compromizes.
Edit: Ok, really horrible, but at least the github authentication works fine …
Very nice! After some cleanup, the help doc I wanted for pcmanfm-qt could be added to it – maybe, under a new title.
the best is - i was in search for a MD based wiki for the last two years - it boiled down to gitwiki, the splitted out github one and wiki.js - and my winner is: wiki.js.
- under very active development
- works fine out of the box and is limited enough to not contain any bad surprises - accept the current implementation
- the main developer is very active and dedicated to it
- All the things are saved in pure git (MD) in our installation (https://git.lxqt.org/LXQt/lxqt-wikijs) so it might be the way to go, maybe with the repo placed on github later
- it’s batshit crazy new in the latest iteration - it is called stable right now - but it lacks a few important things - erm - a lot of them
- in some places it is buggy like hell, but hey - the important few things are nearly working bug free
- it will maybe a bumpy ride if we commit to use it - ok, we have experience with bumpy rides
You’ve done a great job there. It’s so organized! I like that and I think everyone will like it.
bah - nothing about a great job, just a bit patience
So - what i did:
- i read a bit about
- i installed it first a year ago
- it was a bloody mess
- waited a bit longer
- tried it again and finally
- made a new container in our VM
- installed it within five minutes (was able to use my old config file)
- clicked at some things in the admin area (storage: git and such things)
- downloaded our github wiki and merged it into “our” repo
- wrote the useless github navigation 1:1 and go through the pages - 99% work fine without changes
So it is possible to use right now, i would like to suggest to wait for the next release to get it into production. After it we should adopt it (maybe with writing some upstream bugs about)
But yes, mostly good experience after these two years of waiting, but still a long way to go.
Searching for a solution, finding the best option, testing it, and using it: that’s a lot of work. This wiki will attract readers – it attracted me.
you can log in right now with your github account - forget to mention that the login thing is good implemented - like in discourse - but i would limit it right now to github as provider
It encouraged me to start pcmanfm-qt’s help doc in markdown. It’ll take a long time by I’ll do it little by little. When it’s ready, I’ll call you.
MD is the way to go imho - it is not turing complete and it don’t have to be, but i like the idea of MarkDown for years now. Ok, it has it weak points, esp. tables.
But the very strong points are:
- it’s easy enough to be really written by everyone
- nearly every modern system can render it without to much faults
- in rare cases one will be able to embed some html
- our website and discourse use MD already in the very same way - so no need to learn new tricks - ok, i forgot about github, gitea, gitlab - all of these services use MD - so it should be really common to all potentiol contributors
I agree completely.
Upps - and i forget about a really killer feature - language namespace support is already implemented - allthough i suggest not to use it in the very beginning - so the wiki could be really multilanguage later