Log from #neuros IRC channel

gremlin[it]: ah, indeed. i also don't drink cofee and can't eat garlic. Joe is poking fun at me for that all the time, say i'm only faking to be italian.

[03:20]

hahahaha

[03:20]

<gremlin[it]>

hihihi :P

[03:20]

<crweb>

nerochiaro: which exec is it that will let you inhert the env ?

[03:21]

crweb: beats me if i remember, let me check some manpages

[03:21]

<gremlin[it]>

morning crweb !

[03:21]

<crweb>

blah.. reading also..

[03:21]

<crweb>

gremlin[it]: morning

[03:21]

morning crweb....

[03:22]

crweb: sorry about yesterday i drop a question yesterday and left... that was because of Internet problem at my end...

[03:23]

<crweb>

BIMZIE: no prob

[03:23]

thanks man....

[03:23]

crweb: all of them inherit except execle() which lets you specify the env yourself

[03:23]

<crweb>

well.. gr

[03:24]

<crweb>

man my sleeping is all kinds of screwed

[03:24]

crweb: oh, actually not, sorry

[03:24]

<crweb>

ah, execellent

[03:24]

crweb: The execle() function also specifies the environment of the executed process by following the NULL pointer that terminates the list of arguments in the parameter list or the pointer to the argv array with an additional parameter. This additional parameter is an array of pointers to null-terminated strings and must be terminated by a NULL pointer. The other functions take the environment for the new process image from the external var

[03:25]

<crweb>

i'm just going to google execle

[03:25]

crweb: linux.die.net

[03:26]

<crweb>

its either that, or make deskmon a qt app

[03:26]

<crweb>

which.. i guess it sort of is..

[03:26]

<crweb>

can't remember now why I didn't want to do that.

[03:26]

crweb: they all boil down to this one anyway: linux.die.net

[03:26]

crweb: just make it a QT app, why not ?

[03:26]

<crweb>

i can't remember

[03:27]

<crweb>

could make it a console Qt app

[03:27]

crweb: do you recall if there was any issue in the idea of shutting down djmount and lighttpd before doing recording and restarting after ?

[03:27]

<crweb>

should be no issue

[03:27]

<crweb>

except "who does it"

[03:28]

<crweb>

which i still feel is recorders job

[03:28]

recorder, yes

[03:28]

<crweb>

nerochiaro: was thinking about creating another init mode just for recording

[03:28]

init is at boot, you want to reboot to record ?

[03:29]

<crweb>

no, init levels can be entered and exited

[03:29]

<crweb>

init 5 is graphic boot, init 3 is everything but graphics. init 1 is single user mode, etc

[03:29]

so when you exit a level all apps are killed ?

[03:29]

<crweb>

in normal desktops

[03:30]

<crweb>

when you enter "recorder's init" everything is stopped. when you exit it, everything is started ;)

[03:30]

<crweb>

just an idea being toyed with. for now let recorder do it

[03:31]

hmm, let's keep recorder, for now

[03:32]

<crweb>

the idea there is that, recorder doesn't need to know paths or applications to shutdown. it just says recorder mode

[03:32]

<crweb>

pretty special case, but trying to brainstorm ways to make this stuff better

[03:33]

we can probably run recorder mode enter and mode exit scripts, so that the logic is customizable

[03:33]

instead of hardcoding in recorder

[03:33]

and so that users can add their stuff in there

[04:02]

<crweb>

much better :)

[04:03]

<crweb>

QStringList that env :)

[04:37]

crweb: dude, i need a bit of help

[04:38]

crweb: you know the waiting box, which uses a worker thread to do the actual work. we need that to be able to play nice with the HOME key and requests to exit the app

[04:38]

not sure how to do that

[04:38]

<crweb>

yeah i want to kill that piece of crap

[04:39]

actually it was improved a lot lately

[04:39]

<crweb>

there isn't a single xiamen developer that believes waitingbox can be used without the thread

[04:39]

waiting box is made to be used with a worker thread

[04:39]

<crweb>

i spent better part of 2 hours trying to convince wesley and chain that waiting box is a widget

[04:40]

<crweb>

