On Mon, 20 May 2013 15:44:06 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 14:51:36 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> On Mon, 20 May 2013 14:44:04 -0700, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>> >
>> > These days, native UIs are already hardware accelerated. Aero is,
>> > Quartz is, etc. There was a huge push towards this ten-plus years
>> > ago.
>> >
>>
>> Erm, when it comes to Aero, that depends. Aero Glass, the window
>> chrome is rendered in Hardware. But the styling of each UI widget,
>> buttons for example, is still done by GDI in software.
>>
>
> Really? Wow. What in the world *have* they been accomplishing in the
> past decade? ;)
>

Windows 8!!!!!!111111

:-S

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 14:47:47 -0700, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 5/20/13, Adam Wilson <flyboynw@gmail.com> wrote:
>> * There is a deep-seated distrust of any toolkit that does not use the OS
>> Native UI widgets.
>
> That's a shame. If you go native you'll have the "look and feel", but
> you'll have X times the work where X is the number of platforms
> supported. Also, each platform has its own bugs, so you'd have to
> write a lot of workaround code as well (e.g. wxWidgets is full of
> win32 workarounds).
>
> Doing it non-native slows you down at first, but it gives you a lot
> more control on how you can render things. You can add a feature
> without having to worry on how to port the feature to other platforms.
> And finally, you can simulate the native windowing environment.
>
> Just to mention this, we already have native libraries (and written in
> D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find
> them successful, they get the occasional pull request, but otherwise
> they seem to lack any sort of team effort or going-forward schedule.
> So I'd say going "native" has already been a failed experiment (take
> that with a huge grain of salt, it's just my personal viewpoint :) ).
>
>> * Nobody believes that we can do it, you'll hear a lot of moaning about
>> how much work it is. My reply to that is: And Linux is such a piece of
>> cake right? It's only the most widely used kernel on the planet.
>
> I think the lesson with Linux is that one person initially did a lot
> of heavy lifting, and then others joined in. I doubt it would work as
> it did if instead Linus opened a thread asking for a team of
> developers to create a new OS from scratch.
>
> Anyway, there's no doubt a D GUI would be a huge undertaking. There
> would almost certainly be a lot of rewriting involved. It's very easy
> to make mistakes early on and hardcode something, only later to
> realize it's way too brittle so it requires a rewrite. If the system
> is modular enough then the rewrites become less painful. And if the
> system is properly unit tested then regressions become less likely,
> and this is important.
>

It's not the rewriting itself that bothers me, I've worked on enough team projects to know that it's nigh inevitable. My point was just that a good design process can reduce the amount of rewriting that happens by keeping a clear focus on the end goal and being willing to say "no".

> From what I've seen when a codebase becomes large enough, what
> inevitably happens is people stop hacking on the codebase almost
> entirely. It's usually because the codebase is huge and not modular,
> or undocumented, or not tested, or doesn't have any sort of schedule
> on the work that needs to be done.
>
> I have zero doubt that we have the know-how or hacking ability to
> actually work and solve GUI problems in D, but I have big doubts that
> we would ever have leadership that would make sure we have a proper
> schedule and todo list, proper discussions, the guts to say "no" to
> features, etc. It's just not going to work if people randomly create
> pull requests with some code they thought would be nice to include in
> a GUI library.
>
> So to actually do it, I think we need:
>
> 1) A "core" for a GUI library written in D that people can start
> hacking on (meaning you can create windows, and draw in a pixel
> buffer, capture device input, all platform-independent), and
>
> 2) Solid leadership.
>
> I'd say #2 is more important than #1, because #1 is something many
> people can do, and #2 is the really hard bit.

#2 is critical. #1 is just technical leg-work.

#2 is tough to find, and to be honest, I don't know that anyone here could say that they have the technical chops to make it happen. I mean how many of us actually do GUI coding every day? I know I do, but I don't think that is enough to qualify one as a leader. We also need a vision and developer commitment.

