Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using fonts for icons
49 views
Skip to first unread message
Eduardo
Apr 28, 2015, 6:40:36 AM4/28/15
to
Hi folks.
I'm currently in the task of providing better DPI aware support to a
program, and the main problem at this time are the icons.
They are mostly toolbar icons but also some icons in buttons.
I'm using bmp images with MaskColor, not *.ico icons.
When a program runs in another DPI setting, most of the things are
automatically scaled by VB: fonts, controls, Etc.
And if the code handles them in Twips, everything seems to work fine.
But the images at the toolbar and buttons are not scaled.
So my current approach was to let VB to scale all the controls and fonts,
and to set the dimensions of the toolbars and buttons (with icons) by code
to their fixed pixel dimensions based on the dimensions of the images that
they host.
This seemed to work acceptable when running on 120 DPI (I develop in 96
DPI), but recently I saw how it appear at 144 DPI, and the icons appear too
small.
So I need to fix it in some way. There seems not to be an easy way for
dealing with this issue.
The options that I see are:
Option 1) To store several different images for each icon, like 32x32, 48x48
(and may be also 64x64) and use the better one for the DPI setting that the
system has.
Option 2) To have only one image, it could be 32x32 or 64x64 and to stretch
the image to the proper dimension.
The problem with this approach is the MaskColor, because if I use quality
stretching algorithms (like Bilinear), the MaskColor will be blended with
the image colors.
The possible solutions that I can think:
a) To use the nearest neighbor algorithm. The problem with that is that the
images won't look fine.
b) To stretch the images first taking out the Maskcolor, and painting them
directly on the surface. The problem is that I need the surface already
painted with the background in advance. It seems too complicated to do it
right.
What I wrote above was an introduction, not it comes the actual question.
Option 3) This is a different idea: to use fonts for the icons instead of
images.
Of course it won't be a normal font like Arial, with normal letters like
ABC. It will be a font that has icons like Wingdings.
So the idea is to replace the icons with this "icons letters", and so let VB
to scale them to the required DPI as it does with other fonts.
I found a site that lets you make a font that will have just the icons that
want to use: https://icomoon.io/#home
The advantages:
They scale properly to different DPI.
They have high contrast.
The disadvantages:
They are monochrome, of just one color. You can change the color of each
icon, but one icon will have just one background color and one foreground
color.
Now the question: do you have any experience with this?
What do you think of this idea? (before I spend a lot of time doing it).
Thanks.
I'm currently in the task of providing better DPI aware support to a
program, and the main problem at this time are the icons.
They are mostly toolbar icons but also some icons in buttons.
I'm using bmp images with MaskColor, not *.ico icons.
When a program runs in another DPI setting, most of the things are
automatically scaled by VB: fonts, controls, Etc.
And if the code handles them in Twips, everything seems to work fine.
But the images at the toolbar and buttons are not scaled.
So my current approach was to let VB to scale all the controls and fonts,
and to set the dimensions of the toolbars and buttons (with icons) by code
to their fixed pixel dimensions based on the dimensions of the images that
they host.
This seemed to work acceptable when running on 120 DPI (I develop in 96
DPI), but recently I saw how it appear at 144 DPI, and the icons appear too
small.
So I need to fix it in some way. There seems not to be an easy way for
dealing with this issue.
The options that I see are:
Option 1) To store several different images for each icon, like 32x32, 48x48
(and may be also 64x64) and use the better one for the DPI setting that the
system has.
Option 2) To have only one image, it could be 32x32 or 64x64 and to stretch
the image to the proper dimension.
The problem with this approach is the MaskColor, because if I use quality
stretching algorithms (like Bilinear), the MaskColor will be blended with
the image colors.
The possible solutions that I can think:
a) To use the nearest neighbor algorithm. The problem with that is that the
images won't look fine.
b) To stretch the images first taking out the Maskcolor, and painting them
directly on the surface. The problem is that I need the surface already
painted with the background in advance. It seems too complicated to do it
right.
What I wrote above was an introduction, not it comes the actual question.
Option 3) This is a different idea: to use fonts for the icons instead of
images.
Of course it won't be a normal font like Arial, with normal letters like
ABC. It will be a font that has icons like Wingdings.
So the idea is to replace the icons with this "icons letters", and so let VB
to scale them to the required DPI as it does with other fonts.
I found a site that lets you make a font that will have just the icons that
want to use: https://icomoon.io/#home
The advantages:
They scale properly to different DPI.
They have high contrast.
The disadvantages:
They are monochrome, of just one color. You can change the color of each
icon, but one icon will have just one background color and one foreground
color.
Now the question: do you have any experience with this?
What do you think of this idea? (before I spend a lot of time doing it).
Thanks.
Eduardo
Apr 28, 2015, 7:53:38 AM4/28/15
to
"Eduardo" <m...@mm.com> escribió en el mensaje
news:mhno2o$4gg$1...@speranza.aioe.org...
Now that large resolution monitors are common, and perhaps the standard will
be 1980x1080, people with small sized screens (physically small) and people
with not too good vision will be prone set Windows to 120, 144 or even 196
DPI.
I think that we need to find a general approach to the problems that it
brings.
My general approach, as I already say is to work all in Twips (and declare
the app as DPI aware).
But the icon issue is remaining. There is a need to find a general approach
to work around this problem.
To use different size of icons for each DPI (Option 1 in my previous post)
seems to be the best one, because you will have good icons for each case,
and with colors.
But not being a graphic designer expert, I roughly could make one icon set
for my programs, with hard work. To make two or more icons sets for the
other DPI setting, will be very challenging and time consuming.
To scale the icons (Option 2 in my previous post), remove the necessity of
having different sizes for each icon, still having different colors, but it
seems too complex to render them right, and the icons won't be too good
anyway because they will be blurred.
Option 3 was using fonts. And the is another option that seems to be similar
to using fonts: *svg files. They are vector based icons (like the fonts
are). But they are also monochrome (like fonts).
Isn't there any vector based icon technology that can have more than one
color?
Eduardo
Apr 28, 2015, 8:01:06 AM4/28/15
to
news:mhnsbu$gft$1...@speranza.aioe.org...
And also must be under consideration that some users could have screens of
800x600 (at lest in some cases), so to make all the icons bigger for every
case is not an option.
800x600 (at lest in some cases), so to make all the icons bigger for every
case is not an option.
Eduardo
Apr 28, 2015, 9:31:25 AM4/28/15
to
I made a decision.
I checked and I'm using now 16x16 images.
I'll make another set, of 32x32. I'll scale the images with nearest
neighbor, so the mask color is not blended into the images.
I'll use 16x16 or 32x32 based on screen size and DPI setting
(TwipsPerPixels).
I checked and I'm using now 16x16 images.
I'll make another set, of 32x32. I'll scale the images with nearest
neighbor, so the mask color is not blended into the images.
I'll use 16x16 or 32x32 based on screen size and DPI setting
(TwipsPerPixels).
GS
Apr 28, 2015, 11:13:20 AM4/28/15
to
success...
http://www.gdgsoft.com/gconvert/
--
Garry
Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion
Eduardo
Apr 28, 2015, 1:51:46 PM4/28/15
to
"GS" <g...@v.invalid> escribió en el mensaje
news:mho80h$rjl$1...@dont-email.me...
>> "Eduardo" <m...@mm.com> escribió en el mensaje
>> news:mhno2o$4gg$1...@speranza.aioe.org...
>>
>> I made a decision.
>> I checked and I'm using now 16x16 images.
>> I'll make another set, of 32x32. I'll scale the images with nearest
>> neighbor, so the mask color is not blended into the images.
>> I'll use 16x16 or 32x32 based on screen size and DPI setting
>> (TwipsPerPixels).
>
> I've been using this icon software for some years with really good
> success...
>
> http://www.gdgsoft.com/gconvert/
Thanks
>> news:mhno2o$4gg$1...@speranza.aioe.org...
>>
>> I made a decision.
>> I checked and I'm using now 16x16 images.
>> I'll make another set, of 32x32. I'll scale the images with nearest
>> neighbor, so the mask color is not blended into the images.
>> I'll use 16x16 or 32x32 based on screen size and DPI setting
>> (TwipsPerPixels).
>
> I've been using this icon software for some years with really good
> success...
>
> http://www.gdgsoft.com/gconvert/
Bob R
Apr 29, 2015, 5:19:26 PM4/29/15
to
Free, create, edit, resize etc.
http://www.iconedit.com/
--
--
--
No signature
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
http://www.iconedit.com/
--
--
--
No signature
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Ulrich Korndoerfer
Apr 29, 2015, 5:52:42 PM4/29/15
to
Eduardo schrieb:
> ...
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
> ...
> Option 3 was using fonts. And the is another option that seems to be similar
> to using fonts: *svg files. They are vector based icons (like the fonts
> are). But they are also monochrome (like fonts).
>
> Isn't there any vector based icon technology that can have more than one
> color?
>
>
SVG of course.
> to using fonts: *svg files. They are vector based icons (like the fonts
> are). But they are also monochrome (like fonts).
>
> Isn't there any vector based icon technology that can have more than one
> color?
>
>
--
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
Eduardo
Apr 30, 2015, 6:30:15 PM4/30/15
to
"Ulrich Korndoerfer" <ulrich_wa...@prosource.de> escribió en el
mensaje news:cqd259...@mid.individual.net...
> Eduardo schrieb:
>
>> ...
>> Option 3 was using fonts. And the is another option that seems to be
>> similar to using fonts: *svg files. They are vector based icons (like the
>> fonts are). But they are also monochrome (like fonts).
>>
>> Isn't there any vector based icon technology that can have more than one
>> color?
>
> SVG of course.
I thought they were monochrome, all the svg files that I saw were just
>
>> ...
>> Option 3 was using fonts. And the is another option that seems to be
>> similar to using fonts: *svg files. They are vector based icons (like the
>> fonts are). But they are also monochrome (like fonts).
>>
>> Isn't there any vector based icon technology that can have more than one
>> color?
>
> SVG of course.
black.
Ulrich Korndoerfer
Apr 30, 2015, 10:32:21 PM4/30/15
to
Eduardo schrieb:
>>> Isn't there any vector based icon technology that can have more than one
>>> color?
>> SVG of course.
>
> I thought they were monochrome, all the svg files that I saw were just
> black.
Google might had helped, eg with the search string "svg examples".
By the way, since Vista MS stated that icons as bitmaps should be
present in a variety of sizes up to 256x256, at least with the sizes
16x16, 32x32, 48x48 and 256x256. Remember that application icons are
shown at different places, eg in a windows explorer window or in the
applications window and there they will be shown in different sizes. So
for avoiding scaling even for the "standard" monitor resolution with 96
dpi at least these sizes should be preent. Then for avoiding scaling
those for higher dpis MS recommends to include further sizes for some
more "standard" dpis, eg for the 16x16 size at 96 dpi there also should
be present 20x20 (120 dpi), 24x24 (144 dpi), 32x32 (192 dpi).
Icons in vector format can be used if you provide for rendering to icons
yourself. Then SVG, WMF or even PDF or PS come to mind as usable vector
format. Direct use of icons in vector format (where the system does the
rendering to bitmap automatically) is to my knowledge only possible for
programs that are implemented using XAML (that is .NET programs). There
SVG code can be transformed to XAML format.
>>> Isn't there any vector based icon technology that can have more than one
>>> color?
>> SVG of course.
>
> I thought they were monochrome, all the svg files that I saw were just
> black.
By the way, since Vista MS stated that icons as bitmaps should be
present in a variety of sizes up to 256x256, at least with the sizes
16x16, 32x32, 48x48 and 256x256. Remember that application icons are
shown at different places, eg in a windows explorer window or in the
applications window and there they will be shown in different sizes. So
for avoiding scaling even for the "standard" monitor resolution with 96
dpi at least these sizes should be preent. Then for avoiding scaling
those for higher dpis MS recommends to include further sizes for some
more "standard" dpis, eg for the 16x16 size at 96 dpi there also should
be present 20x20 (120 dpi), 24x24 (144 dpi), 32x32 (192 dpi).
Icons in vector format can be used if you provide for rendering to icons
yourself. Then SVG, WMF or even PDF or PS come to mind as usable vector
format. Direct use of icons in vector format (where the system does the
rendering to bitmap automatically) is to my knowledge only possible for
programs that are implemented using XAML (that is .NET programs). There
SVG code can be transformed to XAML format.
Eduardo
Apr 30, 2015, 10:46:28 PM4/30/15
to
mensaje news:cqg6tj...@mid.individual.net...
monochrome.
> By the way, since Vista MS stated that icons as bitmaps should be present
> in a variety of sizes up to 256x256, at least with the sizes 16x16, 32x32,
> 48x48 and 256x256. Remember that application icons are shown at different
> places, eg in a windows explorer window or in the applications window and
> there they will be shown in different sizes. So for avoiding scaling even
> for the "standard" monitor resolution with 96 dpi at least these sizes
> should be preent. Then for avoiding scaling those for higher dpis MS
> recommends to include further sizes for some more "standard" dpis, eg for
> the 16x16 size at 96 dpi there also should be present 20x20 (120 dpi),
> 24x24 (144 dpi), 32x32 (192 dpi).
I have different size of the icon of my app icon, but now I'm working on the
toolbars and buttons icons inside the program.
> Icons in vector format can be used if you provide for rendering to icons
> yourself. Then SVG, WMF or even PDF or PS come to mind as usable vector
> format. Direct use of icons in vector format (where the system does the
> rendering to bitmap automatically) is to my knowledge only possible for
> programs that are implemented using XAML (that is .NET programs). There
> SVG code can be transformed to XAML format.
Yes, svg seems to be a good option then.
But I didn't find any code for handling svg files in VB6 on the web at this
time...
> Eduardo schrieb:
>
>>>> Isn't there any vector based icon technology that can have more than
>>>> one color?
>>> SVG of course.
>>
>> I thought they were monochrome, all the svg files that I saw were just
>> black.
>
> Google might had helped, eg with the search string "svg examples".
Yes, sorry, I searched and saw several all monochrome and assumed all were
>
>>>> Isn't there any vector based icon technology that can have more than
>>>> one color?
>>> SVG of course.
>>
>> I thought they were monochrome, all the svg files that I saw were just
>> black.
>
> Google might had helped, eg with the search string "svg examples".
monochrome.
> By the way, since Vista MS stated that icons as bitmaps should be present
> in a variety of sizes up to 256x256, at least with the sizes 16x16, 32x32,
> 48x48 and 256x256. Remember that application icons are shown at different
> places, eg in a windows explorer window or in the applications window and
> there they will be shown in different sizes. So for avoiding scaling even
> for the "standard" monitor resolution with 96 dpi at least these sizes
> should be preent. Then for avoiding scaling those for higher dpis MS
> recommends to include further sizes for some more "standard" dpis, eg for
> the 16x16 size at 96 dpi there also should be present 20x20 (120 dpi),
> 24x24 (144 dpi), 32x32 (192 dpi).
toolbars and buttons icons inside the program.
> Icons in vector format can be used if you provide for rendering to icons
> yourself. Then SVG, WMF or even PDF or PS come to mind as usable vector
> format. Direct use of icons in vector format (where the system does the
> rendering to bitmap automatically) is to my knowledge only possible for
> programs that are implemented using XAML (that is .NET programs). There
> SVG code can be transformed to XAML format.
But I didn't find any code for handling svg files in VB6 on the web at this
time...
Ulrich Korndoerfer
May 1, 2015, 1:15:24 AM5/1/15
to
Eduardo schrieb:
> ...
Cairo graphics library which handles SVG rendering with ease. The
vbRichClient additionally has a SVG-class which eg can render SVG code
to Windows icons. At
http://www.vbrichclient.com
one can download also some demo code for Cairo usage including SVG
rendering.
> ...
> Yes, svg seems to be a good option then.
> But I didn't find any code for handling svg files in VB6 on the web at this
> time...
Olafs vbRichClient library (written in VB) comes to mind. It wraps the
> But I didn't find any code for handling svg files in VB6 on the web at this
> time...
Cairo graphics library which handles SVG rendering with ease. The
vbRichClient additionally has a SVG-class which eg can render SVG code
to Windows icons. At
http://www.vbrichclient.com
one can download also some demo code for Cairo usage including SVG
rendering.
Eduardo
May 1, 2015, 7:44:13 AM5/1/15
to
mensaje news:cqggf9...@mid.individual.net...
> Eduardo schrieb:
>
>> ...
>> Yes, svg seems to be a good option then.
>> But I didn't find any code for handling svg files in VB6 on the web at
>> this time...
>
> Olafs vbRichClient library (written in VB) comes to mind. It wraps the
> Cairo graphics library which handles SVG rendering with ease. The
> vbRichClient additionally has a SVG-class which eg can render SVG code to
> Windows icons. At
>
> http://www.vbrichclient.com
>
> one can download also some demo code for Cairo usage including SVG
> rendering.
No, I won't add a third party library.
>
>> ...
>> Yes, svg seems to be a good option then.
>> But I didn't find any code for handling svg files in VB6 on the web at
>> this time...
>
> Olafs vbRichClient library (written in VB) comes to mind. It wraps the
> Cairo graphics library which handles SVG rendering with ease. The
> vbRichClient additionally has a SVG-class which eg can render SVG code to
> Windows icons. At
>
> http://www.vbrichclient.com
>
> one can download also some demo code for Cairo usage including SVG
> rendering.
Schmidt
May 1, 2015, 12:13:48 PM5/1/15
to
Am 01.05.2015 um 13:43 schrieb Eduardo:
>> one can download also some demo code for Cairo usage including SVG
>> rendering.
>
> No, I won't add a third party library.
Any problem which is a bit more complex is encapsulated in
>> one can download also some demo code for Cairo usage including SVG
>> rendering.
>
> No, I won't add a third party library.
"3rd-party-libs" (proper SVG-Parsing/Rendering certainly among them).
So, if you will ever end up with SVG-support within your App, then
you will use it from such a library.
If you go the other route - not using Vector-Graphics, but Alpha-
capable 32Bit-Pixel-Formats with "somewhat oversized PNGs or ICOs",
then used with proper downscaling (thereby not destroying the Alpha-
Channel), you will make use of 3rd-party libs too (from MS or others).
So I guess (since MS-libs are apparently favoured?) that you have
either "greater trust in MS" - or a deployment-problem (not knowing
how to use 3rd-party COM-libs regfree).
Olaf
Eduardo
May 1, 2015, 2:36:53 PM5/1/15
to
"Schmidt" <n...@vbRichClient.com> escribió en el mensaje
news:mi08lr$55e$1...@dont-email.me...
I use very few libraries. I like to have the control of how my program works
(and to be able to fix bugs).
The next step is to get rid of Windows.
Eduardo
May 1, 2015, 2:50:46 PM5/1/15
to
"Eduardo" <m...@mm.com> escribió en el mensaje
news:mi0h3v$10e$1...@speranza.aioe.org...
>> So I guess (since MS-libs are apparently favoured?) that you have
>> either "greater trust in MS" - or a deployment-problem (not knowing
>> how to use 3rd-party COM-libs regfree).
>
> No, MS libraries are not favored. I get rid of all that I can.
> I use very few libraries. I like to have the control of how my program
> works (and to be able to fix bugs).
But now I'm working in VB6, COM based, to be run under Windows. Then it's
not possible.
It's nothing about your component that you gently make available for others
to use.
But I prefer to avoid any chance of future trouble, as possible.
It's just about what MS did to us that I took this idea of not to depend on
others, whenever is possible.
Schmidt
May 1, 2015, 3:57:59 PM5/1/15
to
Am 01.05.2015 um 20:50 schrieb Eduardo:
> If I could I would rule out all MS dependencies in the first place.
> But now I'm working in VB6, COM based, to be run under Windows. Then it's
> not possible.
>
> It's nothing about your component that you gently make available for others
> to use.
> But I prefer to avoid any chance of future trouble, as possible.
>
> It's just about what MS did to us that I took this idea of not to depend on
> others, whenever is possible.
>
That'd be sad, when they indeed caused this effect in that "generality"
> If I could I would rule out all MS dependencies in the first place.
> But now I'm working in VB6, COM based, to be run under Windows. Then it's
> not possible.
>
> It's nothing about your component that you gently make available for others
> to use.
> But I prefer to avoid any chance of future trouble, as possible.
>
> It's just about what MS did to us that I took this idea of not to depend on
> others, whenever is possible.
>
on your end.
Especially in case of the RichClient, which is a project with the
*goal to decouple* from as many MS-dependecies as possible (to have
it easier in a later port to other OSes, behind "Class-Interfaces,
which abstract from a given System-API").
In case you're using ADO/JET for example (which I think you do in your
project), you could decouple from that depency entirely (avoiding the
risk that MS breaks it - or doesn't preinstall it anymore).
Also with the MS-Graphics-Systems (where they're still in turmoil,
which way to go in the future - GDI+, Direct2D, WPF, XAML, WinForms) -
one of those techs will be favoured at some point - and none of them
relies on classic GDI.
I'm not saying that I expect GDI to go in future Win-Versions (far from
it, because that would break nearly 100% of all GUI-Apps which are
out there).
But they might favour one of their new Graphics-Engines for example
as the "preferred method to refresh the content of a given Window"
(some of that is already in place in the new Composing-WinManager
since Vista, then e.g. causing the weird effects in the VB6-IDE,
when Controls are dragged or selected in the VB6-FormDesigner).
GDI still integrated and working "decently well" also on Win7/Win8 -
but chances are, that its current position from "second citizen" will
get shifted further down the "Legacy and CompatibilityMode-queue" in
upcoming Win-Versions.
With the RichClient-graphics you'd be quite independent from all that,
since the platform-independend cairo-lib is used for all renderings
(and the final flip to the hosting hWnd - which is currently based
on a simple GDI-BitBlt-call - could be adjusted to more performant
"recommended versions" in the future, should that be needed).
There's already such a more modern Flip-call integrated (making use
of Direct2D under the covers), in case one requests the appropriate
Surface-Type (with the enum-param DXorGLWindow).
Not trying to force it down your throat or something - but since it's
still actively maintained (and the sources spread among a few community-
members), you shouldn't have all that many fears as with perhaps a few
other Dlls (which might not be maintained anymore).
Olaf
Eduardo
May 1, 2015, 4:37:11 PM5/1/15
to
"Schmidt" <n...@vbRichClient.com> escribió en el mensaje
news:mi0lq7$s6a$1...@dont-email.me...
bit on another (RichClient)
If there was a component or a set of components to get rid of all (or the
most part) of MS altogether, it would be more attractive to me.
But to put myself not only in the hands and good will of one, but on two
third party sources... doesn't seem a good idea.
In other words: if you some day finish the VB6 replacement, I'll be glad to
test it and migrate to it (if possible).
PS: you know that I'm a "difficult" guy, to convince. Perhaps I'm wasting my
time not having migrated to your RichClient already, who knows.
I have a project of more than 110.000 lines, about 100 forms, 80 class
modules, 20 usercontrols.
BTW: I use DAO.
I try to avoid problems as possible. Still, I have a lot.
About svg icons: it seems that the use of svg icons is still very limited
today, almost all the icons sites offer them in png format, not vector
based.
Most of the few sites that offer svg icons, are monochrome, like this:
http://www.flaticon.com/categories/interface
I found a set of colored svg icons:
http://sora-meliae.deviantart.com/art/Meliae-SVG-Icon-Theme-v-1-2-151155215
I don't know why svg icons are still not used on Windows programs, they have
the advantage of easily making DPI aware apps.
The disadvantage may be the difficulty to customize them or to make your
own.
Schmidt
May 1, 2015, 10:00:12 PM5/1/15
to
Am 01.05.2015 um 22:36 schrieb Eduardo:
> You propose then to make an hybrid: to depend a bit on one source (MS) and a
> bit on another (RichClient)
No, what you get with the RC5 is a kind of "vbRuntime-Classes 6.5",
> You propose then to make an hybrid: to depend a bit on one source (MS) and a
> bit on another (RichClient)
which already does *not* require you to depend on:
- MS-ADO/JET (SQLite serves as well in the typical Desktop-DB-scenarios)
- MS-GDI+ (nice graphics-support per cairo instead)
- MS-XML COMponents (the RC5-Classes are stable and faster)
- MS-FSO (cFSO can be used instead for Unicode-capable FileHandling)
- MS-Winsock (not needed due to API-based Socket-Classes)
- MS-CommonControls (one can make use of vbWidgets.dll instead)
In combination with the new vbRuntime-independent Form-Engine, you'd
decouple already from a lot of potential stuff which "could break"
or not being available in the future (for normally written VB-Apps).
If you don't use or need anything of the above in your Apps
(directly or indirectly), then you're not "safer with the RC5" -
but if you do - and use the replacements, then you are.
How much safer - that depends - but saying that using the RC5
involves an even greater risk, is just plain wrong (as long as COM
is supported on MS-Systems - and the vbRuntime requires that anyways).
> If there was a component or a set of components to get rid of all (or
> the most part) of MS altogether, it would be more attractive to me.
under the covers of the RC5, is normal (any platform-independent
framework needs to address those System-APIs, in case a "Window
needs to be shown", or a "File needs to be accessed, or a Socket") -
but in certain other categories there's an entire set of System-APIs
which are completely avoided inside the library.
> But to put myself not only in the hands and good will of one, but on
> two third party sources... doesn't seem a good idea.
I'm a longterm VB-Community-Member who bundled a few Man-Years of
work in an free usable package, to close some gaps for the community,
and make what you build on it (somewhat) less dependent on MS...
IF that's not good-will "right there", then I don't know...
Nobody will ever be able to take this COM-lib away from VB6-users.
It would provide what it contains currently (even in case I wont
maintain it anymore) for many more years to come - and would
work as long as the vbRuntime is working on new systems.
> ...you know that I'm a "difficult" guy, to convince. Perhaps I'm wasting
> my time not having migrated to your RichClient already, who knows.
Nobody requires you to do a "full migration" or something - it
contains enough Classes which are not GUI-related, and which you
could incorporate as slowly as you like...
> I have a project of more than 110.000 lines, about 100 forms,
> 80 class modules, 20 usercontrols.
> BTW: I use DAO.
> I try to avoid problems as possible. Still, I have a lot.
scans and stuff" (IIRC), and the performance could still be better
than what you have currently with DAO/JET, why not simply pick
an isolated test-case which performs not as it should, and try
to re-implement only that smaller part with the SQLite-classes.
This engine is really fast and worth a try (converting a JET-*.mdb
is only a matter of using the cConverter-Class of the RC5, with
a few lines of code).
> About svg icons: it seems that the use of svg icons is still very limited
> today, almost all the icons sites offer them in png format, not vector
> based.
Nearly in all OpenSource-Desktop-Projects (KDE or GNome) there's a whole
lot of Icons involved - and the first format the "Designer-Guys" will
produce from either InkScape (an OpenSource-App, which can read and
write SVG as its native format) - or the ones "with a lot of money -
or appropriate Jobs" use Adobe-Illustrator (producing vector-files in
*.ai format then).
These "Desktop-Icon-Sets" - e.g. as the one you linked to below:
> http://sora-meliae.deviantart.com/art/Meliae-SVG-Icon-Theme-v-1-2-151155215
Will then often *not* contain the SVG-originals the Designers have
in their Project-Folders, but already pre-rendered PNG-Files in
different resolutions (that's mainly out of performance-reasons,
since the *parsing+rendering* of an existing SVG often takes (much)
more time, than simply loading (and uncompressing) a *.png-File
(when the SVG-file is a complex one, which most of the nicer ones are).
Current practice is, to load a somewhat higher resolution PNG-file
into the App - and then Downscale from its Pixel-Content (which
doesn't produce much different results from an SVG which is rendered
into the desired size directly, when the Downstretch-Algo is a
decent one).
> I don't know why svg icons are still not used on Windows programs, they
> have the advantage of easily making DPI aware apps.
for SVG - the newer MS-Browser-Engines (since IE9) can render SVG -
but that functionality is not exposed as an easy usable API somewhere
(at least not to my knowledge).
The other reason I already tried to explain above; if your App is using
*a lot* of Icons on a given Form, then rendering them over and over
directly from a given SVG-content is performance-wise not advisable.
What I do is quite similar to how the OpenSource-Guys handle that stuff,
I convert either to decently sized PNGs and ship these with my Apps
(using the DownScale-approach I mentioned) - or load them dynamically -
but only once, on App-Startup - converting them to a "decently sized"
Cairo-Surface beforehand (which is then used for the Pixelbased down-
scaling again).
> The disadvantage may be the difficulty to customize them or to make
> your own.
and edit/change/combine an SVG-File over and over again - they are
often constructed in Layers - and each little Path-Object can be
clicked+selected and then changed with regards to the outline -
or the Stroke, or the Fill-Color, or Fill-Gradients etc.
As said, InkScape is the Tool when you want to use Free-Software -
and Corel- or Adobe (as well as other Vendors) have Vector-Editors
too (most of these Tools can read any of the other Formats which
are common, e.g. InkScape can ready *.ai files as well - and
Adobe-Illustrator can also export to *.svg).
In case you're interested in a larger IconSet of about 1000 SVGs
(which BTW comes also under a more liberal license which allows
also commercial usage -> LGPL - whereas the Link you gave above,
comes under GPL only - so commercial usage would be forbidden).
Here's a link to the Oxygen GitHub-Repo, where you can download
this quite large set (73MB or so) over the small Button:
"Download Zip"- at the right-hand-side of the GitHub-Page:
https://github.com/rubenvb/oxygen-icons-svg
In case you want to make use of my small Viewer-App I've just
adjusted to the latest version of the RC5:
ScreenShot:
http://vbRichClient.com/Downloads/OxygenIconViewer.jpg
VB6-Project:
http://vbRichClient.com/Downloads/OxygenIconViewer.zip
DownloadPage for the recent RC5-libs (currently at 5.0.27):
http://vbRichClient.com/#/en/Downloads.htm
DownloadPage for the needed vbWidgets.dll:
https://github.com/vbRichClient/vbWidgets
("Download ZIP"-Button as on the GitHub-page for the Oxygen-Icons)
Usage:
Put the RC5-libs into a Folder on your Dev-Machine - e.g. C:\RC5\
Register (only) vbRichClient5.dll there...
Put the compiled vbWidgets.dll (out of the GitHub-zip) into the same
Folder (beside vbRichClient5.dll) and register that Dll too.
Then unzip the OxygenIconViewer.zip Demo-Project into a Folder.
And (before you start the *.vbp) - place the \icons\ folder
which is contained in the GitHub-Oxygen-Zip in the same Folderr
as the *.vbp-File (as a "Project-SubFolder", so to say).
Then start the *.vbp and parse through the Icons.
That much in case you (or others) are interested to at least use the
RC5 on your Dev-Machines "as a tool for your own usage" (e.g. to
create Icons or PNGs from those SVGs in any size).
Olaf
Eduardo
May 2, 2015, 7:44:55 AM5/2/15
to
"Schmidt" <n...@vbRichClient.com> escribió en el mensaje
> Am 01.05.2015 um 22:36 schrieb Eduardo:
Hello Olaf:
> No, what you get with the RC5 is a kind of "vbRuntime-Classes 6.5",
> which already does *not* require you to depend on:
> - MS-ADO/JET (SQLite serves as well in the typical Desktop-DB-scenarios)
> - MS-GDI+ (nice graphics-support per cairo instead)
> - MS-XML COMponents (the RC5-Classes are stable and faster)
> - MS-FSO (cFSO can be used instead for Unicode-capable FileHandling)
> - MS-Winsock (not needed due to API-based Socket-Classes)
> - MS-CommonControls (one can make use of vbWidgets.dll instead)
one), some statusbars, some progressbars, imagelists and the UpDown from
Common Controls 2.
Nothing that can't be replaced (with some work, of course).
> That's a really weak argument, starting with the term "good will"...
> I'm a longterm VB-Community-Member who bundled a few Man-Years of
> work in an free usable package, to close some gaps for the community,
> and make what you build on it (somewhat) less dependent on MS...
> IF that's not good-will "right there", then I don't know...
Miss World, and decide to go around the world sailing. Who knows.
> In case this is still your project, which involves the "fast word-
> scans and stuff" (IIRC), and the performance could still be better
> than what you have currently with DAO/JET, why not simply pick
> an isolated test-case which performs not as it should, and try
> to re-implement only that smaller part with the SQLite-classes.
modifications, thank you for that.
BTW: I handle searches with an inverted index now.
The program searches by lemma, and it has a ranking routine to decide what
document to place higher based on several factors.
In the results I show a small extract from the documents with the most
relevant part highlighted, related to the search query.
It supports double quotes for what the user want to be exactly. The AND
operator is implicit, it doesn't search with OR.
It's something similar to what the web search engines do (of course they are
a lot more optimized because they have to handle far more information and
documents, the indexes are a lot bigger, they also need to take into account
many other factors, and to avoid spamming, all things that I don't need to
handle).
Even complex searches are fast (in fact they tend to be faster, because it's
first filtered by the less frequent word).
The only queries that can take some seconds are the ones of phrases with
several words that are all common words. I implemented a cache, if a search
takes more than one second, the result is stored in a cache table, so the
next time it reads it from there.
It still doesn't search by synonymous, but that could be also implemented.
> This engine is really fast and worth a try (converting a JET-*.mdb
> is only a matter of using the cConverter-Class of the RC5, with
> a few lines of code).
cracking.
But I took several measures to protect the databases. It doesn't mean that
no one could crack them, but it won't be so easy (I hope).
>> About svg icons: it seems that the use of svg icons is still very limited
>> today, almost all the icons sites offer them in png format, not vector
>> based.
>
> It is not as limited as you might think.
> Nearly in all OpenSource-Desktop-Projects (KDE or GNome) there's a whole
Well, but if at last one is going to use the png files, why do I need
rendering support for svg files at all then?
I'm not writing an icon editor. I just want the icons to adapt to different
DPI settings.
And I don't like too much that approach of downscaling the icons from larger
sizes, because unless the designer had that under consideration when he/she
designed the icons, downscaling to 16x16 will lose a lot of details and the
icon won't look good.
If you take a close look at the icons sets, you'll see that many times the
16x16 version of the icons are slightly different from the others.
Olaf: I don't say I'll never migrate to your RichClient, but not now. Now I
have the first version of this program almost finished, all is working,
although some things need an adjustment, but not to change everything. Not
now. I don't have the time. I need to deliver this version.
Schmidt
May 2, 2015, 9:57:01 PM5/2/15
to
Am 02.05.2015 um 13:44 schrieb Eduardo:
> ... you could meet a Miss World,
unlikely. ;-)
And as I already wrote - the code for the lib is spread among
community-members I trust, for exactly that "unlikely event" -
besides, the release-date of the binary is still (much) younger than
what you currently use in dependencies into MS-stuff (which apparently
*do* still work, whilst being left alone for quite an amount of years
without maintenance by the vendor.
> Well, but if at last one is going to use the png files, why do I need
> rendering support for svg files at all then?
Because development doesn't start with "coding in your IDE".
It includes "preparing your resources" as well.
As a developer, SVG is a good "base-format" to have for Image- and
Icon-Resources (to be able to prepare nice looking Pixel-resources
in appropriate sizes - if you have a nice looking PNG-Icon - but only
in a max-size of - say - 48Pixels, then this might not be enough for
higher Resolution-Screens, which become more and more common).
And I already mentioned the "editability" of SVGs (applying different
colors in some shapes - or combining a "Folder-Icon" with a smaller
"action-symbol" which was not included in the original set.
> I'm not writing an icon editor. I just want the icons to adapt to
> different DPI settings.
If you can find "PNGs in a high enough resolution" (e.g. 64x64 seems
enough for most smaller Icon-Resources which are (at "standard 96DPI-
Screens") typically rendered in sizes between 16 to 24 Pixels these
days). On a Screen, switched to 200% (192DPI), these Icons would
need to be rendered in 32-48 already - and thus with a 64x64 Base-Icon
you'd have a small reserve for the next step to 300%, should that
become more common over the next decade.
As said, with an SVG instead of a 64x64 PNG you'd be a bit more
future-proof, but for smaller Icons as used in Menus and Toolbars
64x64 seems a "safe-PixelSize to draw from" for the next years.
> And I don't like too much that approach of downscaling the icons
> from larger sizes, because unless the designer had that under
> consideration when he/she designed the icons, downscaling to
> 16x16 will lose a lot of details and the icon won't look good.
I was talking about Downscaling from a larger PNG vs. direct
rendering of SVG into the target-size (looking near indentically,
when the Pixel-Downscale-Algo is a decent one).
E.g. when you look at these Images here:
(each Row was rendered in 64, 48, 32, 24, 18, 16 sizes)
http://vbRichClient.com/Downloads/SvgAndPngDownscaling.png
http://vbRichClient.com/Downloads/SvgAndPngDownscaling2.png
One of the Rows was rendered all from the same 64x64-PNG per
Downscaling...the other Row was produced by the SVG-Parser,
each icon rendered directly into its specific destination-size.
I'm quite sure you will have a hard time, to tell me which Row
was rendered from the 64x64 (downscaled) PNG, and which was
produced by the direct SVG-rendering.
> If you take a close look at the icons sets, you'll see that many times the
> 16x16 version of the icons are slightly different from the others.
Yes, of course, that's why there's also in case of SVG-Icons (despite
being resolution-independent) usually a Folder for the same Set of
Icons, but with reduced details (which then look nice in target-
renderings of 16-24 Pixels - e.g. when you look in the above
ScreenShots at the Plus-Sign in the green little Button... this one
looks "only by chance" still good in 16x16 resolution - in a Base-SVG
for smaller render-sizes, the Plus-Sign would have been made larger,
or completely avoided - using some other "symbolism").
> Olaf: I don't say I'll never migrate to your RichClient, but not now.
Eduardo, Im not saying you should migrate your Application now...
I just had problems with your arguments.
I was going into details because you mentioned that using the RichClient
would mean "a higher risk" (due to increased dependencies), whilst
the opposite is the case, when you start the trade-off with the MS-ones.
Didn't want to leave that stand uncontradicted in a public forum.
You are quite dependent on MS-stuff (DAO/JET and CommonControls) -
and replacing all that *would* take a lot of work in case you want to
develop such replacements yourself. If you have the time - then Ok -
if you don't have it, then "either leave it as is", or try to find
other libs which are "the lesser evil" (I'm just trying to take your
point of view on that topic here... ;-)
> Now I have the first version of this program almost finished, all is working,
Further above you wrote about the "lot's of problems" you still have...
Olaf
> ... you could meet a Miss World,
> and decide to go around the world sailing. Who knows.
I wish I would - but experience tells, that this is increasingly
unlikely. ;-)
And as I already wrote - the code for the lib is spread among
community-members I trust, for exactly that "unlikely event" -
besides, the release-date of the binary is still (much) younger than
what you currently use in dependencies into MS-stuff (which apparently
*do* still work, whilst being left alone for quite an amount of years
without maintenance by the vendor.
> Well, but if at last one is going to use the png files, why do I need
> rendering support for svg files at all then?
It includes "preparing your resources" as well.
As a developer, SVG is a good "base-format" to have for Image- and
Icon-Resources (to be able to prepare nice looking Pixel-resources
in appropriate sizes - if you have a nice looking PNG-Icon - but only
in a max-size of - say - 48Pixels, then this might not be enough for
higher Resolution-Screens, which become more and more common).
And I already mentioned the "editability" of SVGs (applying different
colors in some shapes - or combining a "Folder-Icon" with a smaller
"action-symbol" which was not included in the original set.
> I'm not writing an icon editor. I just want the icons to adapt to
> different DPI settings.
enough for most smaller Icon-Resources which are (at "standard 96DPI-
Screens") typically rendered in sizes between 16 to 24 Pixels these
days). On a Screen, switched to 200% (192DPI), these Icons would
need to be rendered in 32-48 already - and thus with a 64x64 Base-Icon
you'd have a small reserve for the next step to 300%, should that
become more common over the next decade.
As said, with an SVG instead of a 64x64 PNG you'd be a bit more
future-proof, but for smaller Icons as used in Menus and Toolbars
64x64 seems a "safe-PixelSize to draw from" for the next years.
> And I don't like too much that approach of downscaling the icons
> from larger sizes, because unless the designer had that under
> consideration when he/she designed the icons, downscaling to
> 16x16 will lose a lot of details and the icon won't look good.
rendering of SVG into the target-size (looking near indentically,
when the Pixel-Downscale-Algo is a decent one).
E.g. when you look at these Images here:
(each Row was rendered in 64, 48, 32, 24, 18, 16 sizes)
http://vbRichClient.com/Downloads/SvgAndPngDownscaling.png
http://vbRichClient.com/Downloads/SvgAndPngDownscaling2.png
One of the Rows was rendered all from the same 64x64-PNG per
Downscaling...the other Row was produced by the SVG-Parser,
each icon rendered directly into its specific destination-size.
I'm quite sure you will have a hard time, to tell me which Row
was rendered from the 64x64 (downscaled) PNG, and which was
produced by the direct SVG-rendering.
> If you take a close look at the icons sets, you'll see that many times the
> 16x16 version of the icons are slightly different from the others.
being resolution-independent) usually a Folder for the same Set of
Icons, but with reduced details (which then look nice in target-
renderings of 16-24 Pixels - e.g. when you look in the above
ScreenShots at the Plus-Sign in the green little Button... this one
looks "only by chance" still good in 16x16 resolution - in a Base-SVG
for smaller render-sizes, the Plus-Sign would have been made larger,
or completely avoided - using some other "symbolism").
> Olaf: I don't say I'll never migrate to your RichClient, but not now.
I just had problems with your arguments.
I was going into details because you mentioned that using the RichClient
would mean "a higher risk" (due to increased dependencies), whilst
the opposite is the case, when you start the trade-off with the MS-ones.
Didn't want to leave that stand uncontradicted in a public forum.
You are quite dependent on MS-stuff (DAO/JET and CommonControls) -
and replacing all that *would* take a lot of work in case you want to
develop such replacements yourself. If you have the time - then Ok -
if you don't have it, then "either leave it as is", or try to find
other libs which are "the lesser evil" (I'm just trying to take your
point of view on that topic here... ;-)
> Now I have the first version of this program almost finished, all is working,
Olaf
Eduardo
May 2, 2015, 11:04:54 PM5/2/15
to
"Schmidt" <n...@vbRichClient.com> escribió en el mensaje
> Eduardo, Im not saying you should migrate your Application now...
> I just had problems with your arguments.
>
> I was going into details because you mentioned that using the RichClient
> would mean "a higher risk" (due to increased dependencies), whilst
> the opposite is the case, when you start the trade-off with the MS-ones.
> Didn't want to leave that stand uncontradicted in a public forum.
żhow many will I have then?
4 is more risky than 3.
I don't decrease the dependency adding support to svg files, that BTW now I
see that I don't need.
> You are quite dependent on MS-stuff (DAO/JET and CommonControls)
replace.
I have dependency on MSHFlexgrid and RichTextBox, and of course, on DAO.
CommonDialog is already replaced with a direct replacement that actually
works, and enhanced. But I have the code, that's why I could add features
and enhance it.
All my replacements are with things that I can manage, that I can modify. I
didn't add black boxes.
No black boxes any more, MS taught me that lesson.
> and replacing all that *would* take a lot of work in case you want to
> develop such replacements yourself. If you have the time - then Ok -
> if you don't have it, then "either leave it as is", or try to find
> other libs which are "the lesser evil" (I'm just trying to take your
> point of view on that topic here... ;-)
>> Now I have the first version of this program almost finished, all is
>> working,
>
> Further above you wrote about the "lot's of problems" you still have...
of problems.
I didn't mean that I have a lot of unsolved problems now, but that "I have a
lot (of problems)" in general while programming.
You have to know what I mean, you are also a programmer for Windows in 2015.
Schmidt
May 2, 2015, 11:53:19 PM5/2/15
to
Am 03.05.2015 um 05:04 schrieb Eduardo:
> My argument stands. If now I have three dependencies,
> and I add a new one - how many will I have then?
> My argument stands. If now I have three dependencies,
> 4 is more risky than 3.
That's really "playing dumb" what you do now.
>> Further above you wrote about the "lot's of problems" you still have...
>
> There are a lot of problems simply because making software today
> has a lot of problems.
> I didn't mean that I have a lot of unsolved problems now, but that
> "I have a lot (of problems)" in general while programming.
> You have to know what I mean, you are also a programmer for Windows in 2015.
Olaf
Eduardo
May 3, 2015, 12:51:46 PM5/3/15
to
"Schmidt" <n...@vbRichClient.com> escribió en el mensaje
> dumb
Think whatever you want.
I can't explain everything. You wouldn't understand my reasons.
0 new messages