Compiling fails to find Qt properly about qtox HOT 10 CLOSED

Project ERROR: Unknown module(s) in QT: multimediawidgets multimedia

You need to install Qt Multimedia : apt-get install qtmultimedia5-dev libqt5multimediawidgets5 libqt5multimedia5-plugins libqt5multimedia5

...which I find strange, since the documentation says that that header requires QT += network, which I don't see in the .pro file.

Indeed, I'll add it.

Incidentally, where is development primarily coordinated? IRC? Or are you all so many cats doing whatever each of you wants? :D

You can always find me and other Tox devs on IRC (I'm tux3 on #tox-dev @ freenode), and most (?) people go look at the 4chan Tox threads from time to time. And then there's this bug tracker.
But there's no big plan or complex coordination outside of talking to each other and the issues tracker :)

from qtox.

....4chan? lol. (What board is Tox on?)

I meant for toxgui specifically, there seems to be around 3-5 people working on it, and I was wondering if you have any particular goal in mind. If not, then I already thought of one thing I would like improved, and perhaps more importantly, I believe I can do it myself.

It compiles just fine now, and I was pleasantly shocked that the video test worked (though with rather poor framerate). Though I'm sure it matters very little, while doing that I got numerous Camera::getLastImage: Error maping last frame errors in the terminal.

from qtox.

....4chan? lol. (What board is Tox on?)

Usually on 4chan.org/g/ and also here for the graphic design.

and I was wondering if you have any particular goal in mind

In the short term, fixing some of the oldest issues, and then working on audio then video.

If not, then I already thought of one thing I would like improved, and perhaps more importantly, I believe I can do it myself.

Great! And what would that thing be ?

from qtox.

I had no idea, wow. Was the idea originally spawned on /g/? Does IRG frequent /g/?

As for my thing, I mentioned in in IRC a few weeks ago, but this "data" file is about as useless as it could be. What occured to me as I was reading core.cpp was that portability will be important, i.e. "logging in" from different computers and whatnot. The current "data" file (or other arbitrary, hard-coded names in other GUIs) is very non-descript. So instead, 1) Tox save files should be named .tox (I mentioned this a few weeks ago, rather indirectly though) and 2) should be whatever alias the user chooses, and 3) this convention needs to happen for all GUIs. That way it's easy to both explain how to login elsewhere and actually do it. (There would need to be a way for the GUI to get the file out of the config folder, but I would consider that an implementation challenge more than anything.)

For example, my Tox file would be named "Dubslow.tox", and carrying that on my flashdrive is much more intuitive than "data" or "tox_save" or whatever.

I'll try and get something working-ish in the next few days or so -- I might need help working with the GUI though.

from qtox.

It's not a bad idea, but I'd rather avoid breaking compatibility with other clients.

Right now if someone is using, say, Venom and toxgui on the same computer, they share the same save file, so you can switch seamlessly from one to the other.

You should try suggesting this on IRC and see if we can reach a consensus between clients, or try to get your idea into the Single Tox Standard

from qtox.

I meant for toxgui specifically, there seems to be around 3-5 people working on it, and I was wondering if you have any particular goal in mind.

I was thinking of writing a document which contains a list of "feature groups" like you can find at: https://wiki.tox.im/Clients. For each group we could define a set of use cases which must be implemented and tested to be accepted as "done". If all use cases within a group are "done" the group is accepted as "done". For example:

1. 1 on 1 messaging:
   1a) the user is able to write a single line of content to another user
   1b) the user is able to write multiple lines of content to another user. A line is manually wrappable using (for example) shift + enter
   1d) if the user writes a message to another user which is currently offline, he will get a hint that the current message could not be sent
   1e) the user is able to receive a message from another user
   .... and so on

This would be a big bunch of work, but if (mainly) @tux3 and @F1ynn say that this is a good idea, I could start writing such a document.

from qtox.

I, for one, agree with the above.

from qtox.

Well sure it's in the same place as Venom, but uTox does it's own thing, and it wasn't as easy as it should have been for me to share between uTox and Venom. Thus, I posit that what I suggested doesn't break compatibility with anything other than Venom, which isn't even a majority of desktop clients available.

But yes, I'll bandy it about some more on IRC. Edit: What I suggest is in some sense a prerequisite for "multiple profiles", one row of the Clients page.

I do support much more specific criteria for each feature though, just a title is sometimes way too vague to be useful (e.g. what does the "aliases" feature implement)?

from qtox.

Thus, I posit that what I suggested doesn't break compatibility with anything other than Venom, which isn't even a majority of desktop clients available.

Last time I checked, it was the consensus.

And it makes saving a lot harder, if the save file's name "should be whatever alias the user chooses" then you need to remember to rename the save file when users change names, remember to delete the old one, but only if the new one was created successfully or we might lose everything, sanitize names to avoid trouble, somehow resolve conflicts (what if two users have the same name?), etc etc.
And you also need to save a copy of the user's name in a config file somewhere, because we can only know the user's name after we're done loading the tox_save.

from qtox.

I had vague solutions in my head to all those, except for sanitizing and conflicts/collisions. Those could be harder...

from qtox.