work resumes

[John Asmuth]

Just a brief note that I'm resuming work on go.uik, as promised.

[Anthony Starks]

Good to hear, John. any new thoughts on the design or direction.

[André Paquet]

On Thursday, March 7, 2013 3:36:26 PM UTC-5, John Asmuth wrote:

Just a brief note that I'm resuming work on go.uik, as promised.

That's great news. So, when will we have a datagrid with complex databinding to play with? 

Kidding. I wish I had more time and knowledge in this area of expertise, I could see myself investing time in this.

André

[John Asmuth]

Yes, actually. I'd like to (collectively) come up with a good way to remove the concept of a bitmap or a pixel from go.uik code.

I'll float some ideas, just to start the conversation.

1) Definitely never have the concept of a pixel in developer code. At the moment, since go.uik uses go.wde for drawing, everything is eventually put into a pixel raster, but that raster needs to be effectively quarantined.

2) There needs to be some effective way for a developer to know how big the window is, according to the user's perception. Perhaps use cm as a measurement? That seems difficult.

3) Speaking of an underlying raster, perhaps moving to opengl would be better? Any ideas there?

[Job van der Zwan]

For the record: I haven't used go-uik, so maybe I've overlooked part of the documentation, or repeat something that has already been discussed.

On Friday, 8 March 2013 21:31:18 UTC+1, John Asmuth wrote:

1) Definitely never have the concept of a pixel in developer code. At the moment, since go.uik uses go.wde for drawing, everything is eventually put into a pixel raster, but that raster needs to be effectively quarantined.

3) Speaking of an underlying raster, perhaps moving to opengl would be better? Any ideas there?

These two seem related. I'm wondering if you have an interface for renderers - then you could have any rendering backend, as long as it fits in the interface. Software based, OpenGL based, someone could even create a websocket/Canvas/javascript option.

Kinda like in Processing, which initiates its canvas size with a size(w, h, renderer) function call:

http://processing.org/reference/size_.html

... which resulted in a third party library with a better OpenGL renderer (which is now being incorporated into the main version).

Plotinum also does something like this:

http://godoc.org/code.google.com/p/plotinum/vg

Again, I haven't used go-uik, but a quick scan through the documentation gives the impression go-uik doesn't work like that at the moment.

2) There needs to be some effective way for a developer to know how big the window is, according to the user's perception. Perhaps use cm as a measurement? That seems difficult.

 

 For historical reasons, pixel resolution always seem to be measured in pixels per inch (just like printing/scanning is dots per inch). Not very scientific, but maybe easier for compatibility reasons?

[Anthony Starks]

When working with things like OpenVG and SVG, I don't think in pixels, I think of objects placed at coordinates.

 

How you think about coordinates does have implications -- for example float vs. int, or y increasing up or down.

Also, in many cases you wind up mapping your "world" to the underlying coordinate system anyway.

[Ethan Burns]

On Friday, March 8, 2013 9:21:48 PM UTC-5, Job van der Zwan wrote:

Plotinum also does something like this:

http://godoc.org/code.google.com/p/plotinum/vg

By the way, I plan to make an OpenGL back-end for vg at some point (https://code.google.com/p/plotinum/issues/detail?id=110).  If go.uik used vg for its drawing then it could, presumably, support both software rendering (via draw2d) and hardware rendering (via OpenGL).

Ethan

[John Asmuth]

Currently I try to make use of draw2d wherever possible. If we made a nice way to swap in opengl seemlessly, that'd be awesome.

So, what people are saying is good, but it's not quite the issue I was thinking about.

I was thinking along the lines of, for instance, a developer might want to make text big enough so that it is comfortably readable.

Perhaps this could be addressed with giving the dev a coordinate system where a difference of 1 means a difference 1cm, approximately (I prefer cm to inches, despite being an American). Is it easy to reliably do this? Can I query the number of pixels per distance unit, and do the arithmetic when handing coordinates to the developer?

--
You received this message because you are subscribed to the Google Groups "go-uik" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-uik+un...@googlegroups.com.
To post to this group, send email to go-...@googlegroups.com.
Visit this group at http://groups.google.com/group/go-uik?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Job van der Zwan]

Maybe it's worth looking at a failed attempt? And when I say that, I mean browsers and zooming. You can designate pt, em and pixels, IIRC. Which results in not being able to align perfectly per pixel (which is often important), or getting a fixed size that can't scale. Let alone mixing and matching them.

[Daniel Skinner]

I'm by no means going to have a great idea here, but if we're going to look at other examples, android provides the dp unit for density independence. This is based on a sort-of fixed sized target width and height for mobile (fuzzy business) which circles back to the question John is asking, getting that display data in a meaningful way to expose some sort of density independence unit to the programmer. I think this circles back even further to previous comment:

1) Definitely never have the concept of a pixel in developer code. At the moment, since go.uik uses go.wde for drawing, everything is eventually put into a pixel raster, but that raster needs to be effectively quarantined.

