Modernizing DC++

Site Announcements
poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: Modernizing DC++

Post by poy » 26 Jan 2011, 19:40

iceman50 wrote:.dcstyle "Theming" proposal for DC++

Code: Select all

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\userlist...so on so forth....
				all other icons will reside in the root "res" directory
have you looked into the Windows theme format, <http://msdn.microsoft.com/en-us/library ... S.85).aspx>? 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.

iceman50
Junior Member
Posts: 26
Joined: 10 Jun 2010, 15:10

Re: Modernizing DC++

Post by iceman50 » 26 Jan 2011, 20:13

poy wrote:have you looked into the Windows theme format, <http://msdn.microsoft.com/en-us/library ... S.85).aspx>? 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.
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.
poy wrote: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.
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)

andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: Modernizing DC++

Post by andyhhp » 26 Jan 2011, 22:54

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

~Andrew

iceman50
Junior Member
Posts: 26
Joined: 10 Jun 2010, 15:10

Re: Modernizing DC++

Post by iceman50 » 27 Jan 2011, 18:25

andyhhp wrote: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).

andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: Modernizing DC++

Post by andyhhp » 28 Jan 2011, 00:57

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.

iceman50
Junior Member
Posts: 26
Joined: 10 Jun 2010, 15:10

Re: Modernizing DC++

Post by iceman50 » 03 Feb 2011, 21:00

andyhhp wrote: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)

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Modernizing DC++

Post by Crise » 05 Feb 2011, 19:23

iceman50 wrote:
andyhhp wrote: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.

iceman50
Junior Member
Posts: 26
Joined: 10 Jun 2010, 15:10

Re: Modernizing DC++

Post by iceman50 » 15 Feb 2011, 02:57

Crise wrote: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...)

Code: Select all

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

const string DataStructure::dataHeader =
	"[Theme"
	" 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 =)

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Modernizing DC++

Post by Crise » 15 Feb 2011, 12:27

iceman50 wrote:
Crise wrote: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...)

Code: Select all

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

const string DataStructure::dataHeader =
	"[Theme"
	" 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).

iceman50
Junior Member
Posts: 26
Joined: 10 Jun 2010, 15:10

Re: Modernizing DC++

Post by iceman50 » 15 Feb 2011, 14:51

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

Locked

Who is online

Users browsing this forum: No registered users and 1 guest