|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Aug 17, 2013 6:16 pm Post subject: |
|
|
Paul,
Regarding the rounded corners, when I did the mock-up on page 1 of this topic, I copied the colours from a screen grab. With 3d_thin, the background was 3*240, the line was 3*160, and there was a white highlight.
I see what you have done, using 3*240 to soften the curve (looking at the top left and bottom right corners as generated by your last beta). Is it really necessary to be that sophisticated? I had a little go with another mock up for top right and bottom left just using the dark grey and white and it looks OK - your curved corners are a little bigger radius than my original attempt, and I tried to match yours.
Incidentally, your rounded corners are as complex as the corners on a dialog box, mine were less complex than that, but more than a button (in Win 7). From left to right: Yours, mine, and a button corner
Code: | XXXXX XXXXX XXXXX
XX XX X
X X X
X X X
X X X
X X X
X X
X |
I guessed that it wouldn't be easy, but arranging the shading is easier the simpler the curve is.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sun Aug 18, 2013 7:38 am Post subject: |
|
|
Eddie
Many thanks for your input and help on this topic.
I am reasonably satisfied with the outcome so (apart from any remaining simple bug fixes) I am happy to leave things as they are.
Paul |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Aug 18, 2013 10:41 am Post subject: |
|
|
Hi Paul,
My attempt to show corners with pixels as "X marks the spot" in a CODE section looks fine on a PC, but rubbish on my Blackberry - I hope that you got the drift, and of course, there is always a point where future tinkering brings no further benefit.
My opening gambit to this thread was a whole list of ideas, and you did suggest highlighting one at a time. I don't even know what my own priorities are, so attempting not to be selfish, my guess that the next one that is worth looking at, and perhaps won't prove so difficult, is one that didn't even make it to my original list, and that is to revisit %ib and improve the conversion to greyscale of the "greyed-out" icon variant.
To recap, an %ib button bitmap can be anything in terms of size and colours. If it has a complete border round all 4 sides of colour RGB@(R,G,B) then that is taken as background, otherwise a mid-grey RGB@(192,192,192) is taken as background. When converting to a greyed-out or inactive toolbar button, any colour pixel that isn't background is converted to dark grey. This does tend to make greyed-out buttons look like rather shapeless blobs. We did have a thread on this some years back, and it is possible to restore some semblance of the original icon (in the greyed-out state) by judicious use of background colour pixels within the design, and the optical illusion of a 3rd grey shade is achievable with a chess-board pattern of background colour and something else.
When you recently reworked the %bb button, you introduced a rather better algorithm for defining the greyed-out appearance, and (excepting some of my icons that had shadows!) they appear much, much, better than the %ib greyed-out blobs. Just a guess, but was the grey blob the best that could be done on a display without much colour depth?
Given that you already developed that better algorithm, and 24-bit colour is more or less universal, is it perhaps sensible to at least consider applying it to the %ib greyed-out state?
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sun Aug 18, 2013 2:43 pm Post subject: |
|
|
Eddie
My immediate priority is to add a new feature to Plato. So can we come back to this ClearWin+ development in a little while (maybe a month or so).
I wrote most of the %ib code and in particular the multiple images part so I am a little apprehensive about the scope for improvement because I know how much work went into the original.
Having said this, there may be a simple solution (or alternative) along the lines you suggest or maybe just to allow the programmer to provide their own greyed image. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Aug 18, 2013 3:52 pm Post subject: |
|
|
Hi Paul,
Getting a balance in the way the different parts of the FTN95/ Plato/ Clearwin+ system move forwards is probably the optimum solution. I am content to wait for however long it takes - just that my list usually gets longer with time (although it gets shorter too when someone posts a solution in the forum!).
Eddie |
|
Back to top |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Mon Aug 19, 2013 8:37 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: | my guess that the next one that is worth looking at, and perhaps won't prove so difficult, is one that didn't even make it to my original list, and that is to revisit %ib and improve the conversion to greyscale of the "greyed-out" icon variant.
|
Basic RGB-color conversion to greyscale is quite simple, below is a slow example in MINIBasic syntax:
Code: |
func greyscaleBitmap(CBitmap bmp)
int i,j
POINT size
size = bmp.GetSize()
bmp.BeginDrawing()
for i = 0 to size.y - 1
for j = 0 to size.x - 1
uint c = bmp.GetPixel(j,i)
char r = c&0x0000ff
char g = (c&0x00ff00)>>8
char b = (c&0xff0000)>>16
char gray = (30 * r + 11 * g + 59 * b)/100
bmp.SetPixel(j,i,rgb(gray,gray,gray))
next j
next i
bmp.EndDrawing()
endf
|
For 8-bit bitmaps, you could just modify the color table even without modifying the bitmap itself.
However, just converting the bitmap to greyscale won't work well as "greyed-out" state indicator. Probably the best would be to use alpha blending: first draw the background rectangle and then the translucent button image on top of it. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Aug 19, 2013 10:33 pm Post subject: |
|
|
Hi Jalih,
You are running - we arenot even walking! If you take the two following "Open" bitmaps for use with %ib:
and
Code: | WINAPP
OPTIONS (INTL, DREAL)
PROGRAM IMAGEBAR
INCLUDE <WINDOWS.INS>
INTEGER, EXTERNAL :: OPEN_FUNCTION
CHARACTER*(8) INSERT(3), INS
N_IMAGEBAR_TYPE = 1 ! try all 3 modes by changing this
INSERT(1) = ''
INSERT(2) = 'coloured'
INSERT(3) = 'flat'
INS = INSERT(N_IMAGEBAR_TYPE)
IA=WINIO@('%ca[Old Greyed Imagebar Test]&')
IA=WINIO@('%th[delay,ms_style] &', 1, 300)
IMBAR1 = 1; IMBAR2 = 3
IA=WINIO@('%?4.1ib['//INS//'][ Open1 ][ Open2 ]'//
& '[ Open1 Grey ][ Open2 Grey ]',
& 'OPEN1', IMBAR1, Open_FUNCTION,
& 'OPEN2', IMBAR1, Open_FUNCTION,
& 'OPEN1', IMBAR2, Open_FUNCTION,
& 'OPEN2', IMBAR2, Open_FUNCTION)
END
INTEGER FUNCTION OPEN_FUNCTION()
OPEN_FUNCTION = 1
RETURN; END
RESOURCES
OPEN1 BITMAP "OPEN_BASIC.BMP"
OPEN2 BITMAP "OPEN_VARIANT.BMP" |
Save them as BMP to match the resource names above. With the demo you can try the 3 variants of %ib by making N_IMAGEBAR_TYPE 1, 2 or 3, and also see what both greyed out variants look like. Sorry this isn't sophisticated.
The point is that unless you work very hard on the base image, the greyed out version is a blob! Mapping 24-bit RGB to greyscale can be done with multiple algorithms, and I expect (from your other posts) that you are more knowledgeable than I am about these. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Aug 19, 2013 11:06 pm Post subject: |
|
|
I know that when he looks at this, Paul will appreciate your code suggestions.
When I have looked at it, I can see multiple ways to map the RGB colour to greyscale, but it does look to me that what would work best depends on what the background colour is, and it will need a lot of experimentation to get it right.
I much prefer %tb because it gives me fuller control over what the different states look like, but it is a lot less effort to draw just one bitmap and let Paul's code do the work!
(Sorry to split the reply, but I hate it when the Forum truncates my post).
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Aug 20, 2013 7:58 am Post subject: |
|
|
Jalih: Many thanks for the suggestion. This looks similar (if not identical) to the code used for %bb.
Eddie: When I get to it, initially I may just offer the option of a second image provided by the programmer. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Aug 20, 2013 10:43 am Post subject: |
|
|
It occurred to me, late last night, after my 2 posts, that the [flat] mode already contains the "map to more than 2 colours greyscale". In this [flat] mode, the affordance (i.e. hint that the button is enabled, and might do something if pressed) comes from it acquiring colour when the mouse pointer passes over it. A greyed-out image without the affordance could - in principle - look no different to this base case.
It therefore occurs to me that the solution which creates least work for you, Paul, together with least chance of upsetting existing code and least extra work for the user, is to create an optional alternative greyed-out button appearance selected with a different stat_ctrl value - perhaps 5 instead of 3 - that is derived from the original bitmap exactly as per the preparation of the base-case [flat] button. There are, after all, almost unlimited unused stat_ctrl numbers that could be considered "reserved for future use"!
This may prove easier than my original suggestion of using the %bb button code in a rather different context. (And %bb uses an ICO, whereas %ib uses a BMP, so code is not immediately reusable).
My apologies for continuing with this thread when you already said that you needed to work on something else.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Aug 20, 2013 11:16 am Post subject: |
|
|
Many thanks. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Mar 29, 2016 2:27 pm Post subject: |
|
|
I hope that this thread does not get forgotten, especially as some elements of the wish list have been provided e.g. in respect of rounded corners to %ob and dealing with %il limits.
I recognise that 64 bit FTN95 and solving bugs has higher priority.
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Mar 29, 2016 5:11 pm Post subject: |
|
|
Thanks for the reminder but the port to 64 bits is all consuming at the moment. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Mar 29, 2016 7:00 pm Post subject: |
|
|
Agreed, because 64 bit is the future. Even netbooks are being supplied with Windows 10 64 bit OS now, and the discontinuance of the 32-bit OS will be upon us before we know it.
While not asking for any action at this juncture, I am hoping that other contributors will add to the wish list. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu May 26, 2016 12:04 pm Post subject: |
|
|
At some point there was a request for a double precision equivalent to the standard SET callback. SETF will be available in the next release as illustrated here...
Code: | WINAPP
INTEGER w,winio@
DOUBLE PRECISION v,x
v=0.999
x=1.001
w=winio@('%`cn%^bt[Call SETF]&','SETF',v,x)
w=winio@('%2nl%8rf',v)
END
|
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|