I'd be willing to lead the project, I'm just not sure I am the right person to do so. I have a vision, and the skeleton of a design, but no code. I am willing, but my ability is a question mark...

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 13:49:28 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>>
>> And my point is that your assertion that it can never be done is
>> patently untrue. If MS can do it, there is no technical barrier to
>> FOSS doing it, other than our own mental conception of what we are
>> capable of. The point about WPF is that the system is so flexible in
>> it's rendering that you can precisely emulate any native OS toolkit,
>> or go off in a completely new direction. I prefer that flexibility as
>> a UI designer.
>>
>
> I still have a hard time believing that it's realistic for it take take
> everything into account. *Even* if you go to all the effort to make
> every render and behavior pixel-perfect, you're *still* failing to
> account for all of the following things, all of which actually *exist*:
>
> - Software to allow the user to custom-reskin the system. Yes, even on
>   Windows this exists, and has for a looong time. Getting a third-party
>   GUI toolkit compatible with this would likely be quite difficult, if
>   even possible.
>

What if as a UI designer I know that I want to specifically disallow skinning? It's not even that hard of a decision to reach. If the skinning changes the layout metrics at all (margin, padding, size, even shape), my app can end up looking terrible and I have to take a support call for a case that I couldn't have possibly dreamed up.

> - On windows, I use a program called KatMouse that allows me to scroll
>   any control by just pointing at it and using my mouse's scroll-wheel.
>   No need to manually "focus" the control before the retarded Win system
>   allows me to scroll it. This is literally my #1 favorite windows
>   program. But this obviously doesn't work on programs that merely
>   *emulate* the system's look-and-feel, no matter how meticulous the
>   emulation. Hell, even the UI changes in "native" MS-developed Vista
>   and Win7 break it at least half the time.
>

I'd say it's on the developers of KatMouse to get their crap together. It sounds like their development model is "don't upgrade from WinXP because we like that one." By saying that even the MS native changes break it, you've kind of invalidated your point. You are telling me that's it not really a UI problem but a problem with the tool. Yes, this would be completely non-functional in WPF and similar. But I'd stand by the statement that it is imprudent to support extreme corner cases. You may like it, by I've never even heard of it, and my guess is that almost nobody else has either.

> - Tools to reveal the value behind "******"-filled password boxes.
>   Sounds like a black-hat tool, but I've personally had legitimate
>   need to use it.
>

Ehrm, TBH, I consider breaking those tools a good thing. Yes there may be legitimate uses, but the number if illegitimate uses far exceeds the benefit.

> - Anything else that involves either GUI-introspection or adding a
>   cross-application UI feature. There's plenty of other
>   entirely valid use-cases.
>

What is the use case for GUI introspection?

> Unless I'm mistaken, these sorts of things *cannot* be handled by a
> non-native UI without either the given utility special-casing every
> specific UI toolkit out there, or the UI toolkit (somehow)
> special-casing every such tool/utility. Neither approach is scalable
> enough to be a real solution. Ultimately, there must be *some* common
> system-wide UI, without cheaters, so that cross-cutting features are
> *realistically* possible and not inherently unreliable.
>
> Of course, you could say that such uses aren't important, but I'd very
> strongly disagree.
>

Manipulating a UI from another process is bad, evil, and a massive security problem, I'd say that disallowing it is a service to the world.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 14:27:51 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 13:58:56 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> On Mon, 20 May 2013 13:20:22 -0700, Nick Sabalausky
>> <SeeWebsiteToContactMe@semitwist.com> wrote:
>>
>> > On Mon, 20 May 2013 12:41:08 -0700
>> > "Adam Wilson" <flyboynw@gmail.com> wrote:
>
>> >> markup is extensible, OS widgets are not.
>> >>
>> >
>> > I don't know where you got that idea.
>> >
>>
>> I mean extensible in terms of look or style, sorry for the ambiguity.
>
> Ahh, ok, I wasn't actually sure exactly what sort of "extensible" you
> meant.
>
>> OS widgets require tons of custom coding to change the style, I've
>> done it, and I hated every minute of it. But with WPF I don't even
>> think twice, I just do it, because I can get the exact style in under
>> an hour.
>>
>
> Honestly, I'd consider that a major downside: Anything that
> helps/encourages developers to disregard a user's system settings
> (style or otherwise) is a very bad thing, IMO.
>
> Of course, if the toolkit automatically comes with a
> guaranteed user-selectable setting, outside of the app's control, to
> optionally disable any custom styling on a per-app or global basis, then
> that's the best solution of all: It attracts the "To hell with the
> user's system settings because *I* deserve to be in control of my user's
> computer" crowd and then uses that to hand control *back* to the user,
> where it belongs. I've often thought about developing a system like
> that.
>