its not made to be anything. its just a popup window like QMessageBox

[04:40]

<crweb>

you pop it up and do your work

[04:40]

<crweb>

a "waiting box" display doesn't even need a thread

[04:41]

it doesn't. it's not doing the GUI update in the thread in fact. the thread is just for doing time consuming work and it's not part of the waiting box

[04:41]

<crweb>

it doesn't matter

[04:41]

<crweb>

its a window that pops up and does nothing

[04:41]

<crweb>

you don't need to thread to display a window

[04:41]

it update an animation, aside of that it does nothing

[04:42]

in any case, that wasn't my issue

[04:42]

<crweb>

here is my big issue. They try to use the thread to start QProcess's

[04:42]

<crweb>

since you can't use waitingbox without the thread

[04:43]

i don't remember that part. i thought it could be used without

[04:43]

<crweb>

it can

[04:43]

in any case, let's put the box aside

[04:43]

<crweb>

convincing xiamen of that is a whole other mountain though

[04:43]

let's not worry. let's just think about worker threads, even without the box

[04:43]

<crweb>

ok

[04:44]

how do we make them play nice with the HOME key and so on ?

[04:44]

(and so on means "with other requests to shut down app")

[04:44]

<crweb>

the app has full control of events etc.

[04:44]

ya, but can't kill the worker thread

[04:44]

<crweb>

and the app has full control of its own threads. so I don't understand

[04:45]

<crweb>

threads can't receive key events

[04:45]

<crweb>

if the app is going to shutdown, it cleans up its threads, memory, and closes its files. How would that be any different than any other system?

[04:47]

right, so we do it with the usual mutex-protected quit flag variable that the thread checks periodically and quits when it see it set ?

[04:47]

<crweb>

or you terminate the thread

[04:47]

which is usually pretty evil

[04:48]

<crweb>

you override quit() to clean up

[04:48]

<crweb>

oh nvrmind. that assumes the thread has an event loop

[04:48]

:)

[04:48]

ok, i get the general idea anyway

[04:49]

off to talk with Gordon

[04:49]

thanks

[04:50]

<crweb>

threads should really have event loops

[04:50]

<crweb>

so that they can quit cleanly etc

[04:50]

<crweb>

and so you can use signals and slots in the thread

[04:50]

it's not necessary if they don't do GUI

[04:50]

really that's "let's QT everything" thinking :P

[04:50]

<crweb>

you mix up events and gui

[04:51]

<crweb>

signals and slots are events

[04:51]

<crweb>

you can't signal out of a thread to main thread without an event loop

[04:52]

<crweb>

say. you are reading a file in a thread and you want to emit signal, "end of file reached" so that a parser can read the next file

[04:52]

i know, but that's not what we need to do

[04:52]

<crweb>

well.. maybe not this time

[04:52]

i get the idea of event loop, you're right,it's useful also without GUI

[04:52]

i'll keep that in mind

[04:53]

<crweb>

you can also quit(), which will close the event loop cleanly and exit the thread

[04:53]

<crweb>

since your thread is event driven, you can limit the amount of cleanup you have to do

[04:54]

ok

[04:54]

<crweb>

and.. thats about all i know about threads..

[04:55]

<crweb>

lol ;)

[04:56]

HOME is filtered by wm, right ? which then sends the close command to apps via stdin ? do i recall correctly ?

[04:56]

<crweb>

and, if its not a real heavy task you are better off just opening the waiting box, and calling processEvents() throughout the functions code.

[04:56]

<crweb>

correct

[04:56]

<crweb>

no wait

[04:56]

