Modernizing DC++

So, I was sitting here earlier, and for a while people have been asking me about getting DC++ to introduce chat coloring and other things in that nature, basically make DC++ more modernized in respect to the UI being customizable. For the longest times other clients have been customizable in this aspect…I remember using SdDC++ 0.12x (DC++ pre- 0.300) and you could literally change every aspect of the UI from colors to icons even toolbar gradients and what not. So the reason I am here is to propose some UI extensibility to DC++ (which in all honesty is long over do, I mean IRC clients have these kinds of features) so I’d like to formally propose some changes to the UI that I have been thinking up, obviously this isn’t complete but here I go =)

.dcstyle “Theming” proposal for DC++

things to be handled inside of a dcstyle theme layout

Userlist coloring (Bot, Op, Favorite User, Normal User)
Chat formatting
	|> Coloring
		|> Text (including specifications for timestamp coloring, nick coloring, actual text, magnetlinks)
	|> Formatting
		|> Magnet links (make them more readable as per: StrongDC/ApexDC
		|> Text effects (bold, italic, underscore, etc.)
	|> Icons
		|> Icons should be interchangeable and not linked into DC++, i.e. all icons should reside in a "res" or "icons" folder (sub directory of the actual DC++ exe)
			|> Userlist icons, Toolbar icons, and all other icons should be split into individual sub directories as stated prior.. \\res\toolbar ... \\res\ on so forth....
				all other icons will reside in the root "res" directory

So please if you have any comments questions or ideas please by allmeans feel free

No objections to any of it. Looks like you’re taking care of userlist coloring. For chat formatting, the next step is probably either to take advantage of DC++ finally getting wide character regex support to replace the dummy RTF chat formatting code in RichTextBox::rtfEscape and RichTextBox::rtfEscapeFormatter with real code more akin to dcpp.FormatChatText or adopt mshtml and perform some similar tranformations. Whilst the regular expressions currently live in Lua code, they’re not Lua-specific in general and should be easy to transpose into boost::regex.

I don’t recall seeing anyone object, really, to parts of this proposal that have been presented; it’s just a matter of someone actually doing it.

I would love to see some kind of mshtml implemented, would make a lot more sense and would be easier and afaik (from you) it should run under wine and yes I have decided to take some initiative in undertaking this task, would be something pretty nice to see as a finished project…as for regex are you familiar with the way Trem did some of the things in fulDC in that respect with highlighting…I’d really like some opinions especially from some of you “senior” guys and perhaps a little help and guidance. Unfortunately documentation for dwt is practically nonexistent so it may be a bit tougher for me but it’s worth it in the end imho.

Yes, WINE seems to support the MSHTML control and I agree that it’s preferable to richedit in allowing for easier implementation of pretty magnet links and more control over link formatting. I’m unfamiliar with how Trem did chat formatting. Also, how does e.g. StrongDC++ or ApexDC++ format chat? These are all options.

dwt indeed mostly lacks documentation, but since it’s derived from SmartWin++, its documentation might prove useful. I don’t recall how much it’s changed since though. poy could probably most usefully comment on how applicable SmartWin++ documentation might prove to dwt. It’s also not much code, especially for a GUI framework, so simply reading through it as needed is both practical and helps a lot.

Yeah actually ran into a problem with some commenting in regards to doing redraws in dwt with some of my CustomDraw stuff (which i didn’t need in the end but still) that was quite useless as it was an artifact from the smartwin developers that poy or arne had left behind in Table.h (something in regards to invalidateWidget). As for the highlighting, basically you could use regular expressions to highlight certain things in chat like keywords or phrases…pretty much whatever (which can prove very useful). As for StrongDC/Apex they use a custom chatCtrl with CHARFORMAT2

Hopefully you pointed that obsolete Table.h comment documentation out to either poy or arne - that way it won’t just linger there for the next person to find.

fulDC’s method sounds potentially useful. StrongDC++ and ApexDC++ sound like they rather excessively reimplement what one could just get from MSHTML. Most of the actual difficulty lies not in the formatting/highlighting per se but in the GUI and storage schemas for such an extensively configurable feature, so I’d generally suggest that someone figure out what GUI they’re willing to create for this feature and then let the chat text -> RTF and/or HTML code follow almost automatically.

Yes, I brought it up to poy so hopefully he will begin going through dwt and ridding it all of the useless source comments, and perhaps create some sort of initial documentation for dwt.

Yeah I believe that MSHTML would essentially be much more of a feasible and “common” sense choice for this and implementing in dwt would be a good choice (but considering that StrongDC and Apex eventually will migrate to wxWidgets I don’t know if they would do the same)

wxWidgets has wxHtmlWindow, which is their analogue to MSHTML, so that approach is still viable for StrongDC++ and ApexDC++.

As far as DC++'s implementation - the GUI is relatively independent of the underlying markup transformation/application, so it should be possible, without much ultimately wasted effort even if/when DC++ transitions to using MSHTML, to write a configuration/setup system for chat formatting, then adapt it to whatever display control DC++ uses at the time. It’s not even that helpful to wait for someone to implement MSHTML to start.

Oh I didn’t mean to say that they couldn’t or wouldn’t but it’s completely up to them although it could create some uniformity among the different clients.

I agree I would like to begin with it ASAP in all reality, and like you previously said in regards to going through dwt and finding out how things are handled and work, I have been but sometimes for me at least it’s easier to have some formal documentation, it’s just the way I find easiest to learn, although I do sit there and go through dwt bit by bit and find out how to do things so all hope for me isn’t completely lost lol. I know for me it won’t be a “fast” process, but it will be an excellent learning experience and obviously a great and much needed enhancement to DC++.

StrongDC++ uses pure richedit and set text’s format when some specific sequence (own nick, OP nick) is found. I’m not thinking about migrating to wxHtmlWindow now, it’s just not needed and I don’t see any benefits in it.

have you looked into the Windows theme format, <>? would be great if whichever theme format we choose could be derived from another popular format. failing that, XML would be the most sensible alternative since it is what DC++ uses for other settings.

regarding icons, it is generally frowed up requiring users to make changes into the Program Files directory that they normally don’t have access to. ideally, these would just be packed along with the theme, in a directory that has the same name as the theme, similarly to what Windows themes do.

the rest is dependant on how we (and the plugin system) will first tackle the chat implementation.

No I haven’t looked into the windows theme format, but the format would be similar to .dctheme formats (I propose a name change so people wouldn’t use other clients .dctheme files to load a theme that wont work since there are so many variations as is) which on load file will be filtered to .dcstyle file extensions only.

unfortunately you are right making changes to the program files directory IS frowned upon the only other solution i could think of would be to load internally (while retaining the original icons in exe like StrongDC does for toolbar icons and userlist icons)

regarding icons, it is generally frowed up requiring users to make changes into the Program Files directory that they normally don’t have access to.

The recomended solution is to use %APPDATA%, and choose your flavor wisely. We used this when packaging old ***DC++ zip clients so they had write access to their enitre settings area without having write access to program files


The problem with this is the average user won’t really know where t go and how to change the icons, so the question is, how do you make it easier for them, my solution would be when the icons are loaded to automatically have DC++ save them into a “icons” or “res” directory kind of how SdDC++ (albeit in that client it saves to binary files but still the same nonetheless).

Solution to that is to have a wizard in DC++ which takes care of that for you. The end user should not have to touch %APPDATA% directly.

I cant think of a nice way of doing this though.

well that’s why i was thinking of using a way through settings to load the icons… i.e Settings > Appearance > Themes (for sake of discussion)
and just load them through settings like that because it can get messy … or perhaps a way to utilize zlib to import compressed icon packages and use DC++ to save them to appdata (or if not using dcppboot save them to where the exe is (only on standalone exe packages)

This is what I have seen some zlib using applications do when it comes to loading/placing stuff into location that user can not be assumed to find.

Make a zip file (or whatever other archive, compression is really not the point here, format that can hold full directory trees) change the extension to a special one then register that extension so that when the file is clicked the app can then effectively “install” the files to the correct location.

I have made a test function in DiCe!++ (gonna be uploading to its own bzr as a standalone project) which will be able to do .z or .bz2 (well any extension i choose really…)

const DataArraySizeType::size_type DataArraySizeType::npos = -1;

const string DataStructure::dataHeader =
	" Version=" + Util::toString(THEME_VERSIONFLOAT) +
	" CompatibleVersion=1.00" // shouldn't see too many version changes 
	" App=" + DiceUtil::escape<string>(APPNAME, escapeChars.c_str()) + " AppVersion=" + Util::toString(VERSIONFLOAT) +
	" Encoding=utf-8]";

const string DataStructure::escapeChars =	"[] /=";

use that as the data header for a .dcstyle file and the rest compressed into like isaid before a bz2 or .z based compression agorithm which is nice since DC++ natively has both =)

The only problem here… that is restricted to single file, unless you add directory record which essentially would make it a make-shift zip file.

My point, this has a limitation in the long run that will cause incompatibility if you ever need more than one file in a style. Which in reality is quite likely if something like this lands in vanilla dcpp, because then people would want to start changing toolbar icons and the like.

Plus, adding real zip file support to dcpp is no rocket science, all you need is to include mini(un)zip related files and compile them into zlib used by dcpp to get access to the unz… api to extract zip files (involves 4-5 files if I recall correctly).

well i would have to agree zip files do make more sense as an alternative and if it’s only a minor adjustment to the source than it shouldn’t be that big of a deal to add in then