New Option Dialog

[lizard]

How do you like some simplified option dialogue stuff?
A few in this thing behave different from normal.

First, "Control" means right oposite from "View Only".
I made this decision because I believe positive and negative sentences mixed confuse users a lot. Think there's choices "Show A" and "Don't show B", and you wish to disable both. Confusing eh?
I also thought "Control" should come to this spot so that user can easily toggle to take control or not. "Control" checkbox is vertically fat too.

Second, the data format is now chosen in that combo box. This is coming from a quite natural reason that those radio buttons take too much space but you could do the same thing by this.

Compression sliders are as TightVNC has done.

Here's my idea. You don't see those choices for how it deals with mouse cursor anymore. Note that you see the new item "Show mouse cursor" now. Actually I think this is enough. Cursor's behavior will be controlled by 2 simple factors here.
A. "Show mouse cursor" is checked.
B. "Control" is checked.
Lets think how it works.

Both A and B: as "Track remote cursor locally"
Only A: as "Let remote server deal with mouse cursor"
Only B: as "Don't show remote cursor"
None of A or B: as "Don't show remote cursor"

It could cover the Ultra Encoding's bug with "Track..." option, just making an exception for both A and B checked to apply "Let remote..." when Ultra Encoding is chosen.

Any suggestion appreciated.
Thanks.

[lizard]

another one. sample program here (reqires vb6 runtime lib)

this one dynamically follows the mouse cursor position to scroll in vertical direction.

[lizard]

resource file for the type1 dialog. testdlg.zip (2KB)
let me know how you like these replacements.

[lizard]

an example of vertical alignment

[netwolf]

I like them

[cobratbq]

I think the strong point of a GUI is when you can see in the blink of an eye how everything works.
And it's that way with the first two GUIs.
But the file-transfer modification isn't that functional I think.
It's because it's a top/bottom division, and the send and receive aren't at all clear in which directions they go.

[netwolf]

Hmm, FT is indeed more intuitive if you leave it horizontal.
You could change to >> arrows to vertical ones , but it doesn' really improve things.

However, I can imagine that building sliders etc. without using MFC is quite a lot of work.
On the other hand, why not use MFC ?

[Ares]

I absolutely love the first screenshot. I think using more combo boxes would be a great idea. Just my 2 cents worth!


-Ares

[Ares]

I also second the part about changing the mix of negative and positive sentences in the prefs. One similiar thing that confused me at first was that for Zip/Tight compression, a higher number means more compression. Now technically, for Jpeg (Tight) Quality, a higher number would mean higher quality, and less compression, right? Just kind of strange that a high number in one means more compression and yet means less compression in the other. That's why I think the sliders (with like an - on one and and a + on the other) would be a great idea.


-Ares

[Guest]

Well I suggest first of all adding a custom radiobox in the "connection speed selection" box in the client's connection dialog. There should be a "Custom Settings" button next to that ratio that should lead to a dialog where all the settings that usually are set when you select connection speed (like compression format, copyrect caching etc). Then there should be another button in the connection dialog to chose the remaining options (advanced settings).

Also some regrouping of options in the server and maybe a little built-in configuration wizard in the setup program would be interesting too (createinstall installer does that work pretty well).

If there's any way to get access to the program cvs I can try to change the interfaces a bit (i've already changed it in my ultravnc sources and those options seem to work well). The problem however is that all the localized dialogs should be retranslated: maybe loading all the dialog labels from the resource strings would be a better way to localize the program.

Instead of thinking about all those bugfixes (who cares if the server crashes sometimes, one can set it as service with automatic restart) I think that the developers should think even about changing the interface before release 1.0 since it's the only think that messes up people when they're using the program. Changing the interface and making it simpler like windows remote desktop's one would make this program a lot more popular.

[netwolf]

Instead of thinking about all those bugfixes (who cares if the server crashes sometimes, one can set it as service with automatic restart) I think that the developers should think even about changing the interface...

You're kidding, aren't you ?