3) Speaking of an underlying raster, perhaps moving to opengl would be better? Any ideas there?

> These two seem related

Because, well, they are. Except in this case, the programmer gets to choose an arbitrary way of defining the "unit" that's comfortable for him, and then essentially sets the projection so that it's displayed as desired.

So then by that measure, I'd be more interested in how a component within the application is projected (or autoresolved to project) to achieve density independence, bitmaps be damned.

Although, likely, I have no clue what I'm talking about :)

[Job van der Zwan]

I've been thinking about why I consider the way browsers do it to be "wrong", even though they get dynamically resizable content right in many ways. I think Anthony alluded to the core of the problem:

On Saturday, 9 March 2013 15:47:21 UTC+1, Anthony Starks wrote:

How you think about coordinates does have implications -- for example float vs. int, or y increasing up or down.

Also, in many cases you wind up mapping your "world" to the underlying coordinate system anyway.

The problem with browsers is that coordinate systems are always relative to something else. Yes, we're going full Einstein here. And browsers offer so many options as to what an element can be relative to that doing the layout of a website is quite a messy business:

- pt and em are relative to the document flow

- pixels are relative to the screen pixels

- percentages are relative to a normalised screen width

And this is of course ignoring weird browser quirks. The result is contradictory priorities as to where elements are placed at various zoom levels, and different behaviour across browsers.

I think that answering the questions of units relative to what and how to map those units would help us a long way of solving the problem we're discussing here.

[Job van der Zwan]

So what I'm really saying is that we should go for polar coordinates using complex notation. :P

[Gerard]

John, I am an engineer and have created lots of technical drawings. In Europe we always use mm and say that cm are used by construction workers ;-)

Besides that, SI = meters.

The abstraction to cm or mm looks good. I like the idea of having ONE unit. And thanks to interfaces the scaling can be dealt with in the background.

However, except for paper you don't know the actual size of the output media (AFAIK). It might be a handheld device or a 10-foot user interface. 

So, what is a mm then?

Gerard

Op zaterdag 9 maart 2013 17:05:40 UTC+1 schreef John Asmuth het volgende:

[John Asmuth]

On Sunday, March 10, 2013 10:43:03 AM UTC-4, Gerard wrote:

However, except for paper you don't know the actual size of the output media (AFAIK). It might be a handheld device or a 10-foot user interface. 

Right, I don't have a good solution for this problem. For something like that, percentages might be nice. But for smaller things, like phones, you might want to know the minimum readable size for text. 

 

[Anthony Starks]

Looking at prior art on dimensions, I cite my 1986 version of Knuth's the TeXbook, pg 58:

TeX represents all dimensions internally as an integer multiple of tiny units called sp. Since the wavelength of visible light is approximately 100 sp, rounding errors of a few sp make no difference to the eye. However, TeX does all its arithmetic very carefully so that identical results will be obtained on different computers.

TeX uses the sp as the basis for conversion to conventional units: (pg. 57)

pt point
pc pica (1pc = 12pt)
in inch (1in = 72.27 pt)
bp big point (72 bp = 1in)
cm centimeter (2.54 cm = 1in)
mm millimeter (10 mm = 1cm)
dd didot point (1157 dd = 1238 pt)
cc cicero (1 cc = 12 dd)
sp scaled point (65536 sp = 1pt)