crweb: (i hate processEvents method, but let's talk about that another time)

[04:56]

<crweb>

HOME comes to the app. the app closes

[04:56]

<crweb>

1 app at a time, so main-menu comes back up

[04:57]

<crweb>

QCop is the only way to killall

[04:57]

so HOME is sent from WM to all apps ?

[04:57]

one at a time ?

[04:57]

<crweb>

no, just current

[04:57]

and app gets it on focused app window, i guess ?

[04:58]

<crweb>

right, and no one handles so it comes to the MainWindow class, which then shutsdown

[04:59]

ok

[05:00]

crweb: did you already update staff about that issue on framebuffer and monitor that we talked yesterday ?

[05:00]

<crweb>

finishing it up right now

[05:00]

er, stuff

[05:00]

oh, ok

[05:01]

remember to notify team

[05:17]

<crweb>

well, just the ones that were involved right?

[05:18]

crweb: yes

[05:18]

crweb: and corlin

[05:33]

crweb: do we really need that deskmon ? i mean, can't we just restart the nwm after switch ?

[05:34]

<crweb>

how?

[05:34]

the app that does the switch restart it

[05:34]

<crweb>

the app will die before it has a chance

[05:34]

the ntsc_pal app

[05:34]

<crweb>

because nwm is the parent

[05:34]

it's not a GUI app

[05:35]

<crweb>

i know

[05:35]

<crweb>

its a child pid

[05:35]

<crweb>

it can't exist if nwm exits, and nwm can't start if the parent of the parent dies

[05:36]

<crweb>

ntsc_pal app would kill nwm, and deskmon would restart it

[05:36]

it should be possible to spawn it to be independent of parent's death

[05:36]

ntsc_pal kill nwm and restart it

[05:36]

then quit

[05:36]

<crweb>

this is better regardless. this way the config gets set, and nwm can just shutdown

[05:37]

<crweb>

or if nwm segv's, nwm is restarted

[05:37]

i frankly prefer to be able for it to stay down. people won't notice bugs if it just restarts

[05:37]

if it dies, it stay dead

[05:38]

<crweb>

but if it dies and you aren't home, you missed everything you scheduled, etc

[05:39]

it's a bug, which should be solved by fixing the root cause

[05:39]

not by working around

[05:39]

<crweb>

i as a user, want my recording... sorry

[05:40]

catfight ensues. allright, let's keep this monitor

[05:40]

<crweb>

segv's would most likely occur during gui interaction so a reset would be noticed

[05:41]

<crweb>

if we are conserned, maybe deskmon can start nwm with a flag that pops up a window "error has occurred"

[05:41]

<crweb>

"please do blah blah"

[05:42]

fine

[05:42]

<crweb>

but i think it would be better for nwm to simply turn itself off when told to this way it can shutdown all the other processes etc. instead of a script just killing it

[05:43]

<crweb>

and do we know how to fork() so that the child isn't dependent on the parent pid?

[05:49]

crweb: i think fork and setsid from the child

[05:51]

crweb: took me a bit to find that again

[05:52]

<crweb>

i dunno if i ever knew that..

[07:11]

crweb and nerochairo ... how can i increase the text Rect (rect in which item text is displayed) size.....

[07:11]

this is for NListView

[07:12]

i want to increase its items text area

[07:18]

crweb: still there ?

[07:18]

crweb: ISP acting up

[07:56]

<crweb>

nerochiaro: still here yeah. starting to fade though

[07:57]

crweb: no problem, just wondering if you got the message about how to detach child from parent process

[07:57]

<crweb>

yes i did get that, thanks

[07:57]

no problm

[07:57]

<crweb>

i don't think i ever knew that

[07:58]

sendig a nasty gram to wesley for his thread patch. i see now what you meant

[07:58]

<crweb>

i'll discard the one in my drafts to you then

[07:59]

<crweb>

i wrote it a few days ago and never finished ;)

[07:59]

the problem is that gordon started that part and what he did made sense, but then as usual someone picked it up and didn't understand a damn thing

[08:00]

<crweb>

chain was the worst though

[08:00]

<crweb>

took me 2 hours to convince him that he could open a WaitingBox, without th thread helper...

[08:01]

<crweb>

and they want to use the thread, to open a qprocess

[08:01]

<crweb>

aagghh..

[08:01]

who wants to do that ?

[08:01]

i mean, where ?

[08:02]

<crweb>

chain was

[08:02]

<crweb>

Really though, my main problem with all of this is

[08:02]

<crweb>

you shouldn't open a waitinbox and a thread. the whole point of the thread is ability to continue using gui

[08:03]

<crweb>

if all you want to do is display a waiting box, you *should* use the processEvents()

