[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Development
. . -> [Subject]  Problem with text view
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Problem with text view

It is now over 60 days since the last post. This thread is closed.   [New subject]  Start a new subject   [Refresh] Refresh page


Pages: 1  2  3  4 5  6  

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #45 on Mon 27 Sep 2010 04:20 AM (UTC)  quote  ]

Amended on Mon 27 Sep 2010 04:43 AM (UTC) by Twisol

Message
There's IRC. I've always got mIRC running in the background. I can join #mushclient-dev in a snap. Just like that; I'm there now if anyone wants to come by, and I can leave it on my auto-join list.

[EDIT]: I agree with everything Worstje said below, which is why I jumped straight to IRC. Sorry for not being clear. :D

[EDIT] 2: Freenode network, I can't believe I forgot to say that...

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #46 on Mon 27 Sep 2010 04:22 AM (UTC)  quote  ]
Message
I suppose, although messengers tend to be a bit more userfriendly. No need to actually play the game. I've got everything from AIM to Yahoo to MSN to ICQ even.

Likewise, in my experience, people spend less time logged on onto a mud than they do on a messenger, meaning it is trickier to get a hold of someone or to leave them a quick message.
[Go to top] top

Posted by Nick Gammon   Australia  (19,534 posts)  [Biography] bio   Forum Administrator
Date Reply #47 on Mon 27 Sep 2010 04:39 AM (UTC)  quote  ]
Message
Putting aside a nice chat for a minute, I feel as if I have been through the mill with this version, what with the major changes, some subtle issues with the timestamps (solved in the end by changing the opacity of text drawing) and then the corrupted window issue.

Are there any major reasons we can't get this out as a version for people to test? Then we can start from scratch with a new version.

BTW here is another video about noticing things:

http://www.youtube.com/watch?v=mAnKvo-fPs0

In this case the subject fills in a form, and then the guy behind the desk ducks down, and another one stands up in his place, and 75% of people don't notice the change.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #48 on Mon 27 Sep 2010 04:44 AM (UTC)  quote  ]
Message
Oh, I feel this version has had all the changes it needs. (Minus that bugfix that isn't specific enough, but that's been brought up to death by now, so I'll save that for a future version. xD)

I'll check that video out tomorrow - got some stuff to finish and tomorrow it'll be a nice way to start the day. :)
[Go to top] top

Posted by Nick Gammon   Australia  (19,534 posts)  [Biography] bio   Forum Administrator
Date Reply #49 on Tue 28 Sep 2010 11:20 PM (UTC)  quote  ]

Amended on Tue 28 Sep 2010 11:22 PM (UTC) by Nick Gammon

Message
Worstje said:

For your viewing 'pleasure', I have put all VS2010 CEditView code regarding find and replace on pastebin. I'd go through the details and such myself, but I haven't got a clue where it goes wrong for you, and I'd have a hard time debugging an issue I don't have as well. Copy/paste as you see fit, or if you spot a more surgical solution to your problems, do that.

http://pastebin.com/s0k6HfcD


Well I just don't think it's worth it. I see what is happening a bit more clearly. The new controls assume the text is Unicode (obviously the old ones didn't because without changes anywhere else they work).

Now I initially tried changing the ReadFromArchive to convert the text to Unicode (assuming it was UTF-8 - can we assume that? and if not, what do we assume?).

So instead of setting the shadow buffer to nothing, I put the Unicode text in the shadow buffer - in other words like this:


#ifndef _UNICODE
  if (_AfxGetComCtlVersion() >= VERSION_6)
  {

  // work out required length
  int iUnicodeCharacters = MultiByteToWideChar (CP_UTF8, 0, 
                        lpszText, nLen,  // input
                        NULL, 0);         // output


  LPVOID hUnicodeText = LocalAlloc(LMEM_MOVEABLE, (iUnicodeCharacters+1)*sizeof(WCHAR));

  if (hUnicodeText == NULL)
    AfxThrowMemoryException();

  LPTSTR lpszUnicodeText = (LPTSTR)LocalLock(hUnicodeText);
  ASSERT(lpszUnicodeText != NULL);

  MultiByteToWideChar (CP_UTF8, 0, lpszText, nLen, (WCHAR *) lpszUnicodeText, (iUnicodeCharacters+1));

  LocalUnlock(hText);
  LocalFree(hText);

  hText = hUnicodeText;

  }
#endif


So far so good - the text appears OK, and it writes out OK, as the writing part seemed to be assuming Unicode (why?).

But the finding doesn't work. Setting some breakpoints found that the MFC I have assumes we have straight text and not Unicode. But this is reasonable - it *is not* a Unicode app. Now I can start replacing all the finding stuff to do a Unicode find, but why not rewrite the whole app to be Unicode while I'm at it?

Next thing I'll find is that copying and pasting won't work right because one is Unicode and one isn't,

The thing is, Worstje, you are trying to put old wine into new bottles. It doesn't work. And the fact that the new common controls "just assume" you have Unicode in the edit window, when the old ones don't make any such assumption, doesn't help one bit.

I think the whole thing will have to be reverted, sorry. If you want to start again and write a Unicode client, be my guest. But this merging in of (dare I say it) buggy common controls with an old app isn't working.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #50 on Wed 29 Sep 2010 12:22 AM (UTC)  quote  ]
Message
I can't say much other than that I am disappointed.

It is not the common controls that are buggy, it is _your_ specific MFC version. There are ZERO issues on my VS2010 build, and I am pretty sure Twisol has the same experience on his VS2005 build. It is a bugfix to your framework (Twisol would hit me if I said compiler again), and the only way to fix that bug in your framework is to tackle your framework. Newer versions of the framework are the perfect example that MFC is not per definition flawed, and thus there is no 'old genie new bottle' thing going on - it is a plain old bug. Nothing more, nothing less.

Do I get that it isn't fun to work around bugs and all that? Totally. But now you also know how we feel trying to make every single change we make compatible back to W95, VC++6 and whatever else.

Last of all, there is one more thing I'd like to voice.

Back when you made the source available, you have made complaints more than once that it was for naught, saying things like (no exact quote - I am too lazy to look it up) 'only a handful of people has downloaded the source', and more things along the lines of people being unable to help out with patches and the likes.

I have been putting a lot of work into the theming, because I would like to see it implemented. I have not asked you to point out X or Y as I was trying to figure things out, but merely offered patches and welcomed all criticism and issues that popped up as a result of them (which I do thank you for).

In the end, I have gone out of my way to try and keep patches as compatible as humanly possible given the 'demands' placed on me. Is it too much asked that, given the work that has been put in, we do not sling the 'old genie, new bottle' argument while we know very well that the entire compiler has had its end-of-life date placed around 10 years ago now?

By the same argument, we might all just as well stop developing MUSHclient, since this is like putting an ancient bottle in a fancy new winerack, followed by putting a new wine in the bottle from time to time. You either accept time moves on, requirements and tastes differ and evolve, or you put it aside in the antiquated section. Switching sides along with what seems best given the situation

This post is totally all over the place arguments-wise, and I suck at the imagery comparisons as well, and I apologize for all that.

TL;DR: I care about MUSHclient, I'll go along with a lot of decisions despite not agreeing with the reasons, but there's limits to everything. We have a possible fix for your specific framework, and you rather drop a 'feature' than use it. That's how I see it. When it is proven the Find function cannot be patched to make to work again, I'll gladly surrender the argument, but right now, it is total utter poppycock.
[Go to top] top

Posted by Nick Gammon   Australia  (19,534 posts)  [Biography] bio   Forum Administrator
Date Reply #51 on Wed 29 Sep 2010 01:37 AM (UTC)  quote  ]
Message
Worstje said:

There are ZERO issues on my VS2010 build, and I am pretty sure Twisol has the same experience on his VS2005 build.


My major point here is that you two have got it to work using custom builds and using modern versions of Windows. Fine. But I have about 4,000 downloads a month. I get quite a feel that a lot of people are using Ubuntu. Certainly they won't all have the latest Windows controls.

It isn't enough that two people can get it to work. I need it to work reliably for the 4000 * 12 per year that are downloading it.

There are a lot of hurdles to overcome in making MUSHclient look like a modern Vista / Windows 7 app, and adding a file into a directory and tweaking a couple of settings is not it.

Worstje said:

It is not the common controls that are buggy, it is _your_ specific MFC version.


My version of MFC has served me well over the last 15 years. It is the attempt to shoe-horn modern controls into an old framework that is the problem.

Worstje said:

I have gone out of my way to try and keep patches as compatible as humanly possible given the 'demands' placed on me.


I sympathise, honestly. I have suggested in the past that the client could be rewritten. The Mudlet guys have done just that, in that they did their own open-source, cross-platform client.

I appreciate all the suggestions, and realize that they were intended to improve things. I also realize you can't test if your changes will work with my old compiler sophisticated Integrated Development Environment.

There is nothing stopping you or Twisol releasing a "new improved" MUSHclient, designed to work on XP or Vista upwards. It could have reworked GUI interfaces (ie. configuration screens). It could have better theming. It could be refactored <grin>.

I just don't like the idea - and I may well be wrong - of tweaking away, rewriting stuff like the CTextView to incorporate the new controls, and basically adding cosmetic stuff, for no real purpose, apart from looks.

Something like the timestamps, that was a nice idea. I can actually see how that might be used when playing a MUD - to see how quickly hits arrive in combat. But rounded buttons on a dialog box? Which you rarely have up? I think that is just over-egging the pudding.



- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Reply #52 on Wed 29 Sep 2010 01:52 AM (UTC)  quote  ]

Amended on Wed 29 Sep 2010 01:55 AM (UTC) by Twisol

Message
Nick Gammon said:
There is nothing stopping you or Twisol releasing a "new improved" MUSHclient, designed to work on XP or Vista upwards. It could have reworked GUI interfaces (ie. configuration screens). It could have better theming. It could be refactored <grin>.

The topic of forking came up in passing between us, but only to say that we both detest the idea of forking MUSHclient, not least because of all the hard work you personally put into it. A MUSHclient without Nick Gammon sounds like a very strange proposition. I personally would rather create something entirely new.

Nick Gammon said:
But rounded buttons on a dialog box? Which you rarely have up? I think that is just over-egging the pudding.

One of the things Worstje mentioned to me is how he's met so many people who reportedly looked at MUSHclient and didn't think it was even still maintained. MUSHclient looks and feels dated, regardless of whether it's actually true or not. This may not be a major point, but I do think it's a valid one.

[EDIT]: I understand you're probably not actively marketing MUSHclient, and that's a perfectly valid viewpoint too. After all, if you're not trying to put a product out there, there's not as much pressure to make these changes. I would suppose that's why Zugg killed zMud and made CMUD - after all, he makes money from his clients - but of course I know very little about Zugg's stuff.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #53 on Wed 29 Sep 2010 02:12 AM (UTC)  quote  ]
Message
Regarding the way you reverted things...

You are aware the _only_ thing you had to do to get MUSHclient to revert to its 'classic' look was remove the .manifest? The manifest is what causes the v6 controls to be loaded. No manifest, no v6, no unicode, no problem.

Removing all the other improvements only hurts people who wish to build with > VC6++ versions. The THEME_GLUE things did not do anything without the proper controls loaded, for example.

The reason I do not fork MUSHclient is three-fold. First of all, out of respect to the man who created it and maintained it for over 15 years. Second is because it would confuse users. And third is because I don't like to do the entire regular development thing for myself - I rather contribute to something that lasts.

Quote:
My version of MFC has served me well over the last 15 years. It is the attempt to shoe-horn modern controls into an old framework that is the problem.


An attempt that would very likely have been succesful had you not chosen to revert the entire thing. Which is not to say I see that as the problem - I see the fact you insist on sticking to a 'MFC version that has served you well for 15 years' as the problem, while it is obvious it has had its shortcomings for 8 of those years.

Otherwise, you would have enabled support for themed controls 8 years ago. Essentially, you wish to develop using an outdated IDE that has not truly sufficed for the last eight years because you consider all of its shortcomings as bridges you'd rather not cross.

 But rounded buttons on a dialog box? Which you rarely have up? I think that is just over-egging the pudding.


If that is your view, I can see why you are opposed. It is far more than that though. It is about consistency. MUSHclient stands out as a sore thumb just like those very recent Office versions stand out in their own way, and it is a gap that only grows. For a window that takes up 1/3rd of my screen on a near permanent basis, I do like to have the things that can be pretty, be pretty. Additionally, I hear when talking to people that they feel MUSHclient is not worth checking out because it looks outdated and unmaintained.

Personally, the biggest gain throughout this effort for me was to learn some of the code intricacies, and to help move some things along to the next generation. The unicode issues were an unexpected but nice side effect - if you can convert small things on a case-by-case basis, a full conversion becomes a reality at some point.

Theming.
Fixing the weird screen-greedy infobar of doom.
Command line window with red-wavey-underline spellcheck built in.
Redoing world properties.
Cleaning up global prefs.

Those were the things I was working towards, working on, or making plans for. But if something as simple as this already causes major strife, I do not believe I can ever do those other things. The infobar of doom might need a bugfix approach like the unicode issue of today did. The command line window may not be that compatible with older versions of windows. World properties are doing fine as they are, so why change them?

It will always be an uphill battle with you, Nick. And for someone like me who only wants to code so people will have a use for the things being coded, the maintenance / regular releases aspect is not interesting. But the constant battle is equally frustrating - I bet that we could have fixed your bug in the time it took us to discuss this issue, revert those commits, and whatever else you did.

I still love you, but the frustration is not worth it. I doubt I will do much more than fix the occasional bug from now on forth.
[Go to top] top

Posted by Larkin   (278 posts)  [Biography] bio
Date Reply #54 on Wed 29 Sep 2010 08:17 PM (UTC)  quote  ]
Message
Even having only read the last page of posts, this discussion seems to have taken an interesting turn. You all have very valid points, and you're all very good coders, so I hope we can all get along here. :)


Now, I just want to say that I have looked through the MUSHclient source quite a lot, and I learned a good many things from it. I made pretty good progress on my own client before I got distracted with other projects, but I do hope to get back to it and make it something that at least I can use myself to play my MUD.

A modern interface can really go a long way towards better usability and increased functionality. There have been many advances in controls available through the libraries now, and I'm pretty excited about the potential of several of them in my own applications. If only I didn't always get stuck on silly things like art for toolbar icons...
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #55 on Wed 29 Sep 2010 09:07 PM (UTC)  quote  ]
Message
Larkin said:

Even having only read the last page of posts, this discussion seems to have taken an interesting turn. You all have very valid points, and you're all very good coders, so I hope we can all get along here. :)


I'm getting along just fine. It is the working along that is giving me trouble. :)

Quote:
Now, I just want to say that I have looked through the MUSHclient source quite a lot, and I learned a good many things from it. I made pretty good progress on my own client before I got distracted with other projects, but I do hope to get back to it and make it something that at least I can use myself to play my MUD.


I feel the same, there is a fair number of interesting things in the source. If it isn't the good decisions and code, it is the fact the code shows its age with rings like a tree would. It shows me what to pay attention to, and where I can improve.

Quote:
A modern interface can really go a long way towards better usability and increased functionality. There have been many advances in controls available through the libraries now, and I'm pretty excited about the potential of several of them in my own applications. If only I didn't always get stuck on silly things like art for toolbar icons...


I feel the same way, and tend to get stuck at the same spot with art and such. Is there any chance your client is opensource? I'd love to go through it, and if I gathered correctly from other posts you actually borrowed a lot of MUSHclient source code, or forked or whatever - meaning I might be interested in contributing if that is anywhere up your alley.
[Go to top] top

Posted by Nick Gammon   Australia  (19,534 posts)  [Biography] bio   Forum Administrator
Date Reply #56 on Wed 29 Sep 2010 10:24 PM (UTC)  quote  ]
Message
Twisol said:

One of the things Worstje mentioned to me is how he's met so many people who reportedly looked at MUSHclient and didn't think it was even still maintained. MUSHclient looks and feels dated, regardless of whether it's actually true or not.


I just don't understand this bit. Let's say on a MUD someone recommends MUSHclient - in that case they can say "don't worry if it looks a bit old, it works really well".

But if it isn't recommended, you are saying someone downloads it, installs it, fires it up, looks at the user interface and then deletes it? That's a strange workflow, isn't it?

But if they refuse to download and install it, because it looks dated, how do they know it looks dated? If you can explain this "race condition" to me, I'll be interested to hear.

Or are you saying that someone has heard the client is good, but once installed they glance at the configuration dialogs and say "oh blast! square buttons! it's rounded buttons with shadows for me or nothing!". Delete!

I don't mind helping other open-source guys. Here is another client that might be more suited to your tastes if you want a free, cross-platform, and more modern-looking client:

http://www.mudlet.org/

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by WillFa   USA  (517 posts)  [Biography] bio
Date Reply #57 on Wed 29 Sep 2010 11:45 PM (UTC)  quote  ]

Amended on Wed 29 Sep 2010 11:46 PM (UTC) by WillFa

Message
Mudlet has the same problem. They say they're "Open Source like Lua", but according to the Lua FAQ; Lua isn't Open Source. Mudlet is not a collaborative project. It's one guy, Heiko, in control and he's much worse than you about keeping Git repositories updated. There's no point trying to offer patches or aide to the project because any source you can get is ancient.

Plus, Mudlet has some majorly shortcomings functionally... Every other mud client in the world has a trigger for if a line starts with an ansi code (Like MC ONLY tests the first char) Mudlet checks the whole line for the ansi code, with no way to anchor it... argh.





[Go to top] top

Posted by Nick Gammon   Australia  (19,534 posts)  [Biography] bio   Forum Administrator
Date Reply #58 on Thu 30 Sep 2010 (UTC)  quote  ]

Amended on Thu 30 Sep 2010 12:01 AM (UTC) by Nick Gammon

Message
WillFa said:

... he's much worse than you about keeping Git repositories updated.


Bearing in mind that implies I am bad, and he is worse. When I make a change these days, I test it, and as soon as it looks reasonable, I do "git commit" and "git push". Certainly for each release of the executable, I also make sure that the corresponding source is fully committed at the same time.

Willfa said:

... according to the Lua FAQ; Lua isn't Open Source.


See this page on the Lua site:

http://www.lua.org/license.html

First paragraph (in part):

Lua License said:

Lua is certified Open Source software.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Reply #59 on Thu 30 Sep 2010 12:19 AM (UTC)  quote  ]

Amended on Thu 30 Sep 2010 12:21 AM (UTC) by Worstje

Message
I am on Nick's side on this one - for the most part anyway. He is nothing other than excellent in keeping git repositories updated, even though he has a habit of skipping commits to merge, or manually merging and forgetting a thing or two. But the intention is very much there - once he is able, he commits changes.

Regarding open source Lua stuff... I think WillFa refers to the fact that Lua development is done behind closed doors, with periodical patches being released as well as work versions (beta) of new versions. It's quite like Nick solely releasing the source at one-version intervals like he did upto version 4.45. It was only then that he began to incorporate github into his routine.

There's a difference between open source and day-to-day open development.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


28,784 views.

This is page 4, subject is 6 pages long:  [Previous page]  1  2  3  4 5  6  [Next page]

It is now over 60 days since the last post. This thread is closed.   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Web site powered by FutureQuest.Net]