[Gerard]

What I am about to say now is probably noise... 

At the office we work with 3D solid modeller software. The model on the screen can have a length of 1 mm or 50m. You simply don't know the size. To put things in perspective we usually place a 3d manequin in the assembly. Then you know the size of the model regardless the zoom.

So if you want to work with cm (units), it might be an idea to use a reference object, such as a ruler.

Op zondag 10 maart 2013 15:47:35 UTC+1 schreef John Asmuth het volgende:

[John Asmuth]

Sort of riffing off both what you said and what Anthony said...

The think I'm really trying to engineer is making it easy for developers to have GUIs whose components are easy to visually parse and to use.

I think a good way to do this is to introduce a unit, let's call it the m and have it be approximately the same as the width of the letter m. All coordinates, sizes etc reported to the GUI code will be in terms of this m. The number of pixels per m can be set somehow - perhaps a system-level config, or also a function in the uik package. If someone wants the text to get bigger, they can increase the value of m. If someone is on a phone with a retina display (e gads what a time we live in), the value of m should probably be pretty big to make sure that buttons are easy to click and text is easy to read.

That way, the process to zoom in and make sure everything is good is the same as the process to resize the window - it's all the same to the GUI code.

Thoughts?

[Zellyn Hunter]

I see no reason not to introduce a range of size constants the way the built-in libraries do with time (second, hour, etc.)  It doesn't really matter what it's defined in terms of underneath: m's are fine. :-)

Zellyn

--

[Ingo Oeser]

Per display resolution setting might be useful. Systems have often more than one display.

[John Asmuth]

Per-display works easily on top of the m concept, I believe. On the lowest level, it would be per-window, but uik could keep a display-to-value mapping, and notice when a window moves to a different display.

On Tue, Mar 12, 2013 at 4:27 AM, Ingo Oeser <night...@googlemail.com> wrote:

Per display resolution setting might be useful. Systems have often more than one display.

[Job van der Zwan]

On Tuesday, 12 March 2013 02:34:50 UTC+1, John Asmuth wrote:

Sort of riffing off both what you said and what Anthony said...

The think I'm really trying to engineer is making it easy for developers to have GUIs whose components are easy to visually parse and to use.

I think a good way to do this is to introduce a unit, let's call it the m and have it be approximately the same as the width of the letter m.

I assume this is no coincedence?

http://en.wikipedia.org/wiki/Em_(typography)

For the sake of discussion, I'll say we've defined an Em type to represent this unit.

 

That way, the process to zoom in and make sure everything is good is the same as the process to resize the window - it's all the same to the GUI code.

So let's say I make a drawing program, with a canvas and with buttons for different brushes. If resize the window, should the canvas increase/decrease in size? Should the buttons? Where should the buttons be put? Will they just overflow the window?

I think using Em to make the buttons' sizes relative to whatever the user designates as a readable m is a great idea to keep them cross-platform readable. But there's still the question of location: how many Em's relative to what? In the case of the buttons, it's relative to the border. And the amount of Em's is fixed, as the size of the buttons is a fixed size of Em. But it gets more complicated.

What if I have a program with a two-pane setup and I want the split to be exactly in the middle? Can I express that directly in Em's? Well, no, as that depends on window size. I need to express that in a precentage.

Maybe it's sensible to use Em as the input unit for both size and coordinates, and provide mapping functions that makes it easy to translate both different metrics and different relative-to's to and from this Em unit. So something like:

func XinWindow(percentage float) Em {

  //Uses knowledge of internal global variables to translate the percentage of a window to the amount of Em's required

}

func XinScreen(percentage float) Em {

  //Uses knowledge of internal global variables to translate the percentage of the entire screen to the amount of Em's required

  //There's the odd use-case where you want that with windowed applications.

}

[David Roundy]

I'll just point out that in many cases when a developer wants a fixed percentage of a window, they aren't considering what their users may encounter.  e.g. perhaps users with a large screen will want one pane to be larger than the other.