[08:03]

i disagree. using processEvents can't guarantee you smooth updates to the GUI. you're at the mercy of how frequently the user calls it, and with some operations it's not possible to call it often enough or regularly enough

[08:04]

with a separate thread, the OS handle it

[08:04]

much better

[08:04]

<crweb>

whats the point of a thread, if you are still blocking the user input..

[08:04]

to update the animation, for once. to process other events coming in to the app that are not from input

[08:04]

<crweb>

then open the box, before you run the thread

[08:04]

<crweb>

this all in one is really bothering me

[08:05]

yeah, they are opening the box before running the thread

[08:05]

it's already that way

[08:05]

<crweb>

no i mean, openbox->show(); thread->run();

[08:05]

they just put a helper class in the middle, but it's exactly what they do

[08:06]

<crweb>

which is pointless, and causing even more confusion cause none of them know how to thread to begin with. how to communicate with the thread, and are completely limited to the helper

[08:06]

that is a valid concern

[08:06]

but the issue is that they don't know these things, not that there's a helper

[08:08]

in other words, i don't mind the helper, as long as they know that they can do things without

[08:09]

<crweb>

and i really don't like a QThread class, blocking the main thread... (not blocking as in blocking painter, blocking as in app flow) the class that created the QThread should control the gui and what is happening, not the QThread class

[08:09]

the GUI is still controlled by the main thread

[08:09]

<crweb>

no no

[08:10]

<crweb>

the control goes *into the NWaitBoxThread*

[08:10]

yeah, but you're still running in main thread

[08:10]

<crweb>

where it should have stayed in MainWindow so that other things can happen

[08:10]

other things can happen, you're still running the code in main thread. the fact it's in another class doesn't mean antything

[08:10]

<crweb>

like keys, other events, popups

[08:11]

<crweb>

control is not in the Parent object's hands.

[08:11]

<crweb>

they way it should be

[08:11]

what do you mean by "control" ?

[08:11]

i think we are confusing each other

[08:12]

<crweb>

i mean that WaitingBoxThread (not the thread) has control over the application *now*

[08:12]

<crweb>

it opens a WaitingBox on the screen

[08:12]

<crweb>

and thats it. End of story, can do nothing else

[08:13]

<crweb>

can't ask questions during the execution of the thread cause that would require more than just opening WaitingBox

[08:14]

which is correct, since the waiting box purporse is just that. to keep some lights bleeping on screen while some lenghty operation happens

[08:14]

<crweb>

The GUI thread is trapped inside the WaitingThread class

[08:15]

trapped ? dude, i'm not following you. a thread can't be "trapped" into a class

[08:15]

<crweb>

I'm not talking about the thread

[08:15]

<crweb>

I'm talking about execution of the main thread

[08:16]

<crweb>

when you WaitingBoxThread->show(), execution is now in the WaitingBoxThread class

[08:16]

<crweb>

all events, all signals everything dealing with the waiting box and GUI is now "inside" WaitingBoxThread class

[08:17]

<crweb>

instead of letting the parent object control what is happening

[08:17]

there's no show() in the WaitingBoxThread class

[08:18]

<crweb>

then how does the widget get on screen?

[08:18]

waitingBox = new NWaitingBox(toptitle,message); waitingBox ->setAttribute(Qt::WA_DeleteOnClose, true); return waitingBox -> exec();

[08:18]

<crweb>

ok there even worse, exec()

[08:18]

<crweb>

this blocks *everything* else

[08:19]

yeah, because the waiting box is blocking

[08:19]

<crweb>

but its not really

[08:19]

it should be

[08:19]

you are not supposed to do anything else while it's up

[08:19]

<crweb>

why? its just a notification of progress/work

[08:19]

<crweb>

this means nothing else can happen just because waiting box is on the screen?

[08:20]

<crweb>

no other threads can be started? no other data processing?

[08:20]

what data processing ? i show the waiting box because i'm doing data processing in the first place

[08:21]

<crweb>

so you want to limit everything to only 1 thread to do work and just keep the gui drawing

[08:21]

no, you can start several worker threads if you need to do more parallel work, no one is preventing you to do that

