Closed OcculentMoose closed 10 years ago
I believe there should be a separate repository for any work done on a GUI, the idea was to keep a core library relatively stand-alone. And then have the ability to build on that. Following that for the default GUI would be a good idea.
Should we make the GUI native for every platform? I haven't worked with qt or the windows GUI tools, but I could probably make a decent one for OSX in Cocoa.
We'd have to wait until the core is finished, though.
I think the best option is to write a daemon + ncurse client for now. Once the nitty gritty is operational perhaps a QT interface and let others develop for their platform of choice.
On Tuesday, July 9, 2013 at 9:59, Anthony Super wrote:
Should we make the GUI native for every platform? I haven't worked with qt or the windows GUI tools, but I could probably make a decent one for OSX in Cocoa.
We'd have to wait until the core is finished, though.— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20679873).
I'm the one who's been looking at other's mockups, and turning it into a web mockup found at http://tox.vacau.com/
This is so people have one place to correlate their ideas, and so that if a web client is ever a thing... (Or if we decide to go HTML/CSS for the UI.)
Since writing a UI in HTML is easier, and you can add more effects, styles, eye candy than QT, I suggest to write a back-end for Tox core to be used with an HTML application, basically the same as WebUI in Deluge or uTorrent, but this HTML application is rendered is not rendered in a normal browser, but using a custom ToxUI application. This ToxUI application can be achieved using a Blink fork, and modified to provide the necessary Java Script API such as {Minimize windows, Show system notification, Exit Program}, and stripped from features that ToxUI don't use.
Diatahoc, if I'm understanding what you're saying, it's that we should have a HTML/CSS/JS UI for the main client, and then create use our own (or a forked) html renderer? So it would launch like a regular application, but still show the HTML/CSS/JS view?
What's wrong with providing a basic Ncurses UI at first? It won't bother the geek early adopters who will write frontends in the toolkit of their choice like people do with MPD clients. If this kicks off people are going to want ports for their smartphones and that will make it so much easier.
On Saturday, July 13, 2013 at 16:34, llamalord318 wrote:
Diatahoc, if I'm understanding what you're saying, it's that we should have a HTML/CSS/JS UI for the main client, and then create use our own (or a forked) html renderer? So it would launch like a regular application, but still show the HTML/CSS/JS view?
— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20927123).
Diantahoc, if I'm understanding what you're saying, it's that we should have a HTML/CSS/JS UI for the main client, and then create use our own (or a forked) html renderer? So it would launch like a regular application, but still show the HTML/CSS/JS view?
Yes, that is exactly what I am saying.
What's wrong with providing a basic Ncurses UI at first? It won't bother the geek early adopters who will write frontends in the toolkit of their choice like people do with MPD clients. If this kicks off people are going to want ports for their smartphones and that will make it so much easier.
Nothing is wrong with that. I personally would not mind to use a CLI to chat.
Well, there's nothing wrong with that. But a UI for the masses has to be easy to use, and clean too. Also, using HTML/CSS allows for quick changes, and it would be easy for people to change (If we give them the option to. More people are familiar with HTML/CSS than most other languages. Save Java...)
Here is an example of what I am saying
Why would that interface need to launch like a real "app"? Why not just access it through local host within your modern browser of choice?
On Saturday, July 13, 2013 at 16:57, diantahoc wrote:
Diantahoc, if I'm understanding what you're saying, it's that we should have a HTML/CSS/JS UI for the main client, and then create use our own (or a forked) html renderer? So it would launch like a regular application, but still show the HTML/CSS/JS view?
Yes, that is exactly what I am saying.
What's wrong with providing a basic Ncurses UI at first? It won't bother the geek early adopters who will write frontends in the toolkit of their choice like people do with MPD clients. If this kicks off people are going to want ports for their smartphones and that will make it so much easier.
Nothing is wrong with that. I personally would not mind to use a CLI to chat.
— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20927277).
Because the average user don't know what is a browser. Besides, we want it to look like a real app
.
Maybe power users can access it via there browser of choice.
Little people aren't ever going to look at this software until it's moderately mature and a port in their preferred toolkit like Qt has been completed. The web interface will be for "power users" and/or early adopters. Actually, the little people aren't going to touch it until there's an OS X and NT port.
On Saturday, July 13, 2013 at 17:10, diantahoc wrote:
Because the average user don't know what is a browser. Besides, we want it to look like a real app.
Maybe power users can access it via there browser of choice.— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20927668).
I can probably compile on OSX and build a simple window with a web view if the UI is designed in HTML, CSS and Javascript. On Jul 13, 2013, at 6:15 PM, TheAustinHowell notifications@github.com wrote:
Little people aren't ever going to look at this software until it's moderately mature and a port in their preferred toolkit like Qt has been completed. The web interface will be for "power users" and/or early adopters. Actually, the little people aren't going to touch it until there's an OS X and NT port.
On Saturday, July 13, 2013 at 17:10, diantahoc wrote:
Because the average user don't know what is a browser. Besides, we want it to look like a real app. Maybe power users can access it via there browser of choice.
— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20927668).
— Reply to this email directly or view it on GitHub.
Little people aren't ever going to look at this software until it's moderately mature and a port in their preferred toolkit like Qt has been completed. The web interface will be for "power users" and/or early adopters. Actually, the little people aren't going to touch it until there's an OS X and NT port.
What I meant is instead of bothering to write the UI in a framework (like QT), we simply make the default user interface using HTML/CSS/JS, and have a window with a web view to display that HTML UI. The HTML application will look the same on all major OSes since it is rendered using the same rendering engine (eg. Blink). The actual low-level stuffs is performed by Tox Core.
To achieve this, we let Tox core to have an integrated static HTTP server with with special URLs that perform specific actions like sending a message, retrieve friend list, change settings, turn off the core etc. These URLs can be accessed and called via JavaScript.
Of course this will need a lot of work, and Tox need to be a mature program first.
My bad, now I see what you're saying.
On Saturday, July 13, 2013 at 17:33, diantahoc wrote:
Little people aren't ever going to look at this software until it's moderately mature and a port in their preferred toolkit like Qt has been completed. The web interface will be for "power users" and/or early adopters. Actually, the little people aren't going to touch it until there's an OS X and NT port.
What I meant is instead of bothering to write the UI in a framework (like QT), we simply make the default user interface using HTML/CSS/JS, and have a window with a web view to display that HTML UI. The HTML application will look the same on all major OSes since it is rendered using the same rendering engine (eg. Blink). The actual low-level stuffs is performed by Tox Core. To achieve this, we let Tox core to have an integrated static HTTP server with with special URLs that perform specific actions like sending a message, retrieve friend list, change settings, turn off the core etc. These URLs can be accessed and called via JavaScript. Of course this will need a lot of work, and Tox need to be a mature program first.
— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20927973).
@diantahoc You're wrong. Qt is much better in my honest opinion. You see, Qt can do HTML based UIs such as the one you suggested (if needed, check out the QtWebKit). And Qt offers seriously more features, Qt has stable code base, tons of documentation, great community, and most importantly, Qt is very robust, well tested, and an easy to work with model for building multi-platform desktop applications. You probably want to learn how the Qt works and what it can offer before writing anything else about it.
And Qt Quick UIs are very easy to do if you're familiar with HTML, CSS and Javascript. Not to mention that with Qt you can build your own UI styles from sratch if needed using pure CSS. In another words, if you want to build something that doesn't look native for Windows, you can do it.
And also, if I may say so without pissing you off, what you're suggesting is in my opinion a very bad idea. It will feel cheap, it will look cheap, and it will not function like the other similar applications out there for Win/Linux/OSX. And it'll leave a bad taste in mouth.
And completing the text-based client in my opinion should be priority number one. It'll be the showcase that we actually have something working on our hands. Code that can be tested. Code than can be read. Something that will spark the interest of other developers and designers, and will creatly benefit the Tox community and development process.
Talk about UI is important, but time for it isn't now. We should form some kind of a roadmap, which is filled with numerous small steps, big problems broken down to eatable pieces. And I'd very much would like to see that
Sorry for this small rant, but I believe it's better to speak your mind than be silent. Sorry. It's 02.21 AM here. I'll quickly sketch something with Qt for you to see.
tl;dr: Qt is flexible.
Oh well ( ° _ʖ °), I did not know that Qt can do all of this, interesting.
if I may say so without pissing you off, what you're suggesting is in my opinion a very bad idea.
Don't worry, If I was wrong and corrected, why would I get pissed ?
Sorry for this small rant, but I believe it's better to speak your mind than be silent. Sorry. It's 02.21 AM here. I'll quickly sketch something with Qt for you to see.
It is 2:32 AM where I live. Thank you very much, I appreciate your comment. Sweet dreams !
I as well was not aware of how robust Qt is. Knowing that now I do believe that Qt should be the "default" interface for Tox-core.
On Saturday, July 13, 2013 at 18:34, diantahoc wrote:
Oh well ( ° _ʖ °), I did not know that Qt can do all of this, interesting.
if I may say so without pissing you off, what you're suggesting is in my opinion a very bad idea.
Don't worry, If I was wrong and corrected, why would I get pissed ?
Sorry for this small rant, but I believe it's better to speak your mind than be silent. Sorry. It's 02.21 AM here. I'll quickly sketch something with Qt for you to see.
It is 2:32 AM where I live.
Thank you very much, I appreciate your comment. Sweet dreams !— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20928706).
If you want, you can do something like this... (just a simple rich text box)
Or after implement the QtWebKit... (Sorry, I ripped the page and the style from the earlier mockup page)
Probably gives some idea. I was a bit lazy but you'll probably not notice my laziness. Good night!
This is what I was talking about. @Sinihopea I can easily change the HTML/CSS of that, especially if I know that it's in a controlled environment (Like a standalone app, and I know the HTML renderer.)
And if Qt can implement a WebKit engine, then I say we go with that. It will make us that much closer to completion. Also, if you guy want to give me some more suggestions/feedback I would be willing to come up with a fully working UI using HTML/CSS. (I can't into Qt that well, so I would pass of my work/work in conjunction with someone else.)
Showing the QStyle with the new Fusion style...
Just in case I say that this is a real running application that doesn't have any functionality built-in other than the fact that it launches up, draws a window, and has punch of widgets inserted there, and it loads up webpage from the project folder using qwebview.
What HTML engine is that? WebKit works best (I use chrome to test.)
QtWebKit I guess it is WebKit
Okay, thanks. So do we want to go with a Qt/WebKit client then?
I will leave Sinihopea to answer this one. Probably yes though.
@llamalord318 The Qt has a custom built-in version of the WebKit engine. People have successfully used it to build cross-platform web browsers. Developers of Qt offer a web browser as an example application and it's source code. lol
https://code.google.com/p/arora/ https://qt-project.org/doc/qt-5.0/qtwebkitexamples/webkitwidgets-browser.html
More examples of usage: https://qt-project.org/doc/qt-5.0/qtwebkitexamples/qtwebkitexamples-index.html
And I'd rather use the webkit features of Qt for mainly presenting things instead of actually implementing any UI functionality using web technologies. And with that said it really doesn't matter what engine there is underneath.
And sorry for the sales pitch but Qt 5 has tons of other useful stuff that might come handly later. Such as the multimedia related things.
https://qt-project.org/doc/qt-5.0/qtdoc/qt5-intro.html https://qt-project.org/videos/watch/livecoding-video-effects-with-qt5 http://blog.qt.digia.com/blog/2012/02/29/pimp-my-video-shader-effects-and-multimedia/
Qt also features Phonon. It might be helpful in delivering sound.
@Sinihopea What do you mean by "Qt for mainly presenting things instead of actually implementing any UI"?
Like, how chat is formatted?
@diantahoc In my opinion we have a several good options. I like Qt and it essentially offers a great way to work, but of course it's not the only way. We could also do the thing of building 100% native clients per platform. It would have advantages such as minimal performance gains, and ability to use the certain platforms native look and feel options.
For example while Qt on Mac OS X looks completely native, it doesn't however always completely act like a Cocoa application should. When you maximize document window it usually completely dismisses Apple's document oriented windowing rules and resizes the window to full screen width and height. This can be adjusted in my opinion and is not a huge issue but requires extra work towards a single platform which could be avoided by using Cocoa itself.
Eventually we might find out that we have lots and lots of exceptional cases in the source code that the single code, depending on platform, looks and works completely different. And that might pose a problem in distant future.
Another thing what Qt alone can't do is building the Modern UI applications for Windows 8. That's something that needs to be done natively. While Qt can however do pretty good Android and Blackberry 10 applications they're not perfect (yet).
However building native clients would also mean that the amount of work that has to be done grows enormously. And amount of features we can pack requires more on external depencies, and those will require more work, and the thing essentially blows up so that we could do at max only one or two good UIs and then spend years on perfecting and polishing.
On the other hand just to name a few usage cases Qt is a native UI of KDE desktop and various Google applications on all platforms (for example Google Earth). Qt is used to build Jolla's Sailfish OS applications, and various Nokia related products still use Qt. Skype used to use Qt on all platforms but now only Linux version of the Skype uses Qt. Opera browser uses Qt on Linux at least.
...
I'm not a coder in this project (at least yet), and the guys who have actually contributed something this have more to say to this matter than I do. Project leader gets to decide these things usually after discussions with the community memebers.
And to directly answer the question. Yes. I'd feel comfortable building user interface around Qt. And my primary reason is that it's positive offerings outweight all the negative things in scale. And I'd recommend Qt full well knowing that it also might lead to some problems at some point of the time.
Honestly, in my opinion, native is the way to go.
Keep the same design feel, but make TOX look like a native application on every platform. That's one of the places where Skype really falls short - On everything but Windows it looks horrible, and it's honestly not that great on windows either. Native builds will allow us to integrate TOX with the operating system in a way that feels comfortable to the user.
If we make some changes to the core that I suggested in another issue, we could easily write wrappers in other languages, which would make porting natively even easier. It might take a bit more work, but I honestly think that native UIs it is the best long-term way to go on the project.
@llamalord318 I mean the visual design. Like the style of the area where the sent messages are located at, how they are formatted, etc. And the fact that you could just press save, and it would save chat log as a webpage (formatted XML) since it already is a webpage, a document with information, like it was intended to be.
I've literally had enough of HTML5 and Javascript as a building blocks for the Gnome 3 and Windows 8 "Applications". Don't get me wrong, that's nice if you're doing a web application for the desktop (like for example if Tox was a project to build a better Facebook to replace the Facebook...), then the kind of web application as it was described here earlier, would make sense. But highly secure instant message and VoIP application like the Tox, as I've understood, it gains much more out of the "real" widget set.
@SHTheSuper I think that currently Skype probably uses native toolkits on all of the respective platforms, and I agree that it looks awful... Qt doesn't completely disregard the HIGs of the various platforms. It was built-in mechanisms that allow it to look and feel like native application. Ensuring that Qt looks and feels like a native application on all platforms requires only 1/4th of the work required by the building and maintaining of the native applications, or less.
I'm not completely against the native route, but I'm just saying that with Qt it would be very easy to build an application for many different platforms and keep them all updated simultaneously with all the possible features (or at least all the major ones). Going native will mean that one platform might have this or that feature, while lacking something else. And there's no way to keep even three applications in a state that there's always everything up to date. Skype is probably the best of some of the worst examples about that.
If you've used Spotify on any of the platforms, I think it's a good example how to build a multiplatform Qt application. More applications can be found from a list nice folk at Wikipedia have formed up.
https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt
PS. Now I really need to go to sleep. "Good night!"
P.S.S. One more thing. Going native would mean that we'd need guys who know all the various programming languages required to complete the ports. With Qt we could stay mostly in C++ and have people work together instead of fragmenting the developer base in to small competitive camps...
@NDJ1 Yes, it's possible. But it would make more sense to wait that the core gets functional first. While building the core, build a text-based client to test various things is important. And when the API is there, only after then build a GUI becomes a topic. This talk about GUI toolkits, usability and user interface design is still very early. It'd make more sense to talk about the design and features of the client now, rather than means of delivering one, and thus perhaps limiting our options. Because when we know what we what from the client, we have much easier time choosing the base to build it off from.
Perhaps this may be of relevance. This is an update on Gui Designs from /gd:
There are few issues usability wise in that design, but I could make a functional prototype (in another words functional UI without any functions of the application) of that. Wait a moment.
EDIT: Okey, I had to do something else in between but I worked on this right after...
I improved it a bit...
After small changes on Windows 7 with Aero...
And without...
...
At this point I'd like to say that I'd preferably kept the conversation window separate from the contacts window and not merge them like this but both ways are ok. What is really important is that the conversations are tabbed, to avoid having multiple conversations on multiple windows.
tl;dr
There is already a Qt GUI, which is in development since 25th of June.
It works and sends messages, but I have to note that the latest version:
...intended mostly for testing Core's features.
and
This version is not intended for production [public] use.
It's highly unstable and doesn't have any error checking in it, expect it to crash in highly unexpected times. It assumes you have DHT server running somewhere, since the latest version of the Core requires it.
Here is a screenshot, which you can also see on the project page. Please star if you liked it.
The previous goal was to make a GUI to test the Core with, which could grow into something people could use. The current goal is to make it more userfriendly by code, without customizing UI looks yet. Customizing UI looks has lower priority. It needs to have code refactored, errors handled and setting implemented first.
I don't usually read these issue threads on github, so if needed, you can ping me on the irc.
OK, that's unfortunate. Instead of dealing with the nightmare of toolkits should the answer not be just working on the Ncurses client for now?
On Sunday, July 14, 2013 at 22:12, nurupo wrote:
tl;dr There is already (https://github.com/nurupo/ProjectTox-Qt-GUI) a Qt GUI, which was in development since 25th of June. It works and sends messages, but I have to note that the latest version (https://github.com/nurupo/ProjectTox-Qt-GUI/releases/tag/0.1.0):
...intended mostly for testing Core's features.
and
This version is not intended for production [public] use.
It's highly unstable and doesn't have any error checking in it, expect it to crash in highly unexpected times. It assumes you have DHT server running somewhere, since the latest version of the Core (https://github.com/irungentoo/ProjectTox-Core) requires it.
Here is a screenshot, which you can also see on the project page (https://github.com/nurupo/ProjectTox-Qt-GUI). Please star if you liked it.The previous goal was to make a GUI to test the Core with, which could grow into something people could use. The current goal is to make it more userfriendly by code, without customizing UI looks yet. Customizing UI looks has lower priority. It needs to have code refactored, errors handled and setting implemented first.
I don't usually read these issue threads on github, so if needed, you can ping me on the irc.— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-20950092).
How is this for some UI inspiration? (randomly found on tumblr)
I personally think to get people to use it it shouldn't look like some barebones wireframed application. People want pretty communication tools. That's why things like the iPhone are popular. I think we should work on Qt first and then transition to true native UIs and see if we can implement some of the prettier /gd/ mockups.
People who want "pretty" software will wait until Tox has some level of marketshare.
On Tuesday, July 23, 2013 at 11:19, m3hr wrote:
I personally think to get people to use it it shouldn't look like some barebones wireframed application. People want pretty communication tools. That's why things like the iPhone are popular. I think we should work on Qt first and then transition to true native UIs and see if we can implement some of the prettier /gd/ mockups.
— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-21426146).
I think Tox will have a hard time getting market share if it doesn't have a pretty UI.
Completely agree with @Bevinsky
We're not Google, we can't say to people "coming soon!" and just have them take our word for it. We need to show them that we're ready, and have tried our best so far.
I'm sure I'm forgetting this merely due to lack of sleep and a hangover but did we even get around to deciding what kind to toolkit the "default" GUI would be made from?
While I absolutely agree that there should be a default interface packaged for most operating systems I think it's all at this stage it's erroneous to attempt to market to the average end-user. That shouldn't be done until a stable build has been audited for security by third party experts in crypto.
On Thursday, July 25, 2013 at 9:29, NemDiggers wrote:
Completely agree with @Bevinsky (https://github.com/Bevinsky) We're not Google, we can't say to people "coming soon!" and just have them take our word for it. We need to show them that we're ready, and have tried our best so far.
— Reply to this email directly or view it on GitHub (https://github.com/irungentoo/ProjectTox-Core/issues/20#issuecomment-21557609).
I have a question regarding the UI-design. I personally really like the mockup (it is a mockup, right?) that is shown on the http://tox.im/ page. The site is kind of "promising" that it will be kind of like that, therefore, why not do it that way?
@Mianki
(it is a mockup, right?)
Yes it is.
why not do it that way?
I think for now developers want to make sure every thing is working perfectly, then they can focus on making a good user interface, since they don't want to waste their efforts and debug the UI and the Core at the same time.
I think for now developers want to make sure every thing is working perfectly, then they can focus on making a good user interface, since they don't want to waste their efforts and debug the UI and the Core at the same time.
I did not mean to say that it should be done sooner or something. I was just wondering that, with all this discussion about the UI, nobody seemed to even consider building it like it is shown on the tox homepage.
Someone made a start for a Qt GUI here: https://github.com/nurupo/ProjectTox-Qt-GUI
Edit: sorry, that came from the department of redundancy department. Anyway a Google search turned up something quicker than reading this entire thread would take :)
@ameenross you didn't even have to google, you could just read repo's description on the bottom of https://github.com/irungentoo/ProjectTox-Core page
Hm, that could have been a tad more pronounced in that list.
I think it's pronounced enough. I was searching for a GUI and I found the link in no time.
I could try writing a GUI using Qt or GTK+ (If I find time to do it, and no one is already doing it). But I don't want to step on toes of anyone on this matter. The TODO states that Qt UI is already in progress by someone. But if it isn't, I could later do some concepts (in form of Qt .ui files you can load up in Qt Designer, or compile and run them) if you want.