David

[John Asmuth]

The Em connection is no coincidence, but it's not entirely the same concept. I'm going to stick with m.

Since a GUI is necessarily an interaction between the computer and the user, I think it's good to define m in those terms. I think that a good definition might be:

The quantity m is the minimum length such that an m by m square is convenient and easy to interact with.

This implies that

- a button may not be less than m on a side, 

- a scroll bar should really not be narrower than m*,

and really,

- nothing that has to be clicked (with a mouse) or touched (with a fingertip) should require any kind of mental energy.

That is, you shouldn't have to slowly move the mouse around until you get that magic pixel that lets you resize a window, and you shouldn't have to try multiple times to tap the button you want.

People's opinions may differ, but I would guess than an m on a typical screen, where the user's face is a few ergonomically chosen feet away, is about 1cm.

Now, you may say something like "the GUI interaction is two-way, and the quantum wavelengths for information in vs information out may be different!". I tend to agree. However, having more than one wavelength (that's what I just decided I'm going to call m and similar concepts) makes for a confusing API. I think it makes sense to define the minimum type size as that which fits comfortably inside an area with height m without looking stupid. Perhaps better words can be chosen, but that's the gist.

- John

*I know that in most apps a scroll bar can be much narrower than the button lower bound, but I really think that's bad, to be honest. Scroll bars are inconvenient to grab. I think that it only became this way because, in the beginning (maybe), scrollbars were on the very edge of the screen, and you could throw the mouse over there to pick them up, sort of like apple menu bars. Regarding apple menu bars, that's *definitely* why they're on the top of the screen rather than the top of the window - because you can toss the mouse up there without having to precision guide the cursor.

[Job van der Zwan]

On Wednesday, 13 March 2013 03:03:47 UTC+1, John Asmuth wrote:

The Em connection is no coincidence, but it's not entirely the same concept. I'm going to stick with m.

FWIW, I meant "Em" in the sense of "an exportable type in a package", not the classical Em unit.  Go requires a capital letter for exportation after all, and "M" felt a bit too generic for that. I can also understand that confusion with the old unit is something to be avoided, so calling the type Em is not a good idea either. How do you plan to do this in the package?
 

The quantity m is the minimum length such that an m by m square is convenient and easy to interact with.

This implies that

- a button may not be less than m on a side, 

- a scroll bar should really not be narrower than m*,

and really,

- nothing that has to be clicked (with a mouse) or touched (with a fingertip) should require any kind of mental energy.

That is, you shouldn't have to slowly move the mouse around until you get that magic pixel that lets you resize a window, and you shouldn't have to try multiple times to tap the button you want.

People's opinions may differ, but I would guess than an m on a typical screen, where the user's face is a few ergonomically chosen feet away, is about 1cm.

Now, you may say something like "the GUI interaction is two-way, and the quantum wavelengths for information in vs information out may be different!". I tend to agree. However, having more than one wavelength (that's what I just decided I'm going to call m and similar concepts) makes for a confusing API. I think it makes sense to define the minimum type size as that which fits comfortably inside an area with height m without looking stupid. Perhaps better words can be chosen, but that's the gist.

Does that mean that all the GUI elements will have to fit on a grid, or does this only apply to size?

[John Asmuth]

On Wed, Mar 13, 2013 at 9:47 AM, Job van der Zwan <j.l.van...@gmail.com> wrote:

FWIW, I meant "Em" in the sense of "an exportable type in a package", not the classical Em unit.  Go requires a capital letter for exportation after all, and "M" felt a bit too generic for that. I can also understand that confusion with the old unit is something to be avoided, so calling the type Em is not a good idea either. How do you plan to do this in the package?

Ah, I see. I don't think exporting Em, or M, is a good idea - fiddling with it is waaaaay not thread-safe. Most likely there will be a WindowFoundation.SetM() method, or something, that will be responsible for this.

 

Does that mean that all the GUI elements will have to fit on a grid, or does this only apply to size?

Just size.