[08:21]

<crweb>

i can't say.. watch a socket for incoming data while i'm building a audio db

[08:22]

<crweb>

while the waiting box is on screen i can't popup a window that says "you have messages"

[08:22]

sure you can, there's a class that does just that, QSomethingWatcher, i can't recall now

[08:22]

no you can't, because there's the waiting box there already

[08:23]

how many popups do you want to stack

[08:23]

?

[08:23]

<crweb>

thats incorrect. a worker thread does not mean GUI stops

[08:23]

you're not following me

[08:24]

it's not necessary for it to be that way. if you don't want it to be that way simply don't use the helper. just use the waiting box separately, as you please. but in a lot of cases what we want is to block

[08:24]

and the helper is there for these cases

[08:25]

<crweb>

my point is, its just junk in a library

[08:26]

i don't agree with that. i agree it can be confusing, but i don't agree it's useless

[08:26]

<crweb>

we can't really use it for anything, and all it really does is cover up 5-6 lines of code

[08:26]

something more than that. and why do you say we can't use it for anything ? we are already using it

[08:27]

in a lot of places

[08:27]

it provide a quick way to do a certain kind of task. you can still do it in other ways, or manually if you want

[08:27]

<crweb>

it can't be used for anything else, it can barely be customized and if you want to do any actual threading you can't use it anyway

[08:28]

<crweb>

it hides a few lines that would be more readable, and easier to follow in code than if they were not hidden away in a library class

[08:29]

well, that's arguable. but if you think strongly it has to be removed, we can do that. i need your help to drive the guy to cleanup and understand the proper way though

[08:29]

<crweb>

create the waiting box, and attach the waiting box progress updaters that we make slots (could be several different types of progress from %'s, strings, or just colors)

[08:29]

<crweb>

to the threads signal for progress update

[08:34]

let's keep it simple

[08:34]

<crweb>

this is typically how it works

[08:34]

<crweb>

4-5 lines maybe depending on how many things you want to connect the thread and box to

[08:34]

right, but i'd like to keep waiting box for now only with the KITT light indicator, to keep it light as possible.

[08:34]

reagarding the helper, i'm ok in making it go away

[08:34]

<crweb>

in that case, the waiting box should be self animated

[08:34]

but i repeat, we need to explain very clearly how to replace

[08:34]

crweb: it is self animated

[08:34]

<crweb>

ok, so all they would have to do is: new waitingbox -> show(); connect threado signal finished to waitingbox->close()

[08:34]

<crweb>

thread->run()

[08:34]

they also need to create the box everytime, and also implement the logic to collect the thread's return value

[08:34]

the helper is doing all that for them

[08:35]

<crweb>

which seems to me all in a standard days work. You want a widget to show before you do something, you create it. you dont' want it, you dont create it

[08:36]

<crweb>

i need to look at the return value thing though. sounds kinda fishy to me

[08:36]

<crweb>

oh, and 1 class 1 file. that bugged me too

[08:36]

i can agree with that

[08:36]

but minor

[08:37]

in any case, it's all simple stuff. the purpose of helpers is not only to make hard stuff easier, but also to remove the need to type a lot of bolierplate code to do some real work

[08:37]

so that's what it is for in this case

[08:38]

again, all that can be done manually, but you need to do it everytime

[08:38]

<crweb>

i don't consider this boiler plate though..

[08:38]

<crweb>

this is normal every day toolkit usage

[08:39]

we don't agree on this, it already come up in the past.

[08:39]

<crweb>

Q_SIGNALS:

[08:39]

<crweb>

void complete(int);

[08:40]

<crweb>

this the collection of the threads return status ?

[08:41]

<crweb>

qthreads don't really return values, they can signal out before done

[08:41]

ya, the actual thread function (that is the only thing they need to implement with this helper) returns a value, the value is then emitted with the signal, and finally retuned from the blocking helper function.

[08:41]

<crweb>

which is totally up to the thread to do

[08:41]

again, therea are other ways to do it

[08:41]

this is just one

[08:42]

<crweb>

so, using the box helper, you have to write your thread so it returns an int

[08:43]

<crweb>