Very few actual users care about changing the behavior of the widgets. Most people who want to change them just want to skin them.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 15:35:16 -0700, Brad Roberts <braddr@puremagic.com> wrote:

> On 5/20/13 3:08 PM, Adam D. Ruppe wrote:
>> On Monday, 20 May 2013 at 22:04:06 UTC, Andrej Mitrovic wrote:
>>> everyone has their own unique idea and where they disagree with each
>>> other.
>>
>> I don't even agree with myself!
>
> I've been trying to find a good point in this thread to inject my basic thoughts on the subject.  This is probably the best place (and it's not directly specifically at you Adam but rather the topic).
>
> I think it's a pretty huge fallacy to even consider that there can be one true standardized gui toolkit.  As evidence, just look at the sheer number of them that exist right now.  If you could pick a top 10 list, and I think even that would be hard, there's not a clearly ahead of the others champion.  There's just too many different philosophies and approaches to the problem with too many competing goals.
>
> The "ideal GUI" is something that I believe can't be defined, much less exist.
>
> As to re-invent vs wrap.. just consider the number of man years poured into your favorite gui toolkits that already exist, and then consider repeating that cost.  Aren't there a number of other projects, todo's, bug fixes, etc that would benefit from even a fraction of that sort of investment?
>
> My 2 cents,
> Brad
>

Brad, normally I'd agree with you because I am lazy. I hate reinventing, occasionally I spend more time trying to not reinvent than it would've taken to reinvent.

However, are we really reinventing? Yes, on a broad level it's yet another GUI toolkit. But the goal is WPF, not native. And to date the closest thing I've found is QtD, and that requires you fit the Qt ideology, it's not D native. But more to the point Qt is just a shadow of WPF. They are starting to work towards it but they've got a long way to go. D offers inherent advantages that can pretty dramatically speed up the process. We are really creating a markup based UI toolkit in native D. I don't think that exists. It'll can become a showcase for D and has the potential to be used outside of D. Because of that, I don't think it's really reinvention, we're using existing ideas and applying them to D.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Mon, 20 May 2013 23:47:47 +0200
Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 5/20/13, Adam Wilson <flyboynw@gmail.com> wrote:
> > * There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets.
> 
> That's a shame. If you go native you'll have the "look and feel", but you'll have X times the work where X is the number of platforms supported. Also, each platform has its own bugs, so you'd have to write a lot of workaround code as well (e.g. wxWidgets is full of win32 workarounds).
> 
> Doing it non-native slows you down at first, but it gives you a lot more control on how you can render things. You can add a feature without having to worry on how to port the feature to other platforms. And finally, you can simulate the native windowing environment.
> 

While non-native does have certain potential benefits, it's ultimately an inherently-flawed approach because the whole "simulate the native" starts becoming under-valued.

This under-valuing is inevitable because not only is "simulate the
native" far harder to get right than it seems, but it turns
out not to even be realistically possible in many cases that aren't
immediately obvious, but are nonetheless important.

This inevitable "under-valuing" of "simulate the native" is necessarily an erosion of respect for the user's property and preferences. The convenience of the toolkit's developers, and app's developers *becomes* the "center of the universe" so to speak.