[Job van der Zwan]

On Wednesday, 13 March 2013 14:50:31 UTC+1, John Asmuth wrote:

On Wed, Mar 13, 2013 at 9:47 AM, Job van der Zwan <j.l.van...@gmail.com> wrote:

FWIW, I meant "Em" in the sense of "an exportable type in a package", not the classical Em unit.  Go requires a capital letter for exportation after all, and "M" felt a bit too generic for that. I can also understand that confusion with the old unit is something to be avoided, so calling the type Em is not a good idea either. How do you plan to do this in the package?

Ah, I see. I don't think exporting Em, or M, is a good idea - fiddling with it is waaaaay not thread-safe. Most likely there will be a WindowFoundation.SetM() method, or something, that will be responsible for this.

Oh, agreed, but I didn't think of exporting in terms of "setting what m means". What I though was:

type M int

func SomeWidget(x, y, width, height M)

... instead of putting in random floats/integers. Although I'm not actually sure if that is a good or bad idea - it would make sure that you're always aware that the value you are using is of unit M, but it's a bit of a pain.

[David Roundy]

Hi John,

I think you may want *two* sizes, which will vary independently.  One is the user's preferred visual size (the "Em" of typography), the other, which you could call "FingerSize" or something, would be the preferred clickable size.  They're different concepts, and the ideal ratio between the two relates to the type of pointing device (and steadiness of user hand) in a nontrivial way.  I'm happy with 1-pixel-wide lines on my laptop, but not with having to grab a single pixel-wide line in order to resize my windows.

David

[John Asmuth]

I definitely agree that there are two wavelengths to deal with, call them the eye wavelength and the finger wavelength. And I also agree that, depending on context, their ratios could change. However, I'm having a hard time imagining a simple API for a GUI developer that optimizes these values.

However, I may just need to be more creative.

Any ideas?

[Ethan Burns]

I wonder if it would be better to defer this problem to a higher layer of abstraction.  Instead, focus on a nice and simple API that uses centimeters.  Then the next layer up can deal with laying out widgets and such using screen and finger sizes.

Best,

Ethan

[David Roundy]

What sort of GUI developer are you thinking to create a simple API
for? One who creates new GUI elements, or one who just puts existing
elements together in new combinations? The latter, I suspect, is the
common kind, and the one you want a good API for, right?

I expect that one could create a good API for combining widgets that
never requires any length scale (including pixels). Simply do not
allow the developer to specify the size of anything. Or if they
really want to make a big button, make them specify its size relative
to what the default would be. Similarly with fonts. Then internally,
you just need to size everything (and space everything) appropriately.

David

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "go-uik" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/go-uik/MgFbQFeonvg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to

> go-uik+un...@googlegroups.com.
> To post to this group, send email to go-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/go-uik?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
David Roundy

[Robin Eklind]

+1

I also agree that the concept of eve wavelength and finger wavelength should be on a higher layer of abstraction.

The drawing API should IMO be accurate and never lose and/or distort information. The UI widgets may very well use the eve wavelength and finger wavelength to produce easy to use widgets but it has to be possible to produce pixel perfection with the underlying drawing API.

[Hotei]

FWIW - Instead of the term "eye wavelength" I would suggest a name already in common usage:  MOA

 MOA (minutes of arc) is commonly used to refer to the "apparent" size of an object regardless of the distance to that object.  A cellphone button or 60" LCD screen button that both cover 20 MOA appear the same size to the user.  The same approach could be useful to the "touch" wavelength since if you're touching something the distance is less than 1 m for most people. Since the ability to touch a spot easily is an eye-hand coordination issue the apparent size (MOA again) of the target is critical.

On Thursday, March 7, 2013 3:36:26 PM UTC-5, John Asmuth wrote:

Just a brief note that I'm resuming work on go.uik, as promised.

[David Roundy]

I can see that as being useful, but not as being sufficient as defined.  Different people have different abilities to distinguish small objects, so an arc second for a device doesn't tell us what font is too small, or how thin a line will not be distinguishable.

David

