Modifying unix/tx to support Windows is, I think, a bigger task than it might at first appear. Plus, it wouldn't give us a native OS X version. Also, in my mind, one of the biggest benefits to using an external graphics TK is that we can improve our UI in the long term without having to write new widget code for all of the various platforms.
On 1/19/11 3:24 AM, Adam Tkac wrote: > On Tue, Jan 18, 2011 at 02:24:03PM +0100, Pierre Ossman wrote: > > Hello, > > I'm really happy that you are planning to do something with viewers. > > FLTK is a good choice. Another solution might be to improve our code > in unix/tx/* and port it to Windows but I'm really not sure how > difficult it will be. I'm fine with both FLTK and unix/tx/* ways. > > Regards, Adam > >> Currently we have two vncviewers (three if you count the java one) in >> the tree; one for Windows and one for Unix. Apart from the core RFB >> stuff, they share very little code and there has been a lot of code >> duplication and feature disparity between the two. We also lack a >> client for OS X, which is a fairly common platform these days. >> >> I/we would like to remedy this situation by rewriting vncviewer in a >> portable form that allows us to have the same client on Windows, Unix >> and Mac. >> >> Since the core RFB stuff is already handled, what's left for vncviewer >> is mostly user interface. The most important decision for this >> endeavour is then selecting a good toolkit that fits our needs. The >> ones I've looked at are GTK, QT, FLTK and wxWidgets. These satisfy the >> portability requirements we have, and they are all fairly alive >> projects. >> >> In a perfect world, we would use GTK or QT. These are modern, popular >> toolkits with a lot of functionality. Unfortunately they are very >> large. Given the devices we here at Cendio deploy vncviewer on, GTK and >> QT cannot be expected to be present. That means they need to be shipped >> with vncviewer, preferably statically linked. Both GTK and QT surpass >> the 5 MiB mark for a simple hello world application, meaning that the >> size of the vncviewer code is completely dwarfed by the size of the >> libraries it requires. We do not consider this an good option, and I >> suspect DRC has similar wishes when it comes to deployment. >> >> wxWidgets is disqualified as a consequence of this as it uses GTK on >> Unix platforms. >> >> What's left is FLTK. This is not the most fancy toolkit out there, but >> it gets the job done and is very small. We've been using it for our >> propietary tlclient for years, and we haven't had any serious issues. >> It's not as pretty as the other toolkits, but vncviewer isn't that GUI >> heavy and the few dialogs it needs would look decent enough. >> >> >> I'd like to start this project fairly soon, so please comment as soon >> as possible. The plan would be to create a new top-level vncviewer/ >> directory and put the new client there. The old ones would be kept >> around until we are confident that the new one can fully replace them. > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