But unfortunately, any time "the user" stops being the #1 priority, then technology has already failed it's raison d'être. At that point, nothing else matters and it's all becomes pointless waste of time.

tl;dr: Developing a non-native GUI is a cheap shortcut. The hidden cost
comes as severely diminished value for all software that uses it,
thus ultimately wasting everyone's time, including the toolkit's
original developers.

> Just to mention this, we already have native libraries (and written in D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find them successful, they get the occasional pull request, but otherwise they seem to lack any sort of team effort or going-forward schedule. So I'd say going "native" has already been a failed experiment (take that with a huge grain of salt, it's just my personal viewpoint :) ).
> 

By the same token, we don't have any non-native GUIs in D that have fared any better.

> 
> I have zero doubt that we have the know-how or hacking ability to actually work and solve GUI problems in D, but I have big doubts that we would ever have leadership that would make sure we have a proper schedule and todo list, proper discussions, the guts to say "no" to features, etc. It's just not going to work if people randomly create pull requests with some code they thought would be nice to include in a GUI library.
> 

I tend to feel the same way, to be honest.

Or rather, I suspect we may actually have the potential leadership, but
any such people are struggling to find the necessary time to
dedicate to it. Leadership is more than just the willingness and
ability to lead, but also about having the time (and any other
needed resources) with which to do it.

On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
> Sub-pixel font hinting. Almost no games use this, and almost every OS toolkit does.