On Wed, Apr 10, 2013 at 8:36 AM, Hotei <hote...@gmail.com> wrote:

FWIW - Instead of the term "eye wavelength" I would suggest a name already in common usage: http://en.wikipedia.org/wiki/Arc_second

ArcSecond or MOA is commonly used to refer to the "apparent" size of an object regardless of the distance to that object.  A cellphone button or 60" LCD screen button that both cover 20 MOA appear the same size to the user.  (Of course the 60" screen has to be further away for them to be equal.)

On Thursday, March 7, 2013 3:36:26 PM UTC-5, John Asmuth wrote:

Just a brief note that I'm resuming work on go.uik, as promised.

--

You received this message because you are subscribed to a topic in the Google Groups "go-uik" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/go-uik/MgFbQFeonvg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to go-uik+un...@googlegroups.com.
To post to this group, send email to go-...@googlegroups.com.
Visit this group at http://groups.google.com/group/go-uik?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
David Roundy

[Hotei]

Yes, people vary in their visual acuity though most are near 20/20 (by definition).  One of the reasons tablets (e-readers) are nice is you can change the font size to be more readable.  My point was a 20 MOA widget looks the same (size) to the user regardless of the device be it an Apple Retina or my LCD screen at 72 dpi.  In fact the wiki page for Retina was an interesting read - and at least somewhat relevant to this discussion.

http://en.wikipedia.org/wiki/Retina_display

[Dobrosław Żybort]

Interesting reading from new ui2go Library:
http://www.projectory.de/ui2go/fontsize.html
http://code.google.com/p/ui2go/source/detail?r=00e82dee6fea732bffd64dc8e1ced04f6da24bfc

Best regards,
Dobrosław Żybort

[Eduard Castany]

3) Speaking of an underlying raster, perhaps moving to opengl would be better? Any ideas there?

This would be awesome! Would be very nice not to rely on glfw

[John Asmuth]

That's funny... glfw was my first choice for an gl-based wde backend...

Is the problem the installation or the interface?

On Thu, Jun 20, 2013 at 11:46 AM, Eduard Castany <eduard....@gmail.com> wrote:

3) Speaking of an underlying raster, perhaps moving to opengl would be better? Any ideas there?

This would be awesome! Would be very nice not to rely on glfw

--

You received this message because you are subscribed to the Google Groups "go-uik" group.

To unsubscribe from this group and stop receiving emails from it, send an email to go-uik+un...@googlegroups.com.

To post to this group, send email to go-...@googlegroups.com.

Visit this group at http://groups.google.com/group/go-uik.

[Tim Shannon]

I personally haven't had any issues with it.  It works great, and it's simple and straight forward.  Some may see it as an added dependency, and it would make wde not necessarily pure go if that's a concern.

[John Asmuth]

It wouldn't be a dependency... it would be an additional backend. You can import the particular backend you want for the system you're on, and then use it in a cross-platform manner.

wde itself is just an interface.

[Eduard Castany]

But you already have events windows and keyboards, witch glfw provides. The only step missing is the opengl window context creation. Function loading can be done with gogl. Am I missing something..? I'm no expert here

[John Asmuth]

go.wde doesn't have events, etc.: it provides a common interface for talking about them. glfw can provide them, and the wde backend would map them to the common types.

On Thu, Jun 20, 2013 at 3:22 PM, Eduard Castany <eduard....@gmail.com> wrote:

But you already have events windows and keyboards, witch glfw provides. The only step missing is the opengl window context creation. Function loading can be done with gogl. Am I missing something..? I'm no expert here

[Eduard Castany]

Then what does win_windows.go do? Sorry if it's a stupid question

[John Asmuth]

go.wde and go.wde/win are two separate packages. win is the windows backend. just like there is currently go.wde/win, go.wde/xgb, and go.wde/cocoa, there could also be go.wde/glfw which would take advantage of the information provided by glfw.

On Sun, Jun 23, 2013 at 11:27 AM, Eduard Castany <eduard....@gmail.com> wrote:

Then what does win_windows.go do? Sorry if it's a stupid question