Seriously, I also like those suggestions, but as UVNC is not written in VC++ (and doesn't even make use of MFC), I guess it takes quite some time to perform such major GUI changes.
So I definitely vote for bugfixing and maybe adding some nice features (that do not threaten overall stability) like some FT tweaks, current transfer speed etc., and leaving GUI rearrangements for post-v1.

[OhMyGoat]

major gui changes?? I'm sorry but adding a radiobox, a button and moving part of the controls to another dialog doesn't look to me like a major gui change. It took me about 2 hours to translate the program and change those dialogs and I was quite inexpert when I did that. Also even if the program is not made using vc++ or using mfc who cares, vc++ can still be used to edit the program resources in no time (and about the source code that needs to be changed surely using vc++ wouldn't help as much as you think).

A bug fix may require days to track the bug down, changing the interface is just a matter of hours and it's very difficult that, moving some controls in another dialog, will mess the program up.

Also it's very easy to see if something while moving has gone wrong: just close and reopen the option dialog, if the settings remain the same, then they're saved and loaded correctly, if they do not, then something got messed up and it's very easy to find out where the problem is.

The program looks almost stable to me now, and I don't really think that such changes will create new bugs at all. I really think that the interface is far more important that any other features for now, it's really too confusing.

Just think at all those poor people that install the program for the first time: how can they know which compression is better or how can they swim in all those options in the server configuration dialog without sunking? Such big and unorganized dialogs scare most of the new users away. I really think that semplifying the user interface should be a priority for now however It's all up to the developers

[Guest]

Complex interface....

That's what happen when everybody want other settings...
Just try to remove one stupppid option and next time you get 10 messages
about the missing option.

Ultravnc is written in VC++ without using MFC.
MFC is a MS only class, you can forget every other compiler.
All free express version (2003,2005) lack MFC, using MFC
only people with a VC full lic version would be able to compile it.

If the interface is to complex, you always can use a resource hacker
to remove parts in the graphical interface. As long as you don't add or move oprions from one to the other dialog it will work.

[OhMyGoat]

i'm not talking about removing options, i'm talking about regrouping them in 2 different dialogs and any decent resource editor lets you do that in a matter of seconds.

[Guest]

True, a decent resource editor let you edit resources.

Resources on there own doesn't do anything then showing the graphics
on the screen.
The tricky part is adding manual the corresponding code behind
each bottun, checkbox....

If you generate 2 nice dialogs, you also need to split the code.
properties.cpp -->properties1.cpp and properties2.cpp
When you exit a dialog, settings need to be saved/loaded.
Using 2 dialogs you need to split the save/load functions in save1/save2
When there is some relationship between the settings from dialog1 and dialog2 you need a third class that talk to both dialogs

Graphical splitting -> 2 hours work
Making the cpp code and testing a week or more....and plenty bugs

[OhMyGoat]

True, a decent resource editor let you edit resources.

Resources on there own doesn't do anything then showing the graphics
on the screen.
The tricky part is adding manual the corresponding code behind
each bottun, checkbox....

If you generate 2 nice dialogs, you also need to split the code.
properties.cpp -->properties1.cpp and properties2.cpp
When you exit a dialog, settings need to be saved/loaded.
Using 2 dialogs you need to split the save/load functions in save1/save2
When there is some relationship between the settings from dialog1 and dialog2 you need a third class that talk to both dialogs

Graphical splitting -> 2 hours work
Making the cpp code and testing a week or more....and plenty bugs

No you don't need to do all this splitting. The dodialog function can be changed to accept the dialog resource and then it takes only few minutes adding an if in the dialog's ok button callback to chose which settings read and save from the dialog. I've did it very quickly without problems at all.

I think that creating 2 cpp files would be very stupid: if something goes wrong in the source of one of the files it should be fixed even in the 2° one it's just a loss of time. Using the same functions and checking the dialog resource number would take a lot less time and would be a lot more efficient.

[OhMyGoat]

True, a decent resource editor let you edit resources.

Resources on there own doesn't do anything then showing the graphics
on the screen.
The tricky part is adding manual the corresponding code behind
each bottun, checkbox....

If you generate 2 nice dialogs, you also need to split the code.
properties.cpp -->properties1.cpp and properties2.cpp
When you exit a dialog, settings need to be saved/loaded.
Using 2 dialogs you need to split the save/load functions in save1/save2
When there is some relationship between the settings from dialog1 and dialog2 you need a third class that talk to both dialogs

Graphical splitting -> 2 hours work
Making the cpp code and testing a week or more....and plenty bugs

No you don't need to do all this splitting. The dodialog function can be changed to accept the dialog resource and then it takes only few minutes adding an if in the dialog's ok button callback to chose which settings read and save from the dialog. I've did it very quickly without problems at all.

I think that creating 2 cpp files would be very stupid: if something goes wrong in the source of one of the files it should be fixed even in the 2° one it's just a loss of time. Using the same functions and checking the dialog resource number would take a lot less time and would be a lot more efficient.

Programming without using mfc is not so messy as you are having it appear: yes, you may have to do some extra work to access a control's value and yes, you have to remember all those boring messages/notification, but it's not all that bad. Unless one starts using complex controls like treeviews/tab ctrls/etc. it's not all that hard.

Dont be so pessimistic , if everybody were pessimist like you probably ultravnc would work only with command line parameters

Err sorry for the double post, i've messed up

[Rudi De Vos]

If you have a better dialog box (with corresponding cpp code)
we are happy to take a look at it and use it for ultraVnc.

Current time is to limited to do something myself...

That's the fun of opensource, you don't have to do everything yourself,
people always can help and contribute

[OhMyGoat]

If you have a better dialog box (with corresponding cpp code)
we are happy to take a look at it and use it for ultraVnc.

Current time is to limited to do something myself...

That's the fun of opensource, you don't have to do everything yourself,
people always can help and contribute

Yes I did a better interface, but I did it long time ago on an old ultravnc version, when i'll have ported it to the last version i'll send you the source then. I'll post some screenshots in this post when it'll be ready so if somebody has to suggest some interesting changes i'll make them.

[redge]

developer, programer, coder:

don't lost your precious time for brainstorming about better dialog box when very good dialog box and help hint was already done.
so, include work from TightVNC under GPL inside UltraVNC is for that too,
isn't right ?

Use your time for include your very good intelligency and work for mproving performance, quality, stability, feature and debuging

• UltraVNC staff
• Rudi De Vos: repeater, NAT2NAT, SingleClick I+II, video driver
  integer new protocol quality/speed SPEC encoding, new self-update/function of winvnc/vncviewer...
• UltraSam:FileTransfer, Chat, dsmplugin, JavaViewer
• Marscha: MS-Logon authentication, doc UltraVNC website
  
  
  outside of UltraVNC staff
• lizard: optimizing speed hack TCP
• Scovel: encryption plugin
• OhMyGoat: VNCentral (replace the old VNCcon stoped ?)
  [mod=494,1118263631]deleted 2 partners isn't free under GPL, but shareware)[/mod]

more usefull coders forgotten ?

[Marscha]

I think that the interesting parts of TeamViewer and EchoVNC are not open source.
AFAIK, Rudi's repeater, nat2nat and sc are the only open source apps helping VNC through firewalls and routers.

Regarding dialog boxes, there's also RealVNC 4.x that have nice user interfaces, but 4.x is completely new code.