There used to be a nice article about font rendering in OpenGL (methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1

But the link is dead. Most h3r3tic links are dead, not even archive.org has them.

On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:
> On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
>> Sub-pixel font hinting. Almost no games use this, and almost every OS
>> toolkit does.
>
> There used to be a nice article about font rendering in OpenGL
> (methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1
>
> But the link is dead. Most h3r3tic links are dead, not even
> archive.org has them.

I have code based in that tutorial in my current project:

https://github.com/kiith-sa/awesome2D

See the font subdirectory and demo/texturepacker.d
(Note that the package/module structure is badly organized due to rushing).


A slightly different implementation is in my older project, ICE, but it doesn't compile with current DMD.

I'm also working on a simple in-game GUI library as a part of this project,
but I'm only doing what I need myself (which is virtually nothing right
now, because time) and its not nearly  as convenient to use as it could be. Also, not intended for OS-style GUIs, just game GUIs and maybe non-standard stuff like what you see in graphics programs.

H3r3tic had a more advanced GUI framework (still not native), hybrid, which IMO has a far better API than any framework I've seen, but I never found the source,
only documentation somewhere on his (unmaintained) site.

On Mon, 20 May 2013 15:50:06 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Mon, 20 May 2013 15:21:22 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> >
> > I still have a hard time believing that it's realistic for it take take everything into account. *Even* if you go to all the effort to make every render and behavior pixel-perfect, you're *still* failing to account for all of the following things, all of which actually *exist*:
> >
> > - Software to allow the user to custom-reskin the system. Yes, even on Windows this exists, and has for a looong time. Getting a third-party GUI toolkit compatible with this would likely be quite difficult, if even possible.
> >
> 
> What if as a UI designer I know that I want to specifically disallow skinning? It's not even that hard of a decision to reach. If the skinning changes the layout metrics at all (margin, padding, size, even shape), my app can end up looking terrible and I have to take a support call for a case that I couldn't have possibly dreamed up.
> 

Basing software decisions upon worries of "What if some user shoots himself and calls our support?" is *always* a bad idea.

The user overrides the developer/designer. Always. The user is the whole reason for *anything* we do in this field. The user may as well be God - if they want to do something questionable, we can raise warnings, but it is *absolutely* not our place to prevent it. As soon as you start down that route, anything you do becomes a pointess waste that defeats its own reason for existence.


> > - On windows, I use a program called KatMouse that allows me to scroll any control by just pointing at it and using my mouse's scroll-wheel. No need to manually "focus" the control before the retarded Win system allows me to scroll it. This is literally my #1 favorite windows program. But this obviously doesn't work on programs that merely *emulate* the system's look-and-feel, no matter how meticulous the emulation. Hell, even the UI changes in "native" MS-developed Vista and Win7 break it at least half the time.
> >
> 
> I'd say it's on the developers of KatMouse to get their crap together. It sounds like their development model is "don't upgrade from WinXP because we like that one."[...]

You're missing the point:

The point is NOT that "XP -> 7 should be seamless for all software". I don't believe that, and I would never claim it or deliberately imply it.

The point is that even the most *meticulous* and convincing native emulation is *still* insufficient (and ultimately a big waste of time).

Should it be the responsibility of the program itself support newer
versions of Win? Obviously. (Unfortunately, KatMouse appears to
be closed-source abandonware, but that's completely beside the point.)

Should it be the responsibility of the program itself to support the various non-native third-party GUIs just because some self-important GUI developers didn't feel like playing ball and decided that *their* internal conveniences were more important than their users, the very people for whom the all this software exists in the first place? *Absolutely not*.


> You may like it, by I've never even
> heard of it, and my guess is that almost nobody else has either.
> 

popularity != importance
popularity != value
popularity != worthiness

(popularity != a goddamn thing)

It is unreasonable to expect GUI developers or GUI designers to explicitly support various tools like KatMouse? Absolutely. It is definitely unreasonable. And that's *exactly* why non-native GUIs are horrible idea.


> > - Tools to reveal the value behind "******"-filled password boxes.
> >   Sounds like a black-hat tool, but I've personally had legitimate
> >   need to use it.
> >
> 
> Ehrm, TBH, I consider breaking those tools a good thing. Yes there may be legitimate uses, but the number if illegitimate uses far exceeds the benefit.
> 

I strongly disagree:

First of all, there is very little, if any, illegitimate use of this that doesn't require *at least* as significant a security breach to have *already* occurred.

Secondly, we're not babysitters or self-appointed police here. To engage in such a level of control is *already* a very serious breach of our moral obligations.


> > - Anything else that involves either GUI-introspection or adding a
> >   cross-application UI feature. There's plenty of other
> >   entirely valid use-cases.
> >
> 
> What is the use case for GUI introspection?
> 

Just for example, Spy++ or any similar such developer tool. Or GUI macros. Those are just off the top of my head. I'm sure people can, and have, thought of any number of other different uses.

> 
> Manipulating a UI from another process is bad, evil, and a massive security problem, I'd say that disallowing it is a service to the world.
> 

I couldn't disagree more. I don't believe for a second that that's even the slightest bit different from saying "Using a computer is bad, evil, and a massive security problem; disallowing them is a service to the world."

We're not Big Brother and I, for one, refuse to be party to anything even remotely smelling as such, which is something (ie, "Big Brother") that I very much believe your views on our responsibilities as developers *do*, by necessity, constitute.

On Monday, 20 May 2013 at 23:40:34 UTC, Andrej Mitrovic wrote:
> On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
>> Sub-pixel font hinting. Almost no games use this, and almost every OS
>> toolkit does.
>
> There used to be a nice article about font rendering in OpenGL
> (methinks) here: http://h3.gd/dmedia/?n=Tutorials.TextRendering1
>
> But the link is dead. Most h3r3tic links are dead, not even
> archive.org has them.

Generally the idea is to pack the characters into a texture and then render from that - it's very fast as you don't have to switch textures which is relatively slow. There are a few different ways of representing the characters (for large text signed distance maps seem to be currently the state of the art) while for small text a simple single channel alpha map is good and fast.

TBH the rendering itself is fairly simple, the hard part is the layout, glyph conversion and kerning. It seems like the new std.uni module actually does some of the glyph conversion which is nice.

Another technique that might be worth looking into is simply getting the OS to render the text as it will be displayed to a texture and then it's just a case of blitting that to the screen. With some caching that could be efficient enough, most gui text does not change very often, otherwise you wouldn't